Home / Guides / Troubleshooting / Windows
Windows
Written by Jakub Rusinowski · Last updated September 1, 2026
Founder, LLM Configurator — AI educator & workshop leader on local LLM deployment
NAME ID SIZE PROCESSOR UNTIL
llama3.1:8b 42182419e950 6.7 GB 100% CPU 4 minutes from now| If you see | The cause is | Go to |
|---|---|---|
| Your NVIDIA driver is older than 551.61 | Ollama documents 551.61 as the Windows floor and will not use the GPU below it | Fix 1: update the NVIDIA driver |
ollama ps shows a split, e.g. 40%/60% CPU/GPU | The model is larger than your free VRAM, so some layers spilled to system RAM | Fix 2: size the model to the card — this is normal, not a fault |
CUDA_VISIBLE_DEVICES is set in your user environment | An invalid or stale device ID hides every GPU and forces CPU inference | Fix 3: clear CUDA_VISIBLE_DEVICES |
The debug log lists no CUDA library, only cpu entries | Ollama found no usable CUDA runtime at startup | Fix 4: read the discovery lines in the log |
| Your card is a GTX 745, GT 730 or similar pre-Maxwell part | Compute capability below 5.0 is not supported and never will be | Fix 5: this card cannot be made to work |
There is no error, and that is what makes this one hard. Ollama starts, the model loads, generation works — it is simply ten to thirty times slower than it should be, and Task Manager shows your graphics card at roughly zero percent while every CPU core pegs. Nothing failed, so nothing was reported.
CUDA_VISIBLE_DEVICES and never unset it.Ollama decides where to place each model layer at load time, once, based on what it discovered about your hardware at startup. If it cannot find a usable CUDA runtime it falls back to CPU inference silently, because CPU inference is a valid answer — slow, but valid. Three things make that discovery fail on Windows specifically. Your driver can be below the version Ollama requires: the documented floor is 551.61 on Windows, with driver 570 or newer for cards whose compute capability is between 5.0 and 6.2. The card can be too old outright — compute capability 5.0 is the hard minimum. Or an environment variable can be hiding the GPU from the process before it ever looks. Separately, if the model plus its KV cache is larger than the free VRAM, Ollama places what fits on the card and the rest on the CPU, which shows up as a split rather than 100% CPU.
This is the first thing to check and the most common cause. Ollama's Windows requirements name 551.61 as the minimum, and cards with compute capability 5.0–6.2 (Maxwell and Pascal-era parts such as the GTX 1060) need 570 or newer. Get the driver from NVIDIA's own download page or GeForce Experience, not from Windows Update, which lags badly. Verified against Ollama's GPU and Windows documentation, 1 September 2026.
# PowerShell — what driver do I actually have?
nvidia-smi --query-gpu=name,driver_version --format=csv100% GPU.ollama run llama3.1:8b "hi"
ollama psIf ollama ps shows a split like 35%/65% CPU/GPU rather than a flat 100% CPU, your driver is fine and the model is simply too big for the free VRAM. That is normal behaviour, not a fault — Ollama put what it could on the card. Every layer that spilled to system RAM crosses the PCIe bus on every token, which is why a 10% spill can cost far more than 10% of your speed. The durable fix is a smaller model, a lower quant, or a shorter context, and the arithmetic is worth doing before you download another 20 GB file.
ollama ps should read 100% GPU. If it still splits, you are still over budget.ollama psCUDA_VISIBLE_DEVICES selects which GPUs a process can see. Set it to an ID that does not exist — -1 is the classic — and the process sees no GPU at all and quietly runs on the CPU. People set this once while debugging a multi-GPU box and leave it in their user environment for months. Check it, and remove it from Settings → System → About → Advanced system settings → Environment Variables rather than just unsetting it in one shell, because the Ollama service reads the user environment, not your terminal's.
# PowerShell — is it set at all?
$env:CUDA_VISIBLE_DEVICES
[Environment]::GetEnvironmentVariable("CUDA_VISIBLE_DEVICES", "User")
# Remove it for your user account (the value the Ollama app will read)
[Environment]::SetEnvironmentVariable("CUDA_VISIBLE_DEVICES", $null, "User")[Environment]::GetEnvironmentVariable("CUDA_VISIBLE_DEVICES", "User")When the first three have not explained it, the log will. Ollama writes to %LOCALAPPDATA%\Ollama — server.log plus rotated server-#.log files. With debug logging on it prints the libraries it found, in a line that looks like Dynamic LLM libraries [rocm_v6 cpu cpu_avx cpu_avx2 cuda_v11 rocm_v5]. If no cuda_* entry appears in that list, Ollama never found a CUDA runtime and everything downstream is a consequence of that. Quit the app from the tray first — running the debug command while the tray app is up gives you a second instance fighting for the port.
# PowerShell — quit Ollama from the system tray FIRST, then:
$env:OLLAMA_DEBUG="1"
& "ollama app.exe"
# In another PowerShell window, watch the log:
Get-Content "$env:LOCALAPPDATA\Ollama\server.log" -Tail 50 -Waitcuda_v12 or cuda_v11 entry means CUDA was found; a list containing only cpu* entries confirms it was not.Select-String -Path "$env:LOCALAPPDATA\Ollama\server.log" -Pattern "LLM libraries"Ollama supports NVIDIA GPUs of compute capability 5.0 and above. Below that there is no fix and no driver that helps: Kepler and older parts (GTX 700 series and most GT-branded cards) will not run GPU inference in Ollama, full stop. Better to know that in five minutes than after three driver reinstalls. If your card is below the line, a small model on the CPU is a genuinely usable option — a 1–3B at Q4 is fine for chat on a modern CPU — and it is the honest answer rather than a workaround.
# PowerShell — name the card, then look its compute capability up on
# NVIDIA's CUDA GPUs page
nvidia-smi --query-gpu=name --format=csv,noheaderNone of the above applies if your GPU is a Radeon. Ollama ships a Vulkan backend that is enabled by default on Windows and Linux when the backend is installed, and on Windows most AMD drivers bundle Vulkan support. That path is often what actually works on consumer Radeons, in preference to ROCm. OLLAMA_VULKAN=0 or GGML_VK_VISIBLE_DEVICES=-1 disables it — worth checking neither is set — and GGML_VK_VISIBLE_DEVICES=1 picks the discrete GPU on a machine that also has an integrated one.
# PowerShell — confirm neither Vulkan kill-switch is set for your user
[Environment]::GetEnvironmentVariable("OLLAMA_VULKAN", "User")
[Environment]::GetEnvironmentVariable("GGML_VK_VISIBLE_DEVICES", "User")If the driver is current, no device variable is set, the model fits and the log still shows no CUDA library, the CUDA runtime itself is the problem rather than Ollama's use of it. Two pages narrow that down, and the third is the one to read if you are on a laptop.
Include this when you report it
Dynamic LLM libraries [...] line from %LOCALAPPDATA%\Ollama\server.logollama -v and nvidia-smi --query-gpu=name,driver_version --format=csvollama ps row, including the Processor columnwinver) and whether you are running inside WSL2Because CPU inference is a supported mode, not a failure. Ollama places layers where they fit and runs; there is nothing for it to report. ollama ps is the intended way to see the outcome — the Processor column reads 100% GPU, 100% CPU, or a split between them.
No. It means the model was larger than your free VRAM, so Ollama kept what fit on the card and put the rest in system RAM. It is working as designed. It is also much slower than a full GPU load, so treat it as a signal to drop a quant level or shorten the context.
Ollama documents 551.61 or newer for Windows. Cards with compute capability between 5.0 and 6.2 need driver 570 or newer. The general minimum across platforms is 550. Anything below the relevant floor means CPU inference regardless of how good the card is.
Quit Ollama from the system tray and reopen it — the app reads its environment and re-runs GPU discovery only at start, so a driver installed under a running app is not picked up. If it is still on the CPU after a clean restart, check CUDA_VISIBLE_DEVICES and then the debug log.
Yes, substantially. WSL2 has its own driver plumbing and does not use the Windows CUDA path directly. If nvidia-smi works in PowerShell but not inside your distro, the WSL page is the one you want rather than this one.