LiteLLM-Gateway installieren: Docker, config.yaml, Virtual Keys, Cost-Tracking und Langfuse (Mai 2026)

Worum geht es hier?

Diese Anleitung baut einen produktiven LiteLLM-Proxy auf einem Linux-Server (Hetzner, AWS, Render – egal welcher Cloud). Sie installieren LiteLLM via Docker-Compose mit PostgreSQL als Audit-Backend, hinterlegen API-Keys für 3-5 LLM-Provider (OpenAI, Anthropic, Mistral, Gemini, Ollama), konfigurieren Virtual Keys mit Spend-Limit pro User/Team, richten Health-Checks und Langfuse-Tracing ein, und stellen das Ganze hinter einen nginx-Reverse-Proxy mit Auth-Middleware.

Die Anleitung ist für drei Zielgruppen geschrieben. Erstens: KMU, die mehrere LLM-Anbieter parallel nutzen wollen (z.B. Mistral für Mandantendaten, GPT-4o für offene Recherche, Claude Haiku für Code-Klassifikation). Zweitens: Treuhand- oder Anwaltskanzlei, die ein zentrales Audit-Log für alle KI-Anfragen braucht (Art. 957a OR). Drittens: Entwicklerteams, die Budgets pro Anwendung und pro Mandant brauchen (Pilot-Mandant CHF 50/Monat, Produktiv-Mandant CHF 500/Monat).

Voraussetzung: ein Linux-Server mit Docker (4 GB RAM, 2 vCPU reicht), eine Domain unter Cloudflare oder eigenem DNS, API-Keys von 3-5 Providern (mindestens OpenAI oder Anthropic, plus mindestens ein EU-Provider wie Mistral). Setup-Zeit: 3-5 Stunden netto. Kosten: Server CHF 5-10/Monat, kein LiteLLM-Lizenz-Kosten (Apache 2.0 Open Source).

Warum ein Gateway statt direkter Provider-Calls

Wer Anwendungen direkt gegen Provider-SDKs schreibt, baut technische Schulden in jedes Modul. Drei Probleme treten in jedem grösseren Setup auf, und LiteLLM löst sie an einer Stelle.

Erstens: Lock-in. OpenAI, Anthropic und Mistral haben unterschiedliche SDKs, unterschiedliche Token-Limits, unterschiedliche Fehlercodes. Eine Codebasis, die alle drei direkt anspricht, hat drei Fehlerquellen statt einer. Wenn der bevorzugte Anbieter teurer wird oder ausfällt, ist der Wechsel ein Refactor, kein Konfigurations-Eintrag. Mit LiteLLM ist der Provider eine Modell-Konfiguration in einer YAML – Anwendung bleibt unverändert.

Zweitens: Datenschutz-Routing. Eine CH-Treuhand darf Mandanten-PII nicht an US-Provider senden, kann aber anonymisierte Recherche-Anfragen problemlos an GPT-4o stellen. Ohne Gateway ist diese Regel im Code verteilt; mit LiteLLM steht sie zentral. Modellnamen wie mistral-eu-secure, claude-haiku-eu oder local-llama markieren die Stufe, der Proxy entscheidet das Routing. Eine Anwendung darf nur mit den für ihre Klasse erlaubten Modellnamen reden.

Drittens: Kosten und Beobachtbarkeit. Jeder Provider hat eigene Dashboards, eigene Abrechnungsfrequenz, eigene Modell-Preise. Eine Gesamtsicht über alle Anbieter – wer hat wie viel verbraucht, welcher Workflow kostet wie viel – lässt sich ohne Aggregations-Layer nicht erstellen. LiteLLM schreibt jeden Request mit Modell, Token, Kosten und Latenz in Postgres und exportiert Metriken an Prometheus.

Der vierte Punkt ist Spend-Limit pro User. Ein Pilot-Mandant bekommt CHF 50/Monat Budget, ein Produktiv-Mandant CHF 500, eine interne Recherche-Anwendung CHF 200. Wenn das Budget überschritten ist, blockt der Proxy weitere Requests automatisch – der Provider-Master-Key bleibt unberührt. Das ist die einzige saubere Variante, mehrere Mandanten oder Anwendungen ohne unkontrollierte Kosten-Explosionen zu betreiben.

Wie der Stack zusammenhängt

Die Architektur hat fünf Schichten: nginx-Reverse-Proxy mit TLS, LiteLLM-Proxy-Container, PostgreSQL für Audit-Log, Langfuse für Tracing, Prometheus + Grafana für Metriken.

nginx-Reverse-Proxy: terminiert TLS via Let's Encrypt-Zertifikat, leitet llm.ihre-domain.ch auf den LiteLLM-Container (port 4000) weiter. Optional Basic-Auth oder Cloudflare-Access-Tokens für zusätzliche Authentisierungs-Ebene.

LiteLLM-Proxy: ghcr.io/berriai/litellm-stable in der Version 1.50+ (Mai 2026 stable). Konfiguration in einer config.yaml mit drei zentralen Abschnitten. model_list: jedes Modell bekommt einen logischen Namen und ein Provider-Mapping. Beispiel: `model_name: mistral-eu-secure` verweist via `litellm_params: model: mistral/mistral-large-latest, api_key: os.environ/MISTRAL_API_KEY` auf Mistral La Plateforme. Ein zweiter Eintrag mit gleichem model_name kann auf eine Mistral-Instanz in Azure EU zeigen – Fallback-Gruppe. litellm_settings: globale Defaults wie set_verbose, drop_params, success_callback. general_settings: master_key (Admin-Token), database_url für Postgres, alerting.

Virtual Keys: über die Admin-UI oder die /key/generate-API werden Virtual Keys (sk-litellm-xyz) ausgestellt. Jeder Key hat: max_budget (z.B. 50.00 USD/Monat), models (Whitelist erlaubter Modelle), tpm_limit (Tokens pro Minute), rpm_limit (Requests pro Minute), team_id (Gruppierung). Anwendungen bekommen einen Virtual Key statt des Master-Keys.

PostgreSQL: drei zentrale Tabellen. spend_logs (eine Zeile pro Request mit Modell, Tokens, Kosten, Latenz, User, Team). users (User-Stammdaten mit Spend-Total). litellm_verificationtoken (Virtual-Key-Definitionen). Mit dieser Datenbasis kann Grafana pro Mandant zeigen, wie viel verbraucht wurde, welches Modell, zu welcher Zeit.

Langfuse: Open-Source-Observability-Tool für LLM-Apps. LiteLLM exportiert Prompt/Response per Callback an Langfuse – dort sieht man pro Request den vollständigen Prompt, die Antwort, Token-Zählung und Kosten. Wichtig für Debugging und Eval. Langfuse selbst ist self-host-fahig (Docker-Compose) oder als Cloud-Service erhältlich.

Prometheus + Grafana: LiteLLM exportiert /metrics-Endpoint mit Token-Counter, Cost-Counter, Latenz-Histogramm pro Modell und User. Prometheus-Scraper alle 30s, Grafana-Dashboards für "Top-10 Spender Modelle", "Latenz pro Provider", "Error-Rate pro Modell". Alerting bei Spike: Telegram-Notifikation, wenn ein User > 80% seines Monatsbudgets erreicht.

LiteLLM-Setup in 11 Schritten

1. 01Schritt 1 – Server und Domain vorbereiten: Hetzner CX22 (CHF 5/Monat), `apt update && apt install docker.io docker-compose-plugin`. Subdomain llm.ihre-domain.ch in Cloudflare als A-Record auf Server-IP, proxied (orange Wolke aus, für LiteLLM-Proxy nicht nötig).
2. 02Schritt 2 – Provider-API-Keys sammeln: OpenAI (platform.openai.com/api-keys), Anthropic (console.anthropic.com/settings/keys), Mistral (console.mistral.ai/api-keys), Gemini (aistudio.google.com/app/apikey), Ollama (lokaler Endpunkt http://ollama:11434 ohne Key). Mindestens 3 Keys empfohlen.
3. 03Schritt 3 – docker-compose.yml anlegen: `/opt/litellm/docker-compose.yml` mit drei Services: traefik (oder nginx, port 80/443), postgres (image postgres:17-alpine, POSTGRES_DB=litellm), litellm (image ghcr.io/berriai/litellm-stable:main-stable, depends_on postgres, command `--config /app/config.yaml`).
4. 04Schritt 4 – .env mit Secrets: `/opt/litellm/.env`: `OPENAI_API_KEY=sk-...`, `ANTHROPIC_API_KEY=sk-ant-...`, `MISTRAL_API_KEY=...`, `GEMINI_API_KEY=AIza...`, `LITELLM_MASTER_KEY=sk-1234-master-...` (selbst generiert via `openssl rand -hex 32`), `DATABASE_URL=postgres://litellm:pw@postgres:5432/litellm`, `LITELLM_SALT_KEY=...`.
5. 05Schritt 5 – config.yaml schreiben: `/opt/litellm/config.yaml` mit model_list: ```yaml model_list: - model_name: gpt-4o-mini litellm_params: model: openai/gpt-4o-mini api_key: os.environ/OPENAI_API_KEY - model_name: claude-haiku litellm_params: model: anthropic/claude-3-5-haiku-20251022 api_key: os.environ/ANTHROPIC_API_KEY - model_name: mistral-eu litellm_params: model: mistral/mistral-large-latest api_key: os.environ/MISTRAL_API_KEY - model_name: gemini-flash litellm_params: model: gemini/gemini-2.0-flash api_key: os.environ/GEMINI_API_KEY - model_name: local-llama litellm_params: model: ollama/llama3.2:8b api_base: http://ollama:11434 general_settings: master_key: os.environ/LITELLM_MASTER_KEY database_url: os.environ/DATABASE_URL litellm_settings: success_callback: ["langfuse"] drop_params: true ```
6. 06Schritt 6 – Stack hochfahren: `cd /opt/litellm && docker compose up -d`. Logs prüfen: `docker logs litellm -f`. Erwartete Ausgabe: "LiteLLM Proxy started on port 4000", "Database connected", Modelle geladen. Prüfen: `curl http://localhost:4000/health/liveliness` → 200 OK.
7. 07Schritt 7 – Test-Request mit Master-Key: `curl http://localhost:4000/v1/chat/completions -H "Authorization: Bearer $LITELLM_MASTER_KEY" -H "Content-Type: application/json" -d '{"model":"claude-haiku","messages":[{"role":"user","content":"Hallo"}]}'`. Erwarte Antwort im OpenAI-Format mit Modell, Tokens, choices.
8. 08Schritt 8 – Virtual Key generieren: `curl http://localhost:4000/key/generate -H "Authorization: Bearer $LITELLM_MASTER_KEY" -H "Content-Type: application/json" -d '{"max_budget":50.0,"budget_duration":"30d","models":["mistral-eu","claude-haiku"],"team_id":"team-fairlane","user_id":"app-rag-pilot"}'`. Antwort enthält key wie `sk-litellm-abc...`. Diesen Key in der Anwendung als API-Key verwenden.
9. 09Schritt 9 – Langfuse-Tracing einrichten: Langfuse via Docker-Compose (https://github.com/langfuse/langfuse) im gleichen Netzwerk starten. Public + Secret Key in Langfuse-UI generieren. In LiteLLM .env: `LANGFUSE_PUBLIC_KEY=pk-...`, `LANGFUSE_SECRET_KEY=sk-...`, `LANGFUSE_HOST=http://langfuse:3000`. Restart LiteLLM. Jeder Request landet in Langfuse mit Prompt, Response, Tokens, Kosten.
10. 10Schritt 10 – nginx Reverse-Proxy mit TLS: nginx-Config in `/etc/nginx/sites-available/litellm`: `server { listen 443 ssl http2; server_name llm.ihre-domain.ch; ssl_certificate /etc/letsencrypt/live/llm.ihre-domain.ch/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/llm.ihre-domain.ch/privkey.pem; location / { proxy_pass http://localhost:4000; proxy_set_header Host $host; proxy_read_timeout 300s; } }`. `certbot --nginx -d llm.ihre-domain.ch`, dann `systemctl reload nginx`.
11. 11Schritt 11 – Monitoring und Spend-Alarme: Prometheus-Scraper auf `http://litellm:4000/metrics`, Grafana-Dashboard mit Panels "Spend per User", "Latency per Model", "Error Rate per Provider". Alertmanager-Regel: wenn `litellm_spend_user > 0.8 * litellm_budget_user` → Telegram-Notifikation. Wenn `litellm_error_rate_provider > 5%` über 10 Minuten → Telegram. Wenn `litellm_p99_latency > 5s` → Telegram.

Wann sich LiteLLM lohnt

LiteLLM lohnt sich, sobald (a) mehr als ein LLM-Anbieter im Spiel ist, (b) mehrere Anwendungen oder Mandanten parallel auf LLMs zugreifen, oder (c) Datenschutz-Stufen geroutet werden müssen.

Konkrete Trigger: Eine CH-Treuhand will Mistral-EU für Mandantendaten und GPT-4o für offene Recherche im gleichen Workflow nutzen. Ein KMU pilotiert RAG und Voice-Bot gleichzeitig – beide Anwendungen sollen separate Budgets und Modell-Whitelists haben. Ein Büro plant n8n-Automation und einen Chat-Assistenten – beide brauchen Audit-Log und Kosten-Reporting auf Mandanten-Ebene.

Auch für eine einzige Anwendung lohnt sich der Proxy, wenn ein Fallback gewünscht ist. Beispiel: der Mandanten-Chat soll bei Anthropic-Ausfällen automatisch auf Mistral umschalten, ohne dass der Code es merkt. Das geht via LiteLLM in 5 Zeilen YAML; ohne Gateway ist es ein eigenes Stück Code in jedem Service.

Wann LiteLLM nicht das richtige Tool ist

Bei einer einzelnen, überschaubaren Anwendung mit genau einem Provider und ohne Mandanten-Trennung ist LiteLLM Mehraufwand ohne Mehrwert. Wer in einem Wochenend-Projekt mit der OpenAI-Library arbeitet, braucht keinen Proxy.

Ungeeignet ist LiteLLM auch für extrem latenz-kritische Anwendungen, in denen jede Millisekunde zählt. Der Proxy fügt typischerweise 10-30 ms hinzu – bei Voice-Streaming oder Real-Time-Bots kann das relevant werden. In solchen Fällen lohnt eine direkte Provider-Anbindung mit dediziertem Fallback-Code.

Wer in Azure-only- oder AWS-Bedrock-only-Umgebungen lebt, hat dort eigene Gateway-Funktionen (Azure OpenAI Service mit Content Filter, AWS Bedrock mit Guardrails). Wenn die Anforderung dort vollständig abgedeckt ist, ist eine weitere Proxy-Schicht redundant.

Weitere Falle: LiteLLM ohne PostgreSQL betreiben – Audit-Log und Virtual-Keys gehen verloren bei Container-Neustart. PostgreSQL ist nicht optional, sondern Voraussetzung für Produktiv-Setups. Wer das übergeht, hat ein hipsterhaftes Tool, aber keine Compliance.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. BerriAI/litellm – GitHub repository and changelog · 2026-05
2. LiteLLM Proxy Server documentation (config.yaml, virtual keys, fallbacks) · 2026-05
3. LiteLLM Observability hooks – Langfuse, Helicone, Datadog integration · 2026-04
4. Langfuse documentation – self-host and integration · 2026-04
5. BerriAI blog – Multi-tenant cost tracking with virtual keys · 2026-03