Ollama lokal oder in Docker? Ich habe beides analysiert und zeige dir, warum die Frage falsch gestellt ist

Inhalt

• Der Moment, der alles in Frage gestellt hat
• Die zwei Optionen sauber nebeneinander
  • Option A: Ollama auf dem Host (Ubuntu)
  • Option B: Ollama in Docker
• Warum die Frage eigentlich falsch gestellt ist
• Die Konsequenz: Vollständige Containerisierung
• Der erste Start: Einfach wie es sein sollte
• Was das über Softwareentwicklung als Freelancer aussagt
• Die GPU-Frage für später

Der Moment, der alles in Frage gestellt hat

Ich hatte das Backend fertig. Qdrant lief. Die Extension schickte Payloads. Und dann:

Fehler: Ollama is not reachable. Make sure Ollama is running on port 11434.

Der erste Impuls: Ollama installieren, starten, fertig.

Aber ich hab inne gehalten. Und die eigentlich wichtige Frage gestellt:

Was ist der richtige Ort für Ollama – und was sagt diese Entscheidung über das gesamte System aus?

Diese Frage hat mich länger beschäftigt als erwartet. Und das Ergebnis hat die gesamte Architektur beeinflusst.

Die zwei Optionen sauber nebeneinander

Option A: Ollama auf dem Host (Ubuntu)

curl -fsSL https://ollama.com/install.sh | sh
systemctl start ollama
ollama pull nomic-embed-text
ollama pull llama3.2

Der Backend-Container in Docker verbindet sich dann via host.docker.internal:11434 oder 172.17.0.1:11434 mit dem Host.

Vorteile:

• GPU-Zugriff ohne Konfiguration: Ollama auf dem Host kann NVIDIA-GPUs direkt nutzen. In Docker braucht man das NVIDIA Container Toolkit und explizite GPU-Passthrough-Konfiguration
• Weniger Docker-Overhead: Keine Volumes für Modell-Daten, kein Container-Overhead für Inferenz
• Einfacheres erstes Setup: Drei Befehle, läuft sofort

Nachteile:

• System-Verschmutzung: Software auf dem Host bedeutet Updates verwalten, Systemd-Services, potenzielle Konflikte mit anderen Projekten
• Nicht portierbar: Ein neuer Mitarbeiter, ein neues System, eine CI/CD-Pipeline – alle müssen Ollama separat installieren. Das Projekt ist nicht mehr git clone && docker-compose up
• Kein klarer Deployment-Pfad: In der Cloud gibt es keinen “Host”. Die Produktionsumgebung sieht fundamental anders aus als die Entwicklungsumgebung

Option B: Ollama in Docker

services:
  ollama:
    image: ollama/ollama:latest
    volumes:
      - ollama_data:/root/.ollama
    # Kein Host-Port-Mapping: Das Backend kommuniziert intern über das Docker-Netzwerk.
    # Nur aktivieren, wenn kein lokaler Ollama-Dienst auf Port 11434 läuft und
    # Ollama auch vom Host aus erreichbar sein soll:
    # ports:
    #   - "11434:11434"

Vorteile:

• Vollständige Reproduzierbarkeit: docker-compose up startet alles. Auf jedem System. Immer gleich.
• Saubere Isolation: Ollama läuft in seiner eigenen Sandbox. Keine Auswirkungen auf den Host.
• Klarer Deployment-Pfad: Dieselbe docker-compose.yml beschreibt lokal und (mit Overrides) die Cloud
• GPU-Passthrough möglich: Mit NVIDIA Container Toolkit und einer einzigen compose-Konfiguration

Nachteile:

• GPU-Setup ist aufwendiger: NVIDIA Container Toolkit muss auf dem Host installiert sein
• Etwas höherer Overhead: Container-Layer, Volume-Mounting für Modelle
• Port-Konflikt wenn Ollama bereits auf dem Host läuft: Docker versucht standardmäßig, den Host-Port 11434 zu exposen. Läuft bereits ein Ollama-Systemdienst, schlägt docker-compose up mit address already in use fehl. Die Lösung: Das ports-Mapping weglassen — das Backend kommuniziert ohnehin über das Docker-interne Netzwerk, nicht über den Host-Port.

Warum die Frage eigentlich falsch gestellt ist

Ich habe gemerkt, dass ich die Frage “Ollama lokal oder Docker?” aus der falschen Perspektive betrachtet habe. Die eigentliche Frage ist:

Für wen baue ich dieses System?

Wenn die Antwort “nur für mich, auf dieser einen Maschine” ist, dann ist Host-Installation pragmatisch und ausreichend.

Wenn die Antwort “ich will das irgendwann deployen, teilen oder auf einem anderen System laufen lassen” ist, dann ist Host-Installation technische Schulden.

Ich baue ein System, das ich der Öffentlichkeit zugänglich machen möchte. Die Antwort war klar.

Die Konsequenz: Vollständige Containerisierung

Die Entscheidung für Docker hat eine Kaskade von weiteren Entscheidungen ausgelöst:

1. Provider-Abstraktion wird notwendig

Wenn Ollama in Docker läuft, ist das lokal perfekt. Aber in der Cloud? Einen GPU-optimierten Container für Ollama in Azure oder AWS zu betreiben ist teuer – oder gar nicht verfügbar in der günstigsten Tier.

Also brauchte ich eine Abstraktion: Lokal läuft Ollama als Container, in der Cloud wird stattdessen OpenAI verwendet. Dieselbe Code-Basis, dieselbe Architektur, andere Implementierung. Das ist die Provider-Abstraktion, die ich in einem separaten Post beschreibe.

2. Docker Compose Override-Pattern

Wenn lokal Ollama dabei ist, in der Produktion aber nicht – wie manage ich das ohne zwei komplett verschiedene docker-compose.yml-Dateien?

Das Override-Pattern: Eine Basis-Datei, ein lokales Override (automatisch geladen), ein Produktions-Override (explizit angegeben). Drei Dateien, klare Verantwortlichkeiten.

3. Persistentes Volume für Modelle

Modelle sind groß. nomic-embed-text ist ~270MB, llama3.2 ist ~2GB. Die dürfen nicht bei jedem docker-compose down && docker-compose up neu heruntergeladen werden.

volumes:
  ollama_data:
    # Named volume – überlebt docker-compose down
    # Wird gelöscht durch docker-compose down -v (explizit)

Named Volumes in Docker persistieren über Container-Neustarts hinaus. Ohne -v-Flag beim down bleiben die Modell-Daten erhalten. Das ist das korrekte Verhalten.

Der erste Start: Einfach wie es sein sollte

Wenn man das Projekt zum ersten Mal klont und startet:

docker-compose up --build -d

Fertig. Kein zweiter Schritt.

Der Ollama-Container lädt beim ersten Start automatisch nomic-embed-text (~274 MB) und llama3.2 (~2 GB) herunter. Das dauert einige Minuten — je nach Verbindung. Beim nächsten docker-compose up erkennt der Container die vorhandenen Modelle im Volume und startet sofort.

Das ermöglicht ein eigenes ollama/Dockerfile mit einem Entrypoint-Script, das diese Logik übernimmt: Server starten, auf API warten, Modelle prüfen, bei Bedarf pullen. Die Modelle persistieren in einem Named Volume — docker-compose down ohne -v löscht sie nicht. Das ist kein Trick, das ist korrektes Docker-Design.

Das Ergebnis: Wer das Repo klont, tippt einen Befehl. Alles läuft.

Was das über Softwareentwicklung als Freelancer aussagt

Diese Entscheidung – Ollama in Docker statt auf dem Host – hat mich etwa eine Stunde Mehraufwand gekostet. Dafür habe ich:

• Ein System, das auf jedem Rechner mit Docker funktioniert, ohne Setup-Dokumentation
• Eine klare Trennung zwischen lokaler Entwicklung und Produktion durch Override-Pattern
• Die Grundlage für eine Cloud-Deployment-Strategie, die nicht von Null anfangen muss

Als Freelancer ist das entscheidend. Wenn ich ein System für einen Kunden aufbaue und dann übergebe, will ich nicht, dass der nächste Entwickler eine stundenlange Setup-Doku durcharbeiten muss. docker-compose up sollte reichen.

Und wenn ich dasselbe System in die Cloud bringe, will ich nicht bei Null anfangen. Das Override-Pattern macht den Wechsel zu einer Frage von einem Flag.

Das ist keine Überentwicklung. Das ist die Grundlage für nachhaltige Softwareentwicklung.

Die GPU-Frage für später

Für diejenigen mit NVIDIA-GPU: Docker und Ollama können GPU-Beschleunigung nutzen. Das Setup:

# NVIDIA Container Toolkit installieren
sudo apt install nvidia-container-toolkit
sudo systemctl restart docker

# In docker-compose.override.yml:
services:
  ollama:
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

Das ist auskommentiert in meiner Override-Datei – für alle die es nutzen wollen, ist es ein Einzeiler.

Für den produktiven Einsatz ohne GPU ist llama3.2 auf CPU langsamer, aber durchaus nutzbar für moderate Anfragemengen. nomic-embed-text (Embedding-Modell) ist auch auf CPU schnell genug.

Zurück zur Übersicht: Von der Screenshot-Extension zur KI-Memory-Engine