vLLM 分散推論ガイド

vLLM は、LLM 推論における3つの主要なワークロードであるプロンプト処理（プリフィル）、トークン生成（デコード）、および CPU バウンドなフロントエンドタスク（トークナイズおよびパース）を分離する「分散推論（Disaggregated Serving）」を導入しました。これらの段階を分割することで、vLLM は長いプロンプトがアクティブな生成ストリームを停滞させることを防ぎ、運用者が初回トークンまでの時間（TTFT）とトークン間レイテンシ（ITL）を個別に調整できるようにします。

分散推論の技術アーキテクチャ

vLLM における分散推論は、推論パイプラインを個別にスケーリングおよび調整可能な階層に分割します。

プリフィルとデコードの分離

プリフィルとデコードは別々のインスタンスとして実行されます。プリフィルインスタンスは初期プロンプトを処理して KV キャッシュ（アテンションのキーと値）を生成し、それが KV コネクタを介してデコードインスタンスに転送されます。

KV キャッシュ転送: 転送サイズはモデルとプロンプトの長さに依存します。例えば、BF16 の Llama-3.1-70B は 1 トークンあたり 320 KiB を保持するため、10k トークンのプロンプトでは約 3 GB のデータ転送が必要です。
コネクタ: vLLM はこの転送のために NIXL, LMCache, Mooncake, FlexKV, AMD の MoRI-IO など複数のコネクタをサポートしており、多くの場合、高速なデータ移動のために RDMA を利用します。

フロントエンドの分離（レンダリング/デレンダリング）

CPU 負荷の高いタスクは、GPU を使用しないフロントエンド層に移動されます。

/render: OpenAI 形式のリクエストをトークン ID に変換します。
/derender: 出力されたトークン ID を、コンテンツ、推論、ツール呼び出しの分離を含む構造化された OpenAI レスポンスに変換します。

その他の分散の次元

エンコーダーの分離: マルチモーダルモデルにおいて、エンコーダーをパイプラインの他の部分から分離するために使用されます。
AFD プラグイン: Mixture-of-Experts (MoE) モデルにおいて、アテンションとフィードフォワードネットワーク（FFN）を分割します。
ハイブリッド SSM: ハイブリッド SSM モデルのための Mamba 状態転送をサポートします。

パフォーマンスへの影響：Goodput とレイテンシ

分散推論は、ピーク時の生のスループットではなく、TTFT と ITL の両方の目標を達成しながら持続可能なリクエストレートである「Goodput」の向上に焦点を当てています。

テールレイテンシの削減

コロケーション（同一ノード）での推論では、長いプリフィルリクエストが同じ GPU 上のすべての同時デコードストリームを停滞させ、p99 ITL のスパイクを引き起こす可能性があります。分散セットアップでは、デコードインスタンスはデコードバッチのみを実行するため、プリフィルに起因する停滞が排除されます。

2 つの NVIDIA L40S GPU 上で 8k トークンのプロンプトを使用して Qwen2.5-7B-Instruct をテストした際、コロケーション環境では 0.4 req/s で p99 ITL が 23 ms から 169 ms に跳ね上がりましたが、分散（P/D）セットアップでは p99 ITL は 25 ms から 52 ms の間に収まりました。

Goodput の向上

これらの利点を得るには、高速な KV 転送が不可欠です。Qwen3-235B-A22B-FP8 を使用した AMD の MoRI-IO ベンチマークでは、分散モードでリクエストの 73% が TTFT（<1s）および ITL（<50ms）の目標を達成しました。これに対し、コロケーションモードでは 30% に留まり、Goodput が 2.4 倍向上しました。

転送のコスト

すべての最初のトークンは、KV キャッシュ転送のレイテンシペナルティを支払います。転送が遅い場合（例：ピアツーピアサポートや RDMA がない場合）、TTFT が増加します。P2P サポートのないハードウェアでは、8k トークンのプロンプトの転送に約 1.3 秒かかり、ITL が安定していてもシステムが TTFT 目標を達成できなくなりました。

運用実装

プリフィル/デコードの実行

vLLM v0.30.0 以降、分散セットアップにはプリフィラー、デコーダー、およびハンドオフを調整するプロキシの 3 つのコンポーネントが必要です。

プリフィラー: 特定の kv_connector（例：NIXL）を使用して kv_producer として構成します。
デコーダー: kv_consumer として構成します。
プロキシ: max_tokens=1 および do_remote_decode: true を指定してプリフィラーを呼び出し、結果として得られた kv_transfer_params をデコーダーに転送します。

マルチターン会話

チャットにおける過去のターンの KV キャッシュを再計算しないようにするため、vLLM は bidirectional_kv_xfer をサポートしています。これにより、プリフィラーはデコーダーから既存のブロックをプルバックし、プロンプト内の新しいトークンのみを計算できます。

レンダリング層のデプロイ

レンダリング層はステートレスであり、標準的な CPU Web サービスとしてスケーリングします。出力の不一致を避けるため、レンダリング、デレンダリング、およびエンジン層全体でモデル、トークナイザー、およびパーサーの構成を同期させることが重要です。

現在の制限事項と今後の課題

ストリーミングパーサーのオーバーヘッド: パーサーを使用したストリーミングデレンダリングは、現在、チャンクごとにパーサーを再構築し、トークンの履歴をリプレイするため計算コストが高く、長い生成に対して $O(n^3)$ の文字処理が発生します。これに対処するためのキャッシュ層が計画されています。
通信オーバーヘッド: ストリーミングデレンダリング中にチャンクごとに prompt_token_ids が再送されるため、長いプロンプトがリクエストボディを占有します。
正確性のギャップ: バッチデレンダリングにおける finish_reason: "tool_calls" や、logprobs に対して整数トークン ID の代わりにプレースホルダー文字列が返される問題などに対処が進められています。

推奨事項まとめ表

状況	推奨事項
負荷時に ITL p99 が SLO を満たせない	分散させる
高並列で長いプロンプトを扱う	分散させる（KV 転送が高速な場合）
コンテキストが増大するチャット/エージェントループ	双方向転送で分散させる
GPU CPU プロファイルでトークナイズ/パース負荷が高い	レンダリング層を分離する
TTFT が制約条件である	コロケーションを維持するか、まず測定する
KV 転送が遅い	転送を修正するか、コロケーションを維持する
トラフィックが低く、バースト的、またはレイテンシに寛容	コロケーションを維持する