vLLM Prefill/Decode分離の評価設計
CHATGPT / AIChatGPTなどの生成AIを活用して運営・記事制作・更新を行っています。制作方針
vLLMの分離型Prefill/Decodeを導入判断するために、version、GPU、network、KV transferを固定し、TTFT、ITL、tail ITL、throughputを混同せず測る比較計画を解説します。
先に結論
Prefill/Decode分離の採用判断は、単一構成と比較してTTFT、ITL、tail ITL、KV transfer、error率を別々に見ることから始まります。vLLMの公式feature noteは、分離によりTTFTとITLを別のparallel strategyで調整でき、tail ITLを管理しやすいと説明する一方、分離型Prefill自体はthroughputを改善しないと明記します。したがって、throughputだけが課題なら分離を前提にせず、queue、batching、model、hardwareを含めて比較します。
確認日時: 2026年8月7日（Asia/Tokyo）
対象version: vLLM v0.23.0 release（2026年6月15日公開、commit0fc695f）をrelease基準に確認。実装手順は現行Disaggregated Serving exampleを参照。
検証区分: 公式仕様を基にした机上調査・測定計画。本稿に実測値、benchmark結果、実行logはありません。
適用外: connectorごとの対応platform、model品質、実運用のcapacity、NIXL・Mooncake等の依存関係、security review
固定する条件と変える条件を分離する
評価対象を「単一vLLM instance」と「Prefill群＋Decode群＋KV transfer connector＋proxy」の2構成に限定します。比較の途中でmodel、quantization、tokenizer、request内容まで変えると、分離の効果を判定できません。
| 区分 | 固定するもの | 変えてよいもの | 記録する観測値 |
|---|---|---|---|
| software | vLLM version・commit、CUDA、driver、connector版 | 構成の役割 | 起動error、connector error、設定差分 |
| model | repository revision、tokenizer、dtype、max model len | なし | model ID、hash、load時間 |
| hardware | GPU種別・枚数、GPU memory上限、CPU、network経路 | P/DへのGPU配分、TP/PP | VRAM、CPU、network転送、queue |
| workload | prompt token分布、output上限、temperature、concurrency、到着間隔 | prompt長・output長・concurrencyを1軸ずつ | TTFT、ITL、tail ITL、完了率 |
| routing | endpoint、timeout、retry方針、proxy version | P/D instance数 | request ID、KV transfer時間、retry理由 |
vLLMの現行exampleには、2 Prefill instanceと2 Decode instanceをproxyへ渡すXpYdの例があります。これは役割を分けたmultiple instance構成の例であり、2対2が最適な比率という根拠ではありません。台数比を変える試験は、同じ総GPU数と同じrequest群を固定して別runにします。
測定を四つの時間に分ける
client側の終了時間だけでは、Prefillが遅いのか、KV transferで待ったのか、Decodeが詰まったのかを区別できません。request IDを共通キーにし、次の時刻を収集します。
| 指標 | 定義 | 分離型で確認する理由 |
|---|---|---|
| TTFT | client送信から最初のtoken受信まで | prompt処理とqueueを含む入口の体験を測る |
| ITL | token間隔 | stream中の滑らかさを測る |
| tail ITL | 例: 各requestの高percentile ITL | Prefillの混在で起きる長い間隔を見落とさない |
| KV transfer時間 | Prefill完了からDecodeが必要なKVを受け取るまで | network・connectorが新しい律速になっていないか確認する |
| throughput | 完了tokenまたはrequestの単位時間あたり | 分離を自動的な増加要因と誤解しないため別列にする |
percentileの算出方法、warm-up除外、clock同期、stream eventの欠落時の扱いをrun前に決めます。TTFTとITLはclientが観測し、KV transferとworker queueはserver側の同じrequest IDへ結び付けます。server間で時計が揃っていない場合は、絶対時刻の差ではなく、同一process内のintervalとevent順序を主に使います。
比較手順
1. 単一構成の基準を作る
同じmodel revisionとrequest corpusで、単一instanceのTTFT、ITL、tail ITL、throughput、error率を測ります。chunked prefillを比較対象にする場合は、chunk size以外の条件を固定し、分離型とは別のrowにします。公式feature noteも、適切なchunk sizeのchunked prefillでtail ITLを扱えると説明しています。
2. 分離構成は最小台数から始める
PrefillとDecodeに使うGPU、TP/PP、connector、proxyを明示します。現行exampleのproxyはPrefill endpointとDecode endpointを別々に受けます。まず短い固定requestを低concurrencyで送り、KV transferが成功してDecodeからstreamが完了することを確認します。性能runの前に、endpoint不一致、model不一致、connector例外を除外します。
3. 一度に一変数だけ動かす
次の順序なら原因を追いやすくなります。
- prompt長を短・中・長へ変える
- output上限を短・長へ変える
- concurrencyを増やす
- P/D台数比を変える
- TP/PPとnetwork条件を変える
各runでGPU総数が変わるなら、「同じ資源での比較」と「追加資源を使ったcapacity比較」を分けます。特にP/D分離はKVを渡すため、network帯域、遅延、connectorの待機が測定対象から外せません。
解釈で混同しないトレードオフ
公式feature noteは、PrefillとDecodeを別instanceに置くとTTFTとITLへ別のparallel strategyを割り当てられ、tail ITLを制御しやすくなると説明します。ただしfeatureはexperimentalで変更され得ます。また、production-levelの分離はthird-party connectorに依存する場合があると同資料にあります。
- tail ITLが下がり、TTFTが上がる: 入力処理、queue、KV転送を分けて確認します。Decode専用化だけを成果と決めません。
- TTFTが下がり、error率が上がる: connectorのretryやtimeoutを隠さず、成功requestだけの集計を避けます。
- throughputが変わらない: 公式の注意と整合します。SLOがtail ITLなら有効でも、capacity改善の根拠にはなりません。
- 短いpromptで差がない: 直ちに失敗とは限りません。長いpromptや高concurrencyの運用条件を再現できるかを先に確認します。
採用・非採用の判断基準
分離型を候補に残すのは、対象workloadでtail ITLまたはTTFTのSLOが改善し、KV transferとerror率が許容範囲に収まり、version・connector・network設定を再現でき、rollback時に単一構成へ戻せる場合です。どれかが欠けるなら、単一構成またはchunked prefillを基準に改善します。
初めて概念を確認する場合は、vLLMのPrefill/Decode分離を理解する入門から進めてください。vLLM V1の基本用語と通常のAPI運用は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日確認）
