三个近期基础设施问题的事后复盘
官方原文: https://www.anthropic.com/engineering/a-postmortem-of-three-recent-issues
发布日期： 2025 年 9 月 17 日
作者： Sam McAllister 撰写。感谢 Stuart Ritchie、Jonathan Gray、Kashyap Murali、Brennan Saeta、Oliver Rausch、Alex Palcuie 及其他同事。
概览
本文复盘了 2025 年 8 月至 9 月初间歇影响 Claude 回复质量的三项基础设施 Bug。Anthropic 强调：不会因请求量、时段或 server 负载而降低模型质量；本次问题均由基础设施 Bug 引起。
Claude 的服务方式
Claude 通过第一方 API、Amazon Bedrock 和 Google Cloud Vertex AI，在 AWS Trainium、NVIDIA GPU 和 Google TPU 等多个硬件平台上提供服务。各平台需要专门优化，因此基础设施变更必须在不同平台与配置上验证。
事件时间线
用户在 8 月初开始报告输出变差，最初难以与正常波动区分。到 8 月下旬，报告增多，调查最终发现三项相互重叠的 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 配置的 server。Bug 自 8 月 5 日起影响约 0.8% 请求；8 月 29 日一次常规负载均衡变更意外增加了错误路由流量，峰值时影响 16% 请求。期间约 30% Claude Code 用户至少有一条消息被错路由。路由具有“粘性”：一旦首次请求进入错误 server，后续请求也更可能继续进入。
- 开始修复： 9 月 4 日。
- 完成 rollout： 9 月 16 日（第一方 API 和 Vertex AI），9 月 18 日（AWS Bedrock）。
2. 输出损坏
8 月 25 日部署到 Claude API TPU server 的错误配置，导致 token 生成错误。一项 runtime 性能优化偶尔会给本应极少出现的 token 赋予很高概率，例如英文回答中出现泰文或中文字符，或代码中出现明显语法错误。受影响范围是 Opus 4.1、Opus 4（8 月 25 至 28 日）和 Sonnet 4（8 月 25 日至 9 月 2 日）；第三方平台未受影响。
- 修复： 9 月 2 日回滚，并在部署流程中增加异常字符输出检测。
3. Approximate top-k 的 XLA:TPU 误编译
8 月 25 日为改进 token 选择而部署的代码，意外触发 XLA:TPU compiler 的潜在 Bug。已确认影响 Haiku 3.5，并认为可能影响一部分 Sonnet 4 和 Opus 3 请求；第三方平台未受影响。
- 修复： 9 月 4 日回滚 Haiku 3.5，9 月 12 日回滚 Opus 3；Sonnet 4 也出于谨慎回滚。团队与 XLA:TPU 团队合作修复 compiler，并改用更高精度的 exact top-k。
深入：XLA compiler Bug
生成文本时，Claude 会计算下一 token 的概率，并借助 top-p sampling 避免无意义输出。TPU 上的模型跨多个芯片运行，概率排序因而成为分布式排序问题。
2024 年 12 月，团队发现 TPU 实现在 temperature 为零时偶尔遗漏最高概率 token，并部署了一项 workaround。
根因与 mixed-precision arithmetic 有关。模型以 bf16（16 位）计算，但 TPU vector processor 原生使用 fp32，XLA compiler 可能把部分操作转换成 fp32 以优化性能。这导致各操作对最高概率 token 的判断不一致，某些情况下甚至将它完全排除。
8 月 26 日，团队重写 sampling 代码，处理精度问题和接近 top-p threshold 的 token，并移除了 12 月的 workaround，以为根因已经解决。实际却暴露了 approximate top-k 的更深层问题。该性能优化本应用于快速找出高概率 token，但在特定 batch size 与模型配置下会返回完全错误的结果；此前的 workaround 恰好掩盖了它。
这个 Bug 的表现也不稳定，会受周边操作、是否启用调试工具等看似无关的因素影响。最终，团队确认 exact top-k 已不再带来过去那样不可接受的性能损失，因而改为 exact top-k，并将额外操作统一为 fp32 精度。修正后的实现可能会让接近 top-p threshold 的 token 是否被纳入产生细微差别。
为什么难以及时发现
- 现有 eval 没能捕获用户报告的退化，部分原因是 Claude 常能从孤立错误中恢复。
- 内部隐私控制限制了工程师查看未被主动反馈的问题交互。
- 三项 Bug 在不同平台以不同频率呈现不同症状，报告相互干扰。
- 团队过度依赖噪声较大的 eval，且缺少将线上报告关联到具体变更的机制。
- 8 月 29 日的负载均衡变更未能立即与负面报告激增建立关联。
后续改进
- 建设更敏感的 eval，更好地区分正常实现与异常实现。
- 在更多位置持续运行质量 eval，包括真实生产系统。
- 加快调试工具建设，在不牺牲用户隐私的前提下更好分析社区反馈。
用户可通过 Claude Code 的 /bug、Claude 应用内的“踩”按钮，或发送邮件至 feedback@anthropic.com 提交反馈。