Coût énergétique d'une requête LLM : 0,31 Wh à 300 tokens, 3,91 Wh à 5 000
Axel Morel · Fondateur & analyste, ProbansL'essentiel
Oviedo et al. (Joule, 2026) estiment la médiane à 0,31 Wh par requête à 300 tokens de sortie médians, et une médiane de 3,91 Wh à 5 000 tokens de sortie médians, sur un panier de trois modèles ouverts retenus selon un seuil de 200 milliards de paramètres. Ce sont des sorties de simulation Monte-Carlo, pas des mesures physiques. Avant toute comparaison avec une autre technologie, la longueur de calcul que l'on déclenche est déjà, à elle seule, une décision énergétique.
- Ce sont des sorties de simulation, pas des mesures physiques. Oviedo et al. (Joule, 2026) tirent 10 000 configurations aléatoires de trois paramètres, la longueur de sortie, la puissance du nœud et le rendement du centre de données, sur un nœud H100 de référence.
- Le facteur 13 sépare deux longueurs de sortie, pas deux modèles. La médiane passe de 0,31 Wh par requête à 300 tokens de sortie médians à 3,91 Wh à 5 000 tokens, sur le même panier de trois modèles ouverts : DeepSeek-R1 671B, Llama 3.1 405B et Llama 3.1 Nemotron Ultra 253B.
- 3,91 Wh n'est pas un plafond. Le papier chiffre à part DeepSeek-R1 seul à 10,6 Wh par requête (intervalle interquartile 4,29 à 21,7), et aucun modèle propriétaire n'est simulé.
Poser la question « combien coûte une requête à une IA, en énergie ? » suppose qu’il existe une seule réponse. Il n’y en a pas. Le chiffre le plus repris, 2,9 Wh pour une « requête ChatGPT moyenne », vient d’un commentaire de de Vries paru dans Joule en 2023. C’est précisément ce chiffre qu’Oviedo et al. (2026), parus dans la même revue, rangent parmi les valeurs surestimées d’un facteur 4 à 20. Ce n’est pas une mesure physique : c’est une simulation Monte-Carlo qui reconstruit la consommation à partir du débit de tokens, de la puissance d’un nœud et du rendement du centre de données. Sur un panier de trois modèles ouverts de plus de 200 milliards de paramètres, elle situe la médiane à 0,31 Wh par requête quand la sortie fait 300 tokens en médiane, et à 3,91 Wh quand elle en fait 5 000. Les auteurs chiffrent eux-mêmes ce passage, pour ces trois modèles et entre 300 et 5 000 tokens de sortie : la médiane « rises 13× ». Ce facteur 13 sépare donc deux longueurs de sortie sur les mêmes trois modèles. Il ne sépare ni deux classes de requêtes, ni deux catégories de produits, ni deux régimes en général.
- Le panier simulé est nommément composé de DeepSeek-R1 671B, Llama 3.1 405B et Llama 3.1 Nemotron Ultra 253B. Les deux médianes, 0,31 Wh et 3,91 Wh, portent sur ces trois modèles et sur aucun autre.
- Aucun modèle propriétaire n’est simulé. GPT-4o et Claude 3.5 Sonnet ne sont cités que pour justifier le seuil de 200 milliards de paramètres, pas comme objets de mesure, un seuil qui ne distingue pas architecture dense (Llama 3.1 405B, Nemotron Ultra 253B, où tous les paramètres sont actifs par requête) et architecture à mixture d’experts (DeepSeek-R1, 671B au total mais de l’ordre de 37B de paramètres actifs par token). Le nombre de paramètres actifs, pas le total, est ce qui rapproche le plus cette simulation d’une mesure de calcul engagé par requête, même si d’autres facteurs, la bande passante mémoire au décodage notamment, entrent aussi en jeu sans qu’aucune source citée ici ne les détaille.
- 3,91 Wh n’est pas un plafond. Le papier chiffre à part DeepSeek-R1 seul à 10,6 Wh par requête (intervalle interquartile 4,29 à 21,7).
Ce que l’estimation couvre, et ce qu’elle ne couvre pas
Ce que les données établissent. Les auteurs introduisent « a bottom-up framework estimating inference energy from token throughput, node power, and overhead under large-scale deployment assumptions ». Concrètement, ils tirent 10 000 configurations aléatoires de trois paramètres : la longueur de sortie, la puissance du nœud et le rendement du centre de données. La puissance du nœud est modélisée comme une loi log-normale centrée sur 0,7 fois la puissance maximale. Le rendement du centre de données est lui aussi une loi log-normale, entre 1,05 et 1,40 aux percentiles 5 et 95. Le matériel de référence est un nœud H100, avec 500 tokens d’entrée dans les deux régimes.
Les deux régimes sont définis par la longueur de sortie, et par elle seule. Le régime traditionnel correspond à une médiane de 300 tokens de sortie (intervalle interquartile 129 à 618), et donne 0,31 Wh par requête (intervalle interquartile 0,16 à 0,60). Le régime de test-time scaling correspond à une médiane de 5 000 tokens de sortie (intervalle interquartile 2 040 à 9 717), et donne 3,91 Wh par requête (intervalle interquartile 2,15 à 7,05), « with over 10 Wh in a significant portion of queries ». Ce test-time scaling est l’équivalent, dans le vocabulaire d’Oviedo et al., du test-time compute détaillé dans la fiche dédiée de ce dossier.
Ce que les données établissent. Le périmètre de comptage n’est pas celui des mesures auxquelles ces chiffres sont souvent comparés. Les auteurs le signalent : la plupart des mesures publiées portent sur la seule consommation des cartes graphiques, quand leur estimation vise le nœud entier et intègre le rendement du centre de données. Sont explicitement hors du périmètre l’orchestration entre nœuds, les appels d’outils, la gestion des contextes longs, et la consommation d’eau des centres de données, que ce papier ne mesure pas et sur laquelle je ne peux donc engager aucun chiffre. Les auteurs précisent aussi que les flux de travail agentiques peuvent être très hétérogènes, leur consommation pouvant être dominée par les appels d’outils ou par des appels parallèles plutôt que par une seule longue génération.
Ce que la méthode interprète. Je ne peux donc pas présenter ces deux valeurs comme le coût énergétique d’un assistant IA tel qu’on l’utilise au quotidien. Un agent qui appelle des outils, relit des fichiers et enchaîne des étapes sort du périmètre que les auteurs ont modélisé, et ils le disent eux-mêmes.
Ce que la méthode interprète. Google publie de son côté une mesure sur sa propre infrastructure de production (arXiv:2508.15734, 2025) et situe la requête texte médiane de Gemini Apps à 0,24 Wh. Je ne peux pas présenter ce chiffre comme une corroboration indépendante. Google est partie prenante sur exactement la question qu’elle documente, la population couverte n’est pas la même, et les deux chiffres ne sont pas du même type : une mesure interne d’un côté, une sortie de simulation de l’autre. Ce que j’en retiens est plus modeste, et ne vaut pas corroboration au sens strict : deux publications de nature différente placent une requête texte courte dans le même ordre de grandeur, celui du dixième de wattheure. La mesure de Google ne couvre en revanche pas les sorties longues.
Un écart entre deux longueurs de sortie, pas entre deux catégories de modèles
Ce que la méthode interprète. Le réflexe commun consiste à chercher un chiffre unique (« une requête IA coûte X ») pour ensuite le comparer à une activité du quotidien. Ce réflexe masque une variance qui existe déjà à l’intérieur du seul périmètre LLM, avant toute comparaison externe. Et cette variance ne tient pas à la marque du modèle. Dans la simulation, les trois modèles sont les mêmes des deux côtés. Ce qui change, c’est la longueur de la réponse produite : 300 tokens d’un côté, 5 000 de l’autre.
Une précision compte ici, parce qu’elle change ce qu’on peut faire de ce chiffre. Rien dans ce que publient les auteurs n’autorise à dire qu’un modèle réputé « de raisonnement » dépense 3,91 Wh quelle que soit la question. Sur une demande courte, il produit une sortie courte, et c’est l’autre distribution qui s’applique. Le levier n’est donc pas de trier les modèles une fois pour toutes, mais de savoir quelle longueur de calcul on déclenche, requête par requête.
Rapprochement que je construis ici. Le facteur 13 est écrit par les auteurs, mais c’est un rapport de médiane à médiane, et il ne fixe aucun plafond. Le rapport de 13 n’est qu’un point central, et ce qui suit est une extrapolation que je construis à partir des bornes publiées, pas un chiffre avancé par les auteurs : en croisant les bornes des intervalles interquartiles, ce rapport peut tomber vers 3,6 (0,60 Wh contre 2,15 Wh) ou dépasser 40 (0,16 Wh contre 7,05 Wh), ce qui interdit de le traiter comme un multiplicateur unique. Je le retiens comme ordre de grandeur central, et je précise à chaque fois qu’il s’agit d’un rapport entre médianes.
Consommation absolue et efficience : deux questions distinctes
Ce que la méthode interprète. Deux questions se cachent sous le mot « coût énergétique », et les confondre entretient une partie du débat public sur le sujet. La première est la consommation absolue : combien d’énergie une tâche donnée consomme-t-elle en valeur brute. La seconde est l’efficience : quel résultat obtient-on rapporté à cette dépense, pour la tâche visée. La source répond à la première, sous ses hypothèses. Elle ne répond pas du tout à la seconde.
Ce que les données établissent. Le papier ne mesure aucun taux de succès comparé entre une réponse directe et un raisonnement étendu, et aucun nombre d’itérations évitées. Aucune expérience, aucun tableau et aucune figure du document ne porte sur la qualité de la réponse selon le mode de calcul engagé.
Ce que la méthode interprète. Je ne peux donc pas écrire, sur la foi de cette source, qu’une sortie longue « rentabilise » son surcoût en évitant des tentatives ratées. C’est une intuition répandue, la mienne comprise, et elle n’a aucun appui ici. La seule chose que je peux dire est que la question « pour quoi faire » reste ouverte, et que cette source ne la tranche pas.
Et l’entraînement ? Un ordre de grandeur à part
Ce que les données établissent. Les chiffres qui précèdent portent sur l’inférence, c’est-à-dire l’utilisation d’un modèle déjà entraîné pour répondre à une requête. L’entraînement est une dépense distincte, engagée une seule fois avant toute mise en service. Patterson et al. (2021) chiffrent l’entraînement complet de GPT-3 à environ 1 287 000 kWh. Cela représente plus d’un milliard de wattheures pour un seul cycle d’entraînement.
Ce que la méthode interprète. Cette dépense se compare mal, terme à terme, aux deux médianes citées plus haut. Ce ne sont pas les bornes d’une requête individuelle : ce sont deux valeurs centrales, dont les intervalles interquartiles débordent des deux côtés. Le coût d’entraînement, lui, est amorti sur l’ensemble des requêtes traitées par le modèle pendant toute sa durée de service, potentiellement des milliards de requêtes. Un coût d’entraînement élevé peut ainsi correspondre à un coût d’inférence par requête très inférieur, une fois ramené à l’échelle de l’usage réel.
Un facteur 13 sépare, dans cette estimation, deux longueurs de sortie sur les mêmes trois modèles. Avant toute comparaison avec une autre technologie, la longueur de calcul que l’on déclenche est déjà, à elle seule, une décision énergétique.
Ce que la source recommande vraiment : pouvoir couper le raisonnement
Ce que les données établissent. La source ne recommande pas de basculer en raisonnement étendu. Elle documente l’économie inverse. Sur les modèles qui permettent d’activer ou de désactiver explicitement le raisonnement, les auteurs estiment que cette bascule « can reduce per-query energy by 5x or more », par simple réduction de la longueur de la requête. Leur conclusion pousse dans le même sens : beaucoup de tâches n’exigent pas les modèles les plus consommateurs, la performance montrant des rendements décroissants au-delà d’une certaine taille de modèle ou d’une certaine quantité de calcul au moment de la réponse.
Ce que les données établissent. Les deux seuls repères de qualité cités dans le papier viennent de travaux tiers, pas de mesures des auteurs. Un routage intelligent entre modèles, cité par Oviedo et al. d’après des travaux tiers non nommés dans le papier, a maintenu 97 % de la qualité de réponse pour un coût divisé par 2 à 4, sans que le papier précise si ce coût est mesuré en wattheures ou selon une autre unité. Un filtrage dynamique des traces de raisonnement de faible qualité, la méthode DeepConf, a atteint jusqu’à 99,9 % de précision avec une longueur de requête divisée par environ 5.
Ce que la méthode interprète. Aucun de ces deux repères ne compare une réponse directe et un raisonnement étendu à tâche égale. Ce que la source autorise à retenir est donc plus simple, et va dans le sens opposé à celui qu’on lui prête souvent : la seule économie qu’elle chiffre est celle qu’on obtient en coupant le raisonnement quand la tâche ne l’exige pas.
Ce que la méthode interprète. Le simulateur plus bas ne produit pas un chiffre, en tout cas pas au sens d’un calcul précis. Il multiplie un volume de requêtes que vous déclarez par l’une des deux médianes, projette le résultat sur une année, puis le convertit en équivalences du quotidien avec des coefficients qui sont les miens, pas ceux de la source. Trois hypothèses empilées, donc, sur des médianes dont l’intervalle interquartile couvre déjà un facteur proche de 4. Ce qu’il rend est un ordre de grandeur sous hypothèses, à lire comme tel.
Mes réserves
- Les deux chiffres retenus ici sont des sorties de simulation, pas des mesures physiques. Les auteurs n’ont mesuré aucune requête : ils ont tiré 10 000 configurations d’hypothèses et publié la distribution obtenue. Ce sont aussi des médianes assorties d’un intervalle interquartile, pas des constantes.
- La population est beaucoup plus étroite que la formule « modèles frontières de plus de 200 milliards de paramètres », qui est pourtant bien celle des auteurs. Trois modèles ouverts entrent dans le panier, et aucun modèle propriétaire n’est simulé.
- Je dépends d’une source qui juge une autre de mes sources. Les auteurs écrivent que les estimations largement citées sont surestimées d’un facteur 4 à 20, et les publications visées sont nommées : de Vries (2023) à 2,9 Wh, AI Energy Score (2025) à 1,01 Wh sur Llama 3.1 70B, et une estimation de l’Agence internationale de l’énergie (2025) à 1,25 Wh sur Mixtral 8x22B. Une quatrième valeur de l’Agence internationale de l’énergie, 2,25 Wh sur DeepSeek-R1, est également citée par les auteurs parmi ces surestimations, mais elle est très inférieure aux 10,6 Wh qu’ils chiffrent par ailleurs pour DeepSeek-R1 seul : je ne la retiens pas dans cette liste, faute de pouvoir établir si les deux chiffres portent sur la même variante du modèle. Or de Vries est aussi la source que je cite pour le chiffre le plus repris du débat. Je ne peux pas présenter les deux comme compatibles : je cite l’un et celui qui le récuse. Le motif avancé est toujours le même, l’absence d’optimisations de production dans les protocoles visés, batching et accélération de l’inférence en particulier. J’ajoute que le papier n’explicite pas le calcul qui mène précisément aux bornes 4 et 20.
- Les huit auteurs sont salariés de Microsoft, qui exploite une part majeure de l’infrastructure d’inférence dont le texte estime la consommation. C’est la seule déclaration d’intérêts fournie, et aucun financement n’est déclaré. Le papier compare par ailleurs ses résultats à des publications de Google et d’OpenAI, partenaire de Microsoft, sans que ces relations soient mentionnées.
- Je ne compare pas ces chiffres à une recherche web, et ce renoncement n’est pas une prudence personnelle : les auteurs le formulent eux-mêmes. Ils qualifient le 0,3 Wh par recherche, issu d’une divulgation Google de 2009, de « coarse historical reference point », précisent que ce chiffre est daté et surestime probablement la réalité actuelle, et déclarent qu’à leur connaissance aucune divulgation publique plus récente n’existe.
- Je ne peux pas écrire qu’une sortie longue consomme toujours davantage. Le papier fournit deux distributions, pas une loi. Rapprochement que je construis ici : leurs intervalles interquartiles ne se recouvrent pas (0,16 à 0,60 contre 2,15 à 7,05), ce qui rend le sens de l’écart net sur ces deux régimes, sans pour autant valoir pour toute requête.
- Les auteurs déclarent leurs propres limites, et elles pèsent sur ce que j’en tire. La simulation porte sur un nœud unique à taux d’utilisation élevé, sans capturer l’orchestration entre nœuds ni la latence réseau. Elle suppose une distribution de longueurs de tokens idéalisée, qui peut différer des déploiements réels. Le coût de la phase de préremplissage sur les contextes très longs est modélisé de façon limitée, et serait nettement plus élevé sur des entrées de l’ordre de 100 000 tokens. Leur modèle de débit de tokens suppose par ailleurs un palier sur les générations très longues, alors que les systèmes réels montrent plutôt un déclin : les auteurs indiquent eux-mêmes que cela conduit probablement à sous-estimer la consommation dans ce cas, celui-là même du régime à 5 000 tokens de sortie retenu ici. Ils signalent enfin un effet rebond : des gains d’efficience peuvent augmenter la consommation totale, en autorisant plus d’usage et des générations plus longues.
- Le chiffre d’entraînement de GPT-3 (Patterson et al., 2021) porte sur un modèle antérieur à ceux que couvre l’estimation d’inférence citée ici. Les deux chiffres ne portent ni sur la même phase, ni sur le même modèle. Ils ne doivent donc pas être additionnés ou comparés terme à terme.
Retour au dossier Comprendre les modèles post-LLM. Voir aussi qu’est-ce qu’un LLM de raisonnement ? et Test-time compute : pourquoi certains modèles “réfléchissent”
I source primaire indépendante · S secondaire spécialisée · P partie prenante ayant un intérêt commercial sur le sujet traité.
Lexique
- LLM· Grand modèle de langage↗
- Modèle d'intelligence artificielle entraîné sur de vastes corpus de texte pour prédire et générer du langage, capable de tâches d'analyse, de synthèse et de génération de texte en langage naturel sans avoir été explicitement programmé pour la tâche demandée.
- Coût d'inférence↗
- Coût de calcul associé à l'utilisation d'un modèle déjà entraîné pour produire une réponse.
Modification apportée · mis à jour le 4 septembre 2026
J'ai ajouté un exemple concret de comparaison déjà en circulation (« 10x une recherche Google », de Vries 2023, ratio attribué à John Hennessy, président du conseil d'administration d'Alphabet), sourcé et daté par les mesures déjà citées, pour montrer que la recherche a bien été faite plutôt que de l'affirmer. J'ai aussi ajouté une grille de bascule en trois critères opérationnels dans le corps du texte, et pas seulement dans le simulateur externe, pour que l'article parle aussi aux praticiens déjà familiers de la distinction standard/raisonnement. Auparavant, j'avais redécoupé le fichier phrase par phrase et corrigé le chiffre de comparaison de How Hungry is AI : le 0,45 Wh contre 33,6-39,2 Wh était introuvable dans la source, je l'ai remplacé par 0,42 Wh pour GPT-4o et 33,8 Wh pour le modèle le plus consommateur de l'étude, ainsi que par le 29 Wh (65x) mis en avant par l'étude elle-même. J'ai depuis retiré le nom de modèle attaché à ce 33,8 Wh : l'identifiant du préprint que je cite renvoie à un dépôt de mai 2025, et je n'ai pas de version datée à citer pour rattacher ce chiffre à un modèle nommé. J'ai aussi ajouté l'adresse de la page officielle de l'Agence internationale de l'énergie pour la citation Energy and AI (2025), qui n'en portait aucune. J'ai ajouté deux encadrés en langue courante, l'un sur la façon dont ces valeurs sont obtenues, l'autre sur ce qui fait varier la dépense d'une requête à l'autre. J'ai retiré la mention d'une comparaison avec l'étude How Hungry is AI et d'un exemple chiffré (dix fois une recherche Google) que cette note annonçait comme intégrés au corps du texte : en les relisant, je n'ai pas retrouvé ces deux ajouts dans l'article publié, et je préfère l'admettre plutôt que de laisser croire qu'ils y figurent. J'ai précisé dès sa première apparition, pas seulement plus loin dans le texte, que le facteur 13 est un point central et non un multiplicateur fixe. J'ai nuancé le seuil de 200 milliards de paramètres, qui recouvre en réalité une architecture entièrement dense (Llama) et une architecture à mixture d'experts où seule une fraction des paramètres s'active par requête (DeepSeek-R1). J'ai retiré l'estimation de l'Agence internationale de l'énergie sur DeepSeek-R1 de la liste des estimations que les auteurs jugent surestimées, faute de pouvoir établir qu'elle porte sur la même variante du modèle que celle qu'ils chiffrent par ailleurs à 10,6 Wh pour DeepSeek-R1 seul. J'ai nommé Oviedo et al. plutôt que de les désigner par périphrase à deux endroits, et précisé que le chiffre de routage entre modèles cité dans le papier provient lui-même d'un travail tiers non nommé. J'ai enfin signalé que cette estimation ne couvre pas la consommation d'eau des centres de données, une dimension que je laisse hors du périmètre de cette pièce.
Développe une méthode d'analyse destinée à distinguer ce que les preuves établissent, ce qu'elles suggèrent et ce qu'elles ne permettent pas de conclure, puis à traduire cette distinction en décisions professionnelles.
Choix du sujet, direction de la rédaction, validation ou modification des sources, validation et retravail du texte et des illustrations : Axel Morel. Rédaction, choix des sources initiales et plan de rédaction initial : assistance IA.
Responsabilité éditoriale : Axel Morel. Recherche et rédaction assistées par IA selon la méthodologie Probans, sources vérifiées avant publication. Charte éditoriale.
En savoir plus