RPM et TPM par modèle

Les deux métriques de limitation

L’API Grok ne mesure pas votre consommation avec un seul compteur mais avec deux, qui se déclenchent indépendamment : le RPM (requêtes par minute) et le TPM (tokens par minute). Vous pouvez être bloqué par l’un tout en étant très loin du plafond de l’autre. Point décisif pour la suite : ces deux compteurs sont tenus par modèle, si bien que vos limites sur grok-4.5 n’ont aucun effet sur celles de grok-4.3.

Cette distinction n’est pas un détail de documentation. Elle détermine la façon dont vous dimensionnez votre infrastructure, la façon dont vous répartissez la charge, et l’endroit exact où votre service commencera à renvoyer des erreurs le jour d’un pic.

Le RPM plafonne le nombre d’appels

Le RPM compte les appels, sans se soucier de leur taille : une requête de dix tokens et une requête de cent mille tokens pèsent exactement pareil. Pour les modèles texte, la limite standard s’établit à 1 800 RPM, soit trente requêtes par seconde. C’est confortable pour une application conversationnelle classique.

Le RPM devient le facteur bloquant dès que vos requêtes sont nombreuses et courtes. Un pipeline qui classe des tickets de support un par un, ou qui extrait trois entités par phrase sur un corpus de documents, épuisera son quota d’appels bien avant d’approcher son quota de tokens. Dans ce cas, la solution ne consiste pas à demander plus de RPM mais à regrouper plusieurs éléments dans un même appel.

Le TPM plafonne le volume traité

Le TPM additionne les tokens d’entrée et de sortie sur une minute glissante, avec une limite standard de 10 millions pour les modèles texte. Le comportement est ici exactement inverse du précédent : peu d’appels, mais très lourds.

Prenez un service d’analyse documentaire qui envoie des dossiers de 50 000 tokens chacun. Le RPM vous autoriserait 1 800 envois par minute, mais le TPM s’arrête à 200 documents : 200 × 50 000 = 10 millions. Vous saturez donc à un neuvième de votre capacité théorique en nombre d’appels, et aucun réglage de parallélisme ne vous fera dépasser ce mur.

Des limites propres à chaque modèle

Les plafonds ne sont pas les mêmes selon la nature du modèle appelé, et il faut connaître ces ordres de grandeur avant de promettre un débit à un client.

Ces valeurs correspondent au tier standard ; chaque montée de tier les relève proportionnellement.

Puisque les compteurs sont indépendants, saturer un modèle ne bloque pas les autres. Si grok-4.5 renvoie des 429, grok-4.3 continue d’accepter vos requêtes comme si de rien n’était. C’est un levier de débit souvent négligé : plutôt que d’attendre un relèvement de quota, orientez les tâches simples — classification, extraction, résumé court — vers un modèle moins sollicité, réservez grok-4.5 aux raisonnements réellement complexes, et laissez à grok-4.20-multi-agent-0309 les flux qui orchestrent plusieurs sous-agents. Le débit global de votre plateforme devient alors la somme de plusieurs quotas au lieu d’un seul.

Surveiller sa consommation sans header dédié

L’API Grok ne renvoie, dans ses réponses, aucun header indiquant ce qu’il vous reste de RPM ou de TPM. Autrement dit, rien ne vous préviendra de l’approche du plafond : le seul moyen de savoir où vous en êtes consiste à tenir la comptabilité vous-même, côté client.

Ce suivi repose sur trois éléments : un compteur de requêtes par minute et par modèle, un compteur de tokens alimenté par l’objet usage que chaque réponse contient, et un seuil d’alerte déclenché autour de 80 % des limites. Ce dernier point est le plus important : une alerte à 80 % vous laisse le temps d’arbitrer — répartir la charge, lisser les envois, provoquer une montée de tier — alors qu’une alerte à 100 % ne fait que constater l’incident en cours.

Points clés à retenir

• Les limites se mesurent en RPM (requêtes/minute) et TPM (tokens/minute)
• Les modèles texte offrent 1 800 RPM et 10M TPM en standard
• Chaque modèle possède ses propres limites indépendantes
• Répartir la charge entre modèles permet de multiplier le débit effectif
• Implémentez un suivi côté client pour anticiper les limites