RTX 5070 TiでOllamaを動かしたらGPUを認識しない：0xc0000005の切り分けとCPU実測

RTX 5070 Tiを搭載したWindows 11 PCにOllama 0.32.15を導入し、Qwen3 4BとGemma 3 4Bを実際に動かしました。

結論から書くと、今回の環境ではOllama自体とモデル推論は動いたものの、GPU検出用のllama-server.exeが0xc0000005で終了しました。OllamaはRTX 5070 Tiを利用できず、CPUへフォールバックしました。

GPUを搭載していてもCPUへフォールバックしました。「CUDAがないから」と決めつけず、ログから原因を切り分けます。

それでもCore i7-14700Fでは4B量子化モデルが約20〜21 token/sで動作しました。ただし、モデルの回答品質には速度以上に注意すべき差がありました。本記事では、成功した手順だけでなく、GPUを認識しなかったログ、試して効果がなかった設定、2モデルの出力評価まで記録します。

検証日: 2026年8月24日。OllamaやGPUドライバの更新で結果が変わる可能性があります。

検証環境

項目 内容
OS Windows 11 Home 64bit、Version 10.0.26200 / Build 26200
CPU Intel Core i7-14700F、20コア / 28スレッド
メモリ 約32GB
GPU NVIDIA GeForce RTX 5070 Ti
VRAM 16,303 MiB
NVIDIAドライバ 595.71
Compute Capability 12.0
Ollama 0.32.15 Windows portable
Qwen3 qwen3:4b、4.0B、Q4_K_M、2.5GB
Gemma 3 gemma3:4b、Q4_K_M、3.3GB

GPU情報は次のコマンドで取得しました。

nvidia-smi --query-gpu=name,memory.total,driver_version,compute_cap --format=csv,noheader

結果:

NVIDIA GeForce RTX 5070 Ti, 16303 MiB, 595.71, 12.0

Ollamaの導入

公式Windows版は通常のインストーラーで導入できます。今回は検証ファイルをまとめて残すため、公式GitHubリリースのollama-windows-amd64.zipを作業フォルダへ展開しました。

モデル保存先を分け、LANへ公開しないよう127.0.0.1だけで待ち受けます。クラウド機能も無効化しました。

$env:OLLAMA_MODELS = 'C:\path\to\ollama\models'
$env:OLLAMA_HOST = '127.0.0.1:11434'
$env:OLLAMA_NO_CLOUD = 'true'
ollama.exe serve

起動確認:

Invoke-RestMethod http://127.0.0.1:11434/api/version

今回は次の応答が返りました。

{"version":"0.32.15"}

発生した問題：RTX 5070 Tiが認識されない

サーバー起動直後、CUDA v12、CUDA v13、Vulkanの各デバイス検出がすべて失敗しました。

主要部分を抜粋します。

failure during llama-server GPU discovery
error="llama-server --list-devices failed: exit status 0xc0000005"

inference compute id=cpu library=cpu
total_vram="0 B"

0xc0000005はWindowsのアクセス違反を示す終了ステータスです。ただし、この値だけではドライバ、ランタイム、Ollama同梱バックエンドのどこが原因か断定できません。

重要なのは、nvidia-smiではGPU名、VRAM、ドライバ、Compute Capabilityを正常に取得できたことです。「WindowsがGPUを認識していない」のではなく、今回失敗したのはOllamaに同梱されたllama-serverのGPU初期化処理です。

/api/psも次の状態を返しました。

{
  "model": "qwen3:4b",
  "size_vram": 0,
  "context_length": 4096
}

したがって、少なくともこの実行ではGPUへモデルがロードされていません。

GUIでも確認する：タスクマネージャーの見方

ログだけでは直感的に分かりにくいため、Windowsのタスクマネージャーでも確認しました。人が普段使うときは、CUIとGUIを次のように使い分けると切り分けやすくなります。

  1. Ctrl + Shift + Escでタスクマネージャーを開く。
  2. 「プロセス」でllama-serverを探し、モデルロード後のCPUとメモリ使用量を見る。
  3. 「パフォーマンス」→「GPU」を開き、グラフ名をCUDAまたはCompute系に切り替える。
  4. Ollamaへ長めのプロンプトを送り、生成中だけGPU使用率と専用GPUメモリが増えるか観察する。
  5. 同時にollama psまたは/api/psでsize_vramを確認する。

今回、モデルロード後のllama-serverはタスクマネージャー上で約3.7GBのメモリを使用しました。一方、Ollama APIのsize_vramは0で、生成中のGPU使用率もベース負荷と区別できない3〜4%でした。タスクマネージャーだけでCPU/GPU実行を断定せず、Ollama側の値と突き合わせるのが重要です。

Ollamaの実行状況を確認したWindows 11のタスクマネージャー画面
Ollamaの実行状況を確認したWindows 11のタスクマネージャー画面

実験時のタスクマネージャー。GUIの使用率だけで判断せず、Ollama APIのsize_vramやログと突き合わせて実行先を判定しました。

GUIは「負荷が動く瞬間を目で確認する」ことに向き、CUI/APIは「バージョン、実行先、測定値を正確に記録する」ことに向きます。本記事では両方が一致するかを確認しました。

試したが改善しなかった設定

RTX 5070 Ti / BlackwellのWindows向けllama.cpp事例で挙げられていた、次の環境変数を追加してOllamaを再起動しました。

$env:CUDA_VISIBLE_DEVICES = '0'
$env:CUDA_MODULE_LOADING = 'LAZY'

結果は変わらず、CUDA v12 / v13 / Vulkanの--list-devicesが0xc0000005で終了しました。

この結果から言えるのは「今回の構成では、この2設定だけでは改善しなかった」ことだけです。別のPCやOllamaバージョンで無効とは限りません。

WSL 2では同じGPU・同じOllama版で成功した

Windowsネイティブ版だけの問題かを切り分けるため、同じPCへWSL 2とUbuntu 26.04 LTSを導入しました。WSL側では、WindowsホストのNVIDIAドライバを介してRTX 5070 Tiを追加のLinux用ディスプレイドライバなしで認識しました。

/usr/lib/wsl/lib/nvidia-smi \
  --query-gpu=name,memory.total,driver_version,compute_cap \
  --format=csv,noheader

結果:

NVIDIA GeForce RTX 5070 Ti, 16303 MiB, 595.71, 12.0

Linux版Ollama 0.32.15のサーバーログでは、Windows版で失敗したGPU列挙が正常に完了しました。

inference compute id=0 library=CUDA compute=12.0
description="NVIDIA GeForce RTX 5070 Ti"
libdirs=ollama,cuda_v13 driver=13.2
total="15.9 GiB" available="14.7 GiB"

同じgemma3:4bを同条件で実行した結果です。

実行環境 状態 生成速度 API size_vram 最大GPU使用率 最大GPUメモリ 最大電力
Windows 11ネイティブ CPUフォールバック 約21.47 token/s 0 4% 1,057 MiB（画面表示等を含む） 未測定
WSL 2 初回 CUDA、モデルロード込み 94.65 token/s 2,875,520,450 byte 81% 4,550 MiB 197.02 W
WSL 2 温間 CUDA、ロード済み 177.39 token/s 2,875,520,450 byte 82% 4,561 MiB 203.45 W

温間実行の生成部分はWindows CPU実行の約8.3倍でした。初回の壁時計時間は39.08秒ですが、これはモデルをVRAMへロードする時間を含みます。ロード済みの2回目は198 tokenを1.26秒で返しました。

WSL 2上でGemma 3 4Bが日本語を生成した実測GUI
WSL 2上でGemma 3 4Bが日本語を生成した実測GUI

WSL 2上のGPU推論で得た実出力。速度、token数、経過時間、Ollama APIのsize_vramを同じ画面へ表示しています。末尾のカーソルは文章が表示される様子を示すためのUIです。

この比較により、少なくとも今回の原因は「NVIDIA/CUDAドライバが存在しない」ことではありません。同じホストドライバでWSL版がCUDA推論できるため、Windows版Ollamaに同梱されたGPUバックエンドまたはWindows側DLL経路の問題である可能性が高くなりました。

OllamaのIssue #17375には、RTX 4060 LaptopとOllama 0.32.3で同じGPU検出時の0xc0000005とCPUフォールバックが報告されています。また、llama.cppのIssue #22696には、RTX 5070 Ti / Compute Capability 12.0でのビルド時アーキテクチャ指定やCUDA DLL競合などの論点があります。今回の症状との類似性はありますが、同一原因だとは断定していません。

CPUフォールバックでもモデルは動く

GPU検出には失敗しましたが、OllamaサーバーとCPU推論は動作しました。次の2モデルを取得しました。

ollama pull qwen3:4b
ollama pull gemma3:4b
ollama list

取得結果:

NAME         SIZE
gemma3:4b    3.3 GB
qwen3:4b     2.5 GB

ベンチマーク方法

温度0、seed 42、コンテキスト4096に固定し、次の3タスクを各モデルへ与えました。

  1. 量子化とVRAMについて400字以内で説明
  2. CSVの数値列を集計するPython標準ライブラリのコード生成
  3. 今回の0xc0000005を、事実・仮説・回避策に分けて整理

Ollama APIのeval_countとeval_durationから生成速度を計算し、250ms間隔でnvidia-smiを取得しました。出力上限はQwen3の初回試行が512、追加試行とGemma 3が768 tokenです。

生成速度の計算式:

生成速度[token/s] = eval_count / (eval_duration / 1,000,000,000)

APIリクエストの主要条件:

{
  "stream": false,
  "think": false,
  "options": {
    "temperature": 0,
    "seed": 42,
    "num_ctx": 4096,
    "num_predict": 768
  }
}

実測結果

Gemma 3 4B（CPUフォールバック）

タスク 壁時計時間 出力token 生成速度 最大GPU使用率 最大GPUメモリ
技術解説 18.94秒 337 21.47 token/s 4% 1,057 MiB
Pythonコード 36.58秒 768 21.27 token/s 4% 1,056 MiB
障害切り分け 37.29秒 768 21.03 token/s 4% 1,055 MiB

Qwen3 4B（CPUフォールバック）

最初の512 token上限の試行では、3タスクとも約20.18〜20.64 token/sでした。追加の768 token上限の試行でも約19.79〜20.09 token/sです。

GPU使用率は最大3〜4%、GPUメモリは約1,060 MiBでした。これはWindowsの画面表示等を含む値で、Ollamaのsize_vramは0です。したがって「GPU使用率が数%あるからOllamaがGPU推論した」とは判断できません。

Core i7-14700Fで4B Q4_K_Mモデルが約20〜21 token/s出たため、短いチャットや文章処理はCPUでも可能です。しかし、RTX 5070 Tiを搭載している意味は活かせていません。

回答品質の比較

速度だけを見るとGemma 3とQwen3は近い結果でしたが、品質には明確な差がありました。

Qwen3 4B：思考文が出力枠を消費

think:falseを指定しても、今回の/api/generateでは英語の思考過程から出力が始まりました。512 tokenを使い切り、最終的な日本語回答へ到達しないタスクがありました。

さらに障害切り分けでは、プロンプトに「現在は2026年8月」と書いても、RTX 5070 Tiを未発売だと扱う古い知識が現れました。/no_thinkをプロンプト先頭へ追加した再試行でも改善しませんでした。

この結果はQwen3全体の評価ではなく、Ollama 0.32.15、qwen3:4b、/api/generate、今回のテンプレートの組み合わせに対する結果です。

Gemma 3 4B：回答には到達するが、検証は必須

Gemma 3は技術解説を337 tokenで完結させました。Pythonコードも実際のコードを返し、Qwen3よりタスク達成度は高い結果でした。

ただし、コードには次の問題がありました。

  • mathをimportしたが使用していない
  • 戻り値の型が統計4項目の意味を表せていない
  • CSVをencoding指定なしで開いている
  • float(None)等で発生するTypeErrorを行単位で処理していない
  • 広すぎるexcept Exceptionで予期しない不具合を隠す
  • 768 token上限で使用例が途中終了した

障害切り分け回答でも、存在を確認していないconfig.propを候補に挙げるなど、もっともらしい誤情報が混ざりました。「ローカルで動いた」ことと「回答を信頼できる」ことは別です。

実験から分かったこと

  1. Ollamaが起動しても、GPU推論できているとは限らない。 ollama ps、/api/ps、サーバーログの3点を確認する。
  2. nvidia-smiでGPUが見えることと、OllamaのCUDA初期化成功は別問題。
  3. CPUでも4B量子化モデルは実用速度になり得る。 今回のi7-14700Fでは約20〜21 token/sだった。
  4. 小型モデルは速度より出力制御と事実性が問題になることがある。
  5. 生成コードは必ず実行・レビューする。 型、例外処理、文字コード、未使用importまで確認する。
  6. 障害対応をモデルだけに任せない。 公式ドキュメント、実ログ、既知Issueで裏付ける。

未解決のGPU経路を切り分ける条件

GPU経路については未解決です。次の条件を一つずつ変えると、原因を切り分けられます。

  • Ollamaの更新版・旧版で再現性を確認
  • 公式インストーラー版とportable版を同条件で比較
  • llama-server.exe --list-devices --offline --verboseを各バックエンドで直接実行
  • CUDA Toolkit由来DLLがPATHへ混入していないか確認
  • llama.cpp公式Windowsバイナリ、またはCompute Capability 12.0指定ビルドで比較
  • GPUが認識した後、同じプロンプトでCPU/GPUの速度、VRAM、消費電力を再測定

GPU経路が直った場合は、本記事へ結果を追記します。現時点で「RTX 5070 TiならOllamaが必ずGPUで動く」とは書けません。

参考資料

再現用データ

検証に使用したスクリプト、CSV、API応答全文、GPUサンプル、Ollamaサーバーログは、記事作成時の作業フォルダに保存しています。測定値を転記する際は、丸め前のJSONを原本としました。

関連記事