vLLMコミュニティがAMDのprefill競合を報告、非同期スケジューリングでGPUメモリエラーの可能性

9月27日、vLLMコミュニティでAMD推論バックエンドの競合状態が報告された。AITER MLA、FP8 KVキャッシュ、非同期スケジューリングを同時に使用すると、prefill中にGPUメモリエラーが発生する可能性があるという。報告は8基のMI355Xを搭載した開発版環境での事例に基づき、単一GPUで再現できる独立したプログラムも示されている。正式リリースでの影響範囲はまだ確認されていない。[問題報告](https://github.com/vllm-project/vllm/issues/58886)

報告者は、原因をバッチ間で共有されるスケジューリングメタデータにあると見ている。ホストが次のリクエストバッチ用にバッファーを書き換える一方、前のバッチのGPUカーネルがまだキューに残っていると、別のバッチの作業割り当て表を読み込む可能性がある。従来のコピー処理では現在の実行ストリーム内の順序が考慮されておらず、後から同期しても上書きを防げなかったという。[修正案](https://github.com/vllm-project/vllm/pull/58887)

これは推論性能を最適化する際の基本的なトレードオフに関わる。vLLMのドキュメントによると、非同期スケジューリングはGPUのアイドル時間を減らし、レイテンシとスループットを改善できる。AMDのドキュメントでは、非同期転送は計算と重ねて実行できる一方、ストリームとイベントを使って実行順序を調整する必要があると説明されている。この仕組みでは、共有バッファーのライフサイクル管理もサービスの正しさを保つ要素となる。[vLLM設定ドキュメント](https://docs.vllm.ai/en/latest/configuration/engine_args/)、[AMD非同期実行ドキュメント](https://rocmdocs.amd.com/projects/HIP/en/latest/how-to/hip_runtime_api/asynchronous.html)

修正案では、2組のページロック済みホストステージングバッファーを使ってスケジューリングデータを生成し、現在のストリームに沿ってGPUへコピーする。コピー完了イベントを待ってからステージングバッファーを再利用する。作者のテストでは、従来は111件目のリクエストでエラーになった負荷が、修正適用後は1,024件すべて完了した。関連するクラッシュテストでは代替の重みを使っているため、モデルの回答品質を判断する根拠にはならない。[修正案とテスト結果](https://github.com/vllm-project/vllm/pull/58887)

作者はDeepSeek-V3でも同じ障害を再現した。ROCm 7.2でのデフォルト設定によるサービステストではクラッシュしなかったが、独立した再現ケースやキュー設定を変更した場合には引き続き発生させられたため、ダウングレードを根本的な解決策とは見なせない。これらの結果は現時点では提出者によるもので、独立した検証はまだない。また、サイレントな数値エラーが精度に与える影響も十分に定量化されていない。[再現の詳細と制限](https://github.com/vllm-project/vllm/issues/58886)

確認時点で、修正案はまだマージされていない。作者の事例では非同期スケジューリングを無効にすると障害を回避できた。該当する構成の環境では、まずテスト環境で比較検証できるが、性能への影響は個別に測定する必要がある。[提案の状況](https://github.com/vllm-project/vllm/pull/58887) エンジニアリングチームは、障害を特定の構成と照合できるよう、イメージタグ、バックエンドの選択、キャッシュ精度を記録しておくとよい。検証では、既存のデコードバッチに新しいリクエストが加わる状況も含め、完了率とエラーログを確認したうえでスループットを比較する。今後は、メンテナーによるレビュー、修正が取り込まれるバージョン、実際の重みを使った長い入力や複数の同時実行負荷での回帰結果を追跡する必要がある。