vLLMのPrefill/Decode分離を理解する入門

先に結論

vLLMの分離型servingは、入力を読むPrefillと、tokenを続けて返すDecodeを別workerに任せ、途中でKV cacheを受け渡す構成です。目的はTTFT（最初のtokenまでの時間）とITL（token間の時間）を別々に調整し、tail ITLを管理しやすくすることです。単にrequest/sを増やす機能ではないため、単一serverで困っている指標を先に決めてから検討します。

確認日時: 2026年8月7日（Asia/Tokyo）
対象: vLLM v0.23.0 release、現行のDisaggregated Serving example、Disaggregated Prefilling feature note
検証区分: 公式資料を照合した机上調査・読解手順。本稿の制作環境ではvLLM、GPU、複数node、connectorを実行していません。
適用外: この構成の性能値、対応model、NIXL・Mooncake等connectorの依存版、network security、production SLOの保証

まず二つの仕事を分ける

LLM serverは、prompt全体を一度に処理して最初のtokenを準備するPrefillと、その後に1 tokenずつ生成するDecodeを行います。分離型ではPrefill workerが作ったKV cacheをconnectorでDecode workerへ移し、Decode workerがclientへstreamを返します。KV cacheは、すでに読んだtokenの内部状態を再利用するためのデータです。

この分け方が必要になるのは、長い入力が来るときにDecode中のrequestへPrefill処理が混ざり、token間の待ち時間が伸びる状況です。公式feature noteは、PrefillとDecodeを別vLLM instanceにしてtensor parallelやpipeline parallelを個別に選べること、tail ITLを扱いやすくすることを説明しています。一方で、分離型Prefill自体はthroughputを改善しないと明記されています。

最初は「速くなるか」ではなく、次の言葉を区別してください。

TTFT: request送信から最初のtokenが返るまでの時間
ITL: 連続するtokenの間隔。長い間隔がtail ITLです
KV transfer: Prefillが作った状態をDecodeへ渡す時間と失敗の有無

公式demoを読む前の前提確認

公式の現行exampleには、複数のPrefillとDecode instanceを受けるproxy demoがあります。exampleのX prefill / Y decodeは、workerを増やすための構成例であって、手元のPCでそのまま動かすべき最短設定ではありません。

始める前に、次を同じrun sheetへ書き出します。

使用するvLLMのversionとcommit、model revision、tokenizerを固定する
Prefill側・Decode側に使うGPU、GPU memory上限、tensor parallel数、network経路を分けて記録する
KV transfer connectorとその設定を公式資料の対象versionで確認する
proxyが向けるPrefill endpointとDecode endpointを、許可したprivate network内だけに限定する
単一serverで同じmodel・同じrequestを動かす基準値を先に保存する

vLLM v0.23.0は2026年6月15日に公開されたreleaseです。今回の構成は変更が速いため、古いfeature noteの概念をcommandの根拠にせず、実行時は現行exampleとinstalled versionのhelpを照合してください。

最短の成功確認：demoを「起動」ではなく「接続」で読む

安全な複数GPU環境がある場合だけ、公式repositoryのexampleをcheckoutしたversionで読みます。現行exampleのproxyは、次のように複数endpointを受け取る構成です。

python3 examples/disaggregated/disaggregated_serving/disagg_proxy_demo.py \
  --model "$MODEL_NAME" \
  --prefill localhost:8100 localhost:8101 \
  --decode localhost:8200 localhost:8201 \
  --port 8000

このcommandだけでは成功しません。先に、対応connectorを設定したPrefill workerとDecode workerがそれぞれ起動し、proxyが参照するmodelとendpointが一致している必要があります。外部へportを公開せず、検証用network内で次の順に確認します。

各workerのmodel endpointが同じmodel IDを返すか確認する
proxyがPrefillとDecodeの両方を登録できるか確認する
固定した短いpromptを1件だけ送り、最初のtokenとstream完了を別々に記録する
connectorのerror、KV transferの待機、request IDの対応を確認する

成功条件は「応答が出た」だけではありません。同じrequestがPrefillからDecodeへ渡り、proxy経由で応答が完了し、KV transfer errorがないことです。出力内容や速度はmodel、GPU、network、loadで変わるため、ここでは架空のlogや時間を示しません。

つまずきやすい点と単一構成への戻し方

endpointはあるのに応答が返らない

PrefillとDecodeのendpoint、model名、connectorの接続情報を1項目ずつ照合します。proxyだけを先に疑ってportを外部公開しないでください。KV transferで待機している可能性があるため、request IDを共通にしてworker側のlogを確認します。

ITLが改善しない、または悪化する

分離型の目的はTTFTとITLの個別調整であり、throughputの自動改善ではありません。network転送、GPU割当、prompt長、同時requestを同時に変えず、まず単一serverの基準へ戻します。chunked prefillもtail ITLを扱う選択肢なので、同じSLOで比較します。

connectorの説明とinstalled versionが合わない

featureはexperimentalで変更されることがあります。web上の古いsnippetを継ぎ合わせず、使用versionのrelease note、official example、vllm serve —helpへ戻ります。connector名だけを別versionの設定へ流用しません。

次に進む条件

単一serverと分離型で同じmodel revision、request群、concurrency、prompt/output長を固定し、TTFT、中央値ITL、tail ITL、KV transfer時間、error率を別の列へ記録できれば、設計比較に進めます。測定条件と適用範囲は、vLLM Prefill/Decode分離の評価設計で確認してください。vLLM V1の基本運用はvLLM V1入門も参照できます。

参考資料

vLLM公式：Disaggregated Serving example（2026年8月7日確認）
vLLM公式：Disaggregated Prefilling（experimental）（2026年8月7日確認）
vLLM公式repository：v0.23.0 Release Notes（2026年6月15日公開、2026年8月7日確認）