SSD Nodes Learn Hosting plans →
ガイド Matt Connor著者 Matt Connor

OllamaとvLLMの違いと選び方

OllamaはCPUでも動く1人向けの便利なレイヤー、vLLMはGPUで多数のリクエストを処理するスループット重視のエンジンです。用途別の判断基準と実際のコマンドを紹介します。

Ollama と vLLM の違いを 1 段落で

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

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

Ollama の実体

Ollama は利便性を提供するレイヤーです。1 つのインストールコマンドで、モデルレジストリ (ollama pull llama3.1:8b)、重みのローカルストア、チャットプロンプト、systemd サービス、HTTP API を利用できます。提供されるモデルの多くは GGUF ファイルで、通常は 4-bit 量子化されています。そのため、7B または 8B モデルのディスク使用量は 16 GB ではなく約 5 GB です。量子化により、CPU 推論に必要なメモリを削減できます。Apple Silicon Mac では、MLX エンジンを介して safetensors ベースのモデルも実行できます。v0.40.0 (September 2026) 以降は、対応アーキテクチャが自動的に MLX 上で実行されます。

Ollama の GGUF ランナーは、一般的なハードウェアで GGUF 量子化を実用化した C++ 推論ライブラリ、llama.cpp を基盤としています。October 2026 時点で、Ollama は llama.cpp と MLX の 2 つのエンジンをサポートしています。Linux ビルドでは、CUDA による MLX 推論もサポートされます。開発ガイドでは cmake -B build . -DOLLAMA_MLX_BACKENDS=cuda_v13 によってこのバックエンドを有効化します。前提条件は CUDA 13+ と cuDNN 9+ です。そのため、Ollama と llama.cpp を比較する場合、実際には主に、ラッパーが提供する操作性のレイヤーと、そのラッパーが利用する本体を比較しています。

設計上の対象は 1 ユーザーです。October 2026 時点で、OLLAMA_NUM_PARALLEL のデフォルト値は 1 です。つまり、1 つのモデルが一度に処理するリクエストは 1 件で、それ以外はキューで待機します。キューのデフォルト容量は 512 エントリです (OLLAMA_MAX_QUEUE)。並列処理数は増やせますが、そのコストについては以下のセクションで説明します。Ollama をまだ実行したことがない場合は、VPS で Ollama をホストし、ポート 11434 を閉じたままにするから始めてください。ローカル API には認証が必要ないためです。

vLLM とは実際には何か

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

この限定された役割によって得られるのが、スループットです。これを実現する仕組みは 2 つあります。PagedAttention は、KV cache（key-value cache。モデルがアクティブな各リクエストについて保持する、トークンごとの attention 状態）を、オペレーティングシステムがメモリをページングする方法と同じように、固定サイズのブロックへ格納します。リクエストごとに最悪の場合を想定した大きな連続領域を予約する必要がなくなるため、これまで予約されたまま未使用だったメモリを、より多くの同時リクエストに利用できます。Continuous batching では、新しいリクエストを現在のバッチの完了まで待たせず、次のデコードステップで実行中のバッチに追加できます。シーケンスが完了すると、そのシーケンスは直ちにバッチから離れ、空いたスロットに別のリクエストが入ります。

実際の効果は次のとおりです。1 台の GPU で同時利用者を 1 人から 30 人に増やすと、合計の tokens per second は大きく増加します。一方、利用者 1 人あたりの速度は、予想するほど低下しません。Ollama のデフォルト設定では、利用者を 1 人から 30 人に増やすと、29 人が待たされるだけです。

継続的バッチ処理がすべてを変える

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

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

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

OLLAMA_NUM_PARALLEL=4 を設定すれば、この効果の一部を得られます。ただし、メモリが必要です。各並列スロットには独自の KV キャッシュが必要であり、Ollama はコンテキスト割り当てを分割せず、倍増させます。FAQ には、必要な RAM が OLLAMA_NUM_PARALLEL と OLLAMA_CONTEXT_LENGTH の積に応じて増えると記載されています。したがって、8192 トークンに設定したモデルに対して 4 件のリクエストを並列処理すると、各リクエストは 8192 トークンを保持しますが、サーバーは合計 32768 トークン分のキャッシュを保持する必要があります。この 8192 も固定値ではなく選択値です。そのため、num_ctx を増やし、必要な RAM を見積もることが、4 つのスロットを実際に収容できるかどうかを決めます。vLLM のページングキャッシュは、各スロットに全ウィンドウ分の領域をあらかじめ予約する必要をなくします。リクエストの進行に応じて、ブロックが割り当てられるためです。いずれの場合も、1 台のサーバーが同時に処理できる利用者数の上限は、KV キャッシュの容量、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 回測定した値は、容量を示す数値ではなく開始点です。そのため、同時実行数を変えて tokens per second を測定することで、実際に想定する負荷にそのサーバーが耐えられるか、また GPU を借りるほうが token 単位で支払うより有利かを判断できます。

同時実行数を増やすには、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 分続くとモデルがアンロードされるためです。リクエスト間もモデルを常駐させることで、最大 30 分のアイドル時間の後に最初のプロンプトを実行する際、毎回モデルのロード時間を負担せずに済みます。アイドル時間がそれより長くなる場合は、より長い値を設定してください。

vLLM のインストールと配信

vLLM の GPU ビルドには Linux が必要です（Apple Silicon 搭載 Mac では、0.32.0 リリースに含まれる事前ビルド済み wheel によって CPU のみサポートされます。これらの Mac で GPU アクセラレーションを使用するには、MLX を基盤とするコミュニティー保守の別プラグイン vLLM-Metal を使用します）。Python については、現在のリリース（0.32.0、2026 年 10 月）が 3.11 から 3.14 を受け付けており、インストールガイドにも同じ範囲が記載されています。Python 3.10 は 0.32.0 でサポート対象外になったため、以下で使用する 3.12 が安全な選択です。特定の PyTorch ビルドをインストールするため、専用の仮想環境にインストールします。

uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto
vllm download-kernels

2026 年 10 月時点で、最後の行は vLLM の NVIDIA インストールガイドに記載されています。FlashInfer のコンパイル済みカーネルをインストールします。これらがない場合、vLLM は起動時にカーネルをダウンロードしてコンパイルします。ガイドによると、Hopper 以降の GPU では数分かかることがあります。カーネルが一致しないと FlashInfer は import に失敗するため、vLLM をアップグレードするたびに再実行してください。

次に、モデルを配信します。名前には短いタグではなく、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 により、コンテナからホストの共有メモリにアクセスできるようになります。--shm-size を増やす方法もあります。PyTorch はプロセス間でテンソルを共有メモリ経由で渡します。テンソル並列推論では特に重要です。

本番環境で特に重要なフラグは、使用料金を許容できるコンテキストウィンドウを指定する --max-model-len、vLLM が GPU のメモリを使用できる割合を指定する --gpu-memory-utilization（2026 年 10 月時点のデフォルトは 0.92）、1 つのモデルを複数の GPU に分割する --tensor-parallel-size、および --api-key です。

vLLM では認証を 1 つのフラグで有効化できるが、Ollama のローカル API には認証がない

vLLM に bearer token を指定すると、vLLM はそのトークンを要求します。

vllm serve Qwen/Qwen2.5-1.5B-Instruct --api-key token-abc123

同じ値は VLLM_API_KEY 環境変数からも指定できます。/v1 へのリクエストは、トークンがない場合 HTTP 401 になります。ただし、このキーはサーバー全体を保護するものではありません。vLLM のセキュリティガイドと 0.32.0 のソースコードにある認証処理は、/v1、/v2、/inference、/cohere のパスプレフィックス配下にあるエンドポイントだけに適用されます。vllm serve ページの --api-key ヘルプには最初の 3 つしか記載されていませんが、コードは 4 つすべてを確認します。ガイドとヘルプの両方に、その他のエンドポイントは認証されないと記載されています。特に /invocations は /v1 と同じ推論機能を公開します。したがって、ポート 8000 をパブリックインターフェースで公開しない十分な理由になります。vLLM のセキュリティガイドでは、レート制限も vLLM の前段に置くリバースプロキシに任せています。また、平文 HTTP で送信したトークンは通信中に読み取られます。それでも、このフラグにより、サーバーは呼び出し元を識別する仕組みを持つことになります。

Ollama のローカル API には認証がありません。クラウドモデル、モデルの公開、非公開モデルのダウンロードにはサインインが必要です。ollama.com への直接 API アクセスには API key が必要です。11434 に到達できるプロセスであれば、モデルの実行、取得、削除が可能です。loopback 上だけで待ち受けさせ、自分でホストする WireGuard VPN 経由でアクセスしてください。または、TLS (transport layer security) を終端する認証付きリバースプロキシを使用してください。

ハードウェア: それぞれに必要なもの

Ollama は CPU で動作します。4-bit 量子化モデルでは、パラメータ 10 億個あたりおよそ 0.5 GB の RAM に加え、ランタイムのオーバーヘッドとして約 1 GB、さらにコンテキスト用の容量が必要です。そのため、3B モデルには約 4 GB、8B モデルには約 8 GB の空き容量が必要です。共有 vCPU での速度は、1 秒あたり 1 桁から 低い 2 桁程度のトークンです。これはメモリ帯域幅によるもので、設定ミスではありません。どの flag を指定しても改善しません。経験則ではなく、特定のリリースでこの計算結果を確認するには、VPS で Nemotron 3.5 Lightning を実行する方法を参照してください。取得する正確な tag、ロード後に保持される RAM 容量、CPU のみで実用的な速度が出るかどうかを確認できます。

vLLM は GPU を前提とします。デフォルトでは、16-bit 精度の量子化されていない重みを提供します。これはパラメータ 10 億個あたりおよそ 2 GB に相当します。8B モデルでは、重みだけで約 16 GB のビデオメモリが必要です。vLLM を導入した目的である同時実行性を実現する KV cache の容量は、これとは別に必要です。24 GB のカードなら、実用的な容量を cache に残せます。16 GB のカードでは足りません。その場合は、より小さいモデルを選ぶか、--quantization を指定します（量子化済み checkpoint を使用する場合、またはロード時に完全精度の重みを量子化する場合）。あるいは --cpu-offload-gb を使用して、重みの一部をシステム RAM に移します。後者では精度を維持できますが、各 forward pass で重みを GPU に転送するため、速度は低下します。CPU backend もありますが、専用の wheel が必要であり、vLLM を実行する理由自体が失われます。

したがって、ほとんどの場合、ハードウェアの選択がソフトウェアの選択を決めます。GPU がなければ Ollama です。レンタルした GPU の使用率が 5 percent にとどまっているのに、その原因がリクエストの直列処理であるなら vLLM です。

ワークロードに適しているのはどちらか

  • 1 人で使用する CPU VPS 上で、下書き作成や要約を行う場合: Ollama。速度は許容範囲で、これ以上簡単な選択肢はありません。
  • コーディングアシスタント、またはツールとローカルモデルを仲介する MCP サーバーを自分だけが呼び出す場合: Ollama。同時実行数 1 が実際のワークロードです。
  • 今週 5 個のモデルを比較する場合: Ollama。タグ付きモデルの取得と削除は Ollama が得意とする処理です。一方、vLLM ではモデルごとにプロセスの再起動が必要です。
  • 内部アプリ、チャット製品、または実ユーザーが利用する検索パイプラインの場合: vLLM。バッチ処理によって GPU 費用に見合う性能を得られるのはこの用途です。
  • 一晩で 100000 件のドキュメントを評価するバッチジョブの場合: vLLM と高い --max-num-seqs。重視すべき指標はスループットだけで、ドキュメントごとのレイテンシは重要ではありません。
  • 複数のセルフホスト AI エージェントが同時にモデルへアクセスするエージェントプラットフォームの場合: vLLM。エージェントからのトラフィックはバースト的で、本質的に並列処理になるためです。

エラーの種類と表示される文字列

vLLM が KV cache エラーで起動を拒否する

メッセージには両方の数値が示されます。

ValueError: To serve at least one request with the model's max seq len (32768), (4.00 GiB KV cache is needed, which is larger than the available KV cache memory (1.00 GiB). Based on the available memory, the estimated maximum model length is 8192. Try increasing `gpu_memory_utilization` (which also controls CPU memory on the CPU backend) or decreasing `max_model_len` when initializing the engine. See https://docs.vllm.ai/en/latest/configuration/conserving_memory/ for more details.

モデルが定義するコンテキストウィンドウが、重みの読み込み後に残るメモリより大きくなっています。--max-model-len 8192 で値を下げてください。カードを他の用途で使用していない場合は、--gpu-memory-utilization の値を上げる方法もあります。

Ollama が生成途中で Killed を出力する

Linux の out-of-memory killer がプロセスを停止しています。モデルが、ホストに搭載された RAM より多くのメモリを必要としたためです。sudo dmesg | grep -i oom で確認できます。対処方法は、より小さいモデルまたは量子化率の高いモデルに変更することです。設定を変更しても解決しません。

Ollama は単独では正常に応答するが、負荷をかけると停止する

どこにもエラーは表示されません。呼び出し元が増えるほど、リクエストの処理に時間がかかります。OLLAMA_NUM_PARALLEL=1 がリクエストを直列化しているためです。1 つの呼び出し元がモデルの停止まで唯一のスロットを占有すると、その後ろに並ぶすべてのリクエストが待たされます。長い応答ではキューがさらに悪化します。そのため、num_predict で応答を制限すると、1 回の応答がサーバーを占有できる時間に上限を設けられます。並列設定を引き上げる方法もありますが、スロットごとのコンテキストに必要な追加 RAM を受け入れる必要があります。別の方法として、ワークロードを vLLM に移行します。

vLLM がすべての /v1 呼び出しで 401 を返す

--api-key を指定して起動したにもかかわらず、クライアントが Authorization ヘッダーを送信していません。多くの OpenAI クライアントライブラリは、キーとして渡された値をそのまま送信します。したがって、フラグを削除するのではなく、クライアント側でキーを設定してください。

vLLM がモデルが見つからないと表示する

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

両方を実行するのが妥当な選択です

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

FAQ

vLLM は Ollama より高速ですか？

同じ GPU で単一のリクエストを処理する場合、差は小さい傾向があります。どちらも同じ計算を実行するためです。多数のリクエストを並行処理する場合は、vLLM が大幅に高速です。continuous batching により、アクティブなすべてのシーケンスを 1 回の forward pass でデコードする一方、Ollama のデフォルト動作では各シーケンスを順番に処理するためです。CPU のみのマシンでも、どちらにも対応する推論経路があります。vLLM では専用の CPU wheels を使用します。

vLLM は GPU なしで実行できますか？

はい。CPU backend を使用できます。標準の wheels は NVIDIA または AMD GPU を対象としており、バッチ化したリクエストでアクセラレーターを常に有効利用するという vLLM の目的は、CPU では失われます。CPU backend には x86 用と Arm 用の個別の wheels があります。実際に CPU で推論する場合は、Ollama または llama.cpp を直接使用してください。

Ollama と llama.cpp の違いは何ですか？

llama.cpp は推論ライブラリで、GGUF は量子化済み重みの形式です。Ollama は GGUF の推論に llama.cpp を使用し、モデルレジストリ、タグ付きダウンロード、モデル管理、systemd unit を追加します。Ollama には、Apple Silicon 上で safetensors ベースのモデルを実行する MLX engine も含まれています。また、Linux では CUDA builds をサポートするため、内部の実装が常に同じとは限りません。

8B モデルには、どの程度の GPU メモリが必要ですか？

16-bit precision では、重みだけで約 16 GB 必要です。これはパラメーター 1 billion 個あたり、およそ 2 GB に相当します。これに加えて、KV cache 用の容量も必要です。24 GB のカードなら余裕があります。16 GB のカードでは、量子化モデル、小さなモデル、または --cpu-offload-gb が必要です。--cpu-offload-gb を使用すると重みの一部を system RAM に移せますが、速度は低下します。vLLM が使用するカード容量の割合は --gpu-memory-utilization で決まり、2026 年 10 月時点のデフォルト値は 0.92 です。

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

通常は base URL、API key、model name だけを変更します。Ollama は http://127.0.0.1:11434/v1 で OpenAI-compatible surface を提供し、key を無視します。一方、vLLM は http://localhost:8000/v1 を提供し、設定している場合は /v1 routes で key を検証します。model names の形式は異なります。Ollama では llama3.1:8b、vLLM では Qwen/Qwen2.5-1.5B-Instruct のような完全な repository id を使用します。

この記事は役に立ちましたか？

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