SSD Nodes Learn Hosting plans →
ガイド Matt Connor著者 Matt Connor ・更新日 2026-08-26

OllamaとvLLMの違いと選び方

OllamaはCPUでも使える1人向けの利便性重視、vLLMはGPUで多数の同時リクエストを処理するスループット重視です。用途別の選び方と実際のコマンドを紹介します。

Ollama と vLLM の比較

Ollama はサーバー機能を備えたモデルマネージャーです。量子化済みの重みをダウンロードして読み込み、マシンに CPU しかない場合は CPU 上で 127.0.0.1:11434 に応答します。vLLM はスループット向けのエンジンです。多数のリクエストを同時に実行して GPU を最大限に使用するため、GPU のないマシンには適していません。判断基準はこれだけです。1 人がローカルアシスタントを利用するなら Ollama の用途です。チーム向けにアプリケーションを提供するなら vLLM の用途です。

どちらも OpenAI 互換の HTTP API を使用するため、base URL を変更するだけでクライアントコードを移行できます。違いは API ではありません。最初のリクエストがまだトークンを生成している間に、2 番目のリクエストが到着したときの処理が異なります。

Ollama の実体

Ollama は利便性を提供するレイヤーです。1 つのインストールコマンドで、モデルレジストリ（ollama pull llama3.1:8b）、重みのローカル保存領域、チャットプロンプト、systemd サービス、HTTP API を利用できます。Ollama が提供するモデルは GGUF ファイルで、通常は 4-bit 量子化されています。そのため、7B または 8B のモデルは、ディスク上で 16 GB ではなく約 5 GB になります。量子化によって、CPU での推論が実用になります。

Ollama の runner は、C++ 推論ライブラリである llama.cpp を基盤としています。llama.cpp によって、一般的なハードウェアで GGUF 量子化を実用的に扱えるようになりました。その後、Ollama は一部の新しいモデルファミリー向けに独自のエンジンも追加しましたが、提供する機能の大部分では現在も llama.cpp が基盤です。そのため、Ollama と llama.cpp の比較は、主にラッパーである操作性レイヤーと、それがラップする本体の比較です。

想定されている利用者は 1 人です。2026 年 7 月時点で、OLLAMA_NUM_PARALLEL のデフォルト値は 1 です。つまり、1 つのモデルが一度に処理するリクエストは 1 件だけで、それ以外のリクエストはデフォルトで 512 件を保持できるキュー（OLLAMA_MAX_QUEUE）で待機します。parallel 設定の値は増やせますが、その場合のコストについては次のセクションで説明します。Ollama をまだ実行したことがない場合は、VPS で Ollama をホストし、ポート 11434 を閉じたままにする方法から始めてください。API には認証機能が一切ないためです。

vLLM とは実際には何か

vLLM は推論サーバーであり、それ以外の機能はありません。モデルライブラリを管理せず、チャットプロンプトも持たず、リクエスト時にモデルを取得することもありません。起動時に Hugging Face のリポジトリを指定すると、そのモデルだけを読み込み、プロセスを停止するまで提供します。

このように機能を絞ることで、スループットを高めています。主に 2 つの仕組みが使われます。PagedAttention は、KV キャッシュ（key-value cache。アクティブな各リクエストについてモデルが保持する、トークンごとのアテンション状態）を、オペレーティングシステムがメモリをページングするように、固定サイズのブロックへ分割して保存します。これにより、最悪の場合に必要なサイズの大きな連続領域を、リクエストごとに予約する必要がなくなります。そのため、以前は予約されたまま未使用だったメモリを、より多くの同時リクエストに利用できます。Continuous batching では、実行中のバッチが完了するまで待たず、次のデコードステップで新しいリクエストを実行中のバッチに参加させられます。シーケンスが完了すると、直ちにバッチから削除され、そのスロットに別のリクエストが入ります。

実際の効果は明確です。1 台の GPU で同時ユーザー数を 1 から 30 に増やすと、合計の tokens per second は大きく増加します。一方、ユーザーごとの速度の低下は、予想するほど大きくありません。Ollama のデフォルト設定では、ユーザー数を 1 から 30 に増やすと、29 人が待つだけです。

Continuous batching が決定的な違いです

同じハードウェアの各サーバーに、5 件のリクエストが同時に到着したとします。

Ollama はデフォルト設定では、1 件目のリクエストを完了してから2 件目を処理し、その後も同じように処理します。5 件目の利用者は、4 回分の生成が完全に終わるまで待つことになります。プロセッサーが常に1 系列だけを処理するため、全体のスループットはおおむね1 回分の生成速度にとどまります。

vLLM は、5 系列すべてを同じ forward pass でデコードします。5 系列に対して1 token を生成するコストは、1 系列に対して1 token を生成するコストをわずかに上回る程度です。負荷の大部分はモデルの重みをメモリから読み出す処理であり、その読み出しをバッチ全体で共有できるためです。これは CPU 推論が遅くなる理由と同じメモリ帯域幅の特性です。コストの中心は演算ではなく、重みの移動です。

OLLAMA_NUM_PARALLEL=4 を設定すれば、この効果の一部を得られます。ただし、メモリを消費します。並列スロットごとに独自の KV cache が必要です。また Ollama はコンテキストウィンドウをスロット間で分割するため、8192 token に設定したモデルで4 件のリクエストを並列処理すると、各リクエストで利用できるコンテキストは2048 token になります。この8192 という値自体も固定値ではなく選択値です。そのため、num_ctx を増やし、その分の RAM を見積もることが、4 スロットを実用できるかどうかを決めます。vLLM の paged cache は、リクエストの実際の増加に応じてブロックを割り当てるため、このトレードオフを回避できます。いずれの場合も、1 台のサーバーが同時に処理できる利用者数の上限は、KV cache のサイズ、prefill のコスト、キューの深さで決まります。これが、1 人なら問題なく動作したサーバーが5 人では遅くなる理由です。

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 system user を作成し、バイナリをインストールして、127.0.0.1:11434 にバインドされた ollama.service を登録します。--verbose が出力する eval rate の値が、その環境での実測 tokens per second です。公開されている数値よりも、この値を信頼してください。1 つのプロンプトで 1 回測定した値は、処理能力を示す数値ではなく出発点です。実際に想定する負荷でその環境が耐えられるか、また token 単位で支払うより GPU を借りた方がよいかを判断するには、同時実行数を変えて 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 ps

ollama ps で読み込まれている設定を確認でき、PROCESSOR 列に実際の値が表示されます。100% CPU は GPU が使用されていないことを意味します。Ollama が遅いという報告の多くは、これが正直な原因です。この drop-in の OLLAMA_KEEP_ALIVE=30m 行は、負荷の低い環境でも同じように重要です。デフォルトでは、リクエストがない状態が 5 分続くとモデルがアンロードされるためです。リクエスト間もモデルを常駐させることで、1 時間アイドル状態が続いた後の最初のプロンプトで、再び完全なロード時間が発生するのを防げます。

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、vLLM が GPU メモリを使用できる割合を指定する --gpu-memory-utilization（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 を public interface で公開する理由にはなりません。vLLM には rate limiting がなく、平文の HTTP token は通信中に読み取れるためです。一方で、サーバーが呼び出し元を識別する仕組みを持つことは意味します。

Ollama にはそのような仕組みがありません。key、login、allow-list はありません。11434 に接続できるプロセスは、モデルの実行、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 桁から低い 2 桁程度のトークン数です。これはメモリ帯域幅によるもので、設定ミスではありません。どのフラグを指定しても改善しません。目安ではなく、特定のリリースでこの計算結果を確認するには、VPS で Nemotron 3.5 Lightning を実行する方法を参照してください。取得する正確なタグ、ロード後に占有する RAM、CPU のみで実用的な速度が出るかを確認できます。

vLLM は GPU を前提とします。デフォルトでは、16-bit 精度の非量子化重みを提供します。必要なビデオメモリはパラメータ 10 億個あたりおよそ 2 GB です。8B モデルでは、重みだけで約 16 GB のビデオメモリが必要です。さらに、vLLM を導入した目的である同時実行性を実現する KV キャッシュの分も必要になります。24 GB のカードなら、実用的な容量のキャッシュを確保できます。16 GB のカードでは確保できないため、より小さいモデルを選ぶか、量子化済みチェックポイントとともに --quantization を指定します。CPU バックエンドもありますが、標準の wheel は CPU 用にビルドされていません。また、CPU で使うと vLLM を実行する意味が失われます。

したがって、ほとんどの場合、ハードウェアの選択がソフトウェアの選択を決めます。GPU がないなら Ollama を選びます。リクエストが直列化されているため、レンタルした GPU の使用率が 5% にとどまるなら vLLM を選びます。

ワークロードに適した方

  • 1 人で使用する CPU VPS で、下書き作成や要約を行う場合: Ollama。速度は許容範囲で、これ以上簡単な選択肢はありません。
  • コーディングアシスタント、または ツールをローカルモデルに接続する MCP サーバーを自分だけが利用する場合: Ollama。同時実行数 1 が実際のワークロードです。
  • 今週 5 つのモデルを比較する場合: Ollama。タグ付きモデルの取得と削除に適しており、vLLM ではモデルごとにプロセスを再起動する必要があります。
  • 内部アプリ、チャット製品、または実ユーザーが利用する検索パイプラインの場合: vLLM。バッチ処理によって GPU コストに見合う性能を得られるのは、この用途です。
  • 一晩で 100,000 件のドキュメントを評価するバッチジョブの場合: 高い --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.

モデルが宣言するコンテキストウィンドウが、重みを読み込んだ後に残るメモリより大きくなっています。--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 がリクエストを直列化しているためです。1 つの呼び出し元がモデルの停止判断まで唯一のスロットを占有するため、長い応答ではキューがさらに悪化します。そのため、num_predict で応答を制限すると、1 回の処理がサーバーを占有できる時間に上限を設定できます。並列設定を引き上げて、リクエストごとのコンテキストが小さくなることを受け入れるか、ワークロードを vLLM に移行します。

vLLM がすべての呼び出しに 401 を返す。 --api-key を指定して起動したにもかかわらず、クライアントが Authorization ヘッダーを送信していません。多くの OpenAI クライアントライブラリは、キーとして渡した値をそのまま送信します。そのため、flag を削除するのではなく、クライアント側でキーを設定します。

vLLM がモデルが見つからないと表示する。 Ollama は必要に応じてモデルを取得しますが、vLLM は取得しません。リクエスト本文の model フィールドは、起動時に指定した repository id、または設定した場合は --served-model-name の値と一致している必要があります。curl http://localhost:8000/v1/models で正確な文字列を確認します。

両方を稼働させるのも合理的な選択です

両者は排他的ではありません。一般的な構成では、GPU インスタンス上の vLLM でアプリケーションに推論サービスを提供し、通常の VPS 上の Ollama はローカルスクリプト、cron ジョブ、新しいモデルリリースの試行に使用します。どちらのエンドポイントも OpenAI 互換であるため、1 つのクライアントライブラリと base URL の切り替えで対応できます。ここでは、どちらのエンジンを選ぶかよりもコスト管理が重要です。アイドル状態の GPU にも稼働中と同じ料金が発生するためです。また、エージェントと推論のコストを予測可能に保つことは、サーバーの選定とは別の運用課題です。

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 を基盤としており、model registry、automatic download、常駐サーバー、systemd unit、OpenAI 互換 endpoint など、llama.cpp では利用者が用意する部分を追加しています。Ollama は一部の新しい model family 向けに独自の engine も追加しているため、内部の実装はもはや完全に同一ではありません。

8B model にはどの程度の GPU memory が必要ですか？

16-bit precision では、weight だけで約 16 GB 必要です。これはおよそ 10 億パラメーターあたり 2 GB で、これに加えて KV cache の領域も必要です。24 GB のカードなら余裕があります。16 GB のカードでは、quantized checkpoint またはより小さい model が必要です。vLLM は、カード容量のうち --gpu-memory-utilization で指定した割合を使用します。この値は 2026 年 7 月時点でデフォルトが 0.92 です。

それらを切り替えるとき、アプリケーションコードを変更する必要はありますか？

通常は base URL、API key、model name だけを変更します。Ollama は http://127.0.0.1:11434/v1 で OpenAI 互換の interface を提供し、key を無視します。一方、vLLM は http://localhost:8000/v1 を提供し、key を設定した場合はそれを必須にします。model name の形式は異なります。Ollama では llama3.1:8b、vLLM では Qwen/Qwen2.5-1.5B-Instruct のような完全な repository id を使用します。

#ollama#vllm#llm#inference#self-hosting