So erstellen Sie einen anbieterneutralen Ratenlimit-Broker für LLM-APIs mit mehreren Modellen

Wenn mehrere Teams mehrere LLM-Anbieter gemeinsam nutzen, ist die Ratenbegrenzung kein Detail mehr bei der Anbieterintegration. Es wird zu einem Shared-Capacity-Problem. Ein Anbieter kann Anfragen und Eingabe-Tokens begrenzen, ein anderer kann Eingabe- und Ausgabe-Tokens trennen und ein dritter kann Quoten auf Projektebene oder über ein rollierendes Ausgabenfenster anwenden. Eine Wiederholungsschleife in jedem SDK kann diese Einschränkungen nicht über Mandanten, Anwendungen, Partnerschlüssel und Modellrouten hinweg koordinieren.

Die praktische Lösung ist ein zentraler Ratenlimit-Broker am Gateway. Der Makler schätzt die Nachfrage, reserviert Kapazitäten vor dem Versand, stellt Arbeiten gemäß den Richtlinien in die Warteschlange oder lehnt sie ab und gleicht die Reservierung nach Abschluss mit der tatsächlichen Nutzung ab. Die Antworten des Anbieters verfeinern dann die Sicht des Brokers auf die verfügbare Kapazität, anstatt unabhängige Wiederholungsstürme auszulösen.

Diese Architektur ist nützlich für jedes Unternehmens-LLM API, das einen vorhersehbaren Durchsatz über interne Teams, Produktionsanwendungen, Automatisierungsagenten oder externe Partner benötigt.

Warum Anbieterratenlimits nicht auf Anfragen pro Minute reduziert werden können

Fakt: Anbieterkontingente verwenden unterschiedliche Dimensionen und Bereiche. Zu den gängigen Dimensionen gehören Anfragen pro Minute, Eingabe-Tokens pro Minute, Ausgabe-Tokens pro Minute, Gesamt-Tokens, Anfragen pro Tag, Parallelität, Ausgabenfenster sowie Beschleunigungs- oder Rampenratenlimits. Derselbe Anbieter kann unterschiedliche Grenzwerte für eine Organisation, ein Projekt, einen Arbeitsbereich, ein Modell oder ein API Produkt festlegen.

In der Anbieterdokumentation werden beispielsweise Kombinationen beschrieben wie:

• Anforderungs- und Token-Limits mit Informationen zur verbleibenden Kapazität und zum Zurücksetzen in Antwortheadern.
• Getrennte Eingabe-Token- und Ausgabe-Token-Grenzwerte für Nachrichten-APIs.
• Kontingente auf Projektebene statt Kontingente, die an einzelne API Schlüssel gebunden sind.
• Tägliche Anfragelimits, die zu einem vom Anbieter festgelegten Zeitpunkt zurückgesetzt werden.
• Rollende, ausgabenbasierte Fenster, die Traffic ablehnen können, selbst wenn Anfrage- und Token-Raten akzeptabel erscheinen.
• Beschleunigungsgrenzen, die auf einen starken Anstieg des Datenverkehrs reagieren, selbst wenn die Dauernutzung unter dem veröffentlichten Kontingent liegt.

Ein Gateway, das nur eine Nummer namens provider RPM speichert, wird möglicherweise in einer Dimension zu viel Datenverkehr zulassen oder in einer anderen Dimension zu wenig Kapazität nutzen. Es kann auch nicht erklärt werden, ob eine Ablehnung auf eine Mandantenrichtlinie, ein Anbieterprojektkontingent, ein Tageslimit oder eine Überlastungsreaktion zurückzuführen ist.

Referenzarchitektur für einen Rate-Limit-Broker

Platzieren Sie den Broker im Anforderungspfad vor dem Provider-Adapter. Jede Anfrage sollte denselben Reservierungsfluss durchlaufen, unabhängig davon, ob sie über einen SDK-, einen internen Dienst, einen Automatisierungsagenten oder einen API-Partnerschlüssel eingegangen ist.

1. Identität normalisieren. Organisation, Mandant, Team, Anwendung, Umgebung, Partner, API Schlüssel, Modellroute und Arbeitslastklasse auflösen.
2. Schätzen Sie den Bedarf. Berechnen Sie die erwarteten Eingabe-Tokens, maximalen Ausgabe-Tokens, geschätzten Ausgaben und etwaige Parallelitätskosten.
3. Richtlinien auswerten. Mandantenbudgets, Warteschlangenfristen, Routenberechtigung, Priorität und Fallback-Regeln prüfen.
4. Kapazität reservieren. Kapazität in den relevanten internen und anbieterseitigen Buckets atomar reservieren.
5. Dispatch. Senden Sie die Anfrage erst, nachdem die Reservierung erfolgreich war.
6. Abgleichen. Ersetzen Sie Schätzungen durch die tatsächliche Nutzung, geben Sie ungenutzte Reservierungen frei und zeichnen Sie Anbieter-Header und Antwortklassifizierung auf.
7. Entscheiden Sie über die nächste Aktion. Geben Sie das Ergebnis zurück, stellen Sie die Arbeit in die Warteschlange, versuchen Sie es zentral erneut, greifen Sie zurück oder lehnen Sie es gemäß dem Workload-Vertrag ab.

Der Reservierungsdienst sollte horizontal skalierbar sein, aber seine Entscheidung muss für jede Anfrage atomar sein. Ein verteilter Zähler, der es zwei Workern ermöglicht, die gleiche verbleibende Kapazität zu beobachten, kann das Provider-429-Problem innerhalb des Gateways reproduzieren.

Verwenden Sie ein kanonisches Quotenmodell, ohne Anbieterunterschiede zu verbergen

Definieren Sie ein kanonisches Modell, das anbieterspezifische Einschränkungen darstellen kann, anstatt jeden Anbieter in eine Abstraktion zu zwingen.

Jedes Limit als Bucket mit Umfang, Kapazität, Nachfüll- oder Rücksetzregel, Einheit und Quelle darstellen. Ein Anbieterprojekt-Bucket kann Anforderungen und Eingabetokens enthalten. Ein Arbeitsbereich-Bucket kann Ausgabetoken enthalten. Eine interne Partnerrichtlinie könnte Parallelität und Ausgabenlimits hinzufügen. Die Zulassungsentscheidung ist nur dann erfolgreich, wenn alle erforderlichen Reservierungen erfolgreich sind.

Behandeln Sie Anbieter-Header nicht als vollständige Quelle der Wahrheit. Verwenden Sie sie, um die Schätzungen des Brokers zu korrigieren, behalten Sie jedoch ein konfiguriertes Modell für Grenzwerte bei, die nicht bei jeder Antwort angezeigt werden. Header-Namen, Verfügbarkeit und Reset-Semantik variieren je nach Anbieter und Route.

Tokens vor dem Versand reservieren und dann abgleichen

Die Token-Reservierung ist der wichtigste Unterschied zwischen einem Broker und einem Wiederholungs-Wrapper. Der Broker benötigt eine Bedarfsschätzung, bevor er die Anfrage sendet.

Schätzen Sie für Eingabetokens anhand der serialisierten Nachrichten, Tooldefinitionen, des strukturierten Ausgabeschemas und des abgerufenen Kontexts. Verwenden Sie für Ausgabetokens das Anforderungsmaximum, sofern verfügbar, oder eine modell- und arbeitslastspezifische Schätzung, wenn der Client keine bereitstellt. Bewahren Sie den Kostenvoranschlag bei der Reservierung auf, damit er später mit der tatsächlichen Nutzung verglichen werden kann.

Ein einfacher Reservierungsdatensatz kann Folgendes enthalten:

• Eine eindeutige Anfrage- und Reservierungs-ID.
• Mandant, Anwendung, API Schlüssel, Route und Arbeitslastklasse.
• Geschätzte Eingabe-Tokens, Ausgabe-Tokens, Gesamt-Tokens und Ausgaben.
• Jeder von der Reservierung berechnete Bucket.
• Erstellungszeit, Ablaufzeit, Warteschlangenfrist und Idempotenzschlüssel.
• Endgültige tatsächliche Nutzung und der während des Abgleichs freigegebene oder berechnete Betrag.

Konservative Schätzungen reduzieren die Antworten des Anbieters 429, können jedoch die Kapazität beeinträchtigen. Messen Sie den Schätzfehler nach Modell, Route, Eingabeaufforderungsfamilie, Kontextlänge und strukturiertem Ausgabemodus. Passen Sie dann die Schätzungen mithilfe begrenzter Korrekturen an, anstatt zuzulassen, dass eine einzelne ungewöhnliche Anfrage das gesamte Modell verzerrt.

Streaming erfordert eine bestimmte Richtlinie. Sie können die maximale Ausgabemenge reservieren und den ungenutzten Teil freigeben, wenn der Stream endet, oder die Ausgabekapazität in kleineren Schritten reservieren, wenn Token eintreffen. Über den ersten Ansatz lässt sich leichter nachdenken; Die zweite kann die Auslastung verbessern, erfordert jedoch eine zuverlässige Abbruch-, Zeitüberschreitungs- und Trennungsbehandlung.

Kontingente hierarchisch durchsetzen

Die Kapazität sollte von der engsten Richtlinie bis zur breitesten gemeinsam genutzten Ressource überprüft werden. Eine typische Hierarchie ist:

1. API Schlüssel oder Dienstidentität.
2. Anwendung und Umgebung.
3. Team- oder Kundenmandant.
4. Partner- oder Reseller-Konto.
5. Anbieter-Arbeitsbereich oder Unterkonto.
6. Anbieterprojekt oder -organisation.
7. Modell und Route.

Eine Anfrage von einer Partneranwendung erfordert daher möglicherweise vier erfolgreiche Reservierungen: die Parallelitätsrichtlinie des Partners, das Token-Budget des Kundenmandanten, die Routenzuweisung des Gateways und das verfügbare Kontingent des Anbieterprojekts. Wenn eine Reservierung fehlschlägt, geben Sie die bereits erworbenen Reservierungen frei und wenden Sie die Entscheidung des fehlgeschlagenen Buckets an.

Verwenden Sie aus Gründen der Fairness eine gewichtete faire Warteschlange oder ein Defizit-Round-Robin, anstatt zuzulassen, dass der zuerst eintreffende Arbeiter den gemeinsam genutzten Pool nutzt. Weisen Sie dem Produktionsverkehr eine höhere Gewichtung und den Hintergrundjobs eine niedrigere Gewichtung zu und bewahren Sie gleichzeitig die Burst-Credits für jeden Mandanten. Eine harte Partitionierung ist einfacher zu erklären, kann jedoch dazu führen, dass Kapazität ungenutzt bleibt, wenn ein Mieter ruhig ist. Die gewichtete Freigabe nutzt die Kapazität im Allgemeinen effizienter, vorausgesetzt, dass laute Mieter begrenzte Burst-Limits haben.

Entwerfen Sie Warteschlangen rund um Arbeitslastverträge

Eine Warteschlange ist nicht automatisch eine Zuverlässigkeitsfunktion. Es kann eine sichtbare 429 in eine unsichtbare zehnminütige Verzögerung verwandeln. Jede Warteschlangenklasse benötigt eine Frist, ein Abbruchverhalten, eine maximale Tiefe und eine Überlastungsaktion.

• Interaktiv: Kurze Frist, kleine Warteschlange, vorhersehbare Ablehnung oder Modellverschlechterung, wenn die Kapazität nicht verfügbar ist.
• Produktionshintergrund: Längere Frist, dauerhafte Warteschlange, Idempotenzschlüssel und kontrolliertes Wiederholungsbudget.
• Partner: Mandantenspezifische Kontingente, veröffentlichte Antwortmetadaten und kein Zugriff auf den Warteschlangenstatus eines anderen Mandanten.
• Batchbar: Verzögerte Ausführung, größere Warteschlange und optionale Weiterleitung an einen Anbieter-Batch API, wenn die Arbeitslast dies zulässt.

Die Aufnahme in die Warteschlange sollte eine klare Entscheidung zurückgeben. Stellen Sie abhängig vom API-Vertrag eine 429- oder eine Gateway-spezifische Überlastungsantwort mit einem Wiederholungswert, einer Warteschlangenkennung und einem Ursachencode bereit. Versprechen Sie keine Fertigstellungszeit, es sei denn, das System kann dieses Versprechen durchsetzen.

Die Stapelverarbeitung kann nicht interaktive Arbeit aus der synchronen Kapazität entfernen, sie ändert jedoch die Ergebniszeit, das Wiederholungsverhalten, den Abbruch und den Abgleich. Behandeln Sie es als separaten Ausführungspfad, anstatt synchrone Anforderungen einfach in eine sehr lange Warteschlange zu stellen. Vergleichen Sie für Hintergrundarbeitslasten die betrieblichen Kompromisse mit AI API-Kostenkontrollrichtlinien und vorhandenen Batch-Vorgängen.

Wiederholungs- und Überlastbehandlung zentralisieren

Fakt: Temporäre Ratenbegrenzungsantworten verwenden üblicherweise HTTP 429, während Anbieterüberlastungsbedingungen möglicherweise 503 oder einen anbieterspezifischen Fehlercode verwenden. Einige Anbieter geben einen Retry-After-Header zurück, und in der Anbieterdokumentation wird empfohlen, ihn zu berücksichtigen, wenn er vorhanden ist. Eine schnelle Verkehrsrampe kann auch zu Beschleunigungs- oder Verlangsamungsverhalten führen, ohne dass es zu einer normalen Eimererschöpfung kommt.

Empfehlung: Behandeln Sie „Retry-After“ als Untergrenze und nicht als optionalen Vorschlag. Halten Sie den betroffenen Anbieterbereich bis zu diesem Zeitpunkt an, fügen Sie begrenzten Jitter hinzu, um synchronisierte Aktivierungen zu verhindern, und lassen Sie den Broker entscheiden, welche Anfragen in der Warteschlange die wiederhergestellte Kapazität nutzen können.

Wenn Retry-After fehlt oder ungültig ist, verwenden Sie einen begrenzten exponentiellen Backoff mit Jitter. Behalten Sie das Wiederholungsbudget im Broker bei, nicht separat in jedem SDK- und Provider-Adapter. Andernfalls kann eine logische Anfrage einen Gateway-Wiederholungsversuch, einen SDK-Wiederholungsversuch, einen HTTP-Client-Wiederholungsversuch und eine anbieterseitige Wiederholung erzeugen.

Fehler vor erneutem Versuch klassifizieren:

• Wiederholbare Kapazität: Temporäre 429 oder dokumentierte vorübergehende Kontingentantwort.
• Wiederholbare Überlastung: Temporäres 503- oder gleichwertiges Anbieter-Überlastungssignal.
• Nicht wiederholbarer Richtlinienfehler: Tageskontingent, Ausgabenobergrenze, deaktiviertes Projekt oder Mandantenlimit.
• Nicht wiederholbarer Anforderungsfehler: Ungültiges Schema, nicht unterstützter Parameter, Authentifizierungsfehler oder fehlerhafte Eingabe.
• Fristfehler: Eine Anfrage, deren verbleibende Benutzer- oder Workflow-Frist kürzer ist als der nächste sichere Versuch.

Fallback ist eine separate Entscheidung. Ein anderer Anbieter kann ein anderes Ausgabeverhalten, andere Preise, Latenz, Residenz oder Kontextbeschränkungen haben. Verwenden Sie Fallback nur, wenn die Routenrichtlinie bestätigt, dass der Arbeitslastvertrag diese Unterschiede tolerieren kann.

Entscheidungen offenlegen und Sättigung messen

Teams können die Drosselung nicht beheben, wenn das Gateway nur einen generischen 429 zurückgibt. Geben Sie sichere Metadaten zurück, wie etwa das anwendbare Limit, die verbleibende Kapazität, die Rücksetzzeit, die Warteschlangenentscheidung, die Arbeitslastklasse und den Ablehnungsgrund. Vermeiden Sie es, die Nutzung oder die rohen Anbieteranmeldeinformationen eines anderen Mandanten preiszugeben.

Überwachen Sie mindestens Folgendes:

• Reservierungserfolg und Ablehnungsrate nach Mieter, Route und Bucket.
• Warteschlangentiefe, Warteschlangenwartezeit, Fristablauf und Stornierungen.
• Anbieter-429- und 503-Raten, Wiederholungshäufigkeit und Ablehnungen mit steigender Rate.
• Geschätzte versus tatsächliche Token-Nutzung und durch Überreservierung verschwendete Kapazität.
• Gleichzeitigkeitssättigung und der Anteil der von jedem Mandanten verbrauchten Kapazität.
• Wiederholungsversuche pro logischer Anfrage und Fallback-Häufigkeit.
• Tageskontingent und Spielraum im Ausgabenfenster.

Auslastungstests sollten Burst-Traffic, Long-Context-Anfragen, maximale Ausgabeanfragen, Streaming-Trennungen, tägliche Kontingentausschöpfung, Anbieter-429- und 503-Antworten und einen lauten Mandanten umfassen, der mit dem Produktionsverkehr konkurriert. Validieren Sie nicht nur, ob Anfragen schließlich abgeschlossen werden, sondern auch, ob Warteschlangenfristen, Fairness und Wiederholungsbudgets intakt bleiben.

Implementierungs-Checkliste

• Definieren Sie kanonische Dimensionen, ohne anbieterspezifische Beschränkungen zu verwerfen.
• Weisen Sie jeder Anfrage einen normalisierten Mandanten, eine Route, eine Arbeitslastklasse und einen Idempotenzschlüssel zu.
• Schätzen und reservieren Sie Eingaben, Ausgaben, Gesamttokens, Ausgaben, Anfragen und Parallelität vor dem Versand.
• Machen Sie Multi-Bucket-Reservierungen atomar und verfallen Sie aufgegebene Reservierungen sicher.
• Gleichen Sie nach jedem Versuch die tatsächliche Anbieternutzung und die Antwortheader ab.
• Verwenden Sie gewichtete Fairness, Burst-Credits und explizite Prioritätsklassen.
• Geben Sie jeder Warteschlange eine Frist, eine maximale Tiefe und eine Überlastungsaktion.
• Wiederholungen zentralisieren und die Retry-After-Werte des Anbieters berücksichtigen.
• Trennen Sie temporäre Kapazitätsfehler von permanenten Richtlinien- und Anforderungsfehlern.
• Veröffentlichen Sie Drosselungsmetadaten und überwachen Sie die Sättigung nach Mandant und Route.
• Testen Sie die Ausschöpfung der Anbieterkontingente, Rampenlimits, Streaming, Fallback und das Verhalten lauter Nachbarn.

Schlussfolgerung

Ein Multi-Modell-Gateway sollte das Anbieterkontingent als gemeinsam genutzte Infrastrukturkapazität verwalten, nicht als Sammlung unabhängiger SDK Einstellungen. Ein anbieterneutraler Ratenlimit-Broker bietet Plattformteams einen Zugangspfad, eine Fairness-Richtlinie, ein Wiederholungsbudget und einen Ort, an dem sie Schätzungen mit der Realität in Einklang bringen können.

Das Design erfordert mehr als einen generischen Token-Bucket. Es muss Anforderungen, Eingabe- und Ausgabetokens, Tageskontingente, Ausgabenfenster, Parallelität, Anbieterumfang und Rampenrate darstellen. Sobald diese Dimensionen explizit sind, kann das Gateway vorhersehbare Entscheidungen treffen: Jetzt versenden, mit einer Frist in die Warteschlange stellen, Arbeit abgeben, zentral erneut versuchen oder einen vertragssicheren Fallback verwenden. Auf diese Weise wird die Durchsatzkontrolle zu einer betrieblichen Funktion und nicht zu einer wiederkehrenden Quelle für Produktionsvorfälle der Serien 429 und 503.

Verwandte Lektüre

• Stapelverarbeitung für nicht interaktive LLM-Arbeitslasten