Ollama not using your GPU? How to check it and fix it

When Ollama is not using your GPU, nothing breaks: the model still answers, only far more slowly, with the CPU at full load and the graphics card idle. Ollama falls back to the CPU on its own when it cannot find a supported GPU or when the model does not fit in video memory, and it does not stop to tell you. This guide shows how to confirm what Ollama is really using, then walks through the causes in the order we would check them, with the exact commands and settings from Ollama's documentation as of October 9, 2026, for Windows, Linux, Docker and Mac.

Step 1: check what Ollama is using with ollama ps

Load a model by sending it a prompt, then run:

ollama ps

The PROCESSOR column tells you where the model sits. Ollama's FAQ defines the three possible readings:

• 100% GPU: the whole model is in video memory. This is what you want.
• 100% CPU: the model is entirely in system memory. Ollama found no usable GPU, or something is forcing the CPU.
• A split, such as 48%/52% CPU/GPU: the GPU works, but the model and its context did not fit, so part of it runs on the CPU. Ollama's own advice for performance is to avoid this CPU offloading.

The same output has a CONTEXT column with the context length that was allocated. Keep it in mind: it is often the reason for a split. If you need a refresher on the other commands, see our Ollama commands cheat sheet.

Step 2: if you see a CPU/GPU split, the model does not fit

A split is the most common case and it is not a driver problem. Video memory has to hold the model weights and the working memory for the conversation (the KV cache), which grows with the context length. Ollama's documentation says a larger context "will increase the amount of memory required to run a model", and its FAQ adds that the memory needed scales with the number of parallel requests times the context length.

Ollama picks a default context from your video memory: 4k tokens below 24 GiB of VRAM, 32k between 24 and 48 GiB, and 256k from 48 GiB. If you raised it (for example to the 64,000 tokens Ollama suggests for coding tools and agents) on a card with little memory, the model will spill onto the CPU. Fixes, from the cheapest:

1. Lower the context length in the app's settings slider, or start the server with OLLAMA_CONTEXT_LENGTH set to a smaller value.
2. Use a smaller variant of the model, either fewer parameters or a stronger quantization (a smaller tag of the same model). Our explainer on quantization shows what you trade.
3. Quantize the KV cache. OLLAMA_KV_CACHE_TYPE sets its precision; the default is f16, and the setting applies to every model on the server.
4. Check what else is using the GPU. Games, browsers and other models take video memory too. By default Ollama keeps a model loaded for 5 minutes after its last use.

To know before you download whether a model fits, use our VRAM calculator, which counts the weights and the KV cache for each context length.

Step 3: check that your GPU and driver are supported

If ollama ps says 100% CPU, start with the hardware list. Ollama's GPU page sets these requirements:

Table: GPU support in Ollama (documentation checked October 9, 2026)

Two cases deserve a closer look:

• An older NVIDIA card. A driver older than 550 (or 570 for the oldest supported cards) is enough to drop to the CPU. Update the driver from NVIDIA and restart Ollama.
• An AMD card that is not on the list (Linux). Ollama documents HSA_OVERRIDE_GFX_VERSION to make ROCm treat the card as a close supported target. Its example is a Radeon RX 5400 (gfx1034) with the value 10.3.0. This works only for close relatives of a supported chip, so treat it as an experiment.

If you are still choosing hardware, our guide to the best GPU for local LLMs shows which models fit in 8, 12, 16, 24 and 32 GB of video memory.

Step 4: read the server log

The log says why Ollama ignored the GPU. Where to find it, according to Ollama's troubleshooting page:

• Windows: %LOCALAPPDATA%\Ollama\server.log (older logs are server-1.log and so on).
• Linux: journalctl -u ollama --no-pager --follow --pager-end
• macOS: cat ~/.ollama/logs/server.log
• Docker: docker logs <container-name>

For more detail, restart Ollama with the debug variable set. On Windows, quit Ollama from the tray icon first, then run in PowerShell:

$env:OLLAMA_DEBUG="1"
& "ollama app.exe"

On NVIDIA, Ollama lists the GPU discovery error codes it reports: 3 (not initialized), 46 (device unavailable), 100 (no device) and 999 (unknown). Setting CUDA_ERROR_LEVEL=50 adds more diagnostic output.

Step 5: platform fixes

Windows. Update the graphics driver and restart the computer. Ollama inherits your user and system environment variables, so quit it from the tray before you change one, then start it again. Look for a leftover CUDA_VISIBLE_DEVICES or OLLAMA_VULKAN variable from an old tutorial (see step 6).

Linux with NVIDIA. Ollama notes that after a suspend and resume it sometimes fails to find the GPU. Reload the driver module:

sudo rmmod nvidia_uvm && sudo modprobe nvidia_uvm

sudo nvidia-modprobe -u loads it if it is missing, and sudo dmesg | grep -i nvrm shows driver errors. A reboot with the latest NVIDIA driver fixes most remaining cases. To set an environment variable for the service, run systemctl edit ollama.service, add an Environment= line under [Service], reload systemd and restart Ollama.

Linux with AMD. Access to /dev/kfd usually needs the video or render group. If the log says "failed to finish discovery before timeout", Ollama says the AMD driver is probably older than ROCm 7: upgrade it with amdgpu-install, reboot and restart Ollama.

Docker. A container sees no GPU unless you pass it in. For NVIDIA, install the NVIDIA Container Toolkit, check it with docker run --gpus all ubuntu nvidia-smi, and start Ollama with:

docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

For AMD, use the ROCm image and pass the devices: docker run -d --device /dev/kfd --device /dev/dri -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama:rocm. If the GPU works at first and later falls back to the CPU with discovery errors, Ollama's fix is to add "exec-opts": ["native.cgroupdriver=cgroupfs"] to /etc/docker/daemon.json on the host. On SELinux systems, sudo setsebool container_use_devices=1 lets containers reach AMD devices.

Mac. Ollama uses the GPU of Apple devices through Metal. A split on a Mac almost always means the model and context are too big for the memory available (step 2).

Step 6: make sure nothing is forcing the CPU

Ollama documents several variables that deliberately switch the GPU off. Any of them, left over from a test or a guide, produces 100% CPU:

• CUDA_VISIBLE_DEVICES set to an invalid ID such as -1 (NVIDIA)
• ROCR_VISIBLE_DEVICES set to an invalid ID such as -1 (AMD)
• OLLAMA_VULKAN=0 or GGML_VK_VISIBLE_DEVICES=-1 (Vulkan)
• OLLAMA_LLM_LIBRARY set to a CPU library such as cpu_avx2

On a laptop with both integrated and dedicated graphics, Ollama suggests pointing GGML_VK_VISIBLE_DEVICES at the dedicated GPU (for example 1) if the integrated one is unstable. With several NVIDIA cards, nvidia-smi -L lists their UUIDs, which are more reliable than numbers in CUDA_VISIBLE_DEVICES.

Table: symptom, likely cause and first fix

If none of this helps, save the debug log from step 4 and the output of ollama ps: you will need both to report the problem on Ollama's GitHub. And if Ollama keeps fighting your hardware, LM Studio is the main alternative; our guide to running an LLM locally covers both.