OllamaがGPUを使わない？Linux・Windows・WSLでの直し方

TL;DR

モデルをロードした状態でollama psを実行します。PROCESSOR列が真実を語ります。100% GPUならGPUは正常、読み進める必要はありません。40%/60% CPU/GPUのような分割なら、モデルがVRAMに収まらなかったということ——軽いquantを使いましょう。100% CPUならOllamaは使えるGPUを1つも見つけられなかった。たいていは古いドライバー、グループ未加入（LinuxのAMD）、固定されたOLLAMA_LLM_LIBRARY、GPUアクセスなしで起動したコンテナのどれかです。ログが名指しする原因を直せばいい。原因はおよそ5つしかありません。

Ollamaが本当にGPUを使っているか確認するには？

コマンド2本、推測なしで。

# 端末1：モデルをロードする
ollama run llama3.2 "hello"

# 端末2：どこで実行されているか見る
ollama ps

NAME            ID          SIZE     PROCESSOR        UNTIL
llama3.2:latest a80c4de17cd9 3.3 GB   100% GPU         4 minutes from now

PROCESSOR列の状態は3つ：

• 100% GPU — 全レイヤーがオフロード済み。完了です。
• 48%/52% CPU/GPU — 部分的なオフロード。GPUは動いているが、モデル＋コンテキストがVRAMに収まらなかった。後述のVRAMセクションへ。
• 100% CPU — 推論はCPUで実行中。GPUが検出されなかったか、意図的に無効化されています。

続いてサーバーログを読みます。Ollamaが起動時に実際に検出したハードウェアを、ここが名前付きで教えてくれます：

journalctl -u ollama --no-pager | grep -i "inference compute"

健康なNVIDIAマシンなら、次のような行があります：

inference compute id=GPU-xxxx library=CUDA compute=8.9 driver=12.4 name=NVIDIA GeForce RTX 4070

行がまるごと無い、またはCPUフォールバックのメッセージで終わる行しか無ければ、問題のありかは見つかったも同然です。この先は5つの原因を、起きやすい順に並べたものです。

Ollamaが「no compatible GPU discovered」と言うのはなぜ？

NVIDIAでは、容疑者はたいていドライバーであってCUDAではありません。Ollamaは独自のCUDAランタイムライブラリを同梱しているため、CUDAツールキットのインストールは不要です。ただし、同梱ランタイムと対話できるだけ新しいドライバーは必要。nvidia-smiが動くことは証明になりません。ドライバーが存在することしか示さず、新しさは保証しないのです。

nvidia-smi --query-gpu=driver_version --format=csv,noheader

バージョンが数年前のものなら、更新して再起動します：

# Debian/Ubuntu系
sudo apt install nvidia-driver-570
# Arch系
sudo pacman -S nvidia

ドライバー更新後は、Ollamaサービスを再起動してデバイスを再検出させます。検出は起動時に1回だけ、リクエストごとではありません：

sudo systemctl restart ollama

ログがlibrary=CUDA付きでGPUを表示すれば完了です。それでも拒否するなら、OLLAMA_LLM_LIBRARYがどこにも設定されていないか確認しましょう。「アップデート後」のセクションを参照。

Ollamaがモデルの一部にしかGPUを使わないのはなぜ？

部分オフロードはバグではなく算数です。モデルの重みに、コンテキストウィンドウ分のKVキャッシュを足したものがVRAMに収まらなければなりません。7BモデルのQ4はおよそ4〜5GB。そこに8Kコンテキストを与えれば、キャッシュがさらに乗ります。8GBカードでは何かがCPUに残り、ollama psがその配分を見せます。

差を埋める方法を3つ、安い順に：

1. 軽いquant。 Q8からQ4への変更で重みサイズは半減し、品質コストは控えめです。トレードオフの詳細はGGUF quantization levels explainedに譲ります。
2. 短いコンテキスト。 num_ctxがキャッシュサイズを支配します。8GBカードでの32Kコンテキストは、大半のレイヤーがCPUに留まることを意味します。
3. GPUレイヤーを減らす。 num_gpuオプションはオフロードするレイヤー数の上限です。レイヤー総数より小さく設定すれば分割は確定します。ModelfileやAPI呼び出しで誰かが設定しているなら、解除しましょう。

逆の罠にも注意してください。100% GPUを表示しているのに期待より遅い場合は、システムRAMへスワップしている可能性があります。ollama psのSIZEと実際のVRAMを突き合わせてください。

OllamaがAMD GPUを使わないのはなぜ？

Linux上のAMDには3つの要件があり、3つとも確認可能です：

1. ビルドにROCm対応が入っているか。 公式のLinuxインストールスクリプトはROCmビルドを同梱します。サーバーが何を検出したか確認しましょう：

journalctl -u ollama --no-pager | grep -iE "rocm|inference compute"

2. グループ加入。 ROCmランタイムは/dev/kfdと/dev/driへのアクセスを必要とします。つまりrenderとvideoグループです：

sudo usermod -aG render,video $USER
# 一度ログアウトして再ログインしてから：
sudo systemctl restart ollama

このグループ1つの加入漏れこそ、あらゆるフォーラムで最も多い「Ollama not using GPU on Ubuntu」投稿の正体です。ドライバーを再インストールしても消えないのは、ドライバーが最初から原因ではないからです。

3. 対応済みGPU——またはオーバーライド。 非対応のRDNA2コンシューマーカード（gfx1031、gfx1032）は、ROCmスタックが正常に動いていても検出に失敗します。定番の回避策は、互換ターゲットを名乗らせること：

sudo systemctl edit ollama

[Service]
Environment="HSA_OVERRIDE_GFX_VERSION=10.3.0"

続けてsudo systemctl restart ollama。これは非公式ながら広く使われるオーバーライドです。挙動がおかしければ外せば公式サポート圏に戻ります。自動検出と戦うよりバックエンドを完全に自分で握りたいなら、それこそllama.cpp vs Ollamaで扱った核心的な違いです。

WindowsでのAMD対応はより狭い。インストールが壊れたと決めつける前に、Ollamaの対応GPUリストで自分のカードを確認しましょう。

アップデート後にOllamaがGPUを使わなくなったのはなぜ？

アップデートが変えるのは次の3つのどれかです。可能性が高い順に：

1. 固定されたバックエンドライブラリ。 OLLAMA_LLM_LIBRARYは特定のランナー（cuda_v11、rocm、ときにcpu）を強制します。デバッグ用の道具であり、自動検出を黙って上書きし、理由が忘れ去られた後もシェルプロファイルやサービスファイルに居座ります。見つけて消しましょう：

systemctl show ollama --property=Environment | grep -i llm_library
env | grep OLLAMA

2. ドライバーがランタイムに後れを取った。 Ollamaのアップグレードは新しいCUDAランタイムを同梱してきます。あなたのドライバーは、動かさない限り動きません。直し方は上のドライバーセクションと同じです。
3. サービスがコンテナで、フラグが消えた。 GPUフラグなしで作り直されたコンテナは、CPU専用コンテナです。NVIDIAの呼び出しはこう：

docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 ollama/ollama

AMDコンテナなら、同等のものはデバイスパススルー＋グループ追加です：

docker run -d --device=/dev/kfd --device=/dev/dri 
  --group-add video --group-add render 
  -v ollama:/root/.ollama -p 11434:11434 ollama/ollama

--gpus=allが無ければGPUも無い。Dockerが気前よく振る舞う理由はありません。

OllamaはWSL2で動くのか？

動きます。ただし正しいドライバーを正しい場所に。入れるのはWindows用NVIDIAドライバーで、ディストロ内にLinuxドライバーを入れてはいけません。WSL内のドライバーはCUDAパススルーを直すどころか壊します。そのうえでWSL自体を更新し、パススルーデバイスの存在を確認します：

wsl --update   # PowerShellから
ls /dev/dxg    # WSL内——GPU利用には必須

/dev/dxgがあり、Windowsドライバーが最新なら、WSL2のOllamaはネイティブインストール同様にGPUへオフロードします。中継ごと省きたいなら、Windows版Ollamaはネイティブで動き、WSLなしでGPUを見ます。

OllamaにGPUはそもそも必要か？

不要です。CPUのみの実行は機能的には同じで、遅いだけ。高速なCPUなら小さいモデルは十分実用になります。Apple Siliconではそもそも問いが溶解します。Metalはユニファイドメモリを自動で使い、上限はモデルにいくらRAMを分け与えるかだけです。

5分で終わるチェックリスト

症状	原因の見込み	修正
ollama psが100% CPU、NVIDIAカードはある	同梱CUDAに対しドライバーが古すぎる	ドライバー更新、再起動、サービス再起動
100% CPU、LinuxのAMD	render/videoグループ未加入	usermod -aG render,video、再ログイン
100% CPU、非対応のAMDカード	ROCmがgfxターゲットを拒否	HSA_OVERRIDE_GFX_VERSION=10.3.0
40%/60% CPU/GPUの分割	モデル＋コンテキストがVRAM超過	軽いquantか短いnum_ctx
昨日はGPU、今日はCPU	固定されたOLLAMA_LLM_LIBRARYか古いドライバー	環境変数を探して削除、ドライバー更新
ネイティブはGPU、DockerはCPU	GPUフラグなしで起動したコンテナ	--gpus=all（またはAMDデバイス）で再作成

確認の順序はこうです。ollama psで状態、サーバーログで検出リスト、それから表。10回中9回、ログの行がすでに自分のいる行を教えてくれています。