Testa hur din app hanterar OpenAI-hastighetsgränser

Överblick
Mål: Testa hur din app hanterar OpenAI-frekvensbegränsning och överbelastningsfel
Tid: 10 minuter
Plugin-program:GenericRandomErrorPlugin, RetryAfterPlugin
Krav:Konfigurera Dev Proxy

Appen fungerar under utveckling och misslyckas sedan i produktion med 429 Too Many Requests. OpenAI:s begränsningar för begärandefrekvens beror på din organisations användningsnivå, din modell och alla andra som använder samma organisation, så att du inte kan slå i dem med flit på ett tillförlitligt sätt. Dev Proxy returnerar samma fel som OpenAI-API:et returnerar, så att du kan se vad din app gör innan dina användare gör det.

Vet vad OpenAI returnerar

Alla OpenAI-fel betyder inte "försök igen". Din app måste skilja dem åt.

Status error.code Vad det innebär Vad din app ska göra
429 rate_limit_exceeded Du har nått gränsen för dina begäranden per minut (RPM) eller token per minut (TPM). Vänta tills tiden visas i rubriken Retry-After och försök sedan igen.
429 slow_down Din begärandefrekvens ökade för snabbt, även om du ligger inom dina gränser. Vänta tills Retry-After, minska din begärandefrekvens och öka den gradvis.
429 credit_balance_exhausted Din organisation har inga förbetalda krediter kvar. Försök inte igen. Om du försöker igen återställs inte åtkomsten. Berätta för användaren eller avisera en administratör.
503 server_is_overloaded Modellen har inte tillräckligt med kapacitet just nu. Vänta på Retry-After, om den finns, och försök sedan igen med ökande fördröjningar.

Den fullständiga listan finns i Felkoder i OpenAI-dokumentationen.

Important

Alla tre felen på de 429 raderna använder samma statuskod. Om appen försöker igen vid varje 429-fel försöker den igen med debiteringsfel som aldrig går över. Kontrollera error.code för att avgöra vad du ska göra.

Ta reda på vad OpenAI SDK gör åt dig

De officiella OpenAI SDK:erna för Python och JavaScript gör som standard 2 nya försök för svarskoderna 408, 409, 429 och 5xx samt vid anslutningsfel, med exponentiell backoff. Du kan ändra detta med alternativet max_retries i Python och maxRetries i JavaScript.

SDK-återförsök täcker korta toppar. Din app måste fortfarande bestämma vad som händer när återförsöken tar slut och hur fel som återförsök inte åtgärdar ska hanteras. I Python ger en 429 upphov till RateLimitError och en 503 ger upphov till InternalServerError, så hantera båda.

Tip

Om du vill se exakt vad felhanteringskoden tar emot anger du max_retries=0 (Python) eller maxRetries: 0 (JavaScript) när du testar. Aktivera SDK-återförsöken igen efteråt.

Simulera OpenAI-hastighetsbegränsningar

Dev Proxy har en förinställning med OpenAI-felen i tabellen. Ladda ned den:

devproxy config get openai-throttling

Starta Dev Proxy med förinställningen:

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

Förinställningen misslyckas för 90 % av begärandena till https://api.openai.com/* med ett slumpmässigt fel från tabellen. För svar om frekvensbegränsning anger den Retry-After headern och använder RetryAfterPlugin för att kontrollera att appen väntar så länge innan den anropar API:et igen.

Kontrollera att appen skickar sina begäranden via Dev Proxy och litar på Dev Proxy-certifikatet. För Node.js, se Använd Dev Proxy med Node.js-program. För andra körningsmiljöer, se Felsöka Dev Proxy.

Kör appen och kontrollera att:

  • Efter ett rate_limit_exceeded eller slow_down fel väntar appen på tiden Retry-After . Om det anropar API:et för tidigt rapporterar Dev Proxy det och begränsar begäran.
  • Efter ett credit_balance_exhausted fel slutar appen att anropa API:et och visar ett tydligt meddelande.
  • Efter ett server_is_overloaded fel försöker appen igen med en fördröjning och, när återförsöken tar slut, faller tillbaka eller visar ett tydligt meddelande i stället för en stackspårning.
  • Din app förlorar inte ditt arbete. Till exempel fortsätter en lång chattkonversation eller ett batchjobb efter felet.

Om du vill ändra hur ofta förfrågningar ska misslyckas, använder du alternativet --failure-rate. Om du till exempel vill att varje begäran ska misslyckas:

devproxy --config-file "~dataFolder/configs/openai-throttling/.devproxy/devproxyrc.json" --failure-rate 100

Simulera tokengränser för Azure OpenAI och andra providers

Förinställningen returnerar fel slumpmässigt, oavsett hur många token som appen använder. Om du vill begränsa begäranden baserat på faktisk tokenanvändning, till exempel för att se vad som händer när en lång konversation överskrider TPM-gränsen, använder du LanguageModelRateLimitingPlugin. Det fungerar med alla OpenAI-kompatibla API:er, inklusive Azure OpenAI och lokala modeller. Mer information finns i Testa tokenbegränsningar för språkmodeller.

Nästa steg

Lär dig hur du simulerar tokenbaserade gränser.

Testa språkmodellens tokenbegränsningar

Se även

  • Uppdaterades senast