「Ollamaをアップデートしたら推論が遅くなった気がする」——こうした声はGitHubのIssueでも見かける。ユーザー報告にはばらつきがあり、「大幅に遅くなった」というものから「変わらない」というものまで幅がある。これは、バージョンそのものの速度差と、アップデートに伴って変わる設定（特にコンテキスト長の自動設定）やGPU構成の影響が、切り分けられないまま混ざっているからだ。
そこで、手元のRTX 5080 16GBとRTX 5060 Ti 16GB（2枚構成）で、Ollamaの 0.23.3・0.30.6・0.30.7 を同じプロンプト・同じコンテキスト長・同じGPUに固定して実測した。先に結論を言うと、本環境のRTX 5080ではqwen3:8bが0.30.6で落ちて0.30.7で0.23.3並みに戻った一方、ほかのモデルは0.30.7でも0.23.3比で数%低いままだった。RTX 5060 Tiでは3バージョンを通じてほぼ同等。要するに「0.30系がずっと遅い」わけではない。本記事が測ったのは生成tokens/secと起動可否に限られるが、その範囲で見る限り、速度だけを理由に最新版を避ける根拠は薄かった。
なお、ここで示す数値はいずれも筆者環境（後述）での参考値であり、ドライバや筐体、電力設定の異なる環境で同じになるとは限らない。
先に結論：3バージョンの損得早見表
| 観点 | 0.23.3（比較旧版） | 0.30.6 | 0.30.7（2026年6月10日確認時点の最新） |
|---|---|---|---|
| 推論速度（本環境のRTX 5080） | 基準 | 一部モデルで数%〜1割低下 | qwen3:8bは0.23.3並みに回復・他は数%低いまま |
| 推論速度（本環境のRTX 5060 Ti 16GB / Oculink） | 基準 | ほぼ同等 | ほぼ同等 |
| gemma4:12b の起動 | 起動不可 | 起動可 | 起動可 |
| コンテキスト長の既定 | 本環境では4096 | VRAM残量に応じ自動拡大 | VRAM残量に応じ自動拡大 |
判断の目安はシンプルだ。
- gemma4のような新しいモデルを使いたい → 0.30.5以降（対応＋クラッシュ修正済み）を選ぶ
- 速度を気にして旧版に留まっていた → 本環境では0.30.6で見えた低下が0.30系全体で続くわけではなかったので、最新版を一律に避ける理由は薄い
「最新にすると遅くなる」と一括りにはできない。どのバージョンの、どのモデルかで答えが変わる。以下、実測の中身を見ていく。
Ollama 0.30系で何が変わったのか（リリース時系列）
0.30系は内部の実行エンジン（llama.cppバックエンド）まわりが更新されたバージョン群だ。gemma4まわりの変更が複数のバージョンに分かれているので、時系列を整理しておく（公式リリースノートより）。
- v0.30.3：Gemma 4 12B（マルチモーダル）モデルに対応
- v0.30.4：gemma4:12bが浮動小数点例外でクラッシュする既知の不具合
- v0.30.5：そのクラッシュを修正（x86 / CUDA / Linux / Windows）
- v0.30.6：Gemma 4 QAT weights（
gemma4:12b-it-qatなど）を追加 - v0.30.7：Hermes Desktopのネイティブ対応など（2026年6月10日の確認時点での最新）
つまり、gemma4:12bはv0.30.3で対応が追加され、v0.30.5で既知の浮動小数点例外クラッシュが修正された。少なくともこの既知不具合を避けるには 0.30.5以降 が前提で、本記事のWindows/NVIDIA環境では0.30.6・0.30.7で起動を確認した。速度比較もこの0.30.6と0.30.7を対象にしている。
同じGPUで3バージョンはどれだけ違うのか
実測値を示す。プロンプトと生成トークン数を固定し、コンテキスト長は全バージョンとも4096に揃えた。数値は1秒あたりの生成トークン数（tokens/sec、大きいほど速い）で、各モデルをGPUに載せた状態で、測定条件を揃えて取り直した中央値だ（測定条件は「検証環境」の節にまとめた）。あくまで筆者環境での参考比較であり、厳密な再現ベンチとして扱うものではない。
本環境のRTX 5080
| モデル | 0.23.3 | 0.30.6 | 0.30.7 |
|---|---|---|---|
| qwen3:8b | 128.2 | 116.9 | 127.3 |
| gemma3:12b | 86.1 | 80.6 | 81.5 |
| llama3.1:8b | 144.5 | 137.2 | 136.5 |
| gemma4:latest（e4b） | 146.5 | 140.1 | 137.1 |
| gemma4:12b | 起動不可 | 66.4 | 66.6 |
本環境のRTX 5060 Ti 16GB（Oculink接続）
| モデル | 0.23.3 | 0.30.6 | 0.30.7 |
|---|---|---|---|
| qwen3:8b | 74.5 | 75.2 | 75.3 |
| gemma3:12b | 50.6 | 49.2 | 49.1 |
| llama3.1:8b | 84.7 | 83.4 | 81.2 |
| gemma4:latest（e4b） | 93.4 | 87.8 | 92.8 |
| gemma4:12b | 起動不可 | 42.5 | 42.6 |
傾向はこうだ。
- 本環境のRTX 5080では、0.30.6で一部モデルが数%〜1割ほど低下していた。最も安定して測れたqwen3:8bで-9%（128.2→116.9）。これは0.30.7では127.3まで戻り、0.23.3とほぼ同じになっている。
- ただし回復はモデルによる。gemma3:12b・llama3.1:8b・gemma4:latestは0.30.7でも0.23.3比で数%低いままだった。
- 本環境のRTX 5060 Tiでは、3バージョンを通じてほぼ同等（誤差〜数%の範囲）。低下も回復もほとんど見えない。
要するに、本環境で見るかぎり「アップデートで遅くなった」は 0.30.6での一時的・部分的な低下として現れ、最新の0.30.7では少なくともqwen3:8bでは解消していた。0.30.6だけを見て0.30系全体を判断するのは避けたい。
測定で踏んだ落とし穴
この比較は最初から綺麗に取れたわけではない。最初の測定では「0.30.6が40%以上遅い」という、まったく違う結果が出ていた。原因を一つずつ潰すと、いずれもバージョンとは無関係の測定環境の問題だった。
- GPUの取り違え：環境変数
CUDA_VISIBLE_DEVICESの番号が物理カードと一致せず、しかも起動のたびに割り当てが入れ替わった。nvidia-smiでモデルがどちらのカードに載ったかを毎回確認しないと、5080と5060 Tiを取り違えたまま記録してしまう。番号ではなくnvidia-smi -Lで得られるGPUのUUID（CUDA_VISIBLE_DEVICES=GPU-xxxx...）で指定すると、この入れ替わりを避けやすい。 - コンテキスト長の自動拡大：後述するが、0.30系は空きVRAMに応じてコンテキスト長を自動で大きくする。これを揃えずに測ると、KVキャッシュが膨らんでVRAMに収まらず、CPUへ処理がはみ出して激遅になる。
ollama psのPROCESSOR列が100% GPUか、CONTEXT列が意図した値かを見ると、この取りこぼしに気づける。 - モデルの載せっぱなし：複数モデルを連続で測ると前のモデルがVRAMに残り、メモリ不足でやはりCPU処理に落ちる。
これらを排除し、1モデルずつ・GPUを固定・コンテキスト長を揃えて測り直して、ようやく上記の数値に収束した。少なくとも本記事の初回測定では、コンテキスト長の自動拡大・GPUの取り違え・VRAM不足によるCPUオフロードが、速度低下として現れていた。ネット上の報告を読む際も、生成速度とロード時間、GPU配置、num_ctxを切り分けて確認したい。
0.30.6で遅くなったのはなぜか——仮説を立てて検証する
0.30.6の結果には引っかかる点があった。速いはずのRTX 5080でだけ速度が落ち、遅いRTX 5060 Tiでは落ちないのはなぜか。
最初に立てた仮説はこうだった。「RTX 5080はVRAMが高速で、RTX 5060 Ti（Oculink接続）はメモリまわりが速くない。だからメモリ速度に関係した要因で、速いカードだけが影響を受けているのではないか」。
ただ、この仮説にはすぐ穴がある。同じRTX 5080なら、VRAMの物理帯域はバージョンを変えても同じだ。物理帯域そのものがバージョン間の差を生むとは考えにくい（ただし実装変更でメモリアクセスの効率が変わる可能性は残る）。
そこで、速度低下が「リクエストごとの固定コスト」なのか「1トークンを生成する速度そのものの低下」なのかを切り分けた。生成トークン数を変えれば判別できる——固定コストなら短い生成ほど差が大きく、長い生成では薄まる。1トークンあたりの低下なら、生成の長さに関係なく一定の差になる。RTX 5080で生成トークン数を64と1024に変えて、0.23.3と0.30.6を比べた結果がこれだ（qwen3:8b）。
| 生成トークン数 | 0.23.3 | 0.30.6 | 差 |
|---|---|---|---|
| 64 | 135.9 | 121.6 | -10.5% |
| 1024 | 132.5 | 118.3 | -10.7% |
差は生成の長さにほぼ関係なく、一定の約-10.6%だった。固定コストなら短い生成で差が大きくなるはずだが、64でも1024でも同じだけ落ちている。つまり、リクエスト単位のコストではなく、1トークンを生成する速度そのものが落ちていたということになる。なお、レスポンスのログ上はプロンプト処理（プリフィル）よりも生成（デコード）側の低下が目立つ傾向だった。
ここから言えるのは、0.30.6の低下はVRAMの物理帯域ではなく、生成時の計算処理（行列演算の実装）の効率に起因しそうだ、という点だ。当初の「VRAM速度が原因では」という仮説は、速いカードで差が出るという方向は当たっていたが、原因の特定としては外れていた。なお、両GPUはいずれも同世代（Ollamaのサポート上は同じCompute Capability）で、「アーキテクチャの違い」を主因と断定できるだけの根拠は本記事の範囲では得られていない。原因は未特定で、実行エンジン・カーネル・ドライバ・モデル配置などのいずれかが影響した、という仮説にとどまる。
そして注目すべきは、この低下がqwen3:8bでは0.30.7で戻っていたことだ。0.30.6で116.9まで落ちたが、0.30.7では127.3で、0.23.3の128.2にほぼ並ぶ。本記事の測定では戻ったように見えるが、公式リリースノートに速度・カーネル改善の記載はなく、原因は特定できない（実行エンジン・ドライバ・モデル配置などの影響は仮説にとどまる）。いずれにせよ、0.30.6だけを見て「0.30系は遅い」と結論づけると実態を取り違える、という点は複数バージョンを実測して初めて見えてくる。
gemma4:12bはなぜ旧版で動かないのか
表で唯一「起動不可」なのがgemma4:12bだ。0.23.3でロードしようとすると、サーバーログに次のエラーが出て失敗する。
error loading model architecture: unknown model architecture: 'gemma4'旧版の実行エンジンがgemma4というモデル構造を知らないためで、VRAMは足りているのにロードできず500エラーになる。設定で回避できる類の問題ではなく、エンジンが対応していない以上、旧版では動かしようがない。一方、0.30.6・0.30.7では問題なく起動し、本環境のRTX 5080で66 tokens/sec前後、RTX 5060 Tiで43 tokens/sec前後が出た。
紛らわしいのは、gemma4:latestやgemma4:26bは本環境では0.23.3でも起動した点だ。本環境のgemma4:latestは公式タグではgemma4:e4bと同じもの（digest c6eb396dbd59、9.6GB）だった。一方、gemma4:12bはv0.30.3で対応が追加されたモデルで、旧版では動かない。同じ「gemma4」でも、旧版での起動可否はタグ・digest単位で確認するのが確実だ。
gemma4:12bは約12Bで、テキストに加えて画像を入力できるマルチモーダルモデルだ（Ollamaの公式タグでもText/Image入力に対応と示されている）。手元のPCで画像の内容を説明させたり、図表から情報を読み取らせたりできる。ローカルにpullした非cloudタグのモデルを使い、Ollama CloudやWeb search機能を有効にしていなければ、処理はローカルで完結する（機密データを扱うなら:cloudタグを使っていないことを確認し、必要ならOLLAMA_NO_CLOUD=1でクラウド機能を無効化しておくとよい）。こうした新しいモデルが新エンジンを必要としている。
なおlatestというタグは「最新」を指すだけで、中身はモデルが更新されれば変わりうる。後から同じ条件で再現したいなら、gemma4:12bのようにサイズを明示したタグで指定し、ollama showやollama listでdigestを控えておくのが安全だ。
なお、16GBのGPUでGemma 4 12Bを動かしたときの速度やVRAM使用量は、別記事で詳しく実測している。
gemma4:12bを使いたいなら0.30.5以降が前提になる。ここが、最新版を使う明確な動機だ。
コンテキスト長が自動で大きくなる罠
0.30系で挙動が変わった点として、検証中にはっきり確認できたのがコンテキスト長の既定値だ。Ollamaは利用できるVRAMの合計に応じてコンテキスト長を自動で決める。現行の公式Context lengthページによれば、おおよそ「24GiB未満：4k」「24〜48GiB：32k」「48GiB以上：256k」という区分になっている（公式FAQには「既定4096」の記述も残っているので、実際に割り当てられた値はollama psのCONTEXT列で確認するのが確実だ）。
本環境では、qwen3:8bを明示指定なしでロードしたとき、0.23.3ではコンテキスト長が4096だったのに対し、0.30系では利用可能VRAMを32GiB級として扱ったようで、明示指定なしでは32768まで広がった。長い文脈を扱えるのは便利だが、その分KVキャッシュがVRAMを多く消費し、16GBのGPU1枚に収めるつもりだったモデルがVRAMに収まらなくなり、一部がCPUにオフロードされて急に遅くなる——というのが、先に触れた「見かけの速度低下」の一因だった。
対策は、コンテキスト長を用途に合わせて明示指定することだ。長文を扱わないならnum_ctxを4096などに固定すればKVキャッシュの肥大化を防げる。指定方法はいくつかある。
- ネイティブAPI：リクエストの
optionsに"num_ctx": 4096を渡す（本記事の測定もこの方法でバージョン間を揃えた）。 - 実行中に一時指定：
ollama runで開いたセッション内で/set parameter num_ctx 4096。そのセッション限り。 - サーバー既定：環境変数
OLLAMA_CONTEXT_LENGTH=4096（古い資料ではOLLAMA_NUM_CTXの場合もある）。 - Modelfile：
PARAMETER num_ctx 4096を書いてモデルを作り直すと焼き込まれる。OpenAI互換APIではリクエストでcontextを直接変えられないため、この方法を使う。
アップデート後に「なぜか重い」と感じたら、バージョンより先にこのコンテキスト長の自動拡大とVRAM配分を疑うのが近道だ。コンテキスト長をどこまで伸ばせるか、KVキャッシュの量子化でどれだけVRAMを節約できるかは、別記事で実測している。
結局、どのバージョンを使うべきか
本環境での検証から言える実用的な判断はこうだ。
0.30系（できれば0.30.5以降）へ更新したほうがよい場合
- gemma4:12bのような、新しいモデル構造を要求するモデルを使いたい
- 長い文脈を多用し、コンテキスト長の自動拡大が都合よく働く
旧版のままでも困らない場合
- 使っているモデルが旧版でも問題なく動く
- 動作実績のあるバージョンを変えたくない無人運用など
本記事で測った生成tokens/secだけを見る限り、少なくとも本環境では「0.30.6で見えた低下が0.30系全体で続く」とは言いにくかった。ただし、回答の品質・最初のトークンまでの時間（TTFT）・ロード時間・画像理解・長時間の安定性は評価していない。更新は、使うモデルと条件で再確認したうえで判断したい。gemma4対応のような明確なメリットがあるなら、最新版へ更新する価値は分かりやすい。
なお、特定のバージョンに固定したい・戻したい場合、Windows版は自動更新でダウンロード・再起動適用される挙動があるため、固定運用したいなら更新通知や自動更新の設定も確認しておきたい。バージョンを指定するなら、Windowsのwingetで目的のバージョンが提供されているか確認してからインストールする（表示されない場合は実行しない）。
winget show --id Ollama.Ollama --versions --source winget
winget install --exact --id Ollama.Ollama --version 0.23.3 --source winget筆者環境では、アップデートとダウングレードを繰り返した際に、実行エンジンのライブラリが新旧で混在してサーバーが起動直後にクラッシュする（モデルのロード要求がエンジンに届かず500エラーになる）ことがあった。これは公式に一般化できる現象ではないが、入れ替え後に不調が出たときは、いったん完全にアンインストールしてから入れ直すと改善した。
winget uninstall --id Ollama.Ollama
winget install --exact --id Ollama.Ollama --version 0.23.3 --source wingetただし、これを行う前にモデルの保存先（Windows既定はC:\Users\%username%\.ollama\models、OLLAMA_MODELSを設定している場合はその場所）を確認し、必要に応じて退避しておくこと。アンインストールでモデルが必ず残ると保証されているわけではない。winget未収載の最新版（執筆時点でGitHubのみのv0.30.7など）は、公式のダウンロードページまたはGitHub ReleasesのOllamaSetup.exeから入れることになる。
検証環境と測定条件
本記事の測定は筆者の自作環境（RTX 5080とRTX 5060 Ti〔Oculink接続〕の2枚構成、Windows）で実施した。詳しいハードウェア構成は検証環境のページにまとめてある。これは厳密な再現用ベンチではなく筆者環境での参考比較だが、条件を記しておく。
- ネイティブAPI（
/api/generate、stream:false）にoptionsでnum_ctx:4096・num_predict:80を指定。temperature等のサンプリングは指定せず既定のまま、seedは固定していない（このため各回にばらつきが出る）。 - プロンプトは全モデル共通の短文（GPU上のローカルLLMを題材にした生成依頼）。生成長依存の検証ではより長いプロンプトでqwen3:8bを使用。
- 各モデルを1つずつロードし、測定後は
keep_alive:0またはollama stopでアンロードしてから次へ（VRAM残留を避けるため）。 - tokens/secはレスポンスの
eval_count÷eval_durationから算出。各モデル3回測定し中央値を採用。 - GPUは
CUDA_VISIBLE_DEVICESで1枚に固定し、毎回nvidia-smiでモデルが載った物理カードと、ollama psでPROCESSORが100% GPUであることを確認した（番号が物理カードと入れ替わるため）。 - バージョンは0.23.3 / 0.30.6 / 0.30.7。
gemma4:latestは測定時digestc6eb396dbd59。
ここで測ったのは生成のtokens/secと起動可否に限る。各回のraw値（eval_count／eval_duration）や測定日時・ドライバ版まではここに載せていないため、上記はあくまで参考比較として読んでほしい。これらの数値は筆者環境での参考値であり、ドライバ・OS・筐体・電力設定・PCIeリンク幅の異なる環境では結果が変わりうる。
なお、Ollama公式はContext lengthページで、コンテキスト長を大きくすると必要メモリが増えること、ollama psのPROCESSOR列でCPUオフロードの有無を確認することを案内している。本記事でもこの点を確認しながら測定した。
まとめ
- RTX 5080／5060 Tiで0.23.3・0.30.6・0.30.7を同条件で実測すると、本環境では0.30.6でRTX 5080のqwen3:8bが-9%ほど低下し、0.30.7で0.23.3並みに戻った（公式に速度改善の明記はなく筆者環境での実測。他モデルは0.30.7でも数%低いまま）。RTX 5060 Tiでは3バージョンを通じてほぼ同等。
- 「大幅に遅くなった」という体感は、コンテキスト長の自動拡大・GPUの取り違え・VRAM不足によるCPUオフロードといった測定環境の要因や、生成速度とロード時間の混同が混じっていることがある。少なくとも本記事の初回測定はそうだった。
- gemma4:12bは旧版では起動できない（対応はv0.30.3、既知クラッシュ修正はv0.30.5。本環境のWindows/NVIDIAでは0.30.6・0.30.7で起動を確認）。画像入力対応の新しいモデルを使うなら、最新版へ更新する価値は分かりやすい。
- 速度を一律の理由に最新版を避ける必要は薄い。使いたいモデルが動くかを軸に、品質や安定性は運用環境で再確認して選ぶのが実態に合っている。体感で重いと感じたら、バージョンより先に
num_ctxとGPUのVRAM配分を確認するのが近道だ。
参考（公式ドキュメント）
- Ollama リリースノート（GitHub Releases）: https://github.com/ollama/ollama/releases
- コンテキスト長の既定とVRAM別割り当て: https://docs.ollama.com/context-length
- FAQ（ローカル実行とCloud／自動更新／モデル保存先）: https://docs.ollama.com/faq
- API（
/api/generate・keep_alive・options）: https://docs.ollama.com/api/generate - gemma4 モデルページ（タグ・digest・マルチモーダル対応）: https://ollama.com/library/gemma4/tags
