LLM-begränsningar: token per minut, begäranden per minut och vad som händer när du når dem

Språkmodell-API:er begränsar trafiken på två sätt samtidigt: hur många begäranden du skickar per minut (RPM) och hur många token du använder per minut (TPM). Du kan hålla dig under din förfrågningsgräns och fortfarande begränsas eftersom några långa promptar har förbrukat din tokenbudget. När du når någon av gränserna svarar API:et med 429 Too Many Requests och appen måste vänta.

Hur OpenAI, Azure OpenAI och Anthropic räknas

Provider Vad är begränsat Vad du behöver veta
OpenAI RPM, begäranden per dag, TPM, token per dag och mer, per organisation och projekt, per modell Du slår i den gräns som nås först. För tokengränsen räknas en begäran som den högre av max_tokens och en uppskattning baserat på dess tecken. Misslyckade begäranden räknas också.
Azure OpenAI TPM som du tilldelar till varje driftsättning, plus en RPM-gräns som har angetts i proportion till den RPM kontrolleras över fönster på 1 eller 10 sekunder, så en burst får en 429 även när summan per minut är bra. Tokenuppskattningen innehåller max_tokens.
Anthropic RPM, inmatningstoken per minut (ITPM) och utmatningstoken per minut (OTPM) per modell Kapaciteten fylls på kontinuerligt och 60 RPM kan upprätthållas som 1 begäran per sekund. För de flesta modeller räknas cachelagrade indatatoken inte mot ITPM och max_tokens räknas inte mot OTPM.

Om du anger max_tokens till 4 000 och får tillbaka 200 token räknar OpenAI och Azure OpenAI fortfarande 4 000 mot din gräns. Det är så du kan få 429:or medan din användningsstatistik ligger långt under din kvot.

Vad en 429 betyder för varje leverantör

Alla 429-fel går inte över bara för att du väntar.

Provider Vänta och försök igen Stanna och berätta för någon
OpenAI 429 för begäranden eller token, 429 slow_down (trafiken växte för snabbt, även inom dina gränser) och 503 server_is_overloaded. Vänta på Retry-After när den visas. 429 med credit_balance_exhausted, organization_spend_limit_exceeded, project_spend_limit_exceededeller organization_usage_limit_exceeded i error.code. Om du försöker igen återställs inte åtkomsten.
Azure OpenAI 429 för driftsättningens TPM eller RPM, för systemkapacitet eller för en tillfällig sänkning av frekvensgränsen. Vänta på retry-after-ms. Det förekommer ihållande 429-fel i produktion medan du är under din godkända kvot. Kontrollera driftsättningens TPM-allokering och öppna sedan en supportbegäran.
Anthropic 429 rate_limit_error med en retry-after header, inklusive accelerationsgränser efter en kraftig ökning av användningen och 529 overloaded_error. 429 för det månatliga utgiftstaket. Den har ingen retry-after rubrik, error.details.error_code är enforced_spend_limit_reached, och den fortsätter att misslyckas tills åtkomsten återupptas.

Hantera LLM-frekvensbegränsningar

  1. Kontrollera vilka 429 du fick. Fakturerings-, utgifts- och kvotfel behöver en person, inte ett nytt försök.
  2. Vänta så länge som API:et anger. OpenAI och Anthropic skickar retry-after på några sekunder. Azure OpenAI skickar retry-after-ms i millisekunder. Utan en hint kan du backa exponentiellt med slumpmässig jitter och begränsa både antalet försök och den totala tiden.
  3. Vet du vad din SDK redan gör. OpenAI och Anthropic Python SDK:er försöker igen vid anslutningsfel och 408, 409, 429 och 5xx-svar 2 gånger som standard. Om du lägger till en egen återförsöksloop inaktiverar du SDK:ts återförsök, till exempel med max_retries=0 i Python, som Azure OpenAI rekommenderar, eller försöken multipliceras.
  4. Minska det som räknas. I OpenAI och Azure OpenAI ställer du in max_tokens på ett värde nära den svarsstorlek som du förväntar dig. Cachelagra upprepat innehåll på Anthropic, till exempel systeminstruktioner.
  5. Öka gradvis. Ett kraftigt hopp i trafiken utlöser OpenAI:s slow_down och Anthropics accelerationsbegränsningar, även inom dina gränser. OpenAI anger att när du når 1 miljon indatatoken per minut växer du med högst 50 % var 15:e minut.
  6. Spela inte upp en stream som du redan har spelat upp. Ett fel efter att en ström har startat kan komma som en strömhändelse, och OpenAI avråder från att automatiskt upprepa en begäran när du har förbrukat utdata.
  7. Berätta för användaren när en begäran stannar på en 429 i stället för att visa en laddningsindikator.

Så här testar du att din app hanterar LLM-hastighetsgränser

Approach Det här hittar du Vad du saknar
Mocka SDK-klienten i dina tester eller låt kodagenten skriva mock Huruvida felgrenen körs Leverantörens verkliga statuskoder, felkoder och headers samt SDK:ets egna återförsök. Din app behöver också en testomkopplare för att nå mocken.
Anropa det verkliga API:et tills det börjar strypa dina anrop Faktiskt beteende Du betalar för varje token och du kan inte utlösa slow_down, en överbelastning eller ett utgiftstak på begäran
Fånga upp appens verkliga trafik och returnera providerns fel, eller stryp baserat på de token som appen använder Verkliga URL:er, SDK:ets återförsöksprincip och leverantörens felsvar, med en gräns som du väljer Koden är isolerad. Behåll enhetstesterna för det.

Prova det i din app

Dev Proxy fångar upp appens begäranden till språkmodell-API:et och returnerar leverantörens egna fel, medan appen fortsätter att anropa den verkliga URL:en. För OpenAI laddar du ned förinställningen och startar Dev Proxy med den:

devproxy config get openai-throttling
devproxy --config-file "~dataFolder/configs/openai-throttling/.devproxy/devproxyrc.json"

Förinställningen openai-throttling misslyckas med 90% begäranden till https://api.openai.com/* med ett slumpmässigt fel: rate_limit_exceeded för TPM eller RPM, slow_down, credit_balance_exhaustedeller 503 server_is_overloaded. Förinställningen anthropic-throttling gör samma sak för https://api.anthropic.com/* med RPM, indatatoken, utdatatoken och accelerations-429:or och accelerations-529:or overloaded_error. Båda förinställningarna inkluderar RetryAfterPlugin, som anger när din app anropar API:et igen innan retry-after tiden på en 429 är slut. Den kontrollerar inte svaren 503 och 529.

Om du vill begränsa tokenförbrukningen för de token som appen faktiskt använder använder du LanguageModelRateLimitingPlugin. Den räknar de prompt- och slutförandetoken som varje svar rapporterar och returnerar 429 med retry-after när appen överskrider de gränser som du anger. Det fungerar med OpenAI-kompatibla API:er, inklusive Azure OpenAI och lokala modeller:

{
  "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.3.1/rc.schema.json",
  "plugins": [
    {
      "name": "LanguageModelRateLimitingPlugin",
      "enabled": true,
      "pluginPath": "~appFolder/plugins/DevProxy.Plugins.dll",
      "configSection": "languageModelRateLimitingPlugin"
    }
  ],
  "urlsToWatch": [
    "https://api.openai.com/*",
    "https://*.openai.azure.com/openai/deployments/*/chat/completions*"
  ],
  "languageModelRateLimitingPlugin": {
    "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.3.1/languagemodelratelimitingplugin.schema.json",
    "promptTokenLimit": 1000,
    "completionTokenLimit": 500,
    "resetTimeWindowSeconds": 60
  }
}

Plugin-programmet återskapar inte uppskattningen max_tokens . Standardtexten för 429-svar använder koden insufficient_quota. Om du vill returnera feltexten som appen förväntar sig för en frekvensgräns anger du whenLimitExceeded till Custom och pekar customResponseFile till ditt eget svar. Mer information om hur du installerar Dev Proxy finns i Konfigurera Dev Proxy.

Nästa steg

Testa hur din app hanterar OpenAI-hastighetsgränser

Se även

  • Uppdaterades senast