vLLM Prefill-Decode の MORI-IO による分散化

vLLM はシングルノード展開向けに Prefill-Decode (PD) 分散化を導入し、8 GPU AMD Instinct MI300X ノードでスループットを 2.5 倍に向上させました。計算に依存する Prefill フェーズとメモリ帯域幅に依存する Decode フェーズを分離することで、これらのワークロードが同じ GPU リソースを争う際に通常発生する Inter-Token Latency (ITL) のスパイクを排除します。

同時配置サービングのボトルネック

標準的なモノリシック展開では、Prefill と Decode のワークロードが同じ GPU リソースとスケジューラを共有します。Prefill は大規模な GEMM を用いてプロンプト全体を並列処理するため、計算に依存し、単一の Decode ステップよりもはるかに時間がかかります。Prefill リクエストがバッチに入ると、すべての進行中の Decode ストリームがブロックされ、Inter-Token Latency (ITL) の予測不可能なスパイクが発生します。

シングルノード PD 分散化アーキテクチャ

一般的に分散化はマルチノードクラスターが必要と考えられていますが、vLLM は単一の 8 GPU ノード内でこのアーキテクチャを実装しています。システムは以下の 3 つのコンポーネントからなるマイクロサービスアーキテクチャへと移行します:

• Prefill Instance: 入力プロンプトを処理し KV キャッシュを生成します（例: GPU 0–3 を使用）。
• Decode Instance: 転送された KV キャッシュを使用して出力トークンを生成します（例: GPU 4–7 を使用）。
• Proxy Server: エントリーポイントとして機能し、リクエストをまず Prefill Instance に、次に Decode Instance にルーティングします。

これらのインスタンス間でギガバイト規模の KV キャッシュデータを転送できるように、vLLM はオープンソースの MORI (Modular RDMA Interface) フレームワーク上に構築された RDMA ベースの KV キャッシュコネクタ MORI-IO を利用しています。

KV キャッシュ転送モード: 読み取り vs 書き込み

MORI-IO は 2 つの異なる転送モードをサポートしており、VLLM_MORIIO_CONNECTOR_READ_MODE 環境変数で設定します:

読み取りモード (VLLM_MORIIO_CONNECTOR_READ_MODE=1)

Read Mode では、プロキシがリクエストをシリアルにディスパッチします。Prefill Instance が完了し remote_block_ids を返すのを待ってから、リクエストを Decode Instance に転送します。Decode Instance はその後、RDMA を介して Prefill Instance のメモリから KV キャッシュを取得します。

書き込みモード（デフォルト）

Write Mode（デフォルト）では、プロキシがリクエストを Prefill Instance と Decode Instance の両方に同時にディスパッチします。Prefill Instance が各層を計算するたびに、KV データを RDMA WRITE を用いて Decode Instance の事前割り当てメモリに直接プッシュします。これによりプロキシのシリアライズオーバーヘッドが排除され、Decode キューの待ち時間が Prefill 計算と重複します。

プロパティ	読み取りモード	書き込みモード
RDMA の方向	Decode が Prefill から取得	Prefill が Decode にプッシュ
プロキシのディスパッチ	シリアル（Prefill 待ち → Decode ディスパッチ）	同時（Prefill と Decode が並行）
ブロック ID 中継	プロキシ経由で必要	不要
KV クリーンアップ	Decode が Prefill にブロック解放を通知	Prefill が書き込み完了を追跡

パフォーマンス結果とスループット

8 GPU MI300X ノード上で Qwen3-235B-A22B-FP8 モデル（2000 トークンのプロンプト、1000 トークンの出力）を使用し、vLLM は goodput を用いてパフォーマンスを測定しました。goodput とは、リクエストが Time to First Token (TTFT) < 1 秒かつ ITL < 50 ms を満たす最大リクエストレートです。

主な発見

• 2.5 倍の Goodput 増加: Write モードは 8 req/s のレートで 73/100 のリクエストが SLO を満たしたのに対し、標準の TP8 サービングでは 26/100 にとどまりました。
• ITL スパイクの排除: 分散化モードは、Decode エンジンが計算集中的な Prefill ジョブから分離されているため、ITL の違反を完全に排除しました。
• TTFT のトレードオフ: 分散化により RDMA 転送とプロキシのオーバーヘッドが加わるため TTFT が増加します。Write モードはプロキシのシリアライズを排除するため、Read モードよりも TTFT が改善されます。

デプロイと構成

PD 分散化をデプロイするには、vLLM の kv-transfer-config を設定する必要があります。両インスタンスは MoRIIOConnector とそれぞれの役割（Prefill 用は kv_producer、Decode 用は kv_consumer）を指定しなければなりません。

ポート要件

• proxy_ping_port: プロキシへのインスタンス登録用 ZMQ エンドポイント。
• http_port: 推論リクエスト用の vLLM HTTP サーバーポート。
• handshake_port: KV キャッシュレイアウトのメタデータを一度だけ交換するポート。
• notify_port: KV ブロックが準備できたときにリクエストごとの同期シグナルを送るポート。

Use Cases のまとめ

状況	推奨
本番負荷で ITL p99 が SLO を超える	分散化
TTFT が主なボトルネック	標準サービング
長いプロンプトで高い同時実行性	分散化
短いプロンプトで低リクエストレート	標準サービング