Parce qu'une inférence a deux régimes physiques distincts. Le prompt est lu en une seule passe parallèle, qui sature le processeur. La réponse s'écrit token par token, en relisant tous les poids du modèle à chaque fois, sur un processeur inactif 88 % du temps.
La mesure : 6,05 × 10⁻⁵ Wh par token d'entrée contre 2,13 × 10⁻³ Wh par token de sortie, soit un facteur d'environ 35. Le prix, lui, n'affiche qu'un facteur 5.
Les deux phases d'une inférence
Tout appel à un modèle, quel qu'il soit, passe par les deux.
Le prompt entier est disponible d'un coup, donc tous les tokens traversent le réseau en parallèle, en une seule passe. Les multiplications sont des matrices contre des matrices, ce que le matériel adore.
Le prefill est compute-bound : le goulot est le nombre d'opérations arithmétiques. C'est le seul régime où réduire la précision numérique fait gagner de l'énergie.
Un seul token entre, et il faut relire l'intégralité des poids du modèle pour en produire un seul. Les multiplications deviennent matrice contre vecteur. On lit des dizaines de gigaoctets pour quelques milliards d'opérations.
Le décodage est memory-bound : le goulot est la bande passante mémoire, pas le calcul. Sur un H200, plus de 88 % des unités de calcul restent inactives et la puce ne tire que 137 à 300 W sur un budget de 700 W.
| Prefill | Décodage | |
|---|---|---|
| Entrée traitée | tout le prompt | 1 token |
| Parallélisme | total | nul, séquentiel par construction |
| Goulot physique | le calcul | la bande passante mémoire |
| Utilisation GPU mesurée | 95,7 à 97,9 % | 28,6 à 56,9 % |
| Puissance tirée (TDP 700 W) | jusqu'à 684 W | 137 à 300 W |
| Effet d'un plafonnement de puissance | latence très dégradée | aucun, le plafond ne se déclenche jamais |
| Coût par token | faible | environ 35 fois le prefill, à lot unitaire |
Un repère qui frappe, mesuré par Sarathi-Serve (Agrawal et al., OSDI 2024, arXiv:2403.02310) sur Mistral-7B, un A100, avec un prompt de 1 024 tokens : le coût des opérations linéaires d'un seul token de décodage égale celui de 128 tokens de prefill.
Le chiffre, et d'où il vient
La mesure vient de Delavande, Pierrard et Luccioni, Small Talk, Big Impact (janvier 2026). Protocole : serveur dédié H100 SXM 80 Go sans tâche concurrente, mesure GPU par NVML et CPU par RAPL, LLaMA 3.1-8B en FP32, lot unitaire. Les deux phases sont isolées par soustraction, en comparant des générations d'un seul token à des générations complètes.
| Terme | Coefficient mesuré | Ce qu'il représente |
|---|---|---|
| Par token d'entrée | 6,05 × 10⁻⁵ Wh | lecture du prompt |
| Par token de sortie | 2,13 × 10⁻³ Wh | production d'un token |
| Terme croisé | 2,87 × 10⁻⁷ Wh/token² | relecture du contexte à chaque pas |
Le rapport entre les deux premiers vaut environ 35. Il n'est pas écrit tel quel dans le papier, il se dérive de ses deux coefficients publiés. Vellaisamy et al. (Carnegie Mellon), sur H200 et un autre protocole, retrouvent un ordre de grandeur de 30 à 80 selon les configurations comparées.
Les trois coefficients forment un seul modèle, celui que le papier ajuste :
E = A × T_entrée + C × T_sortie + D × T_contexte × T_sortie
Wh = Wh/tk × tk + Wh/tk × tk + Wh/tk² × tk × tk
La deuxième ligne est le contrôle d'homogénéité : chaque produit rend des wattheures, y compris le troisième, dont l'unité en token au carré n'existe que pour être multipliée deux fois.
Le troisième terme mérite qu'on s'y arrête. Il n'est pas un poste à part du décodage : c'est la partie du coût de décodage qui dépend de la longueur du contexte, quand C est la partie qui n'en dépend pas. À chaque token produit, le modèle relit le cache KV de tout ce qui précède, d'où le produit des deux longueurs. T_contexte est le contexte entier, tokens frais et tokens relus depuis le cache confondus, puisque la relecture ne fait pas la différence.
Son poids dépend entièrement du profil, à lot unitaire :
| Profil | Entrée | Sortie | Terme croisé |
|---|---|---|---|
| Chat court, 1 000 tokens pour 150 | 14 % | 76 % | 10 % |
| Chat long, 10 000 pour 500 | 20 % | 34 % | 46 % |
| Session d'agent, 126 180 pour 500 | 28 % | 4 % | 68 % |
C'est le sujet du chapitre sur le contexte long.
Le prix confirme l'écart, en beaucoup plus faible
| Fournisseur | Modèle | Entrée | Sortie | Ratio |
|---|---|---|---|---|
| OpenAI | gpt-6-astra | 10 $ | 50 $ | 5,0 |
| OpenAI | gpt-5 | 1,25 $ | 10 $ | 8,0 |
| Anthropic | Opus 5 | 5 $ | 25 $ | 5,0 |
| Anthropic | Sonnet 5 | 2 $ | 10 $ | 5,0 |
| Gemini 3.8 Flash | 0,75 $ | 3,75 $ | 5,0 |
Le marché converge sur 5, dans une fourchette de 4 à 8,3. La physique mesurée donne 35.
Les deux vont dans le même sens, avec un ordre de grandeur d'écart. Le prix intègre la marge, l'immobilisation de mémoire pendant toute la durée du décodage, la latence contractuelle et le positionnement concurrentiel.
Utiliser le prix comme proxy de l'énergie sous-estime donc le poids de la sortie d'un facteur 7. Ce proxy est le plus disponible et le plus faux du sujet. Il sert à classer des usages entre eux, pas à chiffrer une empreinte.
Question
Un client veut réduire l'empreinte de son assistant interne. Son équipe propose de compresser les prompts de 40 %. Quel gain maximal pouvez-vous annoncer sur un usage de chat classique ?
Choisissez une réponse pour voir l'explication.
Ce que ça change dans une recommandation
Trois conséquences directes, dans l'ordre où elles se posent en mission.
Le levier dépend du profil, et la plupart des équipes se trompent de profil. Sur du chat, la sortie pèse les trois quarts : contraignez la longueur des réponses, coupez le raisonnement quand la tâche ne le justifie pas, choisissez un modèle moins bavard. À tâche identique, deux modèles produisent des réponses de longueurs différentes, et cette verbosité n'apparaît dans aucune grille de comparaison.
Sur de l'agentique, la sortie tombe à quelques pour cent et le poids part dans la longueur de contexte relue à chaque pas. Le levier devient la taille du contexte porté d'un tour à l'autre, pas la concision des réponses.
Le batching, c'est au fournisseur de le gérer. Puisque le décodage est limité par la mémoire, traiter plusieurs requêtes dans la même passe amortit la lecture des poids. Le gain mesuré va de 17 à 25 fois entre un batch de 1 et un batch de 32. C'est le levier le plus puissant de toute la chaîne, et un client n'y a presque aucune prise, sauf à préférer une API mutualisée à une instance dédiée sous-chargée.
Optimisez les joules par tâche, jamais par token. Le piège est mécanique : les coûts fixes s'amortissent sur la longueur, donc l'énergie par token baisse quand on génère plus. Vellaisamy et al. mesurent sur Qwen3-8B et MATH-500, sur un H200, 7,46 J par token à 10 tokens de sortie contre 0,72 J à 512 tokens, alors que l'énergie de la requête entière est multipliée par 5. Un indicateur en joules par token récompense la verbosité.
FAQ
Un token de sortie coûte-t-il plus cher qu'un token d'entrée ?
Oui, environ 35 fois plus en énergie. La mesure de référence donne 6,05 × 10⁻⁵ Wh par token d'entrée contre 2,13 × 10⁻³ Wh par token de sortie sur un H100 avec un modèle de 8 milliards de paramètres à batch 1. Côté prix, les trois grands fournisseurs facturent la sortie 5 fois l'entrée en 2026, soit un écart bien plus faible que l'écart physique.
Pourquoi la génération d'un texte est-elle plus coûteuse que sa lecture ?
Parce que les deux phases n'ont pas le même goulot. La lecture du prompt traite tous les tokens en parallèle et sature les unités de calcul. La génération produit un token à la fois et doit relire l'intégralité des poids du modèle à chaque token, ce qui sature la bande passante mémoire et laisse plus de 88 % des unités de calcul inactives.
Peut-on utiliser le prix de l'API comme proxy de l'empreinte carbone ?
Pour classer des usages entre eux, oui. Pour chiffrer une empreinte, non. Le ratio de prix entre sortie et entrée est d'environ 5, quand le ratio d'énergie mesuré à lot unitaire est d'environ 35. Utiliser le prix sous-estime donc le poids de la sortie d'un facteur 7, et le prix intègre en outre la marge, la latence contractuelle et le positionnement commercial.
Réduire la longueur des prompts fait-il baisser l'empreinte ?
Modérément. Sur un usage de chat classique, l'entrée représente environ un quart de l'énergie totale, donc comprimer les prompts de 40 % fait gagner au mieux 10 %. Sur une session agentique, la part réellement compressible descend autour de 29 % de l'empreinte, ce qui plafonne le gain d'un compresseur parfait à moins d'un tiers.
Le plafonnement de la puissance des GPU réduit-il la consommation d'inférence ?
Presque pas, et c'est contre-intuitif. Pendant la génération, un H200 ne tire que 137 à 300 W sur un budget de 700 W, si bien qu'aucun plafond ne se déclenche jamais. Les mesures publiées concluent qu'un opérateur qui compte sur le seul plafonnement de puissance n'obtient aucune économie d'énergie sur cette phase.