vLLMとは。本番向けLLM推論エンジンの仕組み・できること・Ollamaとの使い分け

Q: vLLMはなぜ速いのですか？

KVキャッシュのメモリを細かいブロックで管理するPagedAttentionと、到着したリクエストを処理中のバッチに随時合流させる連続バッチングの2つが理由です。従来方式ではKVキャッシュ用メモリの60〜80%が無駄になっていたと初出ブログは述べており、この無駄をなくすことで同じGPUで同時に捌けるリクエスト数が増えます。1人で使うときの生成速度はGPUのメモリ帯域でほぼ決まり、vLLMで大きく変わるものではありません。

ローカルLLMの本番構成を調べると、必ず「vLLM」という名前に行き当たります。ただ、検索して出てくる説明は「高速な推論エンジン」という一言で終わるものが多く、何がどう速いのか、Ollamaと何が違うのか、自社のサーバーで動くのかまでは分かりにくいのが実情です。本記事では、vLLMとは何かを開発の経緯から説明し、速さの仕組み、できること、動作要件、他ツールとの使い分け、企業で導入するときに押さえる点までを、2026年10月1日時点の公式ドキュメントに基づいて整理します。

この記事の要点

vLLMはUC Berkeley（Sky Computing Lab）で生まれたオープンソース（Apache-2.0）のLLM推論・配信エンジンで、2025年5月からPyTorch Foundationが運営母体です

速さの核心は、会話文脈（KVキャッシュ）のメモリ管理を効率化するPagedAttentionと、複数リクエストをGPU上で束ねる連続バッチングの2つです。1人で使うときの速さではなく、多人数が同時に使うときの処理量に効きます

OpenAI互換API（さらにAnthropic Messages API）で動くため、クラウドAPI向けに作ったアプリの接続先を差し替えるだけで使えることが多いです

動作要件はLinux+Python 3.10〜3.13、NVIDIA GPUなら計算能力7.5以上（T4・RTX 20世代以降）が基本です。Macでの本番利用は想定されていません

1人の検証はOllama、数十人の本番はvLLMという役割分担が現実的です

vLLMとは（開発元・ライセンス・運営体制）

vLLMは、大規模言語モデル（LLM）をサーバー上で高速かつメモリ効率よく動かすためのオープンソースの推論・配信エンジンです。モデルそのものではなく、Hugging Faceで公開されているモデルを読み込んで、APIリクエストに応答する「土台」にあたります。

項目	内容
開発元	UC Berkeley Sky Computing Lab（初出は2023年6月）
ライセンス	Apache-2.0（商用利用・改変・再配布が可能）
運営母体	PyTorch Foundation（2025年5月にホストプロジェクト入り）
規模	GitHubスター9万超、貢献者2,000人超（2026年10月1日時点の公式情報）
最新版	v0.30.0（2026年9月22日公開）。2〜3週間ごとにマイナー版が出る
対応モデル	200以上のモデルアーキテクチャ（テキスト・マルチモーダル・埋め込み・音声など）

公式の言い方を借りると、vLLMは「LLM推論と配信のための、速くて使いやすいライブラリ」です。研究プロジェクトとして始まり、公開初期の2023年4月からLMSYSのChatbot Arenaの裏側で使われて、1日3万〜6万件のリクエストを捌きながらGPU台数を半減させたという実績が初出ブログに記されています。現在はRed Hat、NVIDIA、AMD、Google、AWSなど多数の企業が開発に参加し、商用のLLM基盤製品の中身としても採用されています。

バージョンがまだ0.x台である点は、企業導入では意識しておくべきところです。安定していないという意味ではなく、新モデルや新機能への追従が優先されるため、更新頻度が高く、設定項目やデフォルト値の変更が起こりやすいという意味です。この点は後半の「企業導入で押さえること」で改めて触れます。

vLLMが解いた問題：KVキャッシュのメモリ浪費

vLLMが生まれた理由は、1つの具体的な問題にあります。LLMが文章を生成するとき、それまでの文脈をGPUメモリに保持します。これがKVキャッシュです。従来の推論システムは、このKVキャッシュのために連続したメモリ領域を最大長ぶん前もって確保していました。実際には短い回答で終わる会話が大半なので、確保したメモリの多くが使われずに終わります。初出ブログは、既存システムではこの断片化と過剰確保によってメモリの60〜80%が無駄になっていたと述べています。

GPUメモリが無駄になると、同時に処理できるリクエスト数が減ります。つまり同時アクセスに弱くなるのです。vLLMの中核技術であるPagedAttentionは、OSの仮想メモリとページングの考え方を借りて、KVキャッシュを固定サイズのブロックに分割し、必要になった分だけ割り当てます。これでメモリの無駄がほぼゼロに近づき、同じGPUで同時に捌けるリクエスト数が増えました。

論文（SOSP 2023）では、同程度の応答遅延のまま、当時の最先端システム（FasterTransformer・Orca）に対してスループットが2〜4倍になったと報告されています。初出ブログの比較ではHugging Face Transformersに対して最大24倍、Text Generation Inferenceに対して最大3.5倍という数字も示されていますが、こちらは2023年当時の比較対象との差であり、現在の他ツールとの差を示すものではありません。

ここで押さえておきたいのは、vLLMの速さが1人で使ったときのトークン生成速度ではないことです。1人で使うときの速さは、GPUのメモリ帯域でほぼ決まります（詳しくは『ローカルLLMの速度はメモリ帯域で決まる。スペック表の正しい読み方』）。vLLMが効くのは、多人数が同時に使ったときに、GPUを遊ばせずに処理量を稼ぐ場面です。

vLLMの主な機能

公式ドキュメントが挙げる機能を、企業利用の観点で整理します。

性能に関わる機能

連続バッチング: 到着したリクエストを待たせずに、処理中のバッチに随時合流させます。1件ずつ順番に処理する方式に比べ、GPUの稼働率が上がります
PagedAttention: 前述のKVキャッシュ管理です。同時接続数を増やしてもメモリを無駄にしません
プレフィックスキャッシュ: 同じシステムプロンプトや文書を含むリクエストが続いたとき、共通部分の計算結果を再利用します。RAGや定型プロンプトで効果が大きい機能です
量子化: FP8、INT4/INT8、GPTQ、AWQなど複数の方式に対応し、モデルのメモリ使用量を減らします
投機的デコーディング: 小さなモデルで下書きを作り、本体モデルで検証することで生成を速めます
テンソル並列・パイプライン並列: 1枚のGPUに載らないモデルを複数GPU、複数ノードに分散して動かします

使い勝手に関わる機能

OpenAI互換APIサーバー: /v1/chat/completions、/v1/completions、/v1/embeddings、/v1/responses、音声の文字起こしなどのエンドポイントを提供します。OpenAI向けに書いたアプリは、接続先URLとモデル名を差し替えるだけで動くことが多いです
Anthropic Messages API: /v1/messagesも提供されます。Claude向けのクライアントを接続する選択肢になります（『Claude Codeをローカルモデルで動かす』で扱ったテーマです）
ツール呼び出し（tool calling）: モデルがAPIや関数を呼ぶための出力を構造化して返します。エージェント用途の前提になる機能で、対応モデルの選び方は『ローカルLLMのtool calling。エージェント実用の鍵はモデル選び』にまとめています
構造化出力: JSONスキーマや正規表現に従った出力を強制できます。業務システムへの組み込みで、出力の形式崩れを防ぎます
マルチモーダル: 画像や動画を入力に取るモデル、埋め込みモデル、音声認識モデル（Whisper系）も同じ基盤で動かせます

動作要件（どんなサーバーで動くか）

vLLMはサーバー用のソフトウェアで、動作環境の前提がはっきりしています。

項目	要件（公式GPU Installationページ、2026年10月1日時点）
OS	Linux。Windowsはネイティブ非対応（WSLまたはコミュニティ版）
Python	3.10〜3.13
NVIDIA GPU	計算能力（Compute Capability）7.5以上。T4、RTX 20世代、A100、L4、H100、B200など
CUDA	配布バイナリはCUDA 12.9向け。12.8・13.0向けも提供
AMD GPU	ROCm 6.3以上。MI200/MI300/MI350、Radeon RX 7900/9000、Ryzen AI MAX/AI 300など
その他	x86/ARM CPU、Google TPU、Intel Gaudi、AWS Neuron、Apple Siliconなどはプラグインや限定サポート

企業の検討で特に多い疑問に、先に答えておきます。

Macでは動くのか: Apple Siliconはプラグイン扱いで、本番の推論基盤としては想定されていません。Mac 1台で社内AIを始める構成では、OllamaやLM Studio、MLX系のツールを使うのが現実的です（Macで始める社内専用AI導入支援）
古いGPUは使えるのか: 計算能力7.5未満（GTX 10世代やV100など）は現在の配布バイナリの対象外です。手元のGPUが要件を満たすかは、導入前に必ず確認してください
VRAMはどれくらい必要か: モデル本体に加えて、同時処理用のKVキャッシュ領域を確保します。「モデルがぎりぎり載る」VRAMでは同時処理の余地がなく、vLLMの利点が出ません。モデルサイズの1.2〜1.5倍程度を目安に余裕を見ておくと安全です

対応モデルとモデル形式

vLLMはHugging Face Hubで配布されている形式（safetensors）のモデルをそのまま読み込みます。Llama、Qwen、Gemma、Mistral、DeepSeekなど主要なオープンモデルは公開直後に対応されることが多く、新モデルへの追従の速さはvLLMの強みの1つです。

一方で注意が必要なのがGGUF形式です。Ollamaやllama.cpp、LM Studioで使われている形式で、ローカルLLMの入門時に最もよく触れるファイルです。vLLMの公式ドキュメントは、GGUFサポートについて「非常に実験的で最適化されておらず、他の機能と互換性がない場合がある」と明記しています。現在は本体から切り離された別プラグイン（vllm-gguf-plugin）の扱いで、トークナイザーの変換にも時間がかかり不安定だとされています。

つまり、Ollamaで試したGGUFモデルをvLLMにそのまま持ち込むことは、できないと考えておくのが安全です。vLLMで本番運用するなら、同じモデルのHugging Face形式か、AWQ・GPTQ・FP8で量子化された版を使います。モデルの入手先がOllamaのライブラリからHugging Face Hubに変わる、と理解しておくと分かりやすいでしょう。

Ollama・llama.cpp・LM Studioとの使い分け

「vLLMとは」を調べている方の多くは、Ollamaとの違いを知りたいはずです。競合というより役割の違いとして整理します。

観点	vLLM	Ollama	llama.cpp	LM Studio
想定用途	本番サーバー（多人数・API組み込み）	個人・開発・小規模共有	組み込み・軽量実行・各種ツールの土台	個人のGUI利用
設計の優先順位	スループット	手軽さ	移植性・省メモリ	使いやすさ
主なモデル形式	Hugging Face形式、AWQ/GPTQ/FP8	GGUF	GGUF	GGUF
動作環境	Linux+NVIDIA/AMD GPUが基本	Mac/Windows/Linux、CPUでも可	ほぼ全環境	Mac/Windows/Linux
同時処理	連続バッチングが前提	既定では同時処理数を絞った設計	対応はあるが用途外	単一ユーザー前提
導入の手間	Python環境・GPUドライバの整備が必要	コマンド1つ	ビルドまたは配布版	インストーラー

1人で使う限り、Ollamaは何も悪くありません。差が出るのは同時アクセスが増えてからです。「いつOllamaからvLLMに乗り換えるか」の判断基準と公開ベンチマークの読み方は、『試作はOllama、本番はvLLM。乗り換えのタイミングと20倍の性能差』で詳しく扱っています。

なお、vLLMと同じ「本番向け推論エンジン」の分類には、SGLangやNVIDIAのTensorRT-LLMもあります。SGLangは構造化出力やエージェント的な多段処理の最適化に強みがあり、TensorRT-LLMはNVIDIA GPUに特化して最大性能を狙う位置づけです。ただし情報量・対応モデルの幅・採用実績の面でvLLMが事実上の標準になっており、特段の理由がなければvLLMから始めるのが無難です。

最小の起動手順

Linux+NVIDIA GPU環境での最小手順です。公式はパッケージ管理にuvを推奨しています。

# インストール（公式推奨の uv を使用。PyTorchも同時に適切な版が入る）
uv pip install vllm --torch-backend=auto

# OpenAI互換サーバーとして起動
vllm serve Qwen/Qwen3.5-9B-Instruct --port 8000

# 動作確認（OpenAI互換のチャットAPI）
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "Qwen/Qwen3.5-9B-Instruct", "messages": [{"role": "user", "content": "こんにちは"}]}'

初回起動時にHugging Face Hubからモデルがダウンロードされます。社内ネットワークで外部通信を制限している場合は、別環境でダウンロードしたモデルを配置してパスを指定する運用になります。本番ではDockerの公式イメージ（vllm/vllm-openai）を使い、GPUドライバとCUDAの版をコンテナ側で固定する構成が一般的です。

企業導入で押さえること

vLLMは起動するだけなら簡単です。難しいのは、社内に公開して運用し続ける部分です。

認証はvLLM単体に頼らない

vLLMには--api-keyオプションでAPIキー認証がありますが、公式のSecurityページは、この認証が守るのは/v1などの一部のパス配下に限られると明記しています。それ以外のエンドポイントは認証なしで推論を実行でき、生成の一時停止や中断など運用系の操作も保護されません。公式の推奨は、nginxやEnvoyなどのリバースプロキシで公開するエンドポイントだけを許可リスト化するか、信頼できる隔離ネットワーク内にのみ置くことです。vLLMをインターネットや社内の全セグメントに直接露出させる構成は避けてください。

更新頻度の高さに備える

前述のとおり、vLLMは2〜3週間ごとにマイナー版が出ます。新モデル対応や性能改善が早い反面、更新のたびに動作確認が必要です。本番では版を固定し、検証環境で新版を試してから切り替える手順と、問題があったときに戻す手順を用意しておきます。「とりあえず最新版」のまま運用すると、ある日の更新でモデルの読み込みに失敗する、という事態が起こり得ます。

GPUの監視とサイジング

vLLMは起動時にKVキャッシュ用のGPUメモリを確保するため、GPU使用率やメモリの監視項目がOllama時代とは変わります。同時利用者数が増えたときに「どこまで耐えるか」は実機で負荷をかけて測るしかなく、この測定が本番サイジングの根拠になります。

運用担当者を決める

ここまでの話はすべて「誰かが回し続ける」ことが前提です。vLLM自体の技術難度よりも、Linuxサーバー・GPUドライバ・Python環境・モデル更新を継続的に面倒見る担当者の確保のほうが、実際の導入では壁になります。この問題は『導入したローカルLLM、誰が維持するのか。挫折の最大要因は運用担当者問題』で詳しく扱っています。社内文書RAGなど実際の構成例は『社内文書RAGの作り方2026』を参照してください。

vLLMが向くケース・向かないケース

向くケース	向かないケース
社内の数十人以上が同時に使うチャットや検索	1人〜数人の検証・試作
業務システムやチャットボットからAPIで呼ぶ	Mac・Windows PC上で動かしたい
OpenAI/Anthropic APIで作った既存アプリの接続先を社内に移したい	手元のGGUFモデルをそのまま使いたい
RAGで長いプロンプトを大量に処理する	GPUのVRAMがモデルぎりぎりしかない
複数GPU・複数ノードでの大型モデル運用	サーバー運用の担当者を置けない

「向かないケース」に多く当てはまるなら、現時点ではOllamaやMac構成のほうが適しています。逆に「向くケース」が複数当てはまり、Ollamaで応答待ちが起きているなら、vLLMへの移行を検討する段階です。

まとめ

vLLMはUC Berkeley発、現在はPyTorch Foundationが運営するオープンソース（Apache-2.0）のLLM推論・配信エンジンで、本番向け推論基盤の事実上の標準です
速さの核心はPagedAttentionと連続バッチングで、多人数の同時アクセス時の処理量に効きます。1人で使うときの速さはGPUのメモリ帯域で決まり、vLLMで変わるものではありません
OpenAI互換API・Anthropic Messages API・tool calling・構造化出力・マルチモーダルに対応し、既存アプリの接続先差し替えで使えることが多いです
動作要件はLinux+Python 3.10〜3.13+計算能力7.5以上のNVIDIA GPU（またはROCm 6.3以上のAMD GPU）が基本で、Macの本番利用は想定外です。GGUF形式は実験的扱いなので、モデルはHugging Face形式か量子化版を使います
企業導入では、リバースプロキシでの認証・公開範囲の制限、版の固定と更新手順、GPU監視、運用担当者の確保が技術選定より重要です

よくある質問

Q. vLLMとは何ですか？一言で言うと？

LLMをサーバー上で高速かつメモリ効率よく動かすためのオープンソースの推論・配信エンジンです。UC Berkeleyで2023年に生まれ、現在はPyTorch FoundationのホストプロジェクトとしてApache-2.0ライセンスで公開されています。モデルそのものではなく、Hugging Faceで公開されたモデルを読み込んでAPIで応答する土台にあたります。

Q. vLLMは無料で商用利用できますか？

はい。Apache-2.0ライセンスのため、商用利用・改変・再配布が可能で、ライセンス費用はかかりません。費用が発生するのはGPUサーバーの機材と、構築・運用の人件費です。支援会社の見積もりに「vLLMライセンス費」のような名目があれば、何に対する費用かを確認してください。

Q. vLLMはなぜ速いのですか？

KVキャッシュ（会話文脈）のメモリをOSのページングのように細かいブロックで管理するPagedAttentionと、到着したリクエストを処理中のバッチに随時合流させる連続バッチングの2つが理由です。従来方式ではKVキャッシュ用メモリの60〜80%が無駄になっていたと初出ブログは述べており、この無駄をなくすことで同じGPUで同時に捌けるリクエスト数が増えます。なお、1人で使うときのトークン生成速度はGPUのメモリ帯域でほぼ決まり、vLLMで大きく変わるものではありません。

Q. vLLMはMacやWindowsで動きますか？

本番利用は想定されていません。公式の動作要件はLinuxで、WindowsはWSLまたはコミュニティ版、Apple Siliconはプラグインによる限定的なサポートです。MacやWindowsのPCで動かすなら、OllamaやLM Studioが適しています。

Q. OllamaとvLLMはどちらを使うべきですか？

人数で決まります。1人〜数人の検証や小規模共有ならOllama、数十人の同時利用や業務システムからのAPI組み込みならvLLMです。Ollamaで「誰かが使っていると返ってこない」という応答待ちが起きたら、vLLMへの移行を検討する目安です。

Q. Ollamaで使っていたモデルはvLLMで使えますか？

そのままの流用はできないと考えてください。OllamaはGGUF形式が中心ですが、vLLMの公式ドキュメントはGGUFサポートを「非常に実験的で最適化されていない」としており、別プラグインの扱いです。vLLMではHugging Face形式か、AWQ・GPTQ・FP8で量子化された版を使います。

Q. vLLMを動かすのにどんなGPUが必要ですか？

NVIDIA GPUなら計算能力7.5以上（T4、RTX 20世代以降、A100、L4、H100など）、AMD GPUならROCm 6.3以上に対応したMI200/MI300系やRadeon RX 7900/9000系です。VRAMはモデル本体に加えて同時処理用のKVキャッシュ領域が必要なので、モデルがぎりぎり載る容量では利点が出ません。

主な参考資料: vLLM公式ドキュメント、GPU Installation、Online Serving、GGUF、Security、vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention（2023年6月20日）、Efficient Memory Management for Large Language Model Serving with PagedAttention（arXiv）、PyTorch Foundation Welcomes vLLM as a Hosted Project（2025年5月6日）、vllm-project/vllm（GitHub）。いずれも2026年10月1日に確認しました。

vLLMでの本番構成を検討している方へ

TodoONadaでは、ローカルLLM・生成AIの導入判断からPoC・構築・運用設計までを支援しています。

Ollamaでの検証構成からvLLMでの本番構成への移行設計
同時利用者数に合わせたGPUサイジングと実機での負荷測定
リバースプロキシでの認証・監視・版固定とモデル更新手順まで含めた運用設計

まずは約30万円・2週間のミニ検証から始められます。機材を買う前に「自社のサーバー室やオフィスにGPU機を置けるか」を確かめたい場合は、機材貸出付きの実現性検証もご用意しています。「今のOllama構成で何人まで耐えるか」の負荷測定だけでも、お気軽にご相談ください。

この記事に関連するサービス

TodoONada株式会社では、機密データを外部に出さないローカルLLMの導入支援を行っています。

ローカルLLM導入支援 — GPUサーバーでの本格構成。モデル選定からRAG構築・運用まで
Macで始める社内専用AI導入支援 — Mac 1台から始める社内専用AI。PoCから部門導入まで対応
ローカルLLM 社内設置の実現性検証（機材貸出） — 機材を買う前に、DGX SparkやMacを貴社オフィスに2週間設置して「置けるか」を判定。機材のみの短期貸出も対応

導入・開発のご相談はお問い合わせからお気軽にどうぞ。検討段階のご相談も歓迎です。