vLLM V1エンジン入門：prefix caching・chunked prefill・speculative decoding

V1を一言でいうと

vLLM V1は、prefillとdecodeを一つのtoken budgetで扱うunified schedulerを中心に、prefix caching、chunked prefill、LoRA、speculative decodingなどを統合した実行基盤です。v0.25.0ではMRv2もdenseモデルの標準となり、新世代の実行経路が中心になりました。

prefillとdecode

LLM推論は大きく2段階に分かれます。

• prefill: 入力プロンプトをまとめて処理する
• decode: 生成トークンを通常1トークンずつ処理する

長い入力はprefillの計算を占有し、すでに生成中のリクエストを待たせる可能性があります。V1 schedulerは、固定token budgetの範囲で各リクエストの処理量を割り当てます。

chunked prefill

長いprefillを一度に処理せずchunkへ分け、decode中のリクエストと混ぜて実行する仕組みです。長文1件がGPUを長時間占有する問題を和らげ、inter-token latencyとのバランスを取りやすくします。

ただしchunkを細かくすれば常に速いわけではありません。バッチ効率、モデル構造、GPU、入力長の分布によって最適点が変わります。

automatic prefix caching

複数リクエストが同じ先頭部分を持つとき、そのprefixのKV cacheを再利用します。長いsystem prompt、共通ドキュメント、同じ会話履歴から枝分かれする処理に有効です。

共通system prompt + 共通資料 + 質問A
共通system prompt + 共通資料 + 質問B
^^^^^^^^^^^^^^^^^^^^^^^^^^ 再利用候補

prefixが少しでも途中で変わると、その先はcache hitになりません。日時やrequest IDをsystem promptの先頭へ毎回埋め込む設計は、cache効率を下げます。固定部分を前、可変部分を後ろへ置くのが基本です。

speculative decoding

小さなdraft modelや専用drafterが複数トークンを候補として提案し、target modelがまとめて検証します。受理率が高ければ、target modelを1トークンずつ呼ぶより生成を速められます。

効きやすい条件	効きにくい条件
draftとtargetの予測が近い	受理率が低い
decodeがボトルネック	prefill中心の処理
追加メモリに余裕がある	draftでOOMやbatch縮小が起きる
同条件で回帰試験済み	量子化・hybrid modelとの未確認組み合わせ

高速化機能同士を足せば必ず相乗効果が出るわけではありません。KV cache量子化、MTP、DFlashなどはモデルとバージョンごとに互換性を確認します。

KV cacheとメモリ

同時リクエストとcontextが増えるほどKV cacheが増えます。vLLMはブロック管理、prefix再利用、offloadなどで効率化しますが、物理メモリの上限はなくなりません。最大contextより、入力長のp50・p95・最大値と同時実行数から容量を決めます。

測定すべき4指標

• TTFT: リクエストから最初のトークンまで
• TPOT: 生成中の1トークン当たり時間
• request throughput: 1秒当たり処理リクエスト
• token throughput: 1秒当たり入出力トークン

vllm bench serve \
  --backend openai-chat \
  --base-url http://127.0.0.1:8000 \
  --model YOUR_MODEL \
  --dataset-name random \
  --num-prompts 500 \
  --request-rate 4

平均だけでなくp95・p99を見ます。prefix cachingの比較では、同じprefixを持つデータセットと、持たないデータセットを分けます。

導入順序

1. 最適化を足さず単一モデルで正しさを確認
2. 実際の長さ分布でbaselineを保存
3. prefix cachingまたはchunked prefillを一つずつ比較
4. decodeが支配的ならspeculative decodingを試す
5. 出力品質、OOM、tail latencyを含めて採用判断

V0からの注意

V1では一部の古い挙動や設定が廃止・変更されています。公式V1 guideではbest_of、request単位のlogits processor、GPUとCPU間の旧KV cache swappingなどに移行上の注意が示されています。古いブログ記事の引数をそのまま使わず、導入versionのCLI helpを確認してください。

まとめ

V1の強みは、個別の高速化機能ではなく、それらを一つのschedulerとKV cache管理の上で組み合わせる点です。設定値から入るのではなく、自分の入力長・同時実行・共通prefixの比率を測り、ボトルネックに合う機能だけを追加するのが近道です。最新リリースの変更はvLLM v0.25.0解説も参照してください。

公式資料

• vLLM V1 User Guide
• Automatic Prefix Caching
• Speculative Decoding