Ollama と llama.cpp の速度を同じ設定で比べた — 「Ollama は遅い」は本当か（RTX 5060 Ti 16GB・Windows で実測）

CONTENTS目次（8）

1. 差が出にくい理由: 今の Ollama の中身は llama.cpp
2. 測った環境
3. 実測 1: 全部 GPU に載る密なモデル
4. 実測 2: VRAM に入りきらない MoE
5. 差が出るのは設定の値: num_batch
6. 測っていないこと
7. まとめ
8. 出典

「Ollama は遅いので、llama.cpp を直接使ったほうが速い」「Linux と llama.cpp にすると数十% 速くなる」という話をよく見かけます。Windows の RTX 5060 Ti 16GB で、Ollama と llama.cpp を同じモデルのファイル・同じ設定で並べて測りました。数字は 2026年9月29日時点のものです。

差が出にくい理由: 今の Ollama の中身は llama.cpp

Ollama 0.34 系は、GGUF（llama.cpp 系で使うモデルのファイル形式）のモデルを動かすときに llama.cpp の推論サーバー（llama-server）を起動しています。Windows でも同じで、実行中のコマンドラインを見ると、Ollama が llama-server.exe に引数を渡して起動していました（Qwen3.8・Qwen3.6・Gemma 4 で確認）。

llama-server.exe --model （モデルのファイル） -c 8192 -np 1 ... \
  --cache-type-k q8_0 --cache-type-v q8_0 --flash-attn on -b 512 -ub 512

Ollama 0.34.3 が起動した llama-server の引数（一部を省略）。

このとき Ollama は、GPU に載せる層の数（-ngl）を渡していません。置き場所は llama.cpp の自動の仕組み（--fit）に任せています。llama.cpp の側も、今は -ngl の既定が auto、--fit の既定が on です。既定どうしで比べると、同じエンジンが同じやり方で置き場所を決めることになります。違いが出るのは、Ollama が付ける既定値（num_batch の 512 など）のほうです。

測った環境

実測 1: 全部 GPU に載る密なモデル

Qwen3.8-27B（unsloth の UD-Q3_K_XL・13.15GB）と Gemma 4 31B（unsloth の UD-IQ3_XXS・11.84GB）で、日本語の文章の続きとコードを 512 トークンずつ書かせました。置き場所はどちらも自動で、2 つとも全部が GPU に載っています。速さは 1 秒あたりに生成したトークンの数（tok/s）で、各 2 回の中央値です。

差は llama.cpp ÷ Ollama - 1。2026年9月29日 6:17〜7:19 に、Ollama → llama.cpp の順に続けて測定。

読み込みの速さ（入力を処理する tok/s）の差も、同じ 10 組で -2.0〜+3.0% でした。

Qwen3.8 では llama.cpp が 1.5〜1.7% 速く出ていますが、この程度の差は測る時間帯でも動きます。同じ llama.cpp・同じ置き場所（VRAM は 12,952MiB と 12,955MiB）で、約 4 時間半後に測り直すと、28.0 → 27.3 tok/s と 2.5% 違いました。全部 GPU に載る密なモデルでは、Ollama と llama.cpp の差は、測り直しのぶれと見分けが付きません。

実測 2: VRAM に入りきらない MoE

「MoE は llama.cpp で専門家（expert）の重みを CPU に置くと速い」という話もあります。VRAM に入りきらない Qwen3.6-35B-A3B（の派生モデル・Q4_K_M・21.2GB）で確かめました。約 2.9 万〜3 万トークンの日本語の文章を読ませて、続きを 1,024 トークン書かせています。文脈は 49,152、-b と -ub は両方とも 4096 です。

各 2 回。llama.cpp の自動と 28 層の 1 回目は、モデルが 57 トークンで書き終えたので外した。1 回の時間は読み込みと生成の合計（モデルの読み込みは含まない）。手で置いた 3 つは -ngl 99 --fit off を付けた。2026年9月29日の 11 時台に測定。

• Ollama と llama.cpp の自動は、1 回の時間が 37.0〜37.2 秒で同じでした。llama.cpp は生成が 4% ほど速く、Ollama は読み込みが 3〜6% 速い、という差の出方です。この Ollama のモデルは画像入力用の部品も一緒に読み込む設定で、そのぶん GPU に置ける量がわずかに少ない、という違いもあります
• 専門家を手で CPU に置いた 3 つは、どれも自動より遅くなりました。CPU に置く層を増やすほど、VRAM が空くだけで、読み込みも生成も落ちています

理由は、llama.cpp の自動の置き場所決めの中身にあります。llama.cpp の説明によると、--fit は VRAM に入りきらないとき、密な部分の重みを GPU に残したまま、専門家の重みを層ごとに CPU へ回し、1GiB の余白を残して GPU を埋めます（説明の例では、48 層のうち 34 層の専門家を CPU に回している。文脈の長さを指定していなければ、先に文脈を縮める）。「専門家を CPU に置く」調整は、今は自動でされています。手で決めた層の数が自動より多いと、そのぶん GPU が空いたまま遅くなります。今の版では、まず自動に任せて測り、手の指定はそれより速いときだけ使えば足ります。

差が出るのは設定の値: num_batch

Ollama で大きく速さが変わったのは、num_batch（入力を何トークンずつまとめて処理するか）でした。Ollama の既定は 512 で、これが llama-server の -b と -ub の両方に渡ります。同じ MoE で、約 4 万トークン（40,452 トークン）の入力を読ませて比べました（2026年9月23日に測定）。

2026年9月23日に測定。文脈 49,152・生成 256 トークン・思考なし。各回の値。

読み込みは 2.5 倍になり、4 万トークンを読むのに 55 秒かかっていたのが 22 秒になりました。代わりに作業領域が増えて GPU に載る割合が下がり、生成は約 4.5% 遅くなります。長い資料や原稿を読ませる使い方なら、差し引きで大きく得をします。読み込みの間、GPU の使用率は 98% なのに消費電力は 74W で、CPU の使用もほとんど増えませんでした。CPU に置いた専門家の重みを、まとめた単位ごとに GPU へ送って計算しているとみられ、まとめる単位が大きいほど送る回数が減ります。

設定の仕方は、API で呼ぶたびに options で num_batch を渡すか、/api/create の parameters に入れてモデルの既定値にするかです。値を変えるとモデルの読み直し（約 25 秒）が起きるので、同じモデルには毎回同じ値を渡します。

測っていないこと

• Linux・Mac・WSL・Docker での速さ。「Linux にすると速い」は、この記事では確かめていません
• Vulkan や ROCm など、CUDA 以外の版
• 同時に複数の要求を処理する使い方（同時処理 2 以上）や、画像を入力する使い方
• 先読みの一種（DFlash）を MoE に足す使い方。下書きの作業領域（3,912MiB）が確保できず、自動の置き場所では起動しませんでした

まとめ

• 今の Ollama は、中で llama.cpp の llama-server を動かしている。置き場所も llama.cpp の自動の仕組みに任せている
• 同じファイル・同じ設定なら、生成の差は 0〜1.7%で、測り直しのぶれ（2.5%）より小さい（2026年9月29日時点・RTX 5060 Ti 16GB・Windows）
• VRAM に入りきらない MoE も、自動の置き場所決めが最も速かった。専門家を手で CPU に置くと 1.05〜1.6 倍の時間がかかった
• 速さを変えたのは設定の値。num_batch を 512 → 4096 にすると、長い入力の読み込みが 2.5 倍になった

出典

• llama.cpp の fit-params の説明（--fit が専門家の重みを層ごとに CPU へ回す例）: https://github.com/ggml-org/llama.cpp/blob/master/tools/fit-params/README.md
• llama.cpp の llama-server の説明: https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md
• Ollama の Modelfile（パラメーターの一覧）: https://github.com/ollama/ollama/blob/main/docs/modelfile.mdx
• Ollama の API（options・/api/create）: https://github.com/ollama/ollama/blob/main/docs/api.md
• unsloth/Qwen3.8-27B-GGUF（Hugging Face）: https://huggingface.co/unsloth/Qwen3.8-27B-GGUF
• unsloth/gemma-4-31B-it-GGUF（Hugging Face）: https://huggingface.co/unsloth/gemma-4-31B-it-GGUF

← 検証ノートの一覧へ

この記事は、手元の機材で行った測定をもとにした一般的な技術情報の提供を目的としており、特定の製品・ソフトウェアの購入や利用を推奨・勧誘するものではありません。数値は 2026年9月29日時点の測定（num_batch の表は 9月23日）で、モデル・ソフトの版・機材・OS によって変わることがあります。