三个Bug让Claude变差，监控却全程没发现

2025年8月，Claude用户开始普遍抱怨模型变差了——回答跑偏、代码里出现明显语法错误，甚至英文回复中混入泰文字符。Anthropic在9月17日发布的复盘报告证实了这些反馈：三个独立的基础设施Bug在8月至9月初期间降低了Claude的回答质量。服务没有宕机，没有遭受攻击，但最严重时（8月31日某一小时）有16%的Sonnet 4请求受到影响，而本应捕捉这类问题的检查全部通过了。

这份复盘几乎全部围绕路由、服务器配置和编译器展开，是"服务在线"与"服务正确"之间差距的教科书级案例。

三个Bug的来龙去脉

Bug一：请求被发往错误的服务器

8月5日，部分Sonnet 4请求开始被"错误路由到为即将推出的100万token上下文窗口配置的服务器"。最初约影响0.8%的Sonnet 4请求，小到看起来像噪声。

8月29日，"一次常规的负载均衡变更无意中增加了短上下文请求被路由到100万上下文服务器的数量"。到8月31日最严重的一小时，16%的Sonnet 4请求受到影响。

路由具有粘性——"一旦某个请求被错误服务器处理，后续追问也很可能由同一台错误服务器处理"。这意味着部分用户会反复得到降质的回答。

最容易被误读的数据是："约30%的Claude Code用户在该时段内至少有一条消息被路由到错误服务器类型。"这是用户占比，不是请求占比，也不能与16%相加——后者是某一小时内Sonnet 4请求的占比。报告没有给出总体受影响用户或请求的总数。

第三方平台受影响要小得多：Amazon Bedrock上误路由流量峰值占全部Sonnet 4请求的0.18%；Google Vertex AI在8月27日至9月16日间受影响请求不到0.0004%。修复于9月4日部署，9月18日全面铺开。

Bug二：错误的token

第二个Bug是"Claude API TPU服务器的配置错误，导致token生成过程中出现错误"。模型逐token生成回答，而一项运行时性能优化"偶尔会给本应很少出现的token赋予高概率"。

结果就是英文提示词得到泰文或中文回复，以及代码中的明显语法错误。该问题在8月25日至28日影响Opus 4.1和Opus 4，影响Sonnet 4直至9月2日回滚。

第三方平台未受影响。Anthropic此后"在部署流程中增加了针对异常字符输出的检测测试"。

top-k采样与近似算法：语言模型在每个生成步骤会为词表中的每个token计算概率，top-k采样是一种解码策略——只保留概率最高的k个候选，再从中按概率采样（温度为零时则退化为取最高概率的token，即贪婪解码）。在TPU等加速器上，精确地对全词表排序代价高昂，因此常采用近似top-k算法（如基于阈值或分桶的快速选择）来降低延迟。近似算法的风险在于：在绝大多数输入下结果与精确排序一致，但在特定批次大小、数值分布或编译器优化下可能返回错误候选集——例如丢弃本应最高概率的token，或给低概率token错误地赋予高概率。这正是Bug二中"英文提示词得到泰文回复"以及Bug三中"同一提示词时好时坏"的技术根源。

Bug三：编译器中的隐藏缺陷

模型选择下一个token时按概率对候选排序，在TPU上使用近似的top-k——一种更快的捷径。

2024年12月，Anthropic发现其"TPU实现在温度为零时偶尔会丢弃最可能的token"，并部署了一个临时方案。2025年8月，他们部署了改进token选择逻辑的代码，"修复移除了12月的临时方案，因为我们认为已经解决了根因"。

这一变更"无意中触发了XLA:TPU编译器中的一个潜在Bug"。近似算法"有时会返回完全错误的结果，但只在特定批次大小和模型配置下出现"。"12月的临时方案一直在无意中掩盖这个问题。"且"同一个提示词可能这次正常、下次失败"。

该问题在Haiku 3.5上得到确认，9月4日回滚。Anthropic认为它"可能影响了Claude API上的部分Sonnet 4和Opus 3请求"。Opus 3于9月12日回滚。Sonnet 4上"无法复现该Bug，但出于谨慎也一并回滚"。最终修复方案是放弃捷径，改用精确top-k，并将部分运算标准化为fp32——"模型质量不容妥协，我们接受了轻微的效率损失"。

TPU与XLA编译器：TPU（张量处理单元）是Google专为神经网络计算设计的加速芯片，Claude模型在TPU集群上推理。XLA（Accelerated Linear Algebra）是Google开发的深度学习编译器，负责将模型计算图编译优化为TPU可执行代码。编译器在优化时会进行算子融合、内存布局调整等变换，其中某些优化可能引入细微的数值差异，在绝大多数情况下无影响，但在特定批次大小或模型配置下可能暴露为错误结果。这类"编译器Bug"通常极难排查，因为它不在模型代码或推理框架内，且往往依赖运行时的具体形状与硬件状态，表现为间歇性、不可复现的故障。Anthropic最终将部分运算标准化为fp32（32位浮点），正是为了规避编译器在低精度近似路径上的不确定性，以可接受的性能损失换取数值稳定性。

为什么几周后才被发现

Anthropic给出了四个原因。

检查通过了。 验证流程依赖基准测试、安全评估和性能指标，工程团队会做抽查并先部署到小规模金丝雀组。但评估"根本没有捕捉到用户反馈的降质，部分原因是Claude往往能从孤立错误中很好地恢复"。

症状相互重叠。 每个Bug在不同平台以不同频率产生不同症状，合在一起"看起来像是随机、不一致的降质"。

时间点掩盖了原因。 "8月29日负面反馈激增时，我们没有立即将其与一次常规负载均衡变更联系起来。"

门是关着的。 内部隐私和安全控制限制了工程师访问用户交互的方式和时机，尤其是未被作为反馈上报的交互。这保护了用户隐私，但也让工程师无法检查识别或复现Bug所需的问题对话。

这项控制本身是正确的。也正因如此，掌握证据的是用户——Anthropic表示，用户的报告"都帮助我们定位了问题"。

金丝雀发布与质量评估的局限：金丝雀发布（canary deployment）是将新变更先推送给极小比例的真实流量，观察指标无异常后再逐步扩大。它能有效捕获崩溃、延迟飙升、错误率上升等硬性故障，但对"回答质量轻微下降"这类软性退化并不敏感——因为质量评估通常依赖基准测试集和自动化评分，而基准测试的题目分布与真实用户请求存在差距，且模型对孤立错误有一定自我恢复能力，使得端到端的质量指标波动被稀释。此外，多项独立Bug同时存在时，各自的症状在聚合指标中相互抵消或模糊，进一步降低了金丝雀阶段发现问题的概率。这解释了为何三个Bug都能通过验证流程，直到用户大规模反馈才被重视。

Anthropic的明确表态

复盘报告开篇写道：

"直白地说：我们从不因需求、时段或服务器负载而降低模型质量。用户报告的问题完全源于基础设施Bug。"

这是Anthropic的声明，报告本身是其提供的证据。

做了哪些改变

Anthropic给出三项承诺：更灵敏的评估，能区分正常实现与故障实现；在更多位置运行质量评估，"将在真实生产系统上持续运行"；更快的调试工具，以便"在不牺牲用户隐私的前提下更好地调试社区反馈"。

同时鼓励用户继续通过Claude Code的/bug命令或应用中的点踩按钮上报问题。

对基础设施团队的四个启示

在线不等于正确。 这三个Bug都没有让服务停止响应。如果监控只测系统是否应答，而不测回答是否正确，质量故障对它就是隐形的。

小变更会叠加。 一次常规负载均衡变更，把影响约0.8%请求的Bug放大到最严重小时的16%。在宣布新变更干净之前，先弄清此前已经坏了什么。

临时方案会掩盖问题。 移除它可能暴露它一直在悄悄遮盖的东西。把移除临时方案本身当作一次独立变更来对待。

提前决定如何调查你无权查看的故障。 隐私之门应当保留，但获得同意的通道和配套工具，必须在你需要它的那一天之前就存在。