LiteLLM als AI Gateway: 100+ LLM-Anbieter über eine Schnittstelle
Selbst gehostetes KI-Gateway mit Rust-Kern und Python-SDK, das über 100 LLM-Anbieter im OpenAI-Format aufruft und Kostenverfolgung, Guardrails und Lastverteilung bietet.
Auf einen Blick
- Was ist das?
- Ein Python-SDK und ein selbst gehosteter Proxy-Server, die OpenAI, Anthropic, Gemini, Bedrock und Azure im OpenAI-Format ansprechbar machen, mit Virtual Keys, Ausgabenverfolgung, Guardrails, Lastverteilung und A2A- sowie MCP-Anbindung.
- Für wen ist es gedacht?
- LiteLLM passt zu Plattformteams, die LLM-Zugriffe mehrerer Teams über einen zentralen, selbst gehosteten Dienst mit Kostenkontrolle und Zugriffsschlüsseln abwickeln wollen. Es passt weniger zu Anwendungen mit einem festen Anbieter, bei denen das direkte SDK weniger Bewegungsteile mitbringt.
- Darf ich es kommerziell nutzen?
- Erst prüfen. Die Lizenz dieses Repositorys ordnen wir nicht automatisch ein; lesen Sie vor jeder kommerziellen Nutzung die LICENSE-Datei.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Das Reibungsproblem: SDKs, Auth-Muster und Fehlerformen pro Anbieter
Wer mehrere LLM-Anbieter nutzt, sammelt nebenbei einen Zoo an SDKs, Authentifizierungsmustern, Anfrageformaten und Fehlertypen, und jeder Anbieterwechsel schreibt Code um. LiteLLM von BerriAI adressiert genau diese Reibung: Es ist laut README ein quelloffenes AI Gateway, das über 100 LLM-Anbieter, OpenAI, Anthropic, Gemini, Bedrock, Azure und weitere, in einem einzigen, vereinheitlichten Interface im OpenAI-Format erreichbar macht. Code, der einmal gegen dieses Format geschrieben ist, zeigt ohne Umschreiben auf andere Anbieter.
Die Verbreitung ist erheblich: Nach Repository-Metadaten zählt das Projekt rund 57.500 Sterne, 11.000 Forks, aber auch 4.883 offene Issues, ein Hinweis auf die Wartungsfläche, die solche Anbieterschnittstelle erzeugen. Als Open-Source-Anwender nennt das README Netflix. Die Release-Kanäle zeigen ein intensives Tempo, v1.99.0-rc.1 erschien am 23. August 2026, danach folgten v1.100.0-dev.1 und v1.100.0-dev.2.
Python SDK mit uv add litellm: Modellpräfixe statt SDK-Zoo
Die SDK-Variante bindet LiteLLM direkt in den Anwendungscode ein. Installation laut README mit uv add litellm, danach macht die completion-Funktion aus litellm den Unterschied nur noch über das Modellpräfix aus: completion(model="openai/gpt-4o", ...) für OpenAI, completion(model="anthropic/claude-sonnet-4-20250514", ...) für Anthropic. Die API-Schlüssel liegen in Umgebungsvariablen wie OPENAI_API_KEY und ANTHROPIC_API_KEY, der Rest des Aufrufs ist identisch.
Diese Präfixkonvention ist der eigentliche Wert des SDKs: Der Anbieterwechsel wird von einer Codestrukturfrage zu einem Stringwechsel, und Fallback-Ketten lassen sich über dieselbe Notation ausdrücken. Für den direkten Bibliothekseinsatz ist das der leichteste Einstieg, weil kein zusätzlicher Dienst entsteht und keine Infrastruktur betrieben werden muss. Die Grenze liegt in der Teamdimension: Kostenkontrolle, Zugriffsschlüssel und zentrale Protokolle entstehen so nicht, dafür braucht es die zweite Variante.
AI Gateway als Proxy: litellm --model gpt-4o auf Port 4000
Die Gateway-Variante installiert das Projekt als Proxy-Server, laut README mit uv tool install "litellm[proxy]" und dem Startbefehl litellm --model gpt-4o. Der Proxy lauscht dann auf Port 4000, und bestehende OpenAI-Clients zeigen einfach auf ihn: openai.OpenAI(api_key="anything", base_url="http://0.0.0.0:4000"), danach verhält sich der Aufruf wie ein normaler Chat-Completion-Call.
Diese Architektur verschiebt die Verantwortung: Der Code in der Anwendung bleibt provideragnostisch, der Austausch des eigentlichen Modells passiert in der Gateway-Konfiguration. Für Teams ist das der Punkt, an dem LiteLLM zum Steuerungspunkt wird, hier laufen alle Aufrufe zusammen und lassen sich messen, beschränken und umleiten. Das README verlinkt für den Einstieg ein End-to-End-Tutorial unter docs.litellm.ai/docs/proxy/docker_quick_start, das Virtual Keys und die erste Anfrage behandelt.
Virtual Keys, Spend Tracking und Guardrails im Proxy
Als produktionsreif beschreibt das README das Gateway mit einem konkreten Funktionsbündel: Virtual Keys für die Zugriffskontrolle, Ausgabenverfolgung und Kostenverwaltung pro Projekt und Nutzer, Guardrails, Lastverteilung über Bereitstellungen hinweg und ein Admin-Dashboard ab Auslieferung. Damit deckt der Proxy die klassischen Anforderungen einer API-Gateway-Schicht ab, nur eben für Modellaufrufe statt für gewöhnliche Dienste.
Der praktische Unterschied zum reinen SDK-Betrieb zeigt sich bei mehreren Konsumenten: Jedes Team erhält eigene Schlüssel, die Ausgaben lassen sich zuordnen, und Fehlverhalten wird am Gateway sichtbar, statt in einzelnen Anwendungen. Das README beschreibt außerdem Router-Logik mit Wiederholungs- und Fallback-Mustern über Bereitstellungen hinweg sowie OpenAI-kompatible Ausnahmebehandlung im SDK. Für protokollierte Aufrufe nennt es projektspezifische Anpassung der Logging- und Schutzmechanismen.
A2A-Protokoll und MCP-Bridge: Agenten und Werkzeuge ans Gateway
Zwei Funktionsbereiche erweitern das Angebot über simple Chat-Aufrufe hinaus. Das A2A-Protokoll (Agent to Agent) erlaubt laut README das Anbinden von Agenten aus LangGraph, Vertex AI Agent Engine, Azure AI Foundry, Bedrock AgentCore und Pydantic AI, pro Agent mit protocolVersion 1.0 oder 0.3. Der Aufruf läuft dann über die A2A-SDK-Clientfabrik an eine Adresse der Form http://localhost:4000/a2a/my-agent, authentifiziert mit einem Bearer-Token, das einem LiteLLM Virtual Key entspricht.
Der zweite Bereich ist das Model Context Protocol. Im SDK lädt experimental_mcp_client mit load_mcp_tools(session, format="openai") Werkzeuge eines MCP-Servers in OpenAI-Format, über einen Stdio-Kanal mit ClientSession. Auf der Gateway-Seite lassen sich MCP-Server als Werkzeuge bereitstellen, die über /chat/completions aufrufbar sind, das README zeigt das Beispiel eines GitHub-MCP-Servers. Damit wird das Gateway zur Vermittlungsstelle zwischen Modellen und Werkzeugservern, was in Agentenarchitekturen die Zahl der direkten Verbindungen reduziert.
Der 8ms-P95-Wert aus dem README und die Release-Reihenfolge
Das README nennt für das Gateway 8 Millisekunden P95-Latenz bei 1.000 Requests pro Sekunde und verlinkt dafür eine Benchmark-Seite unter docs.litellm.ai/docs/benchmarks. Diese Zahl ist eine Herstellerangabe und sollte als solche gelesen werden, sie beschreibt den Gateway-Overhead unter definierten Bedingungen, nicht die Antwortzeit der Modelle dahinter.
Interessant ist auch die Veröffentlichungspraxis: Die Releases-Seite zeigt v1.99.0-rc.1 vom 23. August 2026, dann v1.100.0-dev.1 vom 26. und v1.100.0-dev.2 vom 28. August 2026. Der Entwicklungszweig trägt den Namen litellm_internal_staging, was auf einen internen Staging-Ablauf hinweist. Wer das Gateway in Produktion fährt, sollte daher Release-Kanäle bewusst wählen und Upgrades gestaffelt testen, die Dichte der Veröffentlichungen lässt sonst kaum stabile Zustände zu.
Lizenzspaltung um enterprise/ und die Alternative direkter SDKs
Die Lizenzstruktur verdient eine eigene Betrachtung. Nach dem Lizenzauszug stehen Inhalte außerhalb des enterprise/-Verzeichnisses unter der MIT-Lizenz, während das enterprise-Verzeichnis, sofern vorhanden, unter einer separaten Lizenz steht, die in enterprise/LICENSE definiert ist. Das README erwähnt dazu eine Enterprise-Stufe mit Funktionen unter kommerzieller Lizenz, Funktionspriorisierung, Support, SLAs und Single Sign-On. Für den Selbstbetrieb bedeutet das: Der Kern ist frei nutzbar und änderbar, aber nicht jede im Dashboard sichtbare Funktionalität liegt unter MIT.
Die konkrete Alternative zum Gateway ist der Verzicht auf die Schicht: direkte Anbietersoftware in der Anwendung, ohne Proxy. Das spart einen laufenden Dienst, eine Datenbank und Betriebsverantwortung, kostet aber jede der oben genannten Funktionen, Virtual Keys, zentrale Ausgabenkontrolle, Fallback über Anbieter hinweg und Anbieterwechsel ohne Umbau. Für eine Anwendung mit einem festen Modell ist der direkte Weg schlicht einfacher, für mehrere Teams und Anbieter überwiegt beim Gateway die Steuerungsmacht.
Redaktionelles Fazit
LiteLLM passt zu Plattformteams, die LLM-Zugriffe mehrerer Teams über einen zentralen, selbst gehosteten Dienst mit Kostenkontrolle und Zugriffsschlüsseln abwickeln wollen. Es passt weniger zu Anwendungen mit einem festen Anbieter, bei denen das direkte SDK weniger Bewegungsteile mitbringt. Vor dem Ausbau sollte man den Proxy mit uv tool install "litellm[proxy]" aufsetzen, eine Virtual Key gegen die eigenen Modellpräfixe prüfen und die Anbietertabelle unter docs.litellm.ai/docs/providers gegen die tatsächlich genutzten Endpunkte abgleichen, denn die Abdeckung variiert je nach Anbieter.
Community-Notizen