Ollama nutzt die GPU nicht? Fixes für Linux und WSL

TL;DR

ollama ps ausführen, während ein Modell geladen ist: Die Spalte PROCESSOR verrät die Wahrheit. 100% GPU heißt, die GPU ist in Ordnung, und du kannst hier aufhören zu lesen. Etwas wie 40%/60% CPU/GPU heißt, das Modell passte nicht in den VRAM — nimm eine kleinere Quantisierung. 100% CPU heißt, Ollama hat keine nutzbare GPU gefunden: meist ein veralteter Treiber, eine fehlende Gruppenmitgliedschaft (AMD unter Linux), eine gepinnte OLLAMA_LLM_LIBRARY oder ein Container, der ohne GPU-Zugang gestartet wurde. Behebe die Ursache, die die Logs benennen; es sind nur etwa fünf.

Wie prüfe ich, ob Ollama wirklich die GPU nutzt?

Zwei Befehle, kein Rätselraten.

# In einem Terminal: Modell laden
ollama run llama3.2 "hello"

# In einem anderen: sehen, wo es läuft
ollama ps

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

Die Spalte PROCESSOR kennt drei Zustände:

• 100% GPU — alle Layer sind auf die GPU ausgelagert. Fertig.
• 48%/52% CPU/GPU — teilweise ausgelagert. Die GPU arbeitet, aber Modell plus Kontext passten nicht in den VRAM. Siehe unten den VRAM-Abschnitt.
• 100% CPU — die Inferenz läuft auf der CPU. Die GPU wurde entweder nicht erkannt oder bewusst deaktiviert.

Dann das Server-Log lesen — es benennt die Hardware, die Ollama beim Start tatsächlich gefunden hat:

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

Auf einer gesunden NVIDIA-Kiste willst du eine Zeile sehen wie:

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

Gar keine Zeile, oder eine, die in eine CPU-only-Fallback-Meldung mündet — dann hast du dein Problem gefunden. Der Rest dieses Beitrags sind die fünf Ursachen, sortiert nach Wahrscheinlichkeit.

Warum meldet Ollama „no compatible GPU discovered”?

Bei NVIDIA ist der übliche Täter der Treiber, nicht CUDA. Ollama bringt seine eigenen CUDA-Runtime-Bibliotheken mit, das CUDA-Toolkit muss also nicht installiert sein — aber die mitgelieferte Runtime braucht einen Treiber, der neu genug ist, um mit ihr zu reden. Ein funktionierendes nvidia-smi ist kein Beweis; es beweist nur, dass ein Treiber existiert, nicht dass er neu genug ist.

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

Ist die Version Jahre alt: aktualisieren und neu starten.

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

Nach einem Treiber-Update den Ollama-Dienst neu starten, damit er die Geräte neu erkennt — die Erkennung passiert einmal beim Start, nicht pro Anfrage:

sudo systemctl restart ollama

Druckt das Log deine GPU jetzt mit library=CUDA: fertig. Wenn es sich weiter weigert, prüfe, ob OLLAMA_LLM_LIBRARY irgendwo gesetzt ist — siehe den Abschnitt „nach einem Update”.

Warum nutzt Ollama die GPU nur für einen Teil des Modells?

Partielle Auslagerung ist Arithmetik, kein Bug: Die Modellgewichte plus der KV-Cache für dein Kontextfenster müssen in den VRAM passen. Ein 7B-Modell bei Q4 wiegt grob 4–5 GB; mit 8K Kontext kommt der Cache obendrauf. Auf einer 8-GB-Karte muss etwas auf der CPU bleiben, und ollama ps zeigt die Aufteilung.

Drei Wege, die Lücke zu schließen, nach Kosten sortiert:

1. Kleinere Quantisierung. Der Sprung von Q8 auf Q4 halbiert die Gewichtsgröße bei moderatem Qualitätsverlust. Die Abwägungen stehen in GGUF quantization levels explained.
2. Kürzerer Kontext. num_ctx dominiert die Cache-Größe. 32K Kontext auf einer 8-GB-Karte heißt, die meisten Layer bleiben auf der CPU.
3. Weniger GPU-Layer. Die Option num_gpu deckelt, wie viele Layer ausgelagert werden. Sie unter die Layer-Anzahl zu setzen garantiert eine Aufteilung — hat sie jemand in einem Modelfile oder API-Aufruf gesetzt, entferne sie.

Auch die umgekehrte Falle beachten: Eine GPU, die 100% GPU zeigt, aber langsamer läuft als erwartet, swapt eventuell über den System-RAM. Vergleiche ollama ps SIZE mit deinem tatsächlichen VRAM.

Warum nutzt Ollama nicht meine AMD-GPU?

AMD unter Linux braucht drei Dinge, und alle drei sind prüfbar:

1. ROCm-Unterstützung im Build. Das offizielle Linux-Install-Script bündelt einen ROCm-Build. Bestätige, was der Server erkannt hat:

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

2. Gruppenmitgliedschaft. Die ROCm-Runtime braucht Zugriff auf /dev/kfd und /dev/dri, also die Gruppen render und video:

sudo usermod -aG render,video $USER
# ausloggen und wieder einloggen, dann:
sudo systemctl restart ollama

Diese eine fehlende Gruppe ist der häufigste „Ollama not using GPU on Ubuntu”-Post in jedem Forum — und sie überlebt Treiber-Neuinstallationen, weil der Treiber nie das Problem war.

3. Eine unterstützte GPU — oder ein Override. Nicht unterstützte RDNA2-Consumer-Karten (gfx1031, gfx1032) scheitern an der Erkennung, selbst mit funktionierendem ROCm-Stack. Der gängige Workaround ist, ein kompatibles Ziel vorzutäuschen:

sudo systemctl edit ollama

[Service]
Environment="HSA_OVERRIDE_GFX_VERSION=10.3.0"

Danach sudo systemctl restart ollama. Das ist ein nicht unterstützter, aber weit verbreiteter Override; verhält er sich falsch, entferne ihn, und du bist zurück auf offiziellem Support-Boden. Wer lieber volle Kontrolle über die Backends hat, statt mit der Autoerkennung zu kämpfen: Genau dieser Kernunterschied steckt in llama.cpp vs Ollama.

Unter Windows ist die AMD-Unterstützung enger — wirf einen Blick auf Ollamas Liste der unterstützten GPUs, bevor du die Installation für kaputt erklärst.

Warum nutzt Ollama nach einem Update nicht mehr die GPU?

Updates ändern eines von drei Dingen, in dieser Wahrscheinlichkeitsordnung:

1. Eine gepinnte Backend-Bibliothek. OLLAMA_LLM_LIBRARY erzwingt einen bestimmten Runner (cuda_v11, rocm oder gar cpu). Sie ist zum Debuggen gedacht, übersteuert die Autoerkennung still und überdauert in Shell-Profilen und Service-Dateien lange, nachdem der Grund vergessen ist. Finden und entfernen:

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

2. Der Treiber ist hinter die Runtime zurückgefallen. Ollama-Upgrades bündeln eine neuere CUDA-Runtime; dein Treiber bewegt sich nicht, bis du ihn bewegst. Gleiche Lösung wie oben im Treiber-Abschnitt.
3. Der Dienst ist ein Container, und die Flags sind weg. Ein neu erstellter Container ohne GPU-Flags ist ein CPU-only-Container. Der NVIDIA-Aufruf ist:

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

Für AMD-Container ist das Äquivalent Device-Passthrough plus Gruppen:

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

Ohne --gpus=all, keine GPU — Docker hat keinen Grund, großzügig zu sein.

Funktioniert Ollama in WSL2?

Ja, mit dem richtigen Treiber am richtigen Ort: den Windows-NVIDIA-Treiber installieren, nie einen Linux-Treiber in der Distribution — ein Treiber innerhalb von WSL bricht das CUDA-Passthrough, statt es zu reparieren. Dann WSL selbst aktualisieren und prüfen, ob das Passthrough-Gerät existiert:

wsl --update   # aus PowerShell
ls /dev/dxg    # in WSL — muss existieren, damit die GPU genutzt werden kann

Mit vorhandenem /dev/dxg und aktuellem Windows-Treiber offloadet Ollama in WSL2 auf die GPU wie eine native Installation. Wer die Indirektion ganz überspringen will: Der Windows-Build von Ollama läuft nativ und sieht die GPU ohne WSL.

Braucht Ollama überhaupt eine GPU?

Nein — ein CPU-only-Lauf ist funktional identisch, nur langsamer, und für kleine Modelle auf einer schnellen CPU kann er durchaus brauchbar sein. Auf Apple Silicon stellt sich die Frage gar nicht erst: Metal nutzt automatisch Unified Memory, und das einzige Limit ist, wie viel RAM du dem Modell gönnst.

Die Fünf-Minuten-Checkliste

Symptom	Wahrscheinliche Ursache	Fix
100% CPU in ollama ps, NVIDIA-Karte vorhanden	Treiber zu alt für die mitgelieferte CUDA	Treiber aktualisieren, Reboot, Dienst neu starten
100% CPU, AMD unter Linux	Fehlende Gruppe render/video	usermod -aG render,video, neu einloggen
100% CPU, nicht unterstützte AMD-Karte	ROCm lehnt das gfx-Ziel ab	HSA_OVERRIDE_GFX_VERSION=10.3.0
40%/60% CPU/GPU-Split	Modell + Kontext überschreiten den VRAM	Kleinere Quantisierung oder kürzeres num_ctx
GPU gestern, CPU heute	Gepinnte OLLAMA_LLM_LIBRARY oder alter Treiber	Umgebungsvariable finden und entfernen; Treiber aktualisieren
GPU nativ, CPU in Docker	Container ohne GPU-Flags gestartet	Neu erstellen mit --gpus=all (oder AMD-Devices)

In dieser Reihenfolge prüfen: ollama ps für den Zustand, Server-Logs für die Erkennungsliste, dann die Tabelle. In neun von zehn Fällen hat die Log-Zeile schon verraten, in welcher Zeile du steckst.