Anthropic 对 2024 年 8 月至 9 月 Claude 基础设施故障的事后分析
摘要
Anthropic 披露了三个独立的基础设施故障，这些故障在 2024 年 8 月初至 9 月初期间间歇性地降低了 Claude 的响应质量，并描述了根本原因、补救措施以及为防止再次发生而即将进行的改进。
Claude 的大规模服务方式
Claude 部署在多个云提供商（AWS、Amazon Bedrock、Google Cloud Vertex AI）和硬件后端（AWS Trainium、NVIDIA GPU、Google TPU）之上。Anthropic 强制执行严格的等效标准，以确保无论底层平台如何，请求都能获得相同的质量。这种多平台策略带来了复杂性：任何代码或配置更改都必须在每个硬件堆栈上进行验证。
事件时间线
| 日期 | 事件 |
|---|---|
| 8 月 5 日 | 引入第一个故障（上下文窗口路由错误），影响了约 0.8% 的 Sonnet 4 请求。 |
| 8 月 25 日至 26 日 | 部署了两个额外的故障（TPU 服务器上的输出损坏；近似 top-k XLA 错误编译）。 |
| 8 月 29 日 | 负载均衡更改意外放大了路由错误，将影响推高至单小时内 16% 的 Sonnet 4 请求。 |
| 9 月 2 日 | 回滚了输出损坏故障。 |
| 9 月 4 日 | 部署了路由错误修复；为 Haiku 3.5 回滚了近似 top-k 故障。 |
| 9 月 12 日 | 为 Opus 3 回滚了近似 top-k 故障。 |
| 9 月 16 日至 18 日 | 在第一方平台、Vertex AI 和 Bedrock 上全面推出路由修复。 |
这些故障的重叠性质使得诊断变得困难，因为不同的症状出现在不同的平台上，且频率各异。
三个重叠的问题
1. 上下文窗口路由错误
- 发生了什么： 针对短上下文的 Sonnet 4 请求被错误地发送到为即将推出的 1M token 上下文窗口配置的服务器。
- 影响： 最初影响 0.8% 的请求；8 月 31 日达到峰值，影响了 16% 的 Sonnet 4 流量。约 30% 的 Claude Code 用户至少遇到一次错误路由请求。Amazon Bedrock 上的错误路由在 Sonnet 4 请求中最高达到 0.18%；在 Vertex AI 上则保持在 0.0004% 以下。
- 为何重要： 路由是“粘性的”；一旦会话命中错误的服务器，后续轮次都会停留在该服务器上，从而加剧性能下降。
- 解决方案： 于 9 月 4 日修复了路由逻辑；到 9 月 18 日完成了在所有平台上的部署。
2. TPU 服务器上的输出损坏
- 发生了什么： 一个错误配置引入了一项运行时优化，该优化将高概率分配给了本应极不可能的令牌，导致出现无意义的字符（例如泰文或中文字形）或代码中的语法错误。
- 影响： 从 8 月 25 日至 28 日影响了 Opus 4.1 和 Opus 4，从 8 月 25 日至 9 月 2 日影响了 Sonnet 4。第三方平台（Bedrock、Vertex AI）未受影响。
- 解决方案： 于 9 月 2 日回滚了该更改，并添加了针对意外字符输出的自动化检测测试。
3. 近似 top-k XLA:TPU 错误编译
- 发生了什么： 一项旨在改进令牌选择（token-selection）的代码更改触发了 XLA:TPU 编译器的近似 top-k 操作中的一个潜在故障，导致对于某些批次大小和模型配置，它返回了不正确的高概率令牌。
- 影响： 已在 Claude Haiku 3.5 上确认；怀疑影响 Sonnet 4 和 Opus 3 的子集。对第三方平台没有影响。
- 解决方案： 于 9 月 4 日回滚了 Haiku 3.5 的更改，并于 9 月 12 日回滚了 Opus 3 的更改。切换到使用 fp32 精度的精确 top-k，以适度的性能成本消除了该故障。与 XLA 团队合作，寻求永久的编译器修复。
深入探讨：XLA 编译器故障
Claude 的生成流程使用 top-p 采样。在 TPU 上，概率计算在多个芯片之间进行，需要对 token 概率进行协调排序。系统依赖混合精度算术（模型数学使用 bf16，向量处理使用 fp32）。默认启用的 xla_allow_excess_precision 标志允许编译器将某些 bf16 操作提升为 fp32 以加快速度。
当应用近似 top-k 优化时，精度不匹配导致对于特定的批次配置，最高概率的 token 被完全丢弃。这表现为随机、难以复现的 token 选择错误，有时会在英文回复中插入外语字符。
Anthropic 的修复移除了早前 2024 年 12 月的变通方案（该方案掩盖了症状），并用精确实现替换了近似 top-k，以轻微的效率损失恢复了确定性的 token 选择。
为什么检测很困难
- 评估缺口： 标准基准和安全评估未能发现质量下降，因为 Claude 通常可以从孤立错误中恢复。
- 隐私限制： 内部隐私控制限制了工程师对原始用户交互的访问，阻碍了对未记录故障的根本原因分析。
- 信号噪声： 多个故障在不同平台上产生了不同的症状，表现为随机的质量波动，而不是单一的系统性问题。
- 负载均衡副作用： 8 月 29 日的负载均衡更改放大了路由错误，造成了突然的峰值，但并未立即与底层代码更改联系起来。
Anthropic 正在做出的改变
- 更灵敏的评估 – 能够可靠区分正确和错误实现的新测试将持续完善。
- 生产级质量监控 – 评估将在实时生产系统上运行，而不仅仅是内部金丝雀，以捕获特定于平台的回归。
- 更快的调试工具 – 将构建基础设施，以便在不损害用户隐私的情况下安全地检查社区反馈，从而缩短未来事件的补救时间。
- 用户反馈循环 – Anthropic 鼓励用户通过 Claude Code 中的
/bug命令或 Claude 应用中的“不喜欢”按钮报告异常，并与团队分享自定义评估脚本。
对用户和行业的影响
- 可靠性期望： 即使拥有严格的基础设施，复杂的多平台部署也可能引入影响模型输出质量的细微故障。
- 透明度价值： Anthropic 详细的事后分析为前沿 AI 实验室如何披露基础设施故障提供了范例，有助于建立信任并使社区能够参与检测。
- 工具的重要性： 该事件凸显了在大规模 LLM 服务中，精确且保护隐私的调试工具以及持续的生产监控的必要性。
- 未来的保障措施： 通过转向精确的 top-k 采样并扩大评估覆盖范围，Anthropic 旨在提高 Claude 在所有硬件后端上的基线可靠性。
Anthropic 感谢社区的反馈，并欢迎通过 feedback@anthropic.com 提交更多错误报告和评估贡献。