A postmortem of three recent issues

8月至9月初期间，三个基础设施漏洞间歇性地降低了 Claude 的响应质量。我们目前已解决这些问题，并希望解释事情的经过。

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

坦率地说：我们绝不会因需求、时段或服务器负载而降低模型质量。用户报告的问题完全是基础设施漏洞造成的。

我们理解用户期望 Claude 保持一致的质量，并且我们对确保基础设施变更不影响模型输出坚持极高的标准。在最近的这些事故中，我们未能达到这一标准。以下复盘说明了出了什么问题，为什么检测和解决所花的时间比我们期望的更长，以及我们正在做出哪些改变以防止类似事件再次发生。

我们通常不会分享关于基础设施的这一层级的技术细节，但考虑到这些问题的范围和复杂性，我们认为有必要提供更全面的解释。

我们如何大规模服务 Claude

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

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

事件时间线

Illustrative timeline of events on the Claude API. Yellow: issue detected, Red: degradation worsened, Green: fix deployed. — **Claude API** 上事件时间线的示意图。黄色：检测到问题，红色：性能退化加剧，绿色：已部署修复。

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

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

三个相互重叠的问题

下面我们描述导致性能退化的三个漏洞、它们发生的时间以及我们如何解决它们：

1. 上下文窗口路由错误

8月5日，一些 Sonnet 4 请求被错误路由到为即将推出的 1M token 上下文窗口配置的服务器。此漏洞最初影响了 0.8% 的请求。8月29日，一次例行的负载均衡变更无意中增加了被路由到 1M 上下文服务器的短上下文请求数量。在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%。

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

解决方案：我们修复了路由逻辑，以确保短上下文和长上下文请求被导向正确的服务器池。我们于 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 请求。第三方平台未受此问题影响。

解决方案：我们最早发现该 bug 影响 Haiku 3.5，并于9月4日将其回滚。随后我们注意到用户报告的 Opus 3 问题与此 bug 相符，并于9月12日将其回滚。经过广泛调查，我们未能在 Sonnet 4 上重现该 bug，但出于谨慎考虑，仍决定将其一并回滚。

与此同时，我们已在与 XLA:TPU 团队合作修复该编译器 bug，并推出了一项修复方案，改用具有增强精度的精确 top-k。详情请参阅下方的深入分析。

深入了解 XLA 编译器 bug

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

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

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

Code snippet of a December 2024 patch to work around the unexpected dropped token bug when temperature = 0. — 代码片段：2024 年 12 月的补丁，用于绕过 temperature = 0 时意外丢弃 token 的 bug。

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

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

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

Code snippet showing minimized reproducer merged as part of the August 11 change that root-caused the “bug” being worked around in December 2024; in reality, it’s expected behavior of the xla_allow_excess_precision flag. — 代码片段：展示了一个最小化复现用例，作为 8 月 11 日更改的一部分合并，该更改找出了 2024 年 12 月所绕过的那个“bug”的根本原因。实际上，这是 `xla_allow_excess_precision` 标志的预期行为。

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

Slack message showing reproducer of the underlying approximate top-k bug shared with the XLA:TPU engineers who developed the algorithm. The code returns correct results when run on CPUs. — 与开发该算法的 XLA:TPU 工程师共享的底层近似 top-k bug 复现代码。该代码在 CPU 上运行时能返回正确结果。

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

在调查过程中，我们还发现精确 top-k 操作不再有过去那种令人望而却步的性能损耗。我们从近似 top-k 切换为精确 top-k，并将一些其他操作统一采用 fp32 精度。^[4] 模型质量不容妥协，因此我们接受了这点轻微的效率影响。

为什么难以检测

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

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

每个错误在不同平台上以不同的频率产生不同的症状。这造成了一种令人困惑的、互不关联的报告混杂，无法指向任何单一原因。看起来就像是随机且不一致的性能退化。

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

我们正在做出的改变

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

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

评估和监控固然重要。但这些事件表明，当 Claude 的回复未达到通常的水准时，我们还需要来自用户的持续反馈信号。对所观察到的具体变化的报告、所遇到的意外行为的实例，以及跨不同用例的模式，都帮助我们定位了这些问题。

用户继续直接向我们发送反馈仍然尤其有帮助。您可以在 Claude Code 中使用 /bug 命令，或在 Claude 应用中使用“踩”（thumbs down）按钮来提交反馈。开发者和研究人员常常会创造出评估模型质量的新颖有趣的方式，与我们的内部测试形成互补。如果您愿意分享您的方式，请联系 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（就像 GPU 和 Trainium 一样）与 CPU 的性能特性也不同，因此需要采用不同的实现技术，使用向量化操作而非串行算法。

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

^[4] 请注意，现已修正的 top-k 实现可能会导致在是否纳入接近 top-p 阈值的 token 上出现细微差异，在极少数情况下，用户可能需要重新调整 top-p 的取值。