Rate Limits auf Shared Models
Bei Shared Models dient STACKIT AI Model Serving dazu, compute-intense AI workloads über eine shared API bereitzustellen. Um sicherzustellen, dass die Ressourcen allen Kunden zur Verfügung stehen, wendet STACKIT Rate Limits auf Shared Models an.
Zweck von Rate-Limits
Abschnitt betitelt „Zweck von Rate-Limits“Die Hauptziele von Rate Limits im STACKIT AI Model Serving sind:
- Sicherstellung der Fair Use-Policy der shared Resources unter allen Benutzern.
- Schutz des Service vor Misuse und potenziellem Abuse.
Wie Rate Limits auf Shared Models angewendet werden
Abschnitt betitelt „Wie Rate Limits auf Shared Models angewendet werden“Im STACKIT AI Model Serving wenden wir Rate Limits auf Shared Models wie folgt an:
- Zwei Dimensionen: STACKIT setzt Rate Limits basierend auf zwei dimensions durch
- Requests pro Minute (RPM)
- Tokens pro Minute (TPM)
- Per-Projekt-Basis: Rate Limits werden über alle STACKIT AI Model Serving authentication tokens, die einem single STACKIT project zugeordnet sind, aggregiert.
- Modellspezifische Limits: Rate Limits variieren je nach dem specific model, das verwendet wird. Details dazu sind in Getting Started with Shared Models verfügbar.
Berechnung der TPM-Limits
Abschnitt betitelt „Berechnung der TPM-Limits“Für Tokens Per Minute (TPM) Limits basiert die computation auf der total number of tokens used, wobei sowohl prompt tokens als auch generation tokens berücksichtigt werden (für embedding models werden nur prompt tokens verwendet). Das TPM Limit wird berechnet, indem die prompt tokens zu den generation tokens addiert werden, wobei generation tokens mit einem factor of 5 gewichtet werden. Dies bedeutet, dass generation tokens als 5-mal die number of prompt tokens gezählt werden:
TPM = (prompt tokens + 5 * generation tokens) / minuteBurst Capacity und Erzwingung des Rate Limit
Abschnitt betitelt „Burst Capacity und Erzwingung des Rate Limit“STACKIT bietet auch eine slight burst capacity, um short-term spikes in traffic zu berücksichtigen. Dies bedeutet, dass die Rate Limits für eine very short time leicht exceeded werden können, was eine brief increase in usage über die standard limits hinaus ermöglicht. Allerdings wird sustained usage oberhalb der Limits weiterhin enforced, und requests können rejected oder throttled werden, um abuse zu verhindern.
Response Header für Rate-Limit-Information
Abschnitt betitelt „Response Header für Rate-Limit-Information“Wenn Sie eine request an das STACKIT AI Model Serving senden, enthält die response Header, die useful information über die remaining capacity und den Rate Limit Status bereitstellen. Sie können diese Header verwenden, um efficient retry mechanisms zu implementieren und die usage Ihrer Anwendung des Service zu optimieren.
Jede Antwort enthält Rate-Limit-Header:
x-ratelimit-limit-requests: Das RPM-Limit Ihres Projekts.x-ratelimit-limit-tokens: Das TPM-Limit Ihres Projekts.x-ratelimit-remaining-requests: Die Anzahl verbleibender Anfragen, bis das Rate-Limit greift.x-ratelimit-remaining-tokens: Die Anzahl an verbleibender Tokens, bis das Rate-Limit greift.x-ratelimit-reset-requests: Die verbleibende Zeit, bis das Anfrage-Rate-Limit zurückgesetzt wird.x-ratelimit-reset-tokens: Die verbleibende Zeit, bis das Token-Rate-Limit zurückgesetzt wird.
Sobald Sie ein Rate-Limit (RPM oder TPM) erreichen, antwortet die API mit 429 Too Many Requests. Anhand der x-ratelimit-remaining-*-Headern in der Antwort können Sie bestimmen, wann Sie die Anfragen wiederholen sollten.
Mit dieser information kann die client-side application Rate Limiting entsprechend dem specific use-case scenario handhaben. Im Folgenden werden jedoch einige general strategies und approaches zur Bewältigung von Rate Limits genannt.
Implementierungstipps für Rate-Limits
Abschnitt betitelt „Implementierungstipps für Rate-Limits“Um eine resiliente Anwendung zu erstellen, empfehlen wir die Implementierung der folgenden Algorithmen, um API Rate-Limits sinnvoll in die Anwendung zu integrieren.
Exponentielles Delay mit Jitter
Abschnitt betitelt „Exponentielles Delay mit Jitter“Wenn Sie einen Rate-Limit-Fehler (429 Too Many Requests) erhalten, wiederholen Sie die Anfrage mit einer exponentiell wachsenden Wartezeit. Ein zusätzliches Abwarten eines zufälligen kurzen Intervalls (Jitter) verhindert das gleichzeitige Anfragen mehrerer Clients.
Proaktives Überwachen der Quota
Abschnitt betitelt „Proaktives Überwachen der Quota“Verwenden Sie die x-ratelimit-remaining-*-Header , die mit jeder Antwort der API zurückgegeben werden, um Ihre noch zur Verfügung stehende Quota zu tracken. Ihre Anwendung kann dann neue Anfragen pausieren, wenn das Quota niedrig ist, um Fehler zu vermeiden, bevor sie auftreten.
Möglichkeiten, wenn die Standard-Rate-Limits nicht ausreichend sind
Abschnitt betitelt „Möglichkeiten, wenn die Standard-Rate-Limits nicht ausreichend sind“Wenn die Standard-Rate-Limits für Ihre Anwendung nicht ausreichend sein sollten, reichen Sie bitte eine Service Request über das STACKIT Help Center ein, um mögliche Anpassungen zu besprechen.