Verbinden Sie Anwendungen über ein selbst gehostetes KI-Gateway oder Python-SDK mit mehreren Modellanbietern. Verwalten Sie virtuelle Schlüssel, Routing, Nutzung und Teambudgets mit optionaler Enterprise-Governance.
Hast du dieses Tool genutzt? Bewerte es
Hast du dieses Tool genutzt? Bewerte es
LiteLLM ist ein quelloffenes KI-Gateway und Python-SDK, das Anwendungen mit mehreren Anbietern großer Sprachmodelle verbindet. Sein LLM-Proxy bietet einen gemeinsamen OpenAI-kompatiblen Endpunkt, während das SDK die Integration direkt in einer Python-Anwendung umsetzt. Enterprise ergänzt denselben Kerncode um Governance, Sicherheitsfunktionen und Support.
Das Gateway sitzt zwischen Anwendung und ausgewähltem Modellanbieter: Es empfängt die Anfrage, leitet sie weiter und liefert die Antwort im OpenAI-Format zurück. Diese Trennung bestimmt das Produkt. LiteLLM stellt die Zugriffs- und Verwaltungsebene bereit; das Modell hinter einer konfigurierten Route übernimmt die Inferenz. Ein kompatibler API-Endpunkt ist eine Integrationsfähigkeit und kein enthaltenes Nutzungskontingent für alle erreichbaren Modelle.
Das SDK passt Anbieter innerhalb einer Anwendung an. Ein gemeinsames Gateway zentralisiert Zugriff, Nutzungszuordnung und Routing für mehrere Clients.
Das aktuelle kommerzielle Angebot konzentriert sich auf Selbsthosting. Das kostenlose Gateway und die kostenpflichtige Enterprise-Lizenz erfüllen unterschiedliche Verwaltungs- und Supportanforderungen. Es sind Infrastrukturangebote statt Chat-Abonnements für Verbraucher.
Das SDK stellt Vervollständigung, Embeddings und Bilderzeugung über eine gemeinsame Schnittstelle bereit, ergänzt um einen Router, OpenAI-kompatible Exceptions und Observability-Callbacks.
stream=True werden erzeugte Abschnitte laufend zurückgegeben, sodass ein Client die Antwort schrittweise anzeigen kann.Modellrouting umfasst Abkühlzeiten, Fallbacks, Zeitlimits und Wiederholungen über Deployments und Anbieter hinweg. Wiederholungen können feste oder exponentielle Wartezeiten verwenden. Redis kann im Produktivbetrieb gemeinsame Abkühl- und Nutzungszustände speichern. Diese Mechanismen reagieren auf nicht verfügbare oder ratenbegrenzte Deployments; der Erfolg eines Fallbacks hängt weiter von der Verfügbarkeit der vorgelagerten Systeme ab.
Der Router bietet gewichtete Auswahl, ratenlimitbewusstes Routing, Auswahl der am wenigsten ausgelasteten Instanz sowie latenz- und kostenbasiertes Routing. Gewichtete, nach Latenz gewählte und nach Preis gewählte Pools verhalten sich unterschiedlich. Eine einzelne Strategie optimiert nicht alle Kriterien zugleich.
Das MCP Gateway stellt einen festen Endpunkt für MCP-Tools bereit und steuert den Zugriff nach Schlüssel und Team. Dokumentierte Operationen umfassen das Auflisten und Aufrufen von Tools, Prompts und Ressourcen. Unterstützte Transporte sind Streamable HTTP, SSE und Standardein-/ausgabe. Mehrere Tool-Server können den Zugriffsendpunkt gemeinsam nutzen.
Das AI Gateway verarbeitet auch A2A-Agenten. Modellrouten, Tool-Aufrufe und Agentenendpunkte bleiben verschiedene vorgelagerte Ressourcen, selbst wenn sie dieselbe Gateway-Adresse verwenden.
Die Verwaltung virtueller Schlüssel erfordert eine Postgres-Datenbank und einen Hauptschlüssel als Administratorschlüssel des Proxys. Die dokumentierte Einrichtung nutzt DATABASE_URL für die Verbindung und LITELLM_MASTER_KEY zur Verwaltung. Anschließend können Schlüssel über /key/generate erzeugt werden.
model_list-Einträgen, der Postgres-Verbindung und dem Hauptschlüssel unter general_settings.litellm --config /path/to/config.yaml und der gespeicherten Konfigurationsdatei./key/generate, mit dem Hauptschlüssel im Bearer-Autorisierungsheader, JSON-Inhaltstyp und einer models-Liste, die den Modellzugriff des erzeugten Schlüssels definiert.base_url auf die Gateway-URL und api_key auf den erzeugten virtuellen Schlüssel.Der Hauptschlüssel verwaltet den Proxy; ein virtueller Schlüssel authentifiziert eine Anwendung am Proxy. Anbieterzugangsdaten autorisieren die konfigurierte vorgelagerte Verbindung. Diese Zugangsdaten haben unterschiedliche Geltungsbereiche.
Die Ausgabenverfolgung ordnet Modellkosten anbieterübergreifend Schlüsseln, Nutzern und Teams zu. LiteLLM berechnet Preise bekannter Modelle automatisch und berücksichtigt anbieterspezifische Tarifstufen, wenn die Antwort entsprechende Metadaten enthält. So lässt sich der Verbrauch von Anwendungen oder Abteilungen auch bei gemeinsamen Anbieterkonten trennen.
Die Berechnung hängt von der Modellkostentabelle und aktuellen Preisdaten ab. Gateway-Ausgaben sind eine berechnete Betriebsaufzeichnung und keine Rechnung des vorgelagerten Anbieters.
Lastverteilung kann Aufrufe über Azure, Bedrock und andere Anbieter-Deployments verteilen und bei Fehlern in einer anderen Region wiederholen. Ein gemeinsamer Modellalias kann dadurch mehrere konfigurierte Deployments vertreten, statt jeder Anwendung jeden Endpunkt einzeln zur Auswahl anzubieten.
Dies erhält bei Deployment-Ausfällen einen Anfragepfad. Das gewählte Modell und der Anbieter bestimmen weiterhin die Antwort; ein gemeinsamer Alias macht ihre Ausgaben nicht identisch.
Laut Dokumentation ist SSO für bis zu fünf Nutzer kostenlos; darüber hinaus ist eine Enterprise-Lizenz erforderlich. Diese Identitätsfunktionsschwelle ist von der Verfügbarkeit des kostenlosen Gateways getrennt.
Bei der Erfassung am 23. Oktober 2026 zeigte eine externe Produktstartplattform eine Bewertung von 5.0 aus 24 LiteLLM-Rezensionen. Diese kleine produktbezogene Stichprobe misst weder Latenz noch Sicherheit oder Betriebskosten eines Deployments.
OpenAI-kompatible Clients verbinden sich über die Gateway-Basis-URL und einen virtuellen Schlüssel. Jeder kompatible Client kann diese API ohne eingebettetes Python-SDK aufrufen.
LiteLLM unterstützt auch interne, feinabgestimmte und selbst gehostete Modelle hinter demselben Schlüssel. Interne und kommerzielle Endpunkte können ein Zugriffsmuster teilen und trotzdem eigenes Hosting, eigene Zugangsdaten und eigenes Verhalten behalten.
Produktive Bereitstellungspfade umfassen Helm auf Amazon EKS, Google GKE und Azure AKS. Offizielle Terraform-Module sind für AWS und GCP dokumentiert. Für Azure nennt der Leitfaden AKS mit Helm und erklärt, dass es kein offizielles Azure-Terraform-Modul gibt.
Zwei Service-Architekturen sind dokumentiert. Ein monolithisches Image bedient Modellverkehr, Verwaltungs-APIs und Oberfläche gemeinsam. Eine Microservices-Architektur trennt Gateway, Backend und Oberfläche. PostgreSQL speichert Schlüssel, Teams, Nutzer, Ausgabenprotokolle und Konfiguration und ist für Proxy-Authentifizierung und Tracking erforderlich. Redis teilt Ratenlimit-, Routing- und Cache-Zustände und wird laut Dokumentation benötigt, sobald mehr als eine Instanz läuft.
Der Betreiber betreibt neben der Anfrageweiterleitung auch Zustandsspeicher und Verwaltungsdienst.
Die am 23. Oktober 2026 erfassten Preise trennen einen kostenlosen selbst gehosteten Kern von einer jährlichen Enterprise-Lizenz. Enterprise-Preise richten sich nach jährlicher Gateway-Anfragekapazität, Deployment-Architektur und Supportbedarf; laut Beschreibung erfolgt die Abrechnung niemals pro Token. Die geprüfte Preisseite veröffentlicht keinen festen Enterprise-Abonnementbetrag.
| Angebot | Veröffentlichtes Zugangsmodell | Enthaltener Umfang |
|---|---|---|
| Open Source | $0; dauerhaft kostenlos; selbst gehostet | Virtuelle Schlüssel, Nutzer und Teams, Ausgabenverfolgung, Budgets, Ratenlimits, Fallbacks, Anfrage-/Antwortprotokolle und Prometheus-Metriken |
| Enterprise | Jährliches Vertriebsangebot nach Deployment und Anfragekapazität | Gateway-Kern plus zusätzliche Identitäts-, Audit-, Geheimnisverwaltungs-, Administrations-, Mehrregionen- und Supportfunktionen |
Enterprise verwendet einen Lizenzschlüssel im selben Gateway-Image, statt eine Migration zu einem separaten gehosteten Produkt zu verlangen. Aufgeführt sind SSO und SCIM, Audit-Logs, Organisations- und Teamadministratoren, Secret-Manager, IP-Freigabelisten, teambezogene Protokollierung, Mehrregionenfunktionen und Support-SLAs.
Ein Enterprise-Testschlüssel für 30 Tage ist per E-Mail erhältlich. Beschaffung ist direkt, über AWS Marketplace oder autorisierte Händler möglich. Der Test gewährt zeitlich begrenzten Enterprise-Zugriff.
Standard-Enterprise-Support umfasst einen eigenen Slack- oder Teams-Kanal mit LiteLLM-Ingenieuren. Veröffentlichte Zeiten sind montags bis freitags 9 bis 21 Uhr PST, ohne garantierte Antwortzeit. Garantierte 24/7-Antwort-SLAs sind eine zusätzliche kostenpflichtige Option.
Die vorgelagerte Lizenz stellt Code außerhalb des enterprise-Verzeichnisses und der genannten Einschränkungen unter MIT; für Enterprise-Inhalte gilt eine separate Lizenz. MIT erlaubt Nutzung, Änderung, Verbreitung, Unterlizenzierung und Verkauf, unter Bedingungen wie der Beibehaltung von Urheberrechts- und Erlaubnishinweis.
Die Angabe $0 gilt für die selbst gehostete Softwarelizenz. Infrastruktur und vorgelagerte Inferenz sind separate Architekturteile; Anbieterkompatibilität belegt kein enthaltenes Token-Guthaben oder Modellkontingent.
Portkey positioniert sich als einheitliche Schnittstelle für generative KI-Anwendungen mit Werkzeugen für Kontrolle, Transparenz und Sicherheit. Der genannte Umfang verbindet Modellzugriff mit Überwachung und Governance.
Der Vergleich betrifft die Betriebsebene ebenso wie den API-Zugriff. LiteLLM liefert selbst gehostetes Gateway und Python-SDK mit optionaler Enterprise-Aktivierung; Funktionsüberschneidungen belegen keine gleichwertige Lizenzierung oder Unterstützung.
OpenRouter bietet Zugriff auf Hunderte Modelle über einen API-Endpunkt, mit automatischen Fallbacks und Auswahl einer kostengünstigen Option für eine Anfrage. LiteLLM realisiert gemeinsamen Modellzugriff durch Software im Deployment der Organisation, mit deren eigenen Anbietern und Zugriffskontrollen.
Die Angebote überschneiden sich bei der API-Aggregation. Modellkataloge allein beschreiben nicht den Unterschied zwischen Python-Bibliothek, betriebenem Gateway und Service-Endpunkt.
drop_params nicht aktiviert ist. Diese Einstellung entfernt nicht unterstützte OpenAI-Parameter; andere Parameter gelten als anbieterspezifische Anfragefelder. Ein gemeinsames Format garantiert nicht, dass jeder Anbieter jede Modellfunktion implementiert.LITELLM_SALT_KEY verschlüsselt Anbieterzugangsdaten in der Datenbank. Der Leitfaden erklärt, dass eine Änderung nach Hinzufügen von Modellen diese Zugangsdaten unlesbar macht. Das unterscheidet sich von der Rotation eines virtuellen Schlüssels oder Anbieterschlüssels.hide_secrets und openai_moderations, erfordern Enterprise.Das Abschalten der Nachrichtenprotokollierung verhindert die Übertragung von Nachrichten und Antworten an den konfigurierten Protokollierungsanbieter; Anfragemetadaten wie Ausgaben werden weiterhin erfasst. Inhaltsredaktion erhält Betriebsmetadaten. Inferenzanbieter und konfigurierte Protokollziele bleiben getrennte Teile des Datenpfads.
Nutzungstelemetrie ist ab Version v1.107.0 als standardmäßig deaktiviert dokumentiert; vor Auswahl eines Ziels erfolgt keine Aufzeichnung. Es gibt keinen HTTP-Standardendpunkt. Aktivierte Gruppen können aggregierte Zähler in der Deployment-Datenbank halten oder an den konfigurierten HTTP-Endpunkt senden. Telemetrie bedeutet nicht automatisch eine Meldung an LiteLLM.
Das erklärte Telemetrieschema schließt Prompts, Vervollständigungen, API-Schlüssel, Nutzer- und Team-IDs, Modellnamen, IP-Adressen, Headerwerte und Anfrageinhalte aus. Tokenzahlen werden je Zeile summiert statt je Anfrage gespeichert. Diese Ausschlüsse betreffen Telemetrie und nicht jeden Protokollierungs- oder Inferenzpfad.
Enterprise-Verbindungen haben eine weitere Grenze. Laut Compliance-Dokumentation sendet die Messung abrechenbarer Anfragen die Zahl erfolgreicher Anfragen an einen LiteLLM-Kollektor; Lizenzprüfungen können den Lizenzserver verwenden oder eine signierte Nutzlast offline validieren. In diesem Messkontext verlassen laut Dokumentation weder Prompts noch Antworten, virtuelle Schlüssel oder der Lizenzschlüssel das Deployment. Diese Messung ist von optionaler Nutzungstelemetrie getrennt.
Die bei dieser Erfassung geprüften Sicherheits-, Telemetrie-, Protokollierungs- und Compliance-Seiten nennen keine allgemeine Modelltrainingsrichtlinie für alle vorgelagerten Anbieter. Aussagen zu Selbsthosting und Datenflüssen belegen nicht, wie jeder gewählte Modelldienst Eingaben verarbeitet.
Der Maintainer beschreibt einen Lieferkettenvorfall vom 24. März 2026 mit den PyPI-Paketen v1.82.7 und v1.82.8. Laut Aktualisierung wurden sie unter Quarantäne gestellt und anschließend gelöscht. Die Aussage bezieht sich auf diese historischen Pakete, nicht auf jede Installation oder aktuelle Version.
Unabhängig davon untersuchten externe Sicherheitsforscher v1.77.7 und meldeten Konfigurationszugriffs- und Anbieterzugangsdatenprobleme unter CVE-2026-35029 und CVE-2026-59823. Ihr Bericht nennt die Probleme ab v1.83.9 als behoben. Beschriebene Auswirkungen waren Konfigurationsübernahme mit geringen Rechten und Umleitung von Anbieteraufrufen zur Ausleitung von Zugangsdaten. Dies sind versionsbezogene Befunde und keine Behauptung, dieselben Schwachstellen bestünden in allen späteren Versionen fort.
LiteLLM liefert Gateway und SDK. Konfigurierte vorgelagerte Anbieter liefern die Inferenz; eine Katalogintegration belegt kein enthaltenes Modellkontingent.
Enterprise aktiviert Funktionen per Schlüssel im selben selbst gehosteten Gateway-Image. Die Lizenz ergänzt Governance und Support.
Nein. Nachrichtenprotokolle können Inhalte unterdrücken, während Ausgabenmetadaten bleiben. Nutzungstelemetrie und Enterprise-Anfragemessung haben separate Kontrollen.