
In großen Unternehmen wird der Zugriff auf KI-Sprachmodelle schnell unübersichtlich: Viele Teams, viele Anwendungen und viele verschiedene Anbieter führen zu unkontrollierten Kosten, Sicherheitsrisiken und Compliance-Problemen. Genau hier kommt ein LLM Gateway wie LiteLLM ins Spiel. Es fungiert als zentraler Kontrollpunkt zwischen allen internen Anwendungen und den externen Modellen, indem es eine einheitliche Schnittstelle, zentrales Kosten- und Key-Management sowie automatisches Load-Balancing und Failover bietet. Vor allem aber sorgt es für die nötige Governance, Transparenz und Datensicherheit, die Konzerne benötigen, um KI sicher, kontrolliert und wirtschaftlich einzusetzen.
Die Installation erfolgt mit Docker. Die Konfiguration kann mittels Umgebungsvariablen, der config.yaml oder in der Applikation selbst gemacht werden. Es ist leider nicht immer eindeutig, wo die Konfiguration gemacht werden muss.
Die UI begrenzt einige Funktionen auf eine Enterprise-Lizenz, wie zum Beispiel das Festlegen von Tags zu virtuellen Keys. Dies nutze ich, um in Langfuse (Observability-Tool) die Requests den virtuellen Keys zuzuordnen. Je nach UI-Maske sind einige Funktionen aber doch konfigurierbar.
Das Budgetmanagement ist mit dem Tool sehr gut möglich. Sowohl auf Team-Ebene als auch auf Basis der einzelnen virtuellen Keys ist es möglich, einmalige oder monatliche Budgets zu definieren.
Dank Standardisierung können auch andere Model-Provider als OpenAI oder Antrophic definiert werden. Ich nutze aktuell einen in der EU ansässigen Provider, der die aktuellen Open-Weights Modelle Kimi K3, GLM 5.2 oder Deepseek V4 bereitstellt.
Die Kosten pro Millionen Tokens können für jedes Modell händisch festgelegt werden. Alternativ gibt es eine JSON-Datei, welche bereits einige Preise für Modelle bereithält.
Über das Kostendashboard können die Gesamtkosten sowie die gefilterten Kosten nach virtuellem API-Key aufgelistet werden.
LiteLLM kann auch als MCP Gateway konfiguriert werden. MCP (Model Context Protocol) ist ein standardisiertes Protokoll für LLMs. Hier werden Tools definiert, welche dem LLM dann zur Verfügung gestellt werden.
Diese Tools können z.B. das Durchsuchen des Internets mit einer Suchmaschine wie SearxNG, das Abrufen von Internetseiten mit Firecrawl oder das Erstellen von Seiten in einem Wiki sein.
Hierzu könnte ich einen eigenen Artikel schreiben, da vor allem das Thema Authentifizierung interessant ist: Werden die Credentials des Nutzers, der gerade den Chatbot nutzt, genutzt oder bekommt das LLM einen eigenen Service Account?
Damit die MCPs nicht jedes Mal neu auf Clientseite konfiguriert werden müssen, können diese unternehmensweit in LiteLLM hinterlegt werden. Hier kann dann LiteLLM als Master-MCP in den Clients hinterlegt werden und sich somit Konfigurationsaufwand gespart werden.
Da viele Anwendungen noch keinen MCP Server mitbringen (Nextcloud), dieser hinter einer Subscription versteckt ist (Gitlab) oder dieser noch zusätzlich zur Anwendung betrieben werden muss, habe ich dieses Feature noch nicht testen können.
Für ein endgültiges Fazit ist es noch zu früh, da ich die Anwendung erst seit April 2026 betreibe und ausprobiere.
Auch konnte ich bisher die Features A2A (Agent2Agent) und MCP (Model Context Protocol) mangels Anwendungsfall noch nicht testen.
Die Zentralisierung von LLM-Zugriffen ist wichtig für das Controlling und auch für die Governance. Mit LiteLLM kann dies gut abgedeckt werden. Die Konfiguration ist an manchen Stellen aber noch etwas verbesserungsbedürftig.
Ich werden daher weitere Tools testen wie z.B. agentgateway oder aber auch Netbird LLM Gateway, welches ich aktuell schon als VPN im Einsatz habe.
Quick Links
