Cloud Intelligence™
Comment valider l'attribution des coûts IA en production
Cette page est également disponible en English, Deutsch, Español, Italiano, 日本語 et Português.
About Gregory Wiedeman
Senior Cloud Architect I
Greg is a Cloud Architecture Strategist at DoiT International and holds an M.S. in Systems Engineering from Regis University. He specializes in cloud architecture, FinOps consulting, and technical advisory services—helping clients optimize infrastructure and make smarter build decisions. When he's not immersed in cloud cost strategies, he enjoys writing about AI governance for non-technical leaders, playing cornhole, or climbing Colorado's many 14ers.
My personal pageIl est facile de démontrer que l'on peut attribuer des coûts à l'IA, mais bien plus difficile d'accorder sa confiance à cette attribution.
Un dashboard peut afficher des tokens, des requêtes ou l'utilisation GPU ; toute la difficulté consiste à déterminer si ces chiffres correspondent au bon client, à la bonne fonctionnalité produit, à la bonne équipe ou au bon agent, et si les totaux concordent avec ceux auxquels la finance et l'engineering font déjà confiance.
Cet article présente une approche pratique pour vérifier l'attribution des coûts IA en production. L'objectif n'est pas de disposer d'un dashboard pleinement opérationnel dès le premier jour, mais d'établir une chaîne de preuves mesurable reliant l'activité runtime au contexte métier.
Commencer par définir ce que signifie "correct"
Avant de mettre en place un système d'attribution, il faut d'abord décider à quelles questions les résultats sont censés répondre.
Par exemple :
- Quel est le coût de fourniture du service, client par client ?
- Quelles fonctionnalités produit génèrent les dépenses de modèles les plus élevées ?
- Combien coûte l'exécution de chaque agent IA ?
- Quels workloads partagés sont à l'origine des coûts d'infrastructure ?
- Quelle part des dépenses dans le périmètre est aujourd'hui impossible à attribuer ?
Ces questions touchent à différents aspects de l'attribution : une approche au niveau de l'équipe peut suffire pour du showback, mais obtenir une vue par client exige des identifiants de tenant, des informations sur la fonctionnalité et une correspondance entre identifiants runtime et noms métier.
Avant même d'examiner les résultats, consignez par écrit vos critères de validation. Un plan de validation digne de ce nom doit préciser :
- Les workloads et fournisseurs inclus dans le périmètre
- Les dimensions qui doivent être visibles
- La source de vérité servant de référence
- La fenêtre temporelle comparée
- L'écart acceptable
- Le traitement des dépenses non attribuées
Attribute™ affecte la consommation runtime à différentes dimensions : équipe, namespace, workload, modèle, fonctionnalité, environnement, tenant ou client. L'essentiel est de choisir les dimensions qui répondent à la question métier, plutôt que de collecter toutes les étiquettes possibles.
1. Commencer par un workload au périmètre restreint
Ne commencez pas par valider l'ensemble de votre parc cloud. Démarrez plutôt avec un échantillon restreint et représentatif :
- Un service en production
- Un modèle ou une gateway
- Une fonctionnalité orientée client
- Un namespace Kubernetes
- Un compte de facturation ou un projet
Le périmètre étant restreint, tout écart peut être identifié, et l'équipe plateforme dispose ainsi d'un résultat de référence qu'elle pourra étendre par la suite.
Pour le premier test, capturez l'activité attendue de manière indépendante. Parmi les données de comparaison utiles :
- Données d'utilisation ou de facturation du fournisseur
- Compteurs de requêtes et de tokens de la gateway LLM
- Logs applicatifs
- Identifiants de tenant ou de client
- Métadonnées des workloads Kubernetes
- Utilisation GPU ou compute
Il n'est pas nécessaire que tous les systèmes emploient la même terminologie. L'objectif est simplement de comprendre comment ces différents systèmes s'articulent entre eux.
2. S'assurer que la clé d'attribution reste visible au runtime
Les échecs d'attribution commencent généralement avant le calcul du coût : au moment où la télémétrie est collectée, la clé d'attribution — c'est-à-dire l'identifiant qui permet de distinguer une occurrence d'utilisation d'une autre — peut être absente.
Pour chaque dimension cible, répondez à trois questions :
- Quel identifiant désigne le client, la fonctionnalité ou le tenant ?
- À quel endroit du chemin de requête cet identifiant apparaît-il ?
- Le collecteur runtime peut-il l'observer en continu ?
Par exemple, un identifiant client peut figurer dans une requête authentifiée, dans un en-tête de gateway, dans un attribut de connexion à la base de données ou dans un champ propre à l'application ; mais si l'identifiant n'existe que dans la mémoire de l'application et ne franchit jamais de frontière observable, il faudra recourir à une autre méthode d'intégration ou d'instrumentation.
C'est pourquoi la validation doit commencer par la capacité à observer la clé au runtime, et non par le total affiché sur un dashboard ; si la clé ne peut pas être observée de manière fiable, l'allocation en aval restera incomplète, même avec une couche de reporting soigneusement configurée.
Les tags ne peuvent pas suivre les dépenses IA à travers les GPU partagés et les gateways. Lisez AI Features Have a Visibility Problem pour comprendre pourquoi l'observabilité runtime surpasse l'instrumentation. Télécharger l'ebook →
3. Définir les limites de la collecte
Attribute™ collecte les données de consommation runtime au niveau du noyau grâce à eBPF (extended Berkeley Packet Filter, une technologie du noyau Linux conçue pour une observabilité à faible surcharge), sans aucune modification du code applicatif ni du SDK. La frontière de collecte reste toutefois déterminante.
Documentez :
- Les clusters, hôtes ou comptes couverts
- Les workloads inclus ou exclus
- Les systèmes d'exploitation et versions de noyau pris en charge
- Si le trafic est chiffré avant d'atteindre la frontière observable
- Si l'infrastructure partagée fait partie du périmètre de mesure
Avant toute modélisation de l'attribution, le processus d'onboarding de DoiT comprend une revue de la topologie des clusters, une vérification de la compatibilité du noyau et du système d'exploitation, une revue des exigences de sécurité et un examen du flux de télémétrie. Pour en savoir plus sur le modèle d'accompagnement, consultez la documentation de présentation d'Attribute.
Un énoncé de couverture utile ressemble à ceci :
La validation couvre le namespace d'inférence de production, la gateway auto-hébergée et les nœuds GPU associés, du lundi 00:00 UTC au mardi 00:00 UTC, en excluant le trafic de développement, les workloads batch et les connexions préexistantes.
Des frontières clairement définies évitent que les équipes considèrent un résultat volontairement partiel comme une anomalie, ou qu'elles attribuent un coût nul à une zone non mesurée.
4. Établir la correspondance entre identifiants et dimensions métier
La télémétrie runtime commence souvent par des identifiants techniques :
- Noms de pods
- IDs de conteneurs
- Noms de namespaces
- IDs de modèles
- Clés API
- IDs de tenants
- Noms de services
Les équipes finance et produit ont besoin de dimensions lisibles :
- Nom du client
- Fonctionnalité produit
- Unité métier
- Environnement
- Niveau tarifaire
- Équipe responsable
Veillez à ce que cette correspondance soit explicite et conservez-en une copie : notez qui en est responsable, la date de sa dernière mise à jour, et précisez ce qui se passe lorsqu'un identifiant n'a pas d'enregistrement métier correspondant.
Une table de correspondance doit comporter au minimum les colonnes suivantes, par exemple :
| Identifiant runtime | Dimension métier | Responsable | Date d'effet | Statut de validation |
|---|---|---|---|---|
tenant-4821 |
Acme / Search Assistant | Product Platform | 2026-09-01 | Confirmé |
tenant-5177 |
ExampleCo / Document Review | AI Applications | 2026-09-01 | Confirmé |
tenant-unknown |
Non mappé | Platform FinOps | 2026-09-01 | À investiguer |
La ligne non mappée est importante. La masquer donne l'illusion d'une attribution complète tout en supprimant les éléments nécessaires pour améliorer la couverture.
Envie de savoir quels clients vous coûtent le plus cher ? Téléchargez Cost Per Customer: A FinOps Field Guide to Multi-Tenant Cloud Attribution, avec des requêtes SQL prêtes à l'emploi pour AWS, Google Cloud et Azure. Télécharger le guide →
5. Rapprocher les trois vues d'une même activité
Une validation fiable compare au moins trois perspectives :
- Activité runtime — ce que le workload a appelé ou consommé
- Utilisation côté fournisseur ou gateway — ce que la plateforme rapporte en tokens, requêtes ou compute
- Coût attribué — la manière dont cette utilisation est affectée aux dimensions métier
Comparez la même fenêtre temporelle en tenant compte des décalages possibles : les exports de facturation peuvent être retardés, les compteurs de la gateway peuvent interpréter une requête différemment, et la télémétrie runtime peut observer les nouvelles tentatives ou les appels mis en cache autrement que la facture du fournisseur.
Deux métriques simples sont utiles :
Couverture = dépenses attribuées dans le périmètre / dépenses totales dans le périmètre
Écart = valeur absolue (total source - total attribué) / total source
Suivez ces métriques au jour le jour et par workload : un pourcentage global peut masquer un problème sérieux concernant un client ou une fonctionnalité en particulier.
En cas de divergence, classez-la au lieu de modifier immédiatement la règle d'attribution :
- Écart de périmètre
- Écart de fenêtre temporelle
- Délai de facturation du fournisseur
- Identifiant runtime manquant
- Identifiant non mappé
- Nouvelle tentative ou requête dupliquée
- Traitement mis en cache ou asynchrone
- Chemin de trafic non pris en charge
Ce travail de classification transforme un simple exercice de rapprochement en une série de tâches d'engineering ; l'exemple qui suit montre comment mener ce rapprochement jusqu'au bout avant d'aborder les cas limites.
Cloud bill shouldn't be a mystery
One platform for AI and Cloud optimization.
Exemple illustratif de validation
L'exemple ci-dessous est purement illustratif et ne repose sur aucun résultat client réel.
Une entreprise SaaS souhaite déterminer le coût de sa fonctionnalité de résumé de documents du point de vue de chaque tenant, les requêtes de cette fonctionnalité transitant par une gateway LLM partagée exécutée dans Kubernetes.
L'équipe définit une période de validation de 24 heures couvrant un namespace de production, une gateway et deux fournisseurs de modèles, puis compare les compteurs de tokens de la gateway, l'utilisation rapportée par les fournisseurs et les résultats d'Attribute™.
| Étape de validation | Résultat |
|---|---|
| Total fournisseur et gateway | 10 200 $ d'utilisation IA dans le périmètre |
| Dépenses attribuées à des tenants connus | 9 650 $ |
| Dépenses non mappées ou non attribuées | 550 $, soit 5,4 % du périmètre |
| Conclusion initiale | L'attribution est utile, mais pas encore complète |
Plutôt que de traiter l'écart comme une erreur de calcul, l'équipe l'examine et identifie deux causes :
- Le tenant lancé le plus récemment possède des identifiants runtime absents de la correspondance métier.
- Un workload batch utilise la même gateway, mais se situe hors du périmètre initial du namespace.
L'équipe ajoute la correspondance de tenant manquante, isole le workload batch, puis refait la comparaison avec des fenêtres temporelles alignées. Cette fois, la couverture atteint 99 % sur le périmètre défini de la fonctionnalité, le reste de l'écart s'expliquant par les délais de facturation du fournisseur.
Ce n'est pas le pourcentage en soi qui compte. L'équipe dispose désormais d'une explication cohérente du chiffre, d'une responsabilité clairement établie pour les dépenses non mappées, et d'une procédure de validation réutilisable à chaque ajout de nouveaux tenants, modèles ou workloads.
Des dépenses IA toujours non allouées ? Téléchargez 5 Reasons AI Costs Don't Add Up et découvrez pourquoi les tags et les SDK ne suffisent pas à combler l'écart. Télécharger l'ebook →
6. Tester les cas limites qui faussent l'économie unitaire
Une simple requête ne suffit pas : les systèmes IA en production présentent des comportements qui modifient le coût apparent d'une fonctionnalité ou d'un client. Testez au minimum :
- Les nouvelles tentatives après des erreurs du fournisseur
- Les réponses en streaming
- Les prompts ou réponses mis en cache
- Les requêtes batch
- Plusieurs modèles derrière une même gateway
- Le trafic généré par des humains et par des agents
- Les workloads GPU partagés
- Les connexions longue durée aux bases de données ou aux gateways
- Le basculement entre fournisseurs
Les workloads Java méritent une attention particulière : la visibilité eBPF au niveau du noyau ne suffit pas pour le trafic TLS chiffré au sein de la plateforme Java, et c'est pourquoi Attribute™ a développé un agent Java pour ce scénario. Pour connaître les modes de déploiement pris en charge, les limitations et les vérifications à effectuer après l'installation, consultez le Java Instrumentation Guide.
La validation ne consiste pas seulement à vérifier que le capteur fonctionne ; il s'agit aussi de s'assurer qu'il observe le trafic pertinent pour ce workload, tel que ce workload fonctionne réellement.
7. Maintenir la couverture comme contrôle permanent
La qualité de l'attribution évolue avec l'environnement : des lacunes peuvent apparaître après la validation du déploiement initial, à mesure que de nouveaux tenants, gateways, modèles, namespaces ou fonctionnalités sont ajoutés.
Mettez en place une revue récurrente qui vérifie :
- Les identifiants nouvellement observés sans correspondance
- Les dépenses affectées à une dimension inconnue ou partagée
- Les variations de la couverture attribuée
- Les variations inattendues du coût par requête ou par fonctionnalité
- Les workloads qui ont cessé de remonter des données
- Les écarts entre les totaux des fournisseurs et les totaux attribués
Considérez la couverture comme une métrique opérationnelle, et non comme un objectif atteint une fois pour toutes.
Checklist d'acceptation pratique
Avant de déclarer un déploiement d'attribution prêt pour la production, vérifiez que :
- Les questions métier et les dimensions associées ont été consignées.
- Le périmètre exact et la fenêtre temporelle sont clairement définis.
- L'identifiant cible est visible dans le chemin du trafic runtime.
- Les clusters, hôtes, comptes et workloads sont tous documentés.
- Les identifiants runtime portent des noms lisibles pour le métier.
- Les dépenses non mappées et non attribuées sont visibles.
- L'activité runtime est rapprochée des données du fournisseur ou de la gateway.
- Les nouvelles tentatives, le cache, le streaming et les workloads partagés ont été testés.
- Les workloads Java TLS ont été correctement évalués.
- Un responsable de la couverture et des écarts est désigné, avec un calendrier de revue.
Conclusion
L'attribution des coûts IA n'a de valeur que si les équipes lui accordent suffisamment de confiance pour prendre des décisions sur cette base.
Cette confiance naît d'un processus reproductible : définir la question, délimiter le périmètre, vérifier la visibilité runtime, relier les identifiants techniques au contexte métier, rapprocher les différentes vues, tester les cas limites en production et suivre la couverture dans la durée.
Attribute™ fournit la couche de mesure runtime pour l'IA et l'infrastructure partagée ; la qualité des résultats reste néanmoins déterminée par le modèle d'attribution, la frontière de collecte et le processus de validation associé.
Pour les équipes qui passent de factures IA agrégées à un coût par client, par fonctionnalité ou par agent, la validation n'est pas l'étape finale après le déploiement : c'est le système d'exploitation du programme de mesure.
