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

L'autre jour, 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. 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.

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.

Spoiler : il pèse quelque chose. Et c'est de ça que je veux parler.

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 — de l'ordre de 0,24 Wh pour une requête texte sur une infrastructure optimisée.

0,24 Wh, c'est ridicule. Quelques secondes d'une ampoule LED. 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é, on relevait environ 8,4 kW en pic alors que la capacité théorique frôlait les 10 kW. 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.

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. Sur de l'inférence, la quantification peut diviser la consommation par 4 à 10 — 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 — une simple commande :

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

On baisse la tension tout en gardant une fréquence stable. Résultat typique : −10 à −30 % de consommation pour seulement −5 à −15 % de performance. Le rapport est tellement favorable que les datacenters optimisés le font systématiquement. 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 — de l'ordre de 5 à 15 %, mais ils 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 — peuvent consommer 5 à 20 fois moins qu'un GPU classique sur un workload précis. 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. La VRAM (HBM) peut représenter 20 à 35 % de l'énergie du GPU — 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.

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 — ce serait absurde, et je serais le premier hypocrite. 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.