VPSではOllamaとllama.cppのどちらを使う？

Ollama vs llama.cpp: どのレイヤーを運用しますか？

Ollama と llama.cpp は、この質問が示すような競合関係にはありません。llama.cpp は推論エンジンです。モデルファイルを読み込み、プロンプトをトークンに変換します。Ollama は、そのエンジンの上で動作するモデルマネージャー、バックグラウンドデーモン、HTTP API です。Ollama の README でも、推論バックエンドとして llama.cpp が現在も記載されています（2026年8月2日に確認）。つまり本当の問題は、どちらが高速かではなく、VPS 上でどのレイヤーを運用するかです。

名前を指定してモデルを取得し、手をかけずに動作し続けるサービスが必要なら、Ollama を実行します。サーバーが小さく、使用するモデルファイル、コンテキストサイズ、スレッド数を正確に選ぶ必要があるなら、llama.cpp を直接実行します。小規模な VPS では、これらの設定のどれも、利用できるメモリを消費するためです。

プロジェクトの実体

llama.cpp は、ggml ライブラリを基盤とする transformer 推論の C および C++ 実装です。GGUF ファイルを読み込みます。GGUF（GGML universal file format）は、モデルの実行に必要な重み、tokeniser、メタデータを格納する単一ファイルのコンテナです。このプロジェクトは、用途ごとに別のバイナリを提供します。llama-server は HTTP サーバー、llama-cli は対話型プロンプト、llama-bench はスループットを測定するツールです。リリースには semantic version ではなく、ビルド番号のタグが付けられます。現在のタグは b10224 で、2026 年 8 月 2 日に公開されました。ほとんどの平日には新しいタグが公開されます。

Ollama は Go プログラムです。ollama serve で起動するバックグラウンドデーモンがモデルを読み込み、HTTP リクエストに応答します。コマンドラインクライアントはこのデーモンと通信します。両方の背後では、ollama.com のレジストリがパッケージ済みのモデルを提供します。Ollama は semantic version を使用し、v0.32.5 は 2026 年 7 月 27 日にリリースされました。ollama pull は GGUF とプロンプトテンプレート、既定のパラメータ一式を取得し、Linux では /usr/share/ollama/.ollama/models に保存します。

このパッケージ方式が、両者の違いのすべてです。Ollama では、量子化方式、テンプレート、コンテキスト長を自分で決める必要がなく、覚える名前も 1 つで済みます。llama.cpp は何も決めず、フラグを提供します。

モデルと量子化を制御する軸

量子化により、各重みを 16 ビットまたは 32 ビットから 4、5、8 ビットへ縮小します。これにより、80 億パラメーターのモデルを一般的な VPS の RAM に収められます。パターンを理解すれば、GGUF の命名は読みやすくなります。Q4_K_M は、4 ビットの K 量子化で、中程度のサイズを意味します。数値が大きいほど精度は高くなりますが、より多くのメモリが必要です。

[
  {
    "label": "Q2_K",
    "file_size_gib": 2.96
  },
  {
    "label": "Q3_K_M",
    "file_size_gib": 3.74
  },
  {
    "label": "Q4_K_M",
    "file_size_gib": 4.58
  },
  {
    "label": "Q5_K_M",
    "file_size_gib": 5.34
  },
  {
    "label": "Q6_K",
    "file_size_gib": 6.14
  },
  {
    "label": "Q8_0",
    "file_size_gib": 7.95
  }
]

これらは Hugging Face の bartowski/Meta-Llama-3.1-8B-Instruct-GGUF リポジトリで公開されているファイルサイズです。2026 年 8 月 2 日に読み取り、バイトから GiB に変換しました。1 つのモデルに 6 個のビルドがあり、最小のファイルは 2.96 GiB、最大のファイルは 7.95 GiB です。一般的なデフォルトである Q4_K_M は 4.58 GiB です。4 GiB の VPS では、この選択だけでモデルを読み込めるかどうかが決まります。

llama.cpp ではファイル名を指定するため、その行を自分で選びます。

llama-server -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
  -c 4096 -t 4 --host 127.0.0.1 --port 8080

-c はトークン単位のコンテキストサイズ、-t はスレッド数、-ngl は GPU に移すレイヤー数です（CPU のみのホストでは 0）。値が自動的に推測されることはありません。

Ollama では、量子化は pull するタグに含まれており、ollama ls で実際にディスク上にある内容を確認できます。レジストリに必要なビルドがない場合は、GGUF を自分でインポートします。Modelfile を記述します。

FROM ./Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf
PARAMETER num_ctx 4096

次にビルドし、結果を確認します。

ollama create llama31-q4 -f ./Modelfile
ollama ls

コンテキスト長は、問題になりやすい設定です。Ollama は利用可能な VRAM からデフォルト値を選びます。GPU のないホストでは最小の区分になり、4096 トークンになります。20,000 トークンの文書を渡すと、モデルが見る前に超過分のトークンが破棄されます。そのため、文書を半分しか読んでいないのに、ファイルの内容について確信ありげに誤った回答を返します。デーモンでは OLLAMA_CONTEXT_LENGTH を使用し、Modelfile では PARAMETER num_ctx を使用して値を引き上げます。llama.cpp にも、無条件に信頼できるデフォルトはありません。-c を明示的に設定し、設定値を把握してください。

誰も示してくれないメモリ計算

モデルファイルがコストのすべてではありません。KV キャッシュ（key/value cache）はコンテキスト内のトークンごとに、各レイヤーのエントリを保持します。そのため、会話が長くなるほど増加します。

Llama 3.1 8B で計算してみます。このモデルには 32 レイヤー、8 個の key/value ヘッド、128 のヘッド次元があります。f16 では、各トークンが key と value をそれぞれ 2 bytes で保持するため、1 レイヤーあたりの容量は 2 x 8 x 128 x 2 = 4096 bytes です。32 レイヤー全体では、1 トークンあたり 128 KiB になります。4096 トークンのコンテキストでは 512 MiB、32,768 トークンのコンテキストでは 4 GiB が必要です。

そのため、Q4_K_M 8B モデルを 4k コンテキストで使用する場合、重みに約 4.58 GiB、キャッシュに約 0.5 GiB、さらにランタイム自体の容量が必要です。4 GiB の RAM には収まりません。8 GiB なら、処理用の余裕を残して収まります。同じ 8 GiB の環境でコンテキストを 32k に増やすと、キャッシュだけで余裕を使い切ります。モデルの読み込み中に free -h で実際の使用量を確認し、測定していない推定値をそのまま信頼しないでください。

Ollama では、この影響がさらに大きくなります。OLLAMA_NUM_PARALLEL のデフォルト値は 1 で、モデルに必要なメモリはその値とコンテキスト長の積に応じて増加します。両方を同時に増やすと、デーモンは想定していた RAM の数倍を静かに要求します。

軸 2: 運用するデーモン

Ollama のインストールスクリプトは systemd の unit を書き込み、ollama system user を作成して、サービスを有効化します。これらを自分で記述しなくても、ライフサイクルを管理できます。設定は systemd を通じて行います。

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -e -u ollama

OLLAMA_KEEP_ALIVEは、他の環境よりも CPU VPS で重要になります。モデルはデフォルトで 5 分間メモリに保持され、その後アンロードされます。次のリクエストでは、応答する前にファイル全体をディスクから読み直す必要があります。そのため、低速なストレージでは 4.58 GiB の再読み込みにより、2 秒の応答が 30 秒になります。keep-alive を長くするとレイテンシは解消できますが、RAM を恒久的に消費します。どちらにも実際のコストがあります。影響の小さい方を選択してください。

llama.cpp にはデーモンがないため、/etc/systemd/system/llama-server.serviceとして unit を自分で記述します。

[Unit]
Description=llama.cpp server
After=network-online.target

[Service]
ExecStart=/usr/local/bin/llama-server -m /srv/models/model-Q4_K_M.gguf -c 4096 -t 4 --host 127.0.0.1 --port 8080
Restart=always
RestartSec=3
User=llama

[Install]
WantedBy=multi-user.target

sudo systemctl enable --now llama-serverで有効化します。プロセスはその存続期間全体にわたってモデルを保持します。アイドル状態になってもアンロードされないため、再読み込みによる予期しない遅延はありません。一方、サービスを停止しない限りメモリを解放できません。unit の記述が初めてでも、VPS で systemd の下で自分のサービスを実行する場合と同じパターンです。

軸 3: アプリケーションが接続する API

この軸での差はかなり小さくなっています。現在は両方のプロジェクトが OpenAI chat 形式に対応しているため、base URL を変更するだけで、ほとんどのクライアントライブラリをどちらでも利用できます。

Ollama は 127.0.0.1:11434 で待ち受けます。OpenAI 互換の route は http://localhost:11434/v1/chat/completions で、これとは別にネイティブ API の /api/chat も提供します。Anthropic 互換の route もドキュメント化されています。

curl -X POST http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "llama31-q4", "messages": [{"role": "user", "content": "Say this is a test"}]}'

llama-server は 127.0.0.1:8080 で待ち受け、/v1/chat/completions、/v1/completions、/v1/embeddings を提供します。さらに、独自の /completion endpoint と組み込みの Web UI も備えています。また、Ollama にはない運用向け route も公開しています。/health は readiness probe 用、/props はロード済みモデルの設定用、/slots は各 request slot の処理内容用、/metrics は Prometheus 形式のメトリクス用です。このサービスを監視する予定がある場合、この違いが選択の決め手になる可能性があります。

どちらのサーバーも、認証を自動的に有効にすることはありません。安全上の理由から、デフォルトでは loopback で待ち受けます。SSH tunnel 経由、または reverse proxy の背後から接続し、11434 や 8080 をインターネットに直接公開しないでください。

CPU だけの VPS で現実的にできること

CPU だけの VPS では、小さなモデルを低速で実行できます。これが正直な要約です。重要なのは、実用性の境界がどこにあるかを把握することです。VPS を前提に設計する前に、測定してください。

llama-bench -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -p 512 -n 128

pp列はプロンプト処理速度、tg列はトークン生成速度を示し、どちらも 1 秒あたりのトークン数です。共有 vCPU プランでは、Q4_K_M の 8B モデルの場合、tgは通常、1 桁台前半に収まります。特に負荷が大きいのはプロンプト処理です。最初の出力トークンが現れる前にプロンプト全体を処理するため、長いシステムプロンプトはすべてのリクエストに待ち時間を追加します。

CPU で実用になるのは、分類、情報抽出、短い要約、ルーティングなどを行う 1B から 4B のモデルです。数秒で応答が返り、通常のプランに収まるメモリ量で動作します。CPU では実用にならないのは、読む速度での対話型チャット、コーディングアシスタント、長文書の処理、またはエージェントループが短時間に多数の呼び出しを行う処理です。4 秒かかる呼び出しを 12 回行うループでは、何かを出力するまでに 1 分かかります。

数値が要件を満たさない場合の選択肢は 2 つあります。問題が同時実行数、つまり複数のユーザーが同時に 1 つのモデルへアクセスすることにあるなら、エンジンの選択が変わります。同時実行向けの Ollama と vLLM の比較で詳しく説明しています。問題が処理速度そのものなら、GPU を接続した VPSが選択肢になります。この場合、-nglが実用的な指標になります。どちらを選ぶ場合も、まずハードウェア自体のベースラインを取得してください。ディスク帯域幅とメモリ帯域幅も、CPU と同じようにロード時間に影響するためです。再現可能な VPS ベンチマークには 1 時間をかける価値があります。

llama.cpp を特定のビルドに固定してインストールする

両プロジェクトは毎週更新されるため、デプロイしたバージョンを記録してください。upstream のワンライナーでは、現在のビルドがインストールされます。

curl -LsSf https://llama.app/install.sh | sh
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

特定のビルドに固定するには、代わりに releases ページから prebuilt tarball を取得してください。2026年8月2日時点の current tag は build b10224 です。

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b10224/llama-b10224-bin-ubuntu-x64.tar.gz
tar xf llama-b10224-bin-ubuntu-x64.tar.gz
find . -type f -name 'llama-server'

または、同じ tag をソースからビルドしてください。

sudo apt update && sudo apt install -y build-essential cmake git libssl-dev
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
git checkout b10224
cmake -B build
cmake --build build --config Release -j $(nproc)

HTTPS 機能に必要な依存関係として、libssl-dev がドキュメントに記載されています。コンパイルには数分かかり、最小プランのメモリでは不足する可能性があります。その場合は、大きいマシンでビルドしてバイナリを小さいマシンへコピーしてください。

バージョンを固定して Ollama をインストールする

curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.32.5 sh
ollama -v

このスクリプトは OLLAMA_VERSION を読み取るため、今朝リリースされたバージョンをそのまま使用せず、動作確認済みのリリースを固定できます。v0.32.5 は 27 July 2026 に公開されました。スクリプトをシェルにパイプしたくない場合は、手動でインストールする方法もあります。

sudo rm -rf /usr/lib/ollama
curl -fsSL https://ollama.com/download/ollama-linux-amd64.tar.zst | sudo tar x -C /usr
ollama -v

手動でインストールする場合、systemd unit とサービスユーザーは作成されません。そのため、自分で追加する必要があります。VPS 上で Ollama を設定する手順全体では、このサービス設定を手順ごとに説明しています。

失敗するケースと表示される文字列

Ollama がモデルの読み込みを拒否する。 ollama run は次の形式の行を返します。

Error: model requires more system memory (5.6 GiB) than is available (3.2 GiB)

Ollama は読み込み前にサイズを確認するため、すぐに失敗し、理由を表示します。量子化の行を1つ下げる、コンテキスト長を短くする、または小さいモデルを選択してください。

llama.cpp は失敗せず、処理が極端に遅くなる。 llama.cpp はデフォルトで GGUF をメモリマップするため、RAM より大きいファイルでも起動します。その後、カーネルが各トークンの生成時にディスクから重みを繰り返し読み書きし、ディスク使用率が100パーセントに張り付いたまま、生成速度が1トークンあたり数秒まで低下します。--no-mmap を渡すと実際にメモリを確保するため、性能が低下する前にすぐ失敗します。カーネルが介入した場合は、dmesg に理由が表示されます。

Out of memory: Killed process 1234 (llama-server)

モデルファイルをまったく読み込めない。 使用しているエンジンより新しいモデルファミリー向けに作成された GGUF を読み込むと、認識できないアーキテクチャ名を含むエラーが表示されます。

error loading model architecture: unknown model architecture: 'qwen3next'

必要なのは別のファイルではなく、エンジンのアップグレードです。これはバージョンを固定する際の代償であり、ビルド番号を記録しておく理由でもあります。アップグレード元のバージョンを把握しておく必要があります。

API はローカルでは応答するが、アプリからは応答しない。 Ollama は 127.0.0.1:11434 にバインドするため、別のホストから接続すると connection refused になります。ポートがファイアウォールまたはプライベートネットワークの内側にある場合に限り、OLLAMA_HOST=0.0.0.0:11434 を systemctl edit ollama で設定してください。API の前段には認証がないためです。

一時停止後の最初の応答が非常に遅い。 5分間アイドル状態が続いたためアンロードが発生し、モデルが再びディスクから読み込まれています。リクエストの直前に ollama ps を実行して何も読み込まれていなければ、これが確認できます。OLLAMA_KEEP_ALIVE を増やしてください。

では、どちらを実行すべきでしょうか。

モデル管理を任せ、追加作業なしで OpenAI 形式のエンドポイントを利用したい場合は、Ollama を実行します。初回デプロイの標準的な選択肢であり、モデルを頻繁に変更する構成にも適しています。

メモリに余裕がなく、量子化の行を自分で選ぶ必要がある場合は、llama.cpp を直接実行します。監視用に /health、/slots、/metrics を使用したい場合や、Ollama で公開されていないフラグが必要な場合にも適しています。モデルがかろうじて収まる VPS では、これが適切な選択です。モデルを収めるための設定を、Ollama が代わりに選択するためです。

両方を実行しても問題ありません。実験には Ollama を使用し、本番環境に配置して変更したくない 1 つのモデルには llama.cpp を使用します。

FAQ

Ollama は llama.cpp の単なるラッパーですか？

近いですが、ラッパーは実際の処理も担います。Ollama の README では、llama.cpp が推論バックエンドとして記載されています（2026 年 8 月 2 日確認）。Ollama はその上に、モデルレジストリ、チャットメッセージをプロンプトに変換するプロンプトテンプレート、デフォルトのサンプリングパラメーター一式、アイドル時にモデルをアンロードするデーモン、HTTP API を追加しています。同じ設定で tokens per second を比較する場合、同じエンジン同士を比較しています。実際に選択しているのは、管理レイヤーです。

CPU のみの VPS では、どちらが高速ですか？

同じエンジンを共有しているため、同じモデルファイル、量子化、コンテキストサイズ、スレッド数であれば、結果はほぼ同じです。報告される差は通常、エンジンではなく、異なるデフォルト設定、特にコンテキスト長とスレッド数に起因します。llama-bench -m <file> -p 512 -n 128 で測定し、公開されている数値を信じる前に、自分のサーバーで tg 列を比較してください。

自分の GGUF ファイルを Ollama で使用できますか？

はい。ファイルをサーバーに配置し、1 行目が FROM ./your-model.gguf になる Modelfile を作成します。必要に応じて、num_ctx などの PARAMETER 行を追加し、その後 ollama create your-name -f ./Modelfile を実行します。ollama ls を実行すると、レジストリから取得したモデルと並べて一覧表示されます。これにより、レジストリで提供されていない量子化を使用できます。

8B モデルにはどの程度の RAM が必要ですか？

ファイルサイズに KV キャッシュとランタイムの分を加えて見積もります。Llama 3.1 8B の Q4_K_M ビルドはディスク上で約 4.58 GiB です。4096 トークンのコンテキストではキャッシュが約 512 MiB 増えるため、RAM 8 GiB なら十分ですが、4 GiB では不足します。キャッシュ容量はコンテキストに応じて増加します。同じモデルでコンテキストを 32,768 トークンにすると、キャッシュだけで約 4 GiB 必要です。Ollama では、必要量が OLLAMA_NUM_PARALLEL に応じても増加する点に注意してください。