RPS（1秒あたりのリクエスト数）が 14,720 に達した本番環境で、LLM 推論サーバーが突然停止した。原因は vLLM の PagedAttention が管理する KV キャッシュの破損だった。このインシデントレポートは、LLM サービングの内部構造を知る良い機会になる。
vLLM と PagedAttention の仕組みをおさらいする
vLLM は、大規模言語モデルをサービングする（APIとして提供する）ためのオープンソースの推論エンジンです。UC バークレーが開発し、現在は広く使われている OSS プロジェクトです。
その中核技術が PagedAttention です。Transformer モデルは、推論の各ステップで過去のトークン（単語の断片）に対応する Key と Value のベクトルを再利用します。この Key-Value の対を保存する領域を KV キャッシュと呼びます。通常、KV キャッシュはシーケンス長に比例してメモリを消費し、長文になるほど GPU メモリを大量に使います。
PagedAttention はこの問題を、OS のページングメモリ（仮想アドレスを物理メモリに動的に割り当てる仕組み）と同じ考え方で解決します。連続したメモリブロックに縛られず、空いているブロックを柔軟に組み合わせて KV キャッシュを配置します。これにより、GPU メモリの断片化が減り、スループットが向上します。
何が壊れたのか：キャッシュ退避ポリシーのバグ
今回のインシデントでは、KV ストアへのアクセス時に `Cache corruption detected` という例外が発生し続けました。問題の構造を整理すると次のようになります。
vLLM → PagedAttention → KV Store → (破損した応答) → エラーデバッグの過程でチームが最初に試みた対処は、どれも的外れでした。NCCL（GPU間の通信ライブラリ）のタイムアウト延長、Pod の再起動、nvidia-smi による GPU ヘルスチェックなど、45分間を費やした調査はすべて空振りに終わっています。
最終的に判明した原因は、キャッシュ退避ポリシー（使用頻度の低いキャッシュを削除してメモリを回収する処理）の 1行のバグでした。退避処理が誤ったブロックを無効化し、後続リクエストが壊れたデータを参照し続けたと考えられます。
このバグが高 RPS 時にのみ顕在化した点は重要です。低負荷では退避が走らないため無害に見えるバグが、ピーク時の大量リクエストをきっかけにキャッシュ操作が頻発して初めて露出する、典型的なパターンです。
関連技術との比較で理解を深める
vLLM の競合として近年注目されているのが SGLang です。SGLang は RadixAttention という独自の KV キャッシュ共有方式を採用しており、同じプレフィックスを持つ複数リクエスト間でキャッシュを効率よく再利用します。PagedAttention との最大の違いは、ツリー構造でキャッシュを管理するため、プレフィックスが長いユースケース（システムプロンプトが共通の API など）での再利用率が高い点です。
KV キャッシュのオフロードという方向性もあります。GPU メモリが不足する場面では、KV キャッシュを CPU RAM や NVMe SSD に退避させる手法が研究・実装されています。vLLM 0.4 系以降はこの機能を実験的にサポートしており、コスト削減とスループットのトレードオフを調整できます。
NCCL（NVIDIA Collective Communications Library）への言及もインシデントの中にあります。NCCL は複数 GPU 間での all_reduce（分散処理で各ノードのデータを集約する操作）に使うライブラリで、シングルノードには無関係です。今回のエラーはマルチノード構成でのみ再現するとも報告されており、分散推論特有の複雑さが診断を難しくしていた側面があります。
監視設計から学べること
チームはインシデント後、Grafana と PagerDuty を組み合わせた 3 種のアラートを追加しました。具体的には、NCCL エラーレートの閾値監視と、all_reduce レイテンシの 99 パーセンタイル監視の 2 本立てです。
# 99パーセンタイルの all_reduce レイテンシが 50ms を超えたら通知
histogram_quantile(0.99, nccl_allreduce_duration_seconds_bucket) > 0.05この設計で学べるのは、LLM 推論基盤では「モデルの精度」だけでなく「通信レイテンシ」と「キャッシュの健全性」を独立して観測することが必要だという点です。どちらが劣化しても推論品質とスループットの両方に影響します。
vLLM を本番運用する際には、キャッシュヒット率・退避頻度・GPU 間通信のレイテンシをそれぞれ独立した指標として収集しておくと、次のインシデントを事前に捕捉できる可能性が上がります。KV キャッシュの破損は再現が難しい性質の障害だからこそ、観測の網を事前に張っておくことが現実的な対策になります。