Wie funktioniert ein LLM-Gateway? Ein Praxisleitfaden für Engineering-Teams

Ein LLM-Gateway sitzt zwischen Ihren Anwendungen und den Modellanbietern, die Sie darüber anbinden, und bietet Ihnen einen zentralen Ort, um Zugangsdaten zu verwalten und die Nutzung nachzuverfolgen.

„Im Moment ist das ein einziges Sch***chaos“, schrieb ein Entwickler im September 2026 auf Reddit in r/LLMDevs.

„Jeder hat seine eigenen Schlüssel für Claude, OpenAI, AWS Bedrock und all die anderen Inferenzanbieter, die wir nutzen.“

BigGos Bericht über llm-proxy-tk, ein schlankes FastAPI-Gateway, vergleicht das Setup damit, LLMs in „Leitungswasser für Unternehmen“ zu verwandeln – mit dem Gateway als Hauptventil des Gebäudes.

Doch bevor Sie den Leitungen so viel Vertrauen schenken, sehen wir uns an, was Sie da eigentlich installieren.

Was ist ein LLM-Gateway?

Ein LLM-Gateway ist ein Reverse Proxy für Modellaufrufe. Ihre Anwendungen senden Anfragen an das Gateway statt direkt an OpenAI, Anthropic, Google oder welche LLM-Anbieter Sie auch immer nutzen. Das Gateway leitet diese Anfragen weiter und wendet dabei Ihre Regeln an.

Jeder LLM-Anbieter hat seine eigene API: mit eigenem Anfrageformat, eigener Authentifizierung und eigener Art, Fehler zurückzugeben. Jeder hat außerdem eigene Rate Limits und Fehlermodi. Gibt es keine gemeinsame Schicht davor, erledigt jede Anwendung, die einen Anbieter aufruft, alles selbst – und zwar jeweils ein wenig anders.

Die Leitungswasser-Analogie trägt nur bis zu einem gewissen Punkt, aber immerhin bis hierhin: Anbieter werden einmal angeschlossen, nämlich am Gateway. Von da an erhält jede Anwendung ihren eigenen Anschluss mit Zähler, sodass Sie sehen, wer was nutzt, und jede einzelne Leitung abdrehen können, ohne die anderen anzurühren.

LLM-, KI-, MCP- und API-Gateways: Was ist der Unterschied?

Wie funktioniert ein LLM-Gateway?

Verfolgen wir eine Anfrage von Ihrer Anwendung zum Modell und zurück.

1. Die Anfrage erreicht das Gateway: Ihre Anwendung sendet eine gewöhnlich aussehende Chat-Anfrage, oft in einem OpenAI-kompatiblen Format, an den Endpunkt des Gateways. Aus Sicht der Anwendung ist das die Adresse, die sie aufruft, um das Modell zu erreichen.
2. Das Gateway prüft, wer anfragt und was der Anfragende darf: Bevor es die Anfrage weiterleitet, validiert es die Zugangsdaten. Häufig ist das ein virtueller Schlüssel, der für ein Team oder Produkt ausgestellt wurde. Wenn Sie Input-Guardrails eingebunden haben, können Prompts zudem auf sensible Daten oder auf Versuche gescannt werden, die Anweisungen des Modells auszuhebeln.
3. Das Gateway prüft, ob es die Antwort bereits hat: Ist Caching aktiviert, kann eine passende, dafür geeignete Anfrage mit einer gespeicherten Antwort bedient werden, ohne den Anbieter erneut aufzurufen. Manche Gateways bieten auch semantisches Caching an, das nach Anfragen sucht, die als ausreichend ähnlich statt identisch eingestuft werden. Das kann sich für FAQ-artigen Traffic eignen.
4. Das Gateway entscheidet, wohin die Anfrage geht: Die Anfrage kann ein bestimmtes Modell oder einen Alias nennen. Das Gateway sucht die passende Route in Ihrer Konfiguration. Sie können auch eine Ersatzroute konfigurieren. Kommt es bei Anbieter A zu einer Zeitüberschreitung, kann das Gateway es bei Anbieter B versuchen.
5. Das Gateway bereitet den Aufruf vor und gibt die Antwort zurück: Ein Gateway wandelt Ihre Anfrage in das Format des gewählten Anbieters um und authentifiziert den ausgehenden Aufruf. Sobald die Antwort eingeht, wird sie in das Format umgewandelt, das Ihre Anwendung benötigt.
6. Das Gateway protokolliert, was passiert ist: Ist das Logging aktiviert, erfasst das Gateway Details wie den Urheber des Aufrufs, das Modell, das ihn bedient hat, Token-Anzahl, Latenz und Kosten. Genau dieses Protokoll fehlte dem Reddit-Entwickler aus der Einleitung.

4 Dinge, die Sie wissen müssen, bevor Sie ein Gateway in Produktion nehmen

Alles im obigen Abschnitt ist möglich, weil das Gateway jede Anfrage sieht, die darüber geleitet wird. Das ist das Verkaufsargument. Es beschreibt aber zugleich die Angriffsfläche und die Anbieterabhängigkeit, die Sie einplanen müssen.

Das Gateway ist jetzt die wertvollste Komponente in Ihrem KI-Stack

Das Gateway zentralisiert den Zugriff. Und damit bringt es auch viele Zugangsdaten in die Reichweite eines einzigen Dienstes. Das Sicherheitsteam von Microsoft listet auf, was ein LiteLLM-Deployment enthalten oder abrufen kann: API-Schlüssel der Anbieter, den eigenen Master-Key, Datensätze zu virtuellen Schlüsseln, Datenbank-Verbindungsstrings, Routing-Einstellungen und Mandantenrichtlinien.

Im Oktober 2026 veröffentlichte Check Point Research zwei Schwachstellen mit hohem Risiko in LiteLLM:

• Über CVE-2026-35029 konnten authentifizierte Benutzer, auch solche mit reinem Lesezugriff, auf Verwaltungsfunktionen zugreifen und die Instanz übernehmen.
• Über CVE-2026-59823 konnten Benutzer Anfragen auf einen von ihnen kontrollierten Server umleiten und Anbieterschlüssel abgreifen.

Beide wurden in Version 1.83.9 behoben. Eine Anwendung, die das Gateway nutzt, sollte dessen Einstellungen nicht ändern können.

Ihre Guardrails brauchen eine Richtlinie für den Fehlerfall

Eine Analyse von Pillar Security vom 4. Oktober 2026 dokumentiert Guardrail-Integrationen von Drittanbietern in wichtigen Gateways, darunter LiteLLM, Kong, TrueFoundry, Portkey, Azure API Management und Apigee. (Pillar verkauft selbst Guardrails – behalten Sie das beim Lesen der Empfehlungen im Hinterkopf.)

Ein Hook ist ein Punkt im Anfragepfad – typischerweise bevor der Prompt an das Modell geht oder nachdem die Antwort zurückkommt –, an dem das Gateway den Inhalt zur Bewertung an einen externen Scanner übergeben kann. Eine blockierende Prüfung wartet auf dieses Urteil, bevor sie den Traffic weiterlässt. Die Dokumentation von Portkey nennt diese before_request_hooks und after_request_hooks; TrueFoundry nutzt vier und ergänzt Prüfungen vor und nach MCP-Tool-Aufrufen.

Zwei Dinge sollten Sie nun prüfen:

• Was passiert, wenn der Scanner selbst ausfällt? Blockieren Sie die Anfrage, stoppen Sie ungeprüften Traffic, unterbrechen aber womöglich Ihre Anwendung. Lassen Sie sie durch, kann Ihre Anwendung ohne diese Prüfung weiterlaufen. Das Fehlerprotokoll zeigt Ihnen hinterher, dass die Prüfung fehlte – das ist nützlich, ersetzt aber nicht die Prüfung selbst.
• Können Sie den Scanner austauschen? Wird ein anderer Anbieter nicht unterstützt, müssen Sie möglicherweise Ihre Anwendung anpassen oder einen weiteren Proxy für die Anbindung nutzen.

Die MCP-Hooks von TrueFoundry erweitern die Reichweite des Gateways von Modellanfragen auf Tool-Aufrufe. Es kann aber nur Traffic prüfen, der darüber läuft. Ein Coding-Agent, der einen Befehl auf dem Rechner eines Entwicklers ausführt, liegt womöglich außerhalb dieses Blickfelds.

Perplexitys Open-Source-Tool Numbat setzt auf dieser Seite an. Numbat verbindet sich über lokale Hooks mit unterstützten Agenten und kann geplante Aktionen wie Shell-Befehle oder Schreibvorgänge in Dateien prüfen, bevor sie ausgeführt werden. Die Blockierfunktion ist optional und standardmäßig deaktiviert. Das Gateway sieht den Modell-Traffic, der darüber geleitet wird. Numbat schafft zusätzlich Einblick in das, was der Agent mit der Antwort macht.

Sie müssen wissen, wo die Kontrolle des Gateways endet

Forkast News identifiziert drei Entwicklungslinien, die sich dem Gateway aus unterschiedlichen Richtungen nähern:

• LLM-orientierte Gateways: LiteLLM und Portkey begannen mit Modellaufrufen: Übersetzung zwischen Anbietern, Routing von Anfragen und Token-Tracking. Inzwischen ergänzen sie Kontrollen für Tool-Aufrufe.
• API-Management-Plattformen: Kong, Googles Apigee und Azure API Management begannen mit Authentifizierung, Berechtigungen und Traffic-Management und ergänzten später Unterstützung für Modelle und KI-spezifische Regeln.
• Agent-native Infrastruktur: agentgateway etwa wurde rund um Agenten konzipiert, die mit Modellen, Tools und anderen Agenten kommunizieren, auch über MCP und A2A.

Die entscheidende Frage ist, was Sie routen:

• Nur Modellaufrufe? Ein LLM-orientiertes Gateway ist ein guter Ausgangspunkt.
• Modellaufrufe in einem Unternehmen, das bereits voller API-Regeln ist? Beginnen Sie mit der Plattform, die Sie bereits haben.
• Agenten, die Tools aufrufen, die wiederum Modelle aufrufen? Prüfen Sie, ob auch diese Verbindungen abgedeckt sind.

Sie schaffen einen Single Point of Failure

Angenommen, Ihr Support-Chatbot nutzt OpenAI und Ihr Recherchetool nutzt Anthropic – beide sind über dasselbe Gateway angebunden. Fällt dieses Gateway jedoch aus, verlieren beide Tools den Zugriff auf ihre Modelle, selbst wenn OpenAI und Anthropic normal laufen.

Das ist tatsächlich schon passiert. Während des Ausfalls am 12. Juni 2025 erreichte die Fehlerrate von Cloudflares AI Gateway in der Spitze 97 %. Das Gateway war für seine Einstellungen auf Cloudflares Speicherdienst Workers KV angewiesen, und dieser Dienst fiel aus.

Wenn Sie das Gateway selbst betreiben, halten Sie eine weitere Instanz in Betrieb, die übernehmen kann, falls eine ausfällt. Wenn jemand anderes Ihr Gateway hostet, fragen Sie nach, wie der Betrieb bei Störungen aufrechterhalten wird und was während der Wiederherstellung mit Ihren Anfragen passiert.

Die wichtigsten Funktionen, auf die Sie bei LLM-Gateways achten sollten

Sie geben dem Gateway Zugriff auf die Zugangsdaten aller Beteiligten – also sollten Sie hohe Ansprüche an das stellen, was es im Gegenzug leistet.

• Eine API vor mehreren Anbietern: Ihr Code spricht ein Format, oft ein OpenAI-kompatibles, und das Gateway übersetzt. LLM-Anbieter kommen dem entgegen. So unterstützt etwa Perplexitys Agent API die Responses-API-Schnittstelle von OpenAI, sodass Teams vorhandene OpenAI-Clientbibliotheken weiterverwenden können.
• Virtuelle Schlüssel mit hinterlegten Regeln: Jedes Team oder Produkt erhält einen eigenen Schlüssel mit Regeln für zulässige Modelle, Anfragelimits und Ausgaben.
• Routing und Fallback: Das Gateway leitet Anfragen anhand Ihrer Einstellungen an Modelle weiter – etwa mit Vorrang für Kosten, Geschwindigkeit oder einen bestimmten Anbieter. Schlägt ein Aufruf fehl, kann es ein anderes Modell versuchen. Mit Perplexitys Agent API können Sie bis zu fünf Modelle, auch von verschiedenen Anbietern, in Ihrer bevorzugten Reihenfolge angeben.
• Caching: Eine gespeicherte Antwort kann Ihnen einen weiteren Anbieteraufruf ersparen. Manche Gateways erkennen identische Anfragen, andere auch Anfragen mit ähnlicher Bedeutung. Prüfen Sie, ob sich zwischengespeicherte Antworten nach Benutzer oder Team trennen lassen und ob Sie das Caching für personalisierte oder zeitkritische Antworten deaktivieren können.
• Streaming und einheitliche Fehler: Die Antworten kommen an, während sie generiert werden, und Anbieterfehler werden in ein Format übersetzt, das Ihre Anwendung verarbeiten kann. Prüfen Sie, was passiert, wenn Sie KI-Guardrails hinzufügen.
• Logging und Kostenzuordnung: Das Gateway erfasst, wer einen Aufruf getätigt hat, welches Modell ihn bedient hat, wie viele Tokens verbraucht wurden, wie lange er gedauert hat und welche geschätzten Kosten angefallen sind. Prüfen Sie, ob die Logs Prompts und Antworten enthalten und wie lange sie aufbewahrt werden.
• Guardrail-Hooks: Das sind Punkte im Anfragepfad, an denen das Gateway Inhalte zur Bewertung an einen externen Scanner senden kann. Sie liegen meist vor einer Modellanfrage oder nach deren Antwort. Prüfen Sie, ob Anfragen bei einem Ausfall des Scanners gestoppt oder fortgesetzt werden und ob Sie einen anderen Scanner anbinden können.
• Eine Admin-Oberfläche, die Sie absichern können: Das Gateway verwaltet den Zugriff auf die Zugangsdaten der Anbieter und die Regeln, die für alle gelten. Prüfen Sie, ob Sie den Admin-Zugriff getrennt vom Anwendungs-Traffic einschränken können und ob Benutzer mit reinem Lesezugriff tatsächlich keine Einstellungen ändern können. Das Hauptventil braucht ein Schloss.

Mit welchen Tools können Sie Ihr LLM-Gateway aufbauen?

Die Funktionslisten überschneiden sich auf dem gesamten Markt. In einem Reddit-Thread zum internen Modellzugriff fragte der Verfasser: Welches Gateway kommt ohne eigens dafür abgestellten Engineer aus?

Unserer Meinung nach ist das die richtige Frage, und sie hat vier Antworten – je nachdem, wie viel der Arbeit Sie selbst übernehmen wollen.

Selbst entwickeln

Ein minimales Gateway erledigt eine kurze Liste von Aufgaben: Anfragen annehmen, den Schlüssel des Aufrufers prüfen, die Zugangsdaten des Anbieters hinzufügen, den Aufruf weiterleiten und das Ergebnis protokollieren. Die Unterstützung verschiedener Anbieterformate bedeutet jedoch zusätzlichen Aufwand. Ebenso der dauerhafte Betrieb des Ganzen.

Wenn Sie bereits Envoy einsetzen, können Sie über dessen External-Processing-Filter einen Dienst anbinden, der Anfragen und Antworten prüft und verändert. Diesen Dienst müssen Sie allerdings weiterhin selbst entwickeln und betreiben.

In einem r/LLMDevs-Thread zur Frage, ob ein Gateway Kosten senkt, berichtete u/QuanTradin, dass das Protokollieren von Tokens und eines Cache-Hit-Flags bei jedem Aufruf geholfen habe, zwei Jobs zu finden, die für identische Prompts den vollen Preis zahlten.

„...das zu beheben, war mehr wert, als es jede Routing-Schicht gewesen wäre.“

Das ist ein Erfahrungsbericht – und ein guter Ausgangspunkt. Finden Sie heraus, wofür Sie bezahlen, bevor Sie ausgeklügelte Wege entwickeln, diesen Traffic zu routen.

Ein Open-Source-Gateway selbst hosten

LiteLLM ist hier eine gängige Wahl: OpenAI-kompatibel, mit Unterstützung für eine breite Palette von Anbietern und einer großen Community. Bifrost ist eine Alternative, die auf geringen Overhead pro Anfrage ausgelegt ist. Helicone lohnt einen Blick, wenn Observability ganz oben auf Ihrer Funktionsliste steht.

Wie jedes Produkt stößt auch LiteLLM für manche Teams an Grenzen. In einem r/aiagents-Thread über Alternativen zur Eigenentwicklung berichtete u/Own_Bar_920, dass LiteLLM das Routing gut bewältigt habe, bei teamübergreifender Prompt-Versionierung und kontinuierlichen Evals beim Modellwechsel aber nicht ausgereicht habe – was letztlich zum Wechsel auf ein separates Tool führte.

Das geht über grundlegendes Gateway-Routing hinaus, und genau darum geht es: Wenn Routing der Hauptbedarf ist, hat sich LiteLLM in diesem Fall bewährt.

Sie erhalten eine fertige Funktionsliste – wobei manche Funktionen von der Edition abhängen – und behalten das Gateway in Ihrem eigenen Netzwerk. Zugleich sind Sie selbst für das Patchen verantwortlich, wie die bereits erwähnten Veröffentlichungen von Check Point deutlich gemacht haben, sowie für die Verfügbarkeit des Gateways, wie der Abschnitt zum Single Point of Failure gezeigt hat.

Planen Sie aber jemanden ein, der dafür geradesteht. Eine Sorge in einem r/LLMDevs-Thread über Gateways für den internen Zugriff war die Wartung. u/Informal-Writer9685 suchte etwas, das „keinen eigenen Engineer für die Wartung erfordert“, und fragte, ob die berichtete Instabilität von LiteLLM bei Upgrades in der eigenen Größenordnung ein echtes Problem sei oder nur im Produktionsbetrieb eine Rolle spiele.

Ein verwaltetes Gateway nutzen

Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter und das gehostete Gateway von Portkey betreiben den Dienst für Sie. Bei einer kompatiblen Anwendung braucht es für die erste Anfrage womöglich kaum mehr als eine geänderte URL und einen API-Schlüssel.

Der Kompromiss: Jeder Prompt läuft nun über einen Drittanbieter, bevor er den Modellanbieter erreicht. Das ist ein weiterer Auftragsverarbeiter für Ihre Compliance-Unterlagen, und ein Ausfall des Gateways ist ein Vorfall beim Gateway-Betreiber – beheben können Sie ihn nicht selbst.

So kam es am 17. und 19. Februar 2026 bei OpenRouter zu Ausfällen von 38 bzw. 35 Minuten, nachdem eine Caching-Abhängigkeit versagt hatte. Einige Kunden erhielten „User not found“-Fehler und verbrachten Zeit damit, völlig gültige API-Schlüssel zu debuggen. Der Fehler lag in der Infrastruktur des Gateways.

Zugutehalten muss man OpenRouter aber, dass das Unternehmen ein ausführliches Postmortem veröffentlicht und Schutzmaßnahmen ergänzt hat, damit ein Cache-Ausfall die Datenbank nicht mehr überlasten kann. Ein verwaltetes Gateway wie OpenRouter kann den Zugriff vereinfachen, aber wie u/QuanTradin auf r/LLMDevs anmerkt: Zusammengeführte Rechnungen senken die Ausgaben nicht automatisch.

Das vorhandene API-Gateway erweitern

Wenn Kong, Apigee oder Azure API Management Ihren Services bereits vorgeschaltet ist, bietet jede dieser Lösungen KI-spezifische Funktionen: Kong AI Gateway, die KI-Gateway-Richtlinien von Apigee und das KI-Gateway von Azure API Management. Sie können auf Ihrer vorhandenen Authentifizierung, Ihren Netzwerkregeln und Betriebsabläufen aufbauen und Modellkontrollen über Plugins oder Richtlinien ergänzen.

In einem großen Unternehmen kann das der Weg des geringsten organisatorischen Widerstands sein. Die KI-Funktionen sind allerdings jünger als die der eigenständigen Gateways. Testen Sie unbedingt tokenbasiertes Rate Limiting und Streaming mit dem vollständigen Satz an Plugins oder Richtlinien, den Sie einsetzen wollen.

Bauen Sie also ruhig das Hauptventil ein – das allmächtige Gateway. Der Engineer aus der Einleitung hat allerdings nicht ganz unrecht: Der Modellzugang eines Unternehmens sollte nicht davon abhängen, wer zufällig den richtigen Schlüssel in der Schublade hat.

Ein Gateway löst dieses Problem, indem es diese Schlüssel zentral verwaltet – womit allerdings umso mehr auf dem Spiel steht, wenn die Schublade offen bleibt. Sie müssen wissen, wem die Schublade gehört.

FAQ zu LLM-Gateways

Ist das LLM-Gateway kostenlos?

Wenn Sie die Kategorie meinen: Von einigen LLM-Gateways gibt es kostenlose Versionen.

Das Spektrum der LLM-Gateways reicht von kostenloser Open-Source-Software bis zu kostenpflichtigen Tarifen ab etwa 50 US-Dollar pro Monat, mit individuellen Preisen für Enterprise-Bereitstellungen. Manche berechnen stattdessen einen prozentualen Aufschlag; so schlägt etwa der Standard-Tarif von OpenRouter beim Kauf von Credits 5,5 % auf.

Welches LLM-Gateway ist das beste?

Welchen Aufwand sind Sie bereit, selbst zu übernehmen?

• Sehen Sie sich Bifrost oder Helicone an, wenn Sie selbst hosten und die Konfiguration selbst in der Hand haben möchten.
• Eine Managed-Lösung wie OpenRouter oder Vercel AI Gateway eignet sich für Teams, die den Betrieb des Dienstes lieber anderen überlassen.
• Wenn Sie bereits Kong oder Azure API Management nutzen, prüfen Sie zuerst deren KI-Funktionen.

Testen Sie Ihre engere Auswahl mit Ihren eigenen Anfragen – einschließlich der Frage, was passiert, wenn ein Anbieter ausfällt.

Bietet AWS ein LLM-Gateway an?

Ja. Amazon Bedrock AgentCore Gateway unterstützt Modellaufrufe über von AWS so genannte „Inference Targets“. Damit können Anwendungen über einen einzigen Endpunkt Anbieter wie Amazon Bedrock, OpenAI und Anthropic erreichen, während das Gateway die Zugangsdaten der Anbieter und das Routing übernimmt.