著者 OllamaとvLLMの違いと選び方
1人のローカル利用ならOllama、GPUでチーム向けに高スループット処理するならvLLMが適しています。CPU対応や実際の起動コマンドを比較します。
Ollama と vLLM の比較（1段落）
Ollama は、サーバー機能を備えたモデルマネージャーです。量子化された重みをダウンロードして読み込み、127.0.0.1:11434 に応答します。マシンに CPU しかない場合は CPU を使用します。vLLM はスループットエンジンです。多数のリクエストを同時に処理して GPU を最大限に稼働させます。そのため、GPU のないマシンでは適切なツールではありません。判断基準はこれだけです。1人がローカルアシスタントと対話する場合は Ollama の用途です。アプリケーションがチームにサービスを提供する場合は vLLM の用途です。
どちらも OpenAI 互換の HTTP API を使用するため、ベース URL を変更するだけでクライアントコードを切り替えられます。API が違いを生むのではありません。最初のリクエストがまだトークンを生成している間に、2番目のリクエストが到着したときの動作が違います。
Ollamaの実際の役割
Ollamaは利便性を提供するレイヤーです。1つのインストールコマンドで、モデルレジストリ（ollama pull llama3.1:8b）、重みのローカル保存領域、チャットプロンプト、systemdサービス、HTTP APIを利用できます。提供するモデルはGGUFファイルで、通常は4-bit量子化されています。そのため、7Bまたは8Bモデルのディスク容量は16 GBではなく約5 GBです。量子化によって、CPUでの推論が可能になります。
そのランナーは、一般的なハードウェアでGGUF量子化を実用化したC++推論ライブラリ、llama.cppを基盤としています。その後、Ollamaは一部の新しいモデルファミリー向けに独自のエンジンも追加しました。ただし、提供機能の大部分では、現在もllama.cppが基盤です。したがって、Ollamaとllama.cppを比較する場合、主に使いやすさを提供するレイヤーと、それがラップしている本体を比較しています。
設計上の対象は1人のユーザーです。2026年7月時点で、OLLAMA_NUM_PARALLELのデフォルト値は1です。これは、1つのモデルが一度に1つのリクエストだけを処理し、その他のリクエストはデフォルトで512件を保持するキュー（OLLAMA_MAX_QUEUE）で待機することを意味します。並列処理数は増やせますが、そのコストについては次のセクションで説明します。Ollamaをまだ実行したことがない場合は、まずVPSでOllamaをホストし、ポート11434を閉じたままにするを参照してください。APIには認証機能が一切ないためです。
vLLMの実際の役割
vLLMは推論サーバーであり、それ以外の機能はありません。モデルライブラリを管理せず、チャットプロンプトもなく、リクエスト時にモデルを取得することもありません。起動時にHugging Faceリポジトリを指定すると、そのモデルだけを読み込み、プロセスを停止するまで提供します。
この限定された役割によって、スループットが向上します。主に2つの仕組みが処理を担います。PagedAttentionは、KVキャッシュ（key-value cache。モデルがアクティブな各リクエストについて保持する、トークンごとのアテンション状態）を、オペレーティングシステムがメモリをページングする方法と同じように、固定サイズのブロックに格納します。リクエストごとに、最悪のケースに合わせた大きな連続領域を予約する必要がなくなるため、以前は予約されたまま未使用だったメモリを、より多くの同時リクエストに利用できます。Continuous batchingでは、実行中のバッチが完了するまで待たず、次のデコードステップで新しいリクエストを実行中のバッチに参加させます。シーケンスが完了すると、直ちにバッチから離脱し、そのスロットに新しいリクエストが入ります。
実際の結果は次のとおりです。1台のGPUで同時ユーザー数を1から30に増やすと、合計の1秒あたりのトークン数は大きく増加します。一方、ユーザーあたりの速度の低下は、予想するほど大きくありません。Ollamaのデフォルト設定では、ユーザー数を1から30に増やすと、29人が待つだけです。
Continuous batchingがすべてを分けます
同一のハードウェア上で、各サーバーに5件のリクエストが同時に到着したとします。
Ollamaはデフォルト設定では、1件目のリクエストを完了してから2件目を処理し、その後も同様に処理します。5人目の呼び出し元は、4回分の生成が完了するまで待機します。プロセッサーは常に1つのシーケンスだけを処理するため、総スループットはおおむね1回の生成速度になります。
vLLMは、5件すべてを同じforward passでデコードします。5つのシーケンスに対して1トークンを生成するコストは、1つのシーケンスに対して1トークンを生成するコストをわずかに上回る程度です。これは、コストの大部分がモデルの重みをメモリから読み出す処理であり、その読み出しをバッチ全体で共有できるためです。CPU推論が遅くなる理由も、同じメモリ帯域幅の特性です。必要なのは演算ではなく、重みの移動にかかるコストです。
OLLAMA_NUM_PARALLEL=4 を設定すれば、この効果の一部を得られます。代わりにメモリを消費します。各並列スロットには独自のKV cacheが必要です。また、Ollamaはコンテキストウィンドウをスロット間で分割します。そのため、8192トークンに設定されたモデルに対して4件の並列リクエストを処理すると、各リクエストで使用できるコンテキストは2048トークンになります。vLLMのpaged cacheは、リクエストの実際の増加に応じてブロックを割り当てるため、このトレードオフを回避できます。
Ollama をインストールして提供する
curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.1:8b
ollama run --verbose llama3.1:8b "Write two sentences about Linux."インストールスクリプトは ollama システムユーザーを作成し、バイナリをインストールして、127.0.0.1:11434 にバインドされた ollama.service を登録します。--verbose が出力する eval rate の値は、そのマシンでの実際の tokens per second です。公開されている数値よりも、この値を信頼してください。
同時実行数を増やすには、アップグレードで変更が上書きされないように、systemd drop-in を使用します。
sudo systemctl edit ollama.service[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_KEEP_ALIVE=30m"sudo systemctl restart ollama
ollama psollama ps は読み込まれている内容を示し、PROCESSOR 列が実際の値を示します。100% CPU は GPU が使用されていないことを意味します。Ollama が遅いという報告の多くは、これが正しい原因です。
vLLMをインストールして提供する
vLLMにはLinuxとPython 3.10～3.13が必要です。特定のPyTorchビルドがインストールされるため、専用の仮想環境にインストールします。
uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto次に、モデルを提供します。名前には短いタグではなく、Hugging FaceのリポジトリIDを指定します。
vllm serve Qwen/Qwen2.5-1.5B-Instruct初回の起動には時間がかかります。重みをダウンロードした後、GPUをプロファイリングして、KVキャッシュに収まるブロック数を決定するためです。ポート8000でリッスンします。クライアントコードを書く前に確認します。
curl http://localhost:8000/v1/models
curl http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model": "Qwen/Qwen2.5-1.5B-Instruct", "messages": [{"role": "user", "content": "Who won the world series in 2020?"}]}'すでにDockerがホストにインストールされている場合は、公式イメージを使用するとCUDAの依存関係を設定する作業を省けます。
docker run --runtime nvidia --gpus all \
-v ~/.cache/huggingface:/root/.cache/huggingface \
--env "HF_TOKEN=$HF_TOKEN" \
-p 8000:8000 \
--ipc=host \
vllm/vllm-openai:latest \
--model Qwen/Qwen3-0.6B--ipc=hostは必須です。装飾的な指定ではありません。PyTorchはプロセス間でテンソルを共有メモリ経由で渡します。Dockerのデフォルトの共有メモリ割り当ては、テンソル並列推論には小さすぎます。
本番環境で特に重要なフラグは、--max-model-len（使用するコンテキストウィンドウの上限）、--gpu-memory-utilization（vLLMが使用できるGPUメモリの割合。2026年7月時点のデフォルトは0.92）、1つのモデルを複数のGPUに分割する--tensor-parallel-size、および--api-keyです。
vLLMでは認証は1つのフラグで設定でき、Ollamaにはありません
vLLMでは、トークンを指定するとbearer tokenを要求します。
vllm serve Qwen/Qwen2.5-1.5B-Instruct --api-key token-abc123同じ値はVLLM_API_KEY環境変数からも設定できます。トークンを含まないリクエストにはHTTP 401が返されます。ただし、これは公開インターフェースでport 8000を公開する理由にはなりません。vLLMにはrate limitingがなく、平文のHTTP tokenは通信中に読み取れるためです。それでも、サーバーがリクエスト元を識別する仕組みを持つことは意味します。
Ollamaにはそのような仕組みがありません。keyもloginもallow-listもありません。11434に到達できるすべてのprocessが、modelの実行、pull、削除を実行できます。loopbackでのみ待ち受け、自分でホストするWireGuard VPN経由で接続してください。または、TLS（transport layer security）を終端する認証付きreverse proxyを使用してください。
ハードウェア: それぞれに必要なもの
OllamaはCPUで動作します。4-bit量子化モデルでは、パラメータ10億個あたり約0.5 GBのRAMが必要です。これにランタイムのオーバーヘッドとして約1 GB、さらにコンテキスト用の容量が加わります。そのため、3Bモデルには約4 GB、8Bモデルには約8 GBの空き容量が必要です。共有vCPUでの速度は、1秒あたり1桁から低い2桁のトークン数です。これはメモリ帯域幅によるもので、設定ミスではありません。フラグで解決することもできません。
vLLMはGPUを前提とします。デフォルトでは、16-bit精度の非量子化重みを提供します。必要な容量はパラメータ10億個あたり約2 GBです。8Bモデルでは、重みだけで約16 GBのビデオメモリが必要です。vLLMを使用する目的である同時実行性を確保するKVキャッシュの容量は、これとは別に必要です。24 GBのカードなら、実用的なキャッシュ容量を残せます。16 GBのカードでは残せません。そのため、より小さいモデルを選ぶか、量子化チェックポイントと--quantizationを指定します。CPUバックエンドもありますが、標準のwheelはCPU向けにビルドされていません。また、vLLMを実行する理由も失われます。
したがって、ほとんどの場合、ハードウェアの選択がソフトウェアの選択を決めます。GPUがなければOllamaです。リクエストが直列化されているため、レンタルしたGPUの使用率が5%にとどまるなら、vLLMです。
ワークロードに適したもの
- 1人でCPU VPSを使って下書きや要約を行う場合: Ollama。速度は許容範囲で、これより簡単な選択肢はありません。
- コーディングアシスタント、またはローカルモデルにツールを接続するMCPサーバーを自分だけが呼び出す場合: Ollama。同時実行数1が実際のワークロードです。
- 今週、5つのモデルを比較する場合: Ollama。タグ付きモデルの取得と削除はOllamaの得意分野です。一方、vLLMではモデルごとにプロセスを再起動する必要があります。
- 実際のユーザーが利用する内部アプリ、チャット製品、または検索パイプライン: vLLM。バッチ処理によってGPUコストに見合う効果が得られるのはこのケースです。
- 一晩で100000件のドキュメントを評価するバッチジョブ: 高い
--max-num-seqsを設定したvLLM。重要なのはスループットだけで、ドキュメントごとのレイテンシは重要ではありません。 - 複数のセルフホスト型AIエージェントが同時にモデルへアクセスするエージェントプラットフォーム: vLLM。エージェントのネットワークトラフィックは突発的に発生し、本質的に並列処理されるためです。
障害の種類と表示される文字列
vLLM が KV cache エラーで起動を拒否します。 メッセージには両方の数値が示されます。
ValueError: The model's max seq len (32768) is larger than the maximum number of tokens that can be stored in KV cache (8192). Try increasing gpu_memory_utilization or decreasing max_model_len when initializing the engine.モデルが宣言するコンテキストウィンドウが、weights の読み込み後に残るメモリより大きくなっています。--max-model-len 8192 で値を下げるか、GPU を他で使用していない場合は --gpu-memory-utilization を増やします。利用率を約 0.95 より高くすると、起動時エラーの代わりに、負荷時に CUDA out-of-memory でクラッシュすることがあります。通常はこちらのほうが深刻です。
Ollama が生成中に Killed を出力します。 Linux の out-of-memory killer が、モデルに必要な RAM がサーバーの搭載量を超えたため、プロセスを停止しました。sudo dmesg | grep -i oom で確認します。対処方法は、より小さいモデルまたはより強く量子化したモデルを使用することです。設定変更では解決しません。
Ollama は単独では正常に応答しますが、負荷をかけると停止したようになります。 どこにもエラーは表示されません。呼び出し元が増えるほどリクエストの処理に時間がかかります。OLLAMA_NUM_PARALLEL=1 がリクエストを直列化しているためです。値を増やすと、リクエストごとのコンテキストは小さくなります。これを受け入れられない場合は、ワークロードを vLLM に移行します。
vLLM がすべての呼び出しに 401 を返します。 --api-key を指定して起動したのに、クライアントが Authorization ヘッダーを送信していません。OpenAI client libraries の多くは、キーとして渡した値をそのまま送信します。そのため、flag を削除するのではなく、クライアント側でキーを設定します。
vLLM がモデルが見つからないと表示します。 Ollama は必要に応じてモデルを取得しますが、vLLM は取得しません。リクエスト本文の model フィールドは、起動時に指定した repository id、または設定した場合は --served-model-name の値と一致する必要があります。curl http://localhost:8000/v1/models で正確な文字列を確認します。
両方を実行するのが妥当な選択です
両者は排他的ではありません。一般的な構成では、GPU instance 上の vLLM でアプリケーションに推論を提供し、通常の VPS 上の Ollama をローカルスクリプト、cron ジョブ、新しい model release の試用に使用します。どちらの endpoint も OpenAI-compatible であるため、1つの client library と base URL の切り替えで対応できます。ここでは、どちらの engine を選ぶかよりもコスト管理が重要です。アイドル状態の GPU でも稼働中の GPU と同じ料金が発生するためです。また、agent と inference のコストを予測可能に保つことは、server を選ぶこととは別の運用です。
FAQ
vLLMはOllamaより高速ですか？
同じGPUで単一のリクエストを処理する場合、差は小さめです。どちらも同じ計算を行うためです。多数のリクエストを同時に処理する場合は、vLLMが大幅に高速です。continuous batchingにより、アクティブな各シーケンスを1回のforward passでデコードできるためです。一方、Ollamaのデフォルト動作では、リクエストを1つずつ処理します。CPUのみのマシンでは、この比較は当てはまりません。OllamaはCPUで動作しますが、vLLMは実質的に動作しないためです。
vLLMはGPUなしで実行できますか？
実用的にはできません。標準のwheelはNVIDIAまたはAMDのGPUを対象としています。バッチ処理されたリクエストでアクセラレータを高稼働させることがvLLMの目的であるため、CPUではその利点が失われます。開発用のCPU backendは存在します。実際のCPU推論には、Ollamaまたはllama.cppを直接使用してください。
Ollamaとllama.cppの違いは何ですか？
llama.cppは推論ライブラリで、GGUFはその量子化済みweightの形式です。Ollamaのrunnerはllama.cppを基盤としており、llama.cppでは利用者に任される部分を追加します。具体的には、model registry、自動ダウンロード、常駐server、systemd unit、OpenAI互換endpointなどです。Ollamaは一部の新しいmodel family向けに独自のengineも追加しているため、内部実装はすでに同一ではありません。
8BモデルにはどれだけのGPUメモリが必要ですか？
16-bit精度では、weightだけで約16 GB必要です。これはパラメータ1 billionあたりおよそ2 GBに相当します。これに加えて、KV cache用の領域も必要です。24 GBのcardなら余裕があります。16 GBのcardでは、量子化済みcheckpointまたはより小さいmodelが必要です。vLLMは、--gpu-memory-utilizationで設定されたcard容量の一部を使用します。2026年7月時点のデフォルト値は0.92です。
これらを切り替えるには、アプリケーションコードを変更する必要がありますか？
通常はbase URL、API key、model nameだけを変更します。Ollamaはhttp://127.0.0.1:11434/v1でOpenAI互換surfaceを提供し、keyを無視します。一方、vLLMはhttp://localhost:8000/v1を提供し、keyを設定した場合はそれを適用します。model nameの形式は異なります。Ollamaではllama3.1:8b、vLLMではQwen/Qwen2.5-1.5B-Instructのような完全なrepository idを使用します。