Capacité dédiée et débit provisionné
Mis à jour le 28 juillet 2026
Réserver de la capacité plutôt que la partager
Le débit provisionné, ou Provisioned Throughput, constitue le pilier technique de l’offre Enterprise de xAI. Le principe tient en une phrase : vous réservez une capacité de traitement dédiée pour vos modèles Grok, et vos performances cessent alors de dépendre de la charge globale de la plateforme. Toute la valeur du mécanisme se joue dans cette indépendance, et c’est en la comprenant que l’on décide correctement de l’activer ou de s’en passer.
Ce que vous subissez sans capacité réservée
En mode pay-as-you-go, vos requêtes partagent l’infrastructure avec l’ensemble des autres utilisateurs de l’API. La plupart du temps, cela ne se voit pas. Le problème surgit pendant les pics de demande, et vos équipes d’exploitation en reconnaîtront immédiatement les symptômes. Les temps de réponse s’allongent, mais surtout ils deviennent variables — ce qui est bien pire qu’une lenteur constante, car une interface conçue pour une réponse en deux secondes se comporte mal quand elle en met parfois huit. Des erreurs de rate limiting apparaissent ensuite, renvoyées avec le code 429, et votre application doit alors gérer des réessais qui allongent encore la latence perçue par l’utilisateur. Des dégradations ponctuelles de disponibilité peuvent enfin affecter le service au moment précis où la demande est la plus forte.
Le débit provisionné supprime cette exposition. Vos requêtes sont traitées sur une capacité qui vous est réservée, avec une priorité garantie et des temps de réponse nettement plus consistants. Vous ne déplacez pas seulement un coût, vous déplacez un risque : celui de la performance passe de votre application vers le fournisseur.
Le raisonnement en unités
La capacité s’achète par unités, et cette notion reviendra dans toutes les leçons suivantes. Chaque unité correspond à une allocation de tokens par minute — le TPM — pour un modèle donné. Point décisif pour vos calculs : les unités d’entrée, qui traitent vos prompts, et les unités de sortie, qui produisent les réponses, s’achètent séparément.
La grille tarifaire, en revanche, est d’une simplicité désarmante : 10 dollars par unité et par jour, quel que soit le modèle. Ce n’est donc jamais le prix de l’unité qui varie d’un modèle à l’autre, mais le nombre de TPM que cette unité vous procure. Un modèle très puissant vous en donnera peu, un modèle plus léger beaucoup plus, et c’est de cet écart que naîtront les différences de coût considérables que nous chiffrerons dans deux leçons.
Décider si vous en avez besoin
Une application en production soumise à des exigences de latence strictes relève exactement du problème que ce mécanisme résout, et n’a donc guère à hésiter. Le support client automatisé se trouve dans la même situation, avec un argument supplémentaire : chaque seconde d’attente s’y traduit par un abandon ou par un appel entrant qu’il faudra traiter autrement. Le traitement en temps réel de volumes importants et prévisibles est un bon candidat lui aussi, la prévisibilité rendant ici le dimensionnement fiable. Et de façon plus générale, toute application dont l’interruption a un coût élevé, chiffrable en euros ou en réputation, justifie qu’on lui réserve de la capacité.
Le raisonnement inverse est tout aussi utile à tenir. Un traitement batch nocturne sans contrainte de temps n’a rien à gagner à une capacité réservée : qu’il s’achève à trois heures ou à quatre heures du matin ne change rien, et le pay-as-you-go reste alors franchement plus économique. Même conclusion pour le prototypage et les faibles volumes. Si vous hésitez encore, posez-vous une question précise avant d’engager 30 jours : sur les trente derniers jours, combien d’heures par jour ce service a-t-il réellement tourné à pleine charge ? Une réponse honnête tranche presque toujours le débat.
Points clés à retenir
- Le débit provisionné réserve une capacité dédiée à $10 par unité par jour
- L’engagement minimum est de 30 jours
- Le SLA de 99.9% est garanti contractuellement
- Les performances sont constantes indépendamment de la charge globale de la plateforme
- Le pay-as-you-go reste préférable pour les faibles volumes et le prototypage