Ollama nie używa GPU? Napraw to na Linuksie, Windows i WSL

TL;DR

Odpal ollama ps, gdy model jest załadowany: kolumna PROCESSOR mówi prawdę. 100% GPU — GPU działa, możesz przestać czytać. Podział typu 40%/60% CPU/GPU — model nie zmieścił się w VRAM, weź mniejszy quant. 100% CPU — Ollama nie znalazła używalnego GPU: zwykle stary sterownik, brak przynależności do grupy (AMD na Linuksie), przypięte OLLAMA_LLM_LIBRARY albo kontener odpalony bez dostępu do GPU. Napraw przyczynę, którą nazwą logi; jest ich tylko około pięć.

Jak sprawdzić, czy Ollama naprawdę używa GPU?

Dwie komendy, zero zgadywania.

# W jednym terminalu: załaduj model
ollama run llama3.2 "hello"

# W drugim: zobacz, gdzie działa
ollama ps

NAME            ID          SIZE     PROCESSOR        UNTIL
llama3.2:latest a80c4de17cd9 3.3 GB   100% GPU         4 minutes from now

Kolumna PROCESSOR ma trzy stany:

• 100% GPU — wszystkie warstwy zrzucone na kartę. Koniec.
• 48%/52% CPU/GPU — zrzut częściowy. GPU pracuje, ale model plus kontekst nie zmieściły się w VRAM. Patrz sekcja o VRAM niżej.
• 100% CPU — inferencja siedzi na CPU. GPU albo nie zostało wykryte, albo zostało celowo wyłączone.

Potem przeczytaj log serwera, który wypisuje sprzęt, jaki Ollama faktycznie znalazła na starcie:

journalctl -u ollama --no-pager | grep -i "inference compute"

Na zdrowej maszynie z NVIDIA chcesz zobaczyć linię w stylu:

inference compute id=GPU-xxxx library=CUDA compute=8.9 driver=12.4 name=NVIDIA GeForce RTX 4070

Brak linii w ogóle albo linia kończąca się komunikatem o fallbacku na CPU — i masz znaleziony problem. Reszta posta to pięć przyczyn, od najbardziej prawdopodobnej.

Dlaczego Ollama mówi „no compatible GPU discovered”?

Przy NVIDIA zwykłym winowajcą jest sterownik, nie CUDA. Ollama dowozi własne biblioteki runtime CUDA, więc nie potrzebujesz zainstalowanego CUDA toolkit — ale dołączony runtime potrzebuje sterownika na tyle nowego, żeby się z nim dogadać. Działające nvidia-smi to nie dowód; dowodzi tylko, że sterownik istnieje, nie że jest wystarczająco świeży.

nvidia-smi --query-gpu=driver_version --format=csv,noheader

Jeśli wersja ma lata, zaktualizuj ją i zrób reboot:

# Rodzina Debian/Ubuntu
sudo apt install nvidia-driver-570
# Rodzina Arch
sudo pacman -S nvidia

Po aktualizacji sterownika zrestartuj usługę Ollama, żeby ponownie wykryła urządzenia — detekcja dzieje się raz, przy starcie, nie przy każdym zapytaniu:

sudo systemctl restart ollama

Jeśli log wypisuje teraz twoje GPU z library=CUDA, jesteś w domu. Jeśli dalej odmawia, sprawdź, czy OLLAMA_LLM_LIBRARY nie ustawia się gdzieś — patrz sekcja „po aktualizacji”.

Dlaczego Ollama używa GPU tylko dla części modelu?

Częściowy zrzut to arytmetyka, nie bug: wagi modelu plus cache KV dla twojego okna kontekstu muszą zmieścić się w VRAM. Model 7B w Q4 to w przybliżeniu 4–5 GB; daj mu kontekst 8K, a cache dorzuci swoje. Na karcie 8 GB coś musi zostać na CPU, a ollama ps pokazuje podział.

Trzy sposoby na domknięcie luki, od najtańszego:

1. Mniejszy quant. Zejście z Q8 na Q4 tnie rozmiar wag o połowę za umiarkowany koszt jakości. Kompromisy rozpisane są w GGUF quantization levels explained.
2. Krótszy kontekst. num_ctx dominuje rozmiar cache’a. Kontekst 32K na karcie 8 GB oznacza, że większość warstw zostaje na CPU.
3. Mniej warstw na GPU. Opcja num_gpu ogranicza, ile warstw dostaje zrzucone. Ustawienie jej poniżej liczby warstw gwarantuje podział — jeśli ktoś ustawił ją w Modelfile albo wywołaniu API, usuń to.

Zwróć też uwagę na odwrotną pułapkę: GPU pokazujące 100% GPU, które działa wolniej, niż byś oczekiwał, może wymieniać dane przez systemowy RAM. Porównaj SIZE z ollama ps ze swoją realną VRAM.

Dlaczego Ollama nie używa mojego GPU od AMD?

AMD na Linuksie potrzebuje trzech rzeczy i wszystkie trzy da się sprawdzić:

1. Obsługa ROCm w buildzie. Oficjalny skrypt instalacyjny Linuksa dowozi build z ROCm. Potwierdź, co wykrył serwer:

journalctl -u ollama --no-pager | grep -iE "rocm|inference compute"

2. Przynależność do grup. Runtime ROCm potrzebuje dostępu do /dev/kfd i /dev/dri, czyli grup render i video:

sudo usermod -aG render,video $USER
# wyloguj się i zaloguj ponownie, potem:
sudo systemctl restart ollama

Ta jedna brakująca grupa to najczęstszy post typu „Ollama nie używa GPU na Ubuntu” na każdym forum — i przeżywa reinstalacje sterownika, bo sterownik nigdy nie był problemem.

3. Obsługiwane GPU — albo obejście. Nieobsługiwane konsumenckie karty RDNA2 (gfx1031, gfx1032) oblewają detekcję, mimo że stos ROCm działa. Standardowe obejście to udawanie zgodnego celu:

sudo systemctl edit ollama

[Service]
Environment="HSA_OVERRIDE_GFX_VERSION=10.3.0"

Potem sudo systemctl restart ollama. To obejście nieoficjalne, ale szeroko używane; jak zacznie płatać figle, usuń je i wracasz na teren oficjalnego wsparcia. Jeśli wolisz pełną kontrolę nad backendami zamiast walki z autodetekcją, to jest ta zasadnicza różnica z llama.cpp vs Ollama.

Na Windows wsparcie AMD jest węższe — zajrzyj na listę obsługiwanych GPU Ollamy, zanim uznasz, że instalacja jest zepsuta.

Dlaczego Ollama przestała używać GPU po aktualizacji?

Aktualizacje zmieniają jedną z trzech rzeczy, w tej kolejności prawdopodobieństwa:

1. Przypięta biblioteka backendu. OLLAMA_LLM_LIBRARY wymusza konkretny runner (cuda_v11, rocm, a nawet cpu). Jest do debugowania, po cichu nadpisuje autodetekcję i wytrzymuje w profilach shella oraz plikach usług długo po tym, jak zapomina się, po co ją ustawiono. Znajdź i usuń:

systemctl show ollama --property=Environment | grep -i llm_library
env | grep OLLAMA

2. Sterownik został w tle za runtime’em. Upgrade Ollamy dowozi nowszy runtime CUDA; twój sterownik nie rusza się, dopóki sam go nie ruszysz. Naprawa jak w sekcji o sterowniku wyżej.
3. Usługa to kontener i flagi zginęły. Odtworzony kontener bez flag GPU to kontener wyłącznie na CPU. Wywołanie dla NVIDIA:

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

Dla kontenerów AMD odpowiednikiem jest przepuszczenie urządzeń plus dodanie grup:

docker run -d --device=/dev/kfd --device=/dev/dri 
  --group-add video --group-add render 
  -v ollama:/root/.ollama -p 11434:11434 ollama/ollama

Brak --gpus=all, brak GPU — Docker nie ma powodu być hojny.

Czy Ollama działa w WSL2?

Tak, z właściwym sterownikiem we właściwym miejscu: zainstaluj sterownik NVIDIA dla Windows, nigdy sterownik linuksowy wewnątrz dystrybucji — sterownik w WSL psuje passthrough CUDA, zamiast go naprawiać. Potem zaktualizuj samo WSL i potwierdź, że urządzenie passthrough istnieje:

wsl --update   # z poziomu PowerShell
ls /dev/dxg    # wewnątrz WSL — musi istnieć, żeby użyć GPU

Z obecnym /dev/dxg i aktualnym sterownikiem Windows Ollama w WSL2 zrzuca obliczenia na GPU jak natywna instalacja. Jeśli wolisz pominąć pośrednictwo w całości, build Windowsowy Ollamy działa natywnie i widzi GPU bez WSL.

Czy Ollama w ogóle potrzebuje GPU?

Nie — run wyłącznie na CPU jest funkcjonalnie identyczny, tylko wolniejszy, a dla małych modeli na szybkim CPU bywa całkowicie używalny. Na Apple Silicon pytanie się rozpuszcza: Metal korzysta z ujednoliconej pamięci automatycznie, a jedynym limitem jest to, ile RAMu jesteś gotów oddać modelowi.

Checklista na pięć minut

Objaw	Prawdopodobna przyczyna	Naprawa
100% CPU w ollama ps, karta NVIDIA obecna	Sterownik za stary na dołączoną CUDA	Aktualizacja sterownika, reboot, restart usługi
100% CPU, AMD na Linuksie	Brak grupy render/video	usermod -aG render,video, ponowne logowanie
100% CPU, nieobsługiwana karta AMD	ROCm odrzuca cel gfx	HSA_OVERRIDE_GFX_VERSION=10.3.0
Podział 40%/60% CPU/GPU	Model + kontekst przekraczają VRAM	Mniejszy quant albo krótszy num_ctx
Wczoraj GPU, dziś CPU	Przypięte OLLAMA_LLM_LIBRARY albo stary sterownik	Znajdź i usuń zmienną; zaktualizuj sterownik
GPU natywnie, CPU w Dockerze	Kontener odpalony bez flag GPU	Odtwórz z --gpus=all (lub urządzeniami AMD)

Sprawdzaj w tej kolejności: ollama ps dla stanu, logi serwera dla listy detekcji, potem tabela. W dziewięciu na dziesięć przypadków linia logu już ci powiedziała, w którym wierszu jesteś.