Ein sicher betriebenes LiteLLM-Gateway mit Budget und klaren Zugriffsregeln für jedes Team

Für die Geschäftsführung werden KI-Ausgaben mit einem Gateway von einer Überraschung zu einem Budget: Jedes Team hat ein eigenes Limit, Ausgaben werden je Team und Anwendung ausgewiesen, und ein widerrufener Schlüssel funktioniert nirgends mehr. Anwendungen sprechen nur mit dem Gateway, deshalb ist ein Modellwechsel eine Konfigurationsänderung, und Sie binden sich an keinen Hersteller.

Für Datenschutzbeauftragten und Betriebsrat ist das Gateway die eine Stelle, an der festgelegt wird, welche Daten zu welchem Modell dürfen und was protokolliert wird. In der Bitkom-Umfrage von 2026 nannten 45 % der Unternehmen, die KI nutzen, die Sorge, dass Unternehmensdaten in falsche Hände geraten, als Hemmnis. Eine Modellliste nur mit EU-Bereitstellungen und Anfrageprotokolle in Ihrem eigenen Speicher beantworten diese Sorge an einer Stelle.

Sobald mehrere Teams Sprachmodelle aufrufen, liegen Schlüssel an vielen Stellen, und niemand kann sagen, welches Team welchen Teil der Rechnung verursacht hat. Ein Gateway gibt jeder Anwendung eine Schnittstelle, egal welches Modell antwortet, und Ihnen einen Ort, an dem Sie festlegen, wer welches Modell nutzen und wie viel ausgeben darf.

LiteLLM wird oft gewählt, weil es Open Source ist, in Ihrer eigenen Umgebung läuft und die meisten kommerziellen Anbieter und selbst betriebenen Modelle unterstützt. Es ist nicht die einzige Option: Kong, Azure API Management und mehrere Cloud-Dienste bieten ebenfalls Gateway-Funktionen für KI. Kein Anbieter bezahlt uns, und wenn eine dieser Lösungen besser zu Ihrer Umgebung passt, sagen wir das.

Ein einzelner Container auf einem Laptop ist schnell gestartet. Ein Gateway, von dem jedes Team abhängt, braucht mehr: eine Postgres-Datenbank für Schlüssel, Teams und Ausgaben, Redis, sobald mehr als eine Instanz läuft, mehrere Replikate hinter einem Load Balancer, Health Checks und einen Plan für die Ausgaben- und Protokolltabellen, die mit jeder Anfrage wachsen.

• Ohne Redis zählt jede Instanz Ratenlimits und Budgets für sich, sodass Limits überschritten werden und widerrufene Schlüssel weiter funktionieren, bis lokale Caches ablaufen.
• Admin-Oberfläche und Verwaltungsendpunkte sind nur aus Ihrem internen Netz erreichbar.
• Anbieterschlüssel liegen in Ihrem Secret Manager, nicht in Konfigurationsdateien.
• Anfrageprotokolle folgen einer Aufbewahrungsregel, die mit Ihrem Datenschutzbeauftragten abgestimmt ist.

LiteLLM hatte 2026 drei ernste Vorfälle. Im März tauchten schädliche Versionen bei PyPI auf. Im Mai wurde eine aktiv ausgenutzte Schwachstelle in den MCP-Testendpunkten behoben. Im Oktober brachte eine kompromittierte Release-Pipeline eine schädliche Version zu PyPI und in die Docker-Images. Alle drei sind behoben, und LiteLLM hat nach Oktober seinen Signaturschlüssel ausgetauscht. Die Vorfälle zeigen aber, was der Betrieb braucht: per Image-Digest gepinnte und geprüfte Versionen, beobachtete Sicherheitsmeldungen, stufenweise Updates mit Tests, Anbieterschlüssel, die sich schnell austauschen lassen, und so wenig vom Gateway erreichbar wie möglich.

Wenn Sie LiteLLM schon betreiben, prüfen wir zuerst, welche Versionen je installiert waren, welche Endpunkte erreichbar sind und wo Anbieterschlüssel liegen. Unser Leitfaden zu LiteLLM im Produktivbetrieb listet die Prüfungen auf.

Jedes Team und jede Anwendung bekommt einen eigenen virtuellen Schlüssel mit den erlaubten Modellen, einem Budget und Ratenlimits. Ausgaben werden je Team, Anwendung und Aufgabe ausgewiesen, sodass Kostenfragen mit Daten beantwortet werden. Routing auf ein günstigeres Modell schalten wir erst ein, wenn Regressionstests zeigen, dass die Qualität für diese Aufgabe hält, und eine Modellliste nur mit EU-Bereitstellungen hält Anfragen dort, wo Ihre Regeln es verlangen.

Coding-Agenten sind in vielen Unternehmen die größten Modellnutzer. Claude Code und andere Werkzeuge, die einen eigenen API-Endpunkt akzeptieren, können ihre Anfragen über das Gateway schicken, sodass ihre Kosten je Team sichtbar werden und ihre Schlüssel an einer Stelle widerrufbar sind. Manche Werkzeuge leiten Anfragen über die Server ihres Anbieters und erreichen kein Gateway in Ihrem internen Netz. Das prüfen wir für jedes Werkzeug, bevor wir etwas zusagen.

Schlüssel, Budgets, Routing, Ausweichmodelle und Kostenerfassung gehören zur Open-Source-Version. Einige Funktionen, etwa Single Sign-On für mehr als fünf Nutzer und mehrere Audit- und Governance-Funktionen, brauchen die kostenpflichtige Enterprise-Lizenz von LiteLLM. Wir gleichen Ihre Anforderungen mit der Funktionsliste ab, bevor Sie etwas kaufen, und nutzen die Identitäts- und Protokollierungsdienste Ihres Cloud-Anbieters, wo sie eine Lücke schließen.

Wir betreiben LiteLLM auf dem Kubernetes, das Sie schon nutzen, im eigenen Rechenzentrum oder auf EKS oder AKS, oder als verwalteten Container-Dienst in Ihrem Cloud-Konto. Dahinter können Azure OpenAI und Amazon Bedrock in Ihren eigenen Konten stehen, Modelle, die Sie selbst mit vLLM betreiben, und öffentliche APIs, wo Ihre Regeln das erlauben.