三个近期问题的事后复盘
发布日期： 2025年9月17日 作者： Sam McAllister 撰稿，感谢 Stuart Ritchie、Jonathan Gray、Kashyap Murali、Brennan Saeta、Oliver Rausch、Alex Palcuie 及其他众多同事。 来源： Anthropic 工程博客
概述
本技术报告涵盖了三个基础设施 Bug，它们在 2025 年 8 月至 9 月初期间间歇性地降低了 Claude 的响应质量。Anthropic 声明他们"绝不会因为需求量、时间段或服务器负载而降低模型质量"——这些问题纯粹是基础设施 Bug。
Claude 的服务架构
Claude 通过第一方 API、Amazon Bedrock 和 Google Cloud 的 Vertex AI 提供服务，跨多个硬件平台运行：AWS Trainium、NVIDIA GPU 和 Google TPU。每个平台需要特定的优化，基础设施变更需要在所有平台和配置上进行验证。
事件时间线
用户关于响应质量下降的报告始于 8 月初。起初这些很难与正常波动区分开来。到 8 月下旬，频率的增加促使调查展开，发现了三个独立的 Bug。这些 Bug 的重叠特性使诊断尤为困难。
- 8月5日： 引入第一个 Bug，影响约 0.8% 的 Sonnet 4 请求
- 8月25-26日： 部署引发了另外两个 Bug
- 8月29日： 负载均衡变更增加了受影响的流量，导致更广泛的用户影响
- 8月31日： 影响最严重的一小时——16% 的 Sonnet 4 请求受到影响
三个 Bug
1. Context Window 路由错误
部分 Sonnet 4 请求被错误路由到为即将推出的 1M Token Context Window 配置的服务器。该 Bug 在 8 月 5 日影响了 0.8% 的请求。8 月 29 日的一次例行负载均衡变更无意中增加了错误路由的流量。在高峰期，16% 的 Sonnet 4 请求受到影响。在此期间，约 30% 的 Claude Code 用户至少有一条消息被错误路由。路由是"粘性的"，意味着一旦请求命中了错误的服务器，后续请求很可能也会如此。
- 修复部署： 9月4日
- 推出完成： 9月16日（第一方 + Vertex AI），9月18日（AWS Bedrock）
2. 输出损坏
8月25日部署到 Claude API TPU 服务器的一个配置错误导致 Token 生成过程中出现错误。一个运行时性能优化偶尔会为不应出现的 Token 分配高概率——例如在英文响应中出现泰文或中文字符，或代码中出现明显的语法错误。这影响了 Opus 4.1 和 Opus 4（8月25-28日）以及 Sonnet 4（8月25日至9月2日）。第三方平台未受影响。
- 修复： 9月2日回滚。在部署流程中添加了对意外字符输出的检测测试。
3. 近似 Top-K XLA:TPU 编译错误
8月25日部署的改进 Token 选择的代码无意中触发了 XLA:TPU 编译器中的一个潜在 Bug，已确认影响 Haiku 3.5，并被认为可能影响一部分 Sonnet 4 和 Opus 3 请求。第三方平台未受影响。
- 修复： Haiku 3.5 于 9月4日回滚；Opus 3 于 9月12日回滚；Sonnet 4 出于谨慎也进行了回滚。与 XLA:TPU 团队合作修复编译器问题，并切换到具有增强精度的精确 top-k。
深入分析：XLA 编译器 Bug
当 Claude 生成文本时，它会计算下一个 Token 的概率，并使用"top-p 采样"来避免无意义的输出。在 TPU 上，模型跨多个芯片运行，使得概率排序成为分布式排序操作。
2024年12月： 发现了一个 Bug——TPU 实现在温度为零时偶尔会丢弃最可能的 Token。部署了一个临时解决方案。
根本原因： 混合精度算术。模型以 bf16（16位）计算，但 TPU 向量处理器是 fp32 原生的，因此 XLA 编译器可以通过将某些操作转换为 fp32 来优化。这导致了不匹配——操作在最高概率 Token 上产生分歧，有时会将其完全从考虑中丢弃。
8月26日： 部署了采样代码重写以修复精度问题并处理接近 top-p 阈值的 Token。此修复移除了 12 月的临时解决方案，认为根本原因已解决。然而，这暴露了近似 top-k 操作中更深层的 Bug——一种快速找到最高概率 Token 的性能优化。近似有时会返回完全错误的结果，但仅在特定的批大小和模型配置下。12 月的临时解决方案一直在无意中掩盖此问题。
该 Bug 的行为不一致，会根据不相关的因素（如周围操作或是否启用了调试工具）而变化。
最终，Anthropic 发现精确 top-k 不再有曾经的性能代价，因此他们从近似切换到精确 top-k，并将额外操作标准化为 fp32 精度。他们指出，修正后的实现"可能导致 top-p 阈值附近的 Token 包含方面存在细微差异"。
为什么难以检测
- 现有评估未能捕捉到用户报告的质量下降，部分原因是 Claude 通常能从孤立的错误中很好地恢复
- 内部隐私控制限制了工程师检查未报告为反馈的问题交互的能力
- 每个 Bug 在不同平台上以不同速率产生不同的症状，造成报告混淆
- 他们"过于依赖嘈杂的评估"，缺乏将在线报告与特定变更关联的方法
- 8月29日的负载均衡变更没有立即与负面报告的激增关联起来
改进措施
- 更敏感的评估，能够更好地区分正常和异常的实现
- 在更多地方运行质量评估——在真实生产系统上持续运行
- 更快的调试工具，在不牺牲用户隐私的前提下更好地调试社区反馈
用户可以通过 Claude Code 中的 /bug 命令、Claude 应用中的"踩"按钮、或发送邮件至 feedback@anthropic.com 来提供反馈。