Ollama + Open WebUI selbst hosten: Deine KI ohne Cloud

Große Sprachmodelle wie ChatGPT & Co. schicken deine Eingaben auf fremde Server. Ollama bringt die Modelle auf deine eigene Hardware, Open WebUI liefert die komfortable Chat-Oberfläche dazu – komplett quelloffen, ohne Cloud, ohne Abo. In diesem Artikel richten wir den Stack mit Docker Compose ein und gehen jede Zeile der Konfiguration durch: Ressourcen-Limits, Kontextfenster, Modell-Download und sicheren Zugriff von außen.

Warum Ollama + Open WebUI?

Die Kombination aus Ollama und Open WebUI ist in der Self-Hosting-Community das Pendant zu ChatGPT, das dir gehört:

• Deine Daten bleiben bei dir – Anfragen und Chatverläufe verlassen deinen Server nicht.
• Open Source & kostenlos – Software und Modelle (z. B. Llama, Qwen, Gemma) sind frei, keine Token-Abrechnung.
• Open WebUI bringt eine ChatGPT-ähnliche Oberfläche mit – inkl. Chat-Verlauf, Datei-Upload („RAG“), mehreren Modellen pro Chat und einer Admin-Verwaltung.
• Standard-API: Ollama spricht eine OpenAI-kompatible Schnittstelle – bestehende Tools lassen sich einfach umbiegen.

Den Anfang macht die Konfiguration, die wir in unserer Instanz seit einiger Zeit im Einsatz haben – bewusst für CPU-Betrieb ausgelegt und mit harten Ressourcen-Grenzen, damit die KI dem restlichen Server nie die Luft nimmt.

Vorbereitung: Hardware, Docker & Ordnerstruktur

Für den CPU-Betrieb brauchst du vor allem eines: Arbeitsspeicher. Ein 7B-Modell (z. B. Llama 3.2 in 4-Bit-Quantisierung) belegt rund 5 GB RAM – zuzüglich Kontext-Puffer und Overhead. Wer nur kleinere Modelle (1–4B) fährt, kommt mit 8 GB aus; wer 13B+ nutzen will, sollte 32 GB oder mehr einplanen. Die CPU sollte mehrere Kerne haben: Die Config unten rechnet mit 12 verfügbaren Threads, drosselt den Container aber per Limit auf 4 Kerne.

mkdir -p ~/ollama && cd ~/ollama

# Nachher sollte die Struktur so aussehen:
# ~/ollama/
# ├── docker-compose.yml
# ├── .env
# ├── ollama_data/        ← Modelle & Ollama-Konfiguration (wächst!)
# └── openwebui_data/     ← Chatverläufe & Einstellungen

Die beiden Daten-Ordner werden als Bind-Mounts eingebunden – dadurch liegen alle Daten direkt im Projektordner und lassen sich einfach sichern (mehr dazu im Abschnitt Updates).

docker-compose.yml – der komplette Stack

Zwei Dienste, ein internes Netz: ollama stellt die Modelle bereit (API auf Port 11434), open-webui ist die Weboberfläche (Port 8080 im Container). Beide reden im privaten ai-network miteinander – nach außen geöffnet wird über die Port-Zuordnung nur, was wirklich öffentlich sein soll:

services:
  ollama:
    image: ollama/ollama:latest   # CPU-Version – für ROCm/GPU anderes Tag nötig!
    container_name: ollama
    ports:
      - "127.0.0.1:50530:11434"
    volumes:
      - ./ollama_data:/root/.ollama
    environment:
      - OLLAMA_HOST=0.0.0.0
      - OLLAMA_KEEP_ALIVE=1h
      - OLLAMA_NUM_PARALLEL=1
      - OLLAMA_MAX_LOADED_MODELS=1
      - OLLAMA_NUM_CTX=8192
      - OMP_NUM_THREADS=12
      - OMP_WAIT_POLICY=active
    shm_size: 4gb
    restart: unless-stopped
    deploy:
      resources:
        limits:
          cpus: "4"
          memory: 4G
    networks:
      - ai-network

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    ports:
      - "127.0.0.1:50531:8080"
    volumes:
      - ./openwebui_data:/app/backend/data
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
      - WEBUI_SECRET_KEY=${WEBUI_SECRET_KEY:-default_secret_change_me}
      - WEBUI_NAME=HAI
    depends_on:
      - ollama
    restart: unless-stopped
    networks:
      - ai-network

networks:
  ai-network:
    driver: bridge

Zwei bewusste Änderungen gegenüber der ursprünglichen Vorlage: Der überflüssige volumes:-Block am Anfang wurde entfernt (die Dienste nutzen Bind-Mounts, keine Named Volumes – die Deklaration hätte nur ungenutzte Volume-Einträge erzeugt), und alle Ports sind in Anführungszeichen gesetzt, damit Compose sie nicht als Zahlen fehlinterpretiert.

Der Ollama-Dienst Zeile für Zeile

Ollama ist der eigentliche „Model-Runner“. Die wichtigsten Einstellungen im Detail:

• image: ollama/ollama:latest – das Standard-Image ist die CPU-Version (im Kommentar der Datei deshalb „nicht ROCm!“). Für AMD-GPUs gibt es eigene ROCm-Tags, für Nvidia braucht es zusätzlich den GPU-Runtime – dazu später mehr.
• ports: 127.0.0.1:50530:11434 – die Ollama-API (Container-Port 11434) wird nur auf localhost gemappt. Wichtig, denn die Ollama-API bringt keine eigene Authentifizierung mit – wer sie öffentlich exponiert, stellt jedem einen unbegrenzten Modell-Zugang bereit.
• ./ollama_data:/root/.ollama – hier liegen alle Modelle und Einstellungen. Der Ordner wird schnell mehrere Dutzend GB groß – auf ausreichend freien Speicher achten.
• OLLAMA_HOST=0.0.0.0 – im Container an allen Interfaces lauschen. Klingt gefährlich, ist es hier nicht: Das Port-Mapping auf 127.0.0.1 sorgt dafür, dass die API von außen trotzdem nicht erreichbar ist – nur Open WebUI erreicht sie im internen Netz unter http://ollama:11434.
• OLLAMA_KEEP_ALIVE=1h – ein geladenes Modell bleibt eine Stunde im Speicher, statt nach jeder Anfrage entladen zu werden. Spart Ladezeit, kostet aber RAM – für eine einzelne Person ideal.
• OLLAMA_NUM_PARALLEL=1 – nur eine Anfrage wird gleichzeitig bearbeitet. Macht die Antwortzeiten vorhersehbar und verhindert RAM-Spitzen bei mehreren parallelen Chats.
• OLLAMA_MAX_LOADED_MODELS=1 – es ist immer nur ein Modell gleichzeitig geladen. Wer zwischen Modellen wechselt, nimmt dafür einen erneuten Ladevorgang in Kauf – dafür bleibt der Speicherbedarf konstant.
• OLLAMA_NUM_CTX=8192 – Größe des Kontextfensters in Tokens. Größer = längere Gespräche und mehr Dokument-Kontext, aber auch deutlich mehr RAM durch den KV-Cache. 8192 ist für die meisten Alltagsfälle ein guter Kompromiss.
• OMP_NUM_THREADS=12 + OMP_WAIT_POLICY=active – CPU-Optimierung für die zugrundeliegende Llama.cpp-Runtime: 12 Threads nutzen, die Kerne aktiv („busy waiting“) halten. Zum Host-System passend abstimmen.
• shm_size: 4gb – vergrößert das Shared Memory des Containers; bei Ollama in Verbindung mit den Ressourcen-Limits ein bewährtes Mittel gegen Abstürze unter Last.
• deploy.resources.limits – cpus: 4, memory: 4G: Ein hartes Limit, damit Ollama niemals den gesamten Server frisst. Bedenke: Das Limit gilt zusätzlich zum Modell-RAM-Bedarf – das System sollte entsprechend dimensioniert sein.

Open WebUI & der sichere Secret-Key

Open WebUI ist die eigentliche Oberfläche, unter der du später chattest:

• image: ghcr.io/open-webui/open-webui:main – Achtung: :main ist die Rolling-Release-Variante mit den neuesten Features, aber auch den frischesten Bugs. Für Stabilität besser auf ein konkretes Release-Tag pinnen (z. B. :v0.6.x – verfügbare Tags in der GHCR-Übersicht).
• 127.0.0.1:50531:8080 – die Oberfläche lauscht ebenfalls nur lokal; ausgeliefert wird sie später über einen Reverse Proxy mit HTTPS.
• ./openwebui_data:/app/backend/data – Chatverläufe, Nutzerkonten und Einstellungen. Wer hier sein Backup pflegt, verliert nie einen Chat.
• OLLAMA_BASE_URL=http://ollama:11434 – Open WebUI spricht Ollama über den Dienstnamen im Compose-Netz an. Wichtig: Der Name muss exakt dem Service-Namen im Compose-File entsprechen (ollama), nicht einer IP.
• WEBUI_SECRET_KEY – signiert Sessions und ist Pflicht, sobald die Instanz öffentlich erreichbar ist. Der Fallback-Wert default_secret_change_me ist nur ein Platzhalter!
• WEBUI_NAME=HAI – der angezeigte Name deiner Instanz in der Oberfläche (bei dir „HAI“ – lässt sich jederzeit ändern).

Den Secret-Key legen wir sauber in einer .env-Datei ab – Compose liest sie automatisch und setzt ihn in das ${WEBUI_SECRET_KEY}-Muster ein:

# ~/ollama/.env
WEBUI_SECRET_KEY=HIER_LANGES_GEHEIMNIS_EINFUEGEN

# Geheimen Schlüssel erzeugen:
openssl rand -hex 32

Erster Start: Admin-Konto & Modell laden

cd ~/ollama
docker compose up -d

# Laufen beide Container?
docker compose ps

Danach die Oberfläche öffnen – auf dem Server selbst über http://127.0.0.1:50531 (per SSH-Tunnel: ssh -L 50531:127.0.0.1:50531 dein-server). Beim allerersten Aufruf legst du das Admin-Konto an – dieser erste Nutzer erhält automatisch Admin-Rechte. Anschließend ein Modell herunterladen:

# Variante 1: Direkt in der Oberfläche
# → oben links das Modell-Icon → „Modelle verwalten“ → Modellnamen eingeben (z. B. llama3.2:3b)

# Variante 2: Per Ollama-CLI im Container
docker exec -it ollama ollama pull llama3.2:3b

# Vorhandene Modelle anzeigen
docker exec ollama ollama list

Der Download kann je nach Modell und Leitung einige Minuten dauern (3B-Modelle ≈ 2 GB, 7B-Modelle ≈ 4–5 GB). Danach kannst du im Chat oben das Modell auswählen und losschreiben. Die aktuelle Modell-Auswahl findest du unter ollama.com/library – die Namen in den Beispielen oben sind nur Einstiegspunkte.

Zugriff von außen: Reverse Proxy & API

Für den Zugriff von unterwegs hängst du Open WebUI hinter einen Reverse Proxy mit HTTPS – wie beim SearXNG-Setup genügt beim Caddy ein kleiner Block:

# Caddyfile
ai.example.org {
    encode zstd gzip
    reverse_proxy 127.0.0.1:50531
}

Lokal kannst du die OpenAI-kompatible API auch direkt testen:

curl http://127.0.0.1:50530/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"llama3.2:3b","messages":[{"role":"user","content":"Was ist Self-Hosting?"}]}'

Ressourcen & Performance-Tuning

Die Config ist auf einen Nutzer und CPU-Betrieb optimiert. Die wichtigsten Stellschrauben, falls du etwas ändern willst:

GPU-Alternative: AMD RX 7900 XT (ROCm)

Wer spürbar größere Modelle flüssig betreiben will, lagert die Berechnung auf die Grafikkarte aus: Eine AMD Radeon RX 7900 XT (RDNA3, gfx1100, 20 GB VRAM) schafft 7–14B-Modelle locker und bewegt sich bei 32B-Modellen (4-Bit) an der Grenze des Machbaren – ohne dass die CPU währenddessen unter Last steht. Für AMD-GPUs liefert Ollama ein eigenes Image: ollama/ollama:rocm. So sieht unsere GPU-Variante des Stacks aus – wieder als eigener Compose-Stack mit den gleichen Daten-Ordnern und dem ai-network:

services:
  ollama:
    image: ollama/ollama:rocm          # ROCm-Variante für AMD-GPUs
    container_name: ollama
    ports:
      - "127.0.0.1:50513:11434"
    devices:
      - /dev/kfd
      - /dev/dri
    volumes:
      - ./ollama_data:/root/.ollama
    environment:
      # RX 7900 XT (RDNA3, gfx1100)
      - HSA_OVERRIDE_GFX_VERSION=11.0.0
      - HCC_AMDGPU_TARGET=gfx1100
      - OLLAMA_HOST=0.0.0.0
      - OLLAMA_KEEP_ALIVE=1h            # Modell bleibt 1h geladen
      - OLLAMA_NUM_PARALLEL=1           # Nur eine Anfrage parallel
      - OLLAMA_MAX_LOADED_MODELS=1      # Nur ein Modell gleichzeitig
      - OLLAMA_LOAD_TIMEOUT=10m         # Lade-Timeout großzügig (10 Min.)
      - OLLAMA_SCHED_SPREAD=1           # Last gleichmäßig verteilen
      - OLLAMA_FLASH_ATTENTION=1        # Flash Attention aktivieren
      - OLLAMA_NUM_CTX=16384            # Großes Kontextfenster
      - OLLAMA_DEBUG=0                  # 0 = aus, 1 = Diagnose-Logs
    shm_size: '32gb'                    # ROCm braucht viel Shared Memory
    restart: unless-stopped
    networks:
      - ai-network

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    ports:
      - "127.0.0.1:50512:8080"
    volumes:
      - ./openwebui_data:/app/backend/data
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
      - WEBUI_SECRET_KEY=${WEBUI_SECRET_KEY:-default_secret_change_me}
      - WEBUI_NAME=Nextcloud AI
    depends_on:
      - ollama
    restart: unless-stopped
    networks:
      - ai-network

networks:
  ai-network:
    driver: bridge

Wie bei der CPU-Variante habe ich zwei Dinge bereinigt: den überflüssigen volumes:-Block (auch hier laufen Bind-Mounts, keine Named Volumes) und die Kommentare, die nicht zu den Werten passten (MAX_LOADED_MODELS=1 lädt eben ein Modell, KEEP_ALIVE=1h ist nicht „permanent“). WEBUI_NAME=Nextcloud AI ist nur der Anzeigename deiner Instanz – beliebig änderbar.

Voraussetzungen: Kernel, Treiber & passende Modelle

• amdgpu-Kernelmodul: Der Host braucht einen Kernel mit aktivem AMD-Treiber – prüfen mit lsmod | grep amdgpu. Bei Problemen mit Secure Boot oder fehlendem Modul hilft der amdgpu-dkms-Treiber aus dem ROCm-Repository.
• Geräte im Container: /dev/kfd (ROCm-Schnittstelle) und /dev/dri (amdgpu-Geräte) werden per devices durchgereicht – das ist der zentrale Unterschied zur CPU-Variante.
• VRAM-Planung: Die 7900 XT hat 20 GB VRAM – Modellgewichte und Kontext-Puffer (KV-Cache) müssen hineinpassen. Grobe Orientierung:

Die ROCm-Einstellungen im Detail

• image: ollama/ollama:rocm – das ROCm-Image ersetzt die CPU-Version. Achtung: Es ist deutlich größer und lädt bei jedem Start viele Treiber-Bibliotheken.
• HSA_OVERRIDE_GFX_VERSION=11.0.0 + HCC_AMDGPU_TARGET=gfx1100 – legen die Ziel-Architektur fest. Die 7900 XT (gfx1100) wird von aktuellen Ollama-Versionen eigentlich nativ unterstützt; der Override ist der „Sicherheitswert“ aus diesem Setup und schadet nicht. Bei neueren Images lässt er sich oft weglassen.
• OLLAMA_LOAD_TIMEOUT=10m – wartet bis zu 10 Minuten, bis ein großes Modell in den VRAM geladen ist. Ohne diese Erhöhung bricht das Laden auf langsamen Systemen gern mit einem Timeout ab.
• OLLAMA_SCHED_SPREAD=1 – verteilt Anfragen gleichmäßig (bei mehreren GPUs auf alle Karten, sonst dezent auf die verfügbare).
• OLLAMA_FLASH_ATTENTION=1 – aktiviert Flash Attention: beschleunigt die Aufmerksamkeitsberechnung und senkt den KV-Cache-Verbrauch – bei ROCm ein klarer Gewinn.
• OLLAMA_NUM_CTX=16384 – doppelt so großes Kontextfenster wie in der CPU-Variante (der VRAM erlaubt es). Wer 32B-Modelle fahren will, reduziert diesen Wert wieder auf 8192 oder weniger.
• shm_size: '32gb' – ROCm nutzt Shared Memory intensiv für die Kommunikation zwischen CPU und GPU; die 4 GB aus der CPU-Variante wären hier schnell am Limit.
• Bewusst keine deploy.limits: Anders als beim CPU-Setup gibt es hier keine künstlichen CPU-/RAM-Grenzen – Ollama soll frei über VRAM und System-RAM disponieren können. Das System selbst braucht trotzdem genug Arbeitsspeicher (≥ 16 GB empfohlen).

Updates & Backups

Updates laufen wie gewohnt über Compose:

cd ~/ollama
docker compose pull
docker compose up -d

• Backup: Beide Projektordner (ollama_data, openwebui_data) regelmäßig sichern – z. B. per rsync auf ein NAS oder in ein Backup-Skript. Die Chatverläufe liegen komplett in openwebui_data.
• Modell-Pflege: Nicht mehr genutzte Modelle löschen (docker exec ollama ollama rm llama3.2:3b), sonst wächst der Speicher unaufhaltsam.
• Hardware-Wechsel (CPU → GPU): Die komplette AMD-ROCm-Variante für die RX 7900 XT findest du weiter oben in § GPU-Alternative. Für Nvidia-GPUs gilt: das CPU-Image beibehalten und die GPU-Runtime aktivieren (deploy.resources.reservations.devices mit driver: nvidia). In beiden Fällen OMP_NUM_THREADS reduzieren bzw. entfernen – die GPU übernimmt die Rechenarbeit.

Fehlerbehebung: Die häufigsten Stolperfallen

Fazit

Ollama und Open WebUI sind aktuell die unkomplizierteste Möglichkeit, eine eigene KI auf der eigenen Hardware zu betreiben – und die einzige, bei der wirklich jeder Prompt bei dir bleibt. Die Konfiguration in diesem Artikel ist bewusst defensiv ausgelegt: lokale Bindung aller Ports, harte Ressourcen-Limits, ein Modell zur Zeit. Wer die Stellschrauben aus der Tabelle oben versteht, kann den Stack später in jede Richtung skalieren – von der kleinen Familien-Instanz bis zur GPU-beschleunigten Multi-User-Umgebung.