Was ist LiteLLM?
LiteLLM ist ein quelloffenes Projekt, das eine einzige API vor viele Anbieter von Sprachmodellen stellt. Deine Anwendung ruft es im OpenAI-Anfrageformat auf, LiteLLM übersetzt diesen Aufruf für den Anbieter, der tatsächlich antwortet, und übersetzt die Antwort zurück in dieselbe Form. Anthropic, OpenAI, Mistral oder ein Modell, das du selbst betreibst: der aufrufende Code ändert sich nicht, wenn das Modell dahinter wechselt.
Entwickelt wird es von BerriAI, und es deckt über 100 Anbieter ab, für Chat Completions, Embeddings, Bilder, Audio und Batch-Endpunkte.
Das Problem, das es löst
Zwei Probleme, und meistens kommen Organisationen wegen des zweiten.
Jeder Anbieter hat sein eigenes SDK. Ein zweites Modell bedeutet eine zweite Client-Bibliothek, ein zweites Authentifizierungsverfahren und eine zweite Fehlersemantik im Code. Das Modell zu wechseln bedeutet, Anwendungscode zu ändern, womit die Modellwahl ein Deployment wird statt einer Konfigurationsänderung. Teams bleiben am Ende bei dem Anbieter, den sie zuerst angebunden haben, nicht weil er der beste ist, sondern weil der Wechsel Arbeit macht.
Ausgabenkontrollen sitzen auf der falschen Ebene. Die meisten Anbieter begrenzen Ausgaben pro Konto. Eine ausser Kontrolle geratene Wiederholungsschleife eines Teams oder ein besonders eifriger Prototyp bringt das Budget für alle an die Grenze. Es gibt keinen eingebauten Weg zu sagen, dass dieses Projekt einen bestimmten Betrag pro Monat bekommt und jenes Team einen anderen. Genau das verlangt die Finanzabteilung aber in dem Moment, in dem die Ausgaben für KI sichtbar werden.
Ein Gateway löst beides, indem es die eine Stelle ist, durch die jede Anfrage geht: eine Schnittstelle für die Anwendungen, ein Ort für Budgets, Rate Limits und Zugriffsregeln, und ein Protokoll darüber, was gefragt wurde und was es gekostet hat.
Proxy oder SDK, und warum das zählt
LiteLLM gibt es in zwei Formen, und die falsche zu wählen ist der häufigste frühe Fehler.
Das Python-SDK ist eine Bibliothek, die du importierst und die einer entwickelnden Person einen einheitlichen Weg gibt, viele Modelle aus dem eigenen Code aufzurufen. Zentralisiert wird dabei nichts: Budgets, Schlüssel und Protokolle liegen dort, wo dieser Code läuft.
Der Proxy-Server ist ein Dienst, den du ausrollst. Anwendungen sprechen ihn über HTTP an, in jeder Sprache, und er hält die Anbieterschlüssel, die Budgets, die Rate Limits und das Audit-Protokoll. Das ist gemeint, wenn von einem KI-Gateway die Rede ist, und es ist die Form, die die Fragen zu Ausgaben und Zugriff oben beantwortet.
Geht es um Steuerung über mehrere Teams hinweg, ist es der Proxy. Geht es um Bequemlichkeit innerhalb eines Python-Projekts, reicht das SDK, und ein Deployment wäre Zusatzaufwand.
Wann sich ein Gateway lohnt
- Mehr als ein Team ruft Modelle auf. Ein Gateway verdient sein Geld ab dem Punkt, an dem du Budgets und Schlüssel pro Team brauchst.
- Die Modellwahl soll offen bleiben. Routing verschiebt Verkehr zwischen Anbietern oder schaltet bei einem Ausfall um, ohne dass Anwendungscode ausgeliefert werden muss.
- Jemand muss beantworten, was das kostet. Eine Zuordnung pro Person, pro Team und pro Projekt ist der Unterschied zwischen einem Gespräch über Weiterverrechnung und einer Vermutung.
- Prompts sind heikel. Wenn jede Anfrage durch Infrastruktur geht, die du kontrollierst, bleiben die Protokolle darüber, was gefragt wurde, dort, wo du sie hingelegt hast.
Wann nicht
Eine einzelne Anwendung mit einem einzelnen Anbieter braucht kein Gateway, sondern das SDK des Anbieters und weniger Infrastruktur.
Ein Gateway ist ein weiterer Sprung im Anfrageweg. Es kostet Latenz und ist eine Komponente, die ausfallen kann. Wenn deine Architektur keine Abhängigkeit zwischen Anwendung und Modell verträgt, ist das ein ernstzunehmender Einwand.
Es leitet weiter, es hostet nicht. LiteLLM schickt deine Prompts an den Anbieter, den du konfiguriert hast. Wenn die Anforderung lautet, dass Prompt-Text überhaupt nie zu Dritten gelangt, liefert ein Gateway allein das nicht. Dann brauchst du ein selbst betriebenes Modell, auf das das Gateway zeigt. Für die Hosting-Hälfte ist vLLM die übliche Antwort.
Was der Betrieb verlangt
Der Proxy ist der Kontrollpunkt für jeden Modellaufruf der Organisation. Das ist ein guter Ort, um Richtlinien durchzusetzen, und ein unangenehmer Ort für Nachlässigkeit:
- Er hält jeden Anbieterschlüssel. Spätestens hier hört Secrets Management auf, optional zu sein.
- Er liegt auf dem kritischen Pfad. Welche Verfügbarkeit deine KI-Funktionen brauchen, braucht das Gateway mindestens auch, also mehr als eine Replica und ein durchdachtes Failover.
- Die Authentifizierung muss an die bestehende Personenverwaltung anschliessen. Single Sign-on und rollenbasierte Rechte, damit Zugriff Ein- und Austritten folgt statt einer Tabelle voller Schlüssel.
- Die interessanten Kennzahlen sind pro Team, nicht pro Cluster. Tokenverbrauch, Fehlerraten pro Anbieter, Latenz pro Modell und Kosten, zugeordnet zum Team, das sie ausgelöst hat.
Wo VSHN ins Bild kommt
VSHN rollt den LiteLLM-Proxy auf Kubernetes und OpenShift in Schweizer Rechenzentren aus und betreibt ihn, auf Exoscale, Cloudscale und weiteren Schweizer Anbietern, mit konfigurierten Budgetkontrollen, Guardrails und SSO-Anbindung statt mit Standardwerten. Protokolle des Proxys, API-Schlüssel und Metadaten der Anfragen bleiben in der gewählten Rechtsordnung, und unsere Souveränitätsbewertung legt dar, wie das bewertet wird.
Die Frage, die vor jedem Deployment geklärt gehört, ist, welche der beiden Formen du tatsächlich brauchst und ob die Modelle hinter dem Gateway selbst betrieben oder von Dritten bezogen werden. Das ist ein kurzes Gespräch, und es verändert die ganze Architektur.