获取开发者新闻通讯
产品更新、操作指南、社区聚焦等更多内容。每月发送至您的收件箱。
在八月至九月初期间，三个基础设施缺陷间歇性地降低了 Claude 的响应质量。我们现已解决这些问题，并希望解释发生了什么。
八月初，许多用户开始报告 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 日的一次负载均衡变更开始增加受影响的流量。这导致更多用户遇到问题，而其他用户则继续看到正常表现，从而产生了令人困惑且相互矛盾的报告。
下面我们描述导致质量下降的三个缺陷、它们发生的时间以及我们如何解决它们：
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%。在 Google Cloud 的 Vertex AI 上，8 月 27 日至 9 月 16 日期间，错误路由影响的请求不到 0.0004%。
然而，部分用户受到的影响更为严重，因为我们的路由是“粘性”的。这意味着一旦某个请求由错误的服务器处理，后续的跟进请求很可能由同一台错误的服务器处理。
解决方案： 我们修复了路由逻辑，确保短上下文和长上下文请求被定向到正确的服务器池。我们于 9 月 4 日部署了该修复。向我们的第一方平台和 Google Cloud 的 Vertex AI 的推广于 9 月 16 日完成，向 AWS Bedrock 的推广于 9 月 18 日完成。
8 月 25 日，我们在 Claude API 的 TPU 服务器上部署了一个错误配置，导致令牌生成过程中出现错误。一个由运行时性能优化引起的问题偶尔会给那些在给定上下文中很少应该产生的令牌分配高概率，例如针对英文提示产生泰文或中文字符，或在代码中产生明显的语法错误。例如，一小部分用英语提问的用户可能会在响应中间看到“สวัสดี”。
此损坏影响了 8 月 25 日至 28 日对 Opus 4.1 和 Opus 4 的请求，以及 8 月 25 日至 9 月 2 日对 Sonnet 4 的请求。第三方平台未受此问题影响。
解决方案： 我们识别了该问题，并于 9 月 2 日回滚了更改。我们已在部署流程中添加了针对意外字符输出的检测测试。
8 月 25 日，我们部署了代码以改进 Claude 在文本生成期间选择令牌的方式。此更改无意中触发了 XLA:TPU[1] 编译器中的一个潜在错误，该错误已被确认会影响对 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 编译器错误的表现方式以及为何它被证明特别难以诊断。
当 Claude 生成文本时，它会计算每个可能的下一个词的概率，然后从这个概率分布中随机选择一个样本。我们使用“top-p 采样”来避免无意义的输出——只考虑累积概率达到阈值（通常为 0.99 或 0.999）的词。在 TPU 上，我们的模型跨多个芯片运行，概率计算发生在不同的位置。为了对这些概率进行排序，我们需要在芯片之间协调数据，这很复杂。[2]
2024 年 12 月，我们发现 TPU 实现在温度为零时，偶尔会丢弃最可能的 token。我们部署了一个临时解决方案来修复这种情况。
根本原因涉及混合精度算术。我们的模型以 bf16（16 位浮点数）计算下一个 token 的概率。然而，向量处理器是 fp32 原生的，因此 TPU 编译器（XLA）可以通过将某些操作转换为 fp32（32 位）来优化运行时。这个优化过程由 xla_allow_excess_precision 标志控制，该标志默认为 true。
这导致了一个不匹配：本应在最高概率 token 上达成一致的操作却以不同的精度级别运行。精度不匹配意味着它们无法就哪个 token 具有最高概率达成一致。这导致最高概率的 token 有时会完全从考虑中消失。
8 月 26 日，我们部署了采样代码的重写，以修复精度问题并改进我们在达到 top-p 阈值的极限时处理概率的方式。但在修复这些问题的过程中，我们暴露了一个更棘手的问题。
xla_allow_excess_precision
标志。我们的修复移除了 12 月的临时解决方案，因为我们相信已经解决了根本原因。这导致了近似 top-k 操作中更深层的错误——这是一种快速找到最高概率 token 的性能优化。[3] 这种近似有时会返回完全错误的结果，但仅针对某些批次大小和模型配置。12 月的临时解决方案无意中掩盖了这个问题。
该错误的行为令人沮丧地不一致。它会根据无关因素而变化，例如之前或之后运行的操作，以及是否启用了调试工具。相同的提示可能在一个请求中完美工作，而在下一个请求中失败。
在调查过程中，我们还发现精确 top-k 操作不再具有曾经的高昂性能损失。我们从近似 top-k 切换到精确 top-k，并将一些额外操作标准化为 fp32 精度。[4] 模型质量是不可妥协的，因此我们接受了轻微的效率影响。
我们的验证过程通常依赖于基准测试以及安全评估和性能指标。工程团队进行抽查，并首先部署到小型“金丝雀”组。
这些问题暴露了我们本应更早发现的关键差距。我们运行的评估根本没有捕捉到用户报告的退化，部分原因是 Claude 通常能从孤立错误中很好地恢复。我们自己的隐私实践也在调查报告中造成了挑战。我们的内部隐私和安全控制限制了工程师访问用户与 Claude 交互的方式和时间，特别是当这些交互未作为反馈报告给我们时。这保护了用户隐私，但阻止了工程师检查有问题的交互，以识别或重现错误。
每个错误在不同平台上以不同速率产生不同症状。这造成了令人困惑的报告组合，没有指向任何单一原因。它看起来像是随机、不一致的退化。
更根本地说，我们过于依赖有噪声的评估。尽管我们意识到网上报告有所增加，但我们缺乏一种清晰的方式将这些报告与我们近期的每一项变更联系起来。当8月29日负面报告激增时，我们并未立即将其与一项原本标准的负载均衡变更联系起来。
在我们持续改进基础设施的同时，我们也在改进评估和预防上述这类错误的方式，覆盖我们为Claude提供服务的所有平台。以下是我们正在做出的改变：
评估和监控很重要。但这些事件表明，当Claude的响应未达到通常标准时，我们还需要来自用户的持续信号。关于观察到的具体变更的报告、遇到的意外行为的示例，以及不同用例中的模式，都帮助我们定位了问题。
用户继续直接向我们发送反馈仍然特别有帮助。你可以在Claude Code中使用/bug
命令，或者在Claude应用中使用“拇指向下”按钮来做到这一点。开发者和研究人员经常创造出新的、有趣的方式来评估模型质量，这些方式补充了我们的内部测试。如果你想分享你的方法，请联系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选择中受益。
产品更新、操作指南、社区聚焦等。每月发送到您的收件箱。