La métrique manquante entre les tokens et les dépenses cloud

Le problème n’est pas que les équipes IA manquent de données de coût. C’est que le tableau de bord des tokens et la facture cloud décrivent des systèmes différents, appartenant à des équipes différentes, sans moyen fiable de les relier.

Un agent de support peut résoudre un ticket après cinq appels de modèle, une étape de récupération, deux appels d’outil et une nouvelle tentative. L’entreprise enregistre un cas terminé. L’infrastructure enregistre un ensemble dispersé de requêtes, pods, mémoire, temps d’accélérateur et services partagés. Tant que ces enregistrements ne convergent pas, l’optimisation des coûts reste en partie une conjecture.

Pourquoi les métriques de tokens et les factures cloud racontent-elles des histoires différentes?

Le nombre de tokens est utile. Il indique la quantité de texte qu’un modèle a reçu et renvoyé, et il aide les équipes à comparer les invites, les modèles ou les choix de routage. Mais il ne révèle pas ce qui s’est passé autour de l’appel au modèle, la quantité de calcul qui a soutenu la récupération et l’utilisation d’outils, le nombre de tentatives échouées qui sont survenues en premier, ou si le résultat final a été utile.

Le State of FinOps 2026 montre à quelle vitesse l’IA s’est intégrée aux travaux FinOps ordinaires: 98 % des répondants gèrent désormais les dépenses d’IA, contre 63 % en 2025. Mais une ligne budgétaire plus importante ne vous indique toujours pas quel flux de travail a consommé l’argent ni pourquoi. 

Deux tâches de traitement de documents peuvent utiliser à peu près le même nombre de tokens. L’une peut se terminer avec une seule requête de modèle. L’autre peut récupérer du contexte depuis plusieurs dépôts, appeler un service externe, recourir à un autre modèle, puis relancer le document après une validation échouée que l’utilisateur ne voit jamais. Les totaux de tokens semblent similaires alors que les chemins d’exécution ne le sont pas.

Unite.ai a déjà examiné pourquoi token counts don’t automatically represent business value. L’étape suivante consiste à relier ces comptes aux charges de travail qui les ont générées. Sinon, une équipe peut améliorer le coût par token tout en aggravant le coût par tâche terminée.

À quoi ressemble une chaîne de coûts complète?

Une chaîne de coûts utile commence par le résultat qui importe à l’entreprise. Il peut s’agir d’un ticket de support résolu, d’un document traité, d’une modification de code acceptée ou d’un flux de travail d’agent terminé. Tout ce qui suit doit disposer d’une identité pouvant être suivie à travers le système.

La couche applicative fournit la première connexion. Un ID de requête, un ID de trace, un nom de flux de travail ou un ID de conversation peut relier plusieurs opérations de modèle et d’outil à une même tâche. Sans ce fil conducteur, dix événements liés ressemblent à dix frais indépendants.

Les OpenTelemetry conventions for GenAI agents offrent un vocabulaire émergent pour cette couche. Elles couvrent les opérations, les fournisseurs, les modèles demandés, les agents, les conversations, l’utilisation des tokens, l’exécution d’outils, les erreurs et les flux de travail. Les conventions sont encore indiquées comme en cours de développement, les équipes ne doivent donc pas les considérer comme une norme universelle achevée. Elles sont utiles car elles rendent le problème de corrélation concret.

Ensuite vient l’infrastructure. AWS split cost allocation data for EKS peuvent attribuer les coûts partagés de calcul et de mémoire aux pods Kubernetes et exposer des détails tels que le cluster, l’espace de noms, le déploiement, le nœud, le nom de la charge de travail et le type de charge de travail. Pour les instances accélérées prises en charge, les données couvrent également les réservations GPU, Trainium et Inferentia.

C’est l’autre moitié de la chaîne. Une trace peut expliquer ce que l’application a tenté de faire; l’allocation Kubernetes peut montrer quelles ressources ont porté le travail. Le guide d’Unite.ai sur deploying and monitoring LLMs on Kubernetes fournit le contexte de production plus large, incluant l’allocation des ressources, le dimensionnement et l’observabilité.

L’association ne se produira pas par accident. Les équipes ont besoin d’un identifiant stable qui persiste suffisamment longtemps pour relier la télémétrie de l’application aux étiquettes de charge de travail, aux enregistrements d’allocation ou à une autre couche de mappage. Les données client n’appartiennent pas aux balises Kubernetes. Les équipes doivent décider quels identifiants à faible cardinalité peuvent connecter en toute sécurité une catégorie de flux de travail, un service ou une fonctionnalité aux ressources qu’ils ont consommées.

Une fois ce contexte applicatif en place, les équipes peuvent commencer tracking Kubernetes costs by workload et à relier l’utilisation du namespace, du CPU, de la mémoire et du GPU au travail effectué. Cela ne vous indique toujours pas si le flux de travail a créé de la valeur commerciale, mais cela donne à la partie infrastructure du calcul quelque chose de concret à associer à. 

Quelle métrique d’unité l’entreprise doit-elle privilégier?

Il n’existe pas de métrique de coût IA unique que chaque équipe devrait utiliser. Le coût par token répond à une question de consommation du modèle. Le coût par pod répond à une question d’allocation d’infrastructure. Aucun des deux n’indique à un propriétaire de produit si la fonctionnalité est rentable.

Le meilleur dénominateur est généralement le plus petit résultat que l’entreprise peut définir clairement et que l’équipe produit peut influencer. Une opération de support pourrait suivre le coût par cas résolu. Un système de documents pourrait utiliser le coût par fichier traité avec succès, tandis qu’un assistant de codage pourrait examiner le coût par modification acceptée plutôt que le coût par suggestion.

Le succès modifie le calcul.

Un flux de travail avec un faible coût par tentative peut être coûteux s’il échoue souvent, déclenche des validations répétées ou envoie trop de cas à la révision humaine. C’est pourquoi les équipes doivent séparer le coût par tentative du coût par achèvement et, si possible, le coût par résultat accepté. Ce dernier chiffre est souvent le plus utile car il inclut le travail produit par le système que l’entreprise n’a pas pu exploiter.

Les systèmes d’agents compliquent cela car leurs chemins peuvent changer d’une exécution à l’autre. the economics of scaling agentic AI workloads couvrent le routage, les appels d’outil, les nouvelles tentatives et l’attribution au niveau du flux de travail. Ces comportements doivent être inclus dans la métrique d’unité lorsqu’ils consomment des ressources, même si l’utilisateur final ne voit qu’une seule réponse.

La métrique ne sera toujours pas parfaite. Les services partagés, les résultats en cache, les jobs batch et le traitement différé peuvent brouiller l’attribution. Une estimation utile à la décision vaut mieux qu’une précision illusoire, surtout lorsqu’elle indique aux ingénieurs quelle couche mérite d’être examinée.

Qui possède le chiffre?

La partie la plus difficile peut être organisationnelle. Les équipes ML comprennent les appels de modèle et l’évaluation. Les équipes plateforme comprennent les charges de travail et le comportement du cluster. FinOps comprend les données de facturation et les règles d’allocation. Les équipes produit savent quel résultat compte.
Aucune équipe ne possède la chaîne complète.

Cela crée un débat prévisible sur le tableau de bord qui est correct. L’équipe ML peut souligner une utilisation moindre de tokens, tandis que l’équipe plateforme voit les heures GPU augmenter et l’équipe produit constate moins de tâches terminées qu’auparavant. Les trois observations peuvent être vraies simultanément. La métrique partagée doit expliquer la relation entre elles.

Un point de départ fonctionnel est un flux de travail de production avec un événement de complétion clair. Lui attribuer un identifiant stable. Faire suivre ce contexte à travers les traces du modèle et des outils, le mapper au service ou à la charge de travail exécutée dans Kubernetes, et choisir un dénominateur commercial unique. Puis rassembler les équipes lorsque le chiffre évolue de façon inattendue.

Cette révision compte plus qu’un tableau de bord soigné. Une hausse soudaine peut provenir d’invites plus longues, d’un nouveau chemin de secours, d’une capacité GPU sous-utilisée, d’une politique d’autoscaling modifiée, ou d’une décision produit qui envoie davantage de travail via la fonctionnalité IA. Chaque cause appartient à un propriétaire différent.

L’automatisation doit venir plus tard. Un moteur de recommandation ne peut agir que sur les libellés et seuils qu’il reçoit, et un mauvais dénominateur peut faire paraître un système efficace comme gaspilleur ou récompenser un flux de travail bon marché que les utilisateurs rejettent. Les équipes ont besoin d’une visibilité partagée suffisante pour distinguer le comportement du modèle de la conception de l’application et de l’allocation d’infrastructure avant de laisser un système agir sur le résultat. Sinon, une correction automatisée des coûts peut réduire la capacité, augmenter la latence et déplacer la dépense vers un endroit moins visible.

La chaîne de coûts doit être partagée

Le contrôle des coûts IA restera fragmenté tant que chaque équipe n’optimisera que la couche qu’elle peut voir. Les tokens, les traces, les pods, les accélérateurs et les factures ne sont pas des mesures concurrentes. Ils sont des éléments de la même chaîne de coûts.

Les entreprises qui les relient n’obtiendront pas un chiffre parfait dès le premier jour. Ce qui importe, c’est que l’équipe puisse remonter une facture élevée jusqu’au flux de travail qui l’a engendrée, déterminer ce qui a changé et décider si le résultat justifiait le coût.