Diese Anleitung zeigt Dir Schritt für Schritt, wie Du LocalAI mit Docker als lokalen, OpenAI-kompatiblen KI-Server betreibst. LocalAI (mudler/LocalAI) ist eine quelloffene KI-Engine und ein echter OpenAI-API-Drop-in: Er stellt aus einem einzigen Container Text/LLMs, Embeddings, Bildgenerierung sowie Audio (TTS und STT) bereit. Damit ist LocalAI breiter aufgestellt als Ollama, das im Kern auf Text-Chat zielt – LocalAI ersetzt die OpenAI-API über mehrere Modalitäten hinweg. Bestehende Tools, die gegen die OpenAI-API sprechen, lassen sich oft ohne Codeänderung umlenken: Du tauschst nur die Base-URL gegen http://DEIN-SERVER:8080/v1. Zielgruppe sind Admins im Mittelstand und ambitionierte Heimserver-Nutzer auf einem Linux-Server mit Docker und Docker Compose (Debian 12 oder Ubuntu 24.04).

Kurzfassung: Standard-Image (ohne Modelle) wählen, Port 8080 mappen, Volumes für /models und /data mounten und einen API-Key setzen. Die drei Kernbefehle:

docker run -ti --name local-ai -p 8080:8080 localai/localai:latest-cpu  # Schnelltest (CPU)
docker compose up -d                        # Stack im Hintergrund starten
docker compose pull && docker compose up -d # Update einspielen

Danach Web-UI unter http://SERVER-IP:8080 öffnen, im Tab Models ein Modell per 1-Klick installieren und die OpenAI-kompatible API unter http://SERVER-IP:8080/v1 nutzen.

Voraussetzungen

LocalAI läuft als einzelner Container. Was Du an Hardware brauchst, hängt stark davon ab, ob Du auf CPU oder GPU setzt und wie groß deine Modelle sind:

Betriebssystem: Linux-Server mit Docker und Docker Compose, z. B. Debian 12 oder Ubuntu 24.04.
CPU-Betrieb: funktioniert ohne GPU, ist bei LLMs aber spürbar langsamer. Plane je nach Modell mehrere GB RAM ein – große GGUF-Modelle brauchen entsprechend Hauptspeicher.
GPU-Betrieb (empfohlen für schnelles LLM-Serving und Bildgenerierung): eine NVIDIA-GPU mit ausreichend VRAM plus passendem GPU-Image und installiertem nvidia-container-toolkit. Mehr dazu in Schritt 6.
Storage: ausreichend Plattenplatz. AIO-Images sind mehrere GB groß, und GGUF-Modelle belegen oft mehrere GB pro Modell. Die Modelle landen im /models-Volume.
Netzwerk/Domain: Der Container lauscht auf Port 8080. Für den Zugriff von außen brauchst Du eine Domain und idealerweise einen Reverse-Proxy mit HTTPS (Schritt 7). LocalAI läuft per Default OHNE Authentifizierung.

Docker-Grundlagen setzen wir voraus. Wenn Du beim Aufbau von Compose-Stacks noch unsicher bist, hilft Dir vorab die Anleitung Docker Compose: Grundlagen und Stacks.

Schritt 1: Image-Strategie verstehen (Standard vs. AIO, CPU vs. GPU)

Bevor Du startest, solltest Du die Image-Varianten kennen. LocalAI gibt es in zwei Repos mit identischen Tags: Docker Hub localai/localai und Quay quay.io/go-skynet/local-ai. Wir nutzen durchgängig Docker Hub.

Bei den Images unterscheidest Du zwei Linien:

Standard-Images (OHNE Modelle): schlank, Modelle lädst Du selbst über die Gallery, die Web-UI oder die API nach. Tags u. a. localai/localai:latest-cpu (CPU), latest-gpu-nvidia-cuda-12, latest-gpu-nvidia-cuda-13 (NVIDIA), latest-gpu-hipblas (AMD ROCm), latest-gpu-intel (Intel), latest-gpu-vulkan sowie latest-nvidia-l4t-arm64 (Jetson).
AIO-Images (MIT vorinstallierten Modellen, groß): z. B. latest-aio-cpu, latest-aio-gpu-nvidia-cuda-12, latest-aio-gpu-nvidia-cuda-13, latest-aio-gpu-intel, latest-aio-gpu-hipblas. Sie bringen Modelle unter OpenAI-Namen mit: gpt-4 (Chat), gpt-4-vision-preview (Vision), text-embedding-ada-002 (Embeddings), whisper-1 (STT), tts-1 (TTS) und stablediffusion (Bildgenerierung). Das AIO-Image erkennt Hardware und VRAM automatisch und wählt ein Profil (cpu, gpu-8g, intel).

Stabilität: Statt latest solltest Du in Produktion einen festen Versions-Tag pinnen, z. B. localai/localai:v4.3.6-cpu bzw. v4.3.6-aio-cpu (aktuelle Major ist 4.x, Stand Mai 2026: 4.3.x). Die master-Tags sind Entwicklungs-Builds und können sich jederzeit ändern.

Schritt 2: Schnelltest mit docker run

Für einen ersten Eindruck reicht ein einziger Befehl. Damit prüfst Du, dass Image-Download, Container-Start und Web-UI funktionieren:

# CPU-Schnellstart, Standard-Image ohne Modelle:
docker run -ti --name local-ai -p 8080:8080 localai/localai:latest-cpu

Möchtest Du sofort vorkonfigurierte Modelle (gpt-4, Embeddings, whisper-1, tts-1, stablediffusion) ausprobieren, nimm das AIO-CPU-Image. Es ist groß und braucht beim ersten Start Geduld:

# AIO-CPU, batteries included (gross, langer Erststart):
docker run -ti --name local-ai -p 8080:8080 localai/localai:latest-aio-cpu

Hast Du den Container mit Strg+C gestoppt, startest Du ihn so wieder:

docker start -i local-ai

Dieser Schnelltest nutzt noch KEIN persistentes Volume. Für den Dauerbetrieb gehst Du zu Schritt 3 über – sonst sind heruntergeladene Modelle nach einem Container-Neustart oder Image-Update weg.

Schritt 3: Verzeichnis und compose.yaml anlegen

Lege auf dem Server ein Projektverzeichnis an:

mkdir -p $HOME/localai
cd $HOME/localai

Erstelle nun die compose.yaml. Die folgende Datei ist vollständig und lauffähig. Sie nutzt das schlanke CPU-Image, drei benannte Volumes für die Persistenz (Modelle, Daten, Backends) und schützt die API per LOCALAI_API_KEY. Für Produktion pinnst Du statt latest-cpu einen festen Tag wie v4.3.6-cpu.

services:
  local-ai:
    image: localai/localai:latest-cpu   # fuer Prod festen Tag pinnen, z. B. v4.3.6-cpu
    container_name: local-ai
    restart: unless-stopped
    ports:
      - "8080:8080"
    environment:
      - MODELS_PATH=/models
      - THREADS=4
      - CONTEXT_SIZE=4096
      - LOCALAI_API_KEY=BITTE-EIGENEN-KEY-SETZEN
      # - DEBUG=true
    volumes:
      - localai-models:/models
      - localai-data:/data
      - localai-backends:/backends
volumes:
  localai-models:
  localai-data:
  localai-backends:

Was die wichtigsten Umgebungsvariablen bedeuten:

MODELS_PATH=/models – legt das Modellverzeichnis im Container fest; passend dazu mountest Du das localai-models-Volume dorthin.
THREADS – Anzahl der CPU-Threads für die Inferenz; an deine CPU anpassen.
CONTEXT_SIZE – Kontextfenster der LLMs. Zu große Werte erhöhen den RAM-/VRAM-Bedarf und können zu OOM-Abbrüchen führen.
LOCALAI_API_KEY – schützt die API per Bearer-Token. Lass dieses Feld NICHT leer, wenn der Server erreichbar ist.
DEBUG=true – optional für ausführliche Logs bei der Fehlersuche.

Weitere nützliche Variablen sind GALLERIES (JSON-Array zusätzlicher Modell-Galleries, auch file:// innerhalb des models-Verzeichnisses) und PRELOAD_MODELS (JSON-Array, das Modelle bereits beim Start lädt).

Schritt 4: API-Key setzen und Stack starten

Erzeuge einen langen, zufälligen API-Key und trage ihn in die compose.yaml bei LOCALAI_API_KEY ein:

openssl rand -hex 32

Starte den Stack im Hintergrund und prüfe, dass der Container läuft:

docker compose up -d
docker compose ps
docker compose logs -f local-ai   # Logs live mitlesen, mit Strg+C beenden

Ist der API-Key gesetzt, musst Du ihn bei jedem API-Aufruf als Bearer-Token mitschicken. Ein erster Test, ob die OpenAI-kompatible Chat-Completion antwortet (Modellname an ein in LocalAI installiertes/gemapptes Modell anpassen):

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer BITTE-EIGENEN-KEY-SETZEN" \
  -d '{"model": "gpt-4", "messages": [{"role": "user", "content": "Hallo, wie geht es dir?"}], "temperature": 0.1}'

Schritt 5: Web-UI-Ersteinrichtung und Modelle laden

Öffne http://SERVER-IP:8080 im Browser. Du landest auf der Web-UI, die zugleich die OpenAI-kompatible API unter /v1 bereitstellt. Wenn Du das schlanke latest-cpu-Image nutzt, sind anfangs noch keine Modelle vorhanden – die lädst Du jetzt:

Über die Model-Gallery (empfohlen): Wechsle in der Web-UI in den Tab Models. Dort siehst Du installierbare Modelle inklusive Download-Größe und VRAM-Bedarf und installierst sie per 1-Klick.
Über die API: Du kannst Gallery-Modelle auch per POST /models/apply installieren. Beispiel für ein Embedding-Modell:

curl http://localhost:8080/models/apply \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer BITTE-EIGENEN-KEY-SETZEN" \
  -d '{"id": "localai@bert-embeddings"}'

Alternativ lädst Du ein GGUF-Modell direkt über URI-Schemata wie huggingface://, ollama:// oder file:// bzw. legst die Datei manuell ins /models-Volume. Mit der CLI sieht das so aus:

# GGUF direkt von HuggingFace laden/starten:
local-ai run huggingface://TheBloke/phi-2-GGUF/phi-2.Q8_0.gguf

Die Modelle landen dank Volume dauerhaft in /models und überleben Neustarts und Updates. Welche Modelle installiert/gemappt sind, listet der Endpunkt GET /v1/models; die in der Gallery verfügbaren liefert GET /models/available.

Schritt 6: GPU-Betrieb mit NVIDIA aktivieren

Für schnelles LLM-Serving und Bildgenerierung lohnt sich eine GPU. Auf dem Host brauchst Du dafür den passenden NVIDIA-Treiber und das nvidia-container-toolkit. Wähle anschließend das passende GPU-Image: latest-gpu-nvidia-cuda-12 oder latest-gpu-nvidia-cuda-13. Wichtig: Die CUDA-12- und CUDA-13-Images haben unterschiedliche Ubuntu-Basis und Treiberanforderungen – bei älteren NVIDIA-Treibern nimm das cuda-12-Image.

Ein schneller Test per docker run mit GPU-Zugriff:

# NVIDIA-GPU (CUDA 12), Standard-Image, braucht nvidia-container-toolkit:
docker run -ti --name local-ai -p 8080:8080 --gpus all localai/localai:latest-gpu-nvidia-cuda-12

In der compose.yaml setzt Du den Image-Tag auf eine GPU-Variante und reservierst die GPU über die deploy-Sektion:

services:
  local-ai:
    image: localai/localai:latest-gpu-nvidia-cuda-12
    container_name: local-ai
    restart: unless-stopped
    ports:
      - "8080:8080"
    environment:
      - MODELS_PATH=/models
      - LOCALAI_API_KEY=BITTE-EIGENEN-KEY-SETZEN
    volumes:
      - localai-models:/models
      - localai-data:/data
      - localai-backends:/backends
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia   # bzw. 'nvidia.com/gpu' (CDI) bei neuem Container-Toolkit
              count: all
              capabilities: [gpu]
volumes:
  localai-models:
  localai-data:
  localai-backends:

Für andere Hersteller gilt: AMD per latest-gpu-hipblas mit --device=/dev/kfd --device=/dev/dri --group-add=video, Intel per latest-gpu-intel mit --device=/dev/dri/.... Setzt Du den falschen Image-Tag oder fehlt das Toolkit, läuft alles still auf der CPU (langsam) oder der Container findet die GPU gar nicht.

Schritt 7: Reverse-Proxy und HTTPS

Per Default hat LocalAI KEIN Login und KEIN Passwort. Setzt Du keinen LOCALAI_API_KEY und kein LOCALAI_AUTH, ist die API komplett offen. Exponiere Port 8080 deshalb NIE ungeschützt ins Internet. Stelle der Instanz einen Reverse-Proxy mit TLS voran, der nach außen auf 443 lauscht und intern an 127.0.0.1:8080 weiterleitet. Beispiel für nginx:

server {
    listen 443 ssl;
    server_name DEINE-DOMAIN.de;

    ssl_certificate     /etc/letsencrypt/live/DEINE-DOMAIN.de/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/DEINE-DOMAIN.de/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 600s;   # LLM-Antworten koennen dauern
    }
}

Damit die API nicht mehr direkt erreichbar ist, binde das Port-Mapping in der compose.yaml an die Loopback-Adresse: - "127.0.0.1:8080:8080". Kombiniere das mit gesetztem LOCALAI_API_KEY. Brauchst Du Multi-User mit Rollen, aktiviere zusätzlich LOCALAI_AUTH=true (OIDC plus API-Keys, ab 4.x). Eine Firewall vor dem Server gehört ohnehin dazu.

Schritt 8: LocalAI als Backend für Chat-UIs

Weil LocalAI OpenAI-kompatibel ist, kannst Du es als Backend für Chat-Oberflächen wie LibreChat oder AnythingLLM nutzen. Trage dort als OpenAI-Base-URL http://DEIN-LOCALAI-HOST:8080/v1 ein und – falls gesetzt – den LOCALAI_API_KEY als API-Key. Der in der UI gewählte Modellname muss einem in LocalAI installierten oder gemappten Modell entsprechen (im AIO-Image z. B. gpt-4).

Die wichtigsten OpenAI-kompatiblen Endpunkte im Überblick:

Funktion	Endpunkt
Chat	`/v1/chat/completions`
Completion	`/v1/completions`
Embeddings	`/v1/embeddings`
Bildgenerierung	`/v1/images/generations`
Transkription (STT/Whisper)	`/v1/audio/transcriptions`
Sprachausgabe (TTS)	`/v1/audio/speech`
Modell-Liste	`/v1/models`

Ein Beispiel für Bildgenerierung (funktioniert mit dem AIO-Image über stablediffusion):

curl http://localhost:8080/v1/images/generations \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer BITTE-EIGENEN-KEY-SETZEN" \
  -d '{"prompt": "A cute baby sea otter", "size": "256x256"}'

Schritt 9: Update-Workflow und Backup

Ein Update besteht aus zwei Befehlen. Dank der Volumes bleiben Modelle und Konfiguration erhalten:

docker compose pull && docker compose up -d

Sichere vor jedem Update die benannten Volumes – dort liegen deine Modelle und die Konfiguration. Das geht über einen Hilfscontainer, der das Volume in ein Tar-Archiv packt:

docker run --rm \
  -v localai-models:/models \
  -v $(pwd):/backup \
  alpine tar czf /backup/localai-models.tar.gz -C /models .

Wiederhole das analog für localai-data und localai-backends. Mit diesen Archiven stellst Du die Instanz jederzeit auf einem anderen Host wieder her, ohne alle Modelle erneut herunterladen zu müssen.

Troubleshooting

Modelle nach Update/down weg: Es war kein Volume auf /models (bzw. MODELS_PATH) gemountet. Mounte das localai-models-Volume wie in der compose.yaml und lade die Modelle einmalig neu.
GPU wird nicht genutzt: Falscher Image-Tag oder fehlendes Toolkit. NVIDIA braucht ein cuda-12- ODER cuda-13-Image passend zum Host-Treiber plus installiertes nvidia-container-toolkit und --gpus all bzw. die deploy-Reservierung. Bei alten Treibern das cuda-12-Image wählen.
Erststart sehr zäh: Vermutlich ein AIO-Image, das beim ersten Start mehrere GB Modelle lädt. Für einen sauberen, schnellen Start besser latest-cpu plus eigenes /models-Volume nehmen.
OOM / Container stürzt ab: RAM/VRAM oder Disk unterdimensioniert. Wähle eine kleinere Quantisierung, reduziere CONTEXT_SIZE oder nimm ein kleineres Modell.
Falscher Imagename: Quay nutzt quay.io/go-skynet/local-ai, Docker Hub localai/localai. Die offizielle docker-compose.yaml im Repo verweist teils noch auf den go-skynet/master-Tag – Imagename und Tag bewusst anpassen.
API antwortet mit 401/Unauthorized: Es ist ein LOCALAI_API_KEY gesetzt. Schicke ihn als Authorization: Bearer ...-Header mit.

Häufige Fragen

Worin unterscheidet sich LocalAI von Ollama?

LocalAI ist breiter aufgestellt: Es liefert Text/LLMs, Embeddings, Bildgenerierung UND Audio (TTS/STT) als echten OpenAI-API-Ersatz aus einem Container. Ollama fokussiert auf Text-Chat. Wenn Du nur ein lokales Chat-LLM willst, schau Dir Ollama mit Open WebUI per Docker an; brauchst Du den vollen OpenAI-Drop-in über mehrere Modalitäten, ist LocalAI die richtige Wahl.

Brauche ich zwingend eine GPU?

Nein. LocalAI läuft auf CPU. Für schnelles LLM-Serving und Bildgenerierung ist eine NVIDIA-GPU mit nvidia-container-toolkit aber deutlich angenehmer. Auf der CPU funktioniert alles, nur langsamer.

Soll ich das AIO-Image oder das schlanke Image nehmen?

Für einen sauberen Start empfiehlt die Doku das schlanke latest-cpu-Image plus eigenes /models-Volume. Das AIO-Image ist bequem, weil gpt-4, Embeddings, whisper-1, tts-1 und stablediffusion vorkonfiguriert sind – es ist aber mehrere GB groß und lädt beim Erststart viel nach.

Wie lade ich Modelle in LocalAI?

Am einfachsten über die Model-Gallery im Tab Models der Web-UI (1-Klick, mit Anzeige von Download-Größe und VRAM-Bedarf). Alternativ per POST /models/apply, über URIs wie huggingface:///ollama:///file:// oder durch manuelles Ablegen einer GGUF-Datei im /models-Volume.

Kann ich bestehende OpenAI-Tools umlenken?

Ja, das ist der Kern von LocalAI. Setze in der Anwendung die OpenAI-Base-URL auf http://DEIN-SERVER:8080/v1 und – falls gesetzt – den LOCALAI_API_KEY als API-Key. Der Modellname muss zu einem in LocalAI vorhandenen Modell passen.

Ist LocalAI nach dem Start abgesichert?

Nein, per Default nicht. Ohne LOCALAI_API_KEY bzw. LOCALAI_AUTH=true ist die API offen. Setze mindestens einen API-Key, binde den Port an 127.0.0.1 und stelle einen Reverse-Proxy mit TLS sowie eine Firewall davor (Schritt 7).

Fazit

Mit LocalAI und Docker hast Du in unter einer halben Stunde einen vollwertigen, OpenAI-kompatiblen KI-Server am Laufen – aus genau einem Container, der Chat, Embeddings, Bild und Audio bedient. Entscheidend für den Dauerbetrieb sind drei Dinge: die Volumes für /models und /data mounten, einen LOCALAI_API_KEY setzen und die Instanz hinter Reverse-Proxy plus Firewall absichern. CPU funktioniert sofort; für Tempo bei LLMs und Bildgenerierung rüstest Du eine NVIDIA-GPU mit dem passenden cuda-Image und dem nvidia-container-toolkit nach. Weil LocalAI ein echter OpenAI-Drop-in ist, lenkst Du bestehende Tools einfach auf http://DEIN-SERVER:8080/v1 um und bleibst trotzdem komplett im eigenen Haus.

Weiterführende Anleitungen und Quellen

Passende Anleitungen aus unserem Wissensbereich:

Docker Compose: Grundlagen und Stacks – Basis für die hier verwendete compose.yaml.
Ollama mit Open WebUI per Docker – die schlankere Alternative für reines Text-Chat-LLM.
Offene LLMs mit vLLM selbst hosten – High-Throughput-Inferenz für große Modelle.
Alle Anleitungen der Kategorie Künstliche Intelligenz

Quellen (offizielle Doku/Repo, Stand 2026):