著者 Ollamaとllama.cppの違いは？VPSでの最適な選択を解説
VPSでLLMを動かす際、Ollamaとllama.cppのどちらを選ぶべきか解説します。llama.cppは推論エンジン、Ollamaはその管理層です。メモリ消費を抑えるための量子化の選び方や、CPUのみの環境でリソース不足に陥らないための設定のコツを詳しく紹介します。
Ollama と llama.cpp：どのレイヤーで実行すべきか
Ollama と llama.cpp は、この質問が示唆するような競合関係にはありません。llama.cpp は推論エンジンであり、モデルファイルを読み込んでプロンプトをトークンに変換します。Ollama はモデルマネージャーであり、そのエンジンの上で動作するバックグラウンドデーモンおよび HTTP API です。Ollama の README には、現在も推論バックエンドとして llama.cpp が記載されています（2026年10月27日確認）。したがって、真の問いは「どちらが高速か」ではなく、「VPS 上でどのレイヤーを操作したいか」です。
モデル名で取得し、放置していても動作し続けるサービスが必要な場合は Ollama を実行してください。VPS のリソースが小さく、正確なモデルファイル、コンテキストサイズ、スレッド数を指定する必要がある場合は、llama.cpp を直接実行してください。小規模な VPS では、それらの設定一つひとつがメモリ消費に直結するためです。
各プロジェクトの概要
llama.cpp は、ggml ライブラリを基盤として構築された、Transformer 推論の C および C++ 実装です。このプロジェクトは GGUF ファイルを読み込みます。GGUF (GGML universal file format) は、モデルの実行に必要な重み、トークナイザー、メタデータを保持する単一ファイルのコンテナ形式です。このプロジェクトでは、用途ごとに個別のバイナリが提供されます。llama-server は HTTP サーバー、llama-cli は対話型プロンプト、llama-bench はスループットの計測用です。現在、プロジェクトはセマンティックバージョニング（MAJOR.MINOR.PATCH）を採用しており、2026年10月15日に公開された v0.7.0 が、2026年10月27日時点での最新版です。ビルド番号付きの nightly タグも並行して毎日複数リリースされており、2026年10月27日時点の最新は b11913 です。
Ollama は Go 言語で書かれたプログラムです。ollama serve で起動するバックグラウンドデーモンがモデルを読み込んで HTTP リクエストに応答し、コマンドラインクライアントがそのデーモンと通信します。両者の背後には、事前パッケージ化されたモデルを保持する ollama.com のレジストリが存在します。Ollama はセマンティックバージョンを使用しています。v0.32.5 は 2026年7月27日にリリースされ、v0.40.12 は 2026年10月27日 00:07 UTC にリリースされました。ollama pull は、GGUF ファイルをプロンプトテンプレートやデフォルトパラメータのセットとともに取得し、Linux 上では /usr/share/ollama/.ollama/models 配下に保存します。これらのファイルはルートディスクに配置され、それぞれ数ギガバイトに達します。そのため、25 GB のルートボリュームを持つ VPS を利用する場合、3回目のダウンロードでディスクが一杯になる前に pull が何を残し、モデルディレクトリを別の場所に移動する方法 を把握しておくことが重要です。
パッケージングの方法が両者の主な違いです。Ollama は量子化、テンプレート、コンテキスト長を自動的に決定し、ユーザーは名前を覚えるだけで済みます。一方、llama.cpp はこれらの選択肢をフラグとして公開しており、指定しなかった設定については自動的にデフォルト値が適用されます。
軸 1: モデルと量子化の制御
量子化とは、元のモデルの 16 ビットや 32 ビットよりも少ないビット数で重みを保持する手法です。一般的な GGUF ビルドでは、重みあたり平均 4、5、または 8 ビット程度になります。精度はファイル全体で均一ではありません。llama.cpp の量子化ソース（2026 年 10 月 27 日閲覧）によると、Q4_K_M ビルドではほとんどのテンソルを 4 ビットに保ちつつ、出力層や、層の約半分に含まれる attention value および feed-forward down テンソルには 6 ビットの Q6_K を割り当て、norm のような小さなテンソルは量子化しません。これこそが、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 単位に変換したものです。あるモデルのビルド数は 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）です。設定が未指定の場合はデフォルト値が適用され、--fit はデフォルトで有効となっており、デバイスメモリに合わせて未指定の引数を調整します。
Ollama の場合、量子化はプルするタグに付随しており、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 を指定します。特定のジョブだけ大きなウィンドウが必要な場合は、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 人で停止する理由でもあります。
軸 2: 運用すべきデーモン
Ollama のインストールスクリプトは systemd ユニットを作成し、ollama システムユーザーを作成してサービスを有効化します。これにより、自身で記述することなくライフサイクル管理が可能になります。設定は 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 ollamaOLLAMA_KEEP_ALIVE は、CPU VPS において他よりも重要です。モデルはデフォルトで 5 分間メモリに保持され、その後アンロードされます。次のリクエストでは、回答する前にファイル全体を再読み込みする必要があります。カーネルがページキャッシュにファイルを保持していれば高速ですが、空き RAM に依存するため、他の処理で押し出されるとディスクから読み直すことになります。その結果、4.58 GiB のリロードは、低速なストレージでは 2 秒の応答を 30 秒に遅延させます。keep-alive を長く設定すればレイテンシは解消されますが、RAM を恒久的に消費します。どちらも実質的なコストです。影響の少ない方を選択してください。モデルを常駐させる場合は、アイドル期間や再起動後も維持されるよう keep_alive を設定することで、数行の設定で済み、サーバー再起動のたびに手動でモデルをウォームアップする手間を省けます。
llama.cpp にはデーモンやサービスユーザーは付属していないため、自身で設定する必要があります。ビルドを行った llama.cpp ディレクトリから、バイナリとそのライブラリを /usr/local にインストールし、llama ユーザーを作成してモデルのコピーを配置します。
sudo cmake --install build
sudo ldconfig
sudo useradd --system --no-create-home --shell /usr/sbin/nologin llama
sudo install -d -o llama -g llama /srv/models
sudo install -o llama -g llama -m 644 ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf /srv/models/model-Q4_K_M.ggufビルドではなくリリースアーカイブを使用した場合は、ExecStart がアーカイブ内の llama-server を指すように設定してください。アーカイブではライブラリがバイナリと同じ場所に配置されているためです。次に、ユニットを /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.targetsudo systemctl enable --now llama-server で有効化します。このプロセスは起動中ずっとモデルを保持します。デフォルトではアイドル時にアンロードされることはありませんが、--sleep-idle-seconds を追加すると、サービスを停止することなく自動的なアンロードとリロードが可能になります。ユニットの作成が初めてであれば、VPS 上で独自のサービスを systemd で実行する際と同じパターンです。
軸 3: アプリケーションが通信する API
この軸の差異は大幅に縮小しました。両プロジェクトとも OpenAI チャット形式に対応したため、ほとんどのクライアントライブラリはベース URL を変更するだけでどちらに対しても動作します。
Ollama は 127.0.0.1:11434 で待ち受けます。OpenAI 互換のエンドポイントは http://localhost:11434/v1/chat/completions で、これとは別にネイティブ API を /api/chat で提供します。Anthropic 互換のエンドポイントもドキュメントに記載されています。これらのエンドポイントからモデルが自律的に情報を検索することはできません。そのため、アプリケーションでモデルの学習データより新しい情報が必要な場合は、Ollama の API、Open WebUI、または短いツールループを通じて Web 検索を組み込む構成を計画してください。
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 で待ち受けます。デフォルトでは 9931 番ポートを使用する仕様（2026 年 10 月 27 日確認）に変更されたため、アプリケーションが 8080 番ポートを想定している場合は、コマンドラインで --port を指定し続けてください。このサービスは /v1/chat/completions、/v1/completions、/v1/embeddings に加え、独自の /completion エンドポイントと組み込みの Web UI を提供します。また、Ollama にはない運用用のルートも公開しています。具体的には、準備状況を確認する /health、読み込まれたモデルの設定を確認する /props、各リクエストスロットの動作状況を確認する /slots、そして --metrics を追加することで利用可能になる Prometheus 形式の /metrics です（このエンドポイントはデフォルトで無効です）。このサービスを監視する計画がある場合、この違いが選定の決め手となるでしょう。
どちらのサーバーも、デフォルトで認証が有効になることはありません。両者とも、セキュリティ上の理由からデフォルトでループバックアドレスにバインドされます。SSH トンネル経由、またはリバースプロキシの背後からアクセスするようにし、11434 番や 8080 番ポートをインターネットに対して決して開放しないでください。
CPU 専用 VPS で現実的にできること
CPU 専用 VPS では、小型モデルを低速で実行できます。これが率直な要約です。重要なのは、どこまでなら実用になるかを把握することです。構成を決める前に測定してください。
llama-bench -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -p 512 -n 128pp 列はプロンプト処理速度、tg 列はトークン生成速度です。どちらも 1 秒あたりのトークン数で表します。共有 vCPU プランでは、8B モデルを Q4_K_M で実行すると、tg は通常、1 桁台前半になります。特に負荷が大きいのはプロンプト処理です。最初の出力トークンが表示される前にプロンプト全体を処理するため、長いシステムプロンプトはすべてのリクエストで待ち時間を増やします。返信の長さは、実際に制御できる処理量です。1 秒あたり 3 トークンの場合、600 トークンを生成するモデルは 200 秒、つまり生成だけで 3 分以上 VPS を占有します。そのため、num_predict で出力を制限することが、冗長な回答 1 件でタイムアウトになるのを防ぐ最も低コストな方法です。
CPU で実用になるのは、分類、抽出、短い要約、ルーティングを行う 1B から 4B のモデルです。返信は数秒で返り、通常のプランに収まるメモリ量で動作します。このサイズを範囲ではなく具体例で確認するなら、VPS に Nemotron 3.5 Lightning を取得して測定する記事で、正確なタグ、実際に必要な RAM、GPU なしで維持できる速度を確認できます。CPU では、読める速度での対話型チャット、コーディングアシスタント、長文書の処理、またはエージェントループが多数の呼び出しを順番に行う処理は実用的ではありません。4 秒かかる呼び出しを 12 回行うループでは、何かを生成するまでに 1 分かかります。コーディングアシスタントを想定している場合は、自分でホストするモデルにエージェントを接続する記事で、小型のローカルモデルが実際に適する処理と、ホスト型 API に任せるべき処理を説明しています。
数値が要件を満たさない場合の選択肢は 2 つあります。問題が同時実行数、つまり複数のユーザーが 1 つのモデルへ同時にアクセスすることなら、エンジンの選択が変わります。同時サービングにおける Ollama と vLLM の比較で詳しく説明しています。問題が単純な速度なら、答えはGPU を接続した VPSです。この場合、-ngl が実用的な指標になります。どちらを選ぶ場合も、まずハードウェア自体の基準値を取得してください。ディスク帯域幅とメモリ帯域幅も CPU と同様にロード時間へ影響するためです。再現可能な VPS ベンチマークには、1 時間をかける価値があります。
llama.cpp のインストールとビルドの固定
両プロジェクトは毎週更新されるため、デプロイしたバージョンを記録してください。アップストリームのワンライナーを実行すると、現在のビルドがインストールされます。
curl -LsSf https://llama.app/install.sh | sh
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF特定のビルドに固定するには、releases ページからプリビルド済みの tarball を取得してください。現在、プロジェクトはセマンティックバージョニングによるリリースも行っています。2026年10月27日時点の最新は v0.7.0 で、そのリリースページはバイナリとして nightly b11669 を指定しています。2026年10月28日には v0.8.0 がリリースされ、リリースページはバイナリとして nightly b11960 を指定しています。以下のコマンドでは、2026年8月2日時点のタグである 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 機能のドキュメント化された依存関係です。コンパイルには数分かかり、最小プランのメモリ容量では不足することがあります。その場合は、より大きなマシンでビルドしてからバイナリをコピーしてください。
バージョンを固定して 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 のリリースでは読み込み前にサイズをチェックしており、ollama run は以下のような行を返していました。
Error: model requires more system memory (5.6 GiB) than is available (3.2 GiB)現在の Ollama のソースコードにはこのメッセージは含まれていません（2026年10月27日確認）。現在は読み込み処理を llama-server に委譲しているため、モデルが収まらない場合はランナーの失敗として扱われ、以下のようなエラーが表示されます。
llama-server reported out-of-memory during startup
llama-server process has terminatedいずれの場合も修正方法は同じです。量子化レベルを一段下げるか、コンテキスト長を短くするか、より小さなモデルを選択してください。
llama.cpp が失敗せず、極端に低速になる。 llama.cpp はデフォルトで GGUF をメモリマップするため、RAM より大きなファイルでも起動はします。その場合、カーネルがトークンごとにディスクとの間でウェイトのページイン・アウトを繰り返すため、生成速度はトークンあたり数秒まで低下し、ディスク使用率が 100 パーセントに張り付きます。メモリマップを無効にするには --load-mode none を渡してください。このオプションは --no-mmap に代わるものです。--no-mmap は固定された b10224 ビルドで非推奨とされ、現在のビルドには存在しません（2026年10月29日確認）。カーネルが介入している場合、dmesg にその理由が表示されます。
Out of memory: Killed process 1234 (llama-server)モデルファイルが全く読み込まれない。 使用しているエンジンよりも新しいモデルファミリー向けにビルドされた GGUF を使用すると、未知のアーキテクチャを示すエラーが発生します。ここで <arch> はファイル内のメタデータに格納されている名称です。
llama_model_load: error loading model: unknown model architecture: '<arch>'修正には別のファイルではなく、エンジンのアップグレードが必要です。これはバージョンを固定する代償であり、ビルド番号を記録しておくべき理由でもあります。どのバージョンからアップグレードするのかを把握しておく必要があります。
API がローカルでは応答するが、アプリからは接続できない。 Ollama は 127.0.0.1:11434 にバインドするため、他のホストからは接続拒否されます。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年10月27日確認）。Ollama はその上に、モデルレジストリ、チャットメッセージをプロンプトに変換するテンプレート、デフォルトのサンプリングパラメータ、アイドル時のアンロード機能を持つデーモン、そして HTTP API を追加しています。同一設定で 1 秒あたりのトークン数を比較する場合、比較対象は同じエンジンです。実際に選択すべきは、管理レイヤーの利便性です。
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 のキャッシュが追加されます。そのため、8 GiB の RAM があれば余裕があり、4 GiB では不足します。キャッシュはコンテキストに応じて増加します。同じモデルでも 32,768 トークンのコンテキストでは、キャッシュだけで約 4 GiB を必要とします。Ollama を使用する場合、要件は OLLAMA_NUM_PARALLEL に応じても増加することに注意してください。