Wer mehrere KI-Provider nutzt, etwa OpenAI, Anthropic und ein lokales Ollama-Modell, verteilt schnell API-Keys auf viele Anwendungen und verliert den Überblick über die Kosten. LiteLLM Proxy stellt eine einheitliche, OpenAI-kompatible REST-API vor alle Provider; bestehende SDKs und Tools laufen ohne Codeänderung weiter. Dazu kommen Virtual Keys, Team-Budgets und Kostenerfassung über eine Admin-UI. Diese Anleitung richtet LiteLLM mit Docker Compose, PostgreSQL und Admin-UI auf einem Linux-Host ein.

Voraussetzungen

Docker Engine ab 24 und Docker Compose Plugin ab 2.20 auf einem Linux-Host, einer VM oder einem NAS; die Installation beschreibt Docker und Docker Compose auf Linux installieren (Ubuntu/Debian).
Mindestens 1 vCPU und 4 GB RAM je Worker (offizielle Empfehlung) plus rund 2 GB Speicherplatz für Images und Datenbank.
API-Key eines LLM-Providers, zum Beispiel OpenAI (sk-...) oder Anthropic (sk-ant-...).
Für Zugriff aus dem Netz: ein Reverse Proxy mit HTTPS, z. B. Traefik.
openssl für Zufallswerte.

Schritt 1: Projektordner anlegen

Legen Sie einen eigenen Ordner für alle LiteLLM-Dateien an:

sudo mkdir -p /opt/litellm
sudo chown $USER: /opt/litellm
cd /opt/litellm

Verifizieren: pwd gibt /opt/litellm aus. Alle folgenden Dateien liegen in diesem Ordner.

Schritt 2: Secrets und Umgebungsvariablen in .env

Die .env-Datei enthält alle vertraulichen Werte und gehört nie in ein Git-Repository. Erzeugen Sie zwei Zufallswerte:

openssl rand -hex 32   # für LITELLM_MASTER_KEY (mit sk- präfixen!)
openssl rand -hex 32   # für LITELLM_SALT_KEY

Legen Sie danach /opt/litellm/.env an und setzen Sie die Rechte mit chmod 600 .env:

# LiteLLM Master Key – MUSS mit sk- beginnen
LITELLM_MASTER_KEY=sk-ihr-zufallswert

# Salt Key – verschlüsselt alle in der DB gespeicherten Provider-Keys
# WARNUNG: Diesen Wert NIEMALS nach dem ersten Start ändern!
LITELLM_SALT_KEY=ihr-zweiter-zufallswert

# Admin-UI Zugangsdaten
UI_USERNAME=admin
UI_PASSWORD=ihr-ui-passwort

# PostgreSQL-Zugangsdaten
POSTGRES_USER=llmproxy
POSTGRES_PASSWORD=ihr-db-passwort
POSTGRES_DB=litellm

# LLM-Provider-Keys (nur die tatsächlich genutzten)
OPENAI_API_KEY=sk-proj-ihr-openai-key
ANTHROPIC_API_KEY=sk-ant-ihr-anthropic-key

Wichtige Hinweise zu den Werten:

LITELLM_MASTER_KEY muss exakt mit sk- beginnen – sonst schlägt die Key-Generierung und die UI-Authentifizierung fehl.
LITELLM_SALT_KEY verschlüsselt alle in der Datenbank gespeicherten Provider-Credentials. Ändern Sie den Wert nach dem ersten Start, werden alle gespeicherten Keys unlesbar.
UI_USERNAME und UI_PASSWORD legen den Admin-Login fest. Ohne sie meldet sich die UI mit dem Benutzer admin und dem Master Key als Passwort an; ein eigenes Passwort trennt UI-Login und API-Schlüssel.

Verifizieren: grep -c "=$" .env gibt 0 aus (kein leerer Wert), grep ^LITELLM_MASTER_KEY=sk- .env findet die Zeile, ls -l .env zeigt -rw-------.

Schritt 3: Modell-Konfiguration in litellm_config.yaml

Die litellm_config.yaml definiert, welche Modelle der Proxy anbietet. Provider-Keys referenzieren Sie über os.environ/VARIABLENNAME, nie als Klartext. Das Beispiel bindet je ein aktuelles Modell von OpenAI und Anthropic ein (Stand September 2026; aktuelle Modellnamen nennt die jeweilige Provider-Dokumentation):

model_list:
  - model_name: gpt-5.4-mini
    litellm_params:
      model: openai/gpt-5.4-mini
      api_key: os.environ/OPENAI_API_KEY

  - model_name: claude-sonnet
    litellm_params:
      model: anthropic/claude-sonnet-4-6
      api_key: os.environ/ANTHROPIC_API_KEY

  # Lokales Ollama-Modell (kein API-Key nötig)
  # - model_name: llama3
  #   litellm_params:
  #     model: ollama/llama3
  #     api_base: http://host.docker.internal:11434
  #     (auf Linux zusätzlich extra_hosts: "host.docker.internal:host-gateway" im Dienst)

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY

Mit STORE_MODEL_IN_DB=True (siehe compose.yaml) fügen Sie weitere Modelle auch über die Admin-UI hinzu, ohne Neustart. Die Datei muss trotzdem existieren, bevor der Container startet; sonst legt Docker an ihrer Stelle ein Verzeichnis an. Callbacks wie Prometheus oder Langfuse gehören in derselben Datei in den Block litellm_settings: (z. B. callbacks: ["prometheus"]), nicht unter general_settings.

Verifizieren: python3 -c "import yaml;print(yaml.safe_load(open('litellm_config.yaml'))['model_list'][0]['model_name'])" gibt den ersten Modellnamen aus; bei Einrückungsfehlern bricht der Befehl mit einer Fehlermeldung ab.

Schritt 4: Docker-Compose-Stack definieren

Die compose.yaml definiert zwei Dienste: den LiteLLM-Proxy und PostgreSQL 16. LiteLLM startet per depends_on: condition: service_healthy erst, wenn die Datenbank bereit ist.

Eckdaten auf einen Blick

Eigenschaft	Wert	Hinweis
Image	`ghcr.io/berriai/litellm:v1.106.0`	amd64 und arm64; Stand Oktober 2026, Spiegel: `docker.litellm.ai/berriai/litellm`
Port	127.0.0.1:4000	API und Admin-UI (`/ui`, `/health`)
Config-Volume	`./litellm_config.yaml:/app/config.yaml`	Pflicht; muss vor Start existieren
DB-Volume	`litellm_postgres_data` (benannt)	PostgreSQL-Datenpersistenz
Hardware	1 vCPU, 4 GB RAM je Worker	Offizielle Empfehlung

Legen Sie /opt/litellm/compose.yaml an:

services:
  litellm:
    image: ghcr.io/berriai/litellm:v1.106.0
    container_name: litellm
    restart: unless-stopped
    ports:
      - "127.0.0.1:4000:4000"
    volumes:
      - ./litellm_config.yaml:/app/config.yaml
    command: ["--config", "/app/config.yaml"]
    env_file:
      - .env
    environment:
      DATABASE_URL: "postgresql://${POSTGRES_USER}:${POSTGRES_PASSWORD}@db:5432/${POSTGRES_DB}"
      LITELLM_MASTER_KEY: "${LITELLM_MASTER_KEY}"
      LITELLM_SALT_KEY: "${LITELLM_SALT_KEY}"
      STORE_MODEL_IN_DB: "True"
      UI_USERNAME: "${UI_USERNAME}"
      UI_PASSWORD: "${UI_PASSWORD}"
    depends_on:
      db:
        condition: service_healthy
    healthcheck:
      # Image enthält kein curl, daher Python
      test: ["CMD-SHELL", "python3 -c \"import urllib.request; urllib.request.urlopen('http://localhost:4000/health/liveliness')\""]
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 60s

  db:
    image: postgres:16.10
    container_name: litellm-postgres
    restart: unless-stopped
    environment:
      POSTGRES_USER: "${POSTGRES_USER}"
      POSTGRES_PASSWORD: "${POSTGRES_PASSWORD}"
      POSTGRES_DB: "${POSTGRES_DB}"
    volumes:
      - litellm_postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -d ${POSTGRES_DB} -U ${POSTGRES_USER}"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 20s

volumes:
  litellm_postgres_data:

Der Port ist an 127.0.0.1 gebunden. Für Zugriff aus dem Netz schalten Sie einen Reverse Proxy mit HTTPS vor; die Datenbank bleibt ohne Portfreigabe im internen Compose-Netz.

Beim ersten Start führt LiteLLM Datenbankmigrationen aus (30 bis 90 Sekunden); start_period: 60s berücksichtigt das, auf langsamer Hardware setzen Sie 120s.

Verifizieren: docker compose config --quiet gibt keine Fehlermeldung aus; ls -a zeigt .env, compose.yaml und litellm_config.yaml.

Schritt 5: Stack starten

Starten Sie alle Dienste im Hintergrund:

cd /opt/litellm
docker compose up -d

Docker lädt die Images (rund 1,5 bis 2 GB), legt das Volume an und startet PostgreSQL; danach startet LiteLLM und migriert die Datenbank. Den Start verfolgen Sie so:

docker compose logs -f litellm

Typische Ausgabe nach erfolgreichem Start:

litellm  | INFO:     Application startup complete.
litellm  | INFO:     Uvicorn running on http://0.0.0.0:4000 (Press CTRL+C to quit)

Verifizieren: Prüfen Sie den Status beider Container:

docker compose ps
# NAME               IMAGE                                          STATUS
# litellm            ghcr.io/berriai/litellm:v1.106.0               Up (healthy)
# litellm-postgres   postgres:16.10                                   Up (healthy)

Beide Container müssen den Status Up (healthy) zeigen. Steht LiteLLM noch auf starting, warten Sie 60 bis 90 Sekunden. Dann testen Sie den Liveness-Endpunkt:

curl -s http://localhost:4000/health/liveliness
# Erwartete Ausgabe: "I'm alive!"

Schritt 6: Admin-UI und erste API-Tests

Öffnen Sie http://localhost:4000/ui auf dem Host oder über einen SSH-Tunnel (ssh -L 4000:127.0.0.1:4000 benutzer@HOST-IP) und melden Sie sich mit UI_USERNAME und UI_PASSWORD an. In der Admin-UI:

Virtual Keys generieren – individuelle API-Keys für Nutzer, Teams oder Applikationen mit eigenen Budget-Limits
Modelle verwalten – neue Provider hinzufügen ohne Container-Neustart (dank STORE_MODEL_IN_DB=True)
Usage und Spend einsehen – Kosten je Key, Benutzer und Team, berechnet aus der Modell-Preistabelle von LiteLLM
Rate Limits setzen – maximale Requests pro Minute oder Token-Budgets pro Zeitraum

Testen Sie die API mit curl; setzen Sie für sk-ihr-master-key Ihren LITELLM_MASTER_KEY oder einen Virtual Key ein:

curl -s http://localhost:4000/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk-ihr-master-key" \
  -d '{
    "model": "gpt-5.4-mini",
    "messages": [{"role": "user", "content": "Sag kurz Hallo auf Deutsch."}]
  }' | python3 -m json.tool

Bestehende OpenAI-SDK-Integrationen stellen Sie um, indem Sie zwei Parameter ändern:


from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:4000",   # LiteLLM statt api.openai.com
    api_key="sk-ihr-virtual-key",       # Virtual Key aus der Admin-UI
)

Verifizieren: Der curl-Test gibt eine JSON-Antwort mit "role": "assistant" zurück. Im Browser lädt die Admin-UI unter http://localhost:4000/ui das Dashboard nach dem Login. Die Logs zeigen den eingehenden Request:

docker compose logs --tail=20 litellm
# ... "POST /chat/completions HTTP/1.1" 200 OK

Schritt 7: Wartung – Updates und Backup

LiteLLM veröffentlicht mehrmals pro Woche neue Versionen. Sichern Sie vor jedem Update die Datenbank:

docker exec litellm-postgres pg_dump \
  -U llmproxy litellm > /opt/litellm/backup_$(date +%Y%m%d).sql

Lesen Sie dann die Release Notes auf GitHub, tragen Sie den neuen Tag in die compose.yaml ein und starten Sie neu. Datenbankmigrationen laufen beim Start automatisch:

cd /opt/litellm
docker compose pull
docker compose up -d

Beispiel Update von v1.104.0 auf v1.105.1: An compose.yaml, .env und litellm_config.yaml ändert sich nichts. Beim ersten Start spielt LiteLLM die neuen Datenbankmigrationen ein (im Test unter anderem add_daily_model_usage und agent_engine); das Log endet mit All migrations have been successfully applied. und Application startup complete. Neu in 1.105 ist unter anderem, dass die SSO-Debug-Routen /sso/debug/* nur noch mit ENABLE_SSO_DEBUG erreichbar sind und Fehlermeldungen bei 422-Validierungsfehlern den gesendeten Request-Body nicht mehr enthalten; 1.105.1 ist ein Fehlerbehebungs-Release für den Proxy. Am 14.10.2026 wurde dieses Update auf einem Debian-Testhost mit genau diesem Stack nachgestellt: Ein vorher angelegter Virtual Key war danach weiter gültig, /v1/models lieferte ohne Key und mit falschem Key 401, mit Master-Key beide Modelle, und die UI-Anmeldung über /v2/login funktionierte mit dem Passwort aus der .env. Beim Update von v1.105.1 auf v1.106.0 ändert sich an den drei Dateien ebenfalls nichts. Das Release schaltet MCP-Server mit stdio-Transport standardmäßig ab (wer sie nutzt, muss sie nach den Release Notes wieder ausdrücklich freigeben), beendet den Proxy, wenn DATABASE_URL gesetzt ist, aber die Prisma-Werkzeuge fehlen, und speichert die Parameter von Guardrails und Such-Tools verschlüsselt. Im Test am 19.10.2026 liefen die Migrationen durch, der Container war wieder healthy, ein vorher angelegter Virtual Key und ein Team blieben erhalten, /v1/models lieferte mit dem Virtual Key 200, ohne oder mit falschem Key 401, und pg_dump enthielt den Key-Alias.

Sichern Sie außerdem .env und litellm_config.yaml an einem sicheren Ort. Ohne den LITELLM_SALT_KEY aus der .env sind alle in der DB gespeicherten Provider-Keys nach einem Datenverlust unlesbar. Ein vollständiges Backup-Konzept für PostgreSQL-Daten beschreibt die Anleitung MySQL & PostgreSQL Backup automatisieren mit cron.

Verifizieren: docker compose ps zeigt wieder Up (healthy) mit dem neuen Tag. head -5 backup_*.sql zeigt den Kopf eines PostgreSQL-Dumps.

Troubleshooting / Typische Fehler

Error decrypting value – Did your master_key/salt key change recently?
Der LITELLM_SALT_KEY wurde nach dem ersten Start geändert. Setzen Sie ihn in der .env auf den ursprünglichen Wert zurück (aus dem Backup) und führen Sie docker compose up -d aus. Ist der alte Wert verloren, müssen Sie die gespeicherten Provider-Keys in der UI neu eintragen.
401 Unauthorized bei /key/generate
Der LITELLM_MASTER_KEY beginnt nicht mit sk-. In der .env korrigieren und docker compose up -d ausführen.
Config-Fehler beim Start, /app/config.yaml ist ein Verzeichnis
Die Datei litellm_config.yaml fehlte beim ersten Start, Docker hat ein Verzeichnis angelegt. docker compose down, das Verzeichnis entfernen, die Datei anlegen, neu starten.
LiteLLM startet vor PostgreSQL (Connection refused, Prisma-Fehler)
Der Block depends_on: condition: service_healthy fehlt oder start_period ist zu kurz. Auf langsamer Hardware start_period: 120s setzen.
Container bleibt unhealthy, obwohl die API antwortet
Der Healthcheck nutzt curl, das im Image fehlt. Den Python-Healthcheck aus Schritt 4 verwenden.
Prometheus-Metriken fehlen
Der Callback steht unter general_settings. Richtig ist litellm_settings: callbacks: ["prometheus"] in der litellm_config.yaml.

Häufige Fragen

Läuft LiteLLM ohne PostgreSQL?

Ja. Für einfache Proxy-Nutzung ohne Key-Management reicht ein minimales Setup ohne DATABASE_URL, LITELLM_SALT_KEY und den db-Service. Admin-UI und Virtual Keys stehen dann nicht zur Verfügung; für Tests genügt das.

Wie kommt ein neuer LLM-Provider hinzu?

Entweder als Eintrag unter model_list in der litellm_config.yaml mit anschließendem docker compose restart litellm, oder bei STORE_MODEL_IN_DB=True in der Admin-UI unter „Models“ ohne Neustart.

Wie werden bestehende OpenAI-SDK-Integrationen umgestellt?

Über base_url (Adresse des Proxys) und api_key (Virtual Key), siehe Schritt 6. Geben Sie Anwendungen Virtual Keys statt des Master Keys, damit Budgets greifen und Keys einzeln widerrufbar sind.

Wo stehen die Kosten je API-Aufruf?

In der Admin-UI im Bereich „Usage“, aufgeschlüsselt nach Key, Benutzer und Team. Per API liefert GET /spend/logs mit dem Master Key dieselben Daten. Die Werte sind Schätzungen aus der Preistabelle von LiteLLM; maßgeblich bleibt die Abrechnung des Providers.

Was kostet LiteLLM in der Open-Source-Version?

Die Open-Source-Version ist lizenzkostenfrei. Enterprise-Funktionen wie erweitertes SSO und Audit Logs setzen eine kommerzielle Lizenz voraus.

Wann ist Redis nötig?

Sobald mehrere LiteLLM-Instanzen laufen: Redis teilt dann Rate Limits, Budgets und Cache zwischen ihnen (router_settings in der litellm_config.yaml). Für eine einzelne Instanz ist Redis nicht erforderlich.

Wie lassen sich die Images prüfen?

Die offiziellen Images sind mit cosign signiert; das Verfahren beschreibt die LiteLLM-Dokumentation. Beziehen Sie Images nur von ghcr.io/berriai oder docker.litellm.ai/berriai und schreiben Sie die Version fest.

Fazit

Mit LiteLLM Proxy verwalten Sie KI-Provider-Zugriffe zentral: Anwendungen erhalten Virtual Keys statt Provider-Keys, Budgets gelten je Team oder Projekt, und ein Wechsel zwischen OpenAI, Anthropic und einem lokalen Ollama-Modell ist eine Konfigurationszeile. Bewahren Sie den LITELLM_SALT_KEY von Anfang an sicher auf; er darf sich nach dem ersten Start nicht ändern.

Für ein lokales Sprachmodell hinter LiteLLM eignet sich die Anleitung Ollama und Open WebUI mit Docker: eigenes lokales KI-Sprachmodell ohne Cloud betreiben. KI-Workflows mit LiteLLM als API-Schicht beschreibt n8n mit Docker: KI-Workflows und Automatisierung self-hosted.

Weiterführende Anleitungen und Quellen

Offizielle Quellen: LiteLLM Proxy Deployment Dokumentation · LiteLLM GitHub-Repository (BerriAI/litellm) · Virtual Keys & Cost Tracking · Config.yaml Struktur