L’IA frugale

L’IA, c’est du logiciel connecté, qui génère du code en plus. Dès lors, l’IA est synonyme de plus grande consommation électrique.

Midjourney : L’IA frugale, peinture expressionniste abstraite, couleur Electric Lime --ar 16:9 

Remarque préalable

Nous sommes conscients, en nous attaquant à cette question, que notre propos est très situé dans un contexte mi-2023 et que la situation pourrait très vite évoluer. Les IA sont loin d'être stabilisées dans leur architectures et dans leurs fonctionnements.[1]

La plupart des discours sur l'IA se réfèrent implicitement à des systèmes centralisés et propriétaires. Or on a vu que DALL.E et Midjourney qui fonctionnent effectivement selon ce modèle ont très vite été rattrapés et même dépassés sur certaines échelles de performance technique, par des concurrents open source pouvant fonctionner sur de simples ordinateurs personnels. 

De même ChatGPT, centralisé lui aussi, open source en théorie, mais propriétaire dans les faits, est en passe d'être doublé par des concurrents véritablement open source pouvant être exécutés sur des machines aux capacités relativement limitées. Il est difficile de prévoir comment l'écosystème des IA open source pourrait évoluer mais il me paraît probable qu'elles démodent assez rapidement la plupart des discours et des tentatives de régulation qui ne considèrent que ces systèmes centralisés.

[1] Elles ne le seront probablement jamais, puisque beaucoup de nouvelles applications peuvent être développées, et on ne sache pas qu’il y ait une quelconque “main invisible” qui s’occupe de recoder toutes les vieilles applications pour les rendre conformes au nouveau standard. Les programmes logiciels s’additionnent le plus souvent, comme par sédimentation.

Croyance: l'IA pourrait être frugale voire propre

Il faudrait simplement l’optimiser énergétiquement. Une affirmation aussi générale n’emporte aucune conviction sérieuse, puisque nous savons qu’IA, sans autre précision, ne signifie rien de particulier. Il faut donc nous intéresser à la réalité des logiciels et programmes pour envisager cette question.

De manière générale, il faut bien comprendre qu’un programme informatique, même lorsqu’on l’appelle “IA”, ne s’endort pas lorsqu’il est fatigué : autrement dit, il n’arrête pas d’avoir besoin d’énergie supplémentaire, même lorsque ce qu’il fait est absurde, inutile ou dangereux.

De manière générale : c'est le changement d'état (1 vers 0 ou 0 vers 1) qui requiert de l'énergie. Une application qui est en veille ne coûte que l'énergie pour maintenir le système en état. Le coût minimum nécessaire pour un système en veille est l'écoute sur les nouveaux événements qui feront sortir le système de la veille. Sans cela, le système serait considéré comme étant à l'arrêt.

Un regard historique

Le développement des IA aujourd’hui à la mode n’a certainement pas été frugal, leur emploi et donc leur évolution actuelle ne l’est certainement pas non plus.

Cependant, on peut imaginer le développement d’autres IA, tout à fait frugales, qui viendront se rajouter, et pourquoi pas sait-on jamais, remplacer les premières… à moins que les premières soient tellement intégrées dans un système logiciel de production dense, qu’elles ne disparaissent jamais. Autrement dit, pour un effort pour déployer une éventuelle IA, il faut un effort bien supérieur pour enlever ou modifier ce sur quoi, ou ce en regard de quoi on voudra l’installer. 

On sait que ce phénomène d’accumulation est présent également concernant les sources d’énergie. Il est moins présent pour les objets techniques : achetant un rasoir électrique, je ne vais probablement plus m’acheter autant de rasoirs mécaniques.

Quelques ordres de grandeur...

De manière générale [1], un supercalculateur tel que Fugaku consomme 28 335 KW quand il fonctionne à plein régime. Une bonne carte graphique sans être sollicitée peut consommer 20x moins à l’heure que quand un jeu est lancé. Sur ces machines, ont peut installer des programmes d’IA.

Attention : dans ce qui suit, l’estimation ne concerne que la phase expérimentale et de la seule capacité de computation sur un GPU (unité de calcul pour ce genre de technologie.) Il ne s’agit en rien d’une dette carbone totale de l’IA, pas même pour ChatGPT : ce serait cette dette carbonée (entre autres GES) totale, qu'il serait intéressant de mettre en ragard de l’éventuel retour sur investissement et bénéfices qualitatifs associés. [2]

Voici une méthode possible, pas vraiment simple, pour connaître la dette carbone totale de Chat GPT [3]. Il faudrait prendre une photographie de l’état des données de toute l’informatique mondiale connectée; remonter toutes les séries d’inférences qui aboutissent à cet état, jusqu’à pouvoir isoler une série de 0 et de 1 correspondant à la toute première implémentation de ChatGPT.

Aucun chiffre n’est donné par l’éditeur mais plusieurs ont tenté de l’approcher en l’estimant, et les chiffres sont édifiants : 0,00297 KWh par requête, 10 millions de requêtes par jour, soit une consommation journalière de 29700 KWh pour les seules requêtes et leur traitement auxquelles s’ajoutent, 3000W par serveur pour son fonctionnement soit un multiple de 26280000 Wh par an et par serveur. 

Sur la base des premiers développements de ChatGPT d’OpenAI il est possible d’avoir l’estimation suivante pour les ressources de calcul basé sur des cartes graphiques : Nombre de processeurs GPU : 1000. Consommation en Watts par GPU : 250W. Consommation total du parc de GPU : 250000W. Consommation annuelle du parc avec un taux d’utilisation de 100% 24/24 7/7 base 365 jours an   : 250000 * 24 * 365 = 2,19e+9 Wh an soit 219000000 Wh annuels soit 219000 KWh an. 

A titre de comparaison : 219000 journées de jeu sur console de jeu video, un peu plus d’un million d’heure de visionnage TV (ou 73000 heure de VOD), 109500 douches ou 54750 bains, ou 54750 lavage et séchages de linge, c’est aussi 219000 heures de chauffage l’hiver ou bien 109500 heures de climatisation en pleine canicule estivale, ou encore 109500 jours de travail avec un ordinateur fixe contre 328500 jours de travail avec un ordinateur portable. Enfin, c’est 438000 kilomètres parcourus en voiture smart électrique. C’est aussi la consommation électrique annuelle de 46 français. C’est aussi éclairer 851,64 m2 du palais de l’Elysée (Hôtel d’Evreux uniquement) pendant 1 an.

[1] Tout ce qui suit est une tentative d'objectivation/chiffrage totalement subjective, et éminemment contestable. Nous ne souhaitons pas ici proférer une vérité, mais montrer une manière possible de positionner le problème de façon technoréaliste.

[2] https://www.hardware.fr/articles/955-10/consommation-efficacite-energetique.html - lien externe

[3] elle paraîtra absurde, mais la méthode estimative nous paraît bien pire parce qu’ignorant les propagations à l’heure d’internet.

Un problème beaucoup plus multi-dimensionnel qu’il ne paraît

Attention! Le problème est plus multi-dimensionnel qu’il n’y paraît. Il est en fait à peine plus rationnel de chiffrer énergétiquement le bilan d’un service connecté à internet, que celui d’une loi qui entrerait en vigueur : les dépendances sont trop nombreuses, et les frontières objectives pour borner l’analyse, inexistantes (voir nos autres développements sur la notion de “système”).

Nous avons donné une idée de la consommation directe. L’usage induit aussi des émissions dérivées de la mise à l’échelle consommée par les fournisseurs de blocs essentiels à la publication et à l’utilisation de l’IA. Autrement dit, ChatGPT est un service connecté, et ce à quoi il est connecté risque de devoir grandir avec lui. Il ne suffit donc pas de multiplier le nombre de requêtes, par le coût de la requête, pour avoir une idée de l’impact réel de ce service. Nous mettons en note, un billet de blog d’OpenAI, pour donner une idée de la machinerie “derrière le rideau”. [1]

On voit qu’il n’y a pas de sens de faire un “bilan carbone” comme pour un vulgaire scooter, ou une machine à laver. Alors que les frontières de l’IA sont purement conventionnelles, un tel bilan serait parfaitement farfelu : le “système” d’IA (qui est en fait un logiciel) est dynamique et capable de redimensionnement automatique (“autoscalable”), il fonctionne dans le cloud : c’est à dire que l’on peut (et souvent, on doit) programmer de la sorte que la fonction de calcul puisse être assurée, quelle que soit sa durée et sa dimensionnalité, quitte à élargir la ressource de calcul sous-jacente (et donc la puissance associée). De la sorte, l’autoscalling vient justement fournir les ressources manquantes, et l’IA ne se contente pas, comme un animal, de l’énergie à laquelle elle a accès.

[1] Voici un exemple d’un billet de blog d’OpenAI concernant le fonctionnement de ChatGPT   : «  Our workload is bursty and unpredictable  : a line of research can go quickly from single-machine experimentation to needing 1,000 cores. For example, over a few weeks, one experiment went from an interactive phase on a single Titan X, to an experimental phase on 60 Titan Xs, to needing nearly 1600 AWS GPUs. Our cloud infrastructure thus needs to dynamically provision Kubernetes nodes. It’s easy to run Kubernetes nodes in Auto Scaling groups, but it’s harder to correctly manage the size of those groups. After a batch job is submitted, the cluster knows exactly what resources it needs, and should allocate those directly. (In contrast, AWS’s Scaling Policies will spin up new nodes piecemeal until resources are no longer exhausted, which can take multiple iterations.) Also, the cluster needs to drain nodes before terminating them to avoid losing in-flight jobs. It’s tempting to just use raw EC2 for big batch jobs, and indeed that’s where we started. However, the Kubernetes ecosystem adds quite a lot of value  : low-friction tooling, logging, monitoring, ability to manage physical nodes separately from the running instances, and the like. Making Kubernetes autoscale correctly was easier than rebuilding this ecosystem on raw EC2. We’re releasing kubernetes-ec2-autoscaler, a batch-optimized scaling manager for Kubernetes. It runs as a normal Pod on Kubernetes and requires only that your worker nodes are in Auto Scaling groups. » Source  : https  ://openai.com/research/infrastructure-for-deep-learning

Bilan de l'opération

Il nous semble que l’IA (entendue comme l’ensemble des logiciels mobilisant des algorithmes d’IA, ou ayant requis la mobilisation de techniques de programmation typiques de l’IA) est pantagruélique, et tel un trou noir ne cesse jamais de croître tant qu’elle est alimenté en électricité : le paramètrage de limitation de la consommation s’opère en local, ce qui n’a quasiment aucun effet sur les besoins globaux, s’agissant d’un système interconnecté branché. 

Mais des optimisations de la vitesse et de la consommation locales sont parfaitement envisageables : on connaît la modernisation des processeurs CPU vers GPU puis NPU. Cependant, il n’y a pas de raison de penser que ces améliorations locales provoqueront une baisse du besoin global en énergie (en valeur absolue), à cause de ce qu’est un système informatique intégré.

L’IA ne se fatigue jamais de calculer : tant qu’elle est branchée sur le réseau électrique mondial, il est à craindre qu’elle puisse brûler toute l’énergie du monde pour ce faire (l’IA n’est sensible ni au “signal prix”, ni aux craintes climatiques [1]). Des logiciels non-IA feraient sans doute la même chose, peut-être moins vite.

[1] Ce n’est d’ailleurs pas un hasard si Sam Altman, promoteur de ChatGPT, est aussi un acteur important de la recherche en matière de fusion nucléaire contrôlée (sérieusement envisagée comme l’énergie “du futur”) avec son autre entreprise nommée   : Helion Energy.

Vous n'êtes pas d'accord ? Vous voulez participer ? Vous avez une objection ? Une question ? Contribuez !