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は欠かせない要素の一つとなっている。
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 |
まぁなんだかんだ言っても現実的にはやっぱり緑が最強だね。今はまだ。
機能・モデルサポートの進行状況（主要なもの抜粋）
| 機能/モデルカテゴリ | ステータス | 備考 |
|---|---|---|
| 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