Amin Vahdat (Google) "L'inférence coûtera bientôt plus cher que l'entraînement des modèles"

Sans lui, Google ne tournerait pas aussi bien. Amin Vahdat supervise l'infrastructure mondiale qui alimente Search, YouTube, Google Cloud mais surtout Gemini. A l'occasion du Raise Summit, il raconte au JDN l'envers de la course à l'IA.

JDN. DeepMind conçoit les modèles d’IA de Google. Votre équipe, elle, construit l’infrastructure qui permet de les entraîner et de les faire tourner. Comment travaillez-vous ensemble ?

Amin Vahdat. Nous travaillons main dans la main avec DeepMind. C’est l’un des aspects les plus intéressants de mon travail : faire du co-design vertical entre les équipes qui conçoivent les modèles et celles qui construisent l’infrastructure matérielle et logicielle nécessaire pour les entraîner, les servir et, désormais, faire fonctionner des agents. Quand un sujet est critique, nous pouvons réunir cinq, dix ou vingt personnes dans une même salle, peu importe leur hiérarchie d’origine. Elles travaillent côte à côte, écran contre écran, autour d’un tableau blanc, définissent un objectif, désignent un responsable et avancent jusqu’à trouver une solution.

Quand vous concevez l’infrastructure pour l’IA, cherchez-vous d’abord à rendre les modèles plus rapides ou moins coûteux à faire tourner ?

La réponse, malheureusement, c’est : les deux. J’aimerais pouvoir choisir un seul objectif, car cela rendrait notre travail beaucoup plus simple. Mais nous ne pouvons pas nous le permettre. La qualité du modèle est absolument critique : il doit produire la meilleure réponse possible. Mais si ce modèle consomme toutes nos ressources, il devient inutilisable à grande échelle. Même si vous avez le meilleur modèle du monde, si vous ne pouvez fournir qu’une seule réponse par jour, cela ne fonctionne pas.T out l’enjeu consiste donc à trouver le bon équilibre entre qualité, performance et efficacité. C’est un compromis permanent. Nous essayons d’identifier le meilleur point sur cette courbe, celui qui permet d’obtenir la meilleure expérience possible, tout en utilisant les ressources de manière efficace.

Quand on entraîne un modèle comme Gemini, quel est aujourd’hui le vrai mur technique : la puissance de calcul, la mémoire, le réseau ou la manière dont le modèle est conçu ?

"Chez DeepMind, les équipes ont des centaines, parfois des milliers d'idées pour améliorer les modèles."

C’est tout cela à la fois. L’architecture du modèle est évidemment déterminante. Chez DeepMind, les équipes ont des centaines, parfois des milliers d’idées pour améliorer les modèles. Mais elles ne les testent pas directement à très grande échelle. Elles les font d’abord s’affronter à petite échelle, un peu comme dans un tournoi. Les meilleures idées passent ensuite au niveau suivant, puis encore au suivant. A la fin, seules les plus solides peuvent être intégrées dans une future version de Gemini. C’est un processus scientifique très rigoureux, fondé sur des tests d’hypothèses successifs. Quand nous lançons ensuite un entraînement sur des dizaines ou des centaines de milliers de puces, nous avons déjà une forte confiance dans les choix effectués.

Mais il faut aussi penser à la manière dont ce modèle va se déployer sur le matériel. Un grand modèle ne tient pas sur une seule puce. Il faut donc le découper, le répartir entre les puces, décider combien de mémoire placer sur chaque circuit, quelle quantité de calcul attribuer à chaque puce, quelle bande passante réseau prévoir et comment gérer les échanges entre elles. La grande question, c’est aussi la latence. Peut-on continuer à faire du calcul utile localement pendant qu’une puce attend un résultat venu d’une autre partie du système, parfois à l’autre bout d’un cluster de 100 000 puces ? C’est ce que l’on appelle le latency hiding. Toutes ces décisions, architecture du modèle, mémoire, calcul, réseau, latence, sont liées. Et c’est leur équilibre qui détermine la performance réelle à très grande échelle.

Avec les agents IA, une simple requête peut déclencher des centaines d’appels à un modèle. L’inférence est-elle en train de devenir aussi complexe que l’entraînement ?

Oui, nous y sommes clairement. Avec les agents, il ne s’agit plus simplement d’appeler un modèle et de récupérer une réponse. Une seule tâche peut nécessiter des centaines, voire des milliers d’étapes : appeler un modèle, analyser sa réponse, récupérer des données dans le stockage, les remettre en contexte, puis relancer une nouvelle série d’opérations. A ce stade, nous ne coordonnons plus seulement des TPU ou des GPU. Nous devons aussi coordonner des CPU, le réseau du data center et le stockage. Et si un seul élément devient un goulot d’étranglement, toute la réponse de l’agent ralentit. Ces ralentissements s’accumulent très vite et peuvent se propager dans le système.

C’est aussi ce qui rend l’optimisation très difficile. Il peut y avoir des gains de performance de 2x, 3x ou 4x simplement en identifiant le bon goulot d’étranglement et en le supprimant. Mais il n’existe pas de solution parfaite, car il n’y a pas un seul type de workload. Nous devons donc concevoir des algorithmes capables de gérer une très grande diversité de situations, tout en maintenant le meilleur niveau d’efficacité possible.

A cela s’ajoute la question de l’énergie. Dans certains pays, la demande électrique atteint un pic seulement quelques semaines par an, par exemple pendant les périodes les plus chaudes ou les plus froides. Nous travaillons avec les fournisseurs d’électricité sur des mécanismes de demand response : ils nous préviennent en amont, et nous réduisons temporairement notre consommation dans certains data centers. Cela complexifie encore le problème de scheduling. Il ne suffit plus de savoir quelles ressources informatiques sont disponibles. Il faut aussi savoir quelle quantité d’énergie est disponible à tel ou tel endroit, et répartir les workloads en conséquence. Pour les agents, cela signifie que l’infrastructure doit tenir compte à la fois du calcul, du réseau, du stockage et de l’énergie disponible.

Cela veut-il dire que l’énergie devient aujourd’hui l’un des principaux freins au développement de l’IA ?

Oui, c’est à la fois l’un de nos plus grands défis et l’une de nos plus grandes opportunités. Le réseau électrique dispose encore d’une capacité importante, mais il faut penser son usage différemment. Historiquement, les data centers ont été conçus pour atteindre des niveaux de fiabilité extrêmement élevés. Pour cela, on construisait beaucoup de redondance : deux alimentations capables de fournir chacune la pleine puissance, avec des systèmes de bascule très rapides. C’était coûteux, mais acceptable, car l’énergie était moins critique et moins chère.

"Nous faisons désormais de la performance par watt une métrique centrale"

Aujourd’hui, la situation change. Si nous acceptons, pour certains workloads, un niveau de fiabilité légèrement inférieur, nous pouvons parfois accéder à beaucoup plus de puissance, plus rapidement et plus efficacement. C’est un arbitrage très important. Le réseau électrique est dimensionné pour les quelques semaines de plus forte demande dans l’année. Si, pendant ces périodes, nous pouvons réduire notre consommation, voire réinjecter de l’énergie produite localement, nous aidons le réseau au lieu de simplement le contraindre. C’est pour cela que nous faisons désormais de la performance par watt une métrique centrale. Pas seulement la performance par dollar ou la performance brute, mais la performance délivrée pour chaque watt consommé. Quand vous optimisez avec cette contrainte, vous ne concevez pas le hardware et le software de la même manière.

A mesure que les modèles génératifs deviennent de plus en plus gros, l’inférence pourrait-elle finir par coûter plus cher que l’entraînement ?

Si l’on regarde l’histoire, je pense que la réponse est oui. Aux débuts d’Internet et de la recherche web, la majorité des ressources, calcul, stockage, réseau, servait à construire l’index. Le fait de répondre aux requêtes des utilisateurs représentait une part plus faible de la capacité. Avec le temps, cela s’est inversé. Aujourd’hui, on ne parle plus vraiment de construire ponctuellement un nouvel index du web : les utilisateurs attendent un accès quasiment en temps réel à l’ensemble d’Internet. Le service aux utilisateurs est donc devenu la partie dominante de la capacité.

Je pense que nous sommes à un point d’inflexion similaire avec l’IA. L’entraînement reste énorme et continuera de l’être. Mais l’inférence décolle très rapidement, au point de se rapprocher d’un équilibre 50/50 avec l’entraînement. A terme, si l’objectif est bien de délivrer de la valeur aux utilisateurs à partir des modèles, alors l’inférence doit logiquement devenir la part dominante de l’investissement.

L’adoption de l’IA progresse de façon très hétérogène. Comment anticipez-vous les besoins en puces et en data centers, notamment pour des marchés comme la France ou l’Europe ?

C’est un problème extrêmement difficile. La planification de capacité représente une part très importante du travail de mon équipe. La difficulté, c’est que nous sommes face à une croissance exponentielle. Et prévoir précisément une exponentielle est presque impossible. Dans des marchés plus matures, comme le compute traditionnel avant l’arrivée des agents, la demande était plus simple à anticiper. Si elle progressait de 30 % par an, vous pouviez prévoir 35% ou 40% pour garder une marge.

"Un client peut passer très rapidement de quelques TPU ou GPU à une demande de 10 000 puces"

Avec l’IA, c’est très différent. Un client peut passer très rapidement de quelques TPU ou GPU à une demande de 10 000 puces. Nous devons donc planifier et replanifier en permanence. Quand un client, interne ou externe, nous demande davantage de capacité, nous cherchons d’abord à extraire plus d’efficacité de l’infrastructure existante. Ensuite, nous travaillons avec nos fournisseurs et partenaires pour accélérer l’arrivée de nouvelles capacités : ce qui devait arriver dans trois mois peut-il arriver dans deux mois, voire dans un mois ? C’est un processus continu, 24 heures sur 24 et 7 jours sur 7 : prévoir, replanifier, optimiser l’existant, trouver de nouvelles capacités et travailler avec l’ensemble de la chaîne d’approvisionnement.

Jeff Bezos veut envoyer des data centers dans l’espace, notamment pour le training d’IA. Est-ce une piste crédible ou encore de la science-fiction ?

"Chez Google, nous explorons la piste de l'espace avec le projet Suncatcher"

C’est une direction très intéressante. Chez Google, nous explorons aussi cette piste avec un projet appelé Suncatcher. Je pense que c’est l’une des voies les plus excitantes, mais aussi l’une des plus difficiles, pour l’avenir de l’infrastructure de calcul. L’espace permettrait de répondre à une partie des défis énergétiques. Le solaire y est beaucoup plus efficace : il n’y a pas de couverture nuageuse, moins d’atténuation liée à l’atmosphère, et certaines orbites permettent une exposition quasi continue au soleil. Les panneaux peuvent donc produire beaucoup plus efficacement que sur Terre.

Mais les défis sont considérables. Le refroidissement, par exemple, peut sembler plus simple dans l’espace, alors qu’il est en réalité extrêmement complexe. La fiabilité est aussi un sujet majeur : aujourd’hui, ces infrastructures nécessitent de la maintenance. Dans l’espace, il faut donc repenser entièrement la redondance et la réparation. Enfin, il y a la question du réseau. On ne peut pas simplement envoyer un immense data center en orbite. Il faudrait probablement répartir l’infrastructure en plusieurs modules et les faire communiquer entre eux, par exemple avec des liaisons optiques en espace libre. Tous ces problèmes sont techniquement abordables, mais ils restent très difficiles. C’est un pari majeur. Et c’est clairement un pari qui nous intéresse.