ZEN veut accélérer l’entraînement des IA en fluidifiant les échanges entre GPU

Les grands modèles d’intelligence artificielle donnent l’impression de progresser à la vitesse des puces qui les entraînent. En pratique, leur cadence dépend aussi d’un élément moins visible : la capacité des milliers de processeurs à se transmettre les résultats de leurs calculs sans se gêner. Lorsque cet échange devient trop lent, disposer de GPU toujours plus puissants ne suffit plus à accélérer l’apprentissage.

C’est ce problème que s’attaque à résoudre ZEN, un système issu de travaux menés à l’université Rice par une équipe dirigée par Zhuang Wang et T.S. Eugene Ng. L’idée est de ne plus faire voyager systématiquement toutes les valeurs produites durant l’entraînement. En exploitant la sparsification, c’est-à-dire l’élimination des valeurs nulles ou peu importantes dans les communications, les chercheurs cherchent à libérer un canal de communication devenu un frein majeur à l’échelle des grands modèles de langage, les LLM.

Où se situe le goulet d’étranglement de l’entraînement des IA ?

Un modèle d’IA apprend en examinant un très grand nombre d’exemples. Pour chacun, il produit une réponse, compare cette réponse au résultat attendu, puis ajuste progressivement ses paramètres. Cette opération est répétée un nombre considérable de fois. Dans le cas d’un LLM, les paramètres à ajuster se comptent souvent en milliards.

Un seul GPU ne peut pas toujours absorber ce travail dans un délai raisonnable. Les laboratoires et les entreprises répartissent donc l’entraînement sur de nombreuses machines. Chaque GPU reçoit une portion des données, effectue ses calculs en parallèle des autres, puis participe à une étape de mise en commun. C’est cette dernière étape qui peut ralentir l’ensemble.

Les corrections qui guident l’apprentissage sont appelées des gradients. Sans entrer dans les mathématiques, on peut les voir comme des indications de direction : elles signalent quels paramètres doivent être modifiés et dans quel sens pour réduire les erreurs du modèle. Dans un entraînement distribué, les GPU doivent synchroniser ces informations pour que chacun travaille sur une version compatible du même modèle.

Le problème n’est donc pas uniquement la puissance de calcul. Il est aussi lié au temps passé à attendre que les autres processeurs aient transmis ou reçu les informations nécessaires. À grande échelle, le réseau qui relie les GPU, les mécanismes logiciels de synchronisation et l’organisation des données deviennent aussi déterminants que les puces elles-mêmes.

Pourquoi les échanges entre GPU peuvent-ils coûter si cher ?

Le principe de la synchronisation paraît simple : chaque processeur calcule sa contribution, puis toutes les contributions sont combinées. Mais les modèles modernes manipulent des tableaux de nombres de très grande taille, appelés tenseurs. Envoyer ces tableaux à chaque itération peut représenter une circulation massive de données.

Dans de nombreux systèmes, chaque unité doit attendre que les autres aient terminé la phase d’échange avant de poursuivre. Le GPU le plus rapide se retrouve alors ralenti par la communication ou par un GPU plus chargé. Cette logique amplifie les petits retards : une congestion réseau, un lot de données plus complexe ou une répartition inégale du travail peuvent avoir des effets sur toute la grappe de calcul.

Selon Zhuang Wang, une part significative des données échangées lors de cette synchronisation correspond à des valeurs nulles. D’autres valeurs peuvent être trop faibles pour être prioritaires dans la communication. Les transmettre sans distinction revient à mobiliser de la bande passante pour de l’information qui n’apporte pas nécessairement la même utilité à l’étape d’apprentissage en cours.

C’est là qu’intervient la sparsification. Au lieu de traiter un tenseur comme une liste complète où chaque position est envoyée, l’approche consiste à ne conserver que les valeurs jugées pertinentes. Le résultat est un tenseur épars, ou tensor sparse : il contient moins de valeurs utiles à transporter, mais doit aussi indiquer où ces valeurs se situent dans le tableau d’origine.

Les tenseurs épars ne se répartissent pas uniformément

Réduire le volume de données ne règle pas automatiquement tous les problèmes. Les chercheurs de Rice ont étudié le comportement des tenseurs épars dans des modèles populaires et ont constaté un point essentiel : les gradients non nuls ne sont pas distribués uniformément.

Cette distribution dépend à la fois du modèle entraîné et de l’ensemble de données utilisé. Autrement dit, certains GPU ou certains segments du système peuvent se retrouver avec davantage de valeurs importantes à transmettre que d’autres. Si une unité concentre une part disproportionnée du travail de communication, elle devient à son tour un point de ralentissement.

Cette observation nuance une idée intuitive : compresser ou filtrer les données ne suffit pas si la charge restante est mal répartie. Il faut également organiser la circulation des informations afin que les processeurs, les liens réseau et les étapes de synchronisation ne soient pas déséquilibrés.

La sparsification comporte par ailleurs ses propres contraintes générales. Conserver uniquement une partie des valeurs suppose de choisir lesquelles importent, de transmettre leur position et de les reconstituer correctement à destination. Une solution efficace doit donc gagner davantage de temps sur les échanges qu’elle n’en dépense à sélectionner et à gérer ces informations. Elle doit aussi préserver un apprentissage fiable.

Ce que propose ZEN pour mieux communiquer

L’équipe dirigée par Zhuang Wang et T.S. Eugene Ng a examiné plusieurs schémas de communication afin de répondre à ces déséquilibres. Le système ZEN est le résultat de cette recherche. Sa promesse centrale n’est pas de modifier la nature des modèles de langage, mais de rendre plus efficace la manière dont les informations éparses circulent pendant leur entraînement distribué.

ZEN s’intéresse donc à l’architecture de communication, un niveau technique qui reste généralement invisible pour l’utilisateur final d’une IA. Pourtant, l’enjeu est concret : si chaque étape d’entraînement est moins longue, un même parc de machines peut achever davantage de travail dans un temps donné. Les chercheurs indiquent que le système a montré une amélioration notable de la rapidité d’entraînement des LLM en conditions réelles.

Aucun chiffre précis de gain n’est détaillé ici. Il serait donc imprudent de présenter ZEN comme une solution universelle ou de promettre une réduction donnée du temps d’entraînement. Les résultats peuvent varier selon l’architecture du modèle, le jeu de données, le nombre de GPU, la topologie du réseau et le niveau de sparsité effectivement observé. La contribution de ces travaux tient surtout à une meilleure prise en compte de la réalité des données éparses, plutôt qu’à une simple réduction brute de leur volume.

Une approche potentiellement utile au texte comme à l’image

Les LLM sont l’exemple le plus immédiat, car leur entraînement exige des infrastructures considérables. Mais les tenseurs épars apparaissent dans des contextes plus larges, notamment dans des systèmes utilisés pour générer du texte ou des images. Une méthode de communication mieux adaptée à ces structures de données pourrait donc intéresser différents types de modèles d’apprentissage profond.

Pour les concepteurs d’infrastructures, le bénéfice potentiel est double. D’une part, diminuer les données échangées peut réduire le temps où les GPU attendent les uns après les autres. D’autre part, mieux répartir la charge peut éviter qu’un petit nombre de processeurs ou de liens réseau ne dicte la vitesse de tout le système. Ce sont des gains d’efficacité, non des raccourcis qui dispensent de données de qualité, de calcul ou de validation scientifique.

Dans un secteur où le coût de l’informatique et de l’énergie constitue une question stratégique, l’optimisation des communications devient un sujet aussi important que l’amélioration des algorithmes. Elle peut permettre d’exploiter plus efficacement les équipements existants, même si elle ne remplace ni les besoins en matériel ni l’investissement dans les centres de données.

ZEN s’inscrit dans une recherche plus large sur la fiabilité

Ces travaux ne constituent pas le premier projet de Wang et Ng consacré aux contraintes pratiques de l’entraînement à grande échelle. Les deux chercheurs avaient auparavant travaillé sur GEMINI, un projet visant à réduire les surcharges liées à la récupération après une panne durant l’entraînement.

Le rapprochement entre GEMINI et ZEN éclaire une réalité souvent masquée par les démonstrations d’IA : faire fonctionner un entraînement distribué sur la durée impose de gérer à la fois la vitesse, les pannes et l’utilisation des ressources. Une séance d’apprentissage peut mobiliser de nombreuses machines et durer longtemps. Un incident, une synchronisation inefficace ou une mauvaise distribution du travail peuvent alors coûter du temps de calcul.

ZEN s’inscrit dans cette logique d’ingénierie : rendre les systèmes non seulement capables d’entraîner de grands modèles, mais aussi plus efficients dans leur fonctionnement quotidien. Cette dimension est décisive à mesure que les modèles et les jeux de données grandissent.

Ce qu’il faut surveiller

La suite dépendra de la capacité des approches de communication éparse à fonctionner avec une diversité de modèles, de données et d’infrastructures. La présence de tenseurs épars ne garantit pas, à elle seule, un gain identique partout. Il faudra notamment vérifier comment les méthodes s’adaptent aux différents niveaux de sparsité et aux déséquilibres observés par les chercheurs.

Il sera également important d’évaluer le compromis entre vitesse et qualité de l’apprentissage. Réduire les communications est utile si les informations conservées permettent au modèle de continuer à apprendre correctement. La sélection des valeurs, leur encodage et leur synchronisation doivent donc être conçus comme un ensemble cohérent.

Au 12 juillet 2025, ZEN illustre surtout un déplacement du regard sur la course à l’IA. La prochaine amélioration ne viendra pas nécessairement d’un modèle plus vaste ou d’un GPU plus rapide. Elle peut aussi venir d’une meilleure organisation des conversations silencieuses que les machines entretiennent entre elles, des milliards de fois pendant l’entraînement.