Anthropic 复盘 Claude 三个基础设施 bug 的根因与修复过程

在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¹ 编译器中的一个潜在缺陷，现已确认该缺陷会影响对 Claude Haiku 3.5 的请求。

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

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

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

深入了解 XLA 编译器缺陷

为说明这些问题的复杂性，以下介绍 XLA 编译器缺陷是如何显现的，以及为何它特别难以诊断。

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

2024 年 12 月，我们发现 TPU 实现偶尔会在温度为零时丢弃最可能的 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 的性能优化。³ 这种近似有时会返回完全错误的结果，但仅针对某些批次大小和模型配置。12 月的临时解决方案一直在无意中掩盖这个问题。

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

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

为什么检测很困难

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

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

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

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

我们正在做出的改变

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

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

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

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

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