Błędy „Osiągnięto limit żądań” interfejsu OpenAI: co oznaczają i jak je obsłużyć

Interfejs API openAI zwraca wartość 429 „Osiągnięto limit liczby żądań”, gdy organizacja wysłała więcej żądań lub więcej tokenów na minutę niż dozwolone limity. Limity mają zastosowanie do organizacji, a nie dla każdego użytkownika. Te błędy są tymczasowe. Jeśli zaczekasz i ponownie wyślesz żądanie, zwykle zakończy się to powodzeniem. Niektóre inne 429 błędy z platformy OpenAI dotyczą rozliczeń, a te nie znikają, gdy czekasz. Aby uzyskać więcej informacji, zobacz Kody błędów.

Jak wyglądają błędy limitu żądań OpenAI

Status Error Co to znaczy Ponów próbę?
429 rate_limit_exceeded, żądania na minutę (RPM) W ciągu minuty wysłano zbyt wiele żądań. Tak, po Retry-After
429 rate_limit_exceeded, tokeny na minutę (TPM) Twoje żądania przekroczyły limit tokenów na minutę. Komunikat pokazuje limit, liczbę użytych tokenów i liczbę tokenów, o które poproszono w żądaniu. Tak, po Retry-After. Mniejsze żądania pomagają.
429 slow_down (typ rate_limit_error) Twój ruch wzrósł zbyt szybko, mimo że mieścisz się w limitach RPM i TPM. Tak, przy niższej stawce
503 server_is_overloaded (typ service_unavailable_error) Serwery OpenAI są zajęte. Tak, z dłuższymi opóźnieniami za każdym razem
429 credit_balance_exhausted, błędy limitu wydatków lub limitu użycia (typ insufficient_quota) Nie masz kredytów lub przekraczasz limit. No. Zobacz insufficient_quota OpenAI i credit_balance_exhausted.

Większość tych błędów ma ten sam 429 status, więc nie można ich odróżnić wyłącznie na podstawie statusu. Przeczytaj error.code w treści odpowiedzi.

Jak obsługiwać błędy związane z limitem żądań OpenAI

  1. Najpierw sprawdź error.code . Jeśli jest to kod rozliczeniowy, taki jak credit_balance_exhausted, zatrzymaj ponawianie próby i poinformuj użytkownika. Ponowienie próby po błędzie rozliczeniowym nie przywróci dostępu.
  2. Postępuj zgodnie z Retry-After, gdy jest dostępny. Jeśli go brakuje, użyj algorytmu wykładniczego wydłużania odstępów z losowym opóźnieniem i ogranicz liczbę ponownych prób.
  3. Zwolnij po slow_down. Zmniejsz szybkość żądań, a następnie stopniowo zwiększaj ją. Praktyczna zasada OpenAI powyżej 1M wejściowego TPM polega na zwiększaniu ruchu o nie więcej niż 50% co 15 minut.
  4. Wyślij mniej tokenów po błędzie TPM. Krótsze monity i odpowiedzi pozwalają na dopasowanie większej liczby żądań w każdej minucie.
  5. Cofnij się bardziej po 503. Zwiększ opóźnienie między kolejnymi próbami, a następnie sprawdź stronę stanu OpenAI.
  6. Poinformuj użytkownika o tym, co się dzieje. „Zajęty, ponawianie próby w ciągu 5 sekund” jest lepsze niż wskaźnik ładowania, który nigdy się nie kończy.

Zestaw OpenAI Python SDK ponawia próby połączenia oraz odpowiedzi 408, 409, 429 i 5xx domyślnie 2 razy, z krótkim wykładniczo wydłużanym czasem ponawiania. Można to zmienić za pomocą max_retries. Gdy wyczerpią się ponowne próby, SDK zgłasza RateLimitError dla InternalServerError oraz 429 dla 503, więc kod nadal wymaga planu:

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

Jak przetestować, czy aplikacja obsługuje limity szybkości żądań interfejsu OpenAI

Rzadko napotykasz limit żądań OpenAI podczas opracowywania. Jesteś jedynym użytkownikiem, a prompty są krótkie. Dlatego sposób testowania obsługi limitów szybkości decyduje, czy znajdziesz usterki, zanim zrobią to użytkownicy.

Approach Co znajdziesz To, co przegapisz
Poczekaj na produkcję Rzeczywiste awarie Wszystko, dopóki użytkownik tego nie kliknie
Mockuj interfejs API w testach lub pozwól agentowi kodowania napisać mock Czy gałąź ponowienia jest uruchamiana Rzeczywiste treści błędów i kody OpenAI oraz zasady ponawiania prób zestawu SDK. Aplikacja wymaga również przełącznika tylko do testowania, aby uzyskać dostęp do mocka.
Wywołuj rzeczywiste API, aż API zacznie Cię ograniczać Rzeczywiste zachowanie Nie można wyzwolić określonego błędu na żądanie, a każde żądanie kosztuje tokeny
Przechwytuj rzeczywisty ruch aplikacji i zwracaj błędy interfejsu OpenAI na żądanie Rzeczywiste adresy URL, prawdziwy zestaw SDK i zasady ponawiania prób oraz własny format błędu OpenAI W Twojej aplikacji nic się nie zmienia, więc aplikacja nie testuje Twojego kodu w izolacji. Zachowaj testy jednostkowe do tego.

Wypróbuj ją w swojej aplikacji

Dev Proxy przechwytuje żądania aplikacji do api.openai.com i zwraca błędy OpenAI, podczas gdy aplikacja nadal wywołuje rzeczywiste adresy URL. Preset openai-throttling kończy się niepowodzeniem w przypadku większości żądań z losowo wybranymi błędami TPM i RPM rate_limit_exceeded, slow_down, credit_balance_exhausted i 503server_is_overloaded, we własnym formacie OpenAI. Odpowiedzi 429 dotyczące limitu szybkości zawierają nagłówek Retry-After, a jeśli aplikacja ponawia próbę, zanim ten czas upłynie, Dev Proxy zgłasza to.

Pobierz preset i uruchom Dev Proxy za jego pomocą:

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

Następnie uruchom aplikację jak zwykle i obserwuj, co robi. Aby zainstalować Dev Proxy, zobacz Konfigurowanie Dev Proxy.

Aby sprawdzić, jak działa aplikacja, gdy zabraknie tokenów na minutę, na podstawie tokenów monitu i odpowiedzi używanych przez żądania, zobacz Limity tokenów modelu językowego testu.

Następne kroki

Sprawdź, jak Twoja aplikacja obsługuje limity szybkości OpenAI

Informacje dodatkowe

  • Ostatnia aktualizacja o