Was ein LLM-Gateway leistet und wann ein Unternehmen eines braucht

Welche Probleme ein LLM-Gateway löst

Ein Gateway löst Abstimmungsprobleme. Sie entstehen, wenn mehrere Teams Modelle nutzen, und keine einzelne Anwendung kann sie allein beheben. Diese fünf hören wir am häufigsten, in den Worten unserer Gesprächspartner:

• „Jedes Team hat eigene Anbieterschlüssel, und niemand weiß, wie viele es gibt.“ Das Gateway verwahrt die Anbieterschlüssel und gibt jedem Team, Service oder Entwickler einen eigenen Gateway-Schlüssel, der sich einzeln begrenzen und sperren lässt. In LiteLLM etwa trägt jeder virtuelle Schlüssel die erlaubten Modelle, sein Budget und das Team, dem er gehört.
• „Wir bekommen eine Rechnung und können nicht sagen, welches Team sie verursacht hat.“ Jede Anfrage wird mit Schlüssel, Team, Modell und Tokenzahl protokolliert, sodass sich die Kosten pro Team und Anwendungsfall summieren lassen.
• „Ein Modellwechsel bedeutet Codeänderungen in jeder Anwendung.“ Anwendungen rufen einen Endpunkt mit einem Modellnamen auf, und das Gateway ordnet diesen Namen einem Deployment beim Anbieter zu. Der Wechsel wird zur Konfigurationsänderung, wobei Prompts und Ausgaben mit dem neuen Modell trotzdem getestet werden müssen.
• „Fällt der Anbieter aus, fallen unsere Funktionen mit aus.“ Das Gateway wiederholt Anfragen und weicht nach vorab festgelegten Regeln auf ein anderes Deployment oder einen anderen Anbieter aus.
• „Welche Daten dürfen an welches Modell?“ Ein Gateway kann die Antwort durchsetzen, aber nicht selbst finden. Es steuert, welche Schlüssel und Teams welche Modelle aufrufen dürfen, und protokolliert, was gesendet wurde. Ob ein Prompt Kundendaten enthält, weiß es von sich aus nicht. Manche Gateways bieten die Erkennung oder Schwärzung personenbezogener Daten als optionalen Guardrail an, die Klassifizierungsregeln kommen aber von Ihren Datenschutzverantwortlichen, und jede Anwendung entscheidet weiterhin selbst, was sie in einen Prompt schreibt.

Wenn keines dieser Probleme schon drückt, ist ein Gateway nur ein weiterer Dienst, den jemand patchen, überwachen und verfügbar halten muss, und es kann warten. Das ist unsere Einschätzung, und es ist der häufigste gute Grund, die Einführung zu verschieben.

LLM-Kosten nach Team, Aufgabe und Ergebnis zuordnen

Was ein Gateway übernimmt und was außerhalb bleibt

Ein Gateway steuert den Verkehr zu den Modellen. Es betreibt die Modelle nicht, entscheidet nicht, welche Daten eine Anwendung lesen darf, und sagt Ihnen nicht, ob die Antworten etwas taugen. Die Tabelle zeigt die übliche Aufteilung.

Die Aufteilung zählt bei der Planung. Nach unserer Erfahrung bleiben in einem Projekt, das als „Gateway installieren“ zugeschnitten ist, die Evaluierung der Fallbacks, die Entscheidung über die Log-Aufbewahrung und die Guardrail-Richtlinie ohne Verantwortlichen, und genau danach fragen Prüfer und Störungsanalysen.

LLM-Routing ohne versteckten QualitätsverlustFailover zwischen LLM-Anbietern ohne Qualitäts- oder Zugriffsänderung

Die wichtigsten LLM-Gateways, Stand 7. November 2026

Die meisten Unternehmen wählen zwischen einem selbst betriebenen Open-Source-Gateway, den KI-Funktionen eines bereits genutzten API-Management-Produkts und einem gehosteten Gateway. Die Tabelle behandelt sieben gängige Optionen und nennt nur Fakten, die wir am 7. November 2026 auf den Seiten der Anbieter geprüft haben. Eigentümer, Namen und Funktionen haben sich in diesem Markt allein in diesem Jahr mehrfach geändert, prüfen Sie also vor einer Entscheidung erneut.

Viele Listen zu „bestes LLM-Gateway“ oder „LiteLLM-Alternativen“ stammen von Anbietern eines konkurrierenden Gateways. Um Namen zu sammeln, sind sie nützlich, für die Auswahl weniger. Zwei der sieben Optionen oben wurden 2026 übernommen oder sollen übernommen werden, eine dritte wurde umbenannt. Das ist ein praktisches Argument dafür, Ihre Anwendungen auf einem Standard-API-Format zu halten, damit sich auch das Gateway selbst austauschen lässt.

LiteLLM sicher in Produktion betreiben

Wie Sie ein LLM-Gateway auswählen

Entscheiden Sie danach, wo das Gateway laufen muss und wer es betreibt, und prüfen Sie dann Anbieterabdeckung, Lizenz und Datenregeln. Die Funktionslisten ähneln sich so stark, dass sie allein selten den Ausschlag geben.

• Selbst betrieben oder gehostet. Ein selbst betriebenes Gateway läuft in Ihrem Netz oder Cloud-Konto, Prompts und Logs bleiben also dort, wo Sie es installieren, aber Sie patchen, skalieren und überwachen es. Ein gehostetes Gateway nimmt Ihnen diese Arbeit ab und bringt einen weiteren Verarbeiter Ihrer Prompts ins Spiel, dessen Bedingungen Ihre Datenschutzverantwortlichen akzeptieren müssen.
• Vorhandenes API-Management. Wenn Sie bereits Azure API Management oder Kong betreiben, prüfen Sie zuerst deren KI-Funktionen. Sie decken Schlüssel, Limits und Logging womöglich ab, ohne dass eine neue Komponente hinzukommt, die jemand erst lernen muss.
• Abdeckung von Anbietern und Clients. Listen Sie die Anbieter und API-Formate auf, die Sie jetzt und im nächsten Jahr brauchen, einschließlich der Modelle in Ihrem eigenen Azure- oder AWS-Konto und selbst betriebener Modelle. Coding-Agenten bringen eine weitere Bedingung mit: Claude Code arbeitet mit jedem Gateway, das ein unterstütztes API-Format anbietet, und Anthropic weist darauf hin, dass das Gateway mit neuen Claude-Code-Funktionen Schritt halten muss.
• Lizenz. Trennen Sie die Funktionen, die Sie brauchen, von denen der freien oder Open-Source-Version. Bei LiteLLM erfordern SSO für mehr als fünf Nutzer, Audit-Logs und Budgets nach Tags die Enterprise-Lizenz. Entscheiden Sie also früh, ob Sie sie kaufen oder diese Teile rund um das Gateway selbst bauen.
• EU-Datenregeln. Halten Sie für jede Option fest, wo Prompts, Antworten und Logs verarbeitet und gespeichert werden. Bei gehosteten Routern kann die Antwort je nach Datenart verschieden ausfallen: OpenRouter verarbeitet in die EU geroutete Prompts in Europa, gibt aber an, dass Konto-, Abrechnungs- und andere Betriebsdaten in den USA verarbeitet werden können. Bei Cloud-Modellen zählen Region und Deployment-Typ beim Modellanbieter ebenso viel wie das Gateway.
• Betriebsaufwand. Zählen Sie die Teile neben dem Gateway selbst mit. Die LiteLLM-Dokumentation empfiehlt Redis für jede Installation mit mehr als einem Worker oder Replikat: Ohne Redis werden Rate Limits pro Worker gezählt, ein Limit von 100 Anfragen pro Minute lässt bei vier Workern also 400 durch, und ein gesperrter Schlüssel bleibt auf den Workern nutzbar, die die Sperre nicht verarbeitet haben. Dazu kommen eine Datenbank für Schlüssel und Kostenlogs, Updates und eine Rufbereitschaft für eine Komponente, von der jede KI-Funktion abhängt.

Was wir oft sehen, ohne dass es eine Regel wäre: Teams, die auf Azure API Management oder Kong standardisiert sind, beginnen dort. Teams, die Cloud-Modelle im eigenen AWS- oder Azure-Konto plus selbst betriebene Modelle brauchen und Leute für den Betrieb haben, landen meist bei einem selbst betriebenen LiteLLM. Teams ohne Betriebskapazität und mit weniger strengen Datenvorgaben nutzen ein gehostetes Gateway.

EU-Datenresidenz mit Azure OpenAI und Amazon Bedrock

Wo das Gateway in Ihrer KI-Plattform sitzt

Das Gateway sitzt in der Mitte der Plattform: Alles, was ein Modell aufruft, läuft hindurch, und es ist die einzige Komponente, die die Zugangsdaten der Anbieter kennt. Der Weg vom Aufrufer zum Modell sieht so aus:

1. 1

   Aufrufer

   Anwendungen, Agenten und Coding-Agenten wie Claude Code. Jeder meldet sich mit einem eigenen Gateway-Schlüssel oder über Ihren Identity Provider an, nie mit einem Anbieterschlüssel.

2. 2

   Gateway

   Prüft Schlüssel, Modellberechtigung und Budget, wendet Guardrails an, wählt ein Deployment und schreibt einen Logeintrag. Es läuft in Ihrem Netz oder beim Hoster, wenn Sie ein gehostetes Gateway gewählt haben.

3. 3

   Modelle

   Cloud-Modelle im eigenen Azure- oder AWS-Konto, direkte Anbieter-APIs, wo sie freigegeben sind, und selbst betriebene Modelle mit vLLM auf Kubernetes. Nur das Gateway erreicht sie.

4. 4

   Logs und Monitoring

   Logs und Metriken des Gateways fließen in Ihr bestehendes Monitoring, wo Kosten pro Team, Fehlerraten und Latenz pro Anbieter ausgewertet und alarmiert werden.

Das funktioniert nur, wenn Verkehr nicht am Gateway vorbeilaufen kann. Verwahren Sie Anbieterschlüssel in einem Secrets Manager, den nur das Gateway lesen darf, beschränken Sie ausgehenden Netzwerkzugriff auf Modell-Endpunkte und vergleichen Sie die Nutzungsberichte der Anbieter mit den Gateway-Logs, um direkte Aufrufe zu finden. Auch Coding-Agenten lassen sich festlegen: Mit Stand 7. November 2026 lehnt Claude Code ab Version 2.1.285 Sitzungen mit anderem Ziel als Ihrem Gateway ab, wenn in den verwalteten Einstellungen allowedProviders auf customEndpoint gesetzt ist.

Secrets und Zugangsdaten für Agenten: Ablage und RotationCoding-Agenten über ein LLM-Gateway leiten

Ein Gateway Schritt für Schritt einführen

Führen Sie ein Gateway Team für Team und Route für Route ein und testen Sie Budgets, Logging und Fallbacks, bevor die erste produktive Anfrage hindurchläuft.

1. 1

   Bestehende Nutzung erfassen

   Listen Sie jedes Anbieterkonto, jeden Schlüssel und jedes Team auf, das heute Modelle aufruft, und was jedes laut Rechnung ausgibt.

2. 2

   Regeln festlegen

   Legen Sie fest, welche Teams welche Modelle nutzen dürfen, welche Budgets gelten, welche Routen gecacht werden dürfen und ob und wie lange Prompts protokolliert werden. Den letzten Punkt geben Ihre Datenschutzverantwortlichen frei.

3. 3

   Installieren und härten

   Betreiben Sie das Gateway in Ihrer Umgebung oder richten Sie den gehosteten Dienst ein, mit Anbieterschlüsseln im Secrets Manager, ohne öffentliche Admin-Oberfläche, mit festgelegten Versionen und Alarmen bei Fehlern und Latenz.

4. 4

   Vor echtem Verkehr testen

   Prüfen Sie, ob Budgets Anfragen stoppen, gesperrte Schlüssel auf jedem Replikat ungültig werden, Fallbacks bei den richtigen Fehlern greifen und die Logs enthalten, was Sie vereinbart haben. Schicken Sie Ihr Evaluierungsset auch über die Fallback-Routen.

5. 5

   Mit einem Team beginnen

   Stellen Sie eine Anwendung oder ein Team auf den Gateway-Endpunkt um, vergleichen Sie die Gateway-Kosten mit dem Bericht des Anbieters für denselben Zeitraum und klären Sie Abweichungen, bevor das nächste Team folgt.

6. 6

   Umgehungen schließen

   Sobald alle Teams über das Gateway laufen, sperren Sie die alten Anbieterschlüssel in den Anwendungen und blockieren den direkten Netzwerkzugriff auf die Anbieter.

7. 7

   Wie ein Produktivsystem betreiben

   Patchen Sie nach Plan, prüfen Sie die Kosten pro Team monatlich und wiederholen Sie die Tests für Fallbacks und Schlüsselsperren nach jedem Update.

Cloudsail richtet LiteLLM und die Plattform drumherum ein, einschließlich der Tests oben, im eigenen AWS- oder Azure-Konto des Kunden oder auf seinen eigenen Servern. Wenn Sie den Betrieb nicht selbst übernehmen möchten, können unsere Engineers in Deutschland und Polen das danach tun.

LiteLLM-Gateway: Aufbau und BetriebLLM-Plattform-EngineeringKI im eigenen Cloud-Konto