Calcul des coûts et exemple concret

La formule

Tout le dimensionnement du débit provisionné tient dans une addition. Le coût quotidien s’écrit :

Coût quotidien = (Unités entrée + Unités sortie) x $10

Reste à déterminer combien d’unités il vous faut, ce qui dépend de vos besoins en TPM et de l’allocation propre au modèle retenu :

Unités entrée = TPM entrée souhaité / TPM par unité du modèle (arrondi au supérieur)
Unités sortie = TPM sortie souhaité / TPM par unité du modèle (arrondi au supérieur)

L’arrondi au supérieur n’est pas un détail comptable. Vous ne pouvez pas acheter un tiers d’unité : dès que votre besoin dépasse d’un seul token par minute un multiple de l’allocation, vous payez l’unité entière. L’exemple qui suit montre ce que cela représente sur une facture réelle.

Un cas complet : grok-4.3

Prenons une application de support client qui exige 100 000 TPM en entrée et 50 000 TPM en sortie sur le modèle grok-4.3, et déroulons le calcul étape par étape.

Ce modèle offre 31 500 TPM d’entrée par unité, d’où le nombre d’unités d’entrée :

100 000 / 31 500 = 3,17 → 4 unités (arrondi au supérieur)

Capacité réelle obtenue : 4 x 31 500 = 126 000 TPM d’entrée. Observez l’effet de l’arrondi : vous payez pour 126 000 TPM alors que vous en demandiez 100 000. Ces 26 000 TPM excédentaires ne sont pas perdus, ils constituent votre marge d’absorption des pics, mais ils figurent bel et bien sur la facture.

Côté sortie, l’allocation est de 12 500 TPM par unité :

50 000 / 12 500 = 4,00 → 4 unités

Capacité réelle obtenue : 4 x 12 500 = 50 000 TPM de sortie. Ici, le besoin tombe juste sur un multiple de l’allocation et aucune capacité n’est perdue. Simple coïncidence arithmétique, mais elle illustre un réflexe utile : vérifier si un léger ajustement du besoin déclaré vous fait franchir ou non un seuil d’unité.

Il ne reste qu’à additionner :

Coût quotidien = (4 + 4) x $10 = $80/jour
Coût sur 30 jours = $80 x 30 = $2 400

Le comparer au pay-as-you-go

Ce montant ne veut rien dire tant que vous ne l’avez pas confronté au coût du même volume en facturation à l’usage. Supposons que vous consommiez effectivement 100 000 TPM d’entrée pendant 8 heures par jour, 22 jours ouvrés dans le mois :

Tokens entrée mensuels = 100 000 x 60 x 8 x 22 = 10,56 milliards de tokens

Le coût correspondant dépend ensuite du tarif au token du modèle, que vous appliquerez à ce volume. Si le débit provisionné revient moins cher, la décision est prise. Le prix n’épuise cependant pas la question : la capacité réservée se justifie aussi lorsque vous l’utilisez de manière soutenue, plus de six à huit heures par jour, lorsque des temps de réponse garantis conditionnent l’expérience utilisateur, lorsque les pics de trafic de la plateforme se répercutent visiblement sur votre application, ou lorsque le SLA de 99.9 % relève d’une exigence métier explicite. Chacune de ces raisons suffit à elle seule à justifier un surcoût.

Ce que coûte le mauvais modèle

Reprenons exactement le même besoin, cette fois sur grok-4.20-0309-reasoning, un modèle premium :

Entrée : 100 000 / 3 000 = 34 unités
Sortie : 50 000 / 700 = 72 unités
Coût quotidien = 106 x $10 = $1 060/jour
Coût sur 30 jours = $31 800

Même application, même volume, et une facture qui passe de 2 400 à 31 800 dollars sur trente jours. Pour un chatbot de support client, le modèle fast est très probablement suffisant et coûte 13 fois moins que le modèle premium. Retenez ce rapport : aucune optimisation de prompt, aucune négociation commerciale ne rattrapera jamais un facteur 13 gagné ou perdu au moment du choix du modèle.

Dimensionner sans se tromper

Pour votre premier provisionnement, démarrez modeste. Partez d’une estimation basse et ajustez à la hausse : il est plus confortable d’ajouter des unités que d’expliquer un dépassement budgétaire. Surveillez ensuite l’utilisation réelle à l’aide des métriques détaillées de consommation fournies par la Management API, qui vous diront en quelques jours si votre estimation initiale tenait la route. Prévoyez tout de même une marge de 20 à 30 % de capacité supplémentaire pour absorber les pics, faute de quoi une seule journée inhabituelle suffit à saturer l’allocation.

Sachez enfin que le filet de sécurité existe : les requêtes qui dépassent votre allocation retombent automatiquement en pay-as-you-go. Un dépassement ne provoque donc pas d’interruption de service, il produit une ligne supplémentaire sur la facture — ce qui reste, dans la plupart des contextes, le compromis souhaitable.

Points clés à retenir

• La formule est simple : (unités entrée + unités sortie) x $10/jour
• Arrondissez toujours au supérieur le nombre d’unités nécessaires
• Le choix du modèle a un impact majeur sur le coût : un facteur 13x entre fast et premium
• Le débit provisionné est rentable pour un usage soutenu (6+ heures/jour)
• Le fallback pay-as-you-go absorbe automatiquement les dépassements