三个近期问题的复盘

# 三个近期问题的复盘 来源：https://www.anthropic.com/engineering/a-postmortem-of-three-recent-issues 8月至9月初，三个基础设施漏洞间歇性地降低了 Claude 的回复质量。目前这些问题已修复，我们在此说明事件经过。 8月初，部分用户开始反馈 Claude 的回复质量下降。这些早期报告难以与正常的用户反馈波动区分。到8月底，随着报告频率和持续性的增加，我们展开调查并发现了三个独立的基础设施漏洞。 需要明确说明的是：**我们从未因需求、时段或服务器负载而降低模型质量**。用户报告的问题完全由基础设施漏洞导致。 我们理解用户对 Claude 质量一致性的期望，也始终对基础设施变更不影响模型输出保持极高标准。但在这些事件中，我们未能达到这一标准。以下复盘将解释问题根源、检测和修复耗时较长的原因，以及我们为预防类似事件所做的改进。 我们通常不会分享如此详细的基础设施技术细节，但鉴于这些问题的范围和复杂性，我们认为有必要进行全面说明。 ## 我们如何规模化提供 Claude 服务 我们通过自研 API、Amazon Bedrock 和 Google Cloud Vertex AI 向数百万用户提供服务。Claude 部署在多种硬件平台上，包括 AWS Trainium、NVIDIA GPU 和 Google TPU。这种方式提供了服务全球用户所需的容量和地理分布。 每种硬件平台具有不同特性，需要特定的优化方案。尽管存在这些差异，我们对模型实现有严格的等价性标准。目标是让用户无论由哪个平台处理请求，都能获得相同质量的回复。这种复杂性意味着任何基础设施变更都需要在所有平台和配置上进行仔细验证。 ## 事件时间线 Claude API 事件示意时间线。黄色：问题检测，红色：恶化加剧，绿色：修复部署。 这些漏洞的叠加特性使诊断尤为困难。第一个漏洞于8月5日引入，影响了约 0.8% 的 Sonnet 4 请求。8月25日和26日的部署又引入了两个新漏洞。 虽然初始影响有限，但8月29日的一次负载均衡变更开始增加受影响流量。这导致更多用户遇到问题，而其他用户仍表现正常，造成了混乱且矛盾的报告。 ## 三个重叠问题 以下描述导致质量下降的三个漏洞、发生时间及修复方式： ### 1. 上下文窗口路由错误 8月5日，部分 Sonnet 4 请求被错误路由到为即将推出的 [1M token](https://docs.claude.com/en/docs/build-with-claude/context-windows#1m-token-context-window) [上下文窗口](https://docs.claude.com/en/docs/build-with-claude/context-windows) 配置的服务器。该漏洞最初影响 0.8% 的请求。8月29日，一次常规负载均衡变更无意中增加了路由到 1M 上下文服务器的短上下文请求数量。在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 的 rollout，9月18日完成 AWS Bedrock 的 rollout。 ### 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] 编译器中的潜在漏洞，已确认影响对 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 编译器漏洞的表现形式及其难以诊断的原因。 Claude 生成文本时，会计算每个可能下一个词的概率，然后从此概率分布中随机采样。我们使用"top-p 采样"来避免无意义输出——只考虑累积概率达到阈值（通常为 0.99 或 0.999）的词。在 TPU 上，模型跨多个芯片运行，概率计算分布在不同位置。要对这些概率排序，需要协调芯片间的数据，这很复杂。[2] 2024年12月，我们发现 TPU 实现偶尔会在 [temperature](https://docs.claude.com/en/docs/about-claude/glossary#temperature) 为零时丢弃概率最高的 token。我们部署了临时方案修复该情况。 2024年12月针对 temperature=0 时意外丢弃 token 漏洞的补丁代码片段。 根本原因是混合精度算术。我们的模型使用 [bf16](https://github.com/tensorflow/tensorflow/blob/f41959ccb2d9d4c722fe8fc3351401d53bcf4900/tensorflow/core/framework/bfloat16.h)（16位浮点数）计算下一个 token 的概率。但向量处理器是 [fp32-native](https://dl.acm.org/doi/pdf/10.1145/3360307)，因此 TPU 编译器（XLA）可通过将部分操作转换为 fp32（32位）来优化运行时。该优化 pass 受 `xla_allow_excess_precision` 标志保护，默认开启。 这导致了不匹配：本应就最高概率 token 达成一致的操作在不同精度级别运行。精度不匹配使它们无法就哪个 token 概率最高达成一致。这导致最高概率 token 有时完全消失。 8月26日，我们部署了采样代码的重写，以修复精度问题并改进对达到 top-p 阈值极限概率的处理。但在修复这些问题时，暴露了一个更棘手的问题。 展示8月11日变更中合并的最小化复现器的代码片段，该复现器定位了2024年12月临时方案所规避的"漏洞"的根因；实际上，这是 `xla_allow_excess_precision` 标志的预期行为。 我们的修复移除了12月的临时方案，因为我们认为已解决根因。这导致了 [approximate top-k](https://docs.jax.dev/en/latest/_autosummary/jax.lax.approx_max_k.html) 操作中的更深漏洞——一种快速找到最高概率 token 的性能优化。[3] 该近似有时返回完全错误的结果，但仅针对特定 batch size 和模型配置。12月的临时方案一直在无意中掩盖这个问题。 展示与 XLA:TPU 工程师分享的底层近似 top-k 漏洞复现器的 Slack 消息，这些工程师开发了该算法。代码在 CPU 上运行时返回正确结果。 该漏洞的行为令人沮丧地不一致。它随无关因素变化，如前后运行的操作、调试工具是否启用。相同提示可能一次请求完美运行，下一次却失败。 调查过程中，我们还发现精确 top-k 操作已不再具有以往的高性能惩罚。我们从近似 top-k 切换到精确 top-k，并将部分额外操作标准化为 fp32 精度。[4] 模型质量不可妥协，因此我们接受了轻微的效率影响。 ## 检测为何困难 我们的验证流程通常依赖基准测试，以及安全评估和性能指标。工程团队进行抽查，并先部署到小范围"金丝雀"群体。 这些问题暴露了我们本应更早发现的关键漏洞。我们运行的评估未能捕捉用户报告的质量下降，部分原因是 Claude 通常能从孤立错误中很好恢复。我们的隐私实践也给调查带来了挑战。内部隐私和安全控制限制了工程师访问用户与 Claude 交互的方式和时间，特别是当这些交互未作为反馈报告给我们时。这保护了用户隐私，但阻止了工程师检查识别或复现漏洞所需的问题交互。 每个漏洞在不同平台上以不同速率产生不同症状。这造成了混乱的报告混合，无法指向单一原因。看起来像是随机的、不一致的质量下降。 更根本的是，我们过度依赖噪声较大的评估。尽管我们注意到网上报告的增加，但缺乏将这些与近期变更关联的清晰方式。当8月29日负面报告激增时，我们未能立即将其与一次常规的负载均衡变更联系起来。 ## 改进措施 随着我们持续改进基础设施，也在改进评估和预防上述漏洞的方式，覆盖所有提供 Claude 服务的平台。具体改进如下： - **更敏感的评估：** 为帮助发现任何问题的根因，我们开发了能更可靠区分正常和异常实现的评估。我们将持续改进这些评估，更密切地监控模型质量。 - **更多场景的质量评估：** 尽管我们定期在系统上运行评估，但将在真正的生产系统上持续运行，以捕捉上下文窗口负载均衡错误等问题。 - **更快的调试工具：** 我们将开发基础设施和工具，在保护用户隐私的前提下更好地调试社区来源的反馈。此外，此处开发的一些定制工具将用于缩短未来类似事件的修复时间。 评估和监控很重要，但这些事件表明，我们还需要来自用户的持续反馈，当 Claude 的回复未达 usual 标准时。观察到的具体变化、意外行为示例、不同用例中的模式，都帮助我们隔离了问题。 用户继续直接向我们发送反馈尤为重要。您可以在 Claude Code 中使用 `/bug` 命令，或在 Claude 应用中使用"踩"按钮。开发者和研究者常创造出评估模型质量的新颖有趣方法，补充我们的内部测试。如果您愿意分享，请联系 [[email protected]](mailto:[email protected])。 我们始终感谢社区的贡献。 #### 致谢 由 Sam McAllister 撰写，感谢 Stuart Ritchie、Jonathan Gray、Kashyap Murali、Brennan Saeta、Oliver Rausch、Alex Palcuie 及许多其他人的贡献。 [1] XLA:TPU 是将 [XLA](https://openxla.org/xla/architecture)（Accelerated Linear Algebra）高级优化语言——通常使用 [JAX](https://docs.jax.dev/en/latest) 编写——编译为 TPU 机器指令的优化编译器。 [2] 我们的模型对单芯片而言过大，需分区到数十个或更多芯片，使排序操作成为分布式排序。TPU（与 GPU 和 Trainium 一样）具有与 CPU 不同的性能特性，需要使用向量化操作而非串行算法的不同实现技术。 [3] 我们使用此近似操作是因为它带来了显著的性能提升。该近似通过接受最低概率 token 可能存在的不准确来工作，这不应影响质量——除非漏洞导致它丢弃了最高概率 token。 [4] 注意，现在正确的 top-k 实现可能导致接近 top-p 阈值的 token 包含情况有轻微差异，极少数情况下用户可能需要重新调整其 top-p 选择。