Was ist LiteLLM? Das Gateway für viele LLMs

KI-Infrastruktur sauber aufsetzen lassen? WZ-IT baut und betreibt den Open-Source-LLM-Stack auf eigener Infrastruktur - inklusive Gateway, Inferenz und Observability, DSGVO-konform aus einer Hand. LLM-Hosting ansehen

Sobald mehr als eine Anwendung ein Sprachmodell nutzt, stellt sich die Frage nach einer zentralen Anlaufstelle. LiteLLM ist genau das: ein Gateway, das viele Modelle über eine Schnittstelle ansprechbar macht und den Zugriff steuert. Dieser Artikel erklärt, was LiteLLM leistet, warum ein Gateway im Unternehmen sinnvoll ist und wie es im Open-Source-LLM-Stack sitzt. Stand Oktober 2026.

Inhaltsverzeichnis

• Das Problem: viele Modelle, viele APIs
• Was LiteLLM macht
• Der LiteLLM-Proxy (Gateway)
• Warum ein Gateway im Unternehmen
• LiteLLM im Stack
• Sicherheit und Betrieb

Das Problem: viele Modelle, viele APIs

In der Praxis bleibt es selten bei einem Modell. Ein selbst gehostetes LLM für sensible Daten, ein spezialisiertes Modell für Code, vielleicht ein externer Dienst für Ausnahmefälle - und jedes hat seine eigene Schnittstelle, Authentifizierung und Abrechnung. Werden diese Details in jede Anwendung eingebaut, entsteht ein Flickenteppich: Jeder Modellwechsel bedeutet Änderungen an vielen Stellen.

Ein Gateway löst das, indem es sich zwischen Anwendungen und Modelle schiebt und eine einheitliche Schnittstelle nach vorne anbietet.

Was LiteLLM macht

LiteLLM stellt ein einziges, OpenAI-kompatibles Interface über mehr als 100 Sprachmodelle bereit. Eine Anwendung sendet ihre Anfrage im Standard-OpenAI-Format an LiteLLM, und LiteLLM übersetzt sie auf den jeweiligen Anbieter - mit einem konsistenten Antwortformat, unabhängig davon, welches Modell tatsächlich antwortet.

Der praktische Effekt: Anwendungen müssen nur noch das OpenAI-Format kennen. Ob dahinter ein selbst gehostetes vLLM, ein lokales Ollama oder ein externer Dienst arbeitet, ist für die Anwendung transparent. Das Modell wird austauschbar.

Der LiteLLM-Proxy (Gateway)

Über die reine Übersetzung hinaus bringt der LiteLLM-Proxy die Funktionen mit, die den Produktivbetrieb ausmachen (LiteLLM-Dokumentation):

• Authentifizierung und Autorisierung - ein zentraler API-Gateway mit Zugriffskontrolle.
• Kostenverfolgung und Budgets - Ausgaben nachverfolgen und Budgets pro Projekt setzen.
• Rate-Limits - Nutzung pro Nutzer begrenzen.
• Retry und Fallback - automatisches Ausweichen über mehrere Deployments hinweg.
• Admin-Dashboard - eine Oberfläche zur Überwachung und Verwaltung.

LiteLLM ist Open Source (von BerriAI) und lässt sich per Docker vollständig selbst hosten - das Gateway läuft damit auf eigener Infrastruktur.

Warum ein Gateway im Unternehmen

Der Wert eines Gateways zeigt sich, sobald mehrere Teams oder Anwendungen dieselbe Modell-Infrastruktur nutzen. Statt Zugriff, Kosten und Ausfallbehandlung in jeder Anwendung neu zu lösen, liegen sie an einer Stelle:

• Governance - wer darf welches Modell nutzen, mit welchem Limit.
• Kostenkontrolle - transparente Budgets und Verfolgung statt undurchsichtiger Nutzung.
• Entkopplung - Modelle im Hintergrund tauschen oder ergänzen, ohne Anwendungen anzufassen.
• Verfügbarkeit - Fallback erhöht die Robustheit, ohne dass jede Anwendung sie selbst baut.

Das ist der Unterschied zwischen „ein Modell läuft" und „KI wird im Unternehmen betrieben".

LiteLLM im Stack

Im Open-Source-LLM-Stack sitzt LiteLLM als Gateway-Schicht zwischen den Anwendungen und der Inferenz. Unter ihm bedient eine Engine wie vLLM die Modelle; neben ihm zeichnet eine Observability-Schicht wie Langfuse die Anfragen auf. LiteLLM ist damit die zentrale Steuerungsstelle, die aus einem oder mehreren laufenden Modellen einen kontrollierbaren, auditierbaren Dienst macht - die Voraussetzung für einen souveränen, produktiven KI-Betrieb.

Sicherheit und Betrieb

Ein Gateway bündelt nicht nur Zugriffe, sondern auch die API-Schlüssel aller angebundenen Modelle. Entsprechend genau sollte es betrieben werden. Stand Oktober 2026 sind unter anderem diese Meldungen relevant (LiteLLM Security Advisories):

• GHSA-7hp6-4w63-5g45 (kritisch, 30. September 2026): Rechteausweitung bis zum Proxy-Admin durch Wiederverwendung des Salt-Keys; behoben unter anderem in 1.100.4, 1.101.3, 1.102.2 und 1.103.1 (Advisory).
• GHSA-g5ff-637f-6q2m (hoch, 1. Oktober 2026): Ein Nutzer mit der Rolle internal_user_viewer konnte über vertex_ai_credentials beliebige lokale Dateien lesen; behoben ab 1.95.0 (Advisory).
• Lieferkette: Am 24. März 2026 waren die PyPI-Versionen 1.82.7 und 1.82.8 kompromittiert und sammelten Zugangsdaten wie Umgebungsvariablen, SSH- und Cloud-Schlüssel ein (Datadog Security Labs).

Daraus ergeben sich vier Betriebsregeln:

1. Versionen pinnen. Feste Paket- oder Image-Versionen statt latest, Updates bewusst einspielen.
2. Sicherheitsmeldungen verfolgen. Neue Advisories vor jedem Update prüfen und kritische Lücken zeitnah schließen; die Release-Linie ist schnell (Stand Oktober 2026 v1.105.0).
3. Intern halten. Proxy und Admin-Oberfläche nur im internen Netz oder per VPN erreichbar machen, nicht öffentlich.
4. Schlüssel trennen. Master-Key und Salt-Key geheim und getrennt verwalten, Rollen für Nutzer minimal vergeben.

Eine ausführliche Einordnung der Lücke vom September 2026 liefert der Beitrag LiteLLM-Sicherheitslücke: Gateway absichern.