Wer gleichzeitig OpenAI, Claude, DeepSeek und Gemini anbindet, steht selten vor der Frage, welches Modell das beste ist, sondern davor, dass sich Anfrageformat, Keys und Abrechnungslogik jedes SDK unterscheiden. LiteLLM ist genau dafür entstanden: ein Open-Source-Projekt, das mehrere Anbieter hinter einer OpenAI-kompatiblen Schnittstelle vereinheitlicht und einen selbst betreibbaren Gateway bereitstellt.

Dieser Artikel erklärt, was LiteLLM ist, zeigt eine minimale funktionsfähige Konfiguration, beschreibt Routing und Key-Verwaltung, das Deployment und hilft bei der Entscheidung zwischen Selbstbetrieb und Managed Gateway.

Hinweis: LiteLLM ist ein Open-Source-Projekt seines Rechteinhabers; OpenAI, Anthropic, DeepSeek und andere sind Marken der jeweiligen Rechteinhaber. Dieser Artikel beschreibt den üblichen Stand im Oktober 2026; konkrete Parameter richten sich nach der offiziellen Dokumentation.

1. Was LiteLLM eigentlich ist

LiteLLM hat zwei Formen:

  • Python SDK: einheitliche completion-Funktion im Code für Modelle verschiedener Anbieter.
  • Proxy-Gateway: ein eigenständiger Dienst, der OpenAI-kompatible /v1/chat/completions bereitstellt, sodass jeder Client mit konfigurierbarer Base URL angebunden werden kann.

Das Projekt löst drei Dinge: Protokollanpassung, Routing und Abrechnung. Es löst nicht die Frage, ob ein Modell fachlich gut ist. Anders gesagt: LiteLLM ist die Leitung, nicht das Modell.

Wesentliche Fähigkeiten:

Fähigkeit Nutzen
Einheitliches Protokoll Modelle mehrerer Anbieter über das OpenAI-Format
Routing und Lastverteilung Ein Modellname verteilt auf mehrere Deployments
Failover Bei Ausfall des Hauptmodells auf ein Ersatzmodell wechseln
Virtuelle Keys Eigene Keys und Budgets für Teams oder Projekte
Nutzung und Kosten Anfragen, Tokens und Ausgaben erfassen
Log-Callbacks Anbindung an Langfuse, OpenTelemetry und ähnliche Systeme

2. Minimalbetrieb: Start mit pip

Zuerst eine virtuelle Umgebung anlegen, dann das Paket mit Proxy-Unterstützung installieren:

python3 -m venv .venv
source .venv/bin/activate
pip install "litellm[proxy]"

Eine minimale config.yaml schreiben:

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

  - model_name: deepseek-chat
    litellm_params:
      model: deepseek/deepseek-chat
      api_key: os.environ/DEEPSEEK_API_KEY

litellm_settings:
  drop_params: true

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY

Starten:

export ANTHROPIC_API_KEY="sk-ant-IHR-SCHLUESSEL"
export DEEPSEEK_API_KEY="sk-IHR-SCHLUESSEL"
export LITELLM_MASTER_KEY="sk-litellm-lokaler-verwaltungsschluessel"
litellm --config config.yaml --port 4000

model_name ist der nach außen sichtbare Name, litellm_params.model das tatsächliche Upstream-Modell, üblicherweise im Format „Anbieter/Modellname“. os.environ/XXX liest aus einer Umgebungsvariable. Keys sollten nicht direkt in die YAML geschrieben und ins Repository eingecheckt werden.

Nach dem Start mit dem OpenAI SDK auf das lokale Gateway zeigen:

from openai import OpenAI

client = OpenAI(
    api_key="sk-litellm-lokaler-verwaltungsschluessel",
    base_url="http://127.0.0.1:4000",
)
resp = client.chat.completions.create(
    model="claude-sonnet",
    messages=[{"role": "user", "content": "Antworten Sie nur mit OK"}],
)
print(resp.choices[0].message.content)

3. Modell-Routing und Failover

In der Produktion hängt selten nur ein Upstream am Gateway. Eine übliche Konfiguration:

router_settings:
  routing_strategy: simple-shuffle
  num_retries: 2
  timeout: 600
  fallbacks:
    - claude-sonnet: ["deepseek-chat"]

Die Parameter im Einzelnen:

  • routing_strategy: Auswahl zwischen mehreren Deployments desselben Modells; simple-shuffle ist ein üblicher Einstieg.
  • num_retries: Anzahl der Wiederholungen; jede Wiederholung verursacht echte Kosten.
  • timeout: Zeitlimit pro Anfrage, ausgerichtet am langsamsten Geschäftspfad.
  • fallbacks: Wechsel auf ein Ersatzmodell, wenn das Hauptmodell nicht verfügbar ist.

Failover ist nicht kostenlos. Ersatzmodelle können sich in Ausgabestil, Kontextlänge und Tool-Fähigkeiten unterscheiden; die Fachseite muss das akzeptieren können. Bei strengen Formatvorgaben ist ein klarer Fehler besser als eine stille Degradierung.

4. Virtuelle Keys und Budgets

Wenn ein Team einen gemeinsamen Master-Key verwendet, ist das der Anfang eines Betriebsunfalls. Richtig ist ein virtueller Key pro Projekt mit begrenzten Modellen und Budget:

curl -X POST "http://127.0.0.1:4000/key/generate" \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "models": ["claude-sonnet"],
    "max_budget": 20,
    "duration": "30d",
    "metadata": {"project": "demo"}
  }'

Der zurückgegebene Key geht an das Fachteam, der Master-Key bleibt ausschließlich beim Betrieb. Einheit und Währung des Budgets richten sich nach der LiteLLM-Dokumentation; hier wird nur die Feldstruktur gezeigt, keine Preisangabe.

5. Docker-Deployment und Checkliste vor dem Livegang

Für einen Test auf einem Einzelrechner genügt ein Container:

docker run -d --name litellm \
  -p 4000:4000 \
  -v "$(pwd)/config.yaml:/app/config.yaml" \
  -e ANTHROPIC_API_KEY \
  -e DEEPSEEK_API_KEY \
  -e LITELLM_MASTER_KEY \
  ghcr.io/berriai/litellm:main-latest \
  --config /app/config.yaml

Vor dem Livegang mindestens diese Punkte prüfen:

  1. Das Gateway nicht direkt ins öffentliche Netz stellen; Nginx oder Caddy für TLS und Zugriffskontrolle davorsetzen.
  2. Einen starken Zufallswert als Master-Key verwenden und nicht im Repository ablegen.
  3. Für persistente Nutzungsdaten PostgreSQL anbinden, sonst gehen nach einem Neustart Teile der Statistik verloren.
  4. Log-Rotation und Festplattenwarnungen einrichten; Anfrage-Logs wachsen schnell.
  5. Einen Health-Check vorsehen: curl http://127.0.0.1:4000/health.
  6. Vor Upgrades das Changelog lesen und Image-Versionen fest taggen, nicht dauerhaft latest verwenden.

Ein leicht übersehener Punkt: Das Gateway ist ein neuer Single Point of Failure. Fällt es aus, fallen alle Modelle aus. Mindestens Prozessüberwachung, automatischen Neustart und einen unabhängigen Alarmkanal einplanen.

6. Logs und Kosten: nicht erst bei der Rechnung handeln

Ein versteckter Wert des Gateways ist die Protokollierung der Aufrufe. LiteLLM kann Modell, Tokens, Latenz und Kosten jeder Anfrage erfassen und nach Key, Team und Tags aggregieren. Dafür sind drei Schritte nötig:

  1. Eine Datenbank konfigurieren, damit Kostendaten dauerhaft gespeichert werden und nicht nur im Speicher liegen.
  2. Anfragen taggen, etwa den Projektnamen in den Metadaten, sonst lässt sich am Monatsende nicht nach Projekt aufteilen.
  3. Ein Observability-Backend anbinden, um Tracing und Logs zentral zu sammeln.

Beispielkonfiguration:

litellm_settings:
  success_callback: ["langfuse"]
  failure_callback: ["langfuse"]

general_settings:
  database_url: os.environ/DATABASE_URL

Zwei Hinweise: Erstens muss der Callback-Dienst selbst hochverfügbar sein, denn ein blockierender Callback kann die Hauptanfrage verzögern. Zweitens können Logs Originaltexte von Nutzern enthalten; Aufbewahrungsfristen und Zugriffsrechte vorab festlegen und Produktionslogs nicht unbegrenzt speichern.

Beim Thema Kosten gilt: Das Gateway macht Ausgaben sichtbar, aber nicht automatisch kleiner. Wirklich sparen lässt sich durch die richtige Modellwahl, komprimierte Kontexte und begrenzte Wiederholungen.

7. Selbst betreiben oder Managed Gateway

Dimension Eigenes LiteLLM Managed AI-Gateway
Datenpfad Vollständig selbst kontrolliert Über den Anbieter
Anfangskosten Niedrig, nach Installation lauffähig Registrierung und los
Langfristiger Betrieb Upgrade, Backup, Monitoring in eigener Hand Beim Anbieter
Abrechnung und Rechnung Upstream selbst anbinden Einheitliche Rechnung in RMB
Flexibilität Hoch, Quellcode und Routing anpassbar Durch Plattformgrenzen begrenzt
Verantwortung bei Störungen Selbst Nach den Servicebedingungen

Eine praktische Einordnung:

  • Mit Betriebsteam, Compliance-Anforderungen und Bedarf an tiefem Routing-Customizing: selbst betreiben.
  • Kleines Team, das nur Keys und Abrechnung vereinheitlichen will und nachts keine Container reparieren möchte: Managed Gateway.
  • Auch möglich: zuerst Managed für das Geschäft nutzen und den Selbstbetrieb prüfen, wenn das Volumen stabil ist.

Teams in China müssen zusätzlich das Netz berücksichtigen. Ein selbst betriebener Gateway löst die Erreichbarkeit der Upstreams nicht; ist der Upstream instabil, verstärkt das Gateway die Fehler nur. Dann sind „Selbstbetrieb mit erreichbarem Upstream“ oder „direkt Managed Gateway“ realistischer.

Wenn Sie keinen Quellcode ändern müssen und nur einen OpenAI-kompatiblen Zugang, einheitliche Keys und eine Rechnung in RMB möchten, ist ein Managed Gateway meist am Registrierungstag lauffähig; LiteLLM eignet sich eher als langfristig gepflegte Infrastruktur. Beides kann koexistieren: intern LiteLLM für das Routing, nach außen ein Managed Gateway.

8. Häufige Fragen

Ist LiteLLM kostenlos?

Der Open-Source-Teil lässt sich selbst deployen, die Aufrufkosten der Upstream-Modelle fallen jedoch weiter an; Preise für Enterprise-Funktionen und Managed Services richten sich nach dem Anbieter.

Worin unterscheidet es sich von One API und New API?

One API und New API sind stärker auf Kontingentverteilung an viele Nutzer ausgerichtet, LiteLLM stärker auf Multi-Modell-Routing und SDK-Vereinheitlichung. Beide bieten einen OpenAI-kompatiblen Zugang; die Wahl hängt davon ab, ob Abrechnung und Verteilung oder Routing im Vordergrund stehen.

Werden native Tool-Aufrufe von Claude unterstützt?

Das hängt von Version und Upstream-Anpassung ab. Komplexe Tool-Aufrufe und Caching mit echten Anfragen prüfen, nicht nur anhand der Dokumentation.

Spart ein selbst betriebener Gateway Geld?

Nicht unbedingt. Gespart werden Plattformgebühren, bezahlt werden Server, Betrieb und Ausfallzeit. Bei geringem Volumen ist Managed meist wirtschaftlicher.

Was ist im Produktivbetrieb mindestens nötig?

TLS, Master-Key, virtuelle Keys, Budgetobergrenzen, Logs, Datenbank-Backups und Health-Checks – an keinem dieser Punkte sollte es fehlen.

Nächste Schritte

Wenn Sie zuerst Multi-Modell-Aufrufe testen möchten, ohne Container selbst zu betreiben, können Sie sich beim ZSQH AI Gateway registrieren und die erste Anfrage über den OpenAI-kompatiblen Zugang senden; Modelle und Preise richten sich nach den Modellpreisen. Ob ein eigener LiteLLM-Betrieb sinnvoll ist, lässt sich entscheiden, sobald Volumen und Compliance-Anforderungen klar sind.

Weiterlesen: