vLLMコミュニティ、多機デコードの遅延を報告　空のKVコネクタでも性能低下の可能性

9月27日、vLLMコミュニティで複数ノードのデコード性能に関する報告があった。Model Runner V2と非同期スケジューリングを使う0.30.0では、読み書きを行わないKVキャッシュコネクタを追加しただけでも遅延が増加するという。テスト環境は2ノード、計16基のH100 80GBで、GLM-5.2 FP8を実行し、8-wayのパイプライン並列と2-wayのテンソル並列を構成した。入力は約1万2,000トークン、生成数は1,024トークンに固定。8リクエストを同時に実行すると、トークンあたりの遅延は32.1ミリ秒から60.0ミリ秒に増加した。[コミュニティの報告](https://github.com/vllm-project/vllm/issues/58920)

公式コードからは、重要な違いを確認できる。マルチプロセスエグゼキューターが出力アグリゲーターを受け取ると、`output_rank`を`None`に設定し、すべてのワーカープロセスからの応答を収集する。結果を返すプロセスを指定するだけだった経路が、複数の応答キューを一つずつ読み取る処理に変わるため、メッセージが小さくても応答数によって追加の負荷が生じる可能性がある。[0.30.0エグゼキューターのドキュメント](https://docs.vllm.ai/en/v0.30.0/api/vllm/v1/executor/multiproc_executor/)

共有メモリーキューの書き込み側は、ブロックの読み取りが終わるまで繰り返し確認し、`sched_yield`を呼び出す。報告者は、待機中にPythonのグローバルインタープリターロック（GIL）の競合が起き、メインスレッドによる入力準備を妨げていると見ている。診断用の変更でロックを解放する待機方式に切り替えたところ、追加遅延は約13%まで低下した。ただし、これは報告者による原因の特定と測定結果だ。[キューのソースコード](https://github.com/vllm-project/vllm/blob/v0.30.0/vllm/distributed/device_communicators/shm_broadcast.py)、[診断実験](https://github.com/vllm-project/vllm/issues/58920)

こうしたボトルネックは、V2の設計目標に直結する。公式ドキュメントによると、非同期スケジューリングでは、CPUが次のステップの入力を準備する処理と、GPUが現在のステップを実行する処理を重ね合わせ、CPUの処理をノンブロッキングに保つ必要がある。このため、応答処理のスレッドが入力準備を妨げると、GPUの計算カーネルが遅くなっていなくても、デコード全体のペースが制限されると推測できる。[V2設計ドキュメント](https://docs.vllm.ai/en/latest/design/model_runner_v2/)

KVコネクタは、プリフィルとデコードを分離するアーキテクチャでも重要なインターフェースだ。公式ドキュメントでは、分離デプロイは最初のトークンまでの時間と後続トークンの遅延を個別に調整する方法とされており、スループットは向上しないとも説明されている。そのため、デプロイを評価する際は、ネットワーク帯域から効果を推定するだけでなく、キャッシュ転送による利点と制御経路のコストを両方測定する必要がある。[分離デプロイのドキュメント](https://docs.vllm.ai/en/latest/features/disagg_prefill/)

エンジニアリングチームは、コネクタ未設定、空のコネクタ、実際のコネクタを比較対象にし、モデル、並列化の構成、負荷を固定したうえで、トークン間隔とCPUスレッドの動きを同時に観測できる。現時点の証拠は単一のデプロイに限られ、すべてのハードウェアに一般化することはできない。確認時点でこのIssueはオープンのままで、メンテナーによる原因確認や関連する修正は確認されていない。応答の集約、キュー容量、待機方式に関する上流の変更を引き続き追う必要がある。[Issueの状態](https://github.com/vllm-project/vllm/issues/58920)