llama.cpp vs Ollama：2026年、どちらを動かすべきか？

最大のtokens/秒と完全な制御が欲しければ素のllama.cpp、ワンコマンドのインストールと最初から動くAPIサーバーが欲しければOllama。 Ollamaは競合エンジンではありません——llama.cppを推論バックエンドとして同梱するGoのサービスで、モデル管理（ollama pull llama3.1）を足し、ポート11434でREST APIを出します。だから本当の問いは「どちらのエンジンが速いか」ではなく「そのエンジンのノブをどれだけ自分で回したいか」です。Ollamaは控えめなデフォルト（Q4_K_M量子化、控えめなコンテキスト、つい最近までflash attention無効）を出荷するため、同一ハードウェアでも数字が目に見えて変わります。以下、実際の違い、速度差の出所、同じモデルを両方で動かす方法、そして決定表です。

llama.cppとOllamaの違いは何？

llama.cpp は推論エンジンです。GGUFの生みの親Georgi Gerganovによる単一のC/C++プロジェクトで、量子化モデルをCPU、GPU、あるいはその混合で動かします。1発プロンプト用の llama-cli とOpenAI互換HTTPサーバーの llama-server に加え、エンジンが対応する全チューニングフラグ——GPUレイヤーオフロード、KVキャッシュ量子化、speculative decoding、カスタムサンプラー——が揃っています。

Ollama はそのエンジンの上に重ねられたプロダクトです。llama.cppをフォークして取り込み、次のものを包みます:

• モデルレジストリ（ollama pull、ollama list）、GGUF重みの自動分割付き
• Modelfileシステム（プロンプトテンプレートとパラメータを記述するDockerfile風のスペック）
• モデルをVRAMに温存し独自REST APIを公開するバックグラウンドデーモン
• 安全なデフォルト付きの自動ハードウェア検出

実用上の帰結はこうです: Ollamaではモデルを管理し、llama.cppでは推論を管理する。量子化フォーマットを変えたい、KVキャッシュを量子化したい、コンテキストをデフォルト以上に引き上げたい、特定レイヤーをGPUに固定したい——そう思った瞬間からllama.cppの領土です。Ollamaはこれらのダイヤルの大半を、意図的に隠しています。

	llama.cpp	Ollama
何であるか	推論エンジン（C/C++）	llama.cppを包むサービス
インストール	ソースビルドかパッケージ	ワンラインインストーラ、単一バイナリ
モデルを実行	llama-cli -m model.gguf + フラグ	ollama run llama3.1
API	OpenAI互換（llama-server）	独自REST + OpenAI互換エンドポイント
モデル管理	GGUFファイルは自分で取得	レジストリ: pull/list/rm
デフォルト	すべて自分で選ぶ	安全: Q4_K_M、控えめなコンテキスト
エンジン更新	即日（upstream）	upstreamリリースに遅れる
チューニング深度	フル（KV量子化、spec decode、サンプラー）	限定的なパススルー
向いている用途	性能チューニング、サーバー、エッジ	とりあえず動かす、開発ノートPC

llama.cppはOllamaより速い？

同じGGUF、同じ量子化、同じコンテキスト、同じllama.cppバージョンなら——いいえ、誤差の範囲内です。計算しているのはOllama自身、つまりllama.cppだからです。「Ollamaは30%遅い」というベンチマークは、実のところすべてデフォルト設定の比較です。差は3つの場所から来ます:

1. 量子化の選択。 OllamaのレジストリはQ4_K_Mがデフォルト。同じモデルをllama.cppでQ5_K_MやQ6_Kで動かせば、同程度の速度でより良い品質が得られます——あるいは速度第一ならQ4_0/IQ4を選ぶ。
2. flash attentionとKVキャッシュ量子化。 --flash-attn と -ctk q8_0 -ctv q8_0 の組み合わせはKVキャッシュを大幅に縮め、長いコンテキストでtokens/秒を上げ、同じVRAMにより大きなコンテキストを収めさせます。Ollamaはこの一部しか露出していません。
3. バージョンラグ。 llama.cppには週次でカーネル最適化が入ります。Ollamaは独自のペースでupstreamをマージします。Ollamaが追いつくまでの間、新しいllama.cppビルドは同じマシンの数か月前のOllamaバイナリより測定可能な速さで勝ります。

エンジン非依存の簡易ベンチマークコマンド——プロンプト評価と生成の速度を報告します:

./build/bin/llama-bench -m Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99 -fa 1

Ollama自身のモデルファイル（~/.ollama/models/blobs/...、.gguf にリネーム）で実行すれば、通常はOllamaの数字にぴったり一致します——その後、16kコンテキストで -ctk q8_0 を足せば追い越せます。

同じモデルを両方で動かすには？

両方ともGGUFを消費します。それぞれの最小構成はこうです:

# --- Ollamaルート: インストール、pull、serve ---
curl -fsSL https://ollama.com/install.sh | sh
ollama run llama3.1:8b        # Q4_K_Mをダウンロードし、VRAMへロード、チャット開始

# そのAPI、OpenAI互換形式:
curl -s http://localhost:11434/v1/chat/completions -d '{
  "model": "llama3.1:8b",
  "messages": [{"role": "user", "content": "Say hi in 5 words"}]
}'

# --- llama.cppルート: ビルド、GGUFダウンロード、serve ---
git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build -DGGML_CUDA=ON    # または -DGGML_VULKAN=ON / -DGGML_HIP=ON
cmake --build build --config Release -j

huggingface-cli download bartowski/Meta-Llama-3.1-8B-Instruct-GGUF 
  Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf --local-dir models

./build/bin/llama-server -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf 
  -ngl 99 --ctx-size 16384 --flash-attn -ctk q8_0 -ctv q8_0 --port 8080

llama-server はOpenAI Chat Completionsスキーマを公開するので、http://localhost:8080/v1/chat/completions への同じ curl が無変更で通ります。OpenAI API向けに作られたツール——スクリプト、エディタ、RAGパイプライン——はどちらにも向けられます。実際の仕事をするのはフラグです: -ngl 99 が全レイヤーをGPUへオフロードし、--flash-attn と -ctk/-ctv のペアが、Ollamaのデフォルトでは拒まれる8 GBカードに16kコンテキストを収めます。

GGUFファイル自体の選び方と量子ラベルの意味は how to run GGUF models locally をどうぞ。

Ollamaの方が理にかなうのはいつ？

ほとんどの人はOllamaから始めるべきです。それは慰めの賞ではありません:

• 今夜動かしたい。 コマンド1発、モデル取得、API起動。llama.cppはバックエンド選択（CUDA/Vulkan/HIP/Metal）、ビルド、重みの手動取得を意味します。
• 多数のモデルを掛け持ちする。 レジストリ、自動アンロード、ModelfileはGGUFディレクトリの手動管理に勝ります。
• マシンが控えめ。 Ollamaのデフォルトが控えめなのには理由があります——ほぼ確実に収まり、動きます。
• 安定したAPIサーフェスが欲しい。 Ollamaのデーモンがモデルのライフサイクルを管理するので、常設サービスが面倒を見る必要がありません。

素のllama.cppを選ぶのは、ベンチマークを取るとき、どんな規模でもサーブするとき、スマホやRaspberry Piで動かすとき、小さいVRAMで長いコンテキストが必要なとき、upstreamにマージされたその日に機能が欲しいときです。パワーユーザーはしばしば両方を動かします: 日々の相棒はOllama、最後の20%が必要な唯一のワークロードにはピン留めしたllama.cpp。

比較がデスクトップGUIアプリの間であるなら、それは別の軸です——Ollama vs LM Studio をどうぞ。タスク別のエンジン選択なら the best local LLMs for coding がモデル側を扱っています。

どちらを使うべき？

決める基準は速度ではなく制御量です。 エンジンは同じ、デフォルトが違う。「動いてAPIを出せばいい」が目標ならOllamaをインストール——どうせ回さなかったノブをいくつか失うだけです。tokens/秒、コンテキスト長、量子化の制御が目標ならllama.cppをビルド——全ノブが手に入り、代償はモデルを自分で管理すること。どちらにせよ動かしているのは同じGGUFファイルで、後からの乗り換えは書き直しではなく、午後1つで済みます。