Ollama 0.34が遅いのにollama psは100% GPU。RunPodやDockerで2〜3倍遅くなる原因と、3つの直し方

秋葉原IT戦略研究所

2026年9月29日 18:46

RunPodやDockerでOllamaを動かしていて、「最近なんだか遅い」と感じていませんか。

「ollama ps」を見ると「100% GPU」。VRAMにもちゃんと載っている。なのにGPUの使用率が半分も出ない。そういう状態なら、原因はGPUでもモデルでもなく、Ollamaの版数かもしれません。

私のところでは、RunPodで借りたGPUの上で、いつもの31bが1秒に72トークンから20トークンまで落ちました。同じpodで版数だけ戻すと、速度も戻ります。手元のWindowsでは起きません。

この記事では、何が起きているのか、自分の環境が当たっているかの見分け方、直し方を、実測の数字と一緒に書きます。

※runpodとはGPUを時間単位で100円以下でサクっとかりれるサービスです

詳しくはこちらで解説

結論を先に

Ollama 0.32.14以降(いまの最新0.34.4まで)は、CPUの割り当てが少ないコンテナの中だと生成が2〜3倍遅くなります
原因はCPUの「空回り」です。GPUで計算しているあいだ、CPUのスレッドが仕事待ちで回り続け、コンテナに許されたCPUを使い切って、OSに止められます
普通のPCでは起きません。手元のWindowsでは、Gemma 4の3つのモデルとも新旧の差が1%以内でした
直し方は3つ。0.32.13に戻す / 「num_thread」を割り当て以下にする / llama-serverに「--poll 0」を渡す。どれでも元の速さに戻りました
2026年9月29日の時点で、Ollama本体では直っていません

自分の環境が当たっているか

当たりやすいのは、次のような環境です。

RunPodのような、GPUを時間で借りるサービスのpod
Dockerで「--cpus」や「cpuset」を指定してOllamaを動かしている
KubernetesでCPUの上限(limits)を付けている(私は試していませんが、仕組みは同じはずです)

逆に、普通のWindowsやMac、CPUの上限を付けていないDockerなら、たぶん大丈夫です。CPUの使用率が少し上がるだけで、速さは変わりません。

見分けるには、コンテナの中で次を打ちます。

ollama -v
nproc
cat /sys/fs/cgroup/cpu.max 2>/dev/null || cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us

1行目が0.32.14以上
3行目で数字が出て(「max」や「-1」なら上限なし)、それを100000で割った数が、2行目の「nproc」よりずっと小さい

この2つがそろっていたら、当たっている可能性が高いです。今回のRunPodのpodは、「nproc」が112で、割り当ては「1190000」=約12コアぶんでした。

決め手がほしいときは、生成を1回流す前とあとで、これを見比べます。

grep nr_throttled /sys/fs/cgroup/cpu.stat /sys/fs/cgroup/cpu/cpu.stat 2>/dev/null

数字が生成のたびに何百も増えていたら、OSに止められています。止められていない環境では、ずっと0のままです。

きっかけ

私はInkubusという小説生成ツールを作っています。Ollamaで動かしているローカルLLMに、夜のあいだ小説を書かせておくツールです。

Inkubusには、書いた作品ごとの速さの記録が残ります。ある日それを見ると、RunPodのRTX 5090で回した31bの数字だけが、段差をつけて落ちていました。

同じ日の中では、どんな作品を書かせてもほぼ同じ数字です。変わっているのは環境のほう。そこでInkubusを通さず、pod(RunPodで借りたマシン)の上で「ollama run」を直接叩いてみました。

Ollama 0.34.4: 19.87 tok/s
Ollama 0.32.13: 72.10 tok/s

同じpod、同じモデル、同じ短い依頼で、約3.6倍です。アプリの問題ではありませんでした。

Windowsでは起きない

次に気になったのは、手元のWindowsでも起きているのかどうかです。

Ollamaのzip版を別のフォルダに置いて(いまインストールしている版はそのままにして)、0.34.4と0.32.13を入れ替えながら、同じ条件で1作品ずつ書かせました。4章、コンテキスト65536、Inkubus経由です。

差はどれも1%以内。Windowsでは起きていません。

RunPodで確かめ直した

RunPodでもう一度、版数を並べて入れて比べました。RTX 5090が品切れだったので、今回はRTX 6000 Ada(VRAM 48GB)です。モデルは4つ。比べる相手として、Gemma 4とは作りの違うgpt-ossも入れました。

結果は画像01のとおりです。0.34.4だけが、4つとも2.2〜2.9倍遅い。GPUが5090でも6000 Adaでも同じように遅くなったので、GPUの種類は関係なさそうです。

このときのpodの中を見ると、こうなっていました。

GPUに全部載っているのに、CPUが12コアぶん回りっぱなしです。そして1回の生成(約25秒)のあいだに、264回OSに止められています。

原因: CPUの空回り

OllamaはGPUで計算するときも、裏でCPUのスレッドをいくつか持っています。モデルによっては、1トークン書くたびに、ほんの少しだけCPUにも仕事を回すからです。

0.32.14で、Ollamaの中に入っているllama.cpp(実際に計算している部品)が更新されました。そこから、このCPUのスレッドが「常駐」するようになります。しかも仕事が終わるたびに、すぐには眠らず、しばらく空回りして次の仕事を待つ設定になっていました。

ここまでなら、CPUが余っている普通のPCでは問題になりません。CPUの使用率が上がって、ファンが少しうるさくなるくらいです。

問題はコンテナです。RunPodのpodからは、ホストの112コアが全部見えています。Ollamaはその数を見て、スレッドを56本作ります。でもそのコンテナに実際に使っていいと許されているCPUは、約12コアぶんだけ。

56人が空回りしながら12席を奪い合う。許された分を使い切ると、OSがコンテナごと少しのあいだ止めます。そのとき、GPUに次の仕事を渡すスレッドも一緒に止まる。GPUは次の仕事が来るまで待つしかありません(ここは数字からの推測ですが、止められた回数が0になると速さが戻るので、たぶん合っています)。

0.32.13も、スレッドは56本作っていました。違うのは空回りしないことです。仕事がないときはちゃんと眠るので、割り当てを使い切らず、止められません。

ちなみに、GitHubの修正プルリクエストには「gpt-ossのようなモデルはCPUに仕事を回さないので影響しない」と書かれていました。でも今回のpodでは、gpt-ossも同じように遅くなっています。CPUに余裕のある機械なら、影響が見えにくいだけなのかもしれません。

直し方

RunPodで確かめたのは次の3つです。どれでも元の速さに戻りました。

[1] 0.32.13に戻す

いちばん確実です。インストールのときに版数を指定できます。

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

Dockerなら、イメージのタグを「ollama/ollama:0.32.13」にします(Dockerの形では私は試していません)。ただし0.32.14以降に入った修正や新しいモデルの対応は、当然入りません。

[2]「num_thread」を割り当て以下にする

スレッドの数を、コンテナに許されたCPUの数より少なくします。今回は8でも12でも同じように戻りました。

私が試したのは、リクエストのoptionsで「num_thread」を渡す形です。Modelfileでも同じ値を指定できます(こちらは試していません)。

FROM gemma4:31b-it-qat
PARAMETER num_thread 8

ollama create gemma4-31b-t8 -f Modelfile

環境変数で一括指定する方法はありません。モデルごとに作ることになります。

[3] llama-serverに「--poll 0」を渡す

空回りそのものを止めます。CPUの使用率もほぼコア1個ぶんまで下がるので、いちばんきれいに直ります。

ただ、Ollamaには「--poll」を渡す設定がありません。なので、Ollamaが呼ぶllama-serverを、同じ名前の小さなスクリプトで包みます。

cd /usr/local/lib/ollama
mv llama-server llama-server.real
cat > llama-server <<'EOF'
#!/usr/bin/env bash
exec "$0.real" "$@" --poll 0
EOF
chmod +x llama-server

公式のインストールスクリプトで入れた場合、llama-serverは/usr/local/lib/ollama/にあるはずです。私はOllamaの配布ファイルを別のフォルダに展開して、その中で同じように包みました。

Ollamaの版数を上げると元に戻るので、そのたびにやり直しです。このやり方はOllamaのGitHubのissue(#18038)に書かれていたものです。

アプリ経由でも同じだけ変わる

短い依頼だけでなく、実際の使い方でも差が出るのかを見ておきました。Inkubusで31bに4章の小説を書かせています。

夜のあいだに回しておく使い方だと、半分の本数しか書けていなかったことになります。Open WebUIやほかのアプリから使っている人も、Ollamaの側で起きていることなので同じはずです。

なおInkubusからは「num_thread」を送れないので、Inkubusで使うなら1(0.32.13に戻す)か3(「--poll 0」)が手軽です。

なぜ騒がれていないのか

いちばん不思議だったのがここです。0.32.14が出たのは8月の半ば。もう1か月半たっています。日本語で検索しても、それらしい話は見つかりませんでした。

調べてみると、理由は5つ重なっていそうです。

普通のPCやMacでは、CPUの使用率が上がるだけで速さは変わらない。ファンが少しうるさくなる程度
遅くなるのは、CPUの割り当てが限られたコンテナだけ。そういう使い方の人は、遅いと感じたらvLLMのような別のソフトに移ってしまう
「ollama ps」は「100% GPU」と出て、エラーも出ない。GPUのせいだと思って、Ollamaを疑わない
GitHubの報告が「CPUが高い」「遅い」「スレッド数がおかしい」と別々のissueに分かれていて、同じ原因に見えない
開発者の環境(CPUに制限のないDocker)では再現しないので、「ログを見せて」で閉じられてしまう

実際、「0.33.2が0.32.13の5倍遅い」という報告(#18225)は、開発者の環境で再現しないという理由で閉じられています。報告した人は、そのあとvLLMに移ったと書いていました。

RunPodで「今日のpodはハズレだった」と作り直していた人の中にも、実はこれだった人がいるかもしれません。私も速さの記録がなければ、そう思って済ませていたはずです。

Ollama側の状況(9月29日時点)

#17833(GPUに全部載っているのにCPUが高い): 未解決
#17916(スレッド数がコンテナの割り当てを無視する): 未解決
修正のプルリクエストは2本出ています。GPUがあるときに「--poll 0」を渡すもの(#18613)と、スレッド数を割り当てに合わせるもの(#17962)。どちらもまだ取り込まれていません
最新の0.34.4と、試験版の0.35.0のリリースノートにも、この修正は入っていません

https://github.com/ollama/ollama/pull/18613

いつ直るかはわかりません。当面は、上の3つのどれかで回避するのがよさそうです。

まとめ(早見)

症状: 「ollama ps」は100% GPUなのに、GPUの使用率が半分くらいしか出ない。生成が2〜3倍遅い
条件: Ollama 0.32.14以降 × CPUの割り当てがあるコンテナ(RunPod、Dockerの「--cpus」など)
見分け方: 「cpu.max」(か「cpu.cfs_quota_us」)の割り当てが「nproc」よりずっと小さい / 「nr_throttled」が生成のたびに増える
直し方: 0.32.13に戻す / 「num_thread」を割り当て以下に / llama-serverを包んで「--poll 0」
起きないところ: 普通のWindows、Mac、CPUの上限のないDocker

おわりに

「新しい版のほうが速いはず」と思い込んでいると、なかなか版数を疑えません。ローカルLLMの速さは、Ollamaの版数とCPUの割り当てでも2倍以上変わる。今回はそれを数字で見られたのが収穫でした。

Inkubusで速さを測っています

今回の段差に気づけたのは、ふだん使っている小説生成ツールInkubusが、書いた作品ごとの速さを残していたからです。最後に、その仕組みを紹介させてください。

InkubusはOllamaで動くローカルLLMに小説を書かせるツールです。ジャンルと設定を入れて夜に回しておくと、朝には何本もの作品ができています。Ollamaを手元のPCで動かすなら、インターネットにつながなくても動きます。

作品ごとに、速さとOllamaの版数が残る

Inkubusは、Ollamaが返す「実際に書いたトークン数」と「書くのにかかった時間」を、作品ごとに記録しています。どの接続先(GPU)で、どのOllamaの版で書いたかも一緒に残ります。

今回、Windowsで新旧を比べたときも、RunPodで3パターンを比べたときも、数字はここから取っています。

ベンチマーク画面で並べて比べられる

記録はジョブ画面の「ベンチマーク」にまとまります。モデルごとに並べる「モデル比較」と、同じモデルをGPUごとに並べる「GPU比較」があって、「画像を保存」でそのまま貼れるカードになります。

上の画像は、この記事の試験で書かせた作品も入った、31bのGPU比較です。接続先の名前に版数を入れておいたので、同じRTX 6000 Adaでも0.34.4だけが20.0 tok/sで、0.32.13と対策した版が38前後に並んでいます。

新しいGPUを借りたときや、Ollamaを上げたときに、いつもの作品を1本書かせるだけで比べられます。今回のような段差も、並べれば一目でわかります。

ひとつ注意。ベンチマークは接続先の名前ごとにまとめる仕組みなので、同じGPUのままOllamaの版を替えたときは、名前を分けておかないと数字が混ざります。私も最初は混ぜてしまい、RTX 5090の行が遅い版と速い版の平均になっていました。

これまでに測った数字は、使い方サイトにもまとめています。

https://inkubus.pages.dev/help/speed

入手について

まず単品で触ってみたい方へ

単品で買えるのはInkubus 3.0です。この記事で使ったベンチマークと、作品ごとの速さや版数の記録は、3.0にも入っています。

3.0の記事は買い切りで、その版で固定です。あとから機能が足されることはありません。