Claude 再次解釋：八月到九月初，它確實出問題了。

剛剛，Anthropic 今天發布了一份詳細的技術報告，解釋了三個基礎設施 bug 如何讓 Claude 的回答質量斷崖式下降。

雖然他們像是說了些實話，但這份報告來得有點太晚了。

Claude 到底怎么了？

從八月初開始，用戶就開始抱怨 Claude 的回答變差了。

起初 Anthropic 很難分辨這到底是正常的用戶反饋波動，還是真的出了問題。

但隨著投訴越來越多，他們終于在八月底開始調查。

Anthropic 在報告中強調：

我們從不會因為需求量、時間段或服務器負載而降低模型質量。

用戶遇到的問題完全是基礎設施 bug 導致的。

調查發現了三個相互重疊的 bug，這讓診斷變得異常困難。

Anthropic 聲稱：現在，這三個 bug 都已經修復了。

三個讓人頭疼的 Bug

Illustrative timeline of events on the Claude API. Yellow: issue detected, Red: degradation worsened, Green: fix deployed.

第一個 bug：路由錯誤

8 月 5 日，部分 Sonnet 4 的請求被錯誤地路由到了為即將推出的 100 萬 token 上下文窗口配置的服務器。

這個 bug 最初只影響 0.8% 的請求。

但 8 月 29 日的一次常規負載均衡調整，意外地讓更多短上下文請求被路由到了長上下文服務器。

最嚴重的時候，8 月 31 日某個小時內，16% 的 Sonnet 4 請求都受到了影響。

更糟的是，路由是「粘性的」：一旦請求被錯誤的服務器處理，后續的對話也會繼續被同一個錯誤的服務器處理。

第二個 bug：輸出損壞

8 月 25 日，他們在 Claude API 的 TPU 服務器上部署了一個錯誤配置。

這導致模型會莫名其妙地輸出一些不該出現的 token，比如在英文對話中突然蹦出泰文或中文字符，或者在代碼中產生明顯的語法錯誤。

有用戶可能會在英文回答中看到「??????」這樣的泰文問候語。

這個問題影響了 8 月 25-28 日的 Opus 4.1 和 Opus 4，以及 8 月 25 日到 9 月 2 日的 Sonnet 4。

第三個 bug：XLA:TPU 編譯器錯誤

8 月 25 日，他們部署了改進 token 選擇的代碼，但無意中觸發了 XLA:TPU 編譯器中的一個潛在 bug。

這個 bug 確認影響了 Claude Haiku 3.5，可能也影響了部分 Sonnet 4 和 Opus 3。

編譯器 bug 的技術細節

Code snippet of a December 2024 patch to work around the unexpected dropped token bug when temperature = 0.

這個 bug 最為棘手。

Claude 生成文本時，會計算每個可能的下一個詞的概率，然后隨機選擇。

在 TPU 上，模型運行在多個芯片上，概率計算發生在不同位置，需要在芯片之間協調數據。

問題出在混合精度算術上。

模型用 bf16（16 位浮點數）計算概率，但 TPU 的向量處理器原生支持 fp32，所以編譯器會把某些操作轉換為 fp32 來優化性能。

這造成了精度不匹配：本該在最高概率 token 上達成一致的操作，因為運行在不同精度級別而產生分歧。最高概率的 token 有時會完全消失。

Code snippet showing minimized reproducer merged as part of the August 11 change that root-caused the “bug” being worked around in December 2024; in reality, it’s expected behavior of the xla_allow_excess_precision flag.

他們在修復精度問題時，暴露了一個更底層的 bug：approximate top-k 操作的問題。

這是一個性能優化，用來快速找到最高概率的 token，但有時會返回完全錯誤的結果。

Reproducer of the underlying approximate top-k bug shared with the XLA:TPU engineers who developed the algorithm. The code returns correct results when run on CPUs.

這個 bug 的行為令人抓狂。

它會根據無關因素而改變，比如前后運行了什么操作，是否啟用了調試工具。

同一個提示詞，這次可能完美運行，下次就失敗了。

最終他們發現 exact top-k 操作已經沒有以前那么大的性能損失了，于是改用精確算法，并將一些操作標準化為 fp32 精度。

為什么這么難發現？

Anthropic 的驗證流程通常依賴基準測試、安全評估和性能指標。

工程團隊會進行抽查，先部署到小型「金絲雀」組。

但這些問題暴露了他們本該更早發現的關鍵缺陷。

他們的評估根本沒有捕捉到用戶報告的質量下降，部分原因是 Claude 往往能從孤立的錯誤中很好地恢復。

隱私實踐也造成了調查困難：內部隱私和安全控制限制了工程師訪問用戶與 Claude 交互的方式和時間。

這保護了用戶隱私，但也阻止了工程師檢查那些識別或重現 bug 所需的問題交互。

每個 bug 在不同平臺上以不同速率產生不同癥狀，創造了令人困惑的混合報告，沒有指向任何單一原因。

看起來就像是隨機的、不一致的質量下降。

改進措施

Anthropic 承諾將做出以下改變：

• 更敏感的評估：開發能更可靠地區分正常和異常實現的評估方法。
• 更多地方的質量評估：將在真正的生產系統上持續運行評估，以捕捉類似上下文窗口負載均衡錯誤這樣的問題。
• 更快的調試工具：開發基礎設施和工具來更好地調試社區反饋，同時不犧牲用戶隱私。

他們特別強調，用戶的持續反饋至關重要。

用戶可以在 Claude Code 中使用 /bug 命令，或在 Claude 應用中使用「thumbs down」按鈕來提供反饋。

網友反應

雖然 Anthropic 的透明度值得贊賞，但用戶們的反應卻可以說是相當復雜。

Denis Stetskov(@razoorka) 表示能感受到巨大的改進：

我已經能感受到巨大的改進。無論你們修復了什么，它都起作用了。

Rajat(@DRajat33) 贊賞了透明度：

感謝澄清和細節。透明度是讓公司與眾不同的東西，無論他們的產品如何。

但更多用戶對沒有補償表示不滿。

Alexandr Os(@iamavalex) 直接要求：

發布受影響賬戶列表并立即退款。我就是其中之一。

Conor Dart(@Conor_D_Dart) 質疑：

你們會給受影響的用戶退款或補償嗎？報告影響了很多人，你們的價格可不便宜。

The City Keeps Building(@TheCity777) 簡單直接：

我們的退款呢？

peermux(@peermux) 認為：

如果你承認在八月到九月之間沒有交付商定的產品，那么你應該提供退款，或至少提供一個月的免費服務。這將展示誠意并有助于維持信任。

Baby Yoda(@grogu836) 表示失望：

我們不會因此獲得退款？難以置信。再也不用 Claude Code 了。

還有用戶指出問題可能還沒完全解決。

tuna(@tunahorse21) 說：

它很明顯還有 bug，你們等了一個月才承認這個問題。

Daniel Lovera(@dlovera) 則提出了更進一步的質疑，認為短上下文請求在長上下文服務器上表現變差，說明 Anthropic 實際上是在根據需求間接降低模型質量。

Thomas Ip(@_thomasip) 則總結了三個 bug：

tldr： 

bug 1 - 一些請求被路由到測試服務器 

bug 2 - 性能優化 bug 給稀有 token 分配了高概率 

bug 3a - 精度不匹配導致最高概率 token 被丟棄 

bug 3b - approximate top-k 算法完全錯誤

[1]技術后期診斷報告: https://www.anthropic.com/engineering/a-postmortem-of-three-recent-issues