很多人安裝 Ollama 後第一個卡點不是「模型怎麼選」，而是：到底有沒有跑到 GPU？
這個問題在 Windows 特別常見。因為你可能同時有 Windows 原生版、Docker Desktop、WSL2、NVIDIA 驅動、AMD 驅動、工作管理員、PowerShell、VS Code 外掛，任何一層設定錯，Ollama 都可能退回 CPU 推論。
如果只想快速判斷，先記住這句：
跑模型後用 ollama ps 看處理器欄位；NVIDIA 使用者再開 nvidia-smi，確認有 ollama 或相關 runner 進程。
只看 Windows 工作管理員不夠，因為 LLM 推論可能吃 CUDA、Compute、VRAM，不一定會明顯出現在你習慣看的 3D GPU 圖表裡。
先確認你的安裝方式
Windows 上常見有三種 Ollama 路線。
| 路線 | 適合誰 | GPU 注意事項 |
|---|---|---|
| Windows 原生安裝 | 大多數使用者 | 安裝後背景服務自動啟動，官方支援 NVIDIA 與 AMD Radeon |
| Docker Desktop | 想搭 Open WebUI、服務化部署 | 要讓容器取得 GPU，NVIDIA 需要 container toolkit |
| WSL2 | 開發者、Linux 工作流 | Windows 驅動與 WSL2 內部環境都要正確 |
如果只是個人使用，優先用 Windows 原生安裝。Docker 與 WSL2 比較適合你已經知道自己為什麼需要它。
Windows 原生版：最短檢查流程
１、安裝與更新驅動
到 Ollama 官網安裝 Windows 版。官方文件列出的基本條件是 Windows １０ ２２Ｈ２ 或更新版本；NVIDIA 使用者需要 ４５２.３９ 或更新驅動，AMD Radeon 使用者則要安裝 AMD 官方驅動。
安裝完後打開 PowerShell：
ollama --version接著先跑一個小模型：
ollama run llama3.2第一次會下載模型，下載完才會開始推論。
２、用 ollama ps 確認處理器
模型正在跑時，另開一個 PowerShell：
ollama ps你要看的是模型是否顯示正在使用 GPU 或部分層數跑在 GPU。不同版本顯示格式可能略有差異，但重點是不要只看模型有沒有啟動，要看它實際使用的處理器與載入狀態。
３、NVIDIA 用 nvidia-smi 交叉確認
NVIDIA 使用者再跑：
nvidia-smi如果 Ollama 正在用 CUDA，通常會看到相關進程與顯存占用。這比工作管理員可靠。
常見問題一：為什麼有顯卡還是跑 CPU？
最常見原因有四個。
一、驅動太舊
先更新 NVIDIA 或 AMD 官方驅動。Windows Update 自動裝的驅動有時能顯示畫面，但不一定適合本地 LLM 推論。
NVIDIA 使用者至少先確認：
nvidia-smi如果這個指令不存在或報錯，Ollama 看不到 GPU 很正常。
二、模型超過顯存
本地 LLM 的關鍵不是「我有沒有 GPU」，而是模型加上 KV cache 能不能放進 VRAM。
簡單估算：
| 顯存 | 建議模型 |
|---|---|
| ６GB 以下 | １B 到 ３B 小模型 |
| ８GB | ７B／８B Q4 量化模型 |
| １２GB | ８B Q5 或部分 １４B Q4 |
| １６GB | １４B Q4 較舒服 |
| ２４GB 以上 | 可嘗試 ３０B 或更大模型 |
如果模型放不進顯存，系統會把部分工作丟回 CPU 或系統記憶體，速度會突然掉很多。
三、context window 開太大
同一個模型，context 越大，KV cache 越吃顯存。你可能 ４Ｋ context 跑得很快，拉到 １６Ｋ 後突然變慢。
Ollama 可用環境變數調整 context：
$env:OLLAMA_CONTEXT_LENGTH="4096"需要長文時再提高，不要預設就開很大。
四、你其實跑在 Docker 或 WSL2 裡
Windows 主機看得到 GPU，不代表 Docker 容器或 WSL2 也看得到。這是很多人誤判的來源。
Docker Desktop：要讓容器看得到 GPU
如果你用 Docker 跑 Ollama 或 Open WebUI，NVIDIA GPU 需要讓容器取得顯卡。
典型檢查：
docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi如果這個都看不到 GPU，Ollama 容器也不會看到。
跑 Ollama 容器時要加：
docker run -d --gpus all -p 11434:11434 --name ollama ollama/ollama再進容器或透過 API 跑模型，觀察主機 nvidia-smi 的顯存變化。
WSL2：適合開發者，但不要一開始就選
WSL2 的好處是 Linux 工具鏈完整，適合搭 Python、LangChain、向量資料庫或自動化 pipeline。
但對新手來說，WSL2 增加了除錯層數：
- Windows NVIDIA 驅動要正確。
- WSL2 內要能看到
nvidia-smi。 - Ollama 安裝在 Windows 還是 WSL2 要分清楚。
- VS Code 外掛連的是哪一個 Ollama 服務也要確認。
如果你只是要本地聊天或接 Open WebUI，Windows 原生版通常比較省事。
實用排查清單
照這個順序查，通常能抓到問題。
１、確認 Ollama 版本：
ollama --version２、確認模型正在跑：
ollama run llama3.2３、另開 PowerShell 看載入狀態：
ollama ps４、NVIDIA 使用者看顯存：
nvidia-smi５、如果速度很慢，換小模型：
ollama run qwen2.5:3b６、如果小模型正常、大模型很慢，多半是顯存不足，不是 Ollama 壞掉。
該用哪個模型測試 GPU？
第一次測試不要直接拉 ７０B。先用小模型確認 GPU pipeline 正常。
| 測試目的 | 建議模型 |
|---|---|
| 確認能跑 | llama3.2 或 ３B 等級模型 |
| 測 Windows GPU 是否正常 | ７B／８B Q4 模型 |
| 測寫程式 | Qwen Coder 或 DeepSeek Coder 小型版本 |
| 測中文 | Qwen 系列通常比純英文模型穩 |
如果你只是要確認「有沒有吃 GPU」，小模型就夠；要測顯存壓力，再逐步拉大。
Mason 的判斷
Ollama 在 Windows 上已經比兩年前成熟很多，真正麻煩的不是安裝，而是使用者不知道自己跑在哪一層：Windows 原生、Docker、WSL2、Open WebUI、VS Code 外掛，各自都可能連到不同的 Ollama 服務。
最穩的學習順序是：先 Windows 原生跑通，再加 Open WebUI，最後才碰 Docker 或 WSL2。
如果你的目標是隱私、本地文件整理、簡單 RAG，８GB 到 １２GB 顯存已經能做很多事。若你的目標是長上下文、多代理、複雜寫程式，本地模型仍然比較吃力，應該把 Ollama 當雲端模型的補充，而不是完全替代。