Ollama と llama.cpp：2026年にどちらを選べばよいのか ?

#Ollamaとllama.cppの本質的な関係

llama.cpp は、Georgi Gerganov によって開発された C/C++ プロジェクトで、Python または PyTorch に依存せず、CPU および GPU で GGUF 形式の言語モデルを実行できます。ローカルエコシステムにおける推論の基盤として、LM Studio、KoboldCpp、Jan および Ollama が直接またはフォークを介してその上に構築されています。

したがって、Ollamaは厳密な意味ではllama.cppの競合ではなく、その上に機能を追加したものです。llama.cppから派生した独自のエンジンを組み込み、モデル管理機能、バックグラウンドで動作するデーモン、APIを追加しています。`ollama run qwen3`と入力すると、llama.cppに由来するコードがトークンを生成します。問うべきなのは「どちらが速いか」ではなく、「どの抽象化レベルが自分に合うか」です。量子化とハードウェアが同じなら、性能は非常に近いためです。

#Ollamaがllama.cppに実際に追加するもの

llama.cppを手動でコンパイルして実行する場合、GGUFのダウンロード、ファイルパス、長いフラグ指定のコマンドラインを自分で管理する必要があります。Ollamaは、これらをすべて引き受けます。エンジン単体に加えて、具体的に次の機能を提供します。

レジストリとpull

`ollama pull qwen3:8b` はollama.comからモデルをダウンロードし、デフォルトの量子化形式（多くの場合Q4_K_M）を選び、ブロブストアに保存します。Hugging Faceで適切なファイルを探し回る必要はありません。

常駐デーモン

サービスがバックグラウンドで動作し、http://localhost:11434 でリッスンします。モデルはリクエストと次のリクエストの間もメモリに保持され（keep-alive）、使われない状態が続くと自動的にアンロードされます。

GPUの自動オフロード

Ollamaは利用可能なVRAMを推定し、`-ngl`を調整することなく、レイヤーをGPUとCPUの間に分配します。便利ですが、時には慎重すぎる場合があります。

Modelfile

Dockerfileのような宣言的なファイルで、ベースモデル、システムプロンプト、温度、チャットテンプレートを、再利用可能な名前の下に固定します。

OpenAI 互換 API

APIのネイティブエンドポイント /api/generateに加え、/v1/chat/completionsという即時利用可能なエンドポイントも提供されています。任意のOpenAIクライアントは、ベースURLを変更するだけで接続可能です。

一方、llama.cppではあらゆる操作を自由に行えますが、すべて自分で行う必要があります。GGUFを自分で入手し、コマンドラインを書き、プロセスのライフサイクルを管理します。これが完全な制御を得るための代償であり、このllama.cppとOllamaの比較記事の続きで詳しく説明します。

#前提条件

実際に何を動かせるかを決める唯一の要因は、メモリ（RAM、または専用GPUのVRAM）です。エンジンが同じなので、次のQ4_K_Mでの目安は両方のツールに当てはまります。

3B ≈ 2 GB

ほぼどの環境にも収まり、RTX 3060 12 GBでも非常に大きなメモリの余裕があります。

7B ≈ 5 GB

8GBのVRAM（RTX 3060、4060）から快適に利用可能

14B ≈ 9 GB

RTX 3060 12GBまたは4070 12GBのVRAMに全体が収まります。

32B ≈ 19 GB

24 GBのRTX 4090が必要です。16 GBの場合は、CPUとGPUに処理を分ける部分的なオフロードが必要です。

70B ≈ 40 GB

複数のGPU、ユニファイドメモリを搭載したMac（M4 Pro 48 GB）、または大幅なオフロードが必要です。

#両方をインストールして起動する

1. 01
   Ollama のインストール

   公式スクリプトはLinux上で1つのコマンドでデーモンとCLIをインストールします。macOSとWindowsでは、ollama.comでGUIインストーラーが提供されています。セットアップが完了すると、サービスはhttp://localhost:11434でリッスンします。
2. 02
   Ollamaでモデルを起動する

   `ollama run qwen3:8b`を初めて実行すると、モデルがダウンロードされ、その後チャットセッションが開きます。ほかに設定する必要はありません。GPUへのオフロード、コンテキスト、テンプレートは自動的に管理されます。
3. 03
   llama.cpp をコンパイル

   ggml-org/llama.cppリポジトリをクローンし、CMakeでコンパイルします。GPUバックエンドのオプションはハードウェアによって異なります。NVIDIAではCUDA、MacではMetal（デフォルトで有効）、AMDではROCmまたはVulkanです。
4. 04
   llama.cppでGGUFを起動

   `llama-cli`では、読み込む.ggufファイルを明示的に指定し、GPUに配置するレイヤー数（`-ngl`）、コンテキストサイズ（`-c`）、CPUスレッド数（`-t`）など、すべての設定をコマンドラインで指定します。ユーザーに代わって設定が推測されることはありません。

# Installer (Linux) puis lancer un modèle
curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:8b

# Vérifier le daemon et lister les modèles
curl http://localhost:11434/api/tags
ollama list

# Cloner et compiler avec le backend CUDA (NVIDIA)
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

# Lancer un GGUF avec 35 couches sur le GPU et 8192 de contexte
./build/bin/llama-cli -m ./qwen3-8b-Q4_K_M.gguf -ngl 35 -c 8192 -p "Bonjour"

#同じGGUFを使った両者の簡易ベンチマーク

議論に決着をつける最良の方法は、同じファイルを使い、同じマシンで両方を測定することです。llama.cppには、生成スループット（トークン/秒）とプロンプト処理（prompt processing）を分けて測定する専用ツール`llama-bench`が用意されています。

# Débit brut du moteur sur le GGUF, tout GPU
./build/bin/llama-bench -m ./qwen3-8b-Q4_K_M.gguf -ngl 99
# Sortie : colonnes pp (prompt) et tg (génération) en tok/s

# Importer le GGUF dans Ollama sans le re-télécharger
printf 'FROM ./qwen3-8b-Q4_K_M.gguf\n' > Modelfile
ollama create qwen3-local -f Modelfile

# Chronométrer une génération (--verbose affiche les tok/s)
ollama run qwen3-local --verbose "Explique la photosynthèse en 200 mots"

2026 年の典型的な結果では、同じ GGUF を使い、すべての層を GPU に配置した場合、生成スループットは数パーセントの差を除けばほぼ同じです。同じ計算カーネルを使っているので、当然の結果です。観測される差は、ほぼ常に暗黙の設定の違いによるもので、エンジンそのものによるものではありません：

オフロードされたレイヤー

Ollamaは、VRAM容量に余裕を持たせるために、一部のレイヤーをCPU側に残すことがあります。一方、`llama-bench -ngl 99`はすべてのレイヤーをGPUに配置します。その結果、Ollamaのほうが遅く見えますが、これはレイヤーの配置方針によるものです。

コンテキストサイズ

コンテキストを大きくすると、KVキャッシュ用に確保されるVRAMが増え、モデルの重みに使える領域が減ります。コンテキストサイズをそろえて比較してください。

Flash AttentionとKVキャッシュ

有効または無効、量子化されていてもそうでなくても、これらの設定は処理速度に影響を与えます。llama.cppではこれらを明示的に設定しますが、Ollama ではバージョンや環境変数に依存します。

#llama.cppでのみ詳細設定が利用可能です。

llama.cppとOllamaの比較で、はっきりと一方に軍配が上がるのがこの点です。llama.cppはエンジンのフラグを直接利用できるため、Ollamaでは利用者から隠されている、または一部しか公開されていない調整項目にもアクセスできます。高度な用途では、これらの設定が決定的な違いを生みます：

細かく調整できるオフロード（-ngl）

各レイヤーごとに、GPUに配置される層の数を自分で決定できます。VRAMがちょうど十分な場合、Ollama に対して2〜3層を増やすことで、モデルの「遅い」状態から「スムーズ」な状態に変えることができます。

量子化された KV キャッシュ（-ctk/-ctv）

KVキャッシュをq8_0で量子化すると、コンテキストに必要なメモリがほぼ半分になり、同じVRAM容量ではるかに長いコンテキストウィンドウを使えます。Ollamaでは利用しにくい調整方法です。

Flash attention (--flash-attn)

最適化された注意機構の明示的な有効化で、長文コンテキストの速度とメモリ使用量に直接影響を与えます。

投機的デコード（--model-draft）

小さな「ドラフト」モデルを接続して、大きなモデルを高速化する。コード生成では大幅な高速化が得られる可能性があり、llama.cppにはこの機能が標準で備わっています。

GBNF文法（--grammar）

出力を形式文法に従うように制約する（厳密なJSON、列挙、独自形式）。信頼できる構造化出力には不可欠で、OllamaのJSONモードよりもはるかに細かく制御できます。

RoPEとコンテキストのスケーリング

`--rope-freq-base`と`--rope-freq-scale`を調整して、品質の低下を抑えながら、元の学習時のコンテキスト長を超えて拡張する。

Ollamaでは、Modelfileのパラメータや環境変数を通じて、これらの設定の一部を調整できます。ただし、同じ細かさで調整できることはまれで、llama.cppの新機能への対応も遅れることがよくあります。「自分のVRAM容量で可能な限り長いコンテキストを使いたい」あるいは「有効なJSONを確実に得たい」という場合、エンジンを直接使えば、ラッパー側で固定されている部分まで調整できます。

#APIサーバー：Ollama と llama-server

どちらもHTTP経由でモデルを提供できます。Ollamaはhttp://localhost:11434でデーモンを公開し、独自のAPI（/api/generate、/api/chat）とOpenAI互換のエンドポイント（/v1/chat/completions）を提供します。一方、llama.cppは`llama-server`というバイナリを提供しており、これを実行するとOpenAI互換のAPIと付属の小さなウェブインターフェースが起動します。

# API OpenAI-compatible sur le port 8080, tout GPU
./build/bin/llama-server -m ./qwen3-8b-Q4_K_M.gguf -ngl 99 -c 8192 --port 8080
# Interface web : http://localhost:8080  ·  API : /v1/chat/completions

オンデマンドのマルチモデル

Ollamaはリクエストに応じて複数のモデルを自動的にロード／アンロードします。`llama-server`はプロセスごとに1つのモデルを提供するため、動作を把握しやすく、裏で自動的に行われる処理も少なくなります。

フラグの制御

llama-serverでは、推論エンジンの各設定（コンテキスト、KVキャッシュ、Flash Attention）を明示的な起動フラグで指定します。再現可能な本番環境の設定を固定するのに最適です。

エコシステム

ポート11434で提供されるOllamaのAPIは、事実上の標準となっています。Open WebUI、コードエディター、各種連携機能がこのAPIを直接利用します。これは使いやすさの面で大きな利点です。

#利用者タイプ別の結論：初心者、開発者、ホームラボ

共通のエンジンを使っているため、どちらを選ぶかは性能ではなく、利用者のタイプやコマンドライン操作への抵抗感によって決まります。

初心者 → Ollama

コマンド1つでインストールでき、別のコマンド1つで起動でき、何も設定せずにモデルが「動く」。LLM と会話するために C++ をコンパイルする必要はありません。Ollama を使い続け、必要に応じて Open WebUI を組み合わせてください。

開発者 → 両方

素早くプロトタイプを作り、すぐに使えるOpenAI互換APIを利用したいならOllama、GBNF文法、投機的デコーディング、KVキャッシュの厳密な制御が必要ならllama.cppが適しています。GGUFを共通で使えるため、一方から他方への移行も容易です。

ホームラボ／セルフホスト → llama.cpp（llama-server）

限られたVRAMを最大限に活用し、再現可能な設定を固定し、コンテキストを広げたいなら、エンジンを直接使うほうが有利です。その代わりに必要になるコンパイル、フラグの記述、プロセス管理こそ、まさに自分で扱えるようになりたい部分でしょう。

一言で言えば、Ollamaは最適な出発点であり、大多数の用途には十分です。コンテキスト、KVキャッシュ、文法、層単位のオフロードといった細かな設定が制約になったときに、llama.cppを直接使う形に移行します。これは置き換えではなく、制御できる範囲を広げることです。

#さらに詳しく

以下のガイドでは、この比較をさらに掘り下げ、インストールから細かな調整までを扱います。

Ollamaを使い始める

「Windows、macOS、LinuxでOllamaを5分でインストール」では、手軽に始めるための方法として、デーモンのインストールと最初のモデルのセットアップを解説しています。

Ollama を使わずにモデルをサーバーとして提供する

「llama-server：llama.cppによるローカルOpenAI API」では、制御面について、レイヤーのオフロードの細かな調整と、付属のWebインターフェースを詳しく説明しています。

量子化の選択

「2026年のGGUF量子化：Q4_K_M と Q5_K_M と Q6_K」は、両ツールで共通に使用できる適切な.ggufファイルを選択するのに役立ちます。