vLLM は高速な LLM のサービングを行うソフトウェアとして有名だと思っている。
最近、といっても数ヶ月前だと思うが、開発中であった V1 Engine がデフォルトで有効になった。
V1がアルファ版として2025年1月27日に公式ブログで発表されて以来、着実な進歩とコミュニティからのフィードバックを経て成熟してきたことがうかがえる。
ということで、本記事では大規模言語モデル（LLM）の推論を高速化するためのオープンソース標準として広く採用されているであろう vLLM プロジェクトの最新エンジンついて、自分の理解促進も込みで、主に公式のブログやドキュメントを参考に概要をまとめる。
細かなところは割愛しつつ、公式情報や関連技術ブログから、V1エンジンの開発背景・コアアーキテクチャの刷新 (特にマルチモーダル推論能力の飛躍的な向上) そして vLLM V0から V1への移行に伴う主要な変更点（機能強化、仕様変更、非推奨機能）、現時点 (2025年05月18日) でのサポート状況をまとめてみた。
まぁ大概の物事に言えることではあるのですが、公式ドキュメントとソースを読めば思ったより細かいところまでわかるものです。
が、結構日本語でざっくり感が知りたいときにこういう記事探したりするし、頭の整理になるので無駄じゃない。
開発の背景と目標
vLLM V0は多様なモデル、機能、ハードウェアをサポートしているが、新機能が独立して開発されるにつれてシステム全体の複雑性が増し、新たな機能の統合や技術的負債の管理が課題となっていた。
この経験を踏まえ、vLLM V1は V0で実証済みの安定したコンポーネントを継承しつつ、コアシステム（スケジューラ、KV キャッシュマネージャ、ワーカー、サンプラー、API サーバー）を再設計する、というのが V1開発のモチベーションらしい。
その主な目標は以下の通り。
- シンプルでモジュール性が高く、カスタマイズ容易なコードベースの提供
- ほぼゼロのCPUオーバーヘッドによる高性能の実現
- 主要な最適化技術の統一アーキテクチャへの統合
- デフォルトでの機能・最適化有効化による「ゼロコンフィグ」の実現
なるほど、Python 側のコードのみであるが機能追加でちょろっと触ったことがある身としてはウェルカム。
…ただ再学習になっちゃう点はしょうがないかな。
これにより、vLLM は継続的な成長に対応できる、メンテナンス可能なフレームワークを目指している。
特に長文コンテキストのシナリオにおいて V1コアエンジンへのアップグレードによる大幅なパフォーマンス向上が見られると報告されている。
注目どころ
前述の公式ブログで言及される主要な技術的特徴として8つが挙げられている。
- 最適化された実行ループと API サーバー (Optimized Execution Loop & API Server):
CPU 処理および GPU 処理のオーバーラップを最大化するため、API サーバーとモデル実行コア (EngineCore) を分離し、CPU オーバーヘッドを削減する。 - シンプルかつ柔軟なスケジューラ (Simple & Flexible Scheduler):
従来の「prefill」と「decode」フェーズの区別をなくし、プロンプトトークンと生成トークンを統一的に扱うことで、チャンク化 prefill やプレフィックスキャッシュなどを柔軟にサポートする。 - ゼロオーバーヘッド・プレフィックスキャッシュ (Zero-Overhead Prefix Caching):
データ構造の最適化により、プレフィックスキャッシュ有効時の CPU オーバーヘッドをほぼゼロにし、キャッシュヒット率が低い場合でも性能低下を最小限に抑制（デフォルトで有効）。 - テンソル並列推論のためのクリーンなアーキテクチャ (Clean Architecture for Tensor-Parallel Inference):
ワーカー間でリクエスト状態の差分のみを通信することでプロセス間通信を最小化し、よりシンプルで対称的な分散推論アーキテクチャを実現する。 - 効果的な入力準備 (Efficient Input Preparation):
Persistent Batch 技術を導入し、各ステップでの入力テンソル再作成を避け、差分更新と Numpy 操作の活用により CPU オーバーヘッドを削減する。 -
torch.compileとpiecewise CUDA graphs:
torch.compileを統合してモデルを自動的に最適化し、さらにpiecewise CUDA graphsを導入することで従来の CUDA Graphs の制約を緩和し、適用範囲を拡大する。 - マルチモーダル LLM サポートの強化 (Enhanced Support for Multimodal LLMs):
マルチモーダル入力の前処理をノンブロッキング化・キャッシュ対応、画像ハッシュ等も用いたプレフィックスキャッシュ、エンコーダキャッシュによるチャンク化 prefill などを実現する。 - FlashAttention 3 の統合:
V1エンジンの動的な処理（prefill と decode の混在バッチなど）に対応するため、柔軟かつ高性能なアテンションカーネルとして FlashAttention 3を採用する。
V0ではオプションであった Prefix Caching と Chunked Prefill がデフォルト動作になったといっていいはず。
わかりやすい実装、変化としては以下の3つだろうか。
PyTorch及びCUDA Graph利用の最適化
V1では torch.compile の統合によりモデルを自動的に最適化し、カスタムカーネルの作成の必要性を最小限に抑えているらしい。
vLLM V1におけるマルチモーダル推論の進化
現代の LLM はテキストだけでなく、画像、音声、動画といった多様なモダリティを扱う能力が求められる。というかものすごい勢いで当たり前になってきた。
これらのマルチモーダルモデルは一般的に、テキスト処理用のデコーダ LM バックボーンと、非テキストモダリティ用の専用エンコーダを組み合わせた構造を持つ。
vLLM V0でもマルチモーダルの基礎はあったが、いくつかの課題が存在したとのこと。
例えばテキストで <image> などの特殊トークンで表される部分は他のテキスト系列でも同じトークンとなるため、相互に干渉しあってうまい感じで処理できなかったらしい。
vLLM V1では、これらの課題を克服するために以下の機能が導入されている。
- エンコーダキャッシュとエンコーダ対応スケジューラ (Encoder cache and encoder-aware scheduler):
一度計算されたマルチモーダルエンベディングを GPU メモリ上に直接キャッシュし、再計算を防ぐ。 - メタデータによる強化されたプレフィックスキャッシュ (Enhanced prefix caching with metadata):
トークン ID に加え、画像や音声チャンクのハッシュといったメタデータをキャッシュキーに組み込み、キャッシュの衝突を防ぐ。 - 最適化されたマルチモーダルデータ処理 (Optimized multimodal data processing):
生データからテンソルへの変換といった CPU 負荷の高い処理を GPU 処理と非同期化し、GPU の待機時間を削減する。 - マルチモーダル特徴量キャッシュ (Multimodal feature caching):
生データの変換処理自体をキャッシュし、冗長な変換をスキップすることでスループットを向上させる。
これらの改善により、vLLM V1はマルチモーダル推論の性能を向上したとのこと。
なので、よほど旧来のエンジンでしかサポートされない機能が重要でない限りは、デフォルトになった V1を使っていくのがいいんだと思う。
FlashAttention 3
FlashAttention 3は、有名な FlashAttention および FlashAttention 2のさらなる進化版で、特に最新の GPU アーキテクチャ（例えば NVIDIA Hopper など）の特性を最大限に活用するように設計されている模様。
Tensor Core と TMA（Tensor Memory Accelerator）の非同期性を利用して計算とデータ移動をオーバーラップさせる、ブロックワイズ行列乗算とソフトマックス操作をインターリーブする、FP8のような低精度計算のためのハードウェアサポートを活用するといった新しい技術を導入し、さらなる速度向上と精度維持を目指しているらしい。
以下でも、FlashAttention 2と比較して FP16で約1.6倍から2.0倍の高速化を達成したと報告されている。
vLLM V1の文脈では、FlashAttention 3は、特に「prefill と decode の混在バッチ」といった動的なワークロードに対応するための重要なコンポーネントとして採用されたとの記載がある。
vLLM V1は、リクエストを効率的にバッチ処理し、GPU 使用率を最大化するために、様々な長さや状態（初回処理の prefill、トークン生成中の decode）のリクエストを柔軟に組み合わせる。
このような動的で複雑な状況下でも、FlashAttention 3の持つ高い計算効率と柔軟性が、アテンション計算のボトルネック化を防ぎ、システム全体のパフォーマンスを維持・向上させるそうだ。
つまり、vLLM V1の目指す高いスループットと低いレイテンシを実現する上で、FlashAttention 3は欠かせない要素の1つとなっている。
V0からV1への主要な変更点：機能強化・仕様変更・非推奨機能
vLLM V0から V1への移行はメリットがある一方で、いくつかの重要な変更点を理解しておく必要がある。
以下の表は、主に前述の vLLM V1 User Guide の情報を基に、V0からの主要な変更点をまとめたもの。
V1で強化・最適化された主な機能
| 機能名 | V0での状況/課題 | V1での変更/改善点 (ステータス) | 補足説明 |
|---|---|---|---|
| Prefix Caching | CPUオーバーヘッドが大きく、低ヒット率で性能低下の可能性あり、デフォルト無効 | ゼロオーバーヘッドに改善、デフォルト有効 (Optimized) | 過去に処理したプロンプト共通部分の計算結果を再利用し高速化。 |
| Chunked Prefill | マルチモーダルエンベディングとの相性が課題 | 新統一スケジューラにより効率的・柔軟に実装 (Optimized) | 長いプロンプトを分割処理しメモリ効率と応答性向上。 |
| LoRAサポート | 機能的には問題なく対応 | サポートを最適化 (Optimized) | LoRAを推論時に効率的に適用。 |
| Multimodal Models サポート | 前処理のブロッキング、キャッシュ衝突などの課題 | エンコーダキャッシュ、メタデータ付きプレフィックスキャッシュ、非同期データ処理等で大幅改善 (Functional) | テキスト以外の多様なデータ（画像、音声等）を扱うLLMのサポート。 |
| FP8 KV Cache | 未サポート | Hopperデバイスでサポート (Functional) | KVキャッシュを8ビット浮動小数点数で保存しメモリ効率向上。 |
V1におけるLogprobsの計算方法と意味の主な変更点
| 項目 | V1での仕様・状況 | 補足説明 |
|---|---|---|
| Logprobsの計算 | 生のロジットから直接計算（サンプリング後処理が適用される前の値）。 | モデルが次に出力する各トークンの「もっともらしさ」。V1ではサンプリング調整前の値が返る。 |
| Prompt Logprobs と Prefix Caching の互換性 | Prefix Caching有効時（デフォルト）は現在未サポート。将来対応予定だが、再計算の可能性あり（RFC #13414 参照）。 |
V1で非推奨（Deprecated）となった主なV0機能
| 機能カテゴリ | 機能名 | V0での主な用途 | V1での状況 |
|---|---|---|---|
| サンプリング関連 | best_of | 複数候補から最良を選択するサンプリング手法 | 利用僅少のため非推奨 (Deprecated) |
| Per-Request Logits Processors | リクエスト単位でのロジット調整機能 | 非推奨、グローバルロジットプロセッサへ移行方針 (Deprecated) | |
| KVキャッシュ関連 | GPU <> CPU KV Cache Swapping | GPUメモリ逼迫時のKVキャッシュ退避機構 | V1新コアアーキテクチャで不要となり非推奨 (Deprecated) |
| 構造化出力 | Request-level Structured Output Backend | 特定構造（JSON等）でのLLM出力強制機能の一実装 | 非推奨、代替バックエンド (outlines, guidanceなど) がWIP (Deprecated) |
パフォーマンス向上
V1エンジンは V0と比較して最大1.7倍のスループット向上を達成したと報告されている（前述の公式ブログ参照）。
また、マルチモーダルモデルにおける V1の顕著な性能向上も報告されており、例えば Qwen2-VL のオンラインサービングでは高 QPS 環境下で V0や他のオープンソース代替と比較して低いレイテンシを達成し、Molmo-72B のオフライン推論ではキャッシュなしでも V0に対し約40％の性能向上、キャッシュ有効時にはさらに劇的なスループット改善が見られたとされている（前述の Red Hat ブログ記事参照）。
これらの結果は、V1のアーキテクチャ改善とマルチモーダル特化の最適化が実環境での性能向上に大きく貢献していることを示している。
最新のサポート状況と今後の作業
vLLM V1のサポート状況は常に更新されている（前述の vLLM V1 User Guide 参照）。
ハードウェアサポート
| ハードウェア | ステータス |
|---|---|
| NVIDIA | ネイティブサポート |
| AMD | WIP |
| TPU | WIP |
まぁなんだかんだ言っても現実的にはやっぱり緑色の GPU が主要だね。今はまだ。
機能・モデルサポートの進行状況（主要なもの抜粋）
| 機能/モデルカテゴリ | ステータス | 備考 |
|---|---|---|
| Speculative Decoding | WIP | ngramベースのみサポート。Eagle, MTPなど優先対応 |
| Multimodal Models (インターリーブ入力) | WIP | |
| Structured Output Alternative Backends | Planned | outlines, guidanceなど |
| Embedding Models | Planned | 同一エンジンでの生成・埋め込み同時利用目指す |
| Mamba Models | Planned | MambaForCausalLM, JambaForCausalLMなど |
| Encoder-Decoder Models | Planned | BartForConditionalGenerationなど |
完全なリストは公式ドキュメントのサポートモデル一覧を参照のこと。
まとめ
公式ブログを中心にざっくりと状況をまとめてみた。
vLLM V1は、コアアーキテクチャの抜本的な刷新、特にマルチモーダル推論能力の大幅な強化、そして多数の最適化を行った最初のメジャーアップデートのはず。
できれば赤や青の陣営でも容易に使えるようになると個人利用でも幅が広がるから期待したいところ。
それと、今回はまったくコードを追わなかったので、時間があれば具体的にどんなコードになったのかを追っていきたい。
Discussion