API-Ratenbegrenzungen und Durchsatz erklärt

Was ein Ratenlimit eigentlich ist

A Tarifbegrenzung ist eine Obergrenze dafür, wie schnell Sie eine API verwenden können. Die Anbieter verlangen sie, um den Dienst fair und stabil zu halten: Ohne sie könnte eine einzige fehlerhafte Schleife oder ein Verkehrsanstieg eines Kunden alle anderen aushungern lassen. Daher schützen Beschränkungen die Kapazität, erzwingen Tarifstufen und dämmen Missbrauch und Denial-of-Service-Angriffe ein. Wenn Sie ein Limit überschreiten, stellt die API für einen Moment ihre Dienste ein und gibt eine zurück HTTP 429 „Zu viele Anfragen“ Antwort, anstatt die Arbeit zu erledigen.

Limits gibt es in einigen gängigen Einheiten, und Sie können jede davon zuerst erreichen:

Bei LLM-APIs sind es die beiden, die am häufigsten beißen U/min Und TPM, und sie sind unabhängig. Fünfzig winzige Klassifizierungsaufrufe können die Drehzahl überschreiten, während sie den TPM kaum berühren; Eine Dokumentzusammenfassung mit 100.000 Token kann TPM in einer einzigen Anfrage sprengen. Entwerfen Sie für die Obergrenze, die Ihr Arbeitspensum zuerst erreicht.

Ein TPM-Limit in „Wie viele Benutzer kann ich bedienen?“ umwandeln.

Kapazitätsplanung ist reine Arithmetik. Beginnen Sie mit den Token eins Der Benutzer verbraucht pro Minute, dann dividieren Sie Ihr Limit durch diesen Wert.

• Token pro Anfrage = Eingabetokens (Eingabeaufforderung + Systemmeldung + Kontext) Plus Ausgabetoken, die das Modell generiert. Beide zählen gegen TPM.
• Anfragen pro Benutzer und Minute = wie gesprächig ein aktiver Benutzer ist.
• Tokens pro Benutzer und Minute = Token pro Anfrage × Anfragen pro Benutzer und Minute.

Beispiel: Jede Chat-Runde verbraucht ~1.500 Eingaben + ~500 Ausgaben = 2.000 Token, und ein aktiver Benutzer sendet ~1,5 Umdrehungen pro Minute → 3.000 Token/Benutzer/Minute. Mit einem 300.000 TPM Grenze, die Sie ungefähr servieren können 300.000 ÷ 3.000 = 100 gleichzeitig aktive Benutzer. Machen Sie die gleiche Division anhand Ihres Drehzahllimits und nehmen Sie das Ergebnis kleiner der beiden Antworten – das ist Ihre tatsächliche Obergrenze. Hinweis „aktiv“ bedeutet aktives Senden; Ein Produkt mit 100 gleichzeitigen Benutzern verfügt normalerweise über Tausende angemeldete Konten.

Stufen: Wenn Sie mehr ausgeben, steigen Ihre Grenzen

Die meisten Anbieter laufen Nutzungsstufen. Neue Konten beginnen mit niedrigen RPM/TPM/RPD; Wenn Sie mehr ausgeben und Ihr Konto älter wird, werden Sie automatisch in höhere Stufen mit weitaus höheren Obergrenzen befördert – manchmal das 10-fache oder 100-fache der Startzahlen. Wenn Sie an Grenzen stoßen, lauten die ersten Fragen: Auf welcher Stufe befinde ich mich und qualifiziere ich mich für die nächste Stufe? Unternehmensvereinbarungen und Vereinbarungen über zugesagte Ausgaben können die Beschränkungen weiter anheben oder dedizierte Kapazitäten hinzufügen.

Techniken, die Ihren effektiven Durchsatz steigern

• Stapeln – Kombinieren Sie viele Elemente in weniger, größeren Anforderungen, um den RPM-Druck zu verringern. Auch die dedizierten Batch-APIs der Anbieter werden für nicht dringende Arbeiten mit einem Rabatt angeboten.
• Streaming – Durch das Zurückstreamen von Token wird Ihr Token-Budget nicht erhöht, aber es verkürzt die wahrgenommene Latenz und gibt Client-Ressourcen schneller frei, sodass überlappende Anfragen schneller bearbeitet werden.
• Backoff und Tempo – Wenn Sie die Anrufe gleichmäßig über die Minute verteilen, anstatt sie alle auf einmal abzufeuern, bleiben Sie unter hohen Grenzwerten, über die Sie sonst stolpern würden.
• Trimmmarken – Kürzere Eingabeaufforderungen, sofortiges Caching und strenge Ausgabelimits erhöhen direkt die Anzahl der Anfragen, die in ein festes TPM-Budget passen.

Lesen Sie die Überschriften, bevor Sie 429 erreichen

Die meisten LLM-Anbieter geben Ihre aktuelle Nutzung weiter jeder Antwort, nicht nur diejenigen, die scheitern. Überschriften wie x-ratelimit-remaining-requests, x-ratelimit-remaining-tokens Und x-ratelimit-reset-requests / -Reset-Tokens Sagen Sie Ihnen genau, wie viel Budget im aktuellen Fenster übrig ist und wann es wieder aufgefüllt wird – bevor Sie jemals eine 429 sehen.

Dadurch wird die Ratenbegrenzung von reaktiv zu proaktiv: Ein Kunde kann sich selbst verlangsamen, sobald die verbleibenden Token unter eine Sicherheitsmarge (z. B. 10–15 % des Limits) fallen, anstatt auf die Ablehnung zu warten und es blind noch einmal zu versuchen. Dies ist vor allem bei stoßartigen Batch-Jobs von Bedeutung, bei denen Sie durch die Überprüfung der Header nach jedem Aufruf sanft drosseln können, anstatt so lange zu feuern, bis die Verbindung unterbrochen wird, und dann im Dunkeln einen Rückzieher zu machen.

Der Nachteil besteht darin, dass Header das widerspiegeln zuletzt Snapshot der Anfrage, kein Live-Zähler – wenn Sie viele Anfragen gleichzeitig auslösen, können mehrere in Bearbeitung sein, bevor eine Antwort zurückkommt, um Sie zu warnen. Header-basierte Drosselung reduziert 429 Sekunden bei konstanter Last; Es ersetzt den Backoff für gleichzeitige Bursts nicht vollständig.

Umgang mit 429-Fehlern: Backoff, Wiederholungsversuche und Warteschlangen

Das Erreichen eines Limits ist normal – die Frage ist, ob Ihre App ordnungsgemäß wiederhergestellt wird. Das Standardmuster ist exponentielles Backoff mit Jitter: Warten Sie bei einem 429 eine kurze Verzögerung und versuchen Sie es dann erneut. Wenn es erneut fehlschlägt, verdoppeln Sie die Verzögerung jedes Mal ungefähr (z. B. 1 Sekunde, 2 Sekunde, 4 Sekunde, 8 Sekunde) und fügen Sie einen kleinen zufälligen Offset hinzu, damit nicht viele Clients es erneut im Gleichschritt versuchen. Respektiere immer a Wiederholen-Nachdem Header, wenn der Anbieter einen sendet – er sagt Ihnen genau, wie lange Sie warten müssen.

Hartes Limit vs. Soft-/Burst-Limit

A harte Grenze ist eine absolute Obergrenze – wenn diese überschritten wird, wird jede Anfrage abgelehnt, bis das Fenster zurückgesetzt wird. A Soft- oder Burst-Limit ermöglicht kurze Spitzen über Ihrer konstanten Rate (häufig über einen Token-Eimer, der sich mit der Zeit wieder auffüllt), sodass kurze Ausbrüche vergehen, aber anhaltende Überlastung immer noch gedrosselt wird. Wenn Sie wissen, womit Sie konfrontiert sind, ändert sich Ihre Strategie: Burst-Limits belohnen die Glättung des Datenverkehrs über das Fenster; Harte Grenzen erfordern eine echte Warteschlange dass die Zähler Anfragen zu einem sicheren Preis abwickeln.

• Stellen Sie nicht dringende Arbeiten in die Warteschlange Es wird also in einem kontrollierten Tempo entleert, anstatt die API zu belasten.
• Last verteilen gleichmäßig, anstatt jede Minute zu platzen.
• Begrenzen Sie die Gesamtzahl der Wiederholungsversuche Eine zum Scheitern verurteilte Anfrage schlägt also sauber fehl, anstatt sich für immer zu wiederholen.

Der Kostenaspekt: ​​begrenzt die Formarchitektur, nicht die Rechnung

Tarifbegrenzungen kosten nicht direkt Geld – Ihnen wird für einen 429 nie etwas in Rechnung gestellt. Sie haben jedoch großen Einfluss darauf, wie Sie bauen und welche Entscheidungen Sie treffen Tun haben einen Preis. Wenn ein einzelner Schlüssel nicht den benötigten Durchsatz liefern kann, greifen Teams häufig zu einem Fallback-Kette (Failover auf ein zweites Modell oder einen zweiten Anbieter, wenn das primäre Modell drosselt), mehrere Schlüssel oder Anbieter Kapazitäten zu bündeln und a Batch-API um nicht dringende Aufträge auf günstigere Strecken mit höherem Limit zu verlagern. Jedes erhöht die Belastbarkeit und Spielraum, bringt aber auch Komplexität bei der Integration und manchmal höhere Preise pro Token beim Fallback mit sich. Der gesündeste Ansatz besteht darin, zuerst Ihre Stufe zu erhöhen und die Token zu kürzen und dann Redundanz nur dann hinzuzufügen, wenn ein hartes Limit Sie wirklich blockiert.

Lernen Sie weiter

Häufig gestellte Fragen

Was ist der Unterschied zwischen RPM und TPM?

RPM (Anfragen pro Minute) begrenzt, wie viele API-Aufrufe Sie pro Minute durchführen können, während TPM (Tokens pro Minute) begrenzt, wie viel Text diese Aufrufe verschieben können. Sie können zuerst eine der beiden Obergrenzen erreichen – viele kleine Aufrufe erschöpfen die RPM, während einige große Kontextaufrufe das TPM erschöpfen.

Wie wandele ich ein TPM-Limit in die Anzahl der Benutzer um, die ich bedienen kann?

Schätzen Sie die Token, die ein Benutzer pro Minute verbraucht (Token pro Anfrage multipliziert mit Anfragen pro Benutzer und Minute, wobei sowohl Eingabe als auch Ausgabe gezählt werden), und dividieren Sie dann Ihr TPM-Limit durch diese Zahl. Wenn ein Benutzer 3.000 Token/Minute benötigt und Ihr Limit 300.000 TPM beträgt, können Sie etwa 100 gleichzeitig aktive Benutzer bedienen.

Wie gehe ich mit dem Fehler 429 Too Many Requests um?

Wiederholen Sie den Versuch mit exponentiellem Backoff und Jitter – warten Sie zwischen den Versuchen immer länger und respektieren Sie alle Retry-After-Header, die der Anbieter zurückgibt. Stellen Sie nicht dringende Arbeiten in die Warteschlange, verteilen Sie die Last gleichmäßig, anstatt sie zu überlasten, und begrenzen Sie die Gesamtzahl der Wiederholungsversuche, damit eine Anfrage schließlich sauber fehlschlägt und nicht ewig in der Schleife bleibt.

Kann ich 429er vermeiden, bevor sie passieren?

Ja – die meisten Anbieter geben bei jeder Antwort Header wie x-ratelimit-remaining-requests und x-ratelimit-remaining-tokens zurück. Wenn Sie diese lesen, können Sie sich selbst drosseln, sobald Sie sich der Obergrenze nähern, anstatt auf eine Ablehnung zu warten, obwohl gleichzeitige Bursts immer noch schneller sein können als der Snapshot einer einzelnen Antwort.