Anthropic 复盘 Claude 回复质量降低的三个Infra问题

Anthropic 复盘 Claude 回复质量降低的三个Infra问题图1

本文由 Intern-S1、Qwen3 等 AI 生成，由机智流编辑部校对
原文链接：https://www.anthropic.com/engineering/a-postmortem-of-three-recent-issues

前言

在八月至九月初，Anthropic 发现三个基础设施错误间歇性地降低了 Claude 的响应质量。该公司现已解决这些问题，并希望解释事件经过。

八月初，一些用户开始报告 Claude 的响应质量下降。这些初始报告难以与用户反馈的正常波动区分开来。到八月底，这些报告的频率和持续性增加，促使 Anthropic 展开调查，最终发现了三个独立的基础设施错误。

Anthropic 明确声明：该公司从未因需求、时间段或服务器负载等原因降低模型质量。用户报告的问题完全由基础设施错误引起。

Anthropic 认识到，用户期望 Claude 提供一致的质量，该公司对确保基础设施变更不影响模型输出的标准极高。在这些近期事件中，该公司未能达到这一标准。以下回顾解释了问题原因、为何检测和解决耗时较长，以及该公司将采取哪些措施防止类似未来事件。

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

Anthropic 如何大规模服务 Claude

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

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

事件时间线

这些错误的重叠性质使诊断特别具有挑战性。第一个错误于 8 月 5 日引入，影响了约 0.8% 的 Sonnet 4 请求。另外两个错误源于 8 月 25 日和 26 日的部署。

尽管初始影响有限，但 8 月 29 日的负载均衡变更开始增加受影响的流量。这导致许多用户体验到问题，而其他用户继续看到正常性能，造成了混乱且矛盾的报告。

三个重叠问题

以下描述了导致质量下降的三个错误、它们发生的时间以及 Anthropic 如何解决它们：

上下文窗口路由错误

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

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

然而，一些用户受到更严重的影响，因为 Anthropic 的路由是“粘性”的。这意味着一旦请求由不正确的服务器处理，后续跟进请求很可能由同一不正确的服务器处理。

解决方法：Anthropic 修复了路由逻辑，以确保短上下文和长上下文请求被定向到正确的服务器池。该公司于 9 月 4 日部署了修复。到 9 月 16 日，对自有平台和 Google Cloud 的 Vertex AI 的推广完成，到 9 月 18 日，对 AWS Bedrock 的推广完成。

配置导致错误的输出

8 月 25 日，Anthropic 在 Claude API 的 TPU 服务器上部署了一个错误配置，导致 token 生成期间出现错误。由运行时性能优化引起的问题偶尔为不应在给定上下文中产生的 token 分配高概率，例如在英语提示中产生泰语或中文字符，或在代码中产生明显的语法错误。例如，一小部分用户在英语问题中可能在响应中间看到“สวัสดี”。

此损坏影响了 8 月 25 日至 28 日的 Opus 4.1 和 Opus 4 请求，以及 8 月 25 日至 9 月 2 日的 Sonnet 4 请求。第三方平台未受此问题影响。

解决方法：Anthropic 识别了问题并于 9 月 2 日回滚了变更。该公司在部署流程中添加了检测意外字符输出的测试。

近似实现 top-k XLA:TPU 误编译

8 月 25 日，Anthropic 部署了改进 Claude 在文本生成期间选择 token 的代码。此变更无意中触发了 XLA:TPU 编译器的潜在错误，已确认影响了 Claude Haiku 3.5 的请求。

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

解决方法：Anthropic 首先观察到该错误影响 Haiku 3.5，并于 9 月 4 日回滚。该公司后来注意到与此错误一致的 Opus 3 用户报告问题，并于 9 月 12 日回滚。经过广泛调查，该公司无法在 Sonnet 4 上重现此错误，但出于谨慎考虑，也对其进行了回滚。

同时，该公司（a）与 XLA:TPU 团队合作修复编译器错误，以及（b）推广了使用精确 top-k 与增强精度的修复。详情见下面的深入分析。

对 XLA 编译器错误的更深入审视

为了说明这些问题的复杂性，以下是 XLA 编译器错误如何显现以及为何诊断特别具有挑战性。

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

在 2024 年 12 月，Anthropic 发现其 TPU 实现会在温度为零时偶尔丢弃最可能的 token。该公司部署了一个变通方法来修复此情况。

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

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

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

Anthropic 的修复移除了 12 月的变通方法，因为该公司相信已解决了根本原因。这导致了近似 top-k 操作中的更深层错误——一种性能优化，用于快速找到最高概率 token。此近似有时返回完全错误的结果，但仅针对某些批次大小和模型配置。12 月的变通方法无意中掩盖了这个问题。

该错误的行为令人沮丧地不一致。它取决于无关因素，例如在其前后运行的操作，以及是否启用调试工具。同一个提示可能在一次请求中完美工作，而在下一次失败。

在调查过程中，Anthropic 还发现精确 top-k 操作不再具有曾经的禁止性性能罚款。该公司从近似切换到精确 top-k，并标准化了一些额外的 fp32 精度操作。模型质量不可谈判，因此该公司接受了轻微的效率影响。

为何检测困难

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

这些问题暴露了该公司应更早识别的关键差距。该公司运行的评估 просто没有捕捉到用户报告的质量下降，部分原因是 Claude 通常从孤立错误中恢复良好。该公司自身的隐私实践也造成了调查报告的挑战。该公司的内部隐私和安全控制限制了工程师如何以及何时访问用户与 Claude 的交互，特别是当这些交互未作为反馈报告给该公司时。这保护了用户隐私，但阻止工程师检查识别或重现错误所需的问题交互。

每个错误在不同平台上产生了不同的症状，并以不同速率发生。这创建了混乱的报告混合，没有指向任何单一原因。它看起来像是随机、不一致的质量下降。

更根本的是，该公司过于依赖嘈杂的评估。尽管该公司意识到在线报告增加，但缺乏将这些与每个近期变更连接的清晰方式。当 8 月 29 日负面报告激增时，该公司没有立即将其与否则标准的负载均衡变更联系起来。