HomeBlog › Pourquoi les applications LLM atteignent 429 limites de débit

Pourquoi votre application LLM génère 429 erreurs – les calculs du TPM que personne n'explique

Publié 2026-06-28 · Limites de référence, vérifiez dans le tableau de bord de votre fournisseur

Vous lisez la documentation. Votre niveau permet 500 requêtes par minute. Vous en envoyez peut-être huit. Et pourtant les journaux sont pleins de 429 Too Many Requests. Il n'y a rien de mal avec votre code : vous touchez le autre limite, celle que la plupart des tutoriels sautent : jetons par minute (TPM). Tous les principaux fournisseurs de LLM vous mesurent simultanément le RPM et le TPM, et en réalité, la limite de jetons est presque toujours la première.

Deux limites, et celle qui lie réellement

Prenez le niveau d'entrée d'OpenAI pour GPT-4o : environ 500 tr/min et 30 000 TPM (référence, juin 2026). Le nombre de RPM semble généreux. Mais une invite de récupération augmentée avec quelques documents insérés peut facilement être 4 000 jetons dans et 500 sorties — appelez cela 4 500 jetons par requête. Maintenant, faites la division que les documents ne font pas :

LimiteValeurRequêtes maximales/min à 4 500 tok
RPM (requêtes/min)500500
TPM (jetons/min)30,0006.7 ◀ lie

Les prix sont des estimations de référence, juillet 2026. Signaler un prix obsolète →

Donc votre vrai plafond est moins de sept requêtes par minute, et non 500. La limite de jetons vous plafonne à 1,3 % de ce qu'implique la limite de demande. C'est pourquoi les 429 démarrent avec un trafic à un chiffre – et pourquoi « envoyer plus lentement » ou « ajouter une nouvelle tentative » traite le symptôme et non la cause.

Transformez la limite en quelque chose que vous pouvez planifier : utilisateurs simultanés

Les requêtes par minute sont abstraites. Ce que tu veux vraiment savoir, c'est combien de personnes peuvent utiliser l'application à la fois. Si chaque utilisateur actif déclenche environ deux requêtes par minute, ce plafond de 6,7 tr/min est d'environ trois utilisateurs simultanés avant que les demandes ne commencent à être mises en file d'attente. Très bien pour une démo ; un mur pour un lancement. La solution consiste rarement en une boucle plus rapide : il s'agit de l'un des quatre leviers :

Ce n'est pas seulement OpenAI

Le même piège existe partout, parfois plus serré. L'entrée d'Anthropic, Claude Tier, est là 50 tr/min/40 000 TPM; Le niveau gratuit Gemini 2.5 Flash de Google est généreux en jetons (~ 250 000 TPM) mais avare en requêtes (~ 10 RPM). La limite de liaison varie selon que vos invites sont volumineuses ou que votre trafic est pointu – c'est exactement pourquoi une seule règle empirique échoue. Il faut se brancher ton taille du jeton.

C'est ce que notre nouveau calculateur de limite de taux fait : entrez un niveau (ou votre véritable TPM/RPM), vos jetons d'entrée et de sortie et la fréquence à laquelle chaque utilisateur appelle, et il vous indique les requêtes effectives par minute, les utilisateurs simultanés que vous pouvez servir et quelle limite est le goulot d'étranglement. C'est le moyen le plus rapide de savoir si un lancement va heurter un mur avant vos utilisateurs.

Les plats à emporter

Les erreurs 429 en dessous de votre limite de RPM ne sont pas un bug : c'est la limite de jetons par minute qui fait son travail. Capacité de taille activée jetons, et non le nombre de demandes ; coupez le contexte avant de procéder à de nouvelles tentatives ; et rappelez-vous que la limite augmente avec les dépenses. Une fois que vous connaissez votre plafond réel, évaluez le trafic avec le Calculateur du coût des jetons LLM et modélisez l'ensemble de l'application sur le Estimateur du coût des applications d'IA.

Les limites de taux sont des chiffres de référence (juin 2026) et varient selon le fournisseur, le modèle et le niveau de compte — confirmez toujours dans votre tableau de bord. En rapport: Calculateur de limite de taux · Économies liées à l'API par lots · API LLM la moins chère.