Résumé

  • La documentation de GroqCloud mesure le débit en huit unités nommées, au niveau de l’organisation, puis renvoie chaque client aux réglages de son propre compte pour le chiffre qui s’applique réellement : la page publique est donc une convention de mesure avant d’être un plafond.
  • Deux signaux d’échec distincts sont publiés pour deux causes distinctes — 429 quand un débit mesuré est dépassé, 498 quand la capacité Flex est indisponible — et le document susceptible de transformer l’un ou l’autre en obligation contractuelle ne figurait pas parmi les pages retenues pour cette revue.

Une limite est une convention de mesure avant d’être un chiffre

La page des limites de débit commence par nommer ce qu’elle compte, non ce qu’elle autorise. L’extrait retenu indique : « Rate limits are measured in: RPM: Requests per minute RPD: Requests per day TPM: Tokens per minute TPD: Tokens per day ASH: Audio seconds per hour ASD: Audio seconds per day ITPM: Input tokens per minute OTPM: Output tokens per minute. »

Cette liste apprend davantage qu’un débit unique. Huit dimensions et non une seule signifient que l’enveloppe a huit parois. Deux d’entre elles sont libellées en secondes audio, ce qui indique que les modèles vocaux sont comptés sur une horloge différente de celle des modèles texte. Deux autres séparent la comptabilisation des jetons d’entrée et de sortie, ce qui compte parce qu’une charge dominée par les invites et une charge dominée par la génération puisent dans des budgets différents. Deux enfin sont journalières plutôt que par minute : une rafale peut donc être absorbée à court terme et épuiser la journée.

La même page fixe le niveau d’agrégation et la règle d’arbitrage dans ses propres termes : « Rate limits apply at the organization level, not individual users. You can hit any limit type depending on which threshold you reach first. » Elle précise aussi que « Cached tokens do not count towards your rate limits », ce qui constitue un allègement réel pour quiconque rejoue des invites à préfixe stable.

Rapprochez ces trois énoncés et la forme pratique de la contrainte apparaît. Dix services, cinq équipes et un rattrapage par lots derrière une seule organisation partagent une seule enveloppe. La paroi contraignante est celle qui cède la première, et aucune page publiée ne dit à un opérateur donné laquelle ce sera, puisque les chiffres ne s’y trouvent pas.

Le chiffre applicable est délégué à une page derrière authentification

La documentation ne laisse pas le lecteur sans direction. Telle qu’elle est rendue, la page indique que les limites peuvent comporter des exceptions et que les limites exactes en vigueur doivent être consultées sur la page des limites, dans les réglages du compte du lecteur. Cette instruction est la phrase la plus lourde de conséquences de tout l’ensemble, et c’est aussi pourquoi cette revue ne peut énoncer le seuil d’aucune organisation : la page vers laquelle elle renvoie se trouve derrière une authentification et n’a pas été lue ici.

Ce qui reste public est une convention assortie d’une instruction d’aiguillage. Une équipe peut apprendre les unités, le niveau d’agrégation et la règle d’arbitrage depuis le web ouvert. Elle ne peut pas apprendre son propre plafond depuis le web ouvert, et un tiers évaluant le service — analyste achats, journaliste, concurrent préparant un argumentaire de substitution — ne le peut pas davantage.

Un plan publie un socle ; les autres limites ne sont que qualifiées

Le catalogue de modèles est l’endroit où des chiffres apparaissent réellement, et il en délimite soigneusement la portée : « Need higher rate limits? Upgrade to Developer plan to access higher limits, Batch and Flex processing, and more. Note that the limits shown below are the base limits for the Developer plan, and higher limits are available for select workloads and enterprise use cases. »

Trois conséquences. Le tableau publié est un plancher pour un plan, non un plafond du service. Des limites supérieures sont décrites comme existantes pour des charges de travail sélectionnées non nommées et des cas d’entreprise, ce qui en fait une issue négociée plutôt que publiée. Et l’expression « base limits » concède une variance sans en énoncer les dimensions.

Cette concession explique l’importance du document tarifaire, et pourquoi son silence est un résultat. La page tarifaire retenue pour cette revue relève du positionnement — « Groq is the premier neocloud for fast inference … Fast or affordable is no longer a tradeoff. We're building hundreds of megawatts of capacity, with many more on the way » — sans tableau de plans, sans chiffres de limites et sans spécification des niveaux de traitement dans le texte lu. Quiconque cherche à établir, à partir des pages publiques de Groq, quel plan achète quelle enveloppe ne refermera pas la question sur cette page. La correspondance entre plan et limite n’est pas établie par les documents de cet ensemble.

Le plafond suit le modèle, et le modèle peut changer sous vos pieds

Parce que les limites sont présentées ligne par modèle, l’enveloppe est spécifique au modèle par construction. Un plan de capacité exprimé en un chiffre unique est donc sous-spécifié avant même que quoi que ce soit n’aille mal : changez le modèle servi et la contrainte change de forme.

Tel qu’il est rendu, le tableau du plan Developer affiche, parmi d’autres lignes, openai/gpt-oss-120b à 250K jetons par minute et 1K requêtes par minute. Ce chiffre est rapporté à partir du rendu fournisseur d’une ligne de tableau, non lu ici comme un tableau complet ; il vaut comme illustration du format, non comme spécification du service.

La même page ajoute une seconde forme de mobilité : les modèles en aperçu peuvent être retirés à bref délai. C’est un couplage documenté entre le catalogue et le plafond. Une charge calibrée sur une ligne d’aperçu hérite du cycle de vie de cette ligne, et aucun document de limites ne peut stabiliser une limite attachée à un modèle retirable.

Deux codes d’échec portent deux significations

La page des erreurs livre la moitié visible côté client en une phrase : « 429 Too Many Requests: Too many requests were sent in a given timeframe. Implement request throttling and respect rate limits. » Telle que la page des limites est rendue, un 429 est aussi le seul cas où un en-tête retry-after est positionné, et les en-têtes de limites exposés aux clients incluent x-ratelimit-limit-requests pour les requêtes par jour et x-ratelimit-limit-tokens pour les jetons par minute. Ces en-têtes constituent la seule preuve d’exécution dont dispose une application sur la paroi qu’elle approche.

La documentation de Flex Processing publie ensuite un second signal, très différent : « Flex Processing is a service tier optimized for high-throughput workloads that prioritizes fast inference and can handle occasional request failures. … If flex capacity is unavailable, requests will fail quickly with status 498 and error capacity_exceeded. » Flex est rapporté comme offrant des limites dix fois supérieures au niveau à la demande, au même prix, pour les clients payants, et la page des erreurs recense 498 comme un statut personnalisé dont la requête « ne sera pas traitée », sans facturation pour les requêtes renvoyant des codes d’erreur serveur.

Lus ensemble, 429 et 498 répondent à des questions différentes. 429 dit que l’appelant a dépassé un débit mesuré et doit ralentir. 498 dit que le fournisseur manquait de capacité pour cette classe de travail et que la requête n’a jamais été tentée. Une politique de reprise écrite seulement contre 429 traitera 498 comme un bruit, réessaiera immédiatement et créera une charge qui ne peut pas aboutir ; le comportement honnête d’un client face à 498 relève d’une décision de report, non d’un calcul de temporisation.

La documentation Batch affine cette distinction : elle décrit « an asynchronous batch of requests to Groq with 50% lower cost, no impact to your standard rate limits, and 24-hour to 7 day processing window ». Batch n’élève pas le plafond synchrone. Il retire du travail de ce plafond en changeant le contrat temporel sous lequel ce travail est acheté — une voie moins chère et plus lente contournant une paroi qui, elle, ne bouge pas.

Le document qui ferait de cette limite une obligation n’a pas été lu

La seule page de cet ensemble qui s’exprime dans le registre de l’obligation est le contrat de service, et son langage est un avertissement circonscrit au site : « YOUR USE OF THE WEBSITES (INCLUDING ANY THIRD-PARTY MATERIALS) IS AT YOUR SOLE RISK. THE WEBSITES … ARE PROVIDED ON AN “AS IS” AND “AS AVAILABLE” BASIS. … GROQ MAKES NO WARRANTY THAT (A) THE WEBSITES WILL MEET YOUR REQUIREMENTS, (B) THE WEBSITES WILL BE UNINTERRUPTED, TIMELY, SECURE, OR ERROR-FREE. » Un plafond de responsabilité de 100 dollars US pour les réclamations liées aux sites est également rapporté depuis cette page.

Deux limites doivent être posées nettement. Premièrement, cet extrait régit les sites web. Transposer un avertissement de garantie visant des sites vers un engagement de disponibilité d’API serait une erreur de catégorie, et cet article ne la commet pas. Deuxièmement, aucun contrat complet, bon de commande, contrat d’entreprise ni accord de niveau de service distinct n’a été obtenu pour cette revue. L’absence de pourcentages de disponibilité et de crédits de service dans un extrait est une information sur le texte effectivement lu, et sur rien d’autre.

La catégorie de document qui trancherait la question — un instrument de niveau de service signé, ou un bon de commande — relève de la négociation plutôt que de la publication, et c’est la première pièce qu’un acheteur sérieux doit réclamer.

Ce qu’une équipe peut planifier, et ce qu’elle ne peut pas

La surface de contrôle est banale et décisive. Les équipes d’ingénierie dimensionnent la concurrence, fixent les budgets de reprise et écrivent leur temporisation côté client à partir d’une limite publiée, qu’elles lisent comme une enveloppe opérationnelle. Le texte qui les lie réellement — la procédure de modification, la variation par modèle, les niveaux de report et la présence ou l’absence d’un engagement porteur de crédits — se trouve dans des documents que l’on ne lit presque jamais à côté du tableau des limites.

Lorsqu’un chiffre de centre d’aide est consommé comme un plafond contractuel, trois défaillances se suivent. La charge est dimensionnée sur un chiffre qui peut bouger. La logique de reprise est réglée sur une sémantique d’erreur que personne n’a vérifiée. Et l’écart apparaît en pointe de demande sous forme d’étranglement que le modèle de capacité de l’équipe ne contenait pas, au moment où la file a le moins de marge pour l’absorber.

Ce que cette revue peut affirmer avec assurance est plus étroit que le marketing, et plus utile. GroqCloud publie les unités, le niveau d’agrégation, la règle d’arbitrage, l’exclusion des jetons mis en cache, le socle d’un plan, une structure par modèle et deux codes d’échec dont un seul est assorti d’une consigne côté client. Dans les pages lues, il ne publie ni chiffre par compte, ni procédure de modification, ni tableau chiffré par modèle pour chaque plan, ni engagement de disponibilité assorti d’un remède.

Les sept documents ont été récupérés le 19 octobre 2026 ; aucun ne portait de date de publication ou de dernière modification, si bien qu’aucune date d’effet ne peut être attachée à une limite décrite ici.

Pour l’entité elle-même, voir la fiche du répertoire BTW consacrée à Groq Inc..