- 8月から9月初旬にかけて、Claudeの応答品質低下が3つのインフラバグによって発生
- 問題の主な原因はそれぞれ、コンテキストウィンドウのルーティングエラー、出力破損、そしてXLA:TPUの近似top-k未コンパイルエラー
- 各バグはさまざまなハードウェアやデプロイ経路で相互に重なって発生し、診断をさらに難しくした
- 検知と解決が遅れた要因には、検証プロセスの抜け穴や、プライバシーポリシーに基づくアクセス制約などがあった
- Anthropicは、評価とモニタリングの強化、より迅速なデバッグツールの開発などを通じて、同様の事故の防止に取り組んでいる
概要と背景
- 8月から9月初旬まで、Claudeの応答品質が断続的に低下する現象が報告された
- 当初はユーザーフィードバックの中で通常の変動と見なされていたが、報告が継続的に増加したことで調査が始まった
- Anthropicは、需要やサーバー負荷ではなく、インフラバグのみが問題の原因であることを明確にした
- Claudeは数百万人のユーザーに対し、複数のプラットフォーム（APIs、Amazon Bedrock、Google Vertex AIなど）を通じて提供されており、AWS Trainium、NVIDIA GPU、Google TPUなど多様なハードウェア上で同等の結果を保証するため、厳格な検証基準を持つ
- 今回の事後分析では、バグの原因、診断と解決の遅延理由、そして再発防止策を説明する
Claudeの大規模サービス体制
- Claudeのサービスは複数のハードウェア（Trainium、GPU、TPU）を通じてグローバル展開を維持している
- 各プラットフォームごとの同一品質保証に向けた実装同等性の基準は厳格である
- インフラ変更時には、すべてのプラットフォームと設定において精密な検証プロセスが必要となる
主要な問題発生のタイムライン
- 8月5日: 1つ目のバグ。Sonnet 4リクエストの約0.8%に影響
- 8月25日、26日: 2つ目、3つ目のバグがそれぞれデプロイされた
- 8月29日: ロードバランシング変更により問題のあるトラフィックが急増し、より多くのユーザーが影響を受けるようになった
- 各バグは症状が重なり、診断難易度が非常に高かった
3つの重複バグと解決過程
1. コンテキストウィンドウのルーティングエラー
- 8月5日、一部のSonnet 4リクエストが1Mトークンのコンテキストウィンドウ向けサーバーに誤ってルーティングされた
- ロードバランシング変更後は、最大16%のSonnet 4リクエストに影響し、Amazon BedrockとGoogle Vertex AIにも軽微な影響が発生した
- ルーティング方式が"sticky"だったため、一度誤ったサーバーに接続されると、その後も同じサーバーに接続され続ける問題があった
- 解決: ルーティングロジックを改善し、9月4日に自社プラットフォームへパッチを適用、Google Cloudには9月16日までにデプロイ、Bedrockには段階的に適用中
2. 出力破損（bug）
- 8月25日、Claude APIのTPUサーバーに誤った設定が適用され、トークン生成時にエラーが発生
- 英語の質問にタイ語や中国語など無関係な文字が混ざって出力されたり、コードに明白な文法エラーが挿入されたりする現象が発生
- Opus 4.1、Opus 4、Sonnet 4のみに影響し、サードパーティープラットフォームには影響しなかった
- 解決: 9月2日に変更をロールバックし、異常文字出力を検知するテストをデプロイプロセスに追加した
3. 近似top-kのXLA:TPU未コンパイルエラー
- 8月25日、トークン選択方式の高度化の過程で、XLA:TPUコンパイラの潜在的なバグが表面化した
- Claude Haiku 3.5、一部のSonnet 4、Opus 3に影響
- サードパーティープラットフォームには影響なし
- 解決: Haiku 3.5は9月4日、Opus 3は9月12日にそれぞれロールバックし、Sonnet 4では直接再現されなかったものの予防措置としてロールバックした
- 並行してXLA:TPUチームと協力してコンパイラバグを修正中であり、正確なtop-k方式への切り替えを進めている
XLAコンパイラバグの詳細分析
- Claudeはトークン生成過程で各候補に対する確率計算とサンプリングを行う
- TPUは分散環境で動作するため、トークン確率計算の同期が必要であり、複雑さを伴う
- 2024年12月、bf16-32ビット混合精度の使用に伴う誤差により、最上位確率のトークンが欠落する問題が見つかり、これに対する暫定修正がデプロイされた
- 8月26日、根本原因を解決するためのサンプリングコード改修中に、近似top-k演算で特定条件下に完全に誤った結果が出力される、より深刻なバグが露呈した
- このバグは、それ以前の暫定修正によって問題が隠されていた
- また、近似top-k演算のバグは本番環境やバッチサイズによって症状が不規則に変化した
- 近似top-kの代わりに、最近では性能負荷が大幅に減ったexact top-kへ切り替えており、主要な演算をfp32標準化で改善している
検知遅延の原因
- 定期的な自動評価や事前グループデプロイなどの手順を運用していた
- 今回の事件では評価プロセスの抜け穴が明らかになった。たとえば、問題状況をうまく検知できない評価項目や、社内のプライバシー保護方針（エンジニアが具体的なユーザーリクエストにアクセスできない）によって迅速な分析が難しかった
- 症状がプラットフォームやバージョンごとに多様に現れたため、単一の原因を特定することが難しかった
- オンライン報告が急増した際も、標準的なロードバランシング変更との関連を即座に認識できなかった
今後の改善と対応策
- 感度の高い評価項目を開発し、破損状態と正常実装をより明確に判別できる自動評価を強化
- 実運用環境全体に評価とモニタリングシステムを拡大し、たとえばコンテキストウィンドウのルーティングエラーのような本番環境中心の評価を実施
- より迅速で精密なデバッグツールを新設し、コミュニティフィードバックをプライバシーを維持しつつ迅速に分析できるよう、インフラとカスタムツールを開発
- 内部評価だけでなく、ユーザーフィードバックの継続的収集の信頼性も強調。予測しにくいエラーやバグでは、実際のユーザー報告が重要なシグナルとなる
"/bug"コマンドやthumbs down機能の活用、メールを通じたモデル品質評価方法の報告を積極的に奨励している
参考説明
- XLA:TPUはXLAの高水準最適化言語コードをTPU命令へ変換するコンパイラである
- モデルサイズが大きいため、1つのチップではなく複数のチップに分割配置され、sortingオペレーションなどはベクトル化された形で実装する必要がある
- 近似top-k演算は性能向上のために使われるが、確率が最も高いトークンを欠落させるなどの深刻な問題を内包しうる
- 現在は正確なtop-k方式を導入しており、top-pしきい値に近いトークンの含まれ方に微細な変化が生じる可能性がある。場合によってはユーザーがtop-p値を調整する必要があるかもしれない
まだコメントはありません。