LLM-Gateway

Ein LLM-Gateway nimmt die Anfragen aller KI-Anwendungen eines Unternehmens entgegen und leitet sie an das passende Sprachmodell weiter, ob bei OpenAI, Anthropic, Google oder auf eigenen Servern. Dabei prüft es, wer fragt und ob diese Anwendung das darf, schreibt mit, was der Aufruf gekostet hat, und gibt die Antwort zurück. Meist bietet es dafür eine einheitliche Schnittstelle, häufig im Format der OpenAI-API. Anwendungen können so das Modell wechseln, ohne dass ihr Code angepasst werden muss. Gebräuchlich sind auch die Bezeichnungen AI Gateway und LLM Proxy, teils gleichbedeutend, teils mit kleinerem oder größerem Funktionsumfang.

Eine Norm für den Begriff gibt es nicht. Das Muster stammt vom klassischen API-Gateway und wurde auf die Eigenheiten von Sprachmodellen übertragen: Abrechnung nach Token, häufige Modellwechsel, Ausfälle einzelner Anbieter und vertrauliche Inhalte in den Anfragen. Das quelloffene LiteLLM beschreibt sich als selbst betriebener Server, der Anwendungen einen OpenAI-kompatiblen Endpunkt für über hundert Anbieter gibt. Cloudflare bietet ein AI Gateway als gehosteten Dienst an, Microsoft hat entsprechende Funktionen in Azure API Management eingebaut (Stand November 2026).

Für Führungskräfte ist das LLM-Gateway eine Architekturentscheidung mit Folgen für Kosten, Datenschutz und Abhängigkeit von Anbietern. Ohne gemeinsame Schicht hat jede Anwendung eigene Schlüssel, eigene Verträge und eigene Rechnungen. Niemand sieht dann auf einen Blick, welche Daten an welchen Anbieter gehen und welche Abteilung welche Kosten verursacht. Mit Gateway gibt es eine Stelle, an der Regeln für alle Aufrufe gelten.

So läuft ein Aufruf durch das Gateway.

Die Anwendung schickt ihre Anfrage an das Gateway statt direkt an den Modellanbieter. Sie meldet sich dabei mit einem eigenen Schlüssel an. LiteLLM nennt das virtuelle Schlüssel: Jeder Nutzer, jedes Team oder Projekt bekommt einen eigenen Schlüssel mit festgelegtem Zugriff auf bestimmte Modelle. Die eigentlichen Zugangsdaten der Anbieter liegen nur im Gateway.

Danach folgen mehrere Prüfungen. Darf dieser Schlüssel das angefragte Modell nutzen? Ist das Budget erschöpft, ist die Mengenbegrenzung erreicht? Optional prüft das Gateway den Inhalt, etwa um personenbezogene Daten zu maskieren, bevor sie das Haus verlassen. Ein Zwischenspeicher kann eine Anfrage, die schon einmal beantwortet wurde, direkt aus dem Speicher bedienen. Microsoft beschreibt für Azure API Management auch eine semantische Variante, die auch ähnliche Anfragen wiedererkennt.

Erst dann geht die Anfrage an ein Modell. Die Antwort läuft zurück durch das Gateway, das den Verbrauch an Token und die Kosten auf den Schlüssel bucht und den Vorgang protokolliert. Die Anwendung bekommt davon nur die Antwort mit. Jede dieser Stationen kostet allerdings Zeit. Ein Gateway, das spürbar bremst, wird von Entwicklern umgangen, deshalb gehört die Antwortzeit zu den wichtigsten Messwerten im Betrieb.

Model Routing entscheidet, welches Modell antwortet.

Model Routing ist die Funktion des Gateways, die für jede Anfrage das Modell auswählt. Die einfachste Form ist ein Alias: Die Anwendung fragt nach „Standardmodell“, und im Gateway ist hinterlegt, welches konkrete Modell gerade dahinter steht. Wechselt das Unternehmen den Anbieter, ändert es nur diesen Eintrag.

Regelbasiertes Routing geht weiter. Cloudflare beschreibt in der Dokumentation zu Dynamic Routing, wie sich Nutzergruppen auf verschiedene Modelle verteilen lassen, wie bei Überschreiten einer Kostenquote je Schlüssel und Zeitraum auf ein Ersatzmodell umgeschaltet wird und wie neue Modelle schrittweise oder im A/B-Vergleich eingeführt werden, ohne den Code der Anwendung anzufassen. Fällt ein Anbieter aus, leitet das Fallback auf ein hinterlegtes Ersatzmodell um.

Die Forschung arbeitet an gelernten Routern. FrugalGPT (Chen, Zaharia, Zou, 2023) beschreibt eine Kaskade: Zuerst antwortet ein günstiges Modell, ein teureres kommt nur zum Zug, wenn die Antwort nicht genügt. RouteLLM (Ong u. a., 2024) trainiert Router, die je Anfrage zwischen einem stärkeren und einem schwächeren Modell wählen. Beide Ansätze haben dasselbe Ziel: große Modelle nur dort einsetzen, wo die Aufgabe sie braucht. Ob ein kleineres Modell für eine Aufgabe genügt, zeigen allerdings erst Tests mit echten Fällen.

Kosten werden sichtbar, bevor die Rechnung kommt.

Modellanbieter rechnen nach Token ab, also nach der Menge verarbeiteten Texts in Ein- und Ausgabe. Ein Gateway zählt diese Token bei jedem Aufruf und bucht sie auf eine Anwendung, ein Team oder ein Projekt. LiteLLM erfasst Kosten nach Schlüssel, Team, Nutzer und frei vergebenen Markierungen. Azure API Management bietet eine Richtlinie, die Token je Minute oder ein Kontingent je Stunde, Tag, Woche, Monat oder Jahr begrenzt.

Budgets je Schlüssel stoppen Ausreißer, bevor sie teuer werden: einen Agenten in einer Endlosschleife, einen fehlerhaften Massenlauf, einen Test, der versehentlich auf das größte Modell zeigt. Das OWASP-Projekt führt dieses Risiko in seinen Top 10 für Anwendungen mit Sprachmodellen (Ausgabe 2025) als Unbounded Consumption, also unbegrenzten Verbrauch. Dazu gehört der Angriff Denial of Wallet, bei dem Angreifer die Abrechnung pro Nutzung ausnutzen, um Kosten zu treiben. Als Gegenmaßnahmen nennt OWASP Mengenbegrenzungen, Kontingente und eine laufende Überwachung des Verbrauchs.

Ein Gateway senkt die Modellkosten nicht von selbst. Es macht sie zuordenbar. Günstiger wird der Betrieb erst, wenn jemand die Zahlen auswertet, einfache Aufgaben auf kleinere Modelle lenkt und wiederkehrende Anfragen aus dem Zwischenspeicher bedient.

Protokoll und Datenschutz sind eine Frage der Einstellung.

Ein Gateway sieht jede Anfrage und jede Antwort. Das ist sein Vorteil für die Nachvollziehbarkeit: Microsoft beschreibt etwa, wie sich in Azure API Management Prompts und Antworten für Abrechnung und Prüfung protokollieren lassen. Zugleich wird das Protokoll selbst zu einer Sammlung vertraulicher und personenbezogener Daten.

Deshalb muss festgelegt sein, was gespeichert wird: nur Metadaten wie Zeitpunkt, Anwendung, Modell, Token und Kosten oder auch die Inhalte. Ebenso, wie lange und wer die Protokolle lesen darf. Die Datenschutz-Grundverordnung verlangt in Art. 5, personenbezogene Daten nicht länger als nötig zu speichern. Wird das Gateway als Dienst eines Anbieters betrieben, verarbeitet dieser Anbieter die Daten im Auftrag und braucht einen Vertrag nach Art. 28 DSGVO, zusätzlich zu den Verträgen mit den Modellanbietern.

Richtig eingestellt hilft das Gateway, Datenregeln durchzusetzen. Es kann festlegen, dass Anfragen mit Kundendaten nur an Modelle mit passendem Vertrag oder an selbst betriebene Modelle gehen. Das gilt allerdings nur für Aufrufe, die tatsächlich durch das Gateway laufen. Wer ein privates Chat-Konto nutzt, umgeht jede Regel. Ein Gateway ersetzt also keine Vorgaben dazu, welche Werkzeuge erlaubt sind.

API-Gateway, LLM-Gateway und Orchestrierung sind verschiedene Ebenen.

Ein API-Gateway verwaltet beliebige Schnittstellen. Es übernimmt Anmeldung, Lastverteilung und Mengenbegrenzung, zählt dabei aber Anfragen statt Token und kennt weder Modelle noch deren Ausfälle. Ein LLM-Gateway ist auf Sprachmodelle zugeschnitten: Es rechnet nach Token, übersetzt zwischen den Formaten verschiedener Anbieter und wechselt bei einem Ausfall das Modell.

Die Grenze verschwimmt, wenn ein API-Gateway Funktionen für Sprachmodelle nachrüstet. Microsoft schreibt ausdrücklich, das AI Gateway in Azure API Management erweitere das vorhandene API-Gateway und sei kein eigenes Produkt. Ob ein Produkt die Aufgabe erfüllt, zeigen vier Fragen: Zählt es Token je Anwendung? Setzt es Budgets in Token oder Geld? Wechselt es bei Ausfall automatisch das Modell? Versteht es die Schnittstellen mehrerer Anbieter?

KI-Orchestrierung liegt eine Ebene darüber. Sie steuert Abläufe aus mehreren Schritten, Werkzeugen und Prüfungen innerhalb einer Anwendung. Das Gateway regelt dagegen jeden einzelnen Modellaufruf. Ein Agent, der fünf Schritte plant, schickt also fünf Aufrufe durch dasselbe Gateway. Ein LLM Proxy bezeichnet meist eine schlanke Variante, die nur weiterleitet und protokolliert.

Woran man eine gute Umsetzung erkennt.

Bei einer guten Umsetzung hat jede Anwendung einen eigenen Schlüssel, und die Zugangsdaten der Anbieter liegen nur im Gateway. Jeder Aufruf lässt sich einer Anwendung und einem Bereich zuordnen, mit Kosten. Ein Modellwechsel ist eine Änderung der Einstellung, keine Programmierung, und er wird vorher mit festen Testfällen geprüft. Auch das Ersatzmodell wird regelmäßig getestet, ein Eintrag in der Konfiguration allein genügt nicht. Die Aufbewahrungsdauer der Protokolle ist festgelegt und dokumentiert.

Das Gateway ist eine zentrale Abhängigkeit: Fällt es aus, steht jede KI-Anwendung im Haus. Es braucht deshalb Überwachung, Alarme und einen Plan für Updates wie jedes andere kritische System. Ob selbst betrieben oder als Dienst gebucht, ein Gateway kostet Hosting oder Lizenz, Pflege und Überwachung, zusätzlich zu den Modellkosten.

Überdimensioniert ist ein Gateway, wenn ein Team eine einzige Anwendung mit einem einzigen Anbieter betreibt. Dann genügen dessen Konsole und Schlüsselverwaltung. Sinnvoll wird die gemeinsame Schicht, sobald mehrere Anwendungen, Teams oder Anbieter zusammenkommen.

Die Grenze des Begriffs

Ein LLM-Gateway regelt den Weg zum Modell, nicht die Qualität der Antwort: Ob ein Ergebnis stimmt, hängt an Modell, Kontext und fachlicher Prüfung. Abzugrenzen ist es vom allgemeinen API-Gateway, das weder Token noch Modelle kennt, von der KI-Orchestrierung, die Abläufe aus mehreren Schritten steuert, und von Guardrails, die als Prüfungen im Gateway sitzen können. Ein Model Router ist ein Baustein des Gateways, kein Ersatz dafür.