中級 11 分推論

vLLMとは？誰に向いていて、いつ使うべきか ?

端的な回答

vLLM は2023年に Berkeley で生まれたオープンソースの推論エンジンで、GPU 上で動作する LLM を、OpenAI 互換 API を通じて複数のユーザーに同時に提供します。PagedAttention と継続的バッチ処理により、複数のリクエストが同時に届くと、従来のサーバーに比べて総スループットが数倍になります。単独の会話を高速化するわけではありません。自分のパソコンで一人で使う場合は、引き続き Ollama や LM Studio が適切な選択です。

vLLMは、GPU上でOpenAI互換APIを介して複数のユーザーに同時にLLMを提供するために設計された、オープンソースの推論エンジンです。2026年9月20日時点では、オープンウェイトモデルをチームやアプリケーションに提供するための定番です。手元のPCで使うOllamaと競合するツールではありません。両者が解決する課題は異なります。このページでは、vLLMが何をするのか、何が必要なのか、そして自分に必要かどうかを判断する方法を説明します。

著者 Mohamed Meguedmi·更新 2026-09-28·Windows・macOS・Linuxでテスト済み

#vLLMを3文で説明

vLLMは2023年にBerkeley大学のSky Computing Labで誕生したPythonライブラリおよび推論サーバーであり、Apache 2.0ライセンスという商用再利用を無制限に許可するパーミッシブライセンスの下で公開されています。Hugging Face形式（多くの場合safetensors）のモデルを1つ以上のGPUに読み込み、OpenAI互換のHTTP APIとして公開します。これにより、アプリケーションコードを変更することなく、OpenAI API用に作成済みの任意のクライアントを接続でき、ベースURLの変更だけで済みます。その存在意義は一言で言えばスループット、すなわち10、50、または200の異なるリクエストが同時に到着し、すべてが迅速な応答を得る必要がある場合の、GPUが1秒間に生成するトークンの総数です。

i
要点
Ollama と LM Studio は、一人が自分のマシンで使う際の体験を最適化します。vLLM は、多数のリクエストで共有する GPU の処理効率を最適化します。一人で使っている場合、vLLM にしても応答は速くなりません。

#vLLMが解決する問題

ローカルAIキット

お使いのマシンで、プライベートかつ無料のChatGPTを1時間で構築 — LM Studio、Ollama、Open WebUI、ご自身のドキュメント、クラウド不要。

  • 永久に利用できるオンラインスペース
  • PDF + ファイル
  • 生涯アップデート
ローカルAIキット →または すべてのキットを無期限で利用 — 49 € →

LLMがテキストを生成する際、それまでに読み込んだおよび書き出したすべての情報の痕跡をメモリに保持します。これがKVキャッシュです。このキャッシュはトークンごとに増加し、最終的なサイズは予測不可能です。なぜなら、回答が20語になるか2,000語になるかは事前にわからないからです。そのため、第1世代の推論サーバーでは、各リクエストに対して、最悪のケースを想定したサイズの連続メモリブロックを予約していました。

この数値は、vLLMの基礎となった論文（Kwon et al., SOSP 2023）に明記されており、プロジェクトチーム自身も取り上げています。既存のシステムでは、KVキャッシュ用に予約されたメモリの60〜80%が、実際に無駄になっていました。原因は、念のために過剰にメモリを予約することと、割り当て済みのブロックの間に使えない隙間を残す断片化です。実際に使えるメモリが少なければ、同じカードで並列に処理できるリクエスト数も必然的に少なくなります。その結果、数千ユーロもするGPUが、結局は理論上の処理能力のごくわずかな部分しか発揮できないまま稼働することになります。それでも、電気代やハードウェアの減価償却費は変わりません。

#PagedAttentionと連続バッチ処理

vLLM は二つのアイデアに基づいています。一つ目は PagedAttention で、オペレーティングシステムから借用されたものです。リクエストごとに大きな連続ブロックを確保するのではなく、KV キャッシュは固定サイズの小さなページに分割され、必要に応じて割り当てられ、メモリ内のどこに配置されても構いません。テーブルがトークンの論理的な順序とページの物理的な位置を結びつけ、コンピュータの仮想メモリとまったく同じ仕組みです。著者によると、無駄は 4 % 未満に抑えられます。

2つ目のアイデアは、1つ目を補完する連続バッチングです。従来のサーバーはリクエストをバッチにまとめ、同じバッチ内のすべてのリクエストが完了するまで待ってから次のバッチを開始します。そのため、すぐに結果を返せたはずの短いリクエストが、まだGPUを占有している長いリクエストの完了を無駄に待つことになります。一方、vLLMはトークンを生成するたびに、つまりデコーディングの各ステップで、バッチ全体を組み直します。ある応答が完了すると、バッチ内のその枠は直ちにキューで待機しているリクエストに割り当てられ、GPUが無駄なパディング処理に計算を費やすことはありません。このように枠を常に再利用する仕組みと、ページ単位で管理するメモリの組み合わせが、一度に1人のユーザーを処理することを想定した推論エンジンと比べて観測されるスループット向上の大部分を生み出しています。

共有プレフィックス
複数のリクエストがまったく同じテキスト（システムプロンプト、共通ドキュメント）で始まると、対応するページは一度だけ計算され、それらの間で共有されます。これはプレフィックスキャッシュです。
テンソル並列化
1枚のカードに収まりきらないほど大規模なモデルは、単一の起動オプション --tensor-parallel-size を使用して、同一マシンの複数のGPUに自動的に分散されます。
サーバー側の量子化
vLLMは、GPUでのバッチ計算向けに設計されたAWQ、GPTQ、FP8形式を読み込めます。GGUFへの対応は実験的なものに限られます。
OpenAI互換API
/v1/chat/completionsと/v1/completionsのルートは、OpenAIの同じルートとまったく同じ形式で応答します。既存のアプリケーションはベースURLを変更するだけで、ビジネスロジックのコードを1行も書き換える必要はありません。

#vLLMがメモリに読み込む内容

Ollama から来て、既存の習慣をそのまま再利用できると思っている方にとって、最もよくある驚きです。Ollama はデフォルトで 4 ビット量子化された GGUF をダウンロードし、一般的なグラフィックカードで動作することを前提としています。一方、vLLM はデフォルトで Hugging Face に公開されているウェイトをそのまま読み込み、多くの場合 BF16（16 ビット精度）であり、モデルのパラメータ 10 億個あたり約 2 GB になります。そのため、同じモデルでも vLLM では Ollama の約 3 倍のメモリを消費し、さらに進行中の会話ごとに増加する KV キャッシュを考慮すると、Ollama では十分なグラフィックカードでも、ウェイトの形式を変更しない限り vLLM では不十分になることがよくあります。

重みのみ、KV キャッシュを除く · QuelLLM カタログから算出 · 2026年9月20日
モデルBF16（vLLMデフォルト）GGUF Q4_K_M（Ollamaのデフォルト）BF16で必要な最小構成のGPUカード
Qwen 3 8B16 GB5 GBRTX 4090または5090（24～32GB）
Gemma 4 12B24 GB7 GBRTX 5090（32 GB）
Qwen 3 14B28 GB9 GBRTX 5090（32 GB）、短いコンテキスト
Mistral Small 3.2 24B48 GB14 GB2 × RTX 5090 (64 GB)
Qwen 3.8 27B54 GB16 GB80 GBのカード、または短いコンテキストでRTX 5090を2枚
Llama 3.3 70B140 GB40 GB80 GBのGPUカード × 2枚

最も一般的な方法は、既に量子化されたバージョンをGPUで使用するという点です。4ビットのAWQまたはGPTQモデルは、同等のGGUF Q4形式とほぼ同じメモリ使用量を消費し、FP8形式は最近のサポートを受けるGPUでBF16のサイズをほぼ半分にします。実際に人気のあるモデルのほとんどは、Hugging Faceにすでにこれらのフォーマットのいずれかで公開されており、公式リリースの日にその場で公開されています。

!
「vLLMにVRAMを全部使われた」
これは完全に意図された動作であり、バグでもメモリリークでもありません。起動時に、vLLMはデフォルト値が0.9の--gpu-memory-utilizationオプションに従い、GPUの総メモリの90％を確保します。まずモデルの重みに割り当て、その領域の残りすべてをKVキャッシュのページに割り当てます。利用可能なページが多いほど、リクエストを拒否せずに並列処理できる数が増えます。同じマシンでゲームや別のサービスなども利用する場合は、それに応じてこの値を下げてください。

#サポートされるハードウェアおよびシステム

プロジェクトのドキュメントに基づく、2026年9月20日時点のサポート状況
プラットフォームステータス実際には
Linux + GPU NVIDIA (CUDA)主なターゲット最もよく検証されている方法です。Compute Capability 7.0以上が必要で、VoltaおよびTuring（RTX 20）世代以降が対象です。
Linux + AMD GPU (ROCm)サポート対象最近のInstinctおよびRadeonカード。専用Dockerイメージの利用を推奨します。
Windowsネイティブバージョンは存在しませんNVIDIAのGPUを使い、WSL2経由で実行する。
Apple Silicon搭載Mac2026年9月22日から GPU 対応（別プラグイン）2026年9月22日に発表された公式プラグインvllm-metalは、vLLMのスケジューラ、KVキャッシュのページング、OpenAI互換サーバーをApple Silicon上で利用できるようにし、実行にはMLXとMetalを使います。メインパッケージとは別にインストールする、まだ新しいプラグインです。本番ワークロードを移行する前に、お使いのチップとの互換性を確認してください。
CPUのみ（x86、ARM）サポート対象統合のテストには有用ですが、サービングには向きません。

#5 分で起動する

NVIDIA GPUと最新のドライバーを備えたLinuxマシンなら、クリーンなPython環境で数行のコマンドを実行するだけでインストールが完了し、事前に複雑な設定を書く必要はありません。vllm serveコマンドは、初回起動時に指定されたモデルをHugging Faceからダウンロードしてメモリに読み込み、その後すぐにデフォルトのポート8000でAPIを公開します。これで、OpenAIの標準形式のリクエストを受け付けられる状態になります。

モデルをインストールしてサーバーとして提供する
python -m venv vllm-env && source vllm-env/bin/activate
pip install vllm

vllm serve Qwen/Qwen3-8B --max-model-len 8192
OpenAIのAPIと同じ方法でAPIにリクエストを送る
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "Qwen/Qwen3-8B", "messages": [{"role": "user", "content": "Bonjour"}]}'

--max-model-lenオプションは、初回起動時から明示的に設定しておくことをおすすめします。指定しないと、vLLMはモデルが公表している最大コンテキスト長に合わせてKVキャッシュの容量を設定します。最近のモデルでは、この長さが128,000トークン以上になることもあります。このデフォルトの容量設定に対してGPUの空きメモリが足りない場合、vLLMは起動できません。初めて試す際によく発生するエラーです。Dockerコンテナ、呼び出しの認証、継続的な監視、段階的な負荷増加を含む本格的な本番導入については、別のより詳しいガイドで説明しています。

#向いている人、向いていない人

あなたの状況vLLM ?なぜ
自分のPCで、一人でモデルと対話するいいえ単一のリクエストでは速度向上はなく、BF16 での VRAM 使用量は3倍になります。
Macをお持ちの場合最近では、選択肢になる可能性ありプラグインvllm-metal（2026年9月22日）はMLX/Metal経由でGPUをサポートしますが、非常に新しいものです。2026年9月28日時点では、MLXとllama.cppが実績のある選択肢です。
VRAMが8〜12 GBあるまれに一部を CPU にオフロードして動かす Q4 の GGUF モデルのほうが役に立ちます。
5〜50人のチームが1つのモデルを共有しますはい継続バッチングにより、単一のGPUで全ユーザーに対応します。
アプリケーションが短時間に集中してモデルを呼び出すはい待ち行列、高いスループット、標準API。
10,000ドキュメントをまとめて処理していますはいこの用途で、スループットの差が最も顕著になります。

#FAQ

vLLMはOllamaよりも速いですか？+
単一ユーザーの場合、そうではありません。単一のリクエストの生成速度は、主にGPUのメモリ帯域幅に依存し、どちらの場合も同じです。差が現れるのは並行処理のときです。複数のリクエストが同時に到着すると、vLLMはそれらを同じバッチで処理し、その総スループットは単一ユーザー向けに設計されたサーバーを大きく上回ります。
vLLMは無料ですか？+
はい、完全に無料です。このプロジェクトはApache 2.0ライセンスのもとで公開されているオープンソースです。これは制約の少ないライセンスで、一部のモデルライセンスとは異なり、企業での商用利用でもライセンス料やロイヤリティは一切かかりません。実際にかかる費用は、すでに所有しているハードウェアの費用か、サーバーを動かすためにクラウドプロバイダーからGPUをレンタルする費用だけです。
vLLMはWindowsまたはMacで動作しますか？+
Windowsではネイティブに動作しません。公式プロジェクトにはWindows版も、その対応に向けた公開ロードマップもなく、NVIDIA製GPUを使ってWSL2経由で実行する必要があります。コミュニティによるフォークはいくつか存在しますが、いずれも非公式です。Macでは、2026年9月22日に発表された「vllm-metal」という公式プラグインにより、MLXとMetalを通じたGPUアクセラレーションがようやく利用できるようになりました。それ以前はCPUしか利用できなかったため、このプラットフォームではOllamaやMLXに対してvLLMを使うメリットがありませんでした。
vLLM で GGUF ファイルを使用することは可能ですか？+
技術的には対応していますが、まだ実験段階であり、ネイティブの処理経路に比べて性能が大幅に劣ります。vLLMは当初から、safetensors形式のHugging Faceのモデル重みと、GPUでのバッチ計算向けに設計された量子化方式であるAWQ、GPTQ、FP8を想定して設計されています。どうしてもGGUF形式にこだわる場合は、llama.cppとそのサーバーであるllama-serverが、この形式に適した、最もよく最適化されたツールです。
vLLMで1つのGPUが何人のユーザーを処理できますか？+
重みを読み込んだ後にKVキャッシュ用に残るメモリ量と、会話の長さによって異なります。量子化済みの8Bモデルを24 GBのGPUで動かす場合、数十件の短い会話を同時に処理することは現実的です。信頼できる答えを得る唯一の方法は、自分のプロンプトで負荷テストを行うことです。
このガイドは役に立ちましたか？

ご意見、誤りのご指摘、補足はありますか？ぜひお知らせください。皆さんにとってより良いガイドにするために役立ちます。