LiteLLM: ein Gateway für 100+ LLM-Anbieter mit einer einzigen API

Was ist LiteLLM?

LiteLLM ist ein Open-Source-Projekt von BerriAI (Apache-2.0-Lizenz), das einen einheitlichen Zugangspunkt vor mehr als 100 LLM-Anbieter setzt. Egal ob OpenAI, Anthropic, Mistral, Cohere, Google Vertex, Azure, AWS Bedrock, DeepSeek, Groq, Perplexity oder eine lokale Ollama-Instanz – jede Anfrage geht über die gleiche OpenAI-kompatible REST-Schnittstelle (POST /v1/chat/completions). Die Anwendung im Code ändert sich nicht, wenn ein Anbieter ausgetauscht wird.

LiteLLM läuft entweder als Python-Library im Anwendungs-Prozess oder – in produktiven Setups – als eigenständiger Proxy-Server (Docker-Image ghcr.io/berriai/litellm-stable). Der Proxy-Modus bringt zusätzliche Funktionen mit: virtuelle API-Keys pro Team, Budget-Limits, Fallback-Ketten, Rate-Limiting, Caching, sowie Observability-Hooks für Langfuse, Helicone, Datadog und PostgreSQL-Logging. Version 1.50+ ist Stand Mai 2026 stabil; das Projekt ist seit 2023 aktiv und hat über 14.000 GitHub-Sterne.

Auf der fairlane.systems-Infrastruktur läuft LiteLLM unter Port 4100 und bündelt aktuell 24 Modelle aus 8 Anbietern. Jede produktive Anwendung – vom Mandanten-Chat über n8n-Workflows bis zu RAG-Anfragen – geht ausschliesslich über diesen Proxy. Das ist die Basis für Routing nach Datenschutz-Stufe, für Kostenkontrolle und für Anbieter-Wechsel ohne Code-Änderung.

Warum es wichtig ist

Wer LLM-Anwendungen direkt gegen die Provider-SDKs schreibt, baut sich 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 Fehler-Codes. Eine Code-Basis, 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. Modell-Namen wie mistral-eu-secure, claude-haiku-eu oder local-llama markieren die Stufe, der Proxy entscheidet das Routing.

Drittens: Kosten und Beobachtbarkeit. Jeder Provider hat eigene Dashboards, eigene Rechnungs-Frequenz, eigene Modell-Preise. Die Gesamtsicht über alle Anbieter – wer hat wie viel verbraucht, welcher Workflow kostet wie viel – lässt sich ohne Aggregations-Layer nicht erstellen. LiteLLM schreibt jede Anfrage mit Modell, Token-Zählung, Kosten und Latenz in Postgres und exportiert Metriken an Prometheus, sodass Grafana eine einzige Kosten-Sicht pro Mandant zeigen kann.

Wie es funktioniert

Der LiteLLM-Proxy ist eine Python-FastAPI-Anwendung im Docker-Container. Die Konfiguration lebt in einer config.yaml mit drei zentralen Abschnitten: model_list, litellm_settings, general_settings.

Im model_list-Block bekommt jedes Modell einen logischen Namen und eine Provider-Zuordnung. Beispiel: ein Eintrag mit model_name: mistral-eu-secure verweist via litellm_params: model: mistral/mistral-large-latest auf Mistral La Plateforme, einen weiteren Eintrag namens mistral-eu-fallback auf eine Mistral-Instanz in Azure EU. Beide stehen unter dem gleichen logischen Namen in einer Fallback-Gruppe – wenn der erste 5xx zurückgibt, springt der zweite an.

Virtuelle Keys sind das zweite Kern-Feature. Der Proxy speichert Master-API-Keys der Provider intern; nach aussen verteilt er sogenannte Virtual Keys (sk-litellm-...) an Teams, Anwendungen oder einzelne Mandanten. Jeder virtuelle Key hat ein Monats-Budget (z.B. CHF 50 für einen Pilot-Mandanten), eine Modell-Whitelist (z.B. nur mistral-eu-*) und ein Rate-Limit. Überschreitet ein Key sein Budget, blockt der Proxy weitere Anfragen – der Provider-Master-Key bleibt unberührt.

Observability lauft über Callback-Hooks. Bei jeder Antwort feuert der Proxy ein Event an konfigurierte Sinks: Langfuse für Prompt-/Response-Tracing, PostgreSQL für Audit-Log (revisionsfest für Art. 957a OR), Prometheus für Metriken. Das Audit-Log enthält Timestamp, Virtual-Key, Modell, Token-Zahl, Kosten, Hash des Prompts (nicht den Klartext bei Vertraulichkeit) sowie die Antwort-Latenz.

Fallback und Retry werden pro Modellgruppe definiert. Eine typische Konfiguration: drei Versuche mit exponentiellem Backoff, danach Fallback auf das nächste Modell in der Gruppe. Latenz-basiertes Routing (least-busy oder weighted-round-robin) verteilt Last über mehrere Modell-Instanzen.

LiteLLM-Setup in 6 Schritten

1. 01Provider-Inventar erstellen: welche LLMs sind im Einsatz, welche API-Keys, welche Modelle pro Anwendungsfall?
2. 02config.yaml mit model_list anlegen: jeder logische Modellname mit Provider-Mapping, Fallback-Gruppen, Rate-Limits.
3. 03Docker-Compose-Stack starten: LiteLLM-Container auf Port 4100, plus PostgreSQL für Audit-Log und virtuelle Keys.
4. 04Master-Admin-Key generieren und virtuelle Keys pro Team/Mandant ausstellen, mit Budget und Modell-Whitelist.
5. 05Observability anbinden: Langfuse für Tracing, Prometheus-Scraper für Metriken, Grafana-Dashboard für Kosten pro Mandant.
6. 06Anwendungen umstellen: base_url=http://litellm:4100/v1, api_key=sk-litellm-<team>, Modellnamen aus YAML. Tests, dann Schwenk.

Wann LiteLLM einsetzen

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 separate 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. Ein 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 NICHT

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.

Ebenso ungeeignet: 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.

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. BerriAI blog – Multi-tenant cost tracking with virtual keys · 2026-03