原文：15-a-postmortem-of-three-recent-issues.md 来源：https://www.anthropic.com/engineering/a-postmortem-of-three-recent-issues
三个近期问题的故障复盘
发布于 2025 年 9 月 17 日
本文是关于三个间歇性降低 Claude 响应质量的 bug 的技术报告。下面解释发生了什么、为什么修复花了时间、以及我们正在改变什么。
8 月到 9 月初，三个基础设施 bug 间歇性降低了 Claude 的响应质量。我们已解决这些问题，想解释发生了什么。
8 月初，一些用户开始报告 Claude 响应降级。这些初始报告难以与用户反馈的正常变化区分。8 月底，这些报告频率和持续性增加促使我们开调查，最终揭示了三个独立的基础设施 bug。
直接说明：我们从不因需求、时段或服务器负载降低模型质量。我们用户报告的问题仅 由基础设施 bug 引起。
我们认识到用户期望 Claude 一致质量，对确保基础设施改动不影响模型输出维持极高门槛。这些近期事件中，我们没达到那个门槛。本故障复盘解释哪里出错、为什么检测和解决比我们想要的久、我们正在改变什么以防止类似未来事件。
我们通常不分享这种基础设施技术细节级别，但这些问题的范围和复杂性证明更全面解释合理。
我们如何大规模服务 Claude
我们通过我们的第一方 API、Amazon Bedrock 和 Google Cloud's Vertex AI 服务数百万用户。部署 Claude 跨多硬件平台——AWS Trainium、NVIDIA GPU、Google TPU。这种方法提供服务全球用户所需的容量和地理分布。
每个硬件平台有不同特性，需要特定优化。尽管这些变化，我们对模型实现有严格等价标准——目标是用户应得到相同质量响应，不论哪个平台服务请求。这种复杂性意味任何基础设施改动需要跨所有平台和配置仔细验证。
事件时间线
这些 bug 的重叠性质让诊断特别有挑战。第一个 bug 8 月 5 日引入，影响约 0.8% 的 Sonnet 4 请求。两个更多 bug 来自 8 月 25 和 26 日的部署。
虽然初始影 响有限，8 月 29 日的负载均衡改动开始增加受影响流量。这导致更多用户体验问题，而其他人继续看到正常性能——创造混乱矛盾的报告。
三个重叠问题
1. 上下文窗口路由错误
8 月 5 日，一些 Sonnet 4 请求被错误路由到为即将到来的 1M token 上下文窗口配置的服务器。这个 bug 初始影响 0.8% 的请求。8 月 29 日例行负载均衡改动无意中增加了短上下文请求被路由到 1M 上下文服务器的数量。8 月 31 日最差影响小时，16% 的 Sonnet 4 请求受影响。
约 30% 的 Claude Code 用户在该期间至少有一条消息被路由到错误服务器类型，导致响应降级。
某些用户被影响更严重——我们的路由是"粘性的"。这意味一旦请求被错误服务器服务，后续后续可能被同一错误服务器服务。
解决：修复路由逻辑确保短和长上下文请求被导向正确服务器池。9 月 4 日部署修复，第一方平台和 Vertex AI 9 月 16 日完成 rollout，AWS Bedrock 9 月 18 日完成。
2. 输出损坏
8 月 25 日，我们部署了 Claude API TPU 服务器的错误配置，导致 token 生成时的错误。运行时性能优化引起的问题偶尔为给定上下文应该很少产生的 token 分配高概率——例如对英语提示产生泰语或中文字符，或在代码中产生明显语法错误。
例：用英语提问的小子集用户可能在响应中间看到"สวัสดี"。
这种损坏影响：8 月 25-28 日的 Opus 4.1 和 Opus 4 请求；8 月 25-9 月 2 日的 Sonnet 4 请求。第三方平台未受影响。
解决：识别问题并 9 月 2 日回滚改动。我们已为部署流程添加意外字符输出的检测测试。
3. 近似 top-k XLA:TPU 错误编译
8 月 25 日，我们部署改善 Claude 在文本生成时如何选择 token 的代码。这改动无意触发了 XLA:TPU 编译器中的潜伏 bug——已确认影响对 Claude Haiku 3.5 的请求。
也相信这可能影响过 Claude API 上 Sonnet 4 和 Opus 3 的子集。
解决：首先观察 bug 影响 Haiku 3.5 并 9 月 4 日回滚。后注意到 Opus 3 用户报告与此 bug 兼容，9 月 12 日回滚。广泛调查后无法在 Sonnet 4 上复现，但出于过分谨慎也回滚。
同时：(a) 与 XLA:TPU 团队合作修复编译器 bug；(b) 部署修复使用增强精度的精确 top-k。
深入看 XLA 编译器 bug
要说明这些问题的复杂性，这是 XLA 编译器 bug 如何表现及为什么特别难诊断。
Claude 生成文本时，为每个可能下一词计算概率，然后从这个概率分布随机选样。我们用 "top-p sampling" 避免无意义输出——只考虑累积概率达到阈值（通常 0.99 或 0.999）的词。TPU 上，模型跨多芯片运行，概率计算在不同位置发生。排序这些概率需要协调芯片间数据——这复杂。
2024 年 12 月，我们发现 TPU 实现偶尔在温度为零时丢掉最可能 token。我们部署了 workaround 修复此情况。
根因涉及混合精度算术。我们的模型在 bf16（16 位浮点）计算下一 token 概率。但向量处理器是 fp32 原生的，所以 TPU 编译器（XLA）可通过把某些操作转为 fp32（32 位）优化运行时。这优化通道由 xla_allow_excess_precision flag 守卫，默认 true。
这导致不匹配：本应在最高概率 token 上一致的操作以不同精度级别运行。精度不匹配意味它们不同意哪个 token 概率最高。这导致最高概率 token 有时完全从考虑中消失。
8 月 26 日，我们部署了采样代码重写以修复精度问题。但修复时，我们暴露了更棘手的问题。
我们的修复移除了 12 月 workaround 因为我们认为已解决根因。这导致近似 top-k 操作中的更深 bug——一个快速找最高概率 token 的性能优化。这近似有 时返回完全错误结果，但只对某些批次大小和模型配置。12 月 workaround 一直无意中掩盖此问题。
bug 行为令人沮丧地不一致。它取决于不相关因素而变化——如什么操作在它之前或之后运行、调试工具是否启用。同一提示可能在一个请求完美工作，下一个失败。
调查时，我们也发现精确 top-k 操作不再有曾经的高昂性能代价。我们从近似切换到精确 top-k，并把一些额外操作标准化到 fp32 精度。模型质量不可妥协，所以我们接受小效率影响。
为什么检测困难
我们的验证流程通常依赖基准测试加上安全评估和性能指标。工程团队执行抽查并先部署到小"金丝雀"组。
这些问题暴露了我们应早识别的关键缺口。我们运行的评估根本没捕捉用户报告的降级，部分因为 Claude 常从孤立错误中恢复良好。我们自己的隐私实践也在调查报告中创造挑战——我们的内部隐私和安全控制限制工程师如何及何时访问用户与 Claude 的交互。这保护用户隐私，但阻止工程师检查识别或复现 bug 所需的问题交互。
每个 bug 在不同平台以不同速率产生不同症状。这创造令人困惑的报告混合，不指向任何单一原因——看起来像随机、不一致降级。
更根本的，我们太依赖嘈杂的评估。虽我们意识到在线报告增加，我们缺乏将这些与每个近期改动连接的清晰方式。8 月 29 日负面报告激增时，我们没立即与原本标准的负载均衡改动建立连接。
我们正在改变什么
继续改进基础设施时，我们也改进跨所有服务 Claude 的平台评估和防止上述 bug 的方式：
- 更敏感的评估：开发能更可靠区分工作和损坏实现的评估
- 更多地方的质量评估：在真实生产系统上持续运行评估，捕捉如上下文窗口负载均衡错误的问题
- 更快的调试工具：开发不牺牲用户隐私下更好调试社区采购反馈的基础设施和工具
评估和监控重要。但这些事件显示我们也需要来自用户的持续信号——当 Claude 响应不达通常标准时。观察到的具体改动报告、遇到的意外行为示例、跨不同用例的模式，都帮我们隔离问题。
继续直接发送反馈对用户特别有帮助。你可以在 Claude Code 用 /bug 命令或在 Claude 应用用"thumbs down"按钮。开发者和研究员常创建评估模型质量的新有趣方式，补充我们内部测试。如果你想分享你的，联系 feedback@anthropic.com。
脚注
[1] XLA:TPU 是 优化编译器，把 XLA 高级优化语言（常用 JAX 写）翻译为 TPU 机器指令。
[2] 我们的模型对单芯片太大，分区跨数十个或更多芯片，让我们的排序操作成分布式排序。TPU（如 GPU 和 Trainium）也有与 CPU 不同的性能特征，需要不同实现技术——用向量化操作而非串行算法。
[3] 我们一直用这近似操作因为它产生显著性能改善。近似工作通过接受最低概率 token 的潜在不准确——不应影响质量——除非 bug 导致它丢掉最高概率 token。
[4] 现在正确的 top-k 实现可能导致 top-p 阈值附近 token 包含的轻微差异，罕见情况下用户可能从重新调整 top-p 选择中受益。