OllamaがWindowsでGPUを使わない・遅いときの確認手順：ollama psとログ

OllamaがGPUを使っているかは、ollama ps の PROCESSOR 列が 100% GPU かどうかで判断します。 27%/73% CPU/GPU のような表示なら、モデルの一部がメインメモリに置かれていて、生成速度は大きく落ちます。GPUを認識しているかは、%LOCALAPPDATA%\Ollama\server.log の inference compute の行で確かめます。

この記事は、Windows 11 + RTX 3090（24GB）+ Ollama 0.30.6 で2026年9月14日に確認した出力をもとに、見る場所と症状別の切り分けを整理したものです。導入と環境変数の一覧はOllama導入ガイド、何GBのモデルが載るかはVRAM別モデルサイズ早見に分けています。

ollama ps でGPUに載っているかを見る

公式FAQは PROCESSOR 列を、100% GPU はモデル全体がGPU、100% CPU は全体がメインメモリ、48%/52% CPU/GPU は両方に分かれて載っている状態、と説明しています。ollama ps はロード中のモデルしか出さないので、一度モデルを呼んでから実行します。

NAME               ID              SIZE     PROCESSOR    CONTEXT    UNTIL
qwen3-coder:30b    06c1097efce0    19 GB    100% GPU     8192       4 minutes from now

APIの /api/ps なら、size（全体）と size_vram（VRAMに載った分）が一致しているかで同じ判定ができます。

curl -s http://localhost:11434/api/ps

"name":"qwen3-coder:30b", "size":19277482556, "size_vram":19277482556, "context_length":8192

server.log でGPUを検出したかを見る

Windows版のサーバーログは %LOCALAPPDATA%\Ollama にあり、公式Troubleshootingによると最新が server.log、古いものが server-#.log です。PowerShellで検出に関係する行だけを抜き出せます。

Select-String -Path "$env:LOCALAPPDATA\Ollama\server.log" -Pattern "inference compute","skipping CUDA device","vram-based default context"

筆者の環境では、起動直後に次の行が出ていました（パスは一部省略）。

msg="skipping CUDA device — compute capability not in compiled architectures" device="NVIDIA GeForce RTX 3090" cc=860 archs="[750 890 1000 1200]" libDirs="[...\\lib\\ollama ...\\lib\\ollama\\cuda_v13]"
msg="inference compute" id=0 filter_id=0 library=CUDA compute=8.6 name=CUDA0 description="NVIDIA GeForce RTX 3090" libdirs=ollama,cuda_v12 driver=13.4 pci_id=0000:45:00.0 type=discrete total="24.0 GiB" available="22.8 GiB"
msg="vram-based default context" total_vram="24.0 GiB" default_num_ctx=32768

• inference compute が本命です。 library=CUDA、GPU名、total と available が出ていれば、推論に使える状態です。認識していなければ、ここにGPUが出てきません。
• skipping CUDA device だけでは失敗ではありません。 RTX 3090（8.6）は cuda_v13 ではスキップされ、次の行で cuda_v12 として検出され、実際に 100% GPU でロードできました。
• vram-based default context は既定のコンテキスト長です（後述）。

ログ先頭の msg="server config" の行には、起動時に読み込んだ環境変数が並びます（筆者の環境では CUDA_VISIBLE_DEVICES: が空、OLLAMA_CONTEXT_LENGTH:0、OLLAMA_NUM_PARALLEL:1）。設定した環境変数が効かないときは、まずこの行に反映されているかを見ます。より詳しいログが要る場合、公式Troubleshootingはトレイからアプリを終了し、PowerShellで次を実行する手順を案内しています（筆者は未実行）。

$env:OLLAMA_DEBUG="1"
& "ollama app.exe"

nvidia-smi はWindowsでは合計を見る

nvidia-smi --query-gpu=memory.used,memory.total --format=csv

表示モードが WDDM のWindowsでは、nvidia-smi のプロセス一覧の GPU Memory Usage がすべて N/A でした。アプリごとの使用量は読めないので、ロード前後の memory.used の差で見ます。筆者の環境では、ロード前2,455MiB、num_ctx 8192でのロード後21,185MiB、ollama stop 後1,669MiBでした。

ドライバー要件は、Hardware supportページが「compute capability 5.0以上・ドライバー550以降（5.0〜6.2は570以降）」、Windowsページが「NVIDIA 551.61以降」と書いています。RTX 30xxは8.6です。

コンテキスト長を上げると一部がCPUに回る

同じモデルとプロンプトで、num_ctx だけを8192と131072に変えて呼び、ollama ps とログを見ました。

curl -s http://localhost:11434/api/generate -d '{"model":"qwen3-coder:30b","prompt":"Write one sentence about GPUs.","stream":false,"options":{"num_ctx":131072,"num_predict":64,"temperature":0}}'
ollama ps

NAME               ID              SIZE     PROCESSOR          CONTEXT    UNTIL
qwen3-coder:30b    06c1097efce0    31 GB    27%/73% CPU/GPU    131072     4 minutes from now

131072のときのログには、配置を決める過程が出ていました。

common_params_fit_impl: projected to use 30024 MiB of device memory vs. 23335 MiB of free device memory
common_params_fit_impl: context size set by user to 131072 -> no change
common_params_fit_impl:   - CUDA0 (NVIDIA GeForce RTX 3090): 49 layers (24 overflowing),  22218 MiB used,   1116 MiB free
load_tensors: offloaded 49/49 layers to GPU
load_tensors:    CUDA_Host model buffer size =  7939.00 MiB
llama_kv_cache:      CUDA0 KV buffer size = 12288.00 MiB

KVキャッシュがコンテキストに比例して16倍になり、必要量30,024MiBが空き23,335MiBを超えました。そこで指定されたコンテキスト長は変えず（no change）、重みの一部をメインメモリ側（CUDA_Host）に逃がす配置になっています。層の数は49/49のままなので、この行だけ見ると全部GPUに載っているように読めます。判定は ollama ps に寄せるのが確実です。

既定のコンテキスト長はVRAMで変わる

公式の Context length ページでは、既定値は24GiB未満で4k、24〜48GiBで32k、48GiB以上で256kです。FAQには「既定は4096」という記述も残っていますが、RTX 3090では上のログのとおり default_num_ctx=32768 でした。

同じページは、エージェントやコーディングツールには64000トークン以上を勧める一方、性能のためにCPUへのオフロードを避けるよう書いています。上のログでは qwen3-coder:30b のKVキャッシュが8192トークンで768MiB（1トークン約96KiB）なので、64000トークンなら約6,000MiBで、GPU側の重み17,524MiBと合わせると空き23,335MiBをほぼ使い切ります（64000では未実測）。Claude Code / Codexから使うときは、CONTEXT列とPROCESSOR列を並べて確認してください。

症状別チェックリスト

GPUを認識しない（100% CPU になる）

• server.log の inference compute 行にGPUが出ているか
• nvidia-smi のヘッダーでドライバーのバージョンが要件を満たすか、GPUの compute capability が5.0以上か
• CUDA_VISIBLE_DEVICES に -1 のような無効なIDが残っていないか。公式ドキュメントでは、無効なIDでCPU実行を強制できると説明されています。server config 行で実際の値を確認します
• 公式Troubleshootingは、一般に最新のドライバーが最もよい結果になると書いています。エラーコード（3、46、100、999）や nvidia_uvm の再読み込みはLinux向けの項目です

一部だけGPU（CPU/GPU に分割される）

• ollama ps の CONTEXT 列で、クライアントが大きな num_ctx を要求していないか
• コンテキストを下げる：API の options.num_ctx、OLLAMA_CONTEXT_LENGTH、アプリ設定のスライダー
• OLLAMA_NUM_PARALLEL を上げていないか。FAQでは必要メモリが並列数 × コンテキスト長に比例するとされています
• FAQにある OLLAMA_KV_CACHE_TYPE（既定 f16、ほかに q8_0 / q4_0）でKVキャッシュを軽くする
• ロード前の nvidia-smi で、他のアプリがVRAMを使っていないか

急に遅くなった

• PROCESSOR 列が以前と同じか。分割に変わっていれば上の項目を順に見ます
• ollama ps に複数のモデルが並んでいないか。不要なら ollama stop <モデル名> ですぐアンロードできます
• 100% GPU のままなら、/api/generate の prompt_eval_count と prompt_eval_duration で、入力が長くなっていないか確認します
• ドライバーやOllamaの更新後なら、server.log と server-#.log の inference compute 行で library や driver を比べます

複数GPU（未検証）

• FAQによると、1枚に収まるならその1枚に載せ、収まらなければ利用可能なすべてのGPUに分散します
• 使うGPUを絞るには CUDA_VISIBLE_DEVICES。番号は順序が変わりうるためUUIDのほうが確実で、nvidia-smi -L で確認できます（例：GPU 0: NVIDIA GeForce RTX 3090 (UUID: GPU-2c992237-...)）

AMD / Intel GPU（公式記載のみ・未検証）

• Windowsでは AMD ROCm v7 / HIP7 対応のドライバースタックが必要です。対応表は Radeon RX 7900 XTX / 7900 XT / 7900 GRE / 7800 XT / 7700 XT / 7600 XT / 7600 と Radeon PRO W7900 / W7800 / W7700 / W7600 / W7500
• RX 6800クラスを含む一部の RDNA2 / RX 6000 系は、現行のWindows向けドライバーでROCm v7が使えない場合があり、既定で有効なVulkanが推奨の代替とされています
• iGPUとdGPUの混在でVulkanが不安定なiGPUを選ぶ場合は GGML_VK_VISIBLE_DEVICES にdGPUの番号を指定します。Vulkan GPUをすべて無効にするには OLLAMA_VULKAN=0 または GGML_VK_VISIBLE_DEVICES=-1
• Intel GPUについては、Hardware supportページにWindows向けの対応表はなく、Vulkanの項にLinux向けIntelドライバーの案内があるだけでした

まとめ

• GPUに載っているかは ollama ps の PROCESSOR 列、認識しているかは server.log の inference compute 行で見る
• num_ctx 8192→131072で 100% GPU が 27%/73% CPU/GPU になり、約160 tok/sが約25 tok/sに落ちた
• 分割されてもログは offloaded 49/49 layers のままだった。CUDA_Host model buffer size が出ていれば重みがメインメモリにある
• 既定のコンテキスト長はVRAMで変わり、24GiBでは32768。エージェント向けに64000以上にすると24GBでは分割の境目になる

GUIのツールと比べたい場合はLM StudioとOllamaの比較を参照してください。遅いと感じたら、設定を触る前に ollama ps を1回打つのが最短の切り分けでした。