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.

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.

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.