Ollama を使っているのにGPUが動いていない？」
ローカルLLMをWindows PCで動かしていると、こんな疑問にぶつかることがあります。
「NVIDIA GPUを搭載しているのに、OllamaでGPUが使われていないように見える」
特に、OllamaでQwen3などのLLM を動かしている場合、タスクマネージャーを見るとGPU使用率が低かったり、CPU使用率ばかりが高かったりします。
さらに、Ollamaの内部で使われている llama-server.exe を直接調べて、
llama-server.exe--list-devices と実行したところ、
Available devices: (none) と表示されれば、
「やはりCUDAが認識されていないのでは？」
と考えてしまいます。
実際、今回の環境でもまさにこの現象が発生しました。
ところが、Ollamaのログを詳しく調べてみると、結論はまったく違っていました。
GPUは使われていたのです。
しかも、Qwen3:4Bでは、
CUDA0 model bufferoffloaded 22/37 layers to GPU という、GPUオフロードを明確に示すログが確認できました。
一方、Qwen3:8BではGPUが使われず、CPUのみで動作していました。
この記事では、この調査過程をもとに、
OllamaでGPUが使われないように見える理由 CUDAが本当に動作しているか確認する方法 llama-server.exe --list-devices の意味Ollamaのログを見る重要性 GPUオフロードとVRAM容量の関係 Qwen3:4BとQwen3:8Bで結果が違った理由 OLLAMA_LIBRARY_PATH をむやみに変更しないほうがよい理由--gpu-layers、--fit、--device などの意味について、実際のログを交えながら整理します。
1. 今回の環境 今回検証したのは、Windows上でOllamaを利用してローカルLLMを動かす環境です。
GPUは、
NVIDIA GeForce GTX 1050 Ti / VRAM 4GB
です。
CPUはIntel Core i7-8700、メモリは16GBという環境です。
Ollamaでは、これまでQwen系モデルを中心に動作確認を行ってきました。
特に今回比較したのは、
です。
ここで重要なのは、「モデルの大きさ」と「GPUに載るかどうか」は別問題ではあるものの、VRAM容量が大きく影響する ということです。
4GB VRAMしかないGTX 1050 Tiでは、8Bクラスのモデルを完全にGPUへ載せるのは難しくなります。
2. 最初の疑問：「llama-serverにGPUがない？」 まず、Ollamaが使用している llama-server.exe の場所を調べました。
PowerShellで、
Get-ChildItem"C:\Users\maps\AppData\Local\Programs\Ollama\lib\ollama" `-Recurse-Filter"llama-server.exe"|Select-ObjectFullName を実行します。
すると、
FullName--------C:\Users\maps\AppData\Local\Programs\Ollama\lib\ollama\llama-server.exe と表示されました。
そこで、この実行ファイルを直接起動して、
&"C:\Users\maps\AppData\Local\Programs\Ollama\lib\ollama\llama-server.exe"--list-devices を実行します。
結果は、
Available devices: (none) でした。
これは一見すると、かなり重大な問題に見えます。
「CUDAが入っていない？」
「NVIDIA GPUを認識していない？」
「OllamaがCPU版になっている？」
と考えるのは自然です。
しかし、ここでこの結果だけを見て「GPUが使われていない」と判断してはいけません。
3. 決定的だったのはOllamaのserver.log 次に確認したのがOllamaのログです。
Windowsでは、
Get-Content"$env:LOCALAPPDATA\Ollama\server.log"-Tail100 のようにしてログを確認できます。
ここで非常に重要なログが見つかりました。
Qwen3:4Bを読み込んだとき、
load_tensors: offloading output layer to GPUload_tensors: offloading 21 repeating layers to GPUload_tensors: offloaded 22/37 layers to GPU と表示されていました。
さらに、
load_tensors: CUDA0 model buffer size = 1515.48 MiBload_tensors: CUDA_Host model buffer size = 1164.72 MiB とも表示されています。
これは非常に重要な情報です。
つまり、
Qwen3:4Bでは実際にCUDAデバイスへモデルの一部がオフロードされています。
「GPUが使われていない」のではありません。
むしろ、
GPUに全部は載らないため、GPUとCPUを組み合わせて動かしている
という状態です。
4. 「GPU使用率が低い」＝「GPUを使っていない」ではない ここはローカルLLMを扱ううえで非常に重要です。
GPUを使っているかどうかを、
WindowsタスクマネージャーのGPU使用率
だけで判断するのは危険です。
LLMの推論では、モデルのすべてがGPUに載っているとは限りません。
たとえば、
モデル ├─ GPU │ ├─ Layer 1 │ ├─ Layer 2 │ ├─ ... │ └─ Layer 22 │ └─ CPU ├─ Layer 23 ├─ ... └─ Layer 37 というような構成が可能です。
今回のQwen3:4Bでは、まさに、
37 layers↓22 layers GPU15 layers CPU側 というGPUオフロードが行われています。
llama.cppでは --gpu-layers / --n-gpu-layers によってVRAMへ置くレイヤー数を指定できます。また現在のllama.cppには、デバイスのメモリに合わせて設定を調整する --fit もあります。
したがって、
GPU使用率が100%ではない
ことと、
GPUを使っていない
ことは同じではありません。
5. Qwen3:4BではGPUが実際に使われていた 今回もっとも重要な証拠は、このログです。
load_tensors: offloading output layer to GPUload_tensors: offloading 21 repeating layers to GPUload_tensors: offloaded 22/37 layers to GPU さらに、
CUDA0 model buffer size = 1515.48 MiB となっています。
つまり、
CUDA0に約1.5GBのモデルバッファが確保されている
ことが確認できます。
さらにKVキャッシュも、
llama_kv_cache: CUDA0 KV buffer size = 672.00 MiBllama_kv_cache: CPU KV buffer size = 480.00 MiB となっていました。
ここから分かることは、
モデル本体だけでなく、KVキャッシュもGPU側に一部配置されている
ということです。
これは「GPUが使われている」という非常に強い証拠です。
6. では、なぜQwen3:8BではGPUを使わなかったのか？ ここでQwen3:8Bを見てみます。
ログには、
print_info: model type = 8Bprint_info: model params = 8.19 Bprint_info: general.name = Qwen3 8B とあります。
さらに、
print_info: file size = 4.86 GiB となっています。
ここが重要です。
GTX 1050 TiのVRAMは4GBです。
一方、モデルファイルだけで、
4.86 GiB
あります。
つまり、
モデルそのものがVRAM容量を超えている
わけです。
しかも、LLMを実行するにはモデル本体だけあればいいわけではありません。
KVキャッシュや計算用バッファなども必要になります。
したがって、
4GB VRAM ↓Qwen3:8B ↓モデルだけで4.86GiB ↓さらにKV cacheなどが必要 となれば、4GB VRAMに完全に収めることはできません。
7. Qwen3:8BはCPU動作になった 実際のログも、それを裏付けています。
load_tensors: CPU model buffer size = 1818.63 MiBload_tensors: CPU_REPACK model buffer size = 3159.00 MiB さらに、
llama_context: CPU output buffer sizellama_kv_cache: CPU KV buffer size そして、
sched_reserve: CPU compute buffer size となっています。
つまり今回のQwen3:8Bは、
CPU側にモデルを配置して推論している
と判断できます。
これは、
「CUDAが壊れている」
「NVIDIA GPUが認識されていない」
という意味ではありません。
単純に、
4GB VRAMではQwen3:8BをGPU中心で動かす条件が厳しい
ということです。
8. 「モデルサイズ4.86GiB」なのに4GBなら、なぜ一部GPUに載せないのか？ ここは少し注意が必要です。
「4.86GiBなら、4GBに収まらないのだからGPUは一切使えない」と単純に考えることもできますが、実際にはGPUオフロードにはさまざまな構成があります。
llama.cppには、
--gpu-layers--device--split-mode--tensor-split--fit など、GPU/CPU間の配置を調整する仕組みがあります。
特に現在のllama.cppでは、
--fit [on|off] があり、デフォルトは on です。
--fit は、利用可能なデバイスメモリに合わせてモデルやコンテキストなどの設定を調整するための仕組みです。
つまり、
「全部GPUに載せられないなら、CPUとGPUを組み合わせる」
という考え方ができます。
ただし、モデルやバージョン、利用可能なメモリ、コンテキストサイズなどによって最適な配置は変わります。
9. --list-devices の (none) はどう考えるべきか？ 今回、一番混乱したのがここでした。
直接、
llama-server.exe--list-devices を実行すると、
Available devices: (none) です。
しかしOllamaのログでは、
CUDA0 model buffer size が存在しています。
つまり、
直接起動したllama-server ↓--list-devices ↓(none) VSOllama ↓runner / llama-server ↓CUDA0 ↓GPU使用 という状態です。
ここから分かるのは、
「--list-devices の結果だけを根拠にOllamaのGPU動作を判断してはいけない」
ということです。
llama.cppのドキュメント上、--list-devices は利用可能なデバイス一覧を表示するオプションです。--device はオフロードに使用するデバイスを指定し、--gpu-layers はVRAMへ置く最大レイヤー数を指定します。
しかし、Ollamaが内部でrunnerを起動する際には、環境やバックエンド、ライブラリの読み込み方などが関係します。
そのため、
llama-server.exe --list-devices が (none)
とは限りません。
10. 一番信頼できるのは「実際のロードログ」 では、何を見ればいいのでしょうか。
個人的には、今回の調査を通じて、
実際にモデルをロードしたときのログが最も重要
だと考えています。
例えば、
offloading output layer to GPUoffloading 21 repeating layers to GPUoffloaded 22/37 layers to GPU というログがあれば、GPUオフロードが行われています。
さらに、
CUDA0 model buffer size = ...CUDA0 KV buffer size = ...CUDA0 compute buffer size = ... などがあれば、GPU側に実際のバッファが確保されています。
逆に、
CPU model bufferCPU KV bufferCPU compute buffer だけであれば、CPU動作の可能性が高くなります。
11. nvidia-smi も必ず使いたい WindowsでNVIDIA GPUを使っている場合、OS側からGPU状態を確認する方法として、
nvidia-smi も非常に有効です。
LLMを実行している状態で、
nvidia-smi を実行すれば、
GPU使用メモリ GPU使用率 GPUプロセス GPU温度 GPU負荷 などを確認できます。
特に重要なのは、
モデルをロードした直後だけでなく、実際に推論している最中に確認すること
です。
アイドル状態ではGPU使用率が低くても不思議ではありません。
12. ollama ps も確認する Ollama側では、
ollamaps も確認ポイントです。
モデルが現在ロードされているか、CPU/GPUの利用状況がどうなっているかを見るための手掛かりになります。
ただし、ここでも重要なのは、
一つの表示だけで結論を出さない
ことです。
おすすめは、
ollama ps ↓nvidia-smi ↓server.log の3方向から確認することです。
13. OLLAMA_LIBRARY_PATH を変更すればGPUが使える？ 今回の調査では、次のような環境変数も試しました。
$env:OLLAMA_LIBRARY_PATH="...\cuda_v13" そして、その状態で、
llama-server.exe--list-devices を実行しても、
Available devices: (none) でした。
ここで、
「CUDAのパスが違うのでは？」
と考えて、さらに環境変数を変更したくなります。
しかし、今回のケースでは、これは慎重に扱うべきです。
なぜなら、すでにOllamaの実際のログで、
CUDA0 model buffer が確認できているからです。
つまり、
Ollama内部ではCUDAバックエンドが正常に動いている
からです。
この状態で環境変数を次々変更すると、逆に環境を複雑にしてしまう可能性があります。
14. 「GPUを使わせるための設定変更」が逆効果になることもある ローカルLLMでは、
GPUを使わせたい
ということもあります。
特にVRAMが4GB程度しかない場合は注意が必要です。
今回のような環境では、
GPUに全部載せる ことを目標にするより、
GPUに載せられるところまで載せるCPUとGPUを適切に分担する という考え方のほうが現実的です。
llama.cppの現在のserverオプションでも、--fit はデバイスメモリに合わせて設定を調整するための機能として用意されています。
15. コンテキストサイズもVRAMを消費する 今回のQwen3:8Bでは、
llama_context:n_ctx = 4096 となっていました。
一方、Qwen3:4Bでは、
n_ctx = 8192 でした。
LLMでは、モデル本体だけではなくコンテキスト長に応じてKVキャッシュなどのメモリ使用量も増えます。
今回Qwen3:4Bでは、
CUDA0 KV buffer = 672 MiBCPU KV buffer = 480 MiB となっていました。
つまり、コンテキストサイズは単なる「何文字まで読めるか」という設定ではなく、
GPU/CPUメモリ使用量にも関係する重要な設定
です。
VRAMが少ないPCでは、
32K↓16K↓8K↓4K のようにコンテキストを減らすことで、モデルを動かしやすくなる場合があります。
16. だから「GPUが使われない」ときの調査順序が重要 今回の経験から、Windows + Ollama + NVIDIA GPUで問題を調査するときは、次の順序がおすすめです。
STEP 1：GPUそのものを確認 nvidia-smi ここでNVIDIA GPUが正常に認識されているか確認します。
STEP 2：Ollamaのバージョンを確認 ollamaversion バージョンによって内部のrunnerやllama.cppの挙動が変わる可能性があるため、最初に記録しておきます。
STEP 3：モデルをロードする 例えば、
ollamarunqwen3:4b などでモデルを実際にロードします。
STEP 4：ollama ps ollamaps モデルの実行状態を確認します。
STEP 5：nvidia-smi モデルがロードされた状態で、
nvidia-smi を実行します。
VRAM使用量が増えていれば重要な手掛かりになります。
STEP 6：server.log 最終的に一番重要なのが、
Get-Content"$env:LOCALAPPDATA\Ollama\server.log"-Tail150 です。
ここで、
CUDA0offloadingGPU などを探します。
17. ログからGPU使用を判断するキーワード Ollama/llama.cppのログを見るときは、次の文字列を検索すると便利です。
GPU動作を示す可能性が高いもの CUDA0offloadingoffloadedGPUCUDA model bufferCUDA KV bufferCUDA compute buffer 例えば、
offloaded 22/37 layers to GPU は非常に分かりやすいです。
一方、
CPU model bufferCPU KV bufferCPU compute buffer が並んでいる場合はCPU中心の動作を疑います。
llama.cpp自身もGPUオフロードの確認では、実行開始時にGPUへ処理がオフロードされていることを示す診断情報を見る方法を案内しています。
18. 「GPUを使う」には段階がある ローカルLLMでは、
GPUを使う / 使わない
の二択で考えないほうが分かりやすいです。
実際には、
レベル1：完全CPU CPU└── モデル全部 レベル2：一部GPU GPU├── 一部のLayer└── KV cacheの一部CPU├── 残りのLayer└── その他 レベル3：ほぼGPU GPU├── モデル├── KV cache└── 計算 レベル4：完全GPU GPU└── ほぼすべて というように段階があります。
VRAMが4GBのGTX 1050 Tiでは、Qwen3:4Bはレベル2～3に近い使い方が現実的です。
一方、Qwen3:8Bでは今回、CPU中心になりました。
19. 今回の検証結果を表にすると 項目 Qwen3:4B Qwen3:8B パラメータ 約4B 約8.19B モデル Q4系 Q4系 VRAM 4GB 4GB GPUオフロード あり なし/CPU中心 GPU Layer 22/37 なし CUDA0 model buffer 約1.5GB なし KV cache GPU + CPU CPU コンテキスト 8192 4096 動作 GPU/CPU混在 CPU中心 CUDA 正常 モデルサイズ上の制約
この比較から、非常に重要なことが分かります。
同じOllama、同じPC、同じGPUでも、モデルによってGPUの使われ方は変わります。
20. 「GPUが使えない」のではなく「GPUに載せられない」場合がある これは今回の記事で最も伝えたいポイントです。
「OllamaでGPUが使われない」
という問題を見つけたとき、
CUDAが壊れているNVIDIAドライバがおかしいOllamaがCPU版 と考えがちです。
しかし実際には、
GPUは正常↓CUDAも正常↓OllamaもGPUを使える↓ただしモデルが大きすぎる↓GPUに載せられない↓CPU中心で動く というケースがあります。
今回のQwen3:8Bがまさにこれに近い状況でした。
21. さらに重要なのは「Ollama」と「llama.cpp」の関係 Ollamaは単独ですべてのLLM処理を実装しているわけではありません。
今回のログに登場した、
llama-server は、Ollamaがモデル実行に利用している推論ランナーの重要な構成要素です。
そのため、
Ollama ↓runner ↓llama-server ↓llama.cpp / ggml ↓CUDA ↓NVIDIA GPU という関係を意識すると、トラブルシューティングがかなり分かりやすくなります。
llama.cpp側には、
--device--gpu-layers--split-mode--tensor-split--fit など、GPUとCPUへの配置を制御するためのオプションがあります。
つまり、OllamaのGPU問題を調べるときには、
Ollamaだけを見るのではなく、内部で動いているllama.cpp/llama-serverのログを見る
ことが重要です。
22. 4GB VRAM環境では「小さいモデル」が強い 今回の検証から、4GB VRAM環境ではモデル選択そのものが重要だと分かります。
例えば、
1B1.5B3B4B あたりは比較的扱いやすくなります。
一方、
7B8B になると、量子化していてもVRAM 4GBでは厳しくなります。
もちろんCPUとGPUを組み合わせれば動かせるモデルもあります。
しかし、
「動く」と「快適に使える」は別
です。
特にユーザーが目指しているのが、
ローカルだけで完結する自走型の開発環境
であれば、単純に最大モデルを選べばいいわけではありません。
応答速度、安定性、メモリ使用量、コンテキスト長、コード生成能力などを総合的に考える必要があります。
23. 今回の調査で分かったこと 今回の検証結果をまとめると、次のようになります。
① --list-devices が (none) でもGPU使用を即否定しない Available devices: (none) だけでは、Ollama全体のGPU利用状況を判断できません。
② Ollamaの実際のserver.logを見る 今回、
offloaded 22/37 layers to GPU という決定的な証拠がありました。
③ Qwen3:4BはGPUを使えている CUDA0 model buffer = 1515.48 MiB というログからもGPU利用が確認できます。
④ Qwen3:8Bは4GB VRAMでは厳しい モデルサイズが、
4.86 GiB あり、GTX 1050 Tiの4GB VRAMを超えています。
そのためCPU中心の動作になりました。
⑤ GPU使用率だけでは判断できない 一部レイヤーだけGPUへオフロードする構成では、GPU使用率が低くてもGPUは実際に仕事をしています。
⑥ OLLAMA_LIBRARY_PATH をむやみに変更しない GPUが本当に使えていることがログで確認できたなら、環境変数を変更し続けるより、まず現在の構成を把握することが重要です。
24. まとめ――OllamaのGPU問題は「GPUがない」のか「GPUに載らない」のかを分けて考える OllamaでGPUが使われないように見えたとき、最初にやるべきことは、
設定を変更することではありません。
まず、
GPUが認識されているのか↓CUDAが動作しているのか↓OllamaがGPUを使っているのか↓モデルの一部だけGPUに載っているのか↓モデルそのものがVRAMに収まらないのか を一つずつ確認することです。
今回の環境では、最初は、
llama-server.exe --list-devicesAvailable devices: (none) という結果から、
「GPUが使えないのでは？」
と考えました。
ところが、Ollamaのログを調べると、
offloading output layer to GPUoffloading 21 repeating layers to GPUoffloaded 22/37 layers to GPU となっていました。
つまり、
GPUはちゃんと使われていた。
ただし、
Qwen3:4BとQwen3:8Bでは、GPUに載せられる量が違った。
これが今回の調査で得られた最も重要な結論です。
ローカルLLMでは、
「GPUを使っているか？」ではなく、「モデルのどの部分をGPUで処理しているか？」
という視点を持つことが重要です。
特にVRAMが4GB程度の古いGPUでも、モデルサイズや量子化、コンテキストサイズを適切に選べば、OllamaによるローカルLLM環境を十分に構築できます。
そして、GPU問題で困ったときには、タスクマネージャーの数字だけを見るのではなく、
nvidia-smi ollamaps そして、
Get-Content"$env:LOCALAPPDATA\Ollama\server.log"-Tail150 の3つを組み合わせて確認することをおすすめします。
「GPUが使われていない」のか、それとも「GPUには載せられないモデルをCPUで動かしている」のか。
この違いが分かるだけで、OllamaのGPUトラブルシューティングはかなり見通しがよくなります。
