Le poids invisible du prompt : ce que consomme vraiment l'IA

Un soir, par simple curiosité, j'ai posé à une IA une question bête : combien consomme un GPU ? Pas pour un projet, pas pour un cours : juste parce que je me suis rendu compte que je n'en avais aucune idée. Je passe mes journées à envoyer des prompts, et je n'avais jamais réfléchi une seconde à ce que ça brûlait derrière.

La réponse m'a un peu refroidi. Une seule carte de datacenter récente (une H100) peut tirer jusqu'à 700 W en pleine charge.^[1] Un nœud de huit cartes, c'est près de 8 kW : de quoi alimenter une petite maison, pour faire tourner un seul modèle.^[2]

Et là, le réflexe d'ingénieur s'est réveillé. En I&C, en V&V, on passe son temps à dimensionner, à mesurer, à se demander ce qu'un système consomme et avec quelle marge. Sauf que pour l'outil que j'utilise le plus, ce réflexe, je ne l'avais jamais appliqué. Comme si le prompt était gratuit. Comme s'il ne pesait rien.

Il pèse pourtant quelque chose. J'ai voulu savoir combien.

I. L'illusion du cloud : un prompt n'est jamais gratuit#

Le mot « cloud » est une réussite marketing absolue. Il évoque quelque chose d'aérien, d'immatériel, d'infini. Or derrière le nuage, il y a du métal, du silicium, et surtout du courant. Beaucoup de courant.

Il faut d'abord distinguer deux régimes, parce qu'ils n'ont rien à voir :

• L'entraînement : on fabrique le modèle. Des milliers de GPU tournent pendant des jours, voire des semaines. C'est colossal, mais c'est ponctuel.
• L'inférence : on utilise le modèle déjà entraîné. C'est ce qui se passe à chaque fois que j'envoie un prompt. Pris isolément, c'est beaucoup plus léger : environ 0,24 Wh pour la requête texte médiane envoyée à Gemini, d'après les mesures publiées par Google.^[3]

0,24 Wh, c'est ridicule : moins que neuf secondes de télévision, selon Google, ou à peine une minute et demie d'une ampoule LED de 10 W. Sauf que ce chiffre est un piège, parce qu'on ne fait jamais un seul prompt. On en envoie des milliards par jour, à l'échelle de la planète. Et c'est là que le ridicule devient massif : ce n'est pas le coût unitaire qui compte, c'est le coût multiplié par un monde entier qui prompt en continu.

Le piège du chiffre brut, d'ailleurs, un ingénieur le connaît bien. Une carte affichée à 700 W de TDP ne tire pas 700 W en permanence : ça dépend de la charge, de la fréquence, de la taille du batch. Sur un nœud 8×H100 mesuré pendant un entraînement, le pic relevé tournait autour de 8,4 kW, pour 10,2 kW annoncés par le constructeur.^[2] Puissance max ≠ puissance réelle. Et la puissance du GPU seul ≠ la consommation du système : il faut y ajouter le refroidissement, l'alimentation, le reste de l'infrastructure. La facture réelle est toujours plus salée que la ligne « GPU » de la fiche technique. Google l'a chiffré pour Gemini : sur les 0,24 Wh de la requête médiane, les puces d'IA n'en consomment que 0,14. Le reste part dans les processeurs et la mémoire des serveurs, les machines gardées en réserve et le datacenter lui-même.^[3]

II. Côté hardware, l'efficience n'est pas un détail#

La bonne nouvelle, c'est que ce coût n'est pas une fatalité. Et la partie qui m'intéresse le plus, en tant que futur ingénieur, c'est ce qu'on peut faire au niveau matériel pour le réduire. Il y a plusieurs leviers, et certains sont spectaculaires.

Réduire la précision. C'est le levier le plus puissant. Un calcul en FP32 (virgule flottante 32 bits) coûte cher ; le même calcul en FP16, INT8 ou INT4 mobilise des unités arithmétiques bien plus simples, donc bien moins d'énergie. Les Tensor Cores sont justement optimisés pour ça. Les ordres de grandeur parlent d'eux-mêmes : en 45 nm, une multiplication entière sur 8 bits coûte environ 0,2 pJ, contre 3,7 pJ en flottant 32 bits, soit près de vingt fois moins.^[4] Chaque poids occupe en plus quatre fois moins de mémoire. À l'échelle du système, le gain de la quantification est plus modeste, puisque tout n'est pas du calcul, mais il reste réel, sans toucher une vis du matériel. De l'optimisation quasi gratuite.

Brider la puissance (undervolting, power capping). Sur les GPU serveur, on peut imposer une limite de puissance, avec une simple commande :

# Plafonner une H100 à 400 W au lieu de 700 W
nvidia-smi -i 0 -pl 400

Avec un plafond de puissance, le GPU baisse de lui-même sa fréquence et sa tension pour rester dessous. Des chercheurs du MIT ont mesuré environ 23 % d'énergie en moins en inférence pour 7 % de temps de calcul en plus,^[5] et près de 14 % d'énergie en moins en entraînement, pour un surcoût de temps comparable.^[6] Le rapport est assez favorable pour en faire l'un des premiers réglages à tester. Brider, c'est souvent plus malin que de pousser.

Maîtriser la thermique. Un GPU qui chauffe throttle et perd en rendement. Refroidissement liquide, immersion, meilleurs caloducs : au-delà du confort, c'est de l'efficience. Les gains sont indirects (moins de ventilateurs, fonctionnement plus stable), mais mesurables : dans un datacenter étudié par NVIDIA et Vertiv, refroidir environ 75 % de la charge par liquide a réduit la consommation totale du site de 10,2 %.^[7] Et ces gains s'ajoutent au reste.

Changer de matériel. Un GPU généraliste n'est pas le plus efficient pour l'inférence. Les puces spécialisées (ASIC type TPU, NPU) vont beaucoup plus loin sur un workload précis : le premier TPU de Google offrait 30 à 80 fois plus d'opérations par watt que le GPU et le CPU de son époque.^[8] L'écart s'est réduit depuis, les GPU ayant eux-mêmes gagné des unités spécialisées comme les Tensor Cores. C'est le levier le plus radical, mais aussi le moins souple : un ASIC fait une chose, très bien, et rien d'autre.

Ne pas gaspiller le reste. Deux postes qu'on oublie : la mémoire et l'ordonnancement. Aller chercher une donnée en mémoire coûte bien plus cher que de la traiter : toujours en 45 nm, lire 64 bits en DRAM coûte 1,3 à 2,6 nJ, plusieurs centaines de fois une multiplication flottante.^[4] D'où l'intérêt d'adapter la taille des batchs, d'exploiter la sparsité, de compresser les poids. Et laisser huit GPU allumés pour une tâche qui en demande un, c'est jeter de l'énergie par la fenêtre : le scheduling dynamique et la mise en veille des composants inactifs récupèrent ce gaspillage.

Ces chiffres viennent d'études différentes, sur des matériels et des charges différents : ce sont des ordres de grandeur, pas des gains qui s'additionnent.

Si je devais résumer en une phrase : les plus gros gains viennent du matériel spécialisé, combiné à la quantification et au bridage de puissance ; la thermique et la mémoire viennent ensuite, en complément.

III. Le vrai enjeu : la sobriété face à la course à la puissance#

Sauf qu'il y a un piège, et c'est le plus inconfortable. Tous ces gains d'efficience risquent d'être avalés par l'échelle.

C'est un vieux paradoxe, celui de Jevons : quand une ressource devient plus efficace à utiliser, on n'en consomme pas moins, on en consomme plus. Diviser par dix l'énergie d'un prompt ne réduira pas la facture mondiale si, dans le même temps, on multiplie par cent le nombre de prompts. Et c'est exactement la trajectoire actuelle : plus c'est efficace, plus c'est accessible, plus on en met partout.

Du coup, l'efficience matérielle est nécessaire, mais pas suffisante. La vraie question est en amont : a-t-on besoin de ce calcul ? Faut-il vraiment passer un modèle géant sur une tâche qu'un petit modèle, ou même un script, ferait très bien ? On retombe sur une logique d'ingénieur : dimensionner juste, pas surdimensionner par confort.

Et c'est là que ça me concerne directement. Dans quelques années, c'est ma génération qui va concevoir, déployer et dimensionner ces systèmes. Si on traite l'énergie comme une variable invisible (un truc qui se règle « ailleurs », chez l'hébergeur), on va reproduire la même erreur que partout : optimiser la performance, ignorer la conséquence. L'efficience énergétique devrait être une contrainte de conception, au même titre que la latence ou le coût. Pas une case qu'on coche après coup.

Conclusion : penser l'IA comme un ingénieur#

Je ne vais pas arrêter d'utiliser l'IA pour autant : je m'en sers tous les jours, et je continuerai. Mais depuis cette question bête sur la consommation d'un GPU, je ne vois plus le prompt de la même façon. Ce n'est pas une requête immatérielle qui part dans un nuage. C'est du courant qui passe dans du silicium, quelque part, maintenant.

Penser l'IA comme un ingénieur, c'est arrêter de la traiter comme magique. C'est se poser trois questions simples : de quoi ai-je vraiment besoin, quel est le coût réel, et est-ce que je peux faire pareil pour moins ? Mesurer avant de scaler. Préférer un modèle juste à un modèle géant. Savoir qu'un chiffre minuscule, multiplié par le monde entier, devient énorme.

Il y a quelque temps, je me suis demandé ce que coûtait à mon cerveau le fait de trop déléguer à l'IA. Aujourd'hui, je me pose la même question pour la planète. Même réflexe, autre échelle : derrière chaque facilité, il y a un coût. Le travail d'ingénieur, c'est justement de ne jamais le perdre de vue.

Ce qu'on ne mesure pas, on finit toujours par le payer.