Ollama funktioniert nicht? 9 Fehler, die genaue Meldung und die Lösung

Wenn Ollama streikt, steht der Grund meist im Log. Neun Fehler samt Lösung: Port 11434 belegt, ein Client, der den Server nicht erreicht, ein Modell, das auf der CPU hängt, eine NVIDIA- oder AMD-Karte, die nicht erkannt wird, Speicher, der beim größeren Kontext ausgeht, eine quälend langsame erste Antwort und Downloads oder Ordner, die sich querstellen.

Ein Modell auf dem eigenen Rechner laufen zu lassen, macht richtig Spaß – bis statt einer Antwort eine Fehlermeldung kommt. Die gute Nachricht: Die Meldungen von Ollama sind kurz, ziemlich ehrlich und zeigen jeweils auf eine konkrete Ursache. Unten finden Sie zu jedem Problem den genauen Wortlaut, den Grund und die Lösung für Mac, Windows und Linux, mit den Befehlen der aktuellen stabilen Version 0.40.10 (veröffentlicht am 23. Oktober 2026). Jede hier zitierte Meldung von Ollama haben wir seit 0.40.0 in Code und Dokumentation jeder neuen stabilen Version erneut geprüft, zuletzt am 24. Oktober 2026 in 0.40.10, keine hat sich geändert; neu in 0.40.0 sind die Spalte RUNNER in ollama ps und MLX als Standard auf Macs mit Apple Silicon, und die Abschnitte, in denen das zählt, weisen darauf hin. Installation, die Prüfung, ob der Server läuft, und das Setzen von Umgebungsvariablen stehen in unserer Anleitung, um Ollama lokal einzurichten; diese Seite macht dort weiter, wo jene aufhört.

OllamaProgramm-Datenblatt→

Zuerst das Log lesen

Die Fehlermeldung im Terminal ist die Schlagzeile, das Log der ganze Artikel. Hier liegt es:

# macOS
cat ~/.ollama/logs/server.log

# Linux (systemd-Dienst)
journalctl -u ollama --no-pager --follow --pager-end

# Docker
docker logs <container-name>

# Windows: öffnet den Ordner mit server.log (dem aktuellen)
# und server-#.log (den älteren)
explorer %LOCALAPPDATA%\Ollama

Haben Sie ollama serve von Hand gestartet, erscheint das Log direkt in diesem Terminal. Mehr Details liefert OLLAMA_DEBUG=1 (Debug-Stufe), noch mehr OLLAMA_DEBUG=2 (Trace). Wie die Variable zur App oder zum Dienst kommt, hängt vom System ab und steht Schritt für Schritt in der Einrichtungsanleitung. Unter Windows geht es am schnellsten so: die App über den Infobereich der Taskleiste beenden und dann in der PowerShell:

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

Wer es lieber zuerst sieht: Dieses kurze Video zeigt, wie man die Logs prüft, wenn Ollama nicht mehr antwortet. Es ist auf Englisch; wo es von dieser Seite abweicht, gilt Version 0.40.10.

„bind: address already in use“ auf Port 11434

Sie tippen ollama serve und bekommen das zurück:

Error: listen tcp 127.0.0.1:11434: bind: address already in use

So formuliert es Linux; auf anderen Systemen kann das Ende anders lauten. Die Bedeutung bleibt gleich: Es läuft bereits ein Ollama-Server. Unter macOS und Windows startet die Desktop-App ollama serve von selbst, unter Linux hinterlässt der Installer einen aktiven systemd-Dienst namens ollama. Zwei Server, ein Port: Reise nach Jerusalem mit genau einem Stuhl.

Meistens brauchen Sie ollama serve gar nicht. Prüfen Sie lieber, ob der laufende Server antwortet:

curl http://127.0.0.1:11434
Ollama is running

Wollen Sie wirklich einen eigenen Server im Vordergrund, etwa um seine Ausgabe live zu verfolgen, stoppen Sie zuerst den anderen: sudo systemctl stop ollama unter Linux, oder beenden Sie die App über die Menüleiste (Mac) bzw. den Infobereich (Windows). Alternativ bekommt Ihrer einen anderen Port, und die Clients zeigen auf dieselbe Adresse:

OLLAMA_HOST=127.0.0.1:11435 ollama serve

Unter Linux verrät dieser Befehl, welcher Prozess den Port belegt:

sudo ss -ltnp | grep 11434

„could not connect to ollama server“

Der umgekehrte Fall: Der Befehl ist installiert, aber kein Server hört zu.

Error: could not connect to ollama server, run 'ollama serve' to start it

ollama -v überbringt dieselbe Nachricht etwas sanfter: Warning: could not connect to a running Ollama instance. Unter Linux startet die Kommandozeile nie selbst einen Server; die Meldung heißt also schlicht, dass der Dienst steht. Unter macOS und Windows versucht sie zuerst, die App zu öffnen, und meldet den Fehler nur, wenn das nicht klappt.

# Linux
sudo systemctl start ollama
sudo systemctl status ollama

Auf dem Mac oder unter Windows öffnen Sie die Ollama-App. Läuft der Server auf einem anderen Rechner oder Port, braucht der Client dasselbe OLLAMA_HOST wie der Server; ohne das klopft er bei 127.0.0.1:11434 an, und niemand macht auf.

Läuft es auf der GPU? Die Spalte PROCESSOR lesen

Ein Modell, das im Schneckentempo antwortet, sitzt oft nicht auf der Grafikkarte. Die Lüfter Ihres Laptops melden das vor jedem Befehl, aber ollama ps sagt es mit Zahlen. Die Spalten heißen NAME, ID, SIZE, PROCESSOR, CONTEXT, RUNNER (neu in 0.40.0: llamacpp oder mlx) und UNTIL, und entscheidend ist PROCESSOR:

• 100% GPU: Das ganze Modell liegt auf der Karte. Alles bestens.
• 100% CPU: Es liegt im Arbeitsspeicher – entweder wurde die Karte nicht erkannt (die nächsten zwei Abschnitte), oder es gibt keine nutzbare Karte.
• Eine Aufteilung wie 48%/52% CPU/GPU: Modell und Kontext passten nicht in den Grafikspeicher, ein Teil läuft auf dem Prozessor.
• Auf einem Mac mit Apple Silicon und mlx unter RUNNER: 100% GPU, denn MLX teilt ein Modell nicht auf. Passt das Modell selbst nicht in den freien Speicher, wird es nicht geladen, und die Fehlermeldung enthält model requires … but only … are available.

Bei einer Aufteilung gibt es drei Auswege: den Kontext verkleinern (zwei Abschnitte weiter unten), eine stärker komprimierte Fassung oder ein kleineres Modell nehmen, oder Speicher freimachen, indem Sie ungenutzte Modelle mit ollama stop <modell> entladen. Der Modellfinder sagt Ihnen vorher, welche Modelle auf Ihren Rechner passen und mit wie viel Kontext.

NVIDIA-GPU wird nicht erkannt

Fangen Sie mit den Voraussetzungen an, die schließen schon viel aus. Für Version 0.40.10 verlangt Ollama eine NVIDIA-Karte mit Compute Capability 5.0 oder höher und einen Treiber ab Version 550; Karten mit Compute Capability 5.0 bis 6.2 brauchen Treiber 570 oder neuer. Die Compute Capability jeder Karte veröffentlicht NVIDIA auf seiner Seite zu CUDA-GPUs.

Erfüllt die Karte das und Ollama weicht trotzdem auf die CPU aus, steht im Log meist ein Fehlercode: 3 (nicht initialisiert), 46 (Gerät nicht verfügbar), 100 (kein Gerät) oder 999 (unbekannt). Gehen Sie in dieser Reihenfolge vor:

# 1. Der Treiber muss die Karte sehen
nvidia-smi

# 2. Prüfen, ob das Unified-Memory-Modul (UVM) geladen ist
sudo nvidia-modprobe -u

# 3. Das Unified-Memory-Modul neu laden (die dokumentierte Abhilfe nach Standby unter Linux)
sudo rmmod nvidia_uvm && sudo modprobe nvidia_uvm

Hilft nichts davon, starten Sie neu und aktualisieren Sie den Treiber. Mehr Details gibt es, wenn Sie den Server mit CUDA_ERROR_LEVEL=50 starten und sudo dmesg | grep -i nvrm lesen. Und falls irgendwo noch CUDA_VISIBLE_DEVICES=-1 gesetzt ist: Genau das ist der offizielle Weg, die CPU zu erzwingen. Entfernen Sie es.

Unter Docker muss docker run --gpus all ubuntu nvidia-smi funktionieren, bevor Ollama überhaupt etwas sieht. Startet der Container auf der GPU und fällt nach einer Weile auf die CPU zurück, ergänzen Sie "exec-opts": ["native.cgroupdriver=cgroupfs"] in /etc/docker/daemon.json und starten Docker neu.

AMD-GPU wird unter Linux nicht erkannt

Bei einer AMD-Karte verraten zwei Log-Zeilen das Problem:

msg="failure during GPU discovery" ... error="failed to finish discovery before timeout"
msg="bootstrap discovery took" duration=30s

Meist liegt es an der Treiberversion. Ollama 0.40.10 bringt die Bibliotheken von ROCm 7 mit; mit einem Kerneltreiber aus ROCm 6.x oder älter hängt die GPU-Suche und endet auf der CPU. Die Lösung: auf den ROCm-7-Treiber aktualisieren (amdgpu-install), den Rechner neu starten und danach Ollama.

Die zweite Ursache sind die Rechte an /dev/kfd: Der Benutzer, unter dem Ollama läuft, muss in der Gruppe render sein (auf manchen Systemen video). Der offizielle Installer fügt den Benutzer ollama bereits beiden Gruppen hinzu, sofern es sie gibt; nach einer manuellen Installation erledigen Sie das selbst:

sudo usermod -a -G render ollama

Unterstützt ROCm Ihre Karte nicht, können Sie sie als nahe Verwandte ausgeben. Das dokumentierte Beispiel ist eine RX 5400 (gfx1034), die sich als gfx1030 meldet:

HSA_OVERRIDE_GFX_VERSION="10.3.0"

Bei mehreren Karten setzt eine nummerierte Variable wie HSA_OVERRIDE_GFX_VERSION_0 den Wert Karte für Karte. Die Alternative ist Vulkan, das standardmäßig aktiv ist, wenn sein Backend vorhanden ist (OLLAMA_VULKAN=0 schaltet es ab); damit Ollama über Vulkan den tatsächlich freien Speicher liest, führen Sie sudo setcap cap_perfmon+ep /usr/local/bin/ollama aus. Für den vollen Durchblick: AMD_LOG_LEVEL=3, OLLAMA_DEBUG=1 und sudo dmesg | grep -i amdgpu.

Kein Speicher mehr, sobald der Kontext wächst

Der Kontext (wie viel Text das Modell im Blick behält) hat eine Speicherrechnung, den KV-Cache, und mit llama.cpp (llamacpp in der Spalte RUNNER von ollama ps) wird sie beim Laden des Modells im Voraus bezahlt. Verlangen Sie zu viel, bricht Ollama mit einer Meldung wie llama-server reported out-of-memory during startup: … ab, oder mit einer, die out of memory, cudaMalloc failed oder hipMalloc failed enthält. Manchmal kommt gar kein Fehler: Das Modell verteilt sich stillschweigend auf CPU und GPU.

Version 0.40.10 wählt den Standardkontext nach dem erkannten Grafikspeicher: 4.096 Tokens unter 23 GiB, 32.768 ab 23 GiB und 262.144 ab 47 GiB. Im Log steht die Wahl als default_num_ctx. So ändern Sie ihn:

# Für den ganzen Server
OLLAMA_CONTEXT_LENGTH=8192 ollama serve

# In einer ollama-run-Sitzung
/set parameter num_ctx 8192

# Pro Anfrage über die API
"options": {"num_ctx": 8192}

Die Desktop-App hat dafür einen Schieberegler in den Einstellungen. Das Ergebnis sehen Sie in der Spalte CONTEXT von ollama ps.

Auf einem Mac mit Apple Silicon und einem Modell, das über MLX läuft (mlx unter RUNNER), funktionieren diese Einstellungen anders: MLX reserviert den Kontext nicht beim Laden, sein KV-Cache wächst mit dem Gespräch, und die Zahl unter CONTEXT reserviert weder Speicher, noch kürzt sie das Gespräch; die Obergrenze ist der maximale Kontext des Modells selbst. Der Speicher füllt sich dort, je länger das Gespräch wird, nicht auf einen Schlag beim Laden.

Was kostet das? Wir haben es mit unserem eigenen Rechner für einen Mac mit 16 GB durchgerechnet, der dem Modell 13,0 GiB lässt, bei Q4_K_M-Kompression und mit KV-Cache in f16, der Voreinstellung von Ollama:

Mac mit M4 und 16 GB Unified MemoryHardware-Datenblatt→

Modell	4k	8k	32k	64k	Von 8k auf 32k
Qwen3 8B	5,92 GiB	6,56 GiB	10,38 GiB	15,48 GiB ✗	+3,82 GiB
Gemma 4 12B	7,68 GiB	7,82 GiB	8,65 GiB	9,75 GiB	+0,82 GiB
gpt-oss-20b	11,60 GiB	11,77 GiB	12,78 GiB	14,13 GiB ✗	+1,01 GiB

Gesamter Speicherbedarf (Modelldatei + KV-Cache + Eigenbedarf des Programms). Berechnet von Local AI Scope am 5. Oktober 2026 (die Zeile Gemma 4 12B am 15. Oktober 2026): Dateigrößen gemessen, KV-Cache aus der Architektur des jeweiligen Modells berechnet, Eigenbedarf geschätzt. ✗ = passt nicht in die verfügbaren 13,0 GiB.

Auf einem Mac mit Apple Silicon holt seit 0.40.0 ollama pull gemma4:12b stattdessen die MLX-Fassung (NVFP4-Kompression, 7,18 GiB Download gegenüber 7,47 GiB für die GGUF-Fassung), die ihren Kontext während des Gesprächs bezahlt, wie oben erklärt; die Zeile Gemma 4 12B gilt für die GGUF-Fassung, die Windows, Linux und Intel-Macs bekommen. Stand 7. Oktober 2026 gibt es Qwen3 8B und gpt-oss-20b nur als GGUF; sie laufen auch auf dem Mac über llama.cpp.

Die letzte Spalte ist kein Detail: Für Agenten und Programmieraufgaben empfiehlt Ollama mindestens 64.000 Tokens Kontext. Auf einer Grafikkarte mit 8 GB wiederholt sich die Geschichte früher: Qwen3 8B passt bei 4k, knapp bei 8k und bei 32k nicht mehr. Der Modellfinder rechnet das für Ihren eigenen Rechner aus.

PC mit RTX 4060 8 GBHardware-Datenblatt→

Langsame erste Antwort: Das Modell ist aus dem Speicher geflogen

Die erste Frage nach der Kaffeepause dauert ewig, die nächste ist blitzschnell. Das ist kein Defekt: Ollama behält ein Modell nach der letzten Nutzung 5 Minuten im Speicher und entlädt es dann, die nächste Frage bezahlt also das erneute Laden. Die Spalte UNTIL von ollama ps zeigt, wie lange es noch bleibt.

OLLAMA_KEEP_ALIVE am Server oder keep_alive in jeder Anfrage ändert das: eine Dauer wie 10m oder 24h, eine Zahl in Sekunden, ein negativer Wert für dauerhaft geladen oder 0, um es direkt nach der Antwort zu entladen. Der Wert in der Anfrage hat Vorrang vor der Variable. So laden Sie ein Modell vor und lassen es im Speicher:

curl http://localhost:11434/api/generate -d '{"model": "llama3.2", "keep_alive": -1}'

Ersetzen Sie llama3.2 durch Ihr Modell. Speicher freigeben: ollama stop <modell>. Wenn das Laden selbst nicht fertig wird, beginnt die Meldung mit timed out waiting for llama-server to start: Standardmäßig gibt Ollama nach 5 Minuten ohne Fortschritt auf, und OLLAMA_LOAD_TIMEOUT verlängert diese Frist. Bei einem Modell auf MLX beginnt die Meldung stattdessen mit timeout waiting for mlx runner, und die Frist setzt dieselbe Variable, nur zählt sie dort die gesamte Ladezeit, nicht bloß die Zeit ohne Fortschritt.

Downloads hinter einem Proxy und Ordnerrechte unter Linux

Hinter dem Firmen-Proxy braucht ollama pull den Proxy in der Umgebung des Servers, nicht in Ihrem Terminal:

HTTPS_PROXY=https://proxy.example.com

Die Variable wird wie jede andere Servervariable gesetzt, und das Zertifikat des Proxys muss als Systemzertifikat installiert sein. Unter Docker geben Sie sie mit -e HTTPS_PROXY=https://proxy.example.com mit, oder Sie bauen ein Image, das das Zertifikat hinzufügt und update-ca-certificates ausführt.

Der Download kommt über pulling manifest hinaus und bricht dann ab? Prüfen Sie ollama -v. Bis 0.40.5 (bei GGUF-Modellen seit 0.35.0) liefen die Modelldateien selbst nicht über diesen Proxy: Ollama holte sie direkt vom Download-Server und löste dessen Namen vorher auf dem eigenen Rechner auf. In einem Netz, in dem nur der Proxy ins Internet kommt, scheiterte der Download deshalb, mit redirect target not allowed: resolving …: no such host, wenn der Rechner diesen Namen nicht selbst auflösen konnte. Seit 0.40.6 laufen auch die Dateien über den Proxy: Ein Update behebt es.

Modelle verschoben, und jetzt lädt nichts mehr? Standardmäßig liegen sie unter ~/.ollama/models (macOS), /usr/share/ollama/.ollama/models (Linux) und C:\Users\%username%\.ollama\models (Windows); OLLAMA_MODELS verlegt sie. Unter Linux läuft der Dienst als eigener Benutzer ollama, der im neuen Ordner lesen und schreiben können muss:

sudo chown -R ollama:ollama /pfad/zu/ihren/modellen

Ist der Ordner seit dem Update gewachsen, liegt das daran: In den Versionen 0.40.0, 0.40.1 und 0.40.2 konnte ein Modell, das Sie mit einer älteren Version heruntergeladen hatten, beim ersten Start im Hintergrund für llama.cpp umgewandelt werden, sofern die Kopie auf die Platte passte, und Ollama behielt das Original im selben Ordner als Sicherung, für den Fall, dass Sie zu einer älteren Version zurückwollten; die Gewichte eines umgewandelten Modells liegen also doppelt auf der Platte. Version 0.40.3 hat diese Umwandlung ausgesetzt, und auch 0.40.10 nimmt sie nicht wieder auf: Beim Laden eines Modells startet sie nicht mehr, und was schon umgewandelt wurde, bleibt auf der Platte, Kopie wie Sicherung. Seit 0.40.2 zeigt ollama list jedes Modell nur einmal an, und die Versionshinweise zu 0.40.2 enthalten einen Befehl, der die Sicherungen löscht (danach müssen Sie diese Modelle neu herunterladen, wenn Sie zu einer Version vor 0.40 zurückkehren).

Meldungen, Befehle und Standardwerte aus den Ollama-Seiten zu Fehlerbehebung, FAQ, GPU, Linux und Kontextlänge sowie aus dem Quellcode, Version 0.40.10, gelesen am 24. Oktober 2026 (erstmals gelesen am 3. Oktober 2026 in Version 0.35.1): Die Meldungen sind unverändert, die Spalte RUNNER und die Hinweise zu MLX stammen aus 0.40.0.

Was Ollama von sich aus verschickt, während all das läuft, und wie es im Vergleich zu den anderen Programmen dasteht, lesen Sie in seinem Steckbrief.