LiteLLM einrichten: 12 Schritte, 100+ Provider [2026]

Wer heute mehrere KI-Modelle gleichzeitig im Unternehmen einsetzt, kennt das Problem: OpenAI hat eine eigene API, Anthropic eine andere, Mistral wieder eine eigene, und das lokal betriebene Ollama-Modell spricht ein komplett anderes Protokoll. Jedes Team baut seine eigene Integration, niemand hat einen Überblick über die Kosten, und ein Ausfall bei einem Anbieter legt gleich die ganze Anwendung lahm. Genau hier setzt LiteLLM an: ein Open-Source-Gateway, das über 100 KI-Anbieter hinter einer einzigen, OpenAI-kompatiblen Schnittstelle bündelt. Diese Anleitung zeigt in 12 Schritten, wie Sie LiteLLM lokal und mit Docker aufsetzen, Budgets und Guardrails konfigurieren und den Proxy produktionsreif absichern.

Der Zeitpunkt ist kein Zufall. 2026 hat sich in vielen Firmen die Frage von “welches KI-Modell nehmen wir” zu “wie viele KI-Modelle verwalten wir gleichzeitig” verschoben. Agenten-Frameworks rufen mehrere Modelle pro Aufgabe auf, Support-Teams testen parallel drei Anbieter gegeneinander, und Compliance-Abteilungen wollen genau wissen, welche Anfrage bei welchem Anbieter landet. Eine zentrale Gateway-Schicht wie LiteLLM löst genau dieses Koordinationsproblem, statt es in jede einzelne Anwendung zu verlagern.

Was ist LiteLLM und warum lohnt sich ein KI-Gateway?

LiteLLM ist ein quelloffenes Projekt der Firma BerriAI und besteht aus zwei Teilen: einem Python-SDK für die direkte Einbindung in eigenen Code sowie einem eigenständigen Proxy-Server, der als KI-Gateway zwischen Anwendungen und Modellanbietern sitzt. Beide Varianten sprechen nach außen das OpenAI-Format, sodass bestehender Code, der bereits gegen die OpenAI-API entwickelt wurde, ohne größere Anpassung auf andere Anbieter wie Anthropic, Google Gemini, AWS Bedrock, Azure OpenAI, Cohere, Hugging Face, Together AI, NVIDIA NIM oder lokal betriebene Modelle über Ollama und vLLM umgeschaltet werden kann. Auf GitHub liegt das Projekt unter dem Namen BerriAI/litellm, laut eigener Website nennt LiteLLM auch NVIDIA als Anwender: Das Unternehmen setzt den Gateway ein, damit Entwicklerteams einen einheitlichen Zugriff auf mehr als 100 KI-Modell-Endpunkte über Cloud-Anbieter, Open-Source-Deployments und interne Dienste erhalten.

Der technische Kern besteht laut Projektbeschreibung aus einer Rust-Basis mit Python-SDK obenauf, was dem Proxy im Vergleich zu reinen Python-Implementierungen zusätzliche Geschwindigkeit verschafft. Wer bereits mit Ollama lokale Modelle betreibt, kann diese über LiteLLM in dieselbe Routing-Schicht wie Cloud-Modelle einbinden und so hybride Setups fahren, bei denen sensible Anfragen lokal bleiben und alles andere an leistungsstärkere Cloud-Modelle geht.

Zwei Betriebsmodi stehen zur Wahl, und beide kommen in dieser Anleitung vor. Das SDK eignet sich für ein einzelnes Projekt, das mehrere Anbieter testen will, ohne einen zusätzlichen Server zu betreiben. Der Proxy-Modus lohnt sich, sobald mehrere Teams oder Anwendungen denselben Zugang teilen sollen, weil er zentrale Themen wie Authentifizierung, Budgets und Logging an einer Stelle bündelt statt in jedem Projekt neu zu implementieren. Die offizielle Dokumentation des Projekts wurde laut den zuletzt geprüften Änderungsprotokollen noch Anfang September 2026 aktualisiert, unter anderem um Routing für Echtzeit-Sprachschnittstellen im OpenAI-Realtime-Format zu ergänzen, was zeigt, dass die Entwicklung aktiv weiterläuft.

Warum LiteLLM 2026 für DACH-Unternehmen besonders relevant ist

Für Teams in Deutschland, Österreich und der Schweiz kommt neben der reinen Kostenersparnis ein zweiter Punkt dazu: Kontrolle über Datenflüsse. Ein selbst gehosteter Gateway zwingt jede ausgehende KI-Anfrage durch eine zentrale Stelle, die protokolliert, welches Modell welche Daten erhält. Das erleichtert die Dokumentation, die im Rahmen des risikobasierten Ansatzes des EU AI Act ohnehin gefordert wird, auch wenn LiteLLM selbst keine fertige Compliance-Lösung ist, sondern nur die technische Infrastruktur dafür liefert. Firmen entscheiden am Gateway, welche Anfragen die EU verlassen dürfen und welche ausschließlich an lokale oder europäische Modelle wie Mistral gehen.

Hinzu kommt ein aktueller Sicherheitsaspekt: Die Cloud Security Alliance dokumentierte in einer Forschungsnotiz die Schwachstelle CVE-2026-42271, eine Command-Injection-Lücke mit einem CVSS-Wert von 8,7, die alle LiteLLM-Versionen von 1.74.2 bis 1.83.6 betraf. Wer den Gateway produktiv einsetzt, muss also nicht nur wissen, wie man ihn installiert, sondern auch, wie man ihn patcht und absichert. Genau diese beiden Seiten deckt diese Anleitung ab.

Ein dritter Grund ist rein wirtschaftlich. Wechselkurse und unterschiedliche Preismodelle zwischen US-Anbietern und europäischen Alternativen wie Mistral machen einen laufenden Kostenvergleich mühsam, wenn jedes Team seine Abrechnung separat pflegt. Läuft der gesamte Verkehr über ein Gateway, lässt sich in einem einzigen Dashboard vergleichen, welches Modell für welche Aufgabe das beste Verhältnis aus Preis und Qualität liefert, und Budgets lassen sich dort verschieben, wo sie tatsächlich gebraucht werden, statt in Silos gebunden zu bleiben.

Voraussetzungen: Diese Versionen brauchen Sie

Bevor es losgeht, sollten folgende Komponenten bereitstehen. Die Tabelle zeigt die Mindestanforderungen für ein stabiles Setup, sowohl für den lokalen Testbetrieb als auch für ein späteres Docker-Deployment.

Komponente	Empfohlene Version	Zweck
Python	3.11 oder neuer	Basis für SDK und Proxy-Server
LiteLLM	mindestens 1.83.7	Erste Version nach dem CVE-2026-42271-Patch
pip	aktuelle Version	Installation des Pakets inkl. Proxy-Extras
Docker	Docker Engine mit Compose-Plugin	Containerisiertes Deployment
Mindestens ein API-Key	z. B. OpenAI, Anthropic oder Mistral	Test der Cloud-Anbindung
Optional: Ollama	lokal installiert	Hybrides Routing zwischen Cloud und lokalem Modell
Arbeitsspeicher	mindestens 2 GB frei	Proxy-Prozess plus Puffer für Logging

Rechnen Sie für das komplette Setup, von der ersten Installation bis zum abgesicherten Docker-Deployment mit Budgetkontrolle, etwa 60 bis 90 Minuten ein. Wer nur das SDK lokal testen will, ist in 10 Minuten fertig.

Diese Anleitung richtet sich an Entwicklerinnen und Entwickler, die bereits mit mindestens einer KI-API gearbeitet haben, sowie an Plattform- und DevOps-Teams, die eine zentrale KI-Infrastruktur für mehrere interne Anwendungen aufbauen wollen. Grundkenntnisse in YAML-Syntax und im Umgang mit der Kommandozeile reichen aus, tiefere Kenntnisse in Rust oder im internen Aufbau von LiteLLM selbst sind nicht nötig, da die gesamte Konfiguration deklarativ über die config.yaml erfolgt.

LiteLLM einrichten: die Schritt-für-Schritt-Anleitung

Schritt 1: Python-Umgebung vorbereiten

Legen Sie zunächst ein sauberes virtuelles Environment an, damit LiteLLM nicht mit anderen Python-Projekten kollidiert. Das ist besonders wichtig, weil der Proxy-Modus zusätzliche Abhängigkeiten wie FastAPI und Uvicorn mitbringt, die in anderen Projekten zu Versionskonflikten führen können.

python3 -m venv litellm-env
source litellm-env/bin/activate
python3 -m pip install --upgrade pip

Schritt 2: LiteLLM installieren

Für reine SDK-Nutzung reicht das Basispaket, für den Gateway-Betrieb brauchen Sie die Proxy-Extras. Installieren Sie direkt die vollständige Variante von litellm auf PyPI, damit Sie später nicht nachrüsten müssen.

pip install 'litellm[proxy]'==1.83.7
litellm --version

Prüfen Sie nach der Installation immer die Versionsnummer. Wenn Ihre Umgebung eine ältere Version als 1.83.7 zieht, etwa weil ein internes Paket-Mirror-Caching aktiv ist, upgraden Sie manuell mit pip install --upgrade litellm, bevor Sie mit produktiven Schlüsseln arbeiten.

Schritt 3: Ersten API-Call über das Python-SDK senden

Bevor der Proxy-Server überhaupt ins Spiel kommt, lohnt sich ein Test direkt über das SDK. So sehen Sie sofort, ob Ihr API-Key funktioniert, ohne einen Server starten zu müssen.

import os
from litellm import completion

os.environ["OPENAI_API_KEY"] = "sk-ihr-openai-key"

response = completion(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Erkläre LiteLLM in einem Satz."}]
)

print(response.choices[0].message.content)

Wechseln Sie testweise nur den Wert von model auf "claude-sonnet-4-6" oder "mistral/mistral-large-latest" mit dem passenden Umgebungsvariablen-Key, und Sie sehen sofort den Kernvorteil: Der restliche Code bleibt identisch.

Schritt 4: config.yaml für den Proxy-Server anlegen

Der eigentliche Gateway-Betrieb läuft über eine zentrale Konfigurationsdatei. Darin definieren Sie, welche Modellnamen nach außen sichtbar sind und welcher echte Anbieter dahintersteckt. Das ist der Schritt, der aus einem einfachen SDK-Wrapper ein echtes Team-Gateway macht.

model_list:
  - model_name: gpt-4o
    litellm_params:
      model: openai/gpt-4o
      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
  - model_name: mistral-eu
    litellm_params:
      model: mistral/mistral-large-latest
      api_key: os.environ/MISTRAL_API_KEY
  - model_name: llama-lokal
    litellm_params:
      model: ollama/llama3
      api_base: http://localhost:11434

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY

Der Eintrag mistral-eu zeigt bewusst, wie man einen europäischen Anbieter parallel zu US-Diensten einbindet. Teams, die aus Datenschutzgründen bestimmte Anfragen zwingend bei einem EU-Anbieter halten wollen, routen diese Anfragen im Anwendungscode gezielt über diesen Modellnamen statt über gpt-4o.

Schritt 5: Proxy-Server starten und testen

Mit fertiger Konfiguration starten Sie den Server lokal auf Port 4000. Setzen Sie vorher alle referenzierten Umgebungsvariablen, sonst schlägt der Start mit einer Fehlermeldung zu fehlenden Keys fehl.

export OPENAI_API_KEY="sk-ihr-openai-key"
export ANTHROPIC_API_KEY="sk-ant-ihr-key"
export MISTRAL_API_KEY="ihr-mistral-key"
export LITELLM_MASTER_KEY="sk-1234"

litellm --config config.yaml --port 4000

Testen Sie in einem zweiten Terminal, ob der Gateway antwortet:

curl http://localhost:4000/chat/completions \
  -H "Authorization: Bearer sk-1234" \
  -H "Content-Type: application/json" \
  -d '{"model": "gpt-4o", "messages": [{"role": "user", "content": "Sag Hallo"}]}'

Schritt 6: Mehrere Provider gleichzeitig produktiv testen

Wiederholen Sie den Curl-Aufruf aus Schritt 5 einfach mit "model": "claude-sonnet", "mistral-eu" und "llama-lokal". Läuft Ollama nicht lokal, starten Sie es vorher mit ollama serve. So verifizieren Sie in wenigen Minuten, dass alle vier Anbieter über denselben Endpunkt erreichbar sind, bevor Anwendungsteams anfangen, ihren Code umzustellen. Notieren Sie sich dabei auch die Antwortzeiten der einzelnen Anbieter, denn diese unterscheiden sich in der Praxis deutlich und beeinflussen später die Entscheidung, welches Modell als primäres Backend in einer Failover-Konfiguration dient.

Schritt 7: Virtuelle API-Keys pro Team generieren

Statt den Master-Key an jedes Team weiterzugeben, erzeugt der Proxy eigene virtuelle Schlüssel. Das reduziert das Risiko, dass ein einzelner geleakter Key Zugriff auf das gesamte Budget gibt.

curl http://localhost:4000/key/generate \
  -H "Authorization: Bearer sk-1234" \
  -H "Content-Type: application/json" \
  -d '{"models": ["gpt-4o", "mistral-eu"], "max_budget": 50, "duration": "30d"}'

Die Antwort enthält einen neuen Key, der auf die im Aufruf genannten Modelle beschränkt ist und nach Ablauf des Budgets automatisch Anfragen ablehnt. Verteilen Sie diesen Key an das jeweilige Entwicklerteam statt des Master-Keys. Dieser Schritt ist der eigentliche Hebel für Kostentransparenz: Statt hinterher aus Sammelrechnungen zu rekonstruieren, welches Team wie viel verbraucht hat, ist die Zuordnung von Anfang an im Key selbst verankert und lässt sich jederzeit über die Logs nachvollziehen.

Schritt 8: Docker-Deployment vorbereiten

Für den Dauerbetrieb ist ein Container die sauberere Wahl als ein manuell gestarteter Prozess. Legen Sie eine docker-compose.yml neben Ihrer config.yaml an.

services:
  litellm:
    image: ghcr.io/berriai/litellm:main-stable
    ports:
      - "4000:4000"
    volumes:
      - ./config.yaml:/app/config.yaml
    environment:
      - OPENAI_API_KEY=${OPENAI_API_KEY}
      - ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}
      - MISTRAL_API_KEY=${MISTRAL_API_KEY}
      - LITELLM_MASTER_KEY=${LITELLM_MASTER_KEY}
    command: ["--config", "/app/config.yaml", "--port", "4000"]
    restart: unless-stopped

docker compose up -d
docker compose logs -f litellm

Schritt 9: Kostenkontrolle und Budgets pro Modell einrichten

Neben den Team-Keys aus Schritt 7 lässt sich auch ein globales Limit setzen, damit ein einzelner fehlerhafter Anwendungsteil nicht das gesamte Monatsbudget verbrennt. Ergänzen Sie dafür die general_settings in der config.yaml.

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  max_budget: 500
  budget_duration: 30d
  alerting: ["slack"]

Nach einem Neustart des Containers protokolliert der Gateway pro Anfrage die geschätzten Kosten und summiert sie gegen das gesetzte Limit. So sehen Finance- und Engineering-Teams an einer Stelle, wie viel welches Team über welchen Anbieter verbraucht, statt einzelne Rechnungen von OpenAI, Anthropic und Mistral manuell zusammenzurechnen. Der Eintrag alerting: ["slack"] sorgt zusätzlich dafür, dass eine Benachrichtigung ausgelöst wird, sobald ein festgelegter Schwellenwert erreicht ist, sodass ein Team reagieren kann, bevor das Budget vollständig aufgebraucht ist und Anfragen abgelehnt werden.

Schritt 10: Load Balancing und automatisches Failover

Tragen Sie einen Modellnamen mehrfach mit unterschiedlichen Backends ein, verteilt LiteLLM die Last automatisch und springt bei einem Ausfall auf das nächste Backend um.

model_list:
  - model_name: gpt-4o-team
    litellm_params:
      model: openai/gpt-4o
      api_key: os.environ/OPENAI_API_KEY_PRIMARY
  - model_name: gpt-4o-team
    litellm_params:
      model: azure/gpt-4o-deployment
      api_key: os.environ/AZURE_API_KEY
      api_base: os.environ/AZURE_API_BASE

router_settings:
  routing_strategy: usage-based-routing

Fällt der primäre OpenAI-Zugang aus, springt der Router auf die Azure-Bereitstellung desselben Modells um, ohne dass die aufrufende Anwendung etwas davon merkt. Dieses Muster lohnt sich besonders bei Anwendungen, die eine RAG-Pipeline im Hintergrund betreiben und auf durchgängige Verfügbarkeit angewiesen sind.

Schritt 11: Guardrails gegen riskante Prompts aktivieren

LiteLLM lässt sich mit Guardrail-Regeln kombinieren, die Anfragen vor der Weiterleitung prüfen. Das ist vor allem für Teams relevant, die zusätzlich Werkzeuge zur Absicherung gegen Prompt Injection einsetzen und diese Prüfung zentral am Gateway statt in jeder Anwendung einzeln verankern wollen.

guardrails:
  - guardrail_name: pii-filter
    litellm_params:
      guardrail: presidio
      mode: pre_call
      default_on: true

Mit mode: pre_call prüft der Gateway jede eingehende Anfrage, bevor sie an den eigentlichen Modellanbieter geht, und kann sie bei Regelverstoß blockieren oder anonymisieren, statt personenbezogene Daten unkontrolliert an einen externen Anbieter zu schicken. Für Teams, die bereits gezielt gegen Prompt Injection testen, lässt sich diese Guardrail-Schicht als zusätzliche Verteidigungslinie verstehen: Selbst wenn eine einzelne Anwendung eine riskante Eingabe durchlässt, kann der zentrale Gateway sie noch abfangen, bevor sie überhaupt beim Modell ankommt.

Schritt 12: Proxy für den Produktivbetrieb absichern

Vor dem produktiven Rollout gehören drei Dinge zwingend erledigt: Version mindestens 1.83.7 wegen CVE-2026-42271, Master-Key ausschließlich über Umgebungsvariablen statt Klartext in der Konfigurationsdatei, und die MCP-Testendpunkte auf die Rolle PROXY_ADMIN beschränkt, wie es die gepatchte Version bereits vorgibt. Prüfen Sie zusätzlich, dass der Container nicht direkt aus dem Internet erreichbar ist, sondern hinter einem eigenen Reverse Proxy mit TLS liegt.

litellm --version
# Erwartete Ausgabe: 1.83.7 oder neuer
# Falls älter:
pip install --upgrade 'litellm[proxy]'

LiteLLM vs. OpenRouter vs. Portkey: Wann lohnt sich welcher Gateway?

LiteLLM ist nicht die einzige Möglichkeit, mehrere KI-Anbieter hinter einer Schnittstelle zu bündeln. OpenRouter und Portkey verfolgen einen anderen Ansatz: Beide laufen primär als gehosteter Dienst, während LiteLLM als selbst betriebene Software konzipiert ist. Die folgende Tabelle fasst die wichtigsten strukturellen Unterschiede zusammen, basierend auf den öffentlich dokumentierten Eigenschaften der jeweiligen Projekte.

Kriterium	LiteLLM	OpenRouter	Portkey
Betriebsmodell	Self-hosted, quelloffen	Gehosteter SaaS-Dienst	Gehosteter SaaS-Dienst mit Gateway-Option
Lizenzkosten der Software	Kostenlos (Open Source)	Nutzungsbasiert pro Anfrage	Abo-Modell mit Free-Tier
Datenhoheit	Vollständig, da eigene Infrastruktur	Daten laufen über OpenRouter-Server	Daten laufen über Portkey-Server
Provider-Anzahl	Über 100 laut Projektangabe	Mehrere Dutzend große Anbieter	Mehrere Dutzend große Anbieter
Setup-Aufwand	Eigenes Hosting nötig	Sofort startklar über API-Key	Sofort startklar über API-Key
Ideal für	Teams mit Compliance- oder Datenresidenz-Anforderungen	Schnelle Prototypen, Einzelentwickler	Unternehmen, die Observability ohne eigenen Betrieb wollen

Für DACH-Unternehmen mit Datenschutzanforderungen ist der entscheidende Vorteil von LiteLLM offensichtlich: Da der Gateway auf eigener Infrastruktur läuft, verlässt keine Anfrage-Metadaten ein drittes Unternehmen, bevor sie beim eigentlichen Modellanbieter landet. Der Preis dafür ist eigener Betriebsaufwand, den gehostete Alternativen abnehmen.

Als grobe Faustregel gilt: Ein einzelner Entwickler, der schnell verschiedene Modelle für ein Wochenendprojekt ausprobieren will, ist mit OpenRouter oder Portkey oft schneller am Ziel, weil kein eigener Server nötig ist. Ein Unternehmen mit mehreren Teams, festen Compliance-Vorgaben und dem Wunsch, langfristig unabhängig von einem einzelnen SaaS-Anbieter zu bleiben, fährt mit einer selbst gehosteten LiteLLM-Instanz meist besser, auch wenn die initiale Einrichtung wie in dieser Anleitung mehr Zeit kostet als ein einfacher API-Key bei einem gehosteten Dienst.

Migration bestehender OpenAI-Integrationen zu LiteLLM

Die meisten Teams starten nicht bei null, sondern haben bereits Code, der direkt gegen die OpenAI-API läuft. Der Umstieg auf LiteLLM lässt sich in der Regel ohne große Umbauten erledigen, weil der Proxy exakt dieselbe Antwortstruktur liefert wie die OpenAI-API selbst. In den meisten Fällen genügt es, die Basis-URL im bestehenden Client auf die eigene LiteLLM-Instanz umzustellen und den bisherigen OpenAI-Key durch einen virtuellen LiteLLM-Key zu ersetzen.

Bei Verwendung der offiziellen OpenAI-Python-Bibliothek betrifft die Änderung nur zwei Zeilen: Der Parameter base_url zeigt künftig auf http://localhost:4000 statt auf die OpenAI-Server, und der api_key wird durch den in Schritt 7 erzeugten virtuellen Key ersetzt. Der restliche Anwendungscode, inklusive Streaming, Funktionsaufrufen und Fehlerbehandlung, bleibt unverändert, weil LiteLLM das komplette Antwortformat von OpenAI nachbildet. Praktisch bedeutet das: Teams können den Wechsel schrittweise vollziehen, indem sie zunächst nur eine einzelne, unkritische Anwendung umstellen, den Betrieb eine Woche beobachten und erst danach weitere Systeme migrieren. So lässt sich ein eventuelles Konfigurationsproblem früh erkennen, bevor es alle Anwendungen gleichzeitig betrifft.

Häufige Fehler beim LiteLLM-Setup

Diese fünf Fehler tauchen in der Praxis am häufigsten auf und lassen sich mit etwas Vorbereitung vollständig vermeiden.

Master-Key im Klartext in der config.yaml: Landet die Datei versehentlich in einem Git-Repository, ist der komplette Gateway kompromittiert. Nutzen Sie immer os.environ/-Referenzen statt fester Werte, und prüfen Sie vor jedem Commit mit einem einfachen git diff, ob versehentlich ein Schlüssel im Klartext hängen geblieben ist.
Veraltete Version im Einsatz: Wer vor Mai 2026 installiert und seitdem nicht aktualisiert hat, läuft mit einer durch CVE-2026-42271 verwundbaren Version. Ein litellm --version vor jedem Deployment gehört in jede Checkliste, ebenso wie ein fester Termin im Kalender, um Sicherheitsupdates nicht dem Zufall zu überlassen.
Fehlende Modellnamen-Trennung: Wird derselbe interne Modellname für Test- und Produktivumgebung verwendet, landen Testanfragen versehentlich im Produktivbudget. Nutzen Sie eindeutige Präfixe wie dev-gpt-4o und prod-gpt-4o, und dokumentieren Sie diese Konvention verbindlich für alle Teams, die auf den Gateway zugreifen.
Kein Budget-Limit gesetzt: Ohne max_budget kann ein Bug in einer Anwendung, die in einer Schleife Anfragen sendet, hohe Kosten verursachen, bevor jemand es bemerkt. Ein Budget-Limit ist kein Misstrauen gegenüber dem eigenen Team, sondern eine simple technische Sicherung, ähnlich einer Sicherung im Stromkasten.
Docker-Container ohne Volume für die Konfiguration: Wird config.yaml nicht als Volume eingebunden, geht jede Änderung beim nächsten Container-Rebuild verloren, und Teams wundern sich, warum ihre Anpassungen nicht greifen. Ein schneller Test mit docker compose config zeigt vorab, ob das Volume korrekt eingebunden ist.

Fehlerbehebung: Die häufigsten LiteLLM-Probleme

Die folgende Tabelle sammelt die Probleme, die in Community-Foren und Issue-Trackern am häufigsten auftauchen, zusammen mit der jeweiligen Ursache und der praktischen Lösung. Die meisten davon lassen sich in unter fünf Minuten beheben, sobald die eigentliche Ursache klar ist, weshalb sich ein kurzer Blick in diese Übersicht vor einer längeren Fehlersuche lohnt.

Problem	Wahrscheinliche Ursache	Lösung
Server startet nicht, Fehler zu fehlendem Key	Umgebungsvariable nicht gesetzt oder falsch benannt	Mit `echo $OPENAI_API_KEY` prüfen, ob die Variable im aktuellen Terminal existiert
401 Unauthorized bei jedem Aufruf	Falscher oder abgelaufener virtueller Key verwendet	Neuen Key über `/key/generate` erzeugen und im Client aktualisieren
Modell aus config.yaml nicht erreichbar	Tippfehler im `model_name` oder Datei nicht neu geladen	Proxy neu starten und Modellnamen exakt aus der Config kopieren
Ollama-Modell antwortet nicht über den Proxy	Ollama läuft nicht oder falscher `api_base`	Mit `curl http://localhost:11434` direkt prüfen, ob Ollama erreichbar ist
Budget-Limit wird nicht durchgesetzt	Alte LiteLLM-Version ohne aktuelle Budget-Logik	Auf mindestens 1.83.7 aktualisieren
Docker-Container startet und stoppt sofort wieder	Fehler in der YAML-Syntax der config.yaml	YAML mit einem Linter prüfen, Einrückung kontrollieren
Langsame Antwortzeiten trotz funktionierendem Routing	Kein Load Balancing konfiguriert, ein überlasteter Endpunkt bremst alles	`routing_strategy: usage-based-routing` aktivieren
Guardrail blockiert legitime Anfragen	Zu aggressive PII-Filter-Regeln	Regeln im Testmodus (`default_on: false`) einzeln validieren, bevor sie scharf geschaltet werden

Erwartete Ausgabe: So sieht ein funktionierender Gateway aus

Nach einem erfolgreichen Start meldet der Proxy im Terminal, auf welchem Port er lauscht und welche Modelle aus der Konfiguration geladen wurden. Eine typische Antwort auf den Test-Curl aus Schritt 5 sieht so aus:

{
  "id": "chatcmpl-8f92a1",
  "model": "gpt-4o",
  "choices": [
    {
      "message": {
        "role": "assistant",
        "content": "Hallo! Wie kann ich helfen?"
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 9,
    "completion_tokens": 8,
    "total_tokens": 17
  }
}

Wichtig ist der usage-Block: Aus diesen Token-Zahlen berechnet LiteLLM die geschätzten Kosten und zieht sie vom jeweiligen Budget ab. Fehlt dieser Block in der Antwort, stimmt meist die Provider-Zuordnung in der config.yaml nicht.

Ist ein Budget aufgebraucht oder ein Key ungültig, antwortet der Gateway stattdessen mit einem Fehlerobjekt statt einer normalen Chat-Antwort, üblicherweise mit HTTP-Statuscode 429 bei Budgetüberschreitung und 401 bei einem ungültigen Key. Diese Statuscodes lassen sich in der aufrufenden Anwendung genauso abfangen wie bei einer direkten OpenAI-Integration, sodass bestehende Fehlerbehandlung meist unverändert weiterfunktioniert.

Fortgeschrittene Tipps für den Produktivbetrieb

Sobald das Grundsetup läuft, lohnen sich einige zusätzliche Handgriffe, die aus einem Testaufbau eine belastbare Infrastruktur machen.

Erstens: Betreiben Sie den Proxy nicht als manuell gestarteten Prozess, sondern als systemd-Dienst oder in Kubernetes, damit er nach einem Server-Neustart automatisch wieder hochfährt.

[Unit]
Description=LiteLLM AI Gateway
After=network.target

[Service]
EnvironmentFile=/etc/litellm/env
ExecStart=/opt/litellm-env/bin/litellm --config /etc/litellm/config.yaml --port 4000
Restart=always
User=litellm

[Install]
WantedBy=multi-user.target

Zweitens: Aktivieren Sie strukturiertes Logging und leiten Sie es an ein zentrales System weiter, statt nur in der Konsole mitzulesen. Wer bereits eine Observability-Plattform betreibt, sollte prüfen, ob ein Benchmark-Setup für die eigenen Modelle sinnvoll ergänzt werden kann, um Qualitätsschwankungen zwischen den über den Gateway gerouteten Anbietern frühzeitig zu erkennen.

Drittens: Rotieren Sie virtuelle Keys regelmäßig, statt sie dauerhaft laufen zu lassen. Ein Key, der alle 90 Tage automatisch abläuft, begrenzt den Schaden, falls er versehentlich in einem Log oder Client-Code landet.

Viertens: Trennen Sie Staging- und Produktivumgebung technisch, nicht nur über Namenskonventionen. Zwei separate Container mit eigenen config.yaml-Dateien und eigenen Budgets verhindern, dass ein Lasttest in der Testumgebung das Produktivbudget belastet.

Fünftens: Planen Sie von Anfang an mit mehreren Instanzen statt einer einzelnen. Zwei Proxy-Container hinter einem einfachen Load Balancer sorgen dafür, dass ein Neustart wegen eines Updates keine Downtime für angebundene Anwendungen verursacht. Weil der Proxy selbst zustandslos arbeitet und Budgets sowie Keys in einer externen Datenbank statt im Arbeitsspeicher halten kann, lässt sich diese Redundanz ohne Sonderaufwand einrichten.

Monitoring und Kostenauswertung im Alltag

Ein Gateway ohne Sichtbarkeit bringt wenig, deshalb gehört ein Blick auf die eingebauten Auswertungsmöglichkeiten zu jedem produktiven Setup. Der Proxy führt intern ein Log jeder Anfrage inklusive Modell, Team-Key, Tokenzahl und geschätzten Kosten. Über den Endpunkt /spend/logs lässt sich dieser Verlauf abrufen und in ein eigenes Dashboard exportieren, etwa um wöchentlich zu prüfen, welches Team welchen Anbieter am stärksten nutzt.

curl http://localhost:4000/spend/logs \
  -H "Authorization: Bearer sk-1234"

Für Teams, die bereits eine bestehende Observability-Kette betreiben, lässt sich dieses Logging an externe Systeme weiterreichen, statt nur lokal auszuwerten. Wichtig ist dabei, klar zwischen zwei Ebenen zu trennen: technisches Monitoring, das Latenz, Fehlerraten und Verfügbarkeit des Gateways selbst misst, und fachliches Kosten-Reporting, das die Ausgaben pro Team und Modell nachvollzieht. Beide Ebenen sollten getrennt ausgewertet werden, weil ein technisch fehlerfreier Proxy trotzdem stillschweigend ein Budget überschreiten kann, wenn niemand die Kostenseite regelmäßig prüft.

Ein einfacher Startpunkt für die meisten Teams: einmal pro Woche einen kurzen Blick auf die Spend-Logs werfen und die Verteilung zwischen den vier in dieser Anleitung eingerichteten Modellen prüfen. Wächst der Anteil eines teuren Cloud-Modells ungewöhnlich schnell, während ein günstigeres oder lokales Modell für dieselbe Aufgabe ausreichen würde, lässt sich frühzeitig gegensteuern, statt das Problem erst am Monatsende in der Abrechnung zu entdecken.

Komplettes Projekt: LiteLLM-Gateway für ein DACH-Team

Zum Abschluss ein Beispiel, das alle Schritte zu einem funktionierenden Gesamtprojekt zusammenführt. Ein mittelständisches Unternehmen mit drei Teams (Support-Chatbot, interne Suche, Entwicklerwerkzeuge) will einen zentralen Gateway betreiben, der Kosten trennt, sensible Support-Anfragen bevorzugt an ein europäisches Modell schickt und bei Ausfällen automatisch umschaltet. Der Anspruch an das Projekt ist bewusst realistisch gehalten: kein aufwendiges Kubernetes-Cluster, sondern ein einzelner Server mit Docker, der binnen weniger Minuten aus vier Textdateien einsatzbereit ist.

Die Projektstruktur besteht aus vier Dateien: config.yaml mit den vier Modellen aus Schritt 4 plus dem Failover-Paar aus Schritt 10, docker-compose.yml aus Schritt 8, einer .env-Datei mit allen API-Keys und einem kurzen Setup-Skript.

#!/bin/bash
# setup.sh - komplettes LiteLLM-Projekt starten
set -e

docker compose up -d

sleep 3

# Team 1: Support-Chatbot, bevorzugt mistral-eu, Budget 50 Euro/Monat
curl -s http://localhost:4000/key/generate \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{"models": ["mistral-eu", "gpt-4o-team"], "max_budget": 50, "duration": "30d"}'

# Team 2: Interne Suche, RAG-Pipeline, Budget 150 Euro/Monat
curl -s http://localhost:4000/key/generate \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{"models": ["gpt-4o-team", "llama-lokal"], "max_budget": 150, "duration": "30d"}'

echo "Gateway läuft, Keys für beide Teams erzeugt."

Mit diesem Skript entsteht in unter fünf Minuten ein Gateway, das drei Anbieter plus ein lokales Modell bündelt, pro Team eigene Budgets durchsetzt und beim Ausfall des primären OpenAI-Zugangs automatisch auf Azure umschaltet. Genau dieses Muster, zentrales Routing plus getrennte Budgets pro Abteilung, lässt sich unverändert auf größere Organisationen mit mehr als drei Teams übertragen.

Der entscheidende Unterschied zu einem klassischen, verteilten Setup zeigt sich erst nach einigen Wochen Betrieb: Statt drei separaten Rechnungen von OpenAI, Anthropic und Mistral, die jemand manuell den Kostenstellen zuordnen muss, liefert der Gateway eine einzige, nach Team und Modell aufgeschlüsselte Übersicht. Skaliert das Unternehmen auf zehn oder zwanzig Teams, bleibt der Aufwand für ein neues Team gering: eine neue Zeile in der config.yaml, falls ein neues Modell dazukommt, und ein Aufruf von /key/generate für den neuen Zugang. Der grundlegende Betrieb des Gateways selbst ändert sich dabei nicht.

EU AI Act und Datenresidenz: Was LiteLLM leisten kann und was nicht

Ein wichtiger Punkt vorab: LiteLLM ist kein Compliance-Produkt und erfüllt den EU AI Act nicht automatisch. Der Gateway liefert lediglich die technische Grundlage, auf der Compliance-Maßnahmen aufsetzen können, etwa zentrales Logging aller Anfragen, klare Trennung zwischen EU- und Nicht-EU-Modellen über eindeutige Modellnamen, sowie Guardrails, die personenbezogene Daten vor dem Versand an externe Anbieter filtern. Ob das im Einzelfall für die eigenen regulatorischen Pflichten ausreicht, muss jedes Unternehmen mit der eigenen Rechtsabteilung klären, nicht mit einer Software-Konfiguration allein.

Praktisch bedeutet das: Wer über den Gateway strikt zwischen Modellnamen mit dem Präfix eu- und allen anderen unterscheidet und im Anwendungscode erzwingt, dass bestimmte Datenkategorien ausschließlich über eu--Modelle laufen, hat eine nachvollziehbare technische Kontrolle geschaffen. Diese lässt sich im Audit vorzeigen, ersetzt aber keine rechtliche Bewertung der eingesetzten Modelle selbst.

Für die Praxis empfiehlt sich ein einfacher Dreischritt: Erstens gemeinsam mit Datenschutz und Rechtsabteilung festlegen, welche Datenkategorien überhaupt an externe KI-Anbieter gehen dürfen. Zweitens diese Festlegung technisch im Gateway über getrennte Modellnamen und, wo nötig, über Guardrails erzwingen, statt sich auf informelle Absprachen zwischen Entwicklerteams zu verlassen. Drittens die Logs des Gateways regelmäßig stichprobenartig prüfen, ob die Trennung in der Praxis tatsächlich eingehalten wird. Diese drei Schritte machen aus einer abstrakten Richtlinie eine überprüfbare technische Realität.

Sicherheit: Warum das Patchen auf 1.83.7 Pflicht ist

Die von der Cloud Security Alliance dokumentierte Schwachstelle CVE-2026-42271 betraf laut der Forschungsnotiz alle Versionen zwischen 1.74.2 und 1.83.6 und wurde am 8. Mai 2026 mit Version 1.83.7 geschlossen. Der Patch brachte zwei Änderungen: zusätzliche Autorisierungsprüfungen, die MCP-Testendpunkte künftig auf die Rolle PROXY_ADMIN beschränken, sowie ein Update der zugrunde liegenden Starlette-Bibliothek auf Version 1.0.1. Die Cloud Security Alliance stufte die Lücke als so kritisch ein, dass sie Betreibern ein Notfall-Upgrade empfahl, unabhängig vom regulären Update-Zyklus.

Die Lücke betraf die MCP-Testendpunkte des Proxys, also die Schnittstellen, über die sich das Model Context Protocol testen lässt. Ohne die in 1.83.7 eingeführte Rollenbeschränkung konnten diese Endpunkte laut der Forschungsnotiz von unautorisierten Aufrufern erreicht werden, was in der Praxis Command-Injection ermöglichte. Für Betreiber älterer Versionen bedeutete das ein reales Risiko, nicht nur eine theoretische Schwachstelle in einem selten genutzten Codepfad.

Für jedes bestehende Deployment gilt deshalb: Vor der Übernahme dieser Anleitung in die Produktion einmal litellm --version ausführen, und bei jeder Version unter 1.83.7 sofort upgraden, bevor der Gateway an externen Datenverkehr angebunden wird. Wer den Proxy über Docker betreibt, sollte zusätzlich sicherstellen, dass das verwendete Image-Tag nicht auf eine eingefrorene ältere Version zeigt, sondern regelmäßig neu gezogen wird.

Der Fall zeigt außerdem ein grundsätzliches Muster, das über LiteLLM hinausgeht: Je zentraler eine Komponente in der eigenen Infrastruktur wird, desto attraktiver ist sie als Angriffsziel. Ein Gateway, das Zugriff auf mehrere teure API-Keys gleichzeitig bündelt, lohnt sich für Angreifer besonders, weil ein einziger erfolgreicher Zugriff potenziell mehrere Anbieter gleichzeitig kompromittiert. Wer LiteLLM einführt, sollte deshalb Patch-Management für diese eine Komponente genauso ernst nehmen wie für eine Firewall oder ein VPN-Gateway, nicht wie für eine gewöhnliche interne Bibliothek.

Häufig gestellte Fragen zu LiteLLM

Was ist LiteLLM und wofür wird es eingesetzt?

LiteLLM ist ein Open-Source-Gateway, das den Zugriff auf über 100 KI-Modellanbieter hinter einer einzigen, OpenAI-kompatiblen Schnittstelle bündelt. Unternehmen setzen es ein, um Kosten zu verfolgen, Anbieter auszutauschen ohne Code neu zu schreiben, und Ausfälle einzelner Anbieter automatisch abzufedern.

Ist LiteLLM kostenlos?

Die Software selbst ist quelloffen und kostenlos nutzbar. Kosten entstehen ausschließlich bei den dahinterliegenden Modellanbietern wie OpenAI, Anthropic oder Mistral, deren übliche API-Preise unverändert gelten. Hinzu kommt der eigene Aufwand für Hosting und Betrieb, etwa für den Server oder Cloud-Ressourcen, auf denen der Proxy-Container läuft, sowie die Zeit für Wartung und Sicherheitsupdates. Verglichen mit gehosteten Gateway-Diensten, die meist nach Anfragevolumen abrechnen, verschiebt sich bei LiteLLM ein Teil der Kosten also von einer laufenden Nutzungsgebühr hin zu einmaligem Einrichtungsaufwand und fortlaufendem Betrieb.

Welche Provider unterstützt LiteLLM?

Laut Projektangaben werden über 100 Anbieter unterstützt, darunter OpenAI, Anthropic, Google Gemini, AWS Bedrock, Azure OpenAI, Cohere, Hugging Face, Replicate, Together AI, NVIDIA NIM sowie lokal betriebene Modelle über Ollama und vLLM.

Wie sicher ist der LiteLLM-Proxy im Produktivbetrieb?

Mit aktueller Version ab 1.83.7, korrekt gesetztem Master-Key über Umgebungsvariablen und einem vorgeschalteten Reverse Proxy mit TLS lässt sich der Gateway sicher betreiben. Die im Mai 2026 bekannt gewordene Schwachstelle CVE-2026-42271 ist seit dieser Version geschlossen, ältere Versionen sollten nicht mehr produktiv laufen.

Kann ich LiteLLM ohne Docker betreiben?

Ja, der Proxy lässt sich direkt über pip installieren und als Python-Prozess starten, wie in Schritt 2 und 5 gezeigt. Für dauerhaften Betrieb empfiehlt sich trotzdem eine Prozessverwaltung wie systemd, damit der Dienst nach einem Absturz automatisch neu startet.

Wie funktioniert die Kostenkontrolle in LiteLLM?

Der Gateway berechnet aus den Token-Zahlen jeder Antwort die geschätzten Kosten und zieht sie von einem konfigurierbaren Budget ab, das sowohl global als auch pro virtuellem Key gesetzt werden kann. Ist das Budget aufgebraucht, lehnt der Proxy weitere Anfragen ab, bis die nächste Abrechnungsperiode beginnt.

Ist LiteLLM DSGVO-konform einsetzbar?

LiteLLM selbst verarbeitet keine Daten dauerhaft, sondern leitet Anfragen weiter, kann aber durch zentrales Logging und Guardrails zur Einhaltung von Datenschutzanforderungen beitragen. Eine vollständige DSGVO-Konformität hängt von der gesamten Systemarchitektur ab, nicht allein vom Gateway, und sollte im Zweifel mit dem eigenen Datenschutzbeauftragten geprüft werden.

Was ist der Unterschied zwischen SDK-Modus und Proxy-Modus?

Im SDK-Modus wird LiteLLM direkt als Python-Bibliothek in eine einzelne Anwendung eingebunden, ohne eigenen Server. Im Proxy-Modus läuft LiteLLM als eigenständiger Dienst, an den mehrere Anwendungen und Teams gleichzeitig über HTTP anfragen, inklusive zentraler Budgets, virtueller Keys und Logging über alle angebundenen Systeme hinweg.

Was tun, wenn CVE-2026-42271 die eigene Version betrifft?

Prüfen Sie zunächst mit litellm --version, ob die installierte Version zwischen 1.74.2 und 1.83.6 liegt. Ist das der Fall, aktualisieren Sie umgehend auf mindestens 1.83.7 und starten Sie den Proxy neu. Prüfen Sie danach in den Logs, ob vor dem Update ungewöhnliche Zugriffe auf die MCP-Testendpunkte aufgetreten sind, und rotieren Sie sicherheitshalber alle Master- und virtuellen Keys, falls Sie eine Kompromittierung nicht ausschließen können.