vLLM（ブイエルエルエム）
vLLMは、UC Berkeleyで開発されたオープンソースのLLM推論・サービングエンジン。PagedAttentionによるKVキャッシュの効率的管理とContinuous Batching（連続バッチング）を中核技術とし、従来のHugging Face Transformersと比較して3〜24倍のスループット向上を実現する。OpenAI互換APIを標準提供し、本番環境での採用実績が最も多い推論エンジンの一つ。
vLLMとは
vLLM（Virtual Large Language Model）は、2023年にUC BerkeleyのSky Computing Labが発表したオープンソースのLLM推論エンジンである。論文「Efficient Memory Management for Large Language Model Serving with PagedAttention」（SOSP 2023）で提案されたPagedAttention技術を実装し、LLM推論におけるGPUメモリ利用効率を革命的に改善した。2026年現在、GitHub Stars 50,000超、月間PyPIダウンロード数300万以上を記録し、LLM推論エンジンのデファクトスタンダードとなっている。
vLLMの核心的な貢献は、KVキャッシュのメモリ管理にOS仮想メモリのページングメカニズムを導入したことにある。従来のLLM推論では、各リクエストに対して最大シーケンス長分のKVキャッシュメモリを連続領域で事前確保していた。実際に使用されるのはその一部であり、残りは「内部断片化」として浪費される。PagedAttentionはKVキャッシュを固定サイズのブロック（デフォルト16トークン分）に分割し、必要に応じて非連続メモリ領域に動的確保する。これにより、メモリ無駄が従来の60〜80%から5%未満に削減される。
PagedAttentionの技術詳細
PagedAttentionのアーキテクチャは以下の3層で構成される。
ブロックテーブル（Block Table）
各リクエスト（シーケンス）のKVキャッシュがどの物理ブロックに格納されているかを管理するマッピングテーブル。OSのページテーブルに相当する。論理ブロック番号から物理ブロック番号への変換をO(1)で行い、Attentionカーネル内でブロック単位のギャザー（gather）操作を実行する。
ブロックマネージャ（Block Manager）
空きブロックのプール管理、ブロックの割り当て・解放、Copy-on-Write（CoW）によるブロック共有を担当する。Beam Searchや並列サンプリングにおいて、同一プレフィックスのKVキャッシュを複数シーケンスで物理的に共有し、メモリコピーを回避する。CoWにより、共有ブロックへの書き込みが発生した時点で初めてコピーが行われる。
PagedAttentionカーネル
CUDAカーネルレベルでブロック単位のAttention計算を実装。FlashAttention-2のタイル化（tiling）戦略をベースに、非連続メモリレイアウトに対応したギャザー操作を統合している。FP16/BF16に加え、FP8（Hopper以降）・INT8量子化にも対応し、量子化推論時のメモリ効率をさらに向上させる。
| 項目 | 従来方式 | PagedAttention |
|---|---|---|
| メモリ確保 | 連続領域、最大長分事前確保 | 非連続ブロック、動的確保 |
| 内部断片化 | 60〜80% | 5%未満 |
| 外部断片化 | 発生しやすい | ブロック単位で回避 |
| シーケンス間共有 | 不可（フルコピー） | CoWで物理共有 |
| 同時処理数（A100 80GB, 13B FP16） | 8〜16リクエスト | 40〜80リクエスト |
Continuous Batching（連続バッチング）
vLLMのもう一つの中核技術がContinuous Batching（Iteration-Level Scheduling）である。
Static Batchingとの比較
従来のStatic Batchingでは、バッチ内の全リクエストが生成完了するまで新リクエストを投入できない。生成長が短いリクエストが先に完了してもGPUはアイドル状態となり、バッチ全体の平均利用率が低下する。これはPadding Wastageと呼ばれ、入力長・出力長の分散が大きいほど深刻になる。
Continuous Batchingでは、イテレーション（1トークン生成）単位でスケジューリングを行う。あるリクエストがEOSトークンを生成した瞬間、そのスロットを即座に次の待機リクエストに割り当てる。これにより、GPU利用率は95%以上を維持でき、Static Batchingと比較して2〜5倍のスループット向上を実現する。
プリエンプション（Preemption）
GPUメモリが逼迫した場合、vLLMは優先度の低いリクエストのKVキャッシュをCPUメモリに退避（swap out）し、優先度の高いリクエストにGPUメモリを割り当てる。退避されたリクエストは後で復帰（swap in）し、中断地点から生成を再開する。これにより、メモリ不足によるリクエスト拒否（OOM）を回避しつつ、QoS（Quality of Service）を維持する。
主要機能と設定
OpenAI互換APIサーバー
vLLMは/v1/completions・/v1/chat/completions・/v1/embeddingsエンドポイントを提供し、OpenAI SDKからそのまま接続できる。--api-keyオプションで認証トークンを設定可能。
# 起動例（FP16、テンソル並列4）
python -m vllm.entrypoints.openai.api_server \
--model meta-llama/Llama-3.1-70B-Instruct \
--tensor-parallel-size 4 \
--dtype float16 \
--max-model-len 8192 \
--port 8000
量子化サポート
| 量子化方式 | ビット幅 | 精度劣化 | メモリ削減率 | 備考 |
|---|---|---|---|---|
| AWQ | 4bit | 低 | 約75% | 活性化認識量子化、精度維持が良好 |
| GPTQ | 4bit | 低〜中 | 約75% | 後処理量子化の標準 |
| FP8 | 8bit | 極低 | 約50% | Hopper/Ada以降のHWサポート |
| SqueezeLLM | 3〜4bit | 中 | 約80% | 非均一量子化 |
| Marlin | 4bit | 低 | 約75% | GPTQ互換の高速推論カーネル |
LoRA Serving
vLLMはLoRA（Low-Rank Adaptation）アダプタの動的ロード・アンロードをサポートする。ベースモデルを1つロードし、リクエストごとに異なるLoRAアダプタを適用できるため、マルチテナント環境で大幅なメモリ節約を実現する。--enable-lora --max-loras 8で最大8つのLoRAを同時保持可能。
よくある質問（FAQ）
Q1: vLLMの起動に必要な最小スペックは？
7Bモデル（FP16）で約14GB VRAMが必要。NVIDIA RTX 4090（24GB）なら13Bモデルまで対応。AWQ 4bit量子化を使えば、RTX 3060 12GBでも7Bモデルが動作する。CPU RAMはモデルロード時に一時的にVRAMと同量が必要。
Q2: vLLMはAMD GPUでも動作しますか？
動作する。ROCm 6.x以降のAMD Instinct MI250/MI300シリーズで公式サポートされている。ただしCUDA版と比較してFlashAttentionカーネルの最適化が遅れており、同等GPUスペックでもスループットは15〜25%低い傾向がある。コミュニティによる改善が進行中。
Q3: vLLMとSGLangはどう使い分けますか？
汎用的なLLMサービングにはvLLM、構造化出力（JSON Schema準拠の出力強制）や複雑なプロンプトパイプラインにはSGLangが適している。SGLangのRadixAttentionはプレフィックスキャッシュに特化しており、同一プレフィックスの大量リクエスト（バッチ評価、Few-Shot推論）で特に高い性能を示す。両者ともOpenAI互換APIを提供するため、アプリケーション側の変更は最小限で切り替え可能。