Stratégies de déploiement de l'IA : équilibre entre efficacité et impact environnemental
Transcription de la vidéo
Le titre actuel de l'exposé est "Stratégies de déploiement du LLM : Équilibrer l'efficacité et l'impact environnemental". Je sais, personne n'a vraiment envie d'entendre "le discours sur l'environnement". Mais ne vous inquiétez pas, ce sera un exposé qui fera du bien. Voici un chaton ! Sa création ne coûte que 30 grammes d'émissions de CO₂. Et si j'ai bien compris, les émissions de CO₂ provenant de toutes les applications LLM sur Terre représentent actuellement moins de 0,0274 % des émissions mondiales. Ce n'est pas grand-chose.
En fait, nous devrions nous féliciter. Les émissions de CO₂ des LLM sont probablement inférieures à 0,03 mégatonne par jour, soit à peine 11 mégatonnes par an. En tant qu'industrie, nous avons commencé à nous en préoccuper. Nous nous sommes améliorés. Je ne peux pas vous voir tous, mais à main levée, combien d'entre vous savent que leur entreprise a pris un engagement en faveur du climat ou qu'elle est neutre en carbone ? Quelques-uns d'entre vous, peut-être ?
Le fait est que, si nous nous sommes améliorés, il nous reste encore beaucoup de chemin à parcourir. Nous avons recommencé à brûler du charbon comme s'il n'y avait pas de lendemain, ce qui, ironiquement, conduit à ce qu'il n'y ait pas de lendemain. Chaque tonne de CO₂ émise reste dans l'atmosphère - c'est juste de la thermodynamique ; on ne peut pas discuter avec la science.
Il ne s'agit pas d'être un optimiste technologique ou un progressiste. La science ne fonctionne pas comme ça. Le CO₂ ne disparaît pas comme ça. À l'heure actuelle, les émissions de LLM sont environ dix fois supérieures à celles des bombes. Et les bombes ne sont pas géniales - certains ne sont pas d'accord, mais nous en resterons là. Et peu importe que vous soyez assis à côté d'une centrale hydroélectrique ou non. La plupart des émissions sont intégrées dans les processus que nous utilisons.
Voyons donc ce qu'il en est à l'échelle de la planète. Environ deux millions de H100 ont été vendus cette année, ainsi que quelques superordinateurs Grace Hopper, chaque machine consommant environ 700 watts. Avec environ 56 000 watts par machine et un facteur d'efficacité de l'utilisation de l'énergie (PUE), ce sont environ 12 mégatonnes d'émissions qui ont été ajoutées cette année seulement. Et cela s'ajoute aux 11 mégatonnes que je viens de mentionner.
Nous faisons plus que doubler nos émissions chaque année, ce qui signifie que si nous maintenons cette trajectoire, nous devrons émettre environ une demi gigatonne d'émissions au cours des cinq prochaines années. À titre de comparaison, le monde émet actuellement environ 40 gigatonnes par an. Cette tendance n'est pas durable, et les graphiques le montrent clairement.
Pause publicitaire ! Cette conférence est sponsorisée par Reality and Wily. J'ai donc acquis une licence pour un dessin animé pour cette présentation - cela m'a coûté 40 dollars. Et oui, je paie aussi quelques abonnements LLM, comme ChatGPT et Claude d'Anthropic, qui me coûtent environ 40 dollars par mois. C'est à volonté, donc je pourrais techniquement leur demander de générer une caricature similaire gratuitement, mais ce ne serait pas tout à fait la même chose.
Mais bon, j'ai fait le calcul, et la compensation du CO₂ dont nous aurions besoin pour cette empreinte de 12 mégatonnes coûterait environ 0,7 milliard de dollars - un chiffre qui peut sembler dérisoire pour certains acteurs de ce secteur. La plus grande installation de capture directe de l'air au monde, située à Orca, en Islande, ne gère que 4 000 tonnes de CO₂ par an. Comparez cela à 12 mégatonnes et vous aurez compris.
D'accord, puis-je arrêter de parler de CO₂ pendant un moment et me plonger dans la partie technique ? Presque, je le promets ! En bon scientifique et technicien que je suis, j'ai demandé à quelques responsables de LLM quelle quantité de CO₂ ils généraient pour répondre à la question de savoir combien de CO₂ ils généraient. Et, bien sûr, ils ne m'ont donné aucune réponse. J'appelle cela l'apprentissage par renforcement au moyen du retour d'information marketing (RLFM). Il ne s'agit pas d'alignement, mais plutôt de contournement. En fait, ils sont entraînés à éviter de parler de leur empreinte carbone.
Essayez : demandez à Gemini ou à un autre LLM combien de CO₂ ils émettent. Ils vous renverront à un joli article de blog, vous assurant qu'aucun CO₂ n'est émis, du moins selon eux. Mais soyons techniques. Vous avez besoin d'un graphique pour ce genre d'exposé, n'est-ce pas ? J'ai donc créé un graphique de base avec "Prévisibilité/risque" sur un axe et "Héritage/Innovation" sur l'autre. Ce graphique peut représenter assez efficacement les stratégies de déploiement du LLM.
En termes de déploiement de modèles d'apprentissage automatique, nous parlons de tout, des simples requêtes SQL à la formation de nos propres modèles fondamentaux. Et, pour la plupart, ces applications concernent la recherche d'informations : vous avez des données, vous voulez poser des questions et vous voulez des réponses. La beauté de ce type de graphique réside dans le fait que vous pouvez changer les étiquettes des axes et que les points auront toujours un sens.
L'axe des x peut être libellé comme suit : "Mesuré en millisecondes" ou "Mesuré en mois", ou encore "Logiciel qui fonctionne" ou "Matériel qui travaille très dur". Ou, pour dire les choses plus crûment, "Je me soucie" contre "Je ne me soucie pas" du réchauffement de la planète. L'une des dimensions les plus intéressantes que nous pourrions étiqueter est l'argent. Exécuter SQL n'est pas cher ; nous le faisons depuis des années. En revanche, l'exploitation de vos propres GPU coûte une fortune.
Parlons donc des compromis à faire. En tant qu'ingénieurs logiciels, vous savez que tout se résume à des compromis : l'optimisation d'une qualité du système implique souvent d'en sacrifier une autre. Prenons l'exemple de la formation des MLD. Il s'agit d'un processus complexe qui peut échouer de manière spectaculaire, nous laissant avec un modèle surajusté qui se généralise mal. La mauvaise nouvelle est que, dans ce cas, nous n'obtenons pas de compression ou de véritable apprentissage - ce que nous obtenons, c'est essentiellement une base de données.
Et bien sûr, vous pouvez utiliser un LLM surajusté comme une sorte de base de données. Disons que vous l'avez affiné pour connaître le prénom de votre client. Est-il efficace pour cela ? Peut-être - pour le développeur qui n'a pas besoin de demander un nouveau datastore à DevOps ou une nouvelle colonne dans la base de données. Mais cela ajoute de la latence. Chaque requête peut prendre des mois de temps de traitement supplémentaire parce qu'elle ne passe pas par un cache L1 ou L2. Elle peut même récupérer des données incorrectes.
Nous sommes tous passés par là. À l'époque, nous utilisions Oracle pour tout. Aujourd'hui, nous pouvons placer des données dans un fichier de couche Docker et espérer que tout se passe bien. Si votre seul outil est un réseau neuronal, alors oui, il se peut que votre fichier PyTorch finisse par être votre base de données. Cela arrive, même en production.
Lorsque des problèmes surviennent, nous nous appuyons sur une ingénierie rapide. Nous essayons de filtrer les éléments que le modèle ne devrait pas montrer, en espérant que tout ira bien même si nous mettons à jour le modèle ou si nous changeons de fournisseur. Il s'agit simplement d'un nouveau type de dette technique, la dernière invention de notre industrie. Et soyons réalistes, il y a une ironie tragique dans cette approche : si vous exposez un LLM à l'entrée de l'utilisateur sans validation, vous vous préparez essentiellement à un désastre.
Et il ne s'agit pas seulement de nos données. Les données du monde entier deviennent l'entrée de l'utilisateur pour les LLM, ce qui signifie que nous avons un contrôle limité. La génération assistée par récupération (RAG) ne change pas grand-chose à cette réalité. Il s'agit simplement d'une couche supplémentaire, d'une autre abstraction "amicale". Ainsi, lorsque vous utilisez des embeddings d'un grand modèle, n'oubliez pas qu'il ne s'agit pas d'une représentation directe des couches latentes. Ces embeddings contiennent des tonnes d'informations sémantiques qui peuvent souvent être utilisées efficacement dans votre magasin de vecteurs.
L'utilisation efficace d'un magasin de vecteurs peut vous permettre d'économiser une quantité importante de ressources. De nombreuses tâches peuvent être accomplies avec de simples requêtes de distance sur les données que vous avez déjà dans votre base de données vectorielles. Cette approche est beaucoup moins coûteuse, mais il faut savoir que l'argent finira par manquer. Ce que nous faisons actuellement - appeler des modèles massifs hébergés sur du matériel haut de gamme comme Grace Hoppers - ne sera pas financièrement viable dans les cinq prochaines années. La science ne permet pas d'affirmer que ces processus deviendront soudainement abordables.
Quelles sont donc les parties vertes de cette équation ? Elles représentent les choses que nous savons faire sans GPU, les tâches qui peuvent être exécutées par des CPU. L'utilisation du CPU est bien comprise, prévisible et stable. Mais l'utilisation des GPU ? C'est encore un mystère pour la plupart d'entre nous.
Votre travail consiste à trouver ces compromis. Oui, c'est plus de code à écrire, et oui, ce n'est peut-être pas aussi prestigieux que d'utiliser les dernières fonctionnalités à la pointe de la technologie. Mais vous obtiendrez en retour un système plus stable et plus économique. Chaque fois que vous exécutez une requête non mise en cache plutôt qu'un LLM, vous économisez des ressources. Pensez-y de la manière suivante : chaque fois que vous utilisez un LLM pour une requête, un chaton "meurt" métaphoriquement. Utilisez les outils dont vous disposez déjà, comme PostgreSQL et PG Vector, pour sauver les chatons. Il ne s'agit pas de blâmer un mystérieux "eux" ; il s'agit de nous et de nos décisions.
Merci à tous, je suis Ori. Prenez soin de vous !
Liens utiles
Votre meilleur travail
est à l'horizon
