Ollama in Docker installieren: CPU, GPU, Volumes und API-Prüfung

Was sich durch Ollama in Docker ändert

Ollama wirkt nativ wie ein lokaler Dienst: Ein Befehl startet die Laufzeit, Modelle liegen auf dem Rechner und Clients verwenden Port 11434. Docker legt darum einen Container mit eigener Dateisicht, Prozessumgebung, Netzwerkkonfiguration und Lebensdauer. Das macht die Bereitstellung wiederholbar, bedeutet aber auch: Ein Modell, das nur im beschreibbaren Container-Layer liegt, kann beim Entfernen des Containers verschwinden.

Darum ist ein funktionierender docker run-Befehl nur der Anfang. Entscheide, ob Docker die einzige Ollama-Laufzeit ist, ob ein Host-Programm oder ein weiterer Container zugreift und ob Modelldownloads ein Upgrade überleben müssen. Halte diese Grenzen sichtbar, bevor du OpenCode, einen MCP-Host, eine Weboberfläche oder einen Remote-Client ergänzt.

CPU, NVIDIA-GPU oder AMD-GPU wählen

Nutze zunächst CPU, wenn du Netzwerk, Volumes oder einen neuen Host überprüfst. Dieser Weg hat die wenigsten beweglichen Teile und liefert eine saubere Basis für Ladezeit und Antwortgeschwindigkeit. Wenn die API funktioniert, wechsle zu dem für deinen Host dokumentierten Beschleunigerpfad, statt beliebige Docker-Flags aus einer anderen Umgebung zu übernehmen.

NVIDIA-Container benötigen normalerweise einen funktionierenden Host-Treiber und das NVIDIA Container Toolkit. AMD-Bereitstellungen können ein anderes Image-Tag und andere Gerätemappings verwenden; die Unterstützung hängt von Betriebssystem, Runtime und aktueller Ollama-Dokumentation ab. Behandle die GPU als Optimierung: Endpoint, Volume und grundlegende Health-Prüfungen sollten gleich bleiben.

docker version

docker run --rm --gpus=all nvidia/cuda:12.0.0-base-ubuntu22.04 nvidia-smi

Persistenten Modellspeicher anlegen

Ein benanntes Volume ist der einfachste Standard für Ollama in Docker: Docker verwaltet den Speicherort und der Container kann ersetzt werden, ohne die Modelldateien manuell zu kopieren. Das offizielle Image legt Ollama-Daten unter /root/.ollama ab; mounte das Volume deshalb immer dorthin. Erzeuge beim Upgrade nicht versehentlich ein zweites Volume, wenn du dieselbe Modellbibliothek weiterverwenden willst.

Ein Bind-Mount ist sinnvoll, wenn du den Speicherverbrauch auf einem bestimmten Laufwerk kontrollieren oder ein bekanntes Host-Verzeichnis sichern musst. Dafür entstehen mehr Pfad- und Berechtigungsfragen. Für den ersten Betrieb ist ein benanntes Volume meist leichter zu erklären und schwerer versehentlich zu beschädigen.

docker volume create ollama-data

docker run -d --name ollama -p 11434:11434 -v ollama-data:/root/.ollama ollama/ollama

docker exec -it ollama ollama pull <model-name>

Container starten und API prüfen

Prüfe nach der Ausgabe der Container-ID zuerst den Zustand, bevor du ein großes Modell lädst. docker ps zeigt, ob der Prozess noch läuft; docker logs kann Port-, Berechtigungs- oder Runtime-Fehler sichtbar machen. Frage danach /api/tags vom Host ab. Eine erfolgreiche Antwort bestätigt einen erreichbaren HTTP-Endpoint, aber noch nicht, dass jedes Modell geladen ist oder jeder Client zugreifen darf.

Eine kleine Modellanfrage ist die zweite Prüfung. So trennst du einen gesunden HTTP-Listener von einem funktionierenden Modellpfad. Wenn die API antwortet, aber die Modellanfrage scheitert, prüfe Modellnamen, freien Speicher, RAM und Container-Logs, bevor du Netzwerkoptionen änderst.

1. Prozess prüfen

   Bestätige, dass der Container Up ist und der veröffentlichte Port dem beabsichtigten Port entspricht.

2. Endpoint prüfen

   Rufe /api/tags von derselben Maschine auf, die Port 11434 veröffentlicht, und notiere den Statuscode.

3. Modell prüfen

   Lade ein kleines Modell und sende eine harmlose Anfrage, bevor du Editor oder Agent verbindest.

docker ps --filter name=ollama

docker logs ollama --tail 100

curl http://127.0.0.1:11434/api/tags

docker exec -it ollama ollama list

Anwendungen ohne localhost-Verwechslung verbinden

Die richtige Ollama-URL hängt vom Ort des Clients ab. Eine Desktop-Anwendung auf demselben Host kann bei veröffentlichtem Port normalerweise http://127.0.0.1:11434 verwenden. Ein zweiter Container im selben Docker-Netzwerk sollte den Ollama-Service über seinen Compose-Servicenamen und Port aufrufen, zum Beispiel http://ollama:11434. In einem Container bedeutet 127.0.0.1 nur diesen Container und nicht automatisch den Windows-, macOS- oder Linux-Host.

Für einen Remote-Client brauchst du eine ausdrücklich geschützte Adresse und Firewall-Regel. Veröffentliche Port 11434 nicht einfach im öffentlichen Internet, damit ein Testprogramm funktioniert. Dokumentiere Route, Authentifizierung oder privates Netzwerk und den genauen Modelldienst, den der Client erreichen darf.

Modelle, Kontext und Zugriff sicher halten

Docker macht einen Ollama-Dienst nicht automatisch privat. Ein veröffentlichter Port kann je nach Befehl und Host-Standard an alle Interfaces gebunden werden. Für einen reinen Host-Test ist eine Loopback-Bindung wie -p 127.0.0.1:11434:11434 sinnvoll. Wenn ein Compose-Service intern zugreifen muss, nutze ein privates Netzwerk und veröffentliche keinen Host-Port ohne konkreten Grund.

Kontextlänge, Parallelität und GPU-Speicher beeinflussen den RAM- und VRAM-Verbrauch des Containers. Ändere jeweils nur eine Variable und beobachte docker stats, den Host-Speicher und das Antwortverhalten. Halte Geheimnisse aus Images, Shell-Historie, Screenshots und versionierten Compose-Dateien heraus; ein lokaler Model-Endpoint und ein externer Suchdienst haben unterschiedliche Datenschutzgrenzen.

Health-, GPU-, Volume- und API-Fehler prüfen

Wenn die Ollama-Docker-Bereitstellung scheitert, ändere immer nur eine Schicht. Prüfe zuerst Docker, dann ob der Ollama-Container weiterläuft, danach Volume, API, Modell und erst am Ende die Client-Anwendung. Wenn du nach jedem Fehler den kompletten Befehl austauschst, bleibt die tatsächlich fehlerhafte Grenze unsichtbar.

GPU-Probleme liegen meist beim Host-Runtime-Pfad und nicht bei der Ollama-API. Ein Container kann /api/tags beantworten und trotzdem CPU verwenden, weil die GPU nicht durchgereicht wurde, der Treiber nicht passt oder das Image nicht zum Host gehört. Fehlt ein Modell nach dem Ersetzen, vergleiche docker inspect und das Ziel /root/.ollama, bevor du erneut herunterlädst.

docker inspect ollama

docker stats ollama

docker stop ollama && docker rm ollama