AI-Gateway-Budgets architerieren: Virtual Keys, Provider Keys und verteilte Quota-Erzwingung

Wie wir bei der Diskussion der Herausforderungen beim Pooling von API-Schlüsseln festgestellt haben, ist das Routing von Anfragen nur die halbe Miete, wenn man ein AI Gateway als primäre Schnittstelle zwischen seinen Nutzern und Upstream-LLMs aufbaut. Die deutlich schwierigere Aufgabe ist das Design eines Budgetsystems auf Produktionsebene.

Wer sein Quotasystem nicht richtig entwirft, riskiert, dass ein plötzlicher Anstieg gleichzeitiger Anfragen die Limits umgeht, die Upstream-API-Konten leerrechnet und flächendeckende 429 Too Many Requests-Ausfälle für alle Kunden verursacht.

In diesem letzten Beitrag gehen wir eine Blaupause für die Architektur einer verteilten KI-Quota-Engine durch.

Die architektonische Trennung: Ausführung vs. Wahrheit

Der häufigste Fehler beim Aufbau eines AI Gateways ist es, den Proxy selbst als Quelle der Wahrheit zu behandeln.

Eine Produktionsarchitektur muss Anfrageausführung von Budgetwahrheit trennen. Das Gateway kann Header parsen, Streaming Server-Sent Events (SSE) verwalten und Timeouts handhaben. Aber ein dediziertes Budgetmodul (oder ein Microservice) muss die autoritative Sicht auf Nutzerbudgets, Zähler und Ausgaben besitzen.

Demand-Side- vs. Supply-Side-Limits

Ein AI Gateway in Produktion funktioniert wie ein zweiseitiger Marktplatz. Eine Anfrage ist nur gültig, wenn sie die Prüfungen auf beiden Seiten besteht.

1. Demand-Side-Limits (der Nutzer)

Das sind die Beschränkungen für die Entität, die die Anfrage stellt.

• Identität: Wer ist das? (Abgebildet über einen Virtual Key)
• Erlaubte Modelle: Darf der Nutzer gpt-4o verwenden oder nur gpt-3.5-turbo?
• Maximale Ausgaben: Hat dieses Team sein monatliches Limit von 500 $ überschritten?
• Rate Limits: Überschreitet der Nutzer seine zugewiesenen 50 Requests Per Minute (RPM)?

2. Supply-Side-Limits (der Provider)

Das sind die Beschränkungen der tatsächlichen Upstream-Infrastruktur.

• Provider Keys: Welche OpenAI-/Anthropic-Schlüssel sind verfügbar?
• Kapazität: Hat sk-key-1 genug Tokens Per Minute (TPM) übrig, um diesen Prompt zu bedienen?
• Cooldowns: Ist dieser spezifische Schlüssel gerade durch einen Provider-429 gesperrt?

Virtual Keys sind die Budgetgrenze

Ein Virtual Key ist nicht nur ein Authentifizierungstoken; er ist die grundlegende Budgetgrenze.

In einem Multi-Tenant-System repräsentiert der Virtual Key Identität, Modellzugriff und Ausgabenzurechnung gleichzeitig. Das zeigt genau, warum Architekturen, die den Zustand von Virtual Keys über mehrere Knoten hinweg nicht synchronisieren (wie die Open-Source-Bifrost-Deployments, die wir zuvor analysiert haben), fehlerhaft sind. Wenn der Zustand der Virtual Keys nicht global konsistent ist, existiert die Budgetgrenze unter Last schlicht nicht.

Der Anfragefluss eines Budgetmoduls

Um diese Beschränkungen sicher zu orchestrieren, muss das Budgetmodul eine spezifische Folge von Operationen ausführen:

1. Virtual Key auflösen: Nutzer, Team oder Kundenpolitik identifizieren.
2. Modellzugriff prüfen: Sicherstellen, dass das angefragte Modell für diesen Virtual Key erlaubt ist.
3. Demand-Side-Quota prüfen: Redis/Postgres abfragen, um sicherzustellen, dass der Nutzer genug RPM/TPM und monetäres Budget hat.
4. Kandidatenauswahl: Das Routing-Layer nach verfügbaren Provider Keys fragen.
5. Supply-Side-Quota prüfen: Sicherstellen, dass der gewählte Provider Key Kapazität hat.
6. Quota reservieren: Die geschätzten Kosten atomar reservieren, bevor die Anfrage weitergeleitet wird.
7. Ausführen: Die Anfrage an den LLM-Provider proxyen.
8. Abrechnen: Die tatsächlichen verwendeten Token aus den Response-Headern des Providers berechnen und die finalen Kosten aktualisieren.
9. Persistieren: Das dauerhafte Ausgabenkonto in Postgres schreiben.

Warum Reservierung unter Nebenläufigkeit wichtig ist

Schritt 6 (Reservierung) ist der Dreh- und Angelpunkt des gesamten Systems.

Stellen wir uns vor, Nutzer X hat noch 1,00 $ in seinem Budget. Er startet ein Skript, das 100 gleichzeitige Anfragen an das Gateway feuert.

Wenn das Gateway einen "read-only"-Budgetcheck verwendet, werden alle 100 Anfragen in exakt derselben Millisekunde die Datenbank abfragen. Alle 100 Anfragen sehen "1,00 $ übrig" und lassen die Anfrage zu. Ein paar Sekunden später antwortet das LLM, die Kosten werden abgerechnet, und Nutzer X hat 10,00 $ Compute verbraucht und sein Hard-Limit um das Zehnfache überschritten.

iWarning+

Um das zu verhindern, braucht das System atomare Reservierung. Wenn eine Anfrage ankommt, muss das Gateway sofort die geschätzten Kosten der Anfrage (z. B. input_tokens + max_tokens) vom Hot-Counter in Redis abziehen.

Wenn die Reservierung das Budget unter Null drückt, wird die Anfrage blockiert. Sobald die Anfrage fertig ist, erstattet das Gateway nicht verbrauchte Token dem Redis-Counter zurück. Indem man den Budgetcheck und die Abzug-Operation atomar innerhalb von Redis ausführt, beseitigt man die Race-Condition komplett.

Hard Limits, Soft Caps und Abrechnung

Die Erzwingung dieser Limits erfordert unterschiedliche Strategien je nach Metrik:

• Hard-RPM (Requests Per Minute): Das ist direkt. Man inkrementiert atomar einen Redis-Zähler vor dem Routing. Wenn er das Limit überschreitet, wird die Anfrage blockiert.
• Hard-TPM (Tokens Per Minute): Man muss geschätzte Token vor dem Routing reservieren. Da LLM-Output-Token unvorhersehbar sind, nutzt man den max_tokens-Parameter als Worst-Case-Reservierung.
• Soft Budgets (Gesamtausgaben): Vercels AI-Gateway-Dokumentation beschreibt API-Key-Budgets explizit als Soft Caps, die zu Beginn einer Anfrage geprüft werden. Man lässt die "überschreitende Anfrage" (diejenige, die einen Nutzer von 49,95 $ auf 50,10 $ bringt) durchlaufen, blockiert aber sofort alle zukünftigen Anfragen während der Abrechnungsphase.

Die Rolle von Redis und Postgres

Ein robustes Budgetmodul teilt die Verantwortungen zwischen flüchtigen und dauerhaften Datenspeichern auf.

Redis besitzt den Hot Path:

• Live-RPM/TPM-Token-Buckets.
• Atomare Reservierungen für laufende Anfragen.
• Zähler für maximale parallele Anfragen.
• Kurzlebige Provider-Cooldown-Locks.

Postgres besitzt den dauerhaften Pfad:

• Die autoritative Liste von Virtual Keys, Nutzern und Teams.
• Budgetdefinitionen und Billing-Policen.
• Das unveränderliche Ausgabenkonto und die Abstimmungsdatensätze.

Abschließende These

Ein AI Gateway in Produktion ist im Kern eine zweiseitig verteilte Quota-Engine. Virtual Keys repräsentieren die Demand-Side-Identität und Budgeterzwingung, während Provider Keys die Upstream-Kapazität repräsentieren.

Indem man Tools nutzt, die dauerhaften und flüchtigen Zustand trennen, wie LiteLLM, um Live-Reservierungen über Redis zu koordinieren und dauerhafte Ausgaben über Postgres aufzuzeichnen, kann man seine KI-Infrastruktur skalieren, um hohe Nebenläufigkeit zu bewältigen, ohne die API-Konten zu belasten. Jede Gateway-Architektur, die diesen Zustand nicht über ihre Knoten hinweg synchronisieren kann, wie wir im Vergleich von LiteLLM vs. Bifrost gesehen haben, ist für die Produktion nicht sicher.