三个近期问题的事后复盘¶
原文发布于 2025 年 9 月 17 日，作者 Sam McAllister
概述¶
2025 年 8 月至 9 月初，三个基础设施 Bug 间歇性地影响了 Claude 的响应质量，目前已全部修复。 本文是针对这三个问题的技术复盘报告。
背景¶
用户反馈的质量下降源于基础设施 Bug，而非任何主动降质行为。 8 月初，用户开始反馈 Claude 的响应质量有所下降。到 8 月下旬，负面反馈频率上升，促使我们启动了深入调查，最终发现了三个独立的基础设施 Bug。
Anthropic 在此明确声明："我们绝不会因为需求量、时间段或服务器负载而降低模型质量。用户反馈的问题完全是基础设施 Bug 所致。"
Claude 如何大规模提供服务¶
Claude 运行在多平台、多硬件之上，每种组合都必须保证模型输出的严格一致性。 Claude 通过 Anthropic 第一方 API、Amazon Bedrock 和 Google Cloud Vertex AI 服务数百万用户，部署在 AWS Trainium、NVIDIA GPU 和 Google TPU 等不同硬件平台上。每种硬件需要专门的优化，但必须维持模型输出的严格等价标准。
事件时间线¶
第一个 Bug 于 8 月 5 日引入，影响约 0.8% 的 Sonnet 4 请求。 8 月 25 日和 26 日的部署又引入了两个新 Bug。8 月 29 日的负载均衡变更显著扩大了受影响的流量。
时间线图例：黄色 = 发现问题，红色 = 影响加剧，绿色 = 修复上线
三个重叠的问题¶
1. 上下文窗口路由错误¶
部分 Sonnet 4 请求被错误路由到为 1M token 上下文窗口配置的服务器。
- 引入时间： 8 月 5 日
- 问题本质： 部分 Sonnet 4 请求被误路由至为即将推出的 1M token 上下文窗口配置的服务器
| 平台 | 影响范围 | 时间段 |
|---|---|---|
| Claude API（第一方） | 初始 0.8%，最高峰 16%（8月31日某小时） | 8月5日 - 9月4日 |
| Amazon Bedrock | 最高 0.18% Sonnet 4 请求 | 8月12日起 |
| Vertex AI | < 0.0004% 请求 | 8月27日 - 9月16日 |
关键细节：
- 路由具有"粘性"——一旦被误路由，后续的跟进请求很可能继续发往同一错误服务器
- 约 30% 在此期间发起请求的 Claude Code 用户至少有一条消息被错误路由
修复： 9 月 4 日部署修复后的路由逻辑，9 月 16 日完成对第一方平台和 Vertex AI 的全面推出，9 月 18 日完成 Bedrock 修复。
2. 输出乱码¶
TPU 服务器上的配置错误导致 token 生成时出现异常，偶尔产生完全不相关的字符。
- 引入时间： 8 月 25 日
- 问题本质： Claude API TPU 服务器上的配置错误导致 token 生成出错。一项运行时性能优化"偶尔会给本不该在当前上下文中出现的 token 分配高概率"
具体表现：
- 英文响应中突然出现泰语或中文字符（例如在英文回复中冒出"สวัสดี"）
- 代码中出现明显的语法错误
| 模型 | 影响时间 |
|---|---|
| Opus 4.1 / Opus 4 | 8月25日 - 28日 |
| Sonnet 4 | 8月25日 - 9月2日 |
| 第三方平台 | 未受影响 |
修复： 9 月 2 日定位并回滚。在部署流程中增加了对意外字符输出的检测测试。
3. 近似 top-k XLA:TPU 编译器错误¶
部署的采样代码优化触发了 XLA:TPU 编译器中的一个潜在 Bug，影响 token 选择的正确性。
- 引入时间： 8 月 25 日
- 问题本质： 为改进文本生成中 token 选择而部署的代码无意中触发了 XLA:TPU 编译器[^1]中的一个潜在 Bug
- 确认影响： Haiku 3.5，可能也影响了部分 Sonnet 4 和 Opus 3 的 Claude API 请求
- 第三方平台： 未受影响
修复： Haiku 3.5 于 9 月 4 日回滚，Opus 3 于 9 月 12 日回滚，Sonnet 4 出于谨慎也进行了回滚。Anthropic 与 XLA:TPU 团队合作修复编译器 Bug，并推出了具有增强精度的精确 top-k 实现。
深入剖析 XLA 编译器 Bug¶
Claude 的文本生成过程¶
Claude 生成文本时，会计算每个可能下一个词的概率，然后通过 top-p 采样从分布中选取。 在 TPU 上，模型运行在多个芯片上[^2]，概率计算分布在不同位置，需要进行分布式排序。top-p 采样的阈值通常设为 0.99 或 0.999。
2024 年 12 月的发现¶
2024 年底就曾发现 TPU 实现偶尔会在 temperature=0 时丢弃最高概率 token，当时部署了临时补丁。
根因：混合精度运算¶
模型以 bf16（16位浮点）计算概率，但 TPU 向量处理器原生使用 fp32，编译器会静默提升部分运算的精度，导致不一致。
- 模型以 bf16 计算 next-token 概率
- TPU 向量处理器原生使用 fp32
- XLA 编译器会将部分运算转换为 fp32（由
xla_allow_excess_precision标志控制，默认开启） - 精度不匹配导致：应该对"最高概率 token"达成一致的运算在不同精度下执行，使得最高概率 token 有时完全消失
8 月 26 日的部署¶
新的采样代码移除了 12 月的临时补丁（认为已不再需要），暴露了更深层的编译器 Bug。
一次采样代码重写被部署，旨在修复精度问题并改进 top-p 阈值处的概率处理。但这次重写移除了 2024 年 12 月的临时补丁（当时认为已不再需要），从而暴露了更深层的问题。
更深层的 Bug¶
近似 top-k 操作——一种快速查找最高概率 token 的性能优化——在特定批次大小和模型配置下会返回完全错误的结果。
这个 Bug 存在于近似 top-k 操作中[^3]。12 月的临时补丁恰好无意中掩盖了这个问题。
Bug 的行为"令人沮丧地不一致"——它会随着不相关因素（如前后执行的操作、是否启用了调试工具）的变化而变化。
最终方案¶
Anthropic 发现精确 top-k 的性能开销已大幅降低，遂从近似 top-k 切换到精确 top-k，并将额外运算标准化为 fp32 精度。 "模型质量不可妥协，我们接受了微小的效率影响。"[^4]
为什么这些问题难以检测¶
多重因素叠加，使得常规监控和评估未能及时捕获问题。
| 因素 | 说明 |
|---|---|
| 评估覆盖不足 | 标准评估未能捕捉到用户反馈的质量下降——部分原因是 Claude 往往能从孤立错误中恢复 |
| 隐私保护限制调试 | 内部隐私管控限制了工程师对用户交互的访问权限，保护了隐私但也增加了调查难度 |
| 症状分散 | 每个 Bug 在不同平台、以不同频率产生不同的症状 |
| 评估噪声 | 过度依赖噪声较大的评估结果 |
| 间接关联 | 8 月 29 日的负载均衡变更未能立即与负面反馈激增建立关联 |
Anthropic 的改进措施¶
从评估灵敏度、覆盖范围和调试工具三个方向全面加强。
| 改进方向 | 具体措施 |
|---|---|
| 更灵敏的评估 | 开发了能更可靠地区分正常实现和故障实现的评估方法 |
| 更广泛的质量评估 | 在真实生产系统上持续运行评估，以捕获类似上下文窗口负载均衡错误的问题 |
| 更快的调试工具 | 构建基础设施，在不牺牲用户隐私的前提下，更好地利用社区反馈进行调试 |
Anthropic 鼓励用户继续通过以下渠道反馈问题：
- Claude Code 中的 /bug 命令
- Claude 应用中的"踩"按钮
- 邮件 [email protected]
注释¶
[^1]: XLA:TPU 是将 XLA 高级优化语言（通常使用 JAX 编写）编译为 TPU 机器指令的优化编译器。
[^2]: 模型被分布到数十个或更多芯片上，使排序变成分布式排序。TPU（以及 GPU 和 Trainium）需要向量化操作而非串行算法。
[^3]: 近似 top-k 通过接受对最低概率 token 的潜在误差来获得可观的性能提升——但当 Bug 导致最高概率 token 被丢弃时就出了大问题。
[^4]: 现在正确的 top-k 实现可能导致 top-p 阈值附近的 token 包含出现细微差异；在少数情况下，用户可能需要重新调优 top-p 参数的选择。