OpenAI 'Rate limit reached'-foutmeldingen: wat ze betekenen en hoe je ermee omgaat

De OpenAI-API retourneert 429 met "Rate limit reached" wanneer uw organisatie meer aanvragen of meer tokens per minuut heeft verzonden dan de limieten toelaten. Beperkingen gelden voor uw organisatie, niet voor elke gebruiker. Deze fouten zijn van tijdelijke aard. Als u wacht en de aanvraag opnieuw verzendt, slaagt dit meestal. Sommige andere 429 fouten van OpenAI gaan over facturering en die gaan niet weg wanneer u wacht. Zie Foutcodes voor meer informatie.

Zo zien de rate-limitfouten van OpenAI eruit

Status Fout Wat betekent het? Probeer het opnieuw?
429 rate_limit_exceededaanvragen per minuut (RPM) U hebt binnen een minuut te veel aanvragen verzonden. Ja, na Retry-After
429 rate_limit_exceeded, tokens per minuut (TPM) Uw verzoeken gebruikten te veel tokens in één minuut. In het bericht ziet u uw limiet, hoeveel tokens u hebt gebruikt en hoeveel er door het verzoek is aangevraagd. Ja, na Retry-After. Kleinere verzoeken helpen.
429 slow_down (type rate_limit_error) Uw verkeer is te snel gegroeid, ook al bevindt u zich binnen uw RPM- en TPM-limieten. Ja, tegen een lager tarief
503 server_is_overloaded (type service_unavailable_error) De servers van OpenAI zijn bezet. Ja, telkens met langere vertragingen
429 credit_balance_exhausted, fouten met bestedingslimiet of gebruikslimiet (type insufficient_quota) U hebt geen tegoed of een limiet overschreden. No. Zie OpenAI-insufficient_quota en credit_balance_exhausted.

De meeste van deze fouten delen de 429 status, dus kunt u ze niet van elkaar onderscheiden op basis van alleen de status. Lees error.code in de hoofdtekst van het antwoord.

Fouten met OpenAI-rate limits afhandelen

  1. Controleer error.code eerst. Als het een factureringscode is zoals credit_balance_exhausted, stop met opnieuw proberen en vertel de gebruiker. Als u een factureringsfout opnieuw probeert, wordt de toegang niet hersteld.
  2. Volg Retry-After wanneer deze aanwezig is. Als deze ontbreekt, gebruikt u exponentieel uitstel met jitter en beperkt u het aantal nieuwe pogingen.
  3. Vertraag na slow_down. Verlaag uw aanvraagsnelheid en voer deze daarna geleidelijk weer op. OpenAI's vuistregel bij meer dan 1M input-TPM is om het verkeer elke 15 minuten met maximaal 50% te verhogen.
  4. Minder tokens verzenden na een TPM-fout. Kortere prompts en antwoorden laten meer aanvragen in elke minuut passen.
  5. Verder teruggaan na een 503. Verhoog de vertraging tussen nieuwe pogingen en controleer de statuspagina van OpenAI.
  6. Vertel de gebruiker wat er gebeurt. "Bezet, opnieuw proberen in 5 seconden" is beter dan een spinner die nooit eindigt.

De OpenAI Python SDK probeert aanvragen standaard 2 keer opnieuw bij verbindingsfouten en 408, 409, 429 en 5xx-antwoorden, met een korte exponentiële back-off. U kunt het wijzigen met max_retries. Wanneer de herhalingspogingen op zijn, genereert de SDK 429 voor een InternalServerError en 503 voor een RateLimitError, zodat uw code nog steeds een plan nodig heeft:

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

Testen of uw app OpenAI-ratelimieten verwerkt

U loopt tijdens het ontwikkelen zelden tegen een OpenAI-ratelimiet aan. U bent de enige gebruiker en uw prompts zijn kort. De manier waarop u de afhandeling van rate limiting test, bepaalt dus of u de bugs vindt voordat uw gebruikers dat doen.

Approach Wat u vindt Wat u mist
Wacht op productie Echte storingen Alles, tot een gebruiker erop klikt
Mock de API in je tests, of laat je codeeragent de mock schrijven Of uw herhalingsvertakking wordt uitgevoerd OpenAI's daadwerkelijke error-responses en -codes, en het beleid voor opnieuw proberen van uw SDK. Uw app heeft ook een schakelaar alleen voor testdoeleinden nodig om de mock te bereiken.
De echte API aanroepen totdat deze u rate-limiet oplegt Werkelijk gedrag U kunt geen specifieke fout op aanvraag activeren en elke aanvraag kost tokens
Het echte verkeer van uw app onderscheppen en OpenAI-fouten retourneren op aanvraag Echte URL's, uw echte SDK en beleid voor opnieuw proberen, en de eigen foutindeling van OpenAI Er verandert niets in uw app, dus uw code wordt niet geïsoleerd getest. Gebruik daar unittests voor.

Probeer het uit in je app

Dev Proxy onderschept de aanvragen van uw app naar api.openai.com en retourneert OpenAI-fouten, terwijl uw app de echte URL's blijft aanroepen. De voorinstelling mislukt bij de openai-throttling meeste aanvragen met een willekeurige keuze uit TPM- en RPMrate_limit_exceeded, slow_down, credit_balance_exhausted en 503server_is_overloaded-fouten, in de eigen indeling van OpenAI. De 429 rate-limietreacties bevatten een Retry-After header en als uw app opnieuw probeert voordat die tijd is verstreken, rapporteert Dev Proxy deze.

Download de voorinstelling en start de Dev Proxy ermee:

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

Voer vervolgens uw app zoals gebruikelijk uit en bekijk wat deze doet. Zie Dev Proxy instellen om Dev Proxy te installeren.

Zie Tokenlimieten voor het taalmodel testen om te zien hoe uw app zich gedraagt wanneer er per minuut geen tokens meer zijn, op basis van de prompt- en voltooiingstokens die door uw aanvragen worden gebruikt.

Volgende stappen 

Test hoe uw app OpenAI-frequentielimieten verwerkt

Zie ook

  • Laatst bijgewerkt om