Rate limits des API LLM : 13 acteurs, 2 SDK sans retry 429

Sur les treize API LLM étudiées ici, soit dix fournisseurs plus Bedrock, Vertex AI et Azure OpenAI, quatre indiquent le budget restant dans chaque réponse. Mistral ne renvoie qu’un seul compteur restant, et huit ne donnent aucune information avant l’échec de la requête. Un « 429 » recouvre quatre situations différentes : une limitation de débit qu’il faut retenter, une limite d’accélération qui impose de ralentir, un quota ou plafond de dépenses qu’il ne faut pas retenter, et une surcharge signalée par un 429, un 503 ou un 529 selon le fournisseur. Le client pèse aussi lourd que le fournisseur : les SDK OpenAI, Anthropic et Groq retentent deux fois un 429, mais abandonnent lorsque Retry-After dépasse 60 ou 120 secondes. Les SDK Google GenAI et Mistral, eux, désactivent les retries par défaut. Voici une référence transverse : dimensions, tokens comptabilisés, headers, sémantique des 429 et comportement de chaque SDK officiel, vérifié directement dans son code source.

TL;DR

• Les API LLM limitent les requêtes et les tokens par minute. Anthropic sépare entrée et sortie, tandis que DeepSeek limite uniquement la concurrence.
• OpenAI, Azure et Bedrock débitent max_tokens dès le départ. Anthropic exclut les lectures du cache, xAI compte les tokens de raisonnement, et Bedrock consomme 10 tokens de quota par token de sortie Claude 5.
• OpenAI, Anthropic, Groq et Azure renvoient les headers de limite, de solde et de réinitialisation avec chaque 200. Huit API n’en documentent aucun.
• Les SDK google-genai et Mistral ne retentent pas un 429 par défaut. OpenAI, Anthropic et Groq font deux retries et plafonnent Retry-After à 60 ou 120 secondes.

Que signifient RPM, TPM et les autres limites ?

Toutes fixent un plafond d’utilisation sur une fenêtre donnée, mais chaque fournisseur choisit ses propres métriques :

La valeur affichée est un plafond sur la fenêtre, pas un crédit à consommer librement. Anthropic précise que 60 RPM « might be enforced as 1 request per second ». Azure indique qu’« a burst within a 1-second or 10-second window can trigger a 429 even if the per-minute total is within limits ».

Quelles limites les API LLM appliquent-elles ?

Presque toutes limitent les requêtes et les tokens par minute. Les trois clouds ne se contentent pas de relayer les règles de leurs fournisseurs. Les définitions ci-dessous sont celles des fournisseurs, telles qu’elles figuraient sur les pages liées les 2026-09-03 et 2026-09-04.

Deux lignes ne correspondent pas du tout à des fenêtres d’une minute. DeepSeek limite les connexions ouvertes. En cas de charge, il conserve la requête ouverte en envoyant des lignes vides, ou des commentaires : keep-alive sur un stream, pendant 10 minutes au maximum au lieu de la rejeter. Vertex AI en pay-as-you-go ne publie aucun quota consultable : un 429 signifie simplement que le pool partagé manquait de capacité à cet instant.

Quels tokens sont imputés à la limite ?

Ce ne sont pas toujours les mêmes que ceux facturés. Selon la règle retenue, la capacité réelle peut représenter une fraction ou un multiple du chiffre affiché :

Dans l’exemple ci-dessus, la même requête pèse entre 800 et 6,000 tokens selon le fournisseur. Un routeur qui répartit une charge entre plusieurs fournisseurs doit donc maintenir un compteur propre à chacun.

Quels headers chaque fournisseur renvoie-t-il ?

Quatre API exposent l’état des limites dans chaque réponse. Mistral renvoie un seul champ. Les huit autres vous obligent à compter vous-même.

Le vrai problème vient des trois formats utilisés pour un même champ : durée chez OpenAI, timestamp chez Anthropic et valeur comme 2m59.56s chez Groq. Il faut trois parseurs. C’est notamment pour cela que les SDK ne lisent que retry-after. Deux intermédiaires ont été testés le 2026-09-03, avec une requête chacun. Un grand agrégateur multi-fournisseurs n’a renvoyé aucun header de rate limit sur une réponse 200 et les réserve aux 429. La gateway Synthorai a renvoyé x-ratelimit-remaining-requests et x-ratelimit-reset-requests avec le coût de la requête.

Que signifie un 429, et faut-il retenter ?

Un 429 peut correspondre à quatre situations. Seules deux justifient un retry :

Le piège se trouve sur la troisième ligne. Chez Anthropic, un 429 lié au plafond de dépenses porte le même type rate_limit_error qu’un throttling, et la documentation précise : « Retrying, including the SDKs’ automatic retries, fails until access resumes. » Chez OpenAI, insufficient_quota est également un 429. Un client qui ne regarde que le code HTTP retente les deux, comme le font tous les SDK officiels décrits dans la section suivante. Il faut décider selon le code d’erreur et considérer qu’un 429 sans Retry-After peut indiquer qu’attendre ne servira à rien.

Les clouds se distinguent sur la quatrième ligne. Le guide de diagnostic Azure est explicite : « Many customers misinterpret capacity-related 429s as quota problems, leading to incorrect remediation. » Sur Azure, un 429 accompagné d’un x-ratelimit-limit-tokens inférieur à la limite configurée vient du mécanisme de protection du pool partagé. Sur Vertex AI, tous les 429 en pay-as-you-go ont cette signification. Sur Bedrock, la même situation produit un 503 ou un 529, jamais un ThrottlingException. Via un agrégateur, l’information apparaît dans le corps. Lors de la mesure des headers, un 429 a été encapsulé avec provider_error_code: insufficient_quota, limit_source: upstream_provider_shared_pool. Le statut indiquait un throttling, mais le corps signalait le quota d’un tiers.

Comment votre SDK traite-t-il un 429 ?

Cela dépend du SDK, et deux des plus utilisés ne font rien. Les comportements ci-dessous ont été vérifiés le 2026-09-04 directement dans le code source de chaque client officiel, pas dans sa documentation :

Trois conclusions s’imposent. D’abord, un 429 de Gemini, Vertex AI ou Mistral remonte à votre code dès la première occurrence si vous n’avez pas fourni d’options de retry. Dans le code source de google-genai, le commentaire indiquant que le client « will retry 4 times » décrit la configuration activée, pas le comportement par défaut. Ensuite, les plafonds appliqués à Retry-After vont à l’encontre des longues attentes réellement demandées par les fournisseurs. Si Anthropic demande d’attendre 90 secondes, son SDK ignore le header et revient en moins de 8 secondes. Si OpenAI en demande 150, son SDK arrête complètement les retries. Enfin, les SDK générés par Stainless, le générateur de code utilisé par les clients OpenAI, Anthropic et Groq, appliquent d’abord le header non documenté x-should-retry, avant même d’examiner le statut HTTP. Ils lisent aussi retry-after-ms avant retry-after. Un fournisseur ou une gateway peut donc piloter les retries sans modifier le code de statut.

Aucun de ces SDK ne distingue un 429 lié au plafond de dépenses d’un throttling. Deux retries sur une réponse insufficient_quota ne coûtent que quelques secondes chacun. À l’échelle d’une flotte, ils créent pourtant un pic de trafic entièrement évitable.

Que change une gateway ?

Une gateway centralise ce traitement. Côté upstream, elle lit les headers propres à chaque fournisseur. Les trois formats de reset et les quatre significations d’un 429 deviennent son problème, plutôt que celui de chaque client. Côté downstream, elle expose un jeu de headers et un format d’erreur uniques, comme les headers Synthorai mesurés plus haut. Elle ne peut toutefois pas modifier la comptabilité du fournisseur : derrière OpenAI, le max_tokens du client est toujours débité du TPM dès le départ ; derrière Bedrock, un token de sortie Claude en consomme toujours dix. Si une gateway mutualise plusieurs clients sur une même clé fournisseur, elle atteint aussi la limite d’accélération de ce fournisseur plus vite que ne le ferait un client isolé. Il faut donc des buckets par clé, pas un compteur partagé unique.

FAQ

max_tokens compte-t-il dans la limite de débit ?

Oui sur OpenAI, Azure OpenAI et Bedrock : max_tokens est débité à l’arrivée de la requête. Une valeur surdimensionnée gaspille donc du TPM, même si la réponse est courte. Bedrock corrige la déduction à la fin de la réponse. Non sur Anthropic : l’OTPM compte les tokens réellement générés et max_tokens « does not factor » dans ce calcul.

Les tokens en cache comptent-ils dans la limite de débit ?

Pas sur Anthropic, Bedrock ni les déploiements Azure PTU, où les lectures du cache sont exclues. Sur xAI, ils comptent intégralement. OpenAI et Gemini ne le précisent pas.

Retry-After est-il toujours envoyé avec un 429 ?

Non. OpenAI, Azure sous la forme retry-after-ms, et Groq l’envoient en cas de throttling. Anthropic l’envoie aussi pour le throttling, mais pas pour un plafond de dépenses. Kimi et Bedrock ne l’envoient qu’en cas de surcharge. Gemini, Vertex AI, xAI, Alibaba, DeepSeek et MiniMax n’en documentent aucun. Le client doit donc gérer son propre backoff pour ces fournisseurs.

Pourquoi mon SDK n’a-t-il pas retenté un 429 ?

Avec le SDK Python Google GenAI ou Mistral, les retries sont désactivés par défaut. Il faut fournir retry_options ou un RetryConfig. Avec le SDK Python OpenAI, si le serveur demande plus de 120 secondes d’attente, le SDK choisit de ne pas retenter. Si le 429 correspond à un quota ou à un plafond de dépenses plutôt qu’à un throttling, l’absence de retry est le bon comportement.

À lire aussi : guide des unités de facturation, tarifs des longues fenêtres de contexte, anatomie de l’utilisation des tokens, audit du cache d’une gateway.

← Retour au blog