Strona główna → Pomoc

Concurrency limit exceeded for user, please retry later – co to znaczy

Co widzisz

• 429 Too Many Requests
• Concurrency limit exceeded for user, please retry later
• A batch script that works with 1 worker and fails with 20
• An agent that fails only when it starts several subtasks at once
• Two apps on the same account that break each other

Dlaczego tak się dzieje

Komunikat pochodzi z sub2api, otwartoprzepisowej bramki, na której działa wiele usług przekaźnikowych API, więc możesz go spotkać u więcej niż jednego dostawcy. Limit jest ustawiony na konto użytkownika, nie na klucz: dwa klucze tego samego konta korzystają z jednej puli. Domyślnie sub2api pozwala na 5 jednoczesnych żądań.

Bramka nie odrzuca szóstego żądania od razu. Stawia je w kolejce i uruchamia, gdy tylko zwolni się miejsce. Zmierzyliśmy to na naszej bramce 14 października 2026 przy limicie 5: 10 żądań naraz – wszystkie 10 udały się, najwolniejsze trwało 8,3 sekundy; 25 naraz – wszystkie 25 udały się, najwolniejsze trwało 18,8 sekundy. Nadmiarowe żądania czekały zamiast padać. Jeśli więc widzisz ten błąd, nie przekroczyłeś limitu na chwilę – trwało to na tyle długo, że żądanie nie dostało miejsca na czas.

Dlatego pojawia się przy długich żądaniach, a nie przy wielu krótkich. Odpowiedź strumieniowana, model rozumujący, który myśli minutę, albo agent czekający na narzędzie zajmuje swoje miejsce przez cały ten czas. Pięć takich naraz zapełnia konto, a wszystko za nimi czeka, aż się podda.

Sprawdź, czy to ta przyczyna

Wyślij dziesięć identycznych żądań naraz i spójrz na czasy:

seq 1 10 | xargs -P 10 -I{} curl -s -o /dev/null \
  -w '%{http_code} %{time_total}s\n' \
  'YOUR_BASE_URL/chat/completions' \
  -H 'Authorization: Bearer YOUR_KEY' \
  -H 'Content-Type: application/json' \
  -d '{"model":"YOUR_MODEL","messages":[{"role":"user","content":"Count from 1 to 150."}]}'

Jeśli pierwsze wracają szybko, a reszta przychodzi późniejszymi falami, te fale to twój limit. Jeśli niektóre zwracają 429 z tym komunikatem, kolejka się przepełniła – zmniejszaj wartość -P, aż żadne nie zwróci błędu. To jest równoległość, którą twoje konto naprawdę obsłuży.

Jak to naprawić

1. Ogranicz żądania w toku w kliencieOtocz wywołanie semaforem o rozmiarze limitu konta: asyncio.Semaphore(5) w Pythonie, p-limit w Node. Wolniejsza pętla ponowień nie pomoże; limit liczy otwarte żądania, więc pomaga tylko mniej otwartych żądań.
2. Licz wszystkie klucze kontaJeśli agent do kodu, aplikacja czatu i skrypt dzielą konto, dzielą też limit. Daj ciężkim zadaniom wsadowym osobne konto albo planuj je na czas, gdy reszta stoi.
3. Ten błąd ponawiaj – z odczekaniem i losowościąW przeciwieństwie do 429 za pusty balans ten mija sam, gdy trwające żądania się kończą. Odczekaj sekundę lub dwie, dodaj losowe przesunięcie, żeby workery nie ponawiały równocześnie, i spróbuj ponownie.
4. Zmniejsz równoległość w agentachNarzędzia agentowe uruchamiające podzadania mogą otworzyć wiele żądań naraz. Większość pozwala w ustawieniach ograniczyć liczbę jednoczesnych zadań lub workerów; ustaw ją na poziomie limitu konta lub niżej.
5. Wyższy limit tylko przy stałym obciążeniuJeśli twoja praca naprawdę potrzebuje więcej otwartych żądań przez cały dzień, poproś dostawcę. Na skoki ruchu kolejka po twojej stronie jest tańsza i szybsza niż wyższy limit.

Powiązane

Ostatnio sprawdzono 2026-10-14. Napisane na podstawie problemów zdiagnozowanych na działającej bramce zgodnej z OpenAI, a nie zebrane z innych stron.