三个近期问题的复盘
发布时间： 2025年9月17日
概述
2025年8月至9月初，三个基础设施 Bug 间歇性地降低了 Claude 的响应质量。Anthropic 现已解决这些问题，并发布此技术复盘，解释发生了什么、为何检测耗时较长，以及正在实施哪些改进措施。
核心声明
"我们从不因需求、时段或服务器负载而降低模型质量。用户报告的问题完全由基础设施 Bug 引起。"
Claude 的大规模服务架构
Anthropic 通过以下渠道向数百万用户提供 Claude：
- 官方 API
- Amazon Bedrock
- Google Cloud Vertex AI
服务运行在多种硬件平台上：
- AWS Trainium
- NVIDIA GPU
- Google TPU
每个平台特性不同，需要针对性优化，但 Anthropic 保持严格的等价标准，确保用户无论通过哪个平台获得服务都能得到一致的质量。
事件时间线
三个 Bug 相互重叠，增加了诊断难度：
- 8月5日： 第一个 Bug 引入，影响约 0.8% 的 Sonnet 4 请求
- 8月25-26日： 两个额外 Bug 引入
- 8月29日： 负载均衡变更增加了受影响流量
- 8月31日： 影响峰值——16% 的 Sonnet 4 请求受影响
- 9月2-4日： 初步修复部署
- 9月12-18日： 剩余修复完成部署
三个 Bug
1. 上下文窗口路由错误
8月5日，部分 Sonnet 4 请求被错误路由到配置为即将推出的 1M token 上下文窗口的服务器。起初影响 0.8% 的请求，8月29日的负载均衡变更将影响扩大到峰值的 16%。
各平台影响：
- Claude Code：约 30% 的用户至少经历过一次错误路由的消息
- Amazon Bedrock：峰值时 0.18% 的 Sonnet 4 请求
- Google Cloud Vertex AI：不到 0.0004% 的请求
路由系统具有"粘性"，意味着一旦请求被发送到错误的服务器，后续消息很可能会继续被发送到同一个错误的服务器。
解决方案： 9月4日修复路由逻辑；9月18日完成部署。
2. 输出损坏
8月25日，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。
确认受影响的模型：
- Claude Haiku 3.5
- 可能包括部分 Sonnet 4 和 Opus 3
第三方平台未受影响。
解决方案：
- Haiku 3.5：9月4日回滚
- Opus 3：9月12日回滚
- Sonnet 4：尽管无法复现，出于谨慎已回滚
- 从近似 top-k 切换到精确 top-k，增强精度
- 与 XLA:TPU 团队协作修复编译器
深度解析：XLA 编译器 Bug
这个 Bug 展示了问题的复杂性。当 Claude 生成文本时，它会计算每个可能的下一个词的概率，然后使用"top-p 采样"从分布中采样——只考虑累计概率达到阈值（通常为 0.99 或 0.999）的词。
根本原因： 混合精度算术
模型使用 bf16（16位浮点）计算下一个 token 的概率，但 TPU 向量处理器原生支持 fp32。XLA 编译器通过将操作转换为 fp32（32位）来优化运行时，这由 xla_allow_excess_precision 标志控制（默认为 true）。
这种不匹配意味着操作在判断哪个 token 概率最高时产生分歧，有时会导致最高概率的 token 从候选中消失。
复合问题：
2024年12月，针对 temperature 为零时偶发的 token 丢失 Bug 部署了一个临时解决方案。8月26日，采样代码重写移除了这个临时方案，认为根本原因已修复。然而，这暴露了近似 top-k 操作中更深层的 Bug——这是一个性能优化，在特定批次大小和模型配置下有时会返回完全错误的结果。12月的临时方案无意中掩盖了这个问题。
行为挑战：
这个 Bug 的行为令人沮丧地不一致，会根据无关因素改变——比如它之前/之后运行了什么操作，或是否启用了调试工具。同一个 prompt 在一次请求中可能完美运行，下一次却失败。
最终方案：
在发现精确 top-k 不再有 prohibitive 性能损失后，Anthropic 从近似 top-k 切换到精确 top-k，并统一将额外操作标准化为 fp32 精度。"模型质量不可妥协，所以我们接受了轻微的效率影响。"
检测为何困难
多个因素导致诊断延迟：
评估局限性：
- 基准测试、安全评估和性能指标未能捕获用户报告的质量下降
- Claude 通常能从孤立错误中恢复良好
- 评估敏感度不足
隐私权衡： 内部隐私和安全控制限制了工程师访问用户交互数据，尤其是未作为反馈报告的交互。这保护了用户隐私，但也阻止了工程师检查识别或复现 Bug 所需的问题交互。
令人困惑的模式识别： 每个 Bug 在不同平台上以不同比例产生不同症状，产生了相互矛盾的报告，掩盖了任何单一原因。问题表现为随机、不一致的质量下降。
数据关联挑战： Anthropic 缺乏将在线报告与近期基础设施变更明确关联的机制。当 8月29日负面报告激增时，与常规负载均衡变更的联系并非显而易见。
改进措施
1. 更敏感的评估
Anthropic 开发了能更可靠区分正常和异常实现的评估方法，提高了检测质量问题的能力。
2. 在更多位置进行质量评估
虽然定期评估在系统上运行，但现在将在真实生产系统上持续运行，以捕获上下文窗口负载均衡错误等问题。
3. 更快的调试工具
基础设施和工具将改进对社区反馈的调试能力，同时保护用户隐私。此次事件中开发的定制工具将减少未来类似问题的修复时间。
用户反馈的重要性
"评估和监控很重要。但这些事件表明，当 Claude 的回复未达到通常标准时，我们还需要来自用户的持续信号。"
用户可通过以下方式报告问题：
- Claude Code 中的
/bug命令 - Claude 应用中的"拇指朝下"按钮
- 直接发送至 feedback@anthropic.com
鼓励开发者和研究人员分享他们创建的质量评估方法。
致谢
由 Sam McAllister 撰写，感谢 Stuart Ritchie、Jonathan Gray、Kashyap Murali、Brennan Saeta、Oliver Rausch、Alex Palcuie 和许多其他人。
注释
[1] XLA:TPU 是将 XLA（高层优化语言，通常使用 JAX 编写）转换为 TPU 机器指令的优化编译器。
[2] 模型分布在数十个芯片上，使得排序成为分布式操作。TPU 需要向量化操作而非串行算法，这与 CPU 性能特性不同。
[3] 近似操作通过接受最低概率 token 的潜在不准确性来提供显著的性能提升。这个 Bug 导致它丢弃最高概率的 token。
[4] 修正后的 top-k 实现可能在 top-p 阈值附近产生轻微差异；用户可能需要重新调优 top-p 值。