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 では、これらの設定の1つ1つが、余裕のないメモリを消費するためです。

実際の各プロジェクトの概要

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 に保存します。これらのファイルは root ディスクに保存され、1 つあたり数 GB に達します。そのため、root ボリュームが 25 GB の VPS では、3 回目のダウンロードでディスクが満杯になる前に、pull 後に残るファイルとモデルディレクトリを別の場所へ移動する方法を確認しておくとよいでしょう。

このパッケージングの違いが、両者の本質的な違いです。Ollama は量子化方式、テンプレート、コンテキスト長を自動的に決め、覚える名前を 1 つにまとめます。llama.cpp は何も決めず、各種 flags を提供します。

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

量子化により、各重みを 16 ビットまたは 32 ビットから 4、5、8 ビットへ縮小します。これにより、80 億パラメーターのモデルを一般的な VPS の RAM に収められます。パターンを知っていれば、GGUF の命名は読みやすくなります。Q4_K_M は 4 ビットの K-quant で、サイズが medium であることを示します。数字が大きいほど精度を多く維持しますが、必要なメモリも増えます。

[
  {
    "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 では、この選択だけでモデルを読み込めるかどうかが決まります。ただし、サイズは判断材料の半分にすぎません。収められる行が、必ずしも使用する価値のある行とは限らないためです。Q4、Q8、fp16 が回答品質に実際に与えるコストを確認すれば、追加のギガバイトが体感できる効果をもたらすか判断できます。

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 を自分で import します。Modelfile を記述します。

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

続いて build し、結果を確認します。

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

コンテキスト長は、問題になりやすい設定です。Ollama は利用可能な VRAM からデフォルト値を選択します。GPU のないホストでは最小の 4096 トークンになります。20,000 トークンの文書を渡すと、モデルが文書を見る前に超過分のトークンが破棄されます。そのため、モデルが文書を半分しか読んでいないのに、回答は自信ありげに誤った内容になります。デーモンでは OLLAMA_CONTEXT_LENGTH、Modelfile では PARAMETER num_ctx を使って増やします。大きなウィンドウが必要なジョブが 1 つだけなら、num_ctx はサーバー全体ではなくリクエスト単位で設定できます。これにより、デーモンが処理する他のすべての処理に余分なキャッシュが割り当てられることを防げます。llama.cpp にも、そのまま信頼できるデフォルト値はありません。-c を明示的に設定し、設定値を把握してください。

誰も示さないメモリ計算

モデルファイルだけが必要なメモリの全量ではありません。KV cache（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、さらにランタイム自体のメモリが必要です。RAM が 4 GiB の環境には収まりません。8 GiB なら余裕を持って動作します。同じ 8 GiB の環境でコンテキストを 32k に増やすと、キャッシュだけで空きメモリを使い切ります。モデルの読み込み中に free -h で実際の使用量を確認し、測定していない推定値を信用しないでください。8B を大きく超えるモデルを想定して容量を決める場合は、CPU のみの VPS で 27B モデルを動かす例で同じ計算を実際に行っており、8 GB から 64 GB までの各容量で何が保持できるかを確認できます。

Ollama では、これがさらに増幅されます。OLLAMA_NUM_PARALLEL のデフォルト値は 1 で、モデルに必要なメモリはこの値とコンテキスト長の積に応じて増加します。両方を同時に増やすと、デーモンは想定していた RAM の数倍を静かに要求します。この計算によって、同時に処理できるユーザー数の上限も決まります。各同時リクエストが KV cache の専用領域を必要とするためです。これは、1 人なら問題なく動くサーバーが 5 人で停止する理由でもあります。

Axis 2: 運用するデーモン

Ollama のインストールスクリプトは systemd unit を書き込み、ollama system ユーザーを作成して、サービスを有効化します。これらのライフサイクル管理を自分で記述する必要はありません。設定は 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 を継続的に消費します。どちらも実際のコストです。影響の小さい方を選択してください。モデルを常駐させる場合は、アイドル期間や再起動後も保持されるよう keep_alive を設定する方法を使えば、数行の設定で済み、サーバーを再起動するたびに手動でモデルをウォームアップする必要がなくなります。

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

[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 format に対応しているため、base URL を変更するだけで、ほとんどの client library をどちらでも利用できます。

Ollama は 127.0.0.1:11434 で待ち受けます。OpenAI-compatible route は http://localhost:11434/v1/chat/completions で、これとは別に native API の /api/chat も提供します。Anthropic-compatible 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 はロード済み model の設定用、/slots は各 request slot の処理状況用、/metrics は Prometheus format 用です。このサービスを monitor する予定がある場合、この違いが選択を決める可能性があります。

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

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

CPU のみの VPS では、小規模なモデルを低速で実行できます。これが率直な要約です。重要なのは、どこまで実用になるかを把握することです。構成を決める前に測定してください。

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

pp列はプロンプト処理速度、tg列はトークン生成速度を示し、単位はいずれも tokens per second です。共有 vCPU プランでは、8B モデルを Q4_K_M で実行すると、tgは通常、1 桁台前半になります。特に負荷が大きいのはプロンプト処理です。最初の出力トークンが表示される前にプロンプト全体を処理するため、長い system prompt はすべてのリクエストに待ち時間を追加します。応答の長さは、実際に制御できる処理量の半分です。毎秒 3 tokens の場合、600 tokens の長い応答を生成するモデルは VPS を 3 分間占有します。そのため、num_predict で出力を制限することが、1 回の冗長な応答によるタイムアウトを防ぐ最も安価な方法です。

CPU で実用になるのは、分類、情報抽出、短い要約、ルーティングを行う 1B から 4B のモデルです。応答は数秒で返り、通常のプランに収まるメモリで動作します。このサイズ範囲ではなく、具体的なサイズの実例を確認するなら、VPS に Nemotron 3.5 Lightning を取得して測定することで、正確な tag、実際に必要な RAM、GPU なしで維持できる速度を確認できます。CPU では、読む速度での対話型チャット、コーディングアシスタント、長文書の処理、または多数の呼び出しを順番に実行する agent loop は実用的ではありません。1 回 4 秒かかる呼び出しを 12 回行う loop では、何かを出力するまでに 1 分かかります。コーディングアシスタントが目的であれば、自分でホストするモデルを agent に接続することで、小規模なローカルモデルが実際に適する作業と、hosted API に任せるべき作業を整理できます。

数値が合わない場合の選択肢は 2 つあります。問題が同時実行数、つまり多くのユーザーが 1 つのモデルに同時アクセスすることなら、engine の選択を変えます。同時 serving における Ollama と vLLM の比較で詳しく説明しています。問題が純粋な速度なら、GPU を接続した VPSが答えです。この構成では -nglが実用的な指標になります。どちらを選ぶ場合も、まずハードウェア自体の baseline を取得してください。ディスク帯域幅とメモリ帯域幅は、CPU と同じ程度にロード時間へ影響します。再現可能な VPS benchmarkには、1 時間をかける価値があります。

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

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

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

特定のビルドに固定するには、代わりに releases ページから事前ビルド済みの tarball を取得します。2026 年 8 月 2 日時点の現在のタグは 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'

または、同じタグをソースからビルドします。

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)

libssl-dev は、HTTPS 機能で文書化されている依存関係です。コンパイルには数分かかり、最小プランの容量を超える RAM が必要になる場合があります。そのため、小さいサーバーで RAM が不足する場合は、より大きなサーバーでビルドしてバイナリをコピーしてください。

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

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

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

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 より大きいファイルでも起動します。その後、カーネルがトークンごとにディスクから重みをページイン、ページアウトするため、生成速度が1トークンあたり数秒まで低下し、ディスク使用率が100パーセントに張り付きます。--no-mmap を渡すと、実際にメモリを確保するよう強制できます。これにより、性能が劣化する前にすぐ失敗します。カーネルが介入した場合は、dmesg で理由を確認できます。

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

モデルファイルをまったく読み込めない。 使用している engine より新しいモデルファミリー向けに構築された GGUF では、認識できない architecture 名を含むエラーが表示されます。

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

この場合に必要なのは別のファイルではなく、engine のアップグレードです。これはバージョンを固定して運用する場合の制約であり、build number を記録しておく理由でもあります。どのバージョンからアップグレードするのかを把握する必要があります。

API はローカルでは応答するが、アプリからは応答しない。 Ollama は 127.0.0.1:11434 に bind するため、別のホストからは connection refused になります。ポートが firewall または private network の内側にある場合に限り、OLLAMA_HOST=0.0.0.0:11434 を systemctl edit ollama で設定します。API の前段には認証がないためです。

一時停止後の最初の応答が非常に遅い。 5 minute のアイドル時間が経過して unload が発生し、モデルが再びディスクから読み込まれています。リクエストの直前に 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 に応じても増える点に注意してください。