vLLM（ブイエルエルエム）

vLLM（Virtual Large Language Model）は、大規模言語モデルの推論サービングに特化したオープンソースフレームワークである。UC Berkeleyの研究チームが2023年に発表し、PagedAttentionと呼ばれる革新的なメモリ管理手法により、従来の推論エンジンと比較して最大24倍のスループット向上を達成した。2026年現在、商用・研究用途を問わず最も広く採用されているLLMサービングソリューションの一つとなっている。

概要

vLLMは、LLMの推論（Inference）フェーズを高速かつ効率的に処理するために設計されたPythonベースのフレームワークである。従来のHugging Face Transformersライブラリによる推論では、KVキャッシュのメモリ断片化が深刻なボトルネックとなっていた。vLLMはこの問題をPagedAttentionで解決し、GPUメモリの利用効率を大幅に改善した。

2024年にはvLLM 0.4系でSpeculative Decodingのネイティブサポート、2025年にはvLLM 0.6系でマルチモーダルモデル対応やAWQ/GPTQ量子化との統合が進み、2026年のvLLM 0.8系ではPrefix Cachingの強化とNVIDIA H200/B200 GPUへの最適化が実装された。GitHub Stars数は45,000を超え、OpenAIのバッチ推論基盤やAnyscaleのRay Serveとの統合でも活用されている。

主な特徴・仕組み

• PagedAttention: OS の仮想メモリページングに着想を得たKVキャッシュ管理。物理メモリを固定サイズブロックに分割し、非連続メモリ割り当てでフラグメンテーションを95%以上削減
• Continuous Batching: リクエストを動的にバッチに追加・除外し、GPU稼働率を最大化。静的バッチと比較してスループットが2〜5倍向上
• Tensor Parallelism: 複数GPU間でモデルのテンソルを分割し、70B〜405Bパラメータ規模のモデルを効率的にサービング。最大8GPU並列に対応
• Speculative Decoding: ドラフトモデルで候補トークンを先行生成し、ターゲットモデルで検証するパイプライン推論。レイテンシを30〜50%短縮
• 量子化サポート: AWQ（4bit）、GPTQ（4bit）、FP8、INT8量子化モデルをネイティブサポート。VRAM使用量を50〜75%削減
• OpenAI互換API: /v1/completions および /v1/chat/completions エンドポイントをそのまま提供し、既存のOpenAI SDKコードをそのまま流用可能
• Prefix Caching: 共通プレフィックス（システムプロンプト等）のKVキャッシュを複数リクエスト間で共有。同一プレフィックスのリクエストで最大10倍の高速化
• マルチモーダル対応: LLaVA、Qwen-VL、InternVL2などのVision-Languageモデルをサポート

スペック比較表

具体例・対応製品

vLLMは以下の環境・モデルで広く利用されている：

• Llama 3.1 405B: 8x NVIDIA H100 80GB（Tensor Parallelism=8）で秒間約150トークン生成。月額GPU費用は約$25,000〜$30,000（AWS p5.48xlarge）
• Qwen2.5 72B: 2x NVIDIA A100 80GB構成で秒間約80トークン。AWQ 4bit量子化時は1x A100で動作可能（秒間約40トークン）
• Mistral 7B: 1x NVIDIA RTX 4090 24GBで秒間約120トークン。FP16フル精度でもVRAM 14GB程度に収まる
• Gemma 2 27B: 1x NVIDIA A100 40GBで秒間約60トークン。GPTQ 4bit量子化で1x RTX 4090でも動作
• DeepSeek-V3 671B MoE: 8x H100構成でアクティブパラメータ37Bを効率的にサービング。Expert Parallelism対応

選び方・注意点

vLLMを導入する際は以下の点を考慮する：

1. GPU VRAM容量: モデルパラメータ数×2バイト（FP16）が最低必要VRAM。70Bモデルなら最低140GB（2x A100 80GB）。量子化で半減可能
2. スループット vs レイテンシ: Continuous Batchingはスループット重視の設計。単一リクエストの最小レイテンシが必要な場合はSpeculative Decodingを併用
3. モデル互換性: Hugging Face Transformers形式のモデルに広く対応するが、独自アーキテクチャは未対応の場合がある。対応モデルリストを事前確認
4. デプロイ方式: Docker公式イメージ（vllm/vllm-openai）、Ray Serve統合、Kubernetes Operator（KServe/Seldon）など複数の選択肢がある
5. コスト最適化: Prefix Cachingとバッチサイズの調整で、同一ハードウェアでの処理能力を2〜3倍改善可能

関連用語との違い

よくある質問（FAQ）

Q1: vLLMはCPUのみの環境で動作しますか？ A: 基本的にNVIDIA GPU（CUDA）が必須。CPU推論はllama.cppやOllamaを推奨。vLLMのCPUバックエンドは実験的実装で本番使用は非推奨。

Q2: vLLMとOllamaの使い分けはどうすべきですか？ A: ローカル開発・実験用途にはOllama、本番APIサービングにはvLLMが適切。vLLMはContinuous BatchingとPagedAttentionで同時多数リクエスト処理に優れる。

Q3: vLLMの起動に最低限必要なGPU構成は？ A: 7Bモデル（FP16）なら1x RTX 4090（24GB VRAM）で十分。GPTQ 4bit量子化なら3Bモデルを8GB VRAM GPUでも動作可能。70B以上は複数GPU構成が必要。

Q4: vLLMでストリーミングレスポンスは使えますか？ A: OpenAI互換APIの stream=True パラメータでSSE（Server-Sent Events）形式のストリーミング出力に対応。ChatGPTライクなリアルタイム応答を実装可能。

まとめ

• vLLMはPagedAttentionによる効率的メモリ管理で最大24倍のスループットを実現
• OpenAI互換APIを提供し、既存コードの移行コストが最小限
• 7Bから405B+まで幅広いモデル規模に対応し、量子化・マルチGPU並列をサポート
• 本番LLMサービングのデファクトスタンダードとして2026年現在も活発に開発が継続