Rate-Limit-bewusste KI-API-Gateways: Gestalten Sie RPM, TPM, Bursts und Mandantengerechtigkeit, bevor 429s erreicht werden

Eine 429 von einem LLM-Anbieter ist nicht nur ein Wiederholungssignal. In der Produktion ist es oft ein Beweis dafür, dass Ihre Anwendung bereits die Kontrolle über Zulassung, Mietergerechtigkeit, Latenz oder anbieterspezifische Quotenabrechnung verloren hat.

Die gemeinsame Lösung – der exponentielle Backoff – ist notwendig, aber unvollständig. Backoff reagiert, nachdem der Provider Datenverkehr ablehnt. Ein ratenlimitbewusstes KI-API-Gateway sollte den Datenverkehr steuern, bevor Anfragen Ihr System verlassen: Token-Druck schätzen, Kontingent reservieren, Mandanten isolieren, die richtige Arbeit in die Warteschlange stellen, die falsche Arbeit ablehnen und sich anpassen, wenn sich die Anbieterlimits ändern.

Dieser Artikel beschreibt einen praktischen Gateway-Kontingentregler für Teams, die Produktions-Workloads über eine einheitliche API an mehrere LLM-Anbieter senden.

Das Leserproblem: 429er sind mehrdimensional

Viele Teams behandeln Ratenlimits so, als wären sie eine einzelne Anzahl von Anfragen pro Minute. Diese Annahme widerlegt sich bei LLM-APIs schnell.

Fakten aus der aktuellen Anbieterdokumentation:

• OpenAI dokumentiert, dass Grenzwerte über kürzere Zeitfenster als das angekündigte Minutenlimit durchgesetzt werden können, sodass kurze Bursts fehlschlagen können, selbst wenn die durchschnittliche Minute sicher erscheint.
• Das Azure OpenAI-Kontingent wird nach Abonnement, Region, Modell und Bereitstellungstyp in Token pro Minute zugewiesen. Durch die Zuweisung von TPM zu einer Bereitstellung werden auch erzwungene Inferenz-RPM-Grenzwerte bestimmt, und die RPM-zu-TPM-Verhältnisse variieren je nach Modell.
• Azure OpenAI weist außerdem darauf hin, dass die Berechnungen der Ratenbegrenzungstoken bei Eingang der Anfrage geschätzt werden und nicht mit den endgültigen Abrechnungstokenzahlen identisch sind.
• Anthropic dokumentiert die Grenzwerte für Anfragen pro Minute, Eingabe-Tokens pro Minute und Ausgabe-Tokens pro Minute. Das Überschreiten der Grenzwerte gibt eine 429 mit einem Retry-After-Header zurück.
• Anthropic warnt davor, dass ein starker Anstieg des Verkehrs an Beschleunigungsgrenzen stoßen kann, und empfiehlt eine schrittweise Steigerung.
• Bei den meisten Claude-Modellen zählen Anthropic-Dokumente, die Eingabe-Tokens im Cache lesen, nicht zu den Eingabe-Token-pro-Minute-Grenzwerten, was bedeutet, dass das sofortige Caching den effektiven Headroom verändern kann.
• Die Ratenbegrenzungen für die Google Gemini API sind an Projektnutzungsstufen gebunden, wobei höhere Stufen von der Abrechnungseinrichtung, den kumulierten Ausgaben und der verstrichenen Zeit nach Zahlungsmeilensteinen abhängen.

Die operative Lektion ist klar: Eine OpenAI-kompatible Anforderungsform impliziert kein OpenAI-kompatibles Quotenverhalten. Ein Multi-Provider-Gateway benötigt ein internes Kontingentmodell, das umfangreicher ist als „Wiederholen, wenn 429“.

Designziel: Einlasskontrolle zu einer Gateway-Verantwortung machen

Ein Gateway, das Ratenlimits erkennt, sollte fünf Fragen beantworten, bevor es eine Anfrage sendet:

1. Welcher Anbieter, welches Modell, welche Bereitstellung, welche Region, welches Projekt oder welcher Arbeitsbereich erhält die Anfrage?
2. Wie viel Anforderungs-, Eingabe-Token-, Ausgabe-Token- und Parallelitätskapazität könnte es verbrauchen?
3. Welcher Mandant, welches Team, welcher API-Schlüssel, welcher Kunde oder welche Workload-Klasse soll auf die gemeinsam genutzte Kapazität angerechnet werden?
4. Soll die Anfrage jetzt zugelassen, kurz in die Warteschlange gestellt, herabgestuft, an eine andere Stelle weitergeleitet oder abgelehnt werden?
5. Wie soll die Reservierung abgeglichen werden, nachdem der Anbieter die tatsächliche Nutzung gemeldet hat?

Das Gateway wird zum Quotenregler. Es ersetzt keine Anbieterlimits. Dadurch werden Anbietergrenzen in Ihrem eigenen System sichtbar, vorhersehbar und fair.

Erstellen Sie ein normalisiertes Quotenmodell

Beginnen Sie mit der Definition interner Begrenzungsdimensionen, die die wichtigsten Anbieter darstellen können, ohne sie in eine irreführende Kategorie zu zwingen.

Empfohlene Begrenzerabmessungen

• RPM: Anfragen pro Minute.
• Eingabe-TPM: Eingabeaufforderungs-, Nachrichten-, Tool- und Kontexttokens pro Minute.
• Ausgabe-TPM: Abschlusstokens pro Minute, separat für Streaming und lange Generationen reserviert.
• Gesamt-TPM: nützlich für Anbieter oder Bereitstellungen, die einem kombinierten Token-Druck ausgesetzt sind.
• Gleichzeitigkeit: aktive Anfragen, aktive Streams oder laufende Jobs.
• Streaming-Dauer: Langlebige Streams können Verbindungs- und Ausgabetoken-Headroom belegen, selbst wenn die Drehzahl niedrig ist.
• Anbieterspezifischer Bereich: Azure-Abonnement/-Region/-Bereitstellung, Anthropic-Arbeitsbereich/-Modellklasse, Google-Projekt/-Stufe oder OpenAI-Organisation/-Projekt/-Modellgruppe.

Anbieterspezifische Dimensionen nicht ausblenden. Normalisieren Sie sie in ein gemeinsames Schema, bewahren Sie jedoch genügend Details auf, um eine spätere Ablehnung zu erklären.

{
  „provider“: „provider_a“,
  „model_profile“: „Fast-Chat“,
  "provider_scope": {
    „Projekt“: „Produkt“,
    „region“: „us-ost“,
    „deployment“: „chat-large-01“
  },
  "Grenzen": {
    „U/min“: 1200,
    „input_tpm“: 800000,
    „output_tpm“: 250000,
    „Parallelität“: 200
  }

Dieses interne Objekt sollte explizit konfiguriert werden und nicht allein aus Modellnamen abgeleitet werden. Anbieter-Dashboards, Kontostufen, regionale Bereitstellungen und Arbeitsbereichseinstellungen können alle die effektive Kapazität derselben Modellfamilie ändern.

Schätzen Sie den Token-Druck vor dem Versand

Eine anbieterseitige Tarifbegrenzung erfolgt häufig, bevor die endgültige Abrechnungsnutzung bekannt ist. Ihr Gateway sollte die gleiche konservative Schätzung vornehmen, bevor es Datenverkehr sendet.

Preflight-Reservierungseingaben

• Serialisierte Eingabeaufforderung und Nachrichtenlänge.
• Modellspezifische Tokenisierung und Overhead für Rollen, Tools, Bilder oder strukturierte Ausgabeanweisungen.
• max_completion_tokens oder gleichwertige Ausgabeobergrenze.
• Historisches Abschlussverhältnis für diesen Endpunkt, Mandanten, Modellprofil und Anforderungsklasse.
• Erwartete Cache-Lese-Tokens, wenn Prompt-Caching verfügbar und messbar ist.
• Streaming-Flag und erwartete Stream-Dauer.

Eine einfache Reservierungsregel reicht oft aus, um zu beginnen:

estimated_input_tokens = tokenize(request_messages) + model_overhead
geschätzte_output_tokens = min(
  max_completion_tokens,
  p95_historical_output_tokens_for_route
)
reservierte_total_tokens = geschätzte_input_tokens + geschätzte_output_tokens

Verwenden Sie für unbekannte Routen einen konservativen Standard. Für stabile Produktionswege aktualisieren Sie die Schätzungen kontinuierlich anhand der tatsächlichen Nutzung.

Reservieren und dann abgleichen

Kontingentreservierungen sollten nicht zu dauerhaften Gebühren werden. Behandeln Sie sie wie Holds:

1. Zitat: Eingangs- und Ausgangsdruck schätzen.
2. Reservieren: vor dem Versand von den entsprechenden Token-Buckets abziehen.
3. Abrechnen: Ersetzen Sie die Schätzung durch die vom Anbieter gemeldete Nutzung, sofern verfügbar.
4. Rückerstattung oder Abbuchung: ungenutzte reservierte Kapazität zurückgeben oder Überschreitungen bei Bedarf dem nächsten Fenster in Rechnung stellen.

Dies ist am wichtigsten für Long-Context- und Streaming-Anrufe. Wenn Sie vor dem Versand nur das Eingabe-TPM überprüfen, kann ein Stream erfolgreich gestartet werden und später auf den Ausgabe-Token-Druck stoßen. Durch die separate Reservierung des Ausgangs-Headrooms werden Ausfälle in der Mitte des Stroms und das Risiko eines Strömungsabrisses verringert.

Verwenden Sie hierarchische Token-Buckets für Mietergerechtigkeit

Ein einzelner globaler Begrenzer schützt das Anbieterkonto, aber nicht die Mandanten voreinander. Ein Batch-Job mit langem Kontext kann gemeinsam genutztes TPM verbrauchen und dazu führen, dass interaktive Anfragen von anderen Teams fehlschlagen.

Verwenden Sie hierarchische Token-Buckets:

Organisation
  └── Mieter
      └── Team
          └── api_key
              └── model_profile
                  └──provider_deployment

Eine Anfrage muss jeden relevanten Bucket passieren. Dadurch können Sie mehrere Richtlinien gleichzeitig durchsetzen:

• Die Organisation darf die Anbieterkapazität nicht überschreiten.
• Ein Mieter kann nicht mehr als seinen vertraglich vereinbarten Anteil verbrauchen.
• Ein API-Schlüssel darf sein vorgesehenes Umgebungs- oder Anwendungslimit nicht überschreiten.
• Ein Batch-Modellprofil kann ein interaktives Modellprofil nicht blockieren.
• Eine Anbieterbereitstellung kann nicht überlastet werden, selbst wenn eine andere Bereitstellung über ein freies Kontingent verfügt.

Gerechtes Teilen versus Nutzen

Empfehlung: Verwenden Sie eine gewichtete faire Aufteilung mit kontrollierter Burst-Kreditaufnahme.

Strikte Obergrenzen pro Mandant sind leicht zu erklären, können aber dazu führen, dass ungenutzte Kapazitäten verloren gehen. Burst Borrowing verbessert die Auslastung, indem es einem Mieter ermöglicht, vorübergehend Leerlaufkontingente aus einem gemeinsam genutzten Pool zu nutzen. Der Kompromiss liegt in der Komplexität: Dashboards müssen zeigen, was garantiert wurde, was geliehen wurde und wann die Kreditaufnahme widerrufen wurde.

Eine praktische Regel:

• Geben Sie jedem Mieter eine garantierte Basislinie.
• Burst-Ausleihen von ungenutzter gemeinsamer Kapazität zulassen.
• Geliehene Kapazität zurückgewinnen, wenn Datenverkehr mit höherer Priorität oder garantierter Datenverkehr auftritt.
• Lassen Sie niemals zu, dass geliehener Datenverkehr 429-Fehler auf Anbieterebene für garantierten Datenverkehr erzeugt.

Trennen Sie Traffic-Klassen, bevor sie miteinander konkurrieren

Nicht alle Anfragen verdienen das gleiche Warteschlangenverhalten. Leiten Sie den Datenverkehr in Modellprofile mit separaten Warteschlangen und Kontingentpools ein.

{
  „Fehler“: {
    „type“: „rate_limited“,
    „limiter“: „output_tpm“,
    „provider“: „provider_a“,
    „model_profile“: „Fast-Chat“,
    „provider_model“: „model-x“,
    „retry_after_ms“: 2400,
    „tenant_id“: „tenant_123“,
    „api_key_id“: „key_456“,
    „request_class“: „interaktiv“,
    „estimated_input_tokens“: 4200,
    „estimated_output_tokens“: 800,
    „gateway_decision“: „admitted_then_provider_rejected“,
    „fallback_allowed“: false,
    „trace_id“: „trace_abc“
  }