vLLMで外部KVキャッシュの読み込み失敗によりエンジンが終了するとの報告、影響範囲は未確認

vLLMコミュニティに9月21日、外部KVキャッシュの障害が報告された。LMCacheMPConnectorでハイブリッドアテンションモデルを実行したところ、キャッシュの読み込み失敗後に、エンジンプロセスもアサーションエラーで終了したという。報告には環境情報、発生手順、エラーログが添付されている。Issueは現在もオープンで、修正案へのリンクやメンテナーによる公開の確認はまだない。[問題報告](https://github.com/vllm-project/vllm/issues/57938)

この事例ではAMD MI325XとGemma 4 31BのFP8重みを使用している。モデルはスライディングウィンドウアテンションとグローバルアテンションを組み合わせており、構成には6つのKVキャッシュグループが含まれる。再現条件は、GDS／hipFileバックエンド経由の読み込みでストレージエラーを発生させることだ。報告の概要には0.29.1と記載されているが、環境情報に出力された実際のバージョンは開発ビルドの`0.29.1rc1.dev47+gdc36fcce9`であり、これを根拠に正式版全般が影響を受けるとは判断できない。[環境情報とログ](https://github.com/vllm-project/vllm/issues/57938)

焦点は障害の影響範囲にある。この事例では`kv_load_failure_policy=fail`が設定されている。公式の定義では、この設定は影響を受けたリクエストをエラーで終了させるもので、もう一方の選択肢である`recompute`が、無効になったブロックの再計算をスケジュールする。報告者は再計算を期待しているが、現時点の証拠が最も直接的に示す異常は、リクエストの失敗がエンジンの終了にまで波及したことだ。設定を再計算に変更するだけでは、検証済みの解決策とはみなせない。[失敗処理ポリシーのドキュメント](https://docs.vllm.ai/en/latest/api/vllm/config/kv_transfer/)

ログでは、スケジューラがまず1件のリクエストの失敗を記録し、その後、キャッシュ転送の完了状態を更新する際に、リクエストがまだ存在することを確認するアサーションに失敗している。現行ドキュメントに掲載されているコードにも、このチェックは残っている。ただし、これは調査箇所を示すにとどまり、どの処理が先にリクエストを削除したのか、どのコンポーネントで修正すべきなのかを証明するものではない。[スケジューラのコード](https://docs.vllm.ai/en/latest/api/vllm/v1/core/sched/scheduler/)

この種の障害は、デプロイや運用を担うチームにとって注目に値する。LMCacheのマルチプロセスアーキテクチャでは、キャッシュを独立したサービスとして分離し、同一ノード上の複数の推論インスタンスで共有できるほか、キャッシュリソースも独立して設定できる。この構成からは、サービス中断の範囲を限定するには、プロセスの分離に加え、推論側がリモートのエラーを適切に処理する必要があると考えられる。[アーキテクチャのドキュメント](https://docs.lmcache.ai/mp/index.html)

次の段階では、隔離されたテスト環境で読み込み障害を注入し、他のリクエストへのサービスを継続できるか確認するとともに、リクエストのキャンセルと転送完了イベントの発生順序を追跡すべきだ。現時点の資料には、障害の発生率、異なるハードウェアでの再現結果、正式な修正結果は含まれていない。エンジニアリングチームは実際に使用するコミットを固定し、最小限の再現テストと、メンテナーによる影響範囲の特定を待つ必要がある。受け入れ検証でも、単一リクエストのエラー、プロセスの再起動、他のリクエストのレイテンシをそれぞれ記録し、ヘルスチェックの回復だけを見て障害の影響が封じ込められたと判断しないことが求められる。