Anthropic 复盘三起基础设施 bug 导致的 Claude 质量下降

在8月至9月初期间，三个基础设施缺陷间歇性地降低了Claude的响应质量。我们现已解决这些问题，并希望解释发生了什么。

8月初，一些用户开始反馈Claude的响应质量下降。这些最初的反馈很难与用户反馈中的正常波动区分开来。到8月下旬，这些反馈的频率和持续性不断增加，促使我们展开调查，最终发现了三个独立的基础设施缺陷。

直白地说：我们绝不会因需求、时段或服务器负载而降低模型质量。用户反馈的问题完全是由基础设施缺陷造成的。

我们深知用户期望Claude保持稳定的质量，我们也对确保基础设施变更不影响模型输出维持着极高的标准。在最近的这些事件中，我们未能达到这一标准。以下的事后分析解释了问题出在哪里、为何检测和解决耗时超出我们的预期，以及我们正在做出哪些改变以防止未来发生类似事件。

我们通常不会分享如此详细的基础设施技术细节，但这些问题的范围和复杂性使得更全面的解释是必要的。

我们如何大规模提供Claude服务

我们通过第一方API、Amazon Bedrock和Google Cloud的Vertex AI为数百万用户提供Claude服务。我们将Claude部署在多种硬件平台上，即AWS Trainium、NVIDIA GPU和Google TPU。这种方式提供了服务全球用户所需的容量和地理分布。

每个硬件平台都有不同的特性，需要特定的优化。尽管存在这些差异，我们对模型实现有着严格的等效性标准。我们的目标是，无论用户的请求由哪个平台处理，都应获得相同质量的响应。这种复杂性意味着任何基础设施变更都需要在所有平台和配置上进行仔细验证。

事件时间线

这些缺陷相互重叠的特性使得诊断尤为困难。第一个缺陷于8月5日引入，影响了约0.8%发往Sonnet 4的请求。另外两个缺陷源于8月25日和26日的部署。

尽管最初影响有限，但8月29日的一次负载均衡变更开始增加受影响的流量。这导致更多用户遇到问题，而其他用户则继续看到正常表现，从而产生了令人困惑且相互矛盾的反馈。

三个相互重叠的问题

下面我们描述导致质量下降的三个缺陷、它们发生的时间以及我们如何解决它们：

1. 上下文窗口路由错误

8月5日，一些Sonnet 4请求被错误路由到为即将推出的100万token上下文窗口配置的服务器。该缺陷最初影响0.8%的请求。8月29日，一次例行的负载均衡变更无意中增加了路由到100万上下文服务器的短上下文请求数量。在8月31日受影响最严重的时段，16%的Sonnet 4请求受到影响。

在此期间发出请求的 Claude Code 用户中，约有 30% 至少有一条消息被路由到了错误的服务器类型，导致响应质量下降。在 Amazon Bedrock 上，错误路由的流量在 8 月 12 日达到峰值，占所有 Sonnet 4 请求的 0.18%。在 8 月 27 日至 9 月 16 日期间，Google Cloud 的 Vertex AI 上受错误路由影响的请求不到 0.0004%。

然而，部分用户受到的影响更为严重，因为我们的路由是“粘性”的。这意味着一旦某个请求由错误的服务器处理，后续的追问也很可能由同一台错误的服务器处理。

解决方案：我们修复了路由逻辑，确保短上下文和长上下文请求被定向到正确的服务器池。我们于 9 月 4 日部署了该修复。向我们的第一方平台和 Google Cloud 的 Vertex AI 的推广于 9 月 16 日完成，向 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^[1] 编译器中的一个潜在 bug，现已确认该 bug 会影响对 Claude Haiku 3.5 的请求。

我们还认为这可能影响了 Claude API 上的一部分 Sonnet 4 和 Opus 3。第三方平台未受此问题影响。

解决方案：我们最初观察到影响 Haiku 3.5 的该 bug，并于 9 月 4 日将其回滚。后来我们注意到用户报告的 Opus 3 问题与该 bug 相符，并于 9 月 12 日将其回滚。经过大量调查，我们无法在 Sonnet 4 上复现该 bug，但出于谨慎考虑，我们决定也将其回滚。

同时，我们 (a) 一直在与 XLA:TPU 团队合作修复该编译器 bug，并且 (b) 推出了使用增强精度的精确 top-k 的修复。详情请参阅下方的深入分析。

深入了解 XLA 编译器 bug

为说明这些问题的复杂性，以下是 XLA 编译器 bug 的表现方式，以及为何它被证明特别难以诊断。

当 Claude 生成文本时，它会为每个可能的下一个词计算概率，然后从这个概率分布中随机抽取一个样本。我们使用“top-p 采样”来避免无意义的输出——只考虑累积概率达到阈值（通常为 0.99 或 0.999）的词。在 TPU 上，我们的模型跨多个芯片运行，概率计算发生在不同位置。为了对这些概率进行排序，我们需要在芯片之间协调数据，这很复杂。^[2]

2024 年 12 月，我们发现我们的 TPU 实现偶尔会在 temperature 为零时丢弃概率最高的 token。我们部署了一个临时解决方案来修复这种情况。

根本原因涉及混合精度算术。我们的模型以 bf16（16 位浮点）计算下一个 token 的概率。然而，向量处理器是 fp32 原生的，因此 TPU 编译器（XLA）可以通过将某些操作转换为 fp32（32 位）来优化运行时。这个优化过程由 xla_allow_excess_precision 标志控制，该标志默认为 true。

这导致了一个不匹配：本应在最高概率 token 上达成一致的操作却以不同的精度级别运行。精度不匹配意味着它们无法就哪个 token 具有最高概率达成一致。这导致最高概率的 token 有时会完全从考虑中消失。

8 月 26 日，我们部署了采样代码的重写，以修复精度问题并改进我们在达到 top-p 阈值的极限情况下处理概率的方式。但在修复这些问题的过程中，我们暴露了一个更棘手的问题。

我们的修复移除了 12 月的临时解决方案，因为我们相信已经解决了根本原因。这导致了 近似 top-k 操作中一个更深层的 bug——这是一种快速找到最高概率 token 的性能优化。^[3] 这种近似有时会返回完全错误的结果，但仅针对某些批次大小和模型配置。12 月的临时解决方案无意中掩盖了这个问题。

这个 bug 的行为令人沮丧地不一致。它会根据无关因素而变化，例如之前或之后运行了哪些操作，以及是否启用了调试工具。同一个提示词可能在一次请求中完美运行，而在下一次请求中失败。

在调查过程中，我们还发现精确 top-k 操作不再具有曾经的高昂性能代价。我们从近似 top-k 切换到了精确 top-k，并将一些额外操作标准化为 fp32 精度。^[4] 模型质量不容妥协，因此我们接受了轻微的效率影响。

为什么检测很困难

我们的验证流程通常依赖于基准测试以及安全评估和性能指标。工程团队会进行抽查，并首先部署到小型的“金丝雀”组。

这些问题暴露了我们本应更早发现的关键缺口。我们运行的评估根本没有捕捉到用户所报告的降级情况，部分原因是 Claude 往往能从孤立的错误中很好地恢复。我们自身的隐私实践也为调查这些报告带来了挑战。我们的内部隐私和安全控制限制了工程师访问用户与 Claude 交互的方式和时间，尤其是当这些交互未作为反馈报告给我们时。这保护了用户隐私，但也阻止了工程师检查那些有问题的交互，而这些交互正是识别或复现 bug 所必需的。

每个 bug 在不同平台上以不同频率产生不同的症状。这造成了令人困惑的报告混杂，无法指向任何单一原因。看起来像是随机、不一致的降级。

更根本地说，我们过于依赖有噪声的评估。尽管我们意识到网上报告有所增加，但我们缺乏一种清晰的方式将这些报告与我们近期的每一项变更联系起来。当 8 月 29 日负面报告激增时，我们没有立即将其与一项原本常规的负载均衡变更联系起来。

我们正在做出的改变

在我们继续改进基础设施的同时，我们也在改进评估和预防上述这类 bug 的方式，覆盖我们为 Claude 提供服务的所有平台。以下是我们正在做出的改变：

• 更灵敏的评估：为了帮助发现任何给定问题的根本原因，我们开发了能够更可靠地区分正常实现和损坏实现的评估。我们将持续改进这些评估，以更密切地关注模型质量。
• 在更多地方进行质量评估：尽管我们在系统上运行常规评估，但我们将持续在真实生产系统上运行这些评估，以捕捉诸如上下文窗口负载均衡错误之类的问题。
• 更快的调试工具：我们将开发基础设施和工具，以便在不牺牲用户隐私的情况下更好地调试来自社区的反馈。此外，这里开发的一些定制工具将用于减少未来类似事件（如果发生的话）的修复时间。

评估和监控很重要。但这些事件表明，当 Claude 的响应达不到通常标准时，我们还需要来自用户的持续信号。关于所观察到的具体变化的报告、所遇到意外行为的示例，以及不同用例中的模式，都帮助我们定位了问题。

用户继续直接向我们发送反馈仍然特别有帮助。你可以在 Claude Code 中使用 /bug 命令，或者在 Claude 应用中使用“踩”按钮来做到这一点。开发者和研究人员经常创造出新的、有趣的方式来评估模型质量，以补充我们的内部测试。如果你想分享你的方式，请联系 [email protected]。

我们仍然感谢社区做出的这些贡献。

致谢

由 Sam McAllister 撰写，感谢 Stuart Ritchie、Jonathan Gray、Kashyap Murali、Brennan Saeta、Oliver Rausch、Alex Palcuie 以及许多其他人。

^[1] XLA:TPU 是将 XLA 高级优化语言——通常使用 JAX 编写——转换为 TPU 机器指令的优化编译器。

^[2] 我们的模型太大，单块芯片放不下，需要划分到数十块或更多芯片上，这使得我们的排序操作成为分布式排序。TPU（就像 GPU 和 Trainium 一样）的性能特征也与 CPU 不同，需要使用向量化操作而非串行算法来实现不同的技术。

^[3] 我们一直使用这种近似操作，因为它带来了显著的性能提升。该近似方法通过接受最低概率 token 中的潜在不准确性来工作，这不应影响质量——除非当这个 bug 导致它反而丢弃了最高概率的 token 时。

^[4] 请注意，现在正确的 top-k 实现可能会导致接近 top-p 阈值的 token 的纳入出现细微差异，在极少数情况下，用户可能会从重新调整其 top-p 选择中受益。