Claude服务质量下降事故的事后分析

问题描述： 部分 Sonnet 4 的请求被错误地路由到为即将推出的 1M Token 上下文窗口配置的服务器上。

影响范围：

• 最初影响 0.8% 的请求。在 8月31日 的高峰期，影响了 16% 的 Sonnet 4 请求。
• 由于路由具有“粘性”，一旦用户的请求被错误服务器处理，后续请求很可能继续被错误处理，加重了对部分用户的影响。
• 在 Amazon Bedrock 上，错误路由的流量峰值为 0.18%；在 Google Cloud Vertex AI 上，影响小于 0.0004%。

解决方案： 修复了路由逻辑，确保长短上下文请求被定向到正确的服务器池。该修复已于 9月16日 前在自有平台和Google Cloud上完成部署。

问题描述： 8月25日，在 Claude API 的 TPU 服务器上部署的一个错误配置，导致Token生成过程中出现错误。

具体表现： 一项运行时性能优化偶尔会给本不应出现的Token分配高概率，例如在英文回答中插入泰语（"สวัสดี"）或中文字符，或在代码中产生明显的语法错误。

影响范围：

• 影响了 8月25-28日 的 Opus 4.1 和 Opus 4 请求。
• 影响了 8月25日–9月2日 的 Sonnet 4 请求。
• 第三方平台未受此问题影响。

解决方案： 9月2日 发现问题并回滚了变更。同时，在部署流程中增加了对意外字符输出的检测测试。

问题描述： 8月25日，部署的一段旨在改进Token选择的代码，无意中触发了 XLA:TPU 编译器中的一个潜在Bug。

影响范围：

• 已确认影响了 Claude Haiku 3.5。
• 据信可能也影响了 Claude API 上的部分 Sonnet 4 和 Opus 3 请求。
• 第三方平台未受此问题影响。

解决方案： 分别于 9月4日 和 9月12日 回滚了相关代码。同时，正在与XLA:TPU团队合作修复编译器Bug，并已部署了使用更高精度的“精确top-k”作为内部修复方案。

这个Bug的根本原因在于混合精度计算和性能优化的冲突。

• 模型在 bf16（16位浮点）精度下计算概率，但TPU的向量处理器是 fp32（32位）原生的。
• 编译器（XLA）为了优化，会自动将某些操作转换为更高精度的 fp32。
• 这导致了不同芯片上的计算单元在“哪个Token概率最高”这个问题上出现分歧，有时甚至导致概率最高的Token被完全丢弃。
• 2024年12月 的一个临时修复方案无意中掩盖了一个更深层次的、关于“近似top-k”操作的Bug。
• 8月26日 的代码重写移除了这个临时方案，从而暴露了这个更棘手的底层Bug，其行为极其不稳定且难以复现。

模型质量是不可协商的，因此我们接受了切换到性能稍低的“精确 top-k”方案带来的微小效率影响。