はじめに――「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トラブルシューティングはかなり見通しがよくなります。

対処手順

1. Ollama 環境変数の設定（CUDAの明示）

OllamaがNVIDIA GPUを正しく初期化できるように環境変数を指定して再起動します。

PowerShellで以下を実行してください：

PowerShell

# 1. 常駐プロセスを完全終了
Stop-Process -Name "ollama*" -Force -ErrorAction SilentlyContinue

# 2. NVIDIA GPU（0番）の使用を明示
$env:CUDA_VISIBLE_DEVICES="0"

# 3. 再度モデルを実行
ollama run qwen3:8b

2. Windowsのグラフィック設定（iGPUへの自動割当対策）

CPUに内蔵グラフィックス（Intel UHD / AMD Radeon Graphics）があるPCの場合、WindowsがOllamaを「省電力（CPU/iGPU）」で動作させてしまうケースがあります。

Windowsの「設定」 ＞ 「システム」 ＞ 「ディスプレイ」 ＞ 「グラフィックス」 を開く。
アプリ一覧から Ollama を探す（ない場合は「参照」から C:\Users\<ユーザー名>\AppData\Local\Programs\Ollama\ollama app.exe を追加）。
オプションを開き、「高パフォーマンス」（GeForce RTX 3080） に指定して保存する。

3. NVIDIAコントロールパネルの設定

デスクトップを右クリック＞ NVIDIA コントロールパネル を開く。
「3D 設定の管理」 ＞ 「プログラム設定」 タブを開く。
追加ボタンで ollama.exe および ollama app.exe を選択。
優先するグラフィックスプロセッサを 「高パフォーマンス NVIDIA プロセッサ」 に変更して適用。

1. システム環境変数に `CUDA_VISIBLE_DEVICES` を永久追加する

PowerShellの一時的な環境変数ではなく、Windows全体の環境変数として登録してOllamaサービスに強制認識させます。

キーボードの Win + R を押し、sysdm.cpl と入力して Enter。
「詳細設定」タブ＞ 「環境変数」 をクリック。
「システム環境変数」の 「新規」 をクリック。
- 変数名: CUDA_VISIBLE_DEVICES
- 変数値: 0
OKを押して設定を閉じます。

2. Ollama サービスの初期化（インストーラーによる修復）

Ollamaの内部コンポーネント（CUDA用DLL等）の配置がおかしくなっている可能性があります。

タスクマネージャーで Ollama を完全に終了します。
Ollama公式サイトから最新の OllamaSetup.exe をダウンロードして、上書きインストールを実行します。 (※ダウンロードしたモデルデータ qwen3:8b などは削除されませんのでご安心ください)

3. 明示的に GPU モードでデバッグ実行してログを確認

原因を特定するため、サービスではなく直接サーバーを起動してCUDA初期化エラーを出力させます。

PowerShell（管理者）で以下を実行してください：

PowerShell

# 1. 常駐中のOllamaを完全に強制終了
Stop-Process -Name "ollama*" -Force -ErrorAction SilentlyContinue

# 2. CUDAの検出ログを画面に出力させながら起動
$env:OLLAMA_DEBUG="1"
$env:CUDA_VISIBLE_DEVICES="0"
ollama serve

この状態で、起動ログの最初の数行に以下のようなエラーが出ていないか確認してください：

unable to load CUDA library
no compatible GPUs found
pci / nvml 関連のエラー

まずは 1（環境変数追加） と 2（上書き再インストール） を試したあと、一度PCを再起動して ollama run qwen3:8b を実行してみてください。

これが原因　グラフィックドライバーとDLLの互換

+—————————————————————————————–+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=========================================================================================|
| 0 N/A N/A 2576 C+G ….0.4129.93\msedgewebview2.exe N/A |
| 0 N/A N/A 5668 C+G …8bbwe\PhoneExperienceHost.exe N/A |
| 0 N/A N/A 9332 C …a\lib\ollama\llama-server.exe N/A |
| 0 N/A N/A 9812 C+G …y\StartMenuExperienceHost.exe N/A |
| 0 N/A N/A 9864 C+G …_cw5n1h2txyewy\SearchHost.exe N/A |
| 0 N/A N/A 10400 C+G C:\Windows\explorer.exe N/A |
| 0 N/A N/A 10440 C+G …indows\System32\ShellHost.exe N/A |
| 0 N/A N/A 10608 C+G …2txyewy\CrossDeviceResume.exe N/A |
| 0 N/A N/A 12320 C+G …yb3d8bbwe\WindowsTerminal.exe N/A |
| 0 N/A N/A 15528 C+G …5n1h2txyewy\TextInputHost.exe N/A |
| 0 N/A N/A 16500 C+G ….0.4129.93\msedgewebview2.exe N/A |
+—————————————————————————————–+
PS D:\model\llm>

：NVIDIA公式サイトで確認

https://www.nvidia.com/Download/index.aspx にアクセス
製品シリーズ「GeForce」→「GeForce RTX 30 Series」→「GeForce RTX 3080」を選択
オペレーティングシステムを選んで検索
表示される最新ドライバーの種類（Game Ready / Studio）と比較

上のように適用して、再起動すると完了 GPUを使うようになりました

> ollama ps
NAME        ID              SIZE      PROCESSOR    CONTEXT    UNTIL
qwen3:8b    500a1f067a9f    5.6 GB    100% GPU     4096       4 minutes from now

> ollama ps
NAME           ID              SIZE     PROCESSOR          CONTEXT    UNTIL
gpt-oss:20b    17052f91a42e    14 GB    41%/59% CPU/GPU    4096       4 minutes from now

ローカルLLMと貧弱なPCで自走コーディングを試行してみた ― qwen3:4b＋Cline 検証記録

Ollama 各モデルを実機比較｜Qwen・Llama・Gemmaの応答速度を古いPC(GTX1050 Ti)で検証

ローカルLLMは、ここまで来た、2026年夏版

2026年8月
日	月	火	水	木	金	土
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31

1. 今回の環境

2. 最初の疑問：「llama-serverにGPUがない？」

3. 決定的だったのはOllamaのserver.log

4. 「GPU使用率が低い」＝「GPUを使っていない」ではない

5. Qwen3:4BではGPUが実際に使われていた

6. では、なぜQwen3:8BではGPUを使わなかったのか？

7. Qwen3:8BはCPU動作になった

8. 「モデルサイズ4.86GiB」なのに4GBなら、なぜ一部GPUに載せないのか？

9. --list-devices の (none) はどう考えるべきか？

10. 一番信頼できるのは「実際のロードログ」

11. nvidia-smi も必ず使いたい

12. ollama ps も確認する

13. OLLAMA_LIBRARY_PATH を変更すればGPUが使える？

14. 「GPUを使わせるための設定変更」が逆効果になることもある

15. コンテキストサイズもVRAMを消費する

16. だから「GPUが使われない」ときの調査順序が重要

STEP 1：GPUそのものを確認

STEP 2：Ollamaのバージョンを確認

STEP 3：モデルをロードする

STEP 4：ollama ps

STEP 5：nvidia-smi

STEP 6：server.log

17. ログからGPU使用を判断するキーワード

GPU動作を示す可能性が高いもの

18. 「GPUを使う」には段階がある

レベル1：完全CPU

レベル2：一部GPU

レベル3：ほぼGPU

レベル4：完全GPU

19. 今回の検証結果を表にすると

20. 「GPUが使えない」のではなく「GPUに載せられない」場合がある

21. さらに重要なのは「Ollama」と「llama.cpp」の関係

22. 4GB VRAM環境では「小さいモデル」が強い

23. 今回の調査で分かったこと

① --list-devices が (none) でもGPU使用を即否定しない

② Ollamaの実際のserver.logを見る

③ Qwen3:4BはGPUを使えている

④ Qwen3:8Bは4GB VRAMでは厳しい

⑤ GPU使用率だけでは判断できない

⑥ OLLAMA_LIBRARY_PATH をむやみに変更しない

24. まとめ――OllamaのGPU問題は「GPUがない」のか「GPUに載らない」のかを分けて考える

対処手順

1. Ollama 環境変数の設定（CUDAの明示）

2. Windowsのグラフィック設定（iGPUへの自動割当対策）

3. NVIDIAコントロールパネルの設定

1. システム環境変数に CUDA_VISIBLE_DEVICES を永久追加する

2. Ollama サービスの初期化（インストーラーによる修復）

3. 明示的に GPU モードでデバッグ実行してログを確認

これが原因 グラフィックドライバーとDLLの互換

9. `--list-devices` の `(none)` はどう考えるべきか？

11. `nvidia-smi` も必ず使いたい

12. `ollama ps` も確認する

13. `OLLAMA_LIBRARY_PATH` を変更すればGPUが使える？

STEP 4：`ollama ps`

STEP 5：`nvidia-smi`

① `--list-devices` が `(none)` でもGPU使用を即否定しない

⑥ `OLLAMA_LIBRARY_PATH` をむやみに変更しない

1. システム環境変数に `CUDA_VISIBLE_DEVICES` を永久追加する

これが原因　グラフィックドライバーとDLLの互換