LLM-Gateway-Architektur: Routing, Caching, Fallbacks und Kostenkontrolle

Ein Dutzend Features in deinem Unternehmen ruft drei Modellanbieter auf. Jedes Team hat seinen eigenen API-Key, niemand weiß, welches Team letzten Monat wie viel ausgegeben hat, und als der Hauptanbieter eine Stunde lang 429-Fehler lieferte, fiel jede App auf ihre eigene Weise aus. Eine wechselte das Modell und zerschoss damit ihre JSON-Ausgabe.

Ein LLM-Gateway, auch KI-Gateway oder LLM-Proxy genannt, leitet jeden Modellaufruf durch einen einzigen Service, dem die Keys, das Routing und die Verbrauchsmessung gehören. Dieser Beitrag geht den Request-Pfad Stufe für Stufe durch und behandelt dann Routing, Caching, Token-Limits, Metriken, Sicherheit und die Gateways, die du übernehmen kannst.

Warum ein Gateway vor die Modellanbieter gehört

Limits und Rechnungen der Anbieter richten sich nicht nach deinem Organigramm. OpenAI setzt Rate Limits pro Organisation und Projekt, nicht pro Benutzer, Anthropic pro Organisation mit optionalen Workspace-Limits. Ein nächtlicher Batch-Job im selben Projekt wie ein Kunden-Chat kann die Tokens pro Minute des Chats aufbrauchen. Ein Gateway gibt dir einen zentralen Ort für Keys, Routing, Limits pro Team und Kostenzuordnung.

Es ersetzt dein API-Gateway nicht. Ein API-Gateway zählt Requests; ein LLM-Gateway zählt Tokens und Dollar, versteht gestreamte Antworten und behandelt eine 429 eines Anbieters als Grund, ein anderes Modell zu versuchen.

Der Request-Pfad, Stufe für Stufe

Günstige Prüfungen laufen zuerst: Nichts erreicht einen Anbieter, bevor der Request erlaubt ist und feststeht, dass er nicht schon beantwortet wurde.

1. Authentifizieren. Ordne den virtuellen Key einer App, einem Team und dessen erlaubten Modellen zu, oder gib 401 zurück.
2. Limits prüfen. Vergleiche die Token-Zähler und das Budget des Teams in Redis. Ist das Limit überschritten, gib 429 mit Retry-After zurück.
3. Policy anwenden. Setze die Modell-Allowlist und eine Obergrenze für max_tokens durch und maskiere personenbezogene Daten wie E-Mail-Adressen.
4. Cache prüfen. Ein Treffer liefert die gespeicherte Antwort, ohne den Anbieter aufzurufen.
5. Routen. Wähle ein Modell und eine geordnete Fallback-Kette.
6. Adapter aufrufen. Übersetze den Request in die API des Anbieters, häng den Anbieter-Key an und starte einen Timeout für das erste Token.
7. Retry oder Fallback bei 429, 5xx, Anthropics Überlastungsfehler 529 oder einem Timeout, aber nur, bevor das erste Token die App erreicht. Ein Anbieter kann noch einen Fehler senden, nachdem ein 200 den Stream gestartet hat, und ein Modellwechsel mitten in der Antwort näht zwei Antworten zusammen.
8. Streamen und messen. Reich die Server-Sent Events durch und schreib asynchron ein Nutzungsereignis. Die Chat Completions API von OpenAI sendet die Nutzung nur mit stream_options.include_usage in einem letzten Chunk, und bei einem abgebrochenen Stream geht sie verloren, also lies weiter, auch wenn ein Client die Verbindung getrennt hat.

Die Schritte 1 bis 4 sollten reine Lookups im Speicher oder in Redis sein; Logging und Evals bleiben außerhalb des Request-Pfads.

Routing-Strategien

Der sicherste Fallback ist dasselbe Modell bei einem anderen Host, etwa ein Claude-Modell über die Anthropic API und über Amazon Bedrock. Eine andere Modellfamilie braucht eigene Evals, weil Tool-Calls und JSON-Ausgabe zuerst brechen, und jeder Fallback braucht freies Kontingent.

Wiederhole nur in einer Schicht: Das OpenAI-Python-SDK wiederholt standardmäßig zweimal, und die Doku von LiteLLM warnt, dass gestapelte Retries aus einem Request (1 + N)² Upstream-Aufrufe machen. Gönn einem fehlschlagenden Deployment eine Pause, statt weiter darauf einzuhämmern, wie es LiteLLM nach einer 429 standardmäßig für 5 Sekunden tut; das Circuit-Breaker-Pattern verallgemeinert diese Idee.

Caching: Exact Match, semantisch und beim Anbieter

Exact-Match-Caching ist sicher, aber eng: Cloudflare AI Gateway hasht Anbieter, Endpunkt, Modell, Auth-Header und den gesamten Body, also ist jede Änderung ein neuer Eintrag. Nimm den Mandanten in deinen Cache-Key auf, sonst kann die Antwort für einen Kunden bei einem anderen landen. Semantisches Caching trifft auch Umformulierungen, aber „meine Bestellung stornieren“ und „mein Abo stornieren“ können nah beieinander landen, also nutze es nur dort, wo ein Beinahe-Treffer harmlos ist.

Das Caching beim Anbieter spart oft am meisten. Anthropic cacht mit cache_control markierte Präfixe für 5 Minuten, verlängert bei jedem Treffer, und Cache-Lesezugriffe kosten bei den meisten Modellen das 0,1-Fache des Basis-Inputpreises. OpenAI cacht bei unterstützten Modellen standardmäßig, gecachter Input ist bis zu 95 % günstiger (Stand beim Schreiben: November 2026). Halte System-Prompts byte-identisch, ohne Zeitstempel am Anfang, maskiere deterministisch und pinne eine Konversation an ein Deployment, denn jedes Anbieterkonto hat seinen eigenen Cache.

Bei angenommenen 3 USD pro Million Input-Tokens kosten ein System-Prompt mit 6.000 Tokens und eine Frage mit 500 Tokens 0,0195 USD. Wird das Präfix aus dem Cache gelesen, ergibt sich 6.000 × 0,30 USD/M + 500 × 3 USD/M = 0,0033 USD, etwa 83 % weniger pro Treffer. Der Beitrag zu Caching-Strategien behandelt die Invalidierung.

Token-Rate-Limits und Team-Budgets

Requests pro Minute sind ein schlechtes Limit für LLM-Traffic: Ein Request kann 50 Tokens tragen oder 200.000. Begrenze die Tokens pro Minute pro Team, deckle max_tokens und setz ein monatliches Budget in Dollar. Wie groß ein Request ist, weißt du erst, wenn er fertig ist, also wähle einen Ansatz:

• Reservieren, dann abgleichen. Zähle den geschätzten Input plus max_tokens vorab und korrigiere danach. OpenAI rechnet bei seinen eigenen Limits den größeren Wert aus max_tokens und einer zeichenbasierten Schätzung an.
• Laufend zählen. Anthropic zählt Output-Tokens, während sie erzeugt werden, und Cache-Lesezugriffe zählen bei den meisten Modellen nicht zu den Input-Tokens pro Minute.
• Hinterher zählen. Einfach, aber Lastspitzen schießen über das Limit. Cloudflare schreibt, dass gleichzeitige Requests seine Ausgabenlimits kurzzeitig überschreiten können.

Halte die Zähler in Redis, geteilt von allen Gateway-Instanzen; das Rate-Limiter-Systemdesign behandelt die Algorithmen und einen Redis-Ausfall. Bepreise die Nutzung mit einer versionierten Preistabelle, alarmiere bei 80 % eines Budgets und entscheide, ob 100 % einen harten Stopp oder ein günstigeres Modell bedeuten.

Was du messen solltest

Erfasse die Time to First Token pro Anbieter und Modell, Input-, Output- und gecachte Tokens pro Team, Kosten pro Team und Feature, Fehler nach Typ sowie Fallback- und Cache-Trefferquoten. Die GenAI-Konventionen von OpenTelemetry benennen Attribute wie gen_ai.usage.input_tokens, sind aber noch in Entwicklung, also pinne die Version, die du ausgibst. Das Observability-Architekturdiagramm zeigt, wohin die Signale gehen.

Sicherheit: Was ein Gateway nicht löst

Ein Gateway hält jeden Anbieter-Key und sieht jeden Prompt, also gib ihm wenige Admins, auditierte Konfigurationsänderungen und Logs, die Metadaten zu jedem Aufruf behalten, Prompts aber nur stichprobenartig, maskiert und kurzlebig.

Es hilft gegen das, was die OWASP Top 10 für LLM-Anwendungen unbegrenzten Verbrauch (Unbounded Consumption) nennen: Limits und Budgets verhindern, dass ein Agent in einer Schleife oder ein geleakter Key die Rechnung in die Höhe treibt. Prompt Injection löst es nicht; laut OWASP ist unklar, ob es eine narrensichere Prävention gibt, und Anweisungen, die in einem abgerufenen Dokument versteckt sind, sehen für ein Gateway wie Daten aus. Die Abwehr besteht aus Tools mit minimalen Rechten, Freigaben und strikter Ausgabebehandlung, wie im KI-Agent-Architekturdiagramm.

Selbst bauen oder übernehmen

Envoy AI Gateway ist im September 2026 als Agent Router der Agentic AI Foundation beigetreten. Bau nur, was spezifisch für dich ist, etwa Routing nach Datenklasse; der teure Teil ist, die Anbieter-Adapter aktuell zu halten. Ein Managed Gateway setzt einen Dritten in den Pfad jedes Prompts; ein selbst gehostetes macht Redis, Postgres und Upgrades zu deinem Job.

Das LLM-Gateway-Diagramm

So liest du es:

• Zwei Apps rufen mit ihren eigenen virtuellen Keys einen einzigen Endpunkt im OpenAI-Format auf, ohne Anbieter-Key.
• Fünf Stufen laufen nacheinander, über jeder steht ein kurzer Text dazu, was sie entscheidet. Ein Request kann bei Auth (401, 429) oder bei einem Cache-Treffer enden.
• Drei Ziele: OpenAI als primärer Anbieter, Anthropic als gestrichelter Fallback bei 429 oder 5xx und ein selbst gehostetes vLLM-Modell für sensible Daten.
• Unter den Stufen: Postgres für Keys und Budgets, Redis für Zähler und gecachte Antworten und das Nutzungslog, das asynchron geschrieben wird.
• Der Markdown-Block listet Beispieleinstellungen für ein Team.

LLM-Gateway-Diagramme klar zeichnen

• Zeichne Stufen, nicht einen Kasten. Ein einzelnes Gateway-Rechteck verbirgt, ob die Maskierung vor dem Cache passiert.
• Schreib Bedingungen an die Kanten: „fallback on 429/5xx“, „sensitive data“, „miss“.
• Markiere, wo Daten dein Netzwerk verlassen, damit externe Anbieter anders aussehen als das selbst gehostete Modell.
• Zeichne asynchrone Pfade gestrichelt, etwa Metering und Logging.
• Lass den Modellkatalog weg; er gehört in die Konfiguration.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und leg ein Diagramm an.
2. Füge einen Rahmen aus dem Basis-Pack mit dem Namen LLM gateway hinzu.
3. Füge darin fünf Komponente-Nodes aus dem C4-Modell-Pack nebeneinander hinzu: 1 Auth, 2 Policy, 3 Cache, 4 Router und 5 Adapters, mit einem Text aus dem Basis-Pack über jedem.
4. Füge darunter Postgres und Redis aus dem Daten-Pack hinzu und ein Datenlager für das Nutzungs- und Kostenlog.
5. Füge links vom Rahmen zwei Container-Nodes aus dem C4-Modell-Pack für die Apps hinzu; rechts zwei Externes System-Nodes für OpenAI API und Anthropic API und einen Endpunkt aus dem ML-Pack für das selbst gehostete Modell.
6. Zeichne beschriftete Kanten; stell den Fallback und die Nutzungsereignisse gestrichelt dar.
7. Füge einen Markdown-Block aus dem Basis-Pack mit den Beispieleinstellungen hinzu.

Wenn du den Pfad als Mermaid-Flussdiagramm pflegst, macht der Mermaid-Konverter daraus einen bearbeitbaren ersten Entwurf. Das Beispiel nutzt 15 Diagramm-Nodes und bleibt damit im Free-Plan.

FAQ

Was ist ein LLM-Gateway? Ein Service, durch den jeder Modellaufruf läuft. Er hält die Anbieter-Keys, routet zwischen Modellen und weicht bei Bedarf auf andere aus, cacht, setzt Token-Limits und Budgets durch und erfasst die Nutzung pro Team.

Was ist der Unterschied zwischen einem KI-Gateway und einem API-Gateway? Ein API-Gateway begrenzt HTTP-Requests. Ein KI-Gateway versteht zusätzlich Tokens, Streaming und Anbieterfehler, kann also nach Tokens begrenzen, Kosten zuordnen und auf ein anderes Modell ausweichen.

Was ist der Unterschied zwischen semantischem Caching und Prompt-Caching? Semantisches Caching läuft in deinem Gateway und liefert eine gespeicherte Antwort auf eine ähnliche Frage. Prompt-Caching läuft beim Anbieter und verwendet ein bereits verarbeitetes Prompt-Präfix wieder; das Modell schreibt trotzdem eine neue Antwort.

Wie begrenzt man LLM-Requests nach Tokens? Halte in Redis einen Token Bucket pro Team, reserviere vor jedem Aufruf den geschätzten Input plus max_tokens, korrigiere danach und gib am Limit 429 mit Retry-After zurück.

Kann ein LLM-Gateway Prompt Injection verhindern? Nein. Es kann offensichtliche Angriffe filtern und den Schaden mit Budgets begrenzen, aber eingeschleuste Anweisungen in Dokumenten sehen wie Daten aus. Verteidige dich in der Anwendung mit Tools mit minimalen Rechten und mit Freigaben.

Kostenlos starten — ein Seat, keine Kreditkarte.