Mesurer le coût d’un système LLM : méthode de cadrage pour CTO

Mesurer le coût d’un système LLM ne consiste pas à multiplier un prix de token par un volume estimé. Une décision de cadrage défendable relie une requête métier complète aux composants réellement sollicités : modèle, contexte, recherche, outils, traces et infrastructure. Elle sépare ce qui varie avec l’usage de ce qui est facturé même sans trafic, puis compare les hypothèses aux compteurs observés.

En bref

Commencez par un parcours métier représentatif et mesurez ses étapes, pas seulement l’appel au modèle.
Conservez séparément les unités qui expliquent le coût : tokens d’entrée et de sortie, appels d’outils, documents récupérés, durée d’infrastructure et stockage.
Comparez les estimations et les coûts observés au même périmètre technique. Les fournisseurs signalent que les données de facturation peuvent arriver avec un délai.
Choisissez le modèle, le contexte et les limites d’exécution sur des preuves de qualité et de coût propres au cas d’usage. Il n’existe pas de coût universel par requête.

Cette méthode sert à préparer une décision technique et financière. Elle ne fournit ni prix de fournisseur, ni budget projet, ni promesse d’économie. Les prix, volumes, contraintes contractuelles et règles de données doivent être vérifiés pour chaque environnement.

Pourquoi le prix affiché du modèle ne suffit-il pas ?

Le modèle est un poste de coût important, mais il ne résume pas un système LLM. Une requête peut aussi mobiliser une couche de récupération documentaire, des embeddings, un reranking, des appels à des outils, une base de données, des traces, une passerelle de sécurité et une infrastructure disponible en permanence.

AWS distingue notamment les modèles managés, généralement facturés selon les tokens d’entrée et de sortie, des modèles auto-hébergés, dont le coût dépend davantage de l’infrastructure, du stockage et du réseau. La documentation Microsoft Foundry rappelle aussi qu’une application peut utiliser plusieurs services Azure et que la vue d’un modèle ne couvre pas nécessairement le coût de toute la solution.

La question de cadrage devient donc : « quel est le coût d’un parcours utile pour cet utilisateur, avec ce niveau de qualité et ces contrôles ? » Cette formulation évite de comparer un prix unitaire isolé à une facture qui inclut d’autres composants.

Quel parcours faut-il mesurer avant de chiffrer ?

Choisissez un ou plusieurs parcours qui correspondent au périmètre initial. Pour un assistant documentaire, il peut s’agir d’une question simple avec sources, d’une question qui exige plusieurs documents, d’une demande hors périmètre et d’une demande qui doit être refusée selon les droits d’accès. Pour un agent, ajoutez les parcours qui appellent un outil et ceux qui s’arrêtent avant une action à impact.

Pour chaque parcours, conservez une fiche de mesure :

la tâche utilisateur, le rôle et le résultat attendu ;
la version du système, du modèle, du prompt et de l’index ;
les sources ou outils autorisés ;
les étapes exécutées et leur durée ;
les unités consommées par étape ;
le comportement attendu en cas d’échec, de refus ou de dépassement de limite.

Ce même découpage facilite l’évaluation. Notre guide sur l’évaluation d’un RAG en production explique comment séparer récupération, réponse, latence, coût et accès pour ne pas attribuer un écart au mauvais composant.

Quels postes faut-il séparer dans le modèle de coût ?

Le tableau suivant est une grille de collecte, non une grille tarifaire. Les postes pertinents dépendent de l’architecture retenue.

Poste	Unités à observer	Question de cadrage
Inférence	Tokens d’entrée, tokens de sortie, appels par parcours	Quel modèle traite quelle tâche et avec quelle limite de réponse ?
Contexte et récupération	Documents récupérés, taille de contexte, appels de recherche ou reranking	Quel contexte est réellement nécessaire pour une réponse vérifiable ?
Outils et agents	Appels d’outil, étapes, erreurs, tentatives arrêtées	Quelles actions sont autorisées et quelles bornes arrêtent une boucle inutile ?
Données et infrastructure	Stockage, calcul, réseau, disponibilité, réindexation	Quel coût existe même sans requête et quelle capacité est nécessaire au périmètre ?
Observabilité et évaluation	Traces, rétention, exécutions de tests, alertes	Quelles preuves faut-il conserver sans collecter des données métier au-delà du nécessaire ?

Une même unité peut éclairer plusieurs décisions. La taille du contexte affecte par exemple le coût d’entrée, la latence et parfois la qualité. AWS recommande d’optimiser la longueur des prompts, la longueur des réponses et les variables qui influencent directement la consommation, tout en vérifiant que la fonctionnalité attendue reste satisfaite.

Comment construire une estimation qui peut être vérifiée ?

Une estimation utile explicite les hypothèses au lieu de produire un total unique. Commencez par définir une période, un périmètre d’utilisateurs et une distribution de parcours. Conservez ensuite les prix applicables à la date de l’estimation, la région ou le mode d’hébergement, ainsi que les unités facturées par chaque composant.

Pour les parties variables, utilisez une formule par parcours :

coût variable du parcours
= coût d’inférence
+ coût de récupération et de données
+ coût des outils appelés
+ coût de traces et d’évaluation imputable au parcours

Ajoutez séparément les coûts fixes ou semi-fixes : capacité réservée, infrastructure disponible, stockage minimal, services de sécurité, supervision ou support. L’objectif n’est pas de répartir artificiellement chaque centime. Il est de rendre visible ce qui change avec le trafic, ce qui change avec la complexité d’une requête et ce qui reste dû quand le trafic est nul.

Microsoft Foundry recommande de conserver le même périmètre de ressources lorsqu’on compare une estimation à un coût réel et d’enregistrer les écarts par service. La documentation précise également que les enregistrements de coût et d’usage peuvent arriver avec un délai : une réconciliation doit s’appuyer sur une fenêtre de tendance, pas sur une lecture minute par minute.

Comment instrumenter la mesure sans rendre les traces inutilisables ?

Une trace utile à l’analyse de coût relie une requête à ses étapes sans stocker plus de données métier que nécessaire. En pratique, il faut pouvoir retrouver une version du système, des compteurs d’usage, les services sollicités, la durée de chaque étape et le résultat d’exécution. Le contenu intégral d’une demande ou d’une réponse n’est pas indispensable dans tous les contextes et doit suivre les règles de protection des données de l’organisation.

La documentation Microsoft sur l’observabilité décrit des signaux tels que la consommation de tokens, la latence, les taux d’erreur, les scores de qualité et les traces des appels LLM ou d’outils. Utilisez ces signaux pour expliquer une variation, pas comme substitut à une règle de décision métier.

Pour un système RAG, ajoutez aussi les éléments qui permettent de distinguer une réponse coûteuse mais fondée d’une réponse coûteuse causée par une récupération inutile : nombre de documents, taille de contexte, reranking, filtres appliqués et résultat de la réponse. Les droits d’accès doivent rester une dimension de test, comme dans notre méthode pour cadrer un projet RAG d’entreprise.

Quelles décisions de conception peuvent réduire le coût sans dégrader le cas d’usage ?

Le bon levier dépend de la preuve observée. Il ne consiste pas à réduire chaque compteur sans regarder le résultat.

Dimensionner le modèle sur la tâche. AWS recommande d’évaluer des modèles plus petits avant de monter en capacité, puis de comparer la qualité obtenue au besoin réel. Cette décision doit être testée sur un jeu de cas représentatif.
Réduire le contexte au contenu utile. Mesurez la qualité de récupération avant d’augmenter mécaniquement le nombre de documents envoyés au modèle. Un contexte plus long peut augmenter le coût sans rendre la réponse plus vérifiable.
Borner les workflows agentiques. Définissez les actions autorisées, le nombre maximal d’étapes, les conditions d’arrêt et le chemin d’escalade. Une exécution qui tourne sans condition de sortie ne doit pas être considérée comme un simple problème de facture.
Évaluer le cache comme une hypothèse. AWS indique que le prompt caching peut réduire le coût des tokens d’entrée lorsque des composants longs et répétés sont réutilisés, sous réserve des conditions propres au modèle et au fournisseur. Mesurez les taux de hit et de miss, ainsi que la qualité et la latence, avant de retenir ce levier.
Réviser après chaque changement significatif. Un nouveau modèle, une nouvelle politique de récupération, un changement de corpus ou d’outil modifie les unités consommées. Comparez la version candidate à une référence plutôt que de déduire l’effet d’un seul tableau de bord.

Ces choix doivent rester compatibles avec les objectifs de qualité, de sécurité, de droits et d’exploitation. Le profil GenAI du NIST propose d’adapter la gestion des risques au contexte, aux exigences et à la tolérance au risque de l’organisation. Il ne prescrit pas un budget ni une architecture universelle.

Quel tableau de décision préparer pour le CTO ?

Un tableau court est souvent plus utile qu’une projection complexe. Il relie chaque hypothèse à une mesure et à une décision possible.

Hypothèse	Preuve à recueillir	Décision si la preuve manque
Le parcours répond à une tâche utile	Cas métier, règle de revue, réponse attendue	Réduire le périmètre ou revoir le cas d’usage
Le coût variable reste compris	Unités par étape et prix datés	Tester un autre modèle, contexte ou parcours
La capacité fixe est adaptée	Charges observées, disponibilité requise, coût des services	Ajuster l’architecture ou le niveau de service
Les contrôles ne sont pas contournés	Cas de refus, traces de décision, tests négatifs	Bloquer l’ouverture ou corriger le contrôle
L’exploitation peut détecter un écart	Métriques, alertes, responsable et procédure	Préparer l’exploitation avant d’élargir l’usage

Le résultat attendu n’est pas un nombre qui prétend rester vrai à long terme. C’est une base de comparaison que l’équipe peut mettre à jour quand le volume, le modèle, les données ou le périmètre changent. Pour la décision plus large de passage d’un prototype à un système exploité, consultez aussi les critères de go/no-go d’un système LLM.

FAQ

Comment calculer le coût par requête d’un système LLM ?

Mesurez une requête complète sur un parcours représentatif. Séparez l’inférence, le contexte et la récupération, les outils, les traces et la part pertinente de l’infrastructure. Conservez les unités et les prix datés pour pouvoir expliquer l’écart entre une estimation et les coûts observés.

Faut-il suivre les tokens uniquement ?

Non. Les tokens expliquent souvent une partie de l’inférence, mais un système LLM peut aussi entraîner des coûts de recherche, de stockage, d’outils, de calcul, de sécurité et d’observabilité. Les postes à suivre dépendent de l’architecture et du parcours métier.

Comment réduire le coût d’un RAG sans dégrader la réponse ?

Commencez par mesurer la récupération et la réponse sur les mêmes cas de test. Réduisez ensuite le contexte ou changez le modèle seulement si les preuves montrent que le résultat reste adapté au cas d’usage et aux règles d’accès. Ne remplacez pas une évaluation par une réduction de tokens.

Les données de coût en temps réel sont-elles toujours définitives ?

Non. Microsoft indique que les enregistrements de coût et d’usage peuvent être retardés selon l’ingestion. Utilisez les données proches du temps réel pour suivre une tendance opérationnelle et les données de facturation sur une fenêtre cohérente pour la réconciliation financière.

Méthodologie et sources

NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, publié en juillet 2024, consulté le 15 septembre 2026. Ce profil accompagne l’AI RMF et propose des actions à adapter au contexte, aux exigences et à la tolérance au risque.
Microsoft Foundry, Plan and manage costs, consulté le 15 septembre 2026. La documentation décrit l’estimation, le suivi, le périmètre de comparaison entre prévision et coûts observés, ainsi que les délais possibles de remontée des données de coût.
Microsoft Foundry, Observability in Generative AI, consulté le 15 septembre 2026. La documentation décrit notamment les métriques de tokens, latence, erreurs, qualité et les traces d’exécution.
AWS Well-Architected Framework, Generative AI Lens: Cost optimization, consulté le 15 septembre 2026. Le guide traite du choix du modèle, de la consommation de ressources et des limites de workflow.
AWS Well-Architected Framework, Right-size model selection to optimize inference costs, consulté le 15 septembre 2026.
AWS Well-Architected Framework, Implement prompt caching to reduce token costs, consulté le 15 septembre 2026.

La méthode présentée est une grille de cadrage pour des systèmes LLM d’entreprise. Elle ne contient aucun chiffre client, prix fournisseur, délai, SLA, promesse d’économie, de sécurité ou de conformité. Les hypothèses, les responsabilités et les règles de conservation des traces doivent être validées pour chaque organisation.

Vous devez relier un prototype LLM à un modèle de coût et d’exploitation défendable ? Décrivez votre périmètre à IgnitionAI. Un premier échange peut aider à identifier les parcours, les unités à mesurer et les décisions à documenter avant d’élargir l’usage.