AI Gateway (LLM Gateway) erklärt: was es tut, wann Sie eins brauchen und was es kostet

Die erste LLM-Funktion ist einfach. Ein API-Schlüssel in eine Umgebungsvariable, das SDK des Anbieters aufrufen, ausliefern. Ärger macht die zweite und dritte: drei Anbieterschlüssel in fünf Diensten, niemand kann sagen, welches Team letzten Dienstag das Geld ausgegeben hat, und der Ausfall eines Anbieters reißt das ganze Produkt mit. Die übliche Antwort auf alle drei Probleme ist dasselbe Stück Infrastruktur, und es hat zwei Namen: AI Gateway und LLM Gateway.

Dieser Leitfaden erklärt, was ein AI Gateway ist, was darin steckt, wie es sich von Ihrem vorhandenen API Gateway unterscheidet, wann es sich lohnt, was sich in Ihrem Code ändert und was bricht, sobald echter Verkehr hindurchläuft. Und er misst den Teil, den die Landingpages der Anbieter auslassen: was der zusätzliche Hop kostet. Vier Gateways, ein Mock-Modell, dasselbe CPU-Budget für jedes und ein Repository, das Sie selbst ausführen können.

Was ist ein AI Gateway?

Ein AI Gateway, auch LLM Gateway genannt, ist ein Proxy zwischen Ihren Anwendungen und den Modellanbietern, die sie aufrufen. Jede Anwendung schickt ihre Anfragen an einen Endpunkt, meist OpenAI-kompatibel, mit einem Schlüssel, den das Gateway ausgegeben hat. Das Gateway prüft, wer anfragt, setzt Request- und Token-Limits sowie Budgets durch, wählt Anbieter und Modell, wiederholt oder weicht aus, wenn ein Anbieter ausfällt, und protokolliert Tokens, Kosten und Latenz jedes Aufrufs. Die echten Anbieterschlüssel verlassen es nie.

Das ist die ganze Idee: eine Tür zwischen Ihrem Code und jedem Modell. Der Rest dieses Artikels handelt davon, was an dieser Tür passiert.

AI Gateway vs. LLM Gateway vs. LLM Proxy vs. LLM Router

Das Vokabular ist unübersichtlicher als das Konzept. Diese Begriffe begegnen Ihnen in Dokus und auf Anbieterseiten:

Was in einem AI Gateway steckt

Jedes Gateway am Markt kombiniert dieselben Bausteine. Manche bieten alle, manche nur einige:

Anfrageweg von links nach rechts, Antwortweg zurück. Die Anbieterschlüssel liegen in der Control Plane und erreichen nie eine Anwendung.

• Auth und virtuelle Schlüssel. Anwendungen bekommen Schlüssel vom Gateway, je Team, Anwendung oder Nutzer, und das Gateway tauscht sie auf dem Weg nach draußen gegen den echten Anbieterschlüssel. Ein geleakter Schlüssel bedeutet nicht mehr, den OpenAI-Schlüssel an zwölf Stellen zu rotieren.
• Limits. Nicht nur Anfragen pro Sekunde, sondern Tokens pro Minute und Tokens pro Tag , denn eine Anfrage kann 200 oder 200.000 Tokens kosten. Die Algorithmen sind dieselben wie bei jeder API, die Fehler auch; dazu habe ich Rate Limiting in der Praxis geschrieben.
• Budgets. Ausgabengrenzen je Team, Schlüssel oder Projekt, in Geld gezählt. Das Gateway kennt den Preis jedes Modells und kann einen außer Kontrolle geratenen Agenten bei einem festen Betrag stoppen statt am Monatsende.
• Routing, Retries und Fallback. Modell-Aliase (chat-default zeigt auf das, was Sie diese Woche festlegen), Lastverteilung über Schlüssel oder Regionen, Wiederholungen mit Backoff und Ausweichen auf einen anderen Anbieter, wenn der erste 429 oder 5xx liefert. Weil Anbieter unterschiedliche APIs haben, übersetzt das Gateway Anfrage- und Antwortformate im Flug.
• Caching. Exaktes Caching identischer Prompts ist billig und sicher. Semantisches Caching beantwortet auch nur ähnliche Prompts, spart mehr und liegt öfter daneben.
• Guardrails. Prüfungen von Prompts und Antworten: personenbezogene Daten, Geheimnisse, gesperrte Themen, Muster von Prompt Injection. Sie helfen, sind allein aber keine Sicherheitsgrenze; warum, steht in Prompt-Injection-Abwehr.
• Observability und Kosten. Jeder Aufruf protokolliert mit Modell, Tokens, Latenz, Kosten, Team und Schlüssel. Oft ist das der erste Grund für ein Gateway: Die Finanzabteilung will den Bericht.

Selbst betriebene Modelle behandelt das Gateway genauso. Ein vLLM- oder Ollama-Server wird ein weiterer Anbieter hinter demselben Endpunkt, mit denselben Schlüsseln, Limits und Logs.

AI Gateway vs. API Gateway

Wenn Sie bereits ein API Gateway betreiben, liegt die Frage nahe, warum das nicht reicht. Teilweise reicht es. Kong ist buchstäblich ein API Gateway mit KI-Plugins. Einem reinen API Gateway fehlt aber, was LLM-Verkehr anders macht:

Kurz: Ein API Gateway zählt Anfragen, ein AI Gateway zählt Tokens und Geld.

Brauchen Sie ein AI Gateway?

Nicht immer. Ein Gateway ist ein weiterer Dienst, den Sie betreiben, absichern und aktuell halten müssen, und es liegt im heißen Pfad jedes Modellaufrufs. Für eine einzelne Anwendung mit einem Anbieter fügt es vor allem einen Hop hinzu. Drei Fragen entscheiden:

Die meisten Teams kommen schneller an Frage 2 als gedacht: Das zweite Team, das denselben OpenAI-Schlüssel will, ist der Moment.

Die mittlere Option verdient einen Satz. Eine Client-Bibliothek , die viele Anbieter kapselt (das LiteLLM-Python-SDK, das Vercel AI SDK und andere), liefert eine API, Retries und Fallback in Ihrem Prozess, ohne Netzwerk-Hop. Was sie nicht liefern kann, ist ein zentraler Ort für Schlüssel, Budgets und Logs über Teams hinweg. An dieser Linie hört die Bibliothek auf und das Gateway fängt an.

Und selbst schreiben? Ein Proxy, der Anfragen im OpenAI-Format weiterleitet, ist ein Nachmittag Arbeit. Die Monate stecken in dem, was danach kommt: Übersetzen zwischen Anbieter-APIs, die sich ständig ändern (neue Endpunkte, Reasoning-Parameter, Tool-Formate), korrektes Token-Zählen bei Streams, aktuelle Preistabellen und jeder Sonderfall von Server-Sent Events. Solange das Gateway nicht Ihr Produkt ist, starten Sie mit einem vorhandenen.

Einbau: was sich in Ihrem Code ändert

Weniger als gedacht. Die meisten Gateways sprechen die OpenAI-API, die Änderung in der Anwendung sind also zwei Zeilen: Basis-URL und Schlüssel.

app.py: die einzige Änderung auf Client-Seite

import os

from openai import OpenAI

client = OpenAI(

    base_url="https://llm-gateway.internal/v1", # das Gateway, nicht der Anbieter

    api_key=os.environ["LLM_GATEWAY_KEY"], # ein virtueller Schlüssel für diese App

    max_retries=0, # Retries macht das Gateway, siehe unten

)

reply = client.chat.completions.create(

    model="chat-default", # ein Alias, den das Gateway auflöst

    messages=[{"role": "user", "content": "Fasse dieses Support-Ticket zusammen."}],

)

Der Modellname ist jetzt ein Alias. Welcher Anbieter und welches Modell hinter chat-default stehen und was bei einem Fehler passiert, liegt im Gateway. Im LiteLLM-Proxy sieht das so aus:

config.yaml (LiteLLM-Proxy)

model_list:

  - model_name: chat-default

    litellm_params:

      model: anthropic/claude-sonnet-5-5

      api_key: os.environ/ANTHROPIC_API_KEY

  - model_name: chat-backup

    litellm_params:

      model: openai/gpt-6.1-sol

      api_key: os.environ/OPENAI_API_KEY

litellm_settings:

  num_retries: 2

  fallbacks: [{"chat-default": ["chat-backup"]}]

general_settings:

  master_key: os.environ/LITELLM_MASTER_KEY

Kong, Portkey und die gemanagten Gateways schreiben es anders, die Form ist aber dieselbe: Aliase nach außen, Anbieter und Schlüssel innen. Ein anderes Standardmodell wird zur Konfigurationsänderung statt zum Redeploy aller Dienste.

Eine Einführungsreihenfolge ohne böse Überraschungen:

1. Umleiten und beobachten, nichts ändern. Einen Dienst mit großzügigen Limits und nur aktiviertem Logging auf das Gateway zeigen lassen. Sie bekommen den ersten ehrlichen Kostenbericht und eine Latenz-Baseline.
2. Virtuelle Schlüssel ausgeben, dann die direkten widerrufen. Ein Schlüssel je App oder Team. Ein Anbieterschlüssel, der noch in irgendeiner .env-Datei liegt, macht das Gateway optional, und optionale Kontrollen werden umgangen.
3. Budgets und Limits zuerst nur berichten lassen. Prüfen Sie, wer letzte Woche blockiert worden wäre, bevor Sie jemanden blockieren.
4. Fallback zuletzt, und getestet. Lassen Sie Ihre Evals gegen das Fallback-Modell laufen, bevor es je einen Nutzer bedient. Warum, steht im Abschnitt zum Betrieb weiter unten.

Der Benchmark: was kostet der zusätzliche Hop?

Ein AI Gateway ist ein zusätzlicher Netzwerk-Hop und ein zusätzlicher Prozess bei jedem Modellaufruf, die faire Frage ist also, was das kostet. Anbieterseiten antworten mit einer einzelnen Zahl, gemessen auf eigener Hardware. Ich wollte alle unter denselben Bedingungen.

Der Aufbau. Ein kleiner Go-Server spielt das Modell: Er spricht die OpenAI-Chat-API und antwortet sofort, mit einer 1,4-KB-Antwort oder einem Stream aus 40 Chunks. Weil das Modell keine Zeit braucht, ist jede Millisekunde über einem direkten Aufruf Arbeit des Gateways. Jedes Gateway läuft allein in Docker mit demselben Budget von 2 CPUs und 2 GB , Standardeinstellungen, ohne Caching, ohne Guardrails und ohne Logging-Datenbank. Ein einfacher nginx -Reverse-Proxy setzt die Untergrenze: die Kosten eines zusätzlichen Hops, der nichts tut. Die Last ist open-loop, Anfragen kommen also weiter nach Plan, auch wenn ein Gateway langsamer wird, und eine Anfrage zählt nur, wenn die Antwort vollständig und gültig ist. Chat läuft mit 100, 500, 1.000 und 2.000 Anfragen pro Sekunde, Streaming mit 100 und 500; jedes Szenario läuft 3 Runden zu 20 Sekunden nach einer Aufwärmphase, die Tabellen zeigen die mittlere Runde.

Balken: mittlere Zusatzzeit gegenüber einem direkten Aufruf bei 100 rps. Rechts: die höchste getestete Rate mit nur gültigen Antworten und p99 unter 100 ms.

Die Zusatzlatenz ist bei 100 Anfragen pro Sekunde gemessen; CPU und Speicher sind die Spitzen über alle Szenarien, 200 % heißt, beide CPUs des Budgets waren ausgelastet. Was die Zahlen sagen:

• Der Hop selbst ist billig. Unterhalb ihrer Grenzen fügten nginx, Kong und Portkey einer Chat-Antwort weniger als 2 ms hinzu, LiteLLM etwa 4 ms. Ein gehostetes Modell braucht meist Hunderte Millisekunden bis zum ersten Token, ein Gateway im Normalbetrieb ist daneben ein Rundungsfehler.
• Bei der Kapazität unterscheiden sie sich wirklich. Mit zwei Workern auf zwei CPUs hielt LiteLLM etwa 400 Chat-Anfragen pro Sekunde durch: 100 % gültig und p99 von 51 ms in einem separaten Stufentest. Bei 500 dauerte die mittlere Antwort schon 0,7 s, bei 1.000 kamen nur 60 % der Anfragen durch, und beide CPUs standen die ganze Zeit auf 100 %. Streaming endet früher, bei etwa 100 pro Sekunde : Bei 150 bediente es nur 114 pro Sekunde, und das erste Token kam nach zwei Sekunden. nginx, Kong und Portkey bewältigten jedes Szenario ohne eine einzige ungültige Antwort.
• Der Speicher unterscheidet sich um zwei Größenordnungen. nginx brauchte 10 MiB, Portkey 80 MiB, Kong 300 MiB. LiteLLM mit zwei Workern belegte im Leerlauf 1,5 GiB und blieb unter Last knapp unter der 2-GB-Grenze, ohne beendet zu werden. Geben Sie ihm mehr Speicher als dieser Test.
• Portkey fügt dem ersten gestreamten Token feste 28 ms hinzu. Das hängt nicht von der Last ab: 28 ms bei 100 Streams pro Sekunde, 26 ms bei 500. Um zu prüfen, ob Portkey ganze Streams puffert, habe ich den Mock auf 20 ms und dann 100 ms zwischen den Chunks verlangsamt. Der gesamte Stream dauerte genau so lange wie ein direkter Aufruf, und der erste Chunk kam trotzdem rund 30 ms später. Der Stream wird also so durchgereicht, wie er ankommt, und die Kosten sind eine Konstante beim ersten Chunk. In einem Chatfenster ist das unsichtbar; bei einem Sprachagenten, der mehrere Modellaufrufe verkettet, summiert es sich.
• Kong bleibt am nächsten an der Untergrenze. Etwa eine halbe Millisekunde über reinem nginx, wie man es von Lua innerhalb von nginx erwartet, bei moderatem Speicher. Der Haken ist die Lizenz: Open-Source-Images enden bei 3.9, neue KI-Plugin-Funktionen landen in den kommerziellen Versionen.

Was dieser Test nicht zeigt: die Latenz eines echten Modells, eine Logging-Datenbank, Caching oder Guardrails und alles über 2 CPUs. Eine Datenbank für Schlüssel und Ausgaben-Logs kostet jedes Gateway etwas, und LiteLLM läuft meist mit einer. Alles lief auf einer einzigen Maschine unter Docker, deshalb sind die p99-Werte verrauscht; vergleichen Sie Gateways innerhalb eines Laufs, nicht mit Zahlen aus anderen Benchmarks. Mehr Replikas erhöhen die Kapazität bei jedem Gateway hier. Der Test zeigt, was eine Replika mit festem Budget leistet.

Tipp

Prüfen Sie es selbst in drei Befehlen: git clone https://github.com/LF3551/ai-gateway-benchmark, dann docker compose build und node scripts/bench.mjs && node scripts/report.mjs. Das Repository enthält das Mock-Modell, den Lastgenerator, jede Gateway-Konfiguration und jedes Image per Digest gepinnt. Sie brauchen weder ein Konto bei einem Anbieter noch einen API-Schlüssel. Messungen auf einer Maschine sind eine Plausibilitätsprüfung, keine Rangliste: Vergleichen Sie Gateways innerhalb eines Laufs, nicht mit Zahlen von einer anderen Maschine.

Selbst betreiben oder gemanagt?

Beide Arten erledigen die Kernaufgabe, ob Sie Ihr erstes Gateway wählen oder eine Alternative zu LiteLLM suchen. Der Unterschied: wer Ihren Verkehr sieht, wer den Dienst betreibt und wie Sie bezahlen.

Zwei praktische Hinweise aus dem Bau des Benchmarks. Kong : Die Images kong/kong-gateway ab 3.10 starten ohne Lizenz im Read-only-Modus und beantworteten jede Anfrage mit 426, deshalb nutzt der Benchmark kong:3.9, das letzte Open-Source-Image, in dem das Plugin ai-proxy ohne Lizenz funktioniert. LiteLLM : Der Proxy in 1.106 startet ohne starken Master Key nicht (UnsafeMasterKeyError). Das ist der richtige Standard und ein Grund mehr, den nächsten Abschnitt zu lesen.

Hinweis

Der europäische Blick. Ein gemanagtes Gateway sieht jeden Prompt und jede Antwort, sein Betreiber ist nach DSGVO also Auftragsverarbeiter: Sie brauchen einen Auftragsverarbeitungsvertrag und müssen wissen, wo die Logs liegen und wie lange. Lässt sich das für Ihre Daten schwer beantworten, gehört das Gateway ins eigene Netz, neben die selbst betriebenen Modellserver, vor denen es steht.

Was im Betrieb wehtut

Im Diagramm ist ein Gateway ein sauberer Kasten. Diese Stellen schmerzen, sobald echter Verkehr hindurchläuft.

Streaming

• Pufferung. Jeder Proxy auf dem Weg, der Antworten puffert, macht aus einem Stream einen späten Block, und der Nutzer starrt auf ein leeres Feld. NGINX puffert standardmäßig (proxy_buffering on); schalten Sie das für Streaming-Routen auf jedem Hop ab, nicht nur im Gateway.
• Idle-Timeouts. Reasoning-Modelle denken mitunter eine Minute vor dem ersten Token. Die üblichen 60-Sekunden-Standards, proxy_read_timeout von NGINX oder das Idle-Timeout eines AWS Application Load Balancers, schneiden diese Anfragen ab. Der Client sieht eine abgebrochene Verbindung, wiederholt, und Sie zahlen doppelt.
• Token-Zählung. Beim Streaming im OpenAI-Stil kommt die Nutzung erst im letzten Chunk und nur auf Anfrage (stream_options: {"include_usage": true}). Ein Gateway, das sie nicht anfordert, muss schätzen, und sein Kostenbericht driftet.
• Kein Fallback nach dem ersten Token. Ist ein Chunk beim Client angekommen, kann das Gateway nicht mehr den Anbieter wechseln, ohne eine zweite, andere Antwort zu senden. Fallback deckt Fehler vor dem ersten Chunk ab; danach ist ein abgebrochener Stream ein Retry auf Client-Seite.

Fallback ist nicht gratis

• Ein anderes Modell ist ein anderes Produkt. Anderer Tokenizer, anderes Kontextfenster, andere Eigenheiten beim Tool Calling, bei JSON und bei Ablehnungen. Ein auf ein Modell abgestimmter Prompt kommt vom anderen in anderer Form zurück, und Ihr Parsing bricht im schlechtesten Moment: während eines Ausfalls.
• Reasoning-Zustand wandert nicht mit. Verschlüsseltes Reasoning eines Anbieters kann ein anderer nicht lesen. Die LiteLLM-Dokumentation beschreibt, dass es beim Fallback verworfen wird, das Backup-Modell denkt diesen Schritt also neu. Lange Agentenläufe mit Failover werden langsamer und nehmen eventuell einen anderen Weg.
• Retries multiplizieren sich. Das OpenAI-Python-SDK wiederholt standardmäßig zweimal. Zwei Retries im SDK, zwei im Gateway und zwei im eigenen Code machen aus einem fehlgeschlagenen Aufruf bis zu 27 Versuche gegen einen Anbieter, der Sie ohnehin schon drosselt. Wiederholen Sie in einer Schicht, dem Gateway, und setzen Sie den Client auf null, wie im Beispiel oben.
• Budgets und Zugriffsregeln müssen das Fallback-Ziel abdecken. Eine Anfrage an ein billiges Modell, die auf ein teures ausweicht, wird zum teuren Preis abgerechnet. LiteLLM prüft Budget und Modellzugriff für jedes Fallback-Ziel erneut; egal, was Sie betreiben: Testen Sie, dass ein Schlüssel ohne Zugriff auf ein Modell es nicht über einen Fallback erreicht.

Budgets sind Schätzungen

Ein Gateway weiß erst, was eine Anfrage kostet, wenn die Antwort existiert. Entweder reserviert es den schlimmsten Fall aus max_tokens (sicher, blockiert aber früh) oder rechnet hinterher ab (genau, schießt aber über: Fünfzig parallele Agentenaufrufe bestehen alle die Prüfung, bevor der erste abgerechnet ist). Mit mehreren Gateway-Replikas liegen die Zähler in einem gemeinsamen Speicher wie Redis und haben dieselben Race Conditions wie jeder verteilte Rate Limiter. Behandeln Sie ein Budget als weiche Grenze mit bekanntem Überschuss und alarmieren Sie deutlich vorher.

Caching kann leaken und den billigeren Cache zerstören

• Der Cache-Schlüssel muss alles enthalten, was die Antwort ändert: Modell, System-Prompt, Parameter, Tools und den Mandanten. Ein geteilter semantischer Cache, der den Mandanten ignoriert, kann die Antwort eines Kunden samt dessen Daten an einen anderen Kunden ausliefern.
• Anbieter cachen auch. OpenAI und Anthropic rechnen wiederholte Prompt-Präfixe mit Rabatt ab, aber nur, wenn das Präfix Byte für Byte identisch ist. Ein Gateway, das einen Zeitstempel, eine Request-ID oder nutzerspezifischen Guardrail-Text an den Anfang des Prompts setzt, zerstört dieses Präfix und erhöht still Ihre Rechnung. Alles Dynamische gehört ans Ende.

Das Gateway liegt jetzt auf jedem kritischen Pfad

Läuft aller Modellverkehr darüber, ist ein Ausfall des Gateways ein Ausfall jeder KI-Funktion, die Sie haben. Betreiben Sie mindestens zwei Replikas, halten Sie den Anfragepfad zustandslos und entscheiden Sie je Funktion, was passiert, wenn Datenbank oder Redis weg sind: Logging darf offen ausfallen, Authentifizierung und Budgets sollten geschlossen ausfallen. Platzieren Sie es nah an den Anwendungen, denn jeder Hop zeigt sich in der Zeit bis zum ersten Token.

Agenten multiplizieren alles

Ein Klick in einem Agentenprodukt kann Dutzende Modell- und Tool-Aufrufe bedeuten. Limits pro Anfrage sagen dann wenig; Sie brauchen Budgets und Schrittgrenzen pro Lauf, eine Schleifenerkennung und die Lauf-ID in jeder Logzeile, damit eine einzelne außer Kontrolle geratene Aufgabe als ein Ding sichtbar wird. Viele Gateways stehen inzwischen auch vor MCP-Tool-Aufrufen, dieselbe Idee für Tools: ein Ort, der entscheidet, welcher Agent was aufrufen darf.

Für Logs nehmen Sie ein Format, das Ihr Stack schon versteht. OpenTelemetry definiert GenAI Semantic Conventions (gen_ai.request.model, gen_ai.usage.input_tokens, gen_ai.usage.output_tokens), und Gateways, die sie exportieren, docken an das vorhandene Tracing an. Protokollieren Sie vollständige Prompts und Antworten nicht standardmäßig; warum, zeigt der nächste Abschnitt.

Ein Gateway hält alle Ihre Schlüssel: die Lehre aus LiteLLM 1.107.0

Wer jeden Anbieterschlüssel hinter eine Tür legt, hat auch nur eine Tür, die aufgebrochen werden muss. Am 21. Oktober 2026 enthielten alle sieben Wheels von LiteLLM 1.107.0 auf PyPI zwei zusätzliche Dateien, cook.pth und sitecustomize.py, die Python beim Start jedes Prozesses der Umgebung ausführt. Laut der Analyse von SafeDep und dem Incident Report von LiteLLM sammelte die erste SSH-Schlüssel, Cloud- und Kubernetes-Zugangsdaten, CI-Geheimnisse, Browser-Passwörter, Tokens von KI-Coding-Tools und Umgebungsvariablen, die zweite startete einen Daemon, der stündlich neuen Code holte und ausführte. Für ein Gateway ist dieses Detail das schlimmste: War DATABASE_URL gesetzt, las der Stealer auch die Credential- und Modelltabellen des Proxys aus, also jeden Anbieterschlüssel, den das Gateway gespeichert hatte.

Der Ablauf in UTC: Die Wheels gingen um 11:39–11:40 online, kompromittierte Docker-Images folgten um 11:46 (Tags v1.107.0, latest, main-latest, main-stable), PyPI entfernte das Release bis 13:23, die letzten Docker-Tags waren um 14:20 korrigiert. Sauber sind 1.106.2 und die Release Candidates von 1.107.0. Die Ursache ist der unbequeme Teil für jeden Gateway-Betreiber. Der Angreifer besaß GitHub-CLI-Tokens von drei Entwicklern, und LiteLLM geht davon aus, dass sie aus den Logs einer internen LiteLLM-Instanz stammten, die aus dem Internet erreichbar war : Ein Coding-Agent hatte das Token in einen Response Body geschrieben, und das Gateway protokollierte Response Bodies. Mit diesen Tokens richtete der Angreifer den Release-Workflow auf ein Lookalike-Repository, und die offizielle Pipeline baute, signierte und veröffentlichte das Ergebnis. Eine gültige Signatur half also nicht.

Was daraus folgt, egal welches Gateway Sie betreiben:

• Per Digest pinnen, bewusst aktualisieren. latest und main-stable gehörten zu den vergifteten Tags; das Benchmark-Repository pinnt jedes Image per sha256. Pinnen heißt nicht “nie aktualisieren”: LiteLLM vermutet als Einstieg in die interne Instanz eine kürzlich gepatchte Schwachstelle. Die Checkliste gegen npm-Lieferkettenangriffe gilt für PyPI fast wörtlich.
• Protokollierte Prompts und Antworten sind Geheimnisse. Was durch das Gateway läuft, landet in seinen Logs: von Nutzern eingefügte Tokens, von Agenten zurückgegebene Schlüssel, personenbezogene Daten. Vor dem Speichern schwärzen, kurze Aufbewahrung, wenige Leserechte.
• Die Admin-Seite des Gateways ist das Kronjuwel. Keine Admin-Oberfläche oder -API im Internet, SSO davor und ein Alarm bei jedem neuen Nutzer oder Schlüssel.
• Anbieterschlüssel möglichst nicht in der Datenbank des Gateways. Zur Laufzeit aus einem Secret Manager lesen und rotieren; ein gestohlener Datenbank-Dump ist dann deutlich weniger wert.
• Dem Gateway einen eigenen, engen Netzwerkpfad geben. Es muss die Anbieter erreichen, nicht Ihr ganzes Cloud-Konto oder den Metadatendienst der Instanz.
• Wenn Sie 1.107.0 irgendwo installiert hatten, folgen Sie dem Incident Report und rotieren Sie jeden Schlüssel, den diese Maschine lesen konnte, nicht nur die Anbieterschlüssel.

Fazit

Ein AI Gateway oder LLM Gateway ist keine neue Idee. Es ist das Muster des API Gateways, angewandt auf Verkehr, der pro Token abgerechnet wird, minutenlang streamt und zwischen Anbietern ausweicht. Wenn das zweite Team, der zweite Anbieter oder die erste Compliance-Frage kommt, zahlt es sich aus.

Der Benchmark beziffert die Angst vor dem zusätzlichen Hop: Ein Gateway mit ausreichender Kapazität kostet eine oder wenige Millisekunden, weit weniger, als jedes Modell zum Antworten braucht. Was die Optionen trennt, ist, wie viel Verkehr eine Replika trägt, wie sie streamt, wo sie läuft und wer die Schlüssel hält.

Um es auf Ihrer eigenen Hardware zu messen, startet das Benchmark-Repository alles mit Docker in drei Befehlen.

Ursprünglich veröffentlicht auf alekseialeinikov.com