Das erste LLM-Feature geht als direkter Aufruf von einem Service an Bedrock live. Das zehnte geht genauso live, von zehn Services, mit zehn Zugangsdaten-Sätzen, zehn Retry-Policies und ohne eine einzige Stelle, an der sichtbar ist, wer wie viel ausgibt. Das ist der Moment, in dem ein Platform-Team merkt, dass es ein LLM-Gateway braucht, meist ein Quartal nachdem der Bau noch günstig gewesen wäre. Ein Gateway ist die gemeinsame Eingangstür, durch die jeder Modellaufruf läuft, und sie existiert, um die vier Dinge zu übernehmen, die einzelne Teams sonst immer wieder schlecht neu erfinden: Authentifizierung, Quota, Routing und Audit.

Die nützliche Umdeutung: Ein Gateway ist kein KI-Feature. Es ist dieselbe Control Plane, die man ohnehin vor jede geteilte, abgerechnete, teure Abhängigkeit stellt. Man würde nicht jedem Service sein eigenes Datenbank-Admin-Passwort geben und sein eigenes Connection-Limit wählen lassen. Modellzugriff ist da nicht anders, nur dass die Rechnung schneller wächst und die Fehlerbilder lauter sind.

Was das Gateway tatsächlich bündelt

Der Wert liegt nicht im Durchreichen der Anfrage. Er liegt darin, die vier übergreifenden Aufgaben zu besitzen, die nicht in Anwendungscode gehören:

  • Authentifizierung. Aufrufer weisen sich beim Gateway mit einer Service-Identität aus. Das Gateway hält die eine Zugangsdaten, die mit Bedrock spricht. Keine Anwendung bekommt je einen langlebigen Modell-Key zu Gesicht, und das Rotieren dieses Keys ist eine Änderung, nicht zwanzig.
  • Quota. Token-Budgets pro Team und pro Modell liegen an einer Stelle. Eine außer Kontrolle geratene Schleife in einem Service läuft gegen ihre eigene Grenze, statt das gemeinsame Tokens-pro-Minute-Limit aufzuzehren und alle anderen zu drosseln.
  • Routing. Das Gateway bildet einen logischen Modellnamen auf ein konkretes Deployment ab: welche Region, welcher Anbieter, welcher Fallback, wenn das primäre Modell drosselt. Anwendungen fragen nach "dem Summarizer", nicht nach einer bestimmten Modell-ID in einer bestimmten Region.
  • Audit. Jede Anfrage und jede Antwort läuft durch einen Engpass, sodass Kostenzuordnung, Prompt-Logging und Missbrauchserkennung alle an einer einzigen Naht ansetzen können. Ohne das ist Kosten-pro-Feature ein Ausgrabungsprojekt.

Bemerkenswert: Keines davon ist ein Problem der Modellqualität. Es sind Plattformprobleme, die nur neu wirken, weil die Abhängigkeit ein Modell ist.

Eigenbau vs LiteLLM vs API Gateway

Es gibt drei ehrliche Muster, und welches richtig ist, hängt davon ab, wie viel vom Obigen man am ersten Tag wirklich braucht.

LiteLLM (oder einen ähnlichen Proxy) einsetzen

Ein Open-Source-Proxy wie LiteLLM liefert von Haus aus eine einheitliche API über Anbieter hinweg, Budgets pro Key und einfaches Routing. Es ist der schnellste Weg zu einem echten Gateway, das die vier Aufgaben schon kennt. Der Trade-off: Man betreibt und patcht jetzt einen zustandsbehafteten Service auf dem kritischen Pfad jedes KI-Features, und seine Meinung zu Routing und Logging wird die eigene Meinung. Für die meisten Teams, die ihr zweites oder drittes LLM-Feature aufbauen, ist das der richtige Standard. Man kauft die Control Plane, statt sie zu bauen.

Auf API Gateway plus Lambda setzen

Wer bereits tief in AWS steckt, bekommt mit Amazon API Gateway vor einem kleinen Lambda-Authorizer und einer Proxy-Funktion Auth, Usage Plans, Throttling und Access Logs aus Bausteinen, die man ohnehin schon betreibt. Usage Plans übernehmen Rate-Limits pro Key, der Authorizer die Identität, CloudWatch die Audit-Spur. Der Preis: modellspezifische Logik, Streaming, Token-Zählung und Provider-Fallback sind Code, den man selbst schreibt und pflegt. Dieses Muster gewinnt, wenn die eigenen Governance-Anforderungen AWS-förmig sind und man lieber eine bestehende Plattform erweitert, statt eine neue Abhängigkeit einzuführen.

Einen maßgeschneiderten Service bauen

Eigenbau ist nur dann richtig, wenn die eigenen Routing- oder Audit-Anforderungen wirklich ungewöhnlich sind: komplexe Modellauswahl-Policies, Entscheidungen zur Datenresidenz pro Anfrage, oder Logging, das eine Regulierungsbehörde in einer bestimmten Form verlangt. Die meisten Teams, die von Grund auf bauen, bauen in Wahrheit LiteLLM langsamer nach. Das ist die letzte Wahl, und nur, wenn man die Anforderung benennen kann, die die Fertiglösung nicht erfüllt.

Das Fehlerbild, das ein Gateway verhindert

Ohne Gateway ist der Ausfall nicht dramatisch, er ist langsam. Zugangsdaten verteilen sich. Jedes Team setzt sein eigenes Timeout und seinen eigenen Retry, sodass ein kurzer Ausfall beim Anbieter zu einem Retry-Sturm wird, der einen durch das eigene Token-Kontingent treibt. Niemand kann beantworten, "was hat das Support-Summarizer-Feature letzten Monat gekostet", ohne Logs über Services hinweg zu durchsuchen. Dann fragt ein Security-Review, wer welches Modell mit welchen Daten aufrufen darf, und die ehrliche Antwort ist "wir sind uns nicht sicher", was die Antwort ist, die einen Launch stoppt.

Ein Gateway macht all das zu Konfiguration. Das ist der ganze Pitch: die übergreifenden Entscheidungen aus zwanzig Codebases herausnehmen und in eine einzige packen, über die man nachdenken kann.

Die Grenze an der richtigen Stelle ziehen

Das Gateway sollte schlank bleiben. Es sollte Identität, Quota, Routing und Logging übernehmen und sich aus Prompt-Konstruktion und Geschäftslogik heraushalten. Sobald das Gateway anfängt, Prompts zu besitzen, wird es zu einer geteilten Bibliothek mit einem Netzwerk-Hop, und jedes Team hängt an dessen Release-Zyklus fest. Das langlebige Design ist ein langweiliger Proxy mit klaren Meinungen zu Governance und keiner Meinung dazu, was man das Modell fragt.

Fazit

Jedes Platform-Team, das mehr als ein LLM-Feature ausliefert, baut irgendwann ein Gateway. Die einzige Wahl ist, ob man es bewusst baut, früh, solange es noch ein kleiner Proxy ist, oder zufällig, spät, als Aufräumprojekt, nachdem sich die Zugangsdaten verteilt haben und die Rechnung zum Rätsel geworden ist. Setzt einen Proxy ein, wenn möglich, erweitert API Gateway, wenn ihr AWS-nativ seid, und baut nur gegen eine Anforderung, die ihr benennen könnt, von Grund auf. Das Gateway ist nicht der Ort, an dem KI passiert. Es ist der Ort, an dem die Governance, die man ohnehin gebraucht hätte, endlich ein Zuhause findet.

Weiterlesen

Für die Plattform- und Infrastrukturseite des Betriebs einer geteilten Control Plane wie dieser gibt es die Cloud-Field-Notes auf ercan.cloud, und den Hub auf ercanermis.com.