8 月至 9 月初期间，三个基础设施漏洞间歇性地降低了 Claude 的回复质量。我们现已解决这些问题，并希望说明发生了什么。

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

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

我们认识到，用户期待 Claude 具备稳定一致的质量，而我们一直以极高标准确保基础设施变更不会影响模型输出。在最近这些事件中，我们没有达到这一标准。以下事后分析将说明哪里出了问题，为什么检测和解决所花的时间比我们希望的更长，以及我们将做出哪些改变以防止未来发生类似事件。

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

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

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

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

事件时间线

这些 bug 的相互重叠使诊断变得格外具有挑战性。第一个 bug 于 8 月 5 日引入，影响了向 Sonnet 4 发出的约 0.8% 的请求。另有两个 bug 源于 8 月 25 日和 26 日的部署。

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

三个相互重叠的问题

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

1. 上下文窗口路由错误

8 月 5 日，部分 Sonnet 4 请求被错误路由到为即将推出的 1M token 上下文窗口配置的服务器。该 bug 最初影响了 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% 的请求。

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

解决方案：我们修复了路由逻辑，以确保短上下文和长上下文请求被定向到正确的服务器池。我们已于 9 月 4 日部署该修复。到 9 月 16 日，该修复已完成在我们第一方平台和 Google Cloud 的 Vertex AI 上的推出；到 9 月 18 日，已完成在 AWS Bedrock 上的推出。

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，并于 9 月 4 日将其回滚。后来，我们注意到用户报告了与此错误相符的 Opus 3 问题，并于 9 月 12 日将其回滚。经过广泛调查，我们无法在 Sonnet 4 上复现此错误，但出于高度谨慎，也决定将其回滚。

与此同时，我们（a）一直在与 XLA:TPU 团队合作修复该编译器错误，并且（b）已推出一项修复，使用具备增强精度的精确 top-k。有关详细信息，请参见下方的深度解析。

深入了解 XLA 编译器错误

为了说明这些问题的复杂性，下面介绍 XLA 编译器 bug 是如何表现出来的，以及为什么它被证明尤其难以诊断。

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

2024 年 12 月，我们发现，当 temperature 为零时，我们的 TPU 实现偶尔会丢弃最可能的 token。我们部署了一个 workaround 来修复这种情况。

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

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

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

我们的修复移除了 12 月的变通方案，因为我们认为已经解决了根本原因。这导致近似 top-k 操作中出现了一个更深层的错误——这是一种用于快速找出最高概率 token 的性能优化。[3] 这种近似有时会返回完全错误的结果，但只在特定批量大小和模型配置下发生。12 月的变通方案无意中掩盖了这个问题。

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

在调查过程中，我们还发现，精确 top-k 操作不再像过去那样带来令人难以承受的性能损耗。我们从近似 top-k 切换到精确 top-k，并将一些额外操作标准化为 fp32 精度。[4] 模型质量不可妥协，因此我们接受了轻微的效率影响。

为什么检测很困难

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

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

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

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

我们正在做出的改变

随着我们持续改进基础设施，我们也在改进评估和预防上述这类 bug 的方式，覆盖我们提供 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 中可能存在的不准确性来工作，而这些不应影响质量——除非该错误导致它反而丢弃了最高概率的 token。

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