はじめに――「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系モデルを中心に動作確認を行ってきました。
特に今回比較したのは、
- Qwen3:4B
- Qwen3:8B
です。
ここで重要なのは、「モデルの大きさ」と「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)
↓
OllamaもGPUを使っていない
とは限りません。
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を使わせたい
↓
GPU layerを最大にする
↓
VRAM不足
↓
起動失敗・クラッシュ
ということもあります。
特に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トラブルシューティングはかなり見通しがよくなります。
