2025 年 8～9 月，路由、TPU 输出、近似 top-k 三类问题曾经叠在一起，表现成「同一款产品，有人觉得一切正常、有人觉得明显不对」——排障像抓幽灵。原文写得很直白：从来没有因为需求、时段或负载去主动降低模型质量；用户感知到的异常，来自基础设施缺陷。[1]
先看主线
- 主线：时间线怎么叠起来 → 三个根因各是什么 → 为什么难早发现 → 改进项对你意味着什么（观测、RCA、别急着骂 prompt）。
- 跳读位：文内
### 深度解析与「官方叙事与可核对事实」。
一、背景：三条线同时出问题，看起来像「随机变差」
2025 年 8 月—9 月初，三个互相叠加的缺陷间歇影响回答质量；一开始反馈很难和正常波动区分开，8 月底报告变多才推动深挖。[1]
服务横跨 自研 API、Amazon Bedrock、Google Vertex；硬件上还有 Trainium、NVIDIA GPU、Google TPU——跨平台要等价，任何一次变更验证面都很大。[1]
8 月 29 日一次负载均衡调整，把其中一类路由问题放大：于是「有人正常、有人异常」并存，诊断难度直接上去。[1]
二、问题一：上下文窗口路由走错池
8 月 5 日起，部分 Sonnet 4 请求被误路由到给即将上线的 1M token 上下文准备的服务器池（产品说明见 Claude 文档 · 上下文窗口、1M token 窗口）；初期大约 0.8% 请求受影响。[1][3]
8 月 29 日负载均衡变更后，更多短上下文请求误入长上下文池；8 月 31 日最差一小时大约 16% Sonnet 4 请求受影响。约 30% 的 Claude Code 用户在那个时段至少有一条消息走错池；再加上粘性路由，后续对话更容易一直落在错误池上——这不是「你 prompt 写坏了」能解释的。[1]
第三方：Bedrock 峰值约 0.18% ； Vertex 在特定区间 <0.0004%（原文叙述）。[1]
修复：纠正短/长上下文路由；9 月 4 起部署，9 月 16 前完成 Vertex 等 rollout，Bedrock 到 9 月 18。[1]
三、问题二：输出损坏（TPU 配置）
8 月 25 日起，Claude API 的 TPU 服务器上某条配置在 token 生成时出错：性能优化路径偶发把不该高频出现的 token 概率抬得很高——于是你会看到英文提示中间突然冒出泰文/中文片段，或者代码明显语法不对。[1]
影响范围（原文）：Opus 4.1 / Opus 4（8/25–28）、Sonnet 4（8/25–9/2）；第三方平台称未受此问题影响。[1]
9 月 2 日回滚；并补了针对异常字符输出的部署检测。[1]
四、问题三：近似 top-k 撞上 XLA:TPU 误编译
8 月 25–26 日部署的采样相关改动，触发 XLA:TPU 编译器里一个早就存在的坑，影响 approximate top-k；已确认影响 Haiku 3.5；Sonnet 4 / Opus 3 子集也可能（原文措辞）。[1]
技术脉络（压缩版）：bf16 和 fp32 混精、xla_allow_excess_precision、2024 年 12 月对 temperature=0「丢最高概率 token」的 workaround；8 月重写采样时把这个 workaround 拿掉，approximate top-k（性能近似、原文与 XLA 团队对齐的算法背景见 arXiv:2206.14286）在部分 batch/配置下会返回完全错误的结果——以前其实被 workaround 盖住了。XLA:TPU 指将 XLA 编译到 TPU 指令的路径（原文脚注口径）。[1][4][5][6][7]
现象很不稳定：同一个 prompt 可能一次成一次挂，还跟前后算子、调试器开没开之类因素搅在一起。[1]
处置：Haiku 3.5 9 月 4 日回滚；Opus 3 9 月 12 日回滚；Sonnet 4 没能稳定复现，但出于谨慎也回滚。后面和 XLA:TPU 团队修编译器，并改用 exact top-k 和更强的 fp32 规范化（接受一点效率代价）；top-p 阈值附近 token 集合可能有细微变化（原文脚注）。[1]
五、为什么难早发现
常规定期评测没能稳定复现用户说的那种退化（模型对孤立错误有时还会「自愈」）。隐私与内控又不允许工程师随便翻没主动反馈的用户会话，复现更难。三条问题症状和平台/速率都不一样，叠在一起就像「随机变差」。8/29 负载均衡和问题之间的关联，也不是一眼能看出来。[1]
深度解析：「评测没复现」和生产环境的异质性
事实：文里说常规定期评测没能稳定复现。[1]
原文观点：需要生产级质量评测，还要和隐私约束平衡。[1]
本文解读：粘性路由 + 用户子集会带来异质性——全库 offline eval 可能一直绿，但一部分用户红；这时更该想 分桶监控 和 跟云厂商一起对时间线，而不是先改 prompt。
六、改进方向（原文归纳）
- 更敏感、更能区分好坏实现的评测。
- 在真实生产系统上持续跑质量评测（路由类问题也能抓到）。
- 在保护隐私前提下，让社区反馈更好调试；文里也提到内部工具能缩短处置时间。[1]
同时呼吁用户继续用 Claude Code /bug 、应用内点踩、feedback@anthropic.com 这类渠道，把可观察现象说清楚。[1]
官方叙事与可核对事实：复盘和「降质」传言
事实：原文明确否认主动降质。[1]
原文观点：问题在基础设施。[1]
本文解读：对外沟通要把 模型能力 和 路由/硬件栈 分开——客户侧做 RCA，至少对齐 时间窗口 + 平台 + 模型 SKU 三个维度。
结论与讨论
技术坐标
这篇 postmortem 把「模型变差」拆成 路由池、TPU 采样、编译器与历史 workaround 的交互——说明 API 质量是全栈问题，榜单和离线评测只是其中一层。评测叙事还可对照同系列 Demystifying evals for AI agents 与参考文献 [2]。
批判性问题
- 你的应用有没有记 模型 SKU + 路由元数据，方便对标供应商事故？
- Bedrock/Vertex 和 一阶 API 的差异有没有写进 runbook？
- temperature=0 和 近似 top-k 这类历史包袱，在你们自己的推理栈里有没有？
独立判断（事实 / 原文观点 / 本文解读）
| 类型 | 内容 |
|---|---|
| 事实 | 原文 URL；日期与百分比为文内叙述。[1] |
| 原文观点 | 三问题叠加；补评测与反馈通道。[1] |
| 本文解读 | 最值得带走的是 异质性：「有人红有人绿」先查 分桶与时间线，别先骂 prompt。[1] |
| 批判性提醒 | 百分比、日期与根因叙述均为 Anthropic 自述复盘；一阶 API 与 Bedrock / Vertex 的影响面不可直接混成你的 SLA；读者侧仍应用自有请求日志、SKU、区域与厂商状态页交叉验证，别把单篇 postmortem 当永久根因清单。[1] |
参考文献与延伸阅读
- [1] A postmortem of three recent issues — Anthropic Engineering，2025-09-17
- [2] Demystifying evals for AI agents — 同系列评测叙事
- [3] Context windows · 1M token context window
- [4] JAX ·
jax.lax.approx_max_k - [5] Batch Top-k CUDA（arXiv:2206.14286） — 原文链至的近似 top-k 算法背景
- [6] XLA architecture（OpenXLA）
- [7] Temperature（Claude 术语表）
