AI Gateways skalieren: Wie man API-Schlüssel bündelt und Rate Limits übersteht

Wenn man Large Language Models (LLMs) zum ersten Mal in sein Produkt integriert, funktioniert alles. Man sendet einen Prompt, man bekommt eine Antwort. Aber wenn die Nutzerbasis wächst, stößt man auf eine harte Wand: Provider-Rate-Limits.

Egal, ob es sich um OpenAI's strenge Tokens-Per-Minute- (TPM-) Limits oder Anthropics Requests-Per-Minute- (RPM-) Beschränkungen handelt, ein einzelner API-Schlüssel wird schnell zum Flaschenhals. Die intuitive Lösung ist es, mehrere API-Schlüssel für exakt dasselbe Modell zu bündeln, um die gesamte Rate-Limit-Kapazität künstlich zu erhöhen.

Ein Pool von Provider-API-Schlüsseln zu verwalten bringt jedoch einen architektonischen Wechsel mit sich. Lass uns erkunden, warum einfache Reverse Proxys nicht ausreichen, wie man API-Key-Pooling tatsächlich implementiert und die generische Architektur, die das sicher macht.

Der Auslöser: Die Rate-Limit-Wand

Die meisten großen LLM-Provider erzwingen doppelte Rate-Limits:

• RPM (Requests Per Minute): Begrenzt das reine Volumen gleichzeitiger Verbindungen.
• TPM (Tokens Per Minute): Begrenzt den tatsächlichen Compute-Throughput (oft eine Mischung aus Input- und Output-Token).

Wenn man eine schnell wachsende KI-Anwendung hat, ist das Erreichen eines 1M-TPM-Limits leicht. Ein paar Power-User, die große Dokumente verarbeiten, können das Kontingent in Sekunden erschöpfen und lassen den Rest der Nutzer auf 429 Too Many Requests-Fehlern starren.

Der logische Schritt, um das zu überwinden, ist es, mehrere API-Schlüssel (oder mehrere Cloud-Deployments, wie mehrere Azure-OpenAI-Endpoints) zu provisionieren und den Traffic lastverteilend über sie zu verteilen. Wenn ein Schlüssel 1M TPM gibt, geben fünf Schlüssel 5M TPM.

Der naive Ansatz: Warum einfache Load Balancer scheitern

Der erste Instinkt könnte sein, Nginx, HAProxy oder einen einfachen AWS ALB vor die Anfragen zu schalten und eine einfache Round-Robin-Routing-Strategie über den Pool von API-Schlüsseln zu konfigurieren.

Das scheitert in Produktion.

iWarning+

Standard-Reverse-Proxys tracken Anfragen, nicht Token.

Im Gegensatz zu traditionellem Web-Traffic, bei dem Anfragen relativ einheitliche Ressourcenkosten haben, variieren LLM-Anfragen. Anfrage A könnte eine einfache Frage stellen, die 50 Token verbraucht. Anfrage B könnte ein massives PDF übergeben, das 100.000 Token verbraucht.

Wenn ein naiver Round-Robin-Balancer diese Anfragen gleichmäßig nach Anzahl verteilt, erschöpft er die Token-Kontingente der zugrunde liegenden Schlüssel ungleichmäßig. Ein API-Schlüssel könnte sein TPM-Limit sofort erreichen, während ein anderer völlig ungenutzt bleibt. Um den Traffic korrekt zu routen, muss der Load Balancer die Payload-Größe verstehen, Token-Anzahlen schätzen und den Zustand darüber pflegen, wie viel Kapazität auf jedem Provider-Schlüssel verbleibt.

Das How-To: Die 3-Schichten-KI-Architektur

Um das tatsächlich zu bauen, muss man die Idee eines einzelnen "smarten Proxys" aufgeben. Produktions-LLM-Infrastruktur teilt die Verantwortlichkeiten auf drei distincte Schichten auf.

1. Die Kontrollebene (Quelle der Wahrheit)

Diese Schicht besitzt den globalen Zustand. Sie speichert die Virtual Keys (Nutzeridentitäten), Nutzer-Budgets, Provider-API-Schlüssel und Live-RPM/TPM-Zähler. Sie wird meist von Postgres (für dauerhaftes Billing/Schlüssel) und Redis (für schnelle Token-Buckets) gestützt.

2. Die Routing-Engine (Entscheider)

Diese Schicht entscheidet, wohin die Anfrage gehen soll. Sie prüft die Kontrollebene, um zu sehen, welche Provider-Schlüssel Restkapazität haben, wertet Fallback-Logik aus und wählt den optimalen Upstream-Provider (z. B. OpenAI-Schlüssel #3 wählen, weil er die meiste TPM verfügbar hat).

3. Das Gateway (Ausführungsschicht)

Das ist die "dumme" Datenebene. Sie empfängt die Payload, hängt den vom Router gewählten physischen API-Schlüssel an, leitet die Anfrage an das LLM weiter, streamt die Server-Sent Events (SSE) an den Client zurück und sendet Nutzung-Logs an die Kontrollebene zurück.

Verteilte Rate-Limits implementieren

Wie verhindert man tatsächlich, dass sich überlappende Anfragen über die Limits hinwegsetzen, wenn man mehrere Gateway-Knoten betreibt? Man muss die Quota-Prüfung mittels pessimistischem Locking über Redis externalisieren.

Wenn eine Anfrage ankommt, fängt die Kontrollebene sie ab, schätzt die Token-Kosten und zieht diese Kosten von einem globalen Redis-Zähler ab, bevor die Anfrage an das Gateway weitergeleitet wird. Wenn der Redis-Zähler Null erreicht, wird die Anfrage sofort blockiert.

Weil Redis Befehle atomar verarbeitet, spielt es keine Rolle, ob man 1 oder 100 Gateway-Knoten hat, die gleichzeitig Anfragen verarbeiten. Zwei gleichzeitige Anfragen können nicht dasselbe 1,00-$-Budget leeren. Die Kontrollebene garantiert, dass die Quota niemals verletzt wird.

Nächste Schritte: Die Implementierung wählen

Man kann dieses 3-Schichten-System komplett von Grund auf bauen, aber die meisten Teams adoptieren Open-Source-AI-Gateways, die Teile (oder alles) dieses Musters implementieren.

Allerdings handhabt nicht jedes Gateway den globalen Zustand gleich. In zukünftigen Beitragen werden wir betrachten, wie diese architektonische Anforderung die Wahl beeinflusst:

• LiteLLM: Bündelt die Kontrollebene (über Redis) und Router/Gateway zusammen, was ihn hochgradig fähig zu verteiltem, Open-Source-Rate-Limiting out-of-the-box macht.
• Bifrost: Agiert als schneller Router/Gateway, trackt Zustand aber pro Knoten. Um ihn sicher zu skalieren, ohne für Enterprise-Clustering zu bezahlen, muss man eine eigene externe Kontrollebene bauen und anhängen.

Für einen tieferen Einblick in die Theorie hinter Demand-Side-Limits vs. Supply-Side-Limits, erkunde unsere Blaupause für das Architekturieren von AI-Gateway-Budgets.