Ollama 0.20.7×NVIDIAドライバ595.97でRTX 5080の推論速度が平均80%向上した件を検証

Ollama 0.20.7×NVIDIAドライバ595.97環境でのRTX 5080推論速度向上とは、当サイト計測で8モデル全てが+75〜86%跳ねた現象である。

結論から言います。当サイトの検証環境（RTX 5080 / i7-14700F / 96GB RAM）で2026-04-18から04-19にかけて計測したローカルLLM 8モデル全てが、tokens/secで+75〜86%の速度上昇を記録しました。phi4:14bは44.2→82.56 tok/s、mistral:7bは85.58→155.15 tok/s、phi4-mini:3.8bに至っては136.61→239.26 tok/sまで跳ね上がっています。ところがOllama v0.20.7の公式リリースノートにはCUDA最適化の記述がなく、NVIDIAドライバ595.97もGame Ready系の修正が中心。公式changelogと実測値のギャップを、温度・消費電力・TTFTも含めて切り分けるのが本記事の狙い。

8モデル全てが一晩で+80%跳ねた異常値の概要

最初に、何が起きたかを数字で確定させます。ベンチマーク記事として主観を挟む余地のない部分から始めるのが筋。前回計測は2026-04-18、今回計測は翌日の04-19。同一GPU・同一ドライバ・同一Ollamaバージョンで、モデルだけ順に走らせています。

観測された変化の全体像

8モデルの変化率を並べると以下の通り。phi4:14bの+86.79%が最大、phi4-mini:3.8bの+75.14%が最小。つまりバラつきはあるものの、全モデルが+75%を下回っていません。特定のパラメータ数やアーキテクチャに偏った現象ではない点が印象的でした。

モデル	前回tok/s	今回tok/s	変化率
phi4:14b	44.2	82.56	+86.79%
qwen3:14b	42.89	79.06	+84.33%
mistral:7b	85.58	155.15	+81.29%
deepseek-r1:8b	73.81	132.68	+79.76%
qwen3.5:9b	60.13	107.77	+79.23%
gemma3:12b	47.99	85.92	+79.04%
llama3.1:8b	79.62	140.47	+76.43%
phi4-mini:3.8b	136.61	239.26	+75.14%

平均すると約+80%。単発のモデルだけ変化したのではなく、全体が一様に底上げされた挙動です。これは「特定モデルのカーネル最適化」では説明しにくい。もっと下の処理段階、ランタイムかドライバ、あるいはキャッシュ層で何かが変わったと考えるのが自然。

この記事で何を切り分けるか

ベンチマーク数値が跳ねたとき、素直に「Ollamaがv0.20.7で速くなった」「ドライバ595.97が効いた」と書けば読者は納得しやすい。ところが実際に公式の変更履歴を読み込むと、CUDA側の最適化は明示されていませんでした。ドライバもGame Ready系の記述が中心。

そうなると残る可能性は以下の3つ。

• 初回ロードのCUDAグラフ未キャッシュ: 前回計測時はOllama更新直後で、cuBLAS/cuDNNのJITキャッシュやCUDAグラフが未構築の状態だった可能性
• スケジューラやメモリ配置の変化: モデル常駐メモリのアロケータ挙動が2回目以降で安定した可能性
• 公式ノートに記載されないサイレントな最適化: 公表されていないCUDA側の挙動変化

本記事ではこの3つを実測データ（TTFT・VRAM・温度・消費電力）と照らし合わせて、どれが最も整合的かを論じます。公式に書かれていない事象を扱うため、推測部分は「〜と考えられる」「〜の可能性がある」と明示して、事実と分離して書いていくつもり。

検証環境と計測条件

速度向上の原因を切り分けるには、まず「何を使って、どう測ったか」を明確にする必要があります。再現性のない計測は、そもそも議論の土台にならない。ここでは検証機のスペックと計測プロトコルを、誰が読んでも同じ条件を再現できるレベルまで詳述します。

ハードウェア構成

当サイトの検証環境は以下の通り。

CPU	Intel Core i7-14700F
GPU	NVIDIA GeForce RTX 5080（VRAM 15.9GB）
RAM	96GB
OS	Windows 10 (10.0.26200-SP0)
NVIDIAドライバ	595.97（Game Ready）
Ollama	v0.20.7
計測日	2026-04-19

GPUはRTX 5080の1枚構成で計測しています。同機には別途RTX 5060 Ti 16GBも搭載されていますが、今回の計測ではデバイス0（RTX 5080）のみを使用。Ollamaが複数GPUを同時に掴むとベンチマーク値が不安定になるため、環境変数で明示的に1枚に固定しました。

RAMが96GBあるのは、大型モデルがGPU VRAMに収まらずCPU側に処理が移った場合でも計測可能にするため。ただし今回の8モデルは最大でも11.0GB程度（phi4:14b）までで、全てRTX 5080の15.9GB枠内に収まっています。つまりCPU側への処理移行の影響は本記事のデータには入っていません。

計測手順とメトリクス定義

計測プロトコルは以下で統一しています。

• 同一プロンプト（日本語200字程度の説明要求）を投入
• 初回ロード後、1回ウォームアップを挟んでから本計測
• 取得メトリクス: tokens/sec（平均）、TTFT（ms、最初のトークン出力までの時間）、VRAM使用量、GPU温度、消費電力
• GPU監視は nvidia-smi の1秒サンプリングで取得

ここで注目したいのは、前回計測と今回計測でこの手順を変えていない点。プロンプトもウォームアップ手順も同一です。つまり「計測方法が変わったから数字が上がった」という説明は成立しません。

それでも念のため、今回の数値を他メトリクスと合わせて記録しておきます。mistral:7bは155.15 tok/s（モデルVRAM使用量 6.2GB・GPU温度62℃・消費電力279W）、phi4:14bは82.56 tok/s（モデルVRAM使用量 11.0GB・62℃・301W）、phi4-mini:3.8bは239.26 tok/s（モデルVRAM使用量 4.7GB・56℃・242W）。本記事冒頭の時系列差分テーブルの値と完全に一致しています。

消費電力の挙動も示唆的でした。前回計測時は同モデルでTDPの上限まで張り付かず途中で下がる傾向が見られたのに対し、今回は安定して200〜300Wを維持。これは「GPUがアイドル近くまで落ちる時間がなく、継続的に計算が走っている」ことを意味します。推論ワークロードが途切れず回っている証拠であり、スケジューラやキャッシュ層の挙動が変わった仮説を補強する材料になります。

8モデル前後比較（実測テーブル）

ここがベンチマーク記事の心臓部。前回（04-18）と今回（04-19）の8モデル実測値を、VRAM消費・TTFTも含めて一覧化します。

大型モデル（14B/12B）の変化

14Bクラス（phi4:14b・qwen3:14b）と12Bクラス（gemma3:12b）を見ると、tok/sの絶対値は40〜50台→80台へ。具体値はphi4:14bが44.2→82.56、qwen3:14bが42.89→79.06、gemma3:12bが47.99→85.92。いずれも2倍近い上昇でした。

大型モデルは1トークンあたりの計算量が多く、カーネル呼び出しオーバーヘッドよりも行列積本体の時間が支配的になります。にもかかわらず+79〜86%の伸びが出たということは、単なるランチャーオーバーヘッドの削減では説明しきれません。行列積カーネル自体が改善された、あるいはメモリ転送のボトルネックが解消されたと考えるのが自然。

各モデルのVRAM使用量は、今回計測でphi4:14bが11.0GB、qwen3:14bが10.7GB、gemma3:12bが9.8GB（いずれも当サイト04-19計測・nvidia-smi 1秒サンプリング・モデルが占有するVRAM量）。RTX 5080の搭載VRAM 16GB（nvidia-smi表示 15.9GB）に対して余裕があり、メモリ不足による退避処理は発生していません。

ミドル・小型モデルの変化

7〜9Bクラス（mistral:7b・llama3.1:8b・deepseek-r1:8b・qwen3.5:9b）と小型（phi4-mini:3.8b）は以下。

モデル	前回tok/s	今回tok/s	変化率	モデルVRAM使用量（今回）
mistral:7b	85.58	155.15	+81.29%	6.2GB
llama3.1:8b	79.62	140.47	+76.43%	6.6GB
deepseek-r1:8b	73.81	132.68	+79.76%	6.8GB
qwen3.5:9b	60.13	107.77	+79.23%	8.7GB
phi4-mini:3.8b	136.61	239.26	+75.14%	4.7GB

小型モデルほど1トークンあたりの計算量が少なく、カーネル起動オーバーヘッドの比率が相対的に高くなります。もしOllama側の起動処理だけが速くなったのであれば、小型モデルの伸びが大きく、大型モデルの伸びが小さいという非対称性が出るはず。ところが実測は+75〜86%の帯にほぼ全モデルが収まっており、極端な非対称性は見られない。

この「全モデルが似た%で伸びている」という観察は、個別カーネル最適化よりも全モデルに共通する下位層の変化を示唆します。具体的にはCUDAコンテキスト・JITキャッシュ・CUDAグラフのいずれか。この仮説は後半のセクションで詳しく切り分けます。

Ollama 0.20.7公式リリースノートに書かれていること

では、公式changelogには何が書いてあるのか。ここを原典で確認しないと、記事として推測だらけになってしまう。GitHubのリリースタグ（https://github.com/ollama/ollama/releases/tag/v0.20.7）を直接確認しました。

公式changelogの実際の内容

Ollama v0.20.7の公式リリースノートに記載されている変更は、主に以下の2点のみです。

• gemma系モデル（gemma:e2b/e4b）で「思考無効時の品質」を修正
• ROCm 7.2.1へのアップデート

以上。CUDAカーネルの変更、推論エンジンの最適化、CUDAグラフ関連の改善、スケジューラの刷新といった記述は一切ありません。

gemma修正は出力品質の話であって、tokens/secが跳ねる理由にはならない。しかも当サイトの計測対象にはgemma:e2b/e4bは入っておらず、gemma3:12bが含まれるだけ。それでもgemma3:12bは+79.04%伸びています。つまり公式に記載された「gemma品質修正」は今回の速度向上と直接関係がないと断言できます。

CUDA最適化が記載されていない意味

ROCm 7.2.1更新はAMD GPUユーザー向けの変更です。NVIDIA/CUDA環境のRTX 5080には影響しません。よって公式changelogに明記された2項目は、どちらもNVIDIA環境の速度向上を説明できない内容でした。

ここで読者に誤解してほしくないのは、「公式に書かれていない=バージョンに何も変わっていない」ではない点。OSSプロジェクトではリリースノートに載らない細かなリファクタやビルドチェーンの更新で挙動が変わることがあります。Ollamaも内部でllama.cppを利用しており、そのビルド時のCUDAランタイムのバージョンが変わった可能性は排除できない。

ただし、それでも+80%という桁の変化を「公表されていない最適化」だけで説明するのは苦しい。公式に明記されない水準の変更でここまで跳ねるのは稀なため、別の処理層（JITキャッシュ・CUDAグラフ構築状態）が効いたと見るほうが自然と考えます。この仮説は後半のセクションで実測挙動と合わせて検証します。

NVIDIAドライバ595.97のリリース情報

Ollama側で説明しきれないなら、次はドライバ。NVIDIA GeForce 595.97の公式リリース情報を確認します。

公式リリースノートの記載範囲

NVIDIA公式の詳細ページ（Driver Details ID 265875）を確認すると、GeForce 595.97はGame Readyドライバとして提供されており、主な記載はHalo Infiniteをはじめとするゲームタイトル向けのバグ修正・最適化です。CUDA向けの推論最適化、PyTorch/TensorRT向けの改善、Ollama固有の対応といった記述はリリースノート上で見つかりません。

もちろんドライバにはCUDAランタイムが含まれており、内部的にcuBLASやcuDNNのバージョンが上がることはあります。ドライバ単独でもRTX 50シリーズ（Blackwell世代）向けのコードパスが改善されていく流れは継続中。ただし595.97は既存の50番台向けドライバ系列の派生であり、リリース時期的にもBlackwell推論向けの大規模最適化が入ったアナウンスはありません。

ドライバだけでは説明できない理由

仮にドライバ595.97でCUDA側が大幅高速化されたのであれば、以下の2点が起きるはず。

• 更新直後（04-18）から速度が跳ねるはず。ところが当サイトの04-18計測は低い値だった
• RTX 50シリーズ全体で同様の速度向上がユーザー間で広く報告されるはず。現時点でそうした大規模報告は見当たらない

つまり「ドライバ595.97が直接+80%をもたらした」という仮説は、タイミング的にも説明が成立しません。ドライバは04-18も04-19も同一バージョン。にもかかわらず一晩で値が変わった。これはドライバ側ではなく、計測機のランタイム状態が変わったと見るのが筋です。

ランタイム状態とは具体的に、CUDAコンテキストの初期化状態・cuBLAS/cuDNNのJITキャッシュ・CUDAグラフのキャプチャ済みキャッシュなど。これらは実行環境のローカル状態であり、ドライバやOllamaのバージョンを変えなくても、起動回数や前回の実行内容によって変わります。

前半はここまで。後半では、この「ランタイム状態の差」を3つの仮説に分解して実測挙動と照らし合わせ、最も整合的な原因を特定していきます。

原因仮説の切り分け（キャッシュ・CUDAグラフ・スケジューラ）

ここからが検証の本丸。ドライバでもOllama公式の変更でもないとすれば、残るのはランタイム状態の差です。+80%という値を説明しうる仮説を3つに絞り、当サイトの04-18/04-19の実測挙動と照らし合わせていきます。

3つの仮説

候補に挙がるのは次の3つ。いずれもローカル環境に閉じた話で、ドライバやOllama公式ノートには載らない領域です。

仮説A: 初回ロード時のCUDAグラフ未キャッシュ
Ollama 0.20.7へ更新した直後の初回実行では、CUDAグラフがキャプチャされていない状態で推論が走る可能性があります。CUDAグラフはカーネルの起動列を一塊にして再利用する仕組みで、これが効くとカーネル起動のオーバーヘッドが減り、小さなバッチや短いシーケンスでスループットが顕著に伸びる傾向。2回目以降の実行でキャッシュが温まるため、同一プロンプトで計測したときに値が跳ねるという説明が成り立ちます。

仮説B: モデル常駐メモリの再配置
Ollamaはモデルをメモリに保持したまま複数リクエストをさばく常駐型の仕組み。更新直後はモデルの再読み込み処理が発生し、VRAM内でのレイアウトが最適でない状態で推論が始まることがあります。24時間経過後に再計測した際、モデルが連続したVRAM領域に再配置されていた可能性。ただしこれはツール内部実装に依存する推測であり、断定はできません。

仮説C: cuBLAS/cuDNNのJITキャッシュ構築完了
cuBLASやcuDNNは初回利用時に一部カーネルをJITコンパイルし、以降のセッションではキャッシュを再利用します。更新直後は~/.nv/ComputeCache が未構築または古いエントリしかなく、04-18の計測は常にJITの遅延を含んだ値だったと考えられる。04-19の計測では各モデルに必要なカーネルが揃っており、この部分のオーバーヘッドが消えた。

実測挙動との整合性

3仮説をTTFT（Time To First Token）と2回目以降の値の挙動で突き合わせます。当サイトの検証環境では、04-18の遅かった計測も04-19の速い計測も、いずれもウォームアップを挟んだ上での平均値。それでも+80%の差が出ました。つまり「各セッション内の初回だけ遅い」という話ではなく、セッションをまたいでも状態が持ち越される何かが関係しています。

この点で仮説Bは弱い。Ollamaが常駐中のモデル配置を日をまたいで勝手に改善する実装は確認できず、推測のまま置いておきます。

仮説Cは筋が通ります。JITキャッシュはユーザーのホームディレクトリに保存され、OSを跨いで持ち越される。更新直後に新しいカーネル群が必要になり、04-18のセッション内でキャッシュが徐々に積み上がった後、04-19のセッションではフルに活用できる状態に達していた——この順序で考えると整合的です。

仮説Aも同様に有力。CUDAグラフ関連のキャッシュがプロセス再起動をまたいで保持される経路が存在すれば、04-18の低い値と04-19の高い値のギャップを説明できます。ただしOllama内部でCUDAグラフをどう扱っているかはバージョンによって異なるため、ここは「可能性の高い仮説」の域を出ません。

結論として最も整合的な仮説

温度・消費電力の挙動も材料になります。04-19の計測では、たとえばphi4:14bが62℃・301W、mistral:7bが62℃・279Wと、GPUが十分に仕事をしている挙動。一方で速度が+80%跳ねている以上、単位時間あたりのトークン出力は増えているにもかかわらず、消費電力が比例して暴騰しているわけではありません。これは「GPU内部のスループットが上がった」というより、「待ち時間の割合が減った」と解釈するほうが自然。つまりカーネル起動やJITコンパイルに費やされていたアイドル時間が消えた、という仮説A・Cと整合します。

結論として、04-18の低値は更新直後のJIT/CUDAグラフ未キャッシュ状態を含んだ値であり、04-19の値が「この環境での本来値」に近いと考えるのが最も整合的。+80%は本質的な高速化ではなく、環境が温まったことによる復帰と見るのが妥当です。

当サイトの検証環境で生成したAI動画サンプルは下のとおり。RTX 5080で生成した4K 60fps動画です。

他環境でも同様の現象は起きるか

この「アップデート直後に挙動が変わる」という話はOllamaに限りません。画像生成ツールの世界でも似た報告が出ています。

他ツールでのアップデート後挙動の報告

Reddit r/comfyui では、数ヶ月ぶりに環境を戻してComfyUIを動かしたユーザーから、VAEのエンコード/デコード処理がCPU側に落ちる・大きなワークフローでシステムがフリーズする・ブラウザが応答しなくなる・RAM使用量が大きく膨れ上がる——といった報告が出ている。具体的な数値はユーザーごとに異なりますが、ポータブル版の再インストールやドライバ更新、カスタムノードの見直しといった初期化寄りの対処で改善したケースもある、とスレッド上では報告されています。

Ollama+CUDAの話とComfyUI+Pythonの話は処理構造がまったく違う。しかし「バージョンを跨いだ後の初回はランタイムが正常に立ち上がりきっていない」「キャッシュやノード構成が古いまま残っている」という構造は共通している可能性があります。投稿者は個別の環境で問題に遭遇しており、全ユーザーに該当する話ではありません。あくまで「似た挙動がコミュニティで観測されている」という参考情報として受け止めるのが妥当。

自分の環境で確認するチェックリスト

読者が自分のマシンで本記事と同じ現象が起きているかを確認する手順を、簡潔に整理します。

• Ollamaまたはドライバを更新した直後に1回ベンチを取り、tokens/secとTTFTを記録する
• 24時間経過後、同一プロンプト・同一モデルで再計測する。差が±5%以内なら環境は安定、+50%以上なら初回ロードの影響を疑う
• ~/.nv/ComputeCache（Windowsでは%LOCALAPPDATA%\NVIDIA\ComputeCache）のファイルサイズが時間とともに増えているかを確認する
• ウォームアップとして短いプロンプトを3回以上流した後で本計測を開始する
• GPU温度・消費電力・VRAM使用量を同時に記録し、速度だけで判断しない

当サイトの検証環境（RTX 5080 / i7-14700F / 96GB RAM）ではこの手順に沿って04-18と04-19の値を並べ直した結果、初回計測の特異性が明確になりました。他環境でも同じ手順を踏めば、自分の計測値が「本来値」なのか「初回値」なのかを切り分けられます。

ローカルLLMユーザーが取るべき運用上の示唆

この一件から抽出できる実務的な教訓は4つ。ベンチマーク計測をする人だけでなく、日常的にローカルLLMを運用している人にも関係する話です。

1つ目は、バージョン更新直後の速度値を鵜呑みにしないこと。数日使い込んだ後に改めて計測しないと、本来の性能を見誤ります。SNSやフォーラムで「更新したら遅くなった」「速くなった」と話題になる数値も、投稿者がどのタイミングで計測したかを見極める必要がある。

2つ目は、ウォームアップ後の2回目以降の値を採用すること。ベンチマークスクリプトの設計として、最初の数回を捨てる実装は一般的。Ollamaのような常駐型ツールでも、モデルをロードした直後の1発目は遅くなりがちです。

3つ目は、同一プロンプト・同一モデル・同一ドライバで再現確認する習慣。条件を揃えずに前後比較すると、何が速度に効いたのかが切り分けられません。当サイトの04-18/04-19比較が意味を持つのは、プロンプト・モデル・ドライバを固定した上で「時間経過」だけを変数にしたから。

4つ目は、公式changelogに書かれない挙動変化も起こりうると理解しておくこと。Ollama 0.20.7のノートにはCUDA最適化の記述がなかった。それでもRTX 5080での実測値は大きく変わった。オープンソースツールはchangelogに書ききれない挙動差を抱えていて、実測して初めて見える差がある——これを前提に運用する姿勢が求められます。

よくある質問

Q. RTX 4060/4070でも同じ+80%現象は起きますか？

本記事で確認しているのはRTX 5080での挙動のみです。ただし仮説（JITキャッシュ・CUDAグラフ未構築）はGPU世代に依存しない仕組みなので、RTX 4060/4070でも「更新直後の初回計測が低く、後日再計測すると値が戻る」傾向は起きうると考えられる。同条件で実測していないため、具体的な上昇幅は不明です。

Q. Ollamaをダウングレードすれば04-18の低い値を再現できますか？

理屈上は可能ですが、~/.nv/ComputeCache やCUDAグラフのキャッシュはOllamaのバージョンとは独立にOSレベルで保持されるため、単純なダウングレードだけでは04-18と同じ状態には戻らない可能性があります。完全再現を狙うなら ~/.nv/ComputeCache のクリアと再起動が必要と考えられる。

Q. NVIDIAドライバを古いバージョンに戻すとtok/sは下がりますか？

ドライバ595.97自体がOllamaに最適化された記述はリリースノートにないため、戻しても大きく変わらない可能性があります。ただしCUDAランタイムの細かなバージョン差で数%動く可能性は残り、断定はできません。

Q. この+80%は恒久的に維持されますか？

本記事の仮説どおり「環境が温まったことによる本来値への復帰」であれば、次にOllamaやドライバを更新するまでは04-19の値が維持されると考えられる。ただし次の更新直後には再び初回ロードの影響で値が一時的に下がる可能性があります。

まとめ

RTX 5080・Ollama 0.20.7・NVIDIAドライバ595.97の組み合わせで、当サイトの検証環境では2026-04-18から04-19にかけて8モデル全てが+75〜86%の速度上昇を記録しました。Ollama公式ノートはROCm更新とgemma品質修正のみでCUDA最適化の記述はなく、NVIDIAドライバもGame Ready系の修正が中心。公式情報と実測値のギャップを、3つのランタイム仮説（CUDAグラフ未キャッシュ・メモリ再配置・cuBLAS/cuDNN JITキャッシュ）で切り分け、最も整合的なのは初回ロード時のキャッシュ未構築という結論に至りました。読者が自環境でこれを確認する手順は本文のチェックリストの通り。

Ollamaバージョン	0.20.7
NVIDIAドライバ	GeForce 595.97
GPU	RTX 5080（VRAM 16GB）
計測日	2026年4月19日（前回比較: 4月18日）
平均改善率	約+80%（8モデル平均）
最大改善率	phi4:14b +86.79%（44.2→82.56 tok/s）
最小改善率	phi4-mini:3.8b +75.14%（136.61→239.26 tok/s）

ベンチマーク値は「計測した瞬間の環境状態」を含んだ数字。自分の環境で同じモデルを走らせるときは、更新直後ではなく数日使い込んだ後の値を基準にしてください。

当サイトはAmazonアソシエイト・プログラムの参加者です。Amazonのアソシエイトとして、当サイトは適格販売により収入を得ています。

おすすめパーツ 価格まとめ

製品名	カテゴリ	スペック	参考価格
RTX 5080	GPU・グラフィックボード	NVIDIA GeForce RTX 5080 16GB GDDR7	¥200,000〜
RTX 4060	GPU・グラフィックボード	NVIDIA GeForce RTX 4060 8GB GDDR6	¥45,000〜（中古相場）

本記事は AIハードウェア図鑑 編集部 が記載時点の情報をもとに執筆。製品アップデートや第三者ベンチマーク・価格・対応ランタイム等の変動で評価が変わる可能性がある。一定期間経過した内容は再検証を推奨する。