OpenAI 'gränsen för begäranden har nåtts'-fel: vad de betyder och hur man hanterar dem

OpenAI API returnerar 429 med "Gränsen för begärandefrekvens har nåtts" när din organisation har skickat fler begäranden eller fler token per minut än vad dess gränser tillåter. Begränsningar gäller för din organisation, inte för varje användare. Dessa fel är tillfälliga. Om du väntar och skickar begäran igen lyckas den vanligtvis. Vissa andra 429 fel från OpenAI handlar om fakturering och de försvinner inte när du väntar. Mer information finns i Felkoder.

Så här ser OpenAI:s rate limit-fel ut

Status Fel Vad det innebär Försök igen?
429 rate_limit_exceeded, begäranden per minut (RPM) Du har skickat för många begäranden på en minut. Ja, efter Retry-After
429 rate_limit_exceeded, token per minut (TPM) Dina begäranden innehöll för många token på en minut. Meddelandet visar din gräns, hur många token du använde och hur många som begäran efterfrågade. Ja, efter Retry-After. Hjälp med mindre begäranden.
429 slow_down (typ rate_limit_error) Din trafik växte för snabbt, även om du är inom RPM- och TPM-gränserna. Ja, till en lägre takt
503 server_is_overloaded (typ service_unavailable_error) OpenAIs servrar är upptagna. Ja, med längre fördröjningar varje gång
429 credit_balance_exhausted, utgiftsgräns eller fel för användningsgräns (typ insufficient_quota) Du har slut på krediter eller har överskridit en gräns. No. Se OpenAI insufficient_quota och credit_balance_exhausted.

De flesta av dessa fel har statusen 429, så du kan inte skilja dem åt enbart efter status. Läs error.code i svarstexten.

Så hanterar du OpenAI-fel på grund av hastighetsbegränsning

  1. Kontrollera error.code först. Om det är en faktureringskod som credit_balance_exhausted, sluta göra nya försök och berätta för användaren. Att försöka igen efter ett faktureringsfel återställer inte åtkomsten.
  2. Följ Retry-After när den visas. Om den saknas, använd exponentiell backoff med jitter och begränsa antalet återförsök.
  3. Sakta farten efter slow_down. Minska din förfrågningsfrekvens och öka den sedan gradvis. OpenAIs tumregel över 1 miljon TPM för indata är att öka trafiken med högst 50 % var 15:e minut.
  4. Skicka färre token efter ett TPM-fel. Kortare promptar och svar gör att fler begäranden får plats varje minut.
  5. Dra dig tillbaka ytterligare efter en 503. Öka fördröjningen mellan återförsöken och kontrollera OpenAI:s statussida.
  6. Berätta för användaren vad som händer. "Upptaget, försöker igen om 5 sekunder" är bättre än en laddningsindikator som aldrig försvinner.

OpenAI-Python SDK försöker igen vid anslutningsfel och 408, 409, 429 och 5xx-svar 2 gånger som standard, med en kort exponentiell backoff. Du kan ändra det med max_retries. När återförsöken tar slut genererar SDK:t RateLimitError för en 429 och InternalServerError för en 503, så koden behöver fortfarande en plan:

import openai
from openai import OpenAI

client = OpenAI(max_retries=3)

BILLING_CODES = {
    "credit_balance_exhausted",
    "organization_spend_limit_exceeded",
    "project_spend_limit_exceeded",
    "organization_usage_limit_exceeded",
}


def summarize(text: str) -> str | None:
    try:
        response = client.responses.create(model="gpt-4.1", input=text)
        return response.output_text
    except openai.RateLimitError as error:
        if error.code in BILLING_CODES:
            raise  # Retrying won't help: alert and tell the user
        return None  # Still throttled after retries: show "busy, try again"
    except openai.InternalServerError:
        return None

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

Du når sällan en OpenAI-gräns för antal förfrågningar när du utvecklar. Du är den enda användaren och dina uppmaningar är korta. Så sättet du testar hastighetsbegränsningshanteringen på avgör om du hittar buggarna innan användarna gör det.

Approach Det här hittar du Vad du saknar
Vänta på produktionsmiljön Faktiska fel Allt, tills en användare trycker på den
Mocka API:et i dina tester eller låt kodningsagenten skriva mock Om din gren för återförsök körs OpenAI:s verkliga felsvar och koder, och SDK:ns princip för återförsök. Din app behöver också en testomkopplare för att nå mocken.
Anropa det verkliga API:et tills det stryper dina anrop Faktiskt beteende Du kan inte utlösa ett specifikt fel på begäran, och varje begäran kostar token
Fånga upp appens verkliga trafik och returnera OpenAI-fel på begäran Verkliga URL:er, din riktiga SDK och återförsöksprincip och OpenAI:s eget felformat Ingenting i din app ändras, så din kod testas inte isolerat. Använd enhetstester för det.

Prova det i din app

Dev Proxy fångar upp appens begäranden till api.openai.com och returnerar OpenAI-fel, medan appen fortsätter att anropa de verkliga URL:erna. Förinställningen openai-throttling misslyckas med de flesta begäranden med ett slumpmässigt val från TPM- och RPM-rate_limit_exceeded, slow_down, credit_balance_exhausted och 503server_is_overloaded-fel, i OpenAI:s eget format. Svar 429 om hastighetsbegränsning innehåller en Retry-After header, och om appen försöker igen innan den tiden är slut rapporterar Dev Proxy det.

Ladda ned förinställningen och starta Dev Proxy med den:

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

Kör sedan appen som vanligt och se vad den gör. Information om hur du installerar Dev Proxy finns i Set up Dev Proxy.

Om du vill testa hur din app beter sig när appen får slut på token per minut, baserat på de prompt- och slutförandetoken som dina begäranden använder, läser du Testa språkmodellens tokenbegränsningar.

Nästa steg

Testa hur din app hanterar OpenAI-hastighetsgränser

Se även

  • Uppdaterades senast