Accueil → Aide

Concurrency limit exceeded for user, please retry later : ce que cela veut dire

Ce que vous voyez

• 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

Pourquoi cela arrive

Le message vient de sub2api, la passerelle open source sur laquelle tournent beaucoup de services de relais d'API, donc vous pouvez le croiser chez plusieurs fournisseurs. La limite est fixée par compte utilisateur, pas par clé : deux clés du même compte puisent dans le même réservoir. La valeur par défaut de sub2api est de 5 requêtes simultanées.

La passerelle ne rejette pas la sixième requête tout de suite. Elle la met en file d'attente et la lance dès qu'une place se libère. Nous l'avons mesuré sur notre propre passerelle le 14 octobre 2026 avec une limite de 5 : 10 requêtes en même temps, les 10 ont réussi et la plus lente a pris 8,3 secondes ; 25 en même temps, les 25 ont réussi et la plus lente a pris 18,8 secondes. Les requêtes en trop ont attendu au lieu d'échouer. Quand vous voyez cette erreur, vous n'avez donc pas dépassé la limite un instant : vous êtes resté au-dessus assez longtemps pour qu'une requête n'obtienne pas de place à temps.

C'est pourquoi elle apparaît avec des requêtes longues plutôt qu'avec beaucoup de courtes. Une réponse en streaming, un modèle de raisonnement qui réfléchit une minute ou un agent qui attend un outil garde sa place tout ce temps. Cinq comme ça en même temps remplissent le compte, et tout ce qui suit attend jusqu'à abandonner.

Vérifiez si c'est bien la cause

Envoyez dix requêtes identiques en même temps et regardez les durées :

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."}]}'

Si les premières reviennent vite et le reste par vagues ensuite, ces vagues sont votre limite. Si certaines renvoient 429 avec ce message, la file a débordé : baissez la valeur de -P jusqu'à ce qu'aucune ne le fasse. C'est le parallélisme que votre compte supporte vraiment.

Comment le corriger

1. Limitez les requêtes en cours côté clientPlacez un sémaphore autour de l'appel, à la taille de la limite du compte : asyncio.Semaphore(5) en Python, p-limit en Node. Une boucle de relance plus lente ne règle rien ; la limite compte les requêtes ouvertes, seules moins de requêtes ouvertes aident.
2. Comptez toutes les clés du compteSi un agent de code, une appli de chat et un script partagent un compte, ils partagent une limite. Donnez aux gros traitements par lots leur propre compte, ou planifiez-les quand le reste est au repos.
3. Celle-ci se relance, avec délai et aléaContrairement au 429 pour solde épuisé, celle-ci se règle d'elle-même dès que les requêtes en cours finissent. Attendez une à deux secondes, ajoutez un décalage aléatoire pour que vos workers ne relancent pas en même temps, puis réessayez.
4. Réduisez le parallélisme dans les agentsLes outils d'agents qui lancent des sous-tâches peuvent ouvrir beaucoup de requêtes d'un coup. La plupart permettent de plafonner les tâches ou workers simultanés dans leurs réglages ; mettez-le au niveau de la limite du compte ou en dessous.
5. Demandez une limite plus haute seulement pour une charge continueSi votre travail a vraiment besoin de plus de requêtes ouvertes toute la journée, demandez-le à votre fournisseur. Pour des pics, une file d'attente de votre côté est moins chère et plus rapide qu'une limite plus haute.

Voir aussi

Dernière vérification le 2026-10-14. Rédigé à partir de problèmes diagnostiqués sur une passerelle compatible OpenAI en production, pas compilé à partir d'autres sites.