基础设施故障导致Claude响应质量下降的说明

8月至9月初，三个基础设施故障间歇性地降低了Claude的响应质量。目前这些问题已解决，我们在此说明具体情况。

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

明确说明：我们从未因需求、时段或服务器负载而降低模型质量。用户报告的问题完全由基础设施故障导致。

我们深知用户期望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请求受到影响。

在此期间，约30%的Claude Code用户至少有一条消息被路由到错误服务器类型，导致响应质量下降。在Amazon Bedrock上，错误路由流量在8月12日后达到Sonnet 4请求的0.18%。在Google Cloud的Vertex AI上，8月27日至9月16日期间，错误路由影响不到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：XLA编译器bug

8月25日，我们部署了改进Claude文本生成时token选择方式的代码。此变更意外触发了XLA:TPU[1]编译器中的潜在bug，已确认影响Claude Haiku 3.5的请求。

我们相信此问题也可能影响Claude API上部分Sonnet 4和Opus 3的请求。第三方平台未受影响。

解决方案： 我们首先观察到影响Haiku 3.5的bug，并于9月4日回滚。随后注意到与Opus 3问题相符的用户报告，于9月12日回滚。经过广泛调查，我们无法在Sonnet 4上复现此bug，但出于谨慎考虑也进行了回滚。

同时，我们已(a)与XLA:TPU团队合作修复编译器bug，(b)部署了使用增强精度的精确top-k修复方案。详见下文深度分析。

技术深度分析

为说明问题的复杂性，以下解释XLA编译器bug的表现形式及诊断难度。

当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标志控制，默认开启。

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

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

我们的修复移除了2024年12月的临时方案，因为我们相信已解决根本原因。这导致近似top-k操作中出现更深层的bug——这是一种快速找到最高概率token的性能优化。[3]此近似算法有时返回完全错误的结果，但仅针对特定batch size和模型配置。之前的临时方案无意中掩盖了此问题。

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

调查过程中，我们还发现精确top-k操作不再有曾经的高性能代价。我们将近似top-k切换为精确top-k，并将部分额外操作标准化为fp32精度。[4]模型质量不可妥协，因此我们接受了轻微的效率影响。

检测与响应中的不足

我们的验证流程通常依赖benchmark（基准测试）以及安全评估和性能指标。工程团队进行抽查并先部署到小型"canary"组。

这些问题暴露了我们本应更早识别的关键差距。我们运行的评估未能捕捉用户报告的质量下降，部分原因是Claude通常能从孤立错误中良好恢复。我们的隐私实践也给调查报告带来挑战。内部隐私和安全控制限制了工程师访问用户与Claude交互的方式和时机，特别是当这些交互未作为反馈报告时。这保护了用户隐私，但阻止了工程师检查识别或复现bug所需的问题交互。

每个bug在不同平台上以不同速率产生不同症状。这产生了令人困惑的混合报告，无法指向单一原因。看起来像是随机、不一致的质量下降。

更根本的是，我们过度依赖有噪声的评估。虽然注意到在线报告增加，但我们缺乏清晰方式将这些报告与近期变更联系起来。当8月29日负面报告激增时，我们未能立即将其与常规负载均衡变更联系起来。

改进措施

随着我们持续改进基础设施，我们也在改进在所有Claude服务平台上评估和预防此类bug的方式。以下是正在进行的变更：

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

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

我们始终感谢社区的这些贡献。

作者：Sam McAllister，感谢Stuart Ritchie、Jonathan Gray、Kashyap Murali、Brennan Saeta、Oliver Rausch、Alex Palcuie及许多其他人的贡献。