Reve dévoile comment une petite équipe a construit une infrastructure capable de mobiliser 10 000 GPU

Reve publie les coulisses techniques de ses modèles d'image, avec une infrastructure d'entraînement à 10 000 GPU, des clusters multirégions et une récupération automatisée des pannes.

Entraîner des modèles d'intelligence artificielle sur des milliers de GPU ne consiste pas seulement à disposer de suffisamment de puissance de calcul. Il faut également répartir les machines, alimenter les processeurs en données, synchroniser les entraînements et éviter qu'une panne matérielle ne compromette plusieurs heures de travail. Reve, spécialiste de la génération et de l'édition d'images par IA, détaille désormais l'infrastructure développée par ses équipes pour résoudre ces problèmes.

Dans un rapport technique de 19 pages, le laboratoire présente une plateforme construite sur Google Cloud, Kubernetes et Ray, enrichie d'outils internes pour la gestion des ressources, le calcul distribué et la reprise automatique des entraînements. L'ensemble a été conçu pour fonctionner à l'échelle de 10 000 GPU, tout en restant administrable par une équipe d'ingénierie relativement réduite.

Le document décrit l'environnement utilisé pour développer Reve 2.0, Reve 2.1 et leurs prédécesseurs. Il ne révèle pas les architectures complètes des modèles génératifs ni leurs données d'entraînement, mais expose les choix d'infrastructure qui ont rendu leur développement possible. Des milliers de GPU H100 et H200 répartis sur Google Cloud

La plateforme repose sur Google Kubernetes Engine, le service Kubernetes managé de Google Cloud, associé à Ray pour l'exécution distribuée des entraînements.

Les principaux serveurs utilisés appartiennent aux familles A3 Mega et A3 Ultra. Chaque machine dispose de huit accélérateurs NVIDIA.

Les A3 Mega embarquent 8 GPU H100 de 80 Go, avec une bande passante réseau maximale annoncée de 1 800 Gbit/s. Les A3 Ultra utilisent 8 GPU H200 de 141 Go, avec un réseau pouvant atteindre 3 600 Gbit/s.

Ces capacités réseau sont déterminantes : lorsqu'un modèle est entraîné sur des centaines ou des milliers de processeurs, ceux-ci doivent échanger rapidement des informations sur les paramètres et les gradients. Les performances ne dépendent donc pas uniquement de la puissance de calcul individuelle des GPU.

Reve réserve des capacités de calcul sur des périodes relativement longues, plutôt que de dépendre exclusivement de machines ponctuellement disponibles. Cette organisation facilite les entraînements continus nécessitant de nombreux accélérateurs situés à proximité les uns des autres.

Le laboratoire précise néanmoins qu'un entraînement individuel ne mélange pas des types d'accélérateurs différents. Des groupes de machines hétérogènes peuvent participer à une même expérience à travers le dispositif multirégion, mais pas à un seul groupe d'entraînement classique. Une seule commande pour lancer un entraînement distribué

L'équipe a développé GKR, pour Google Kubernetes Engine Runner, un outil interne en ligne de commande qui regroupe les opérations quotidiennes des chercheurs.

Depuis cette interface, ils peuvent lancer une expérience, choisir un cluster, demander un nombre précis de GPU, réserver de la mémoire, examiner les journaux ou ouvrir un environnement de développement.

Une configuration peut, par exemple, demander deux groupes de huit GPU H200, soit 16 accélérateurs, avec les ressources CPU et mémoire correspondantes.

GKR transforme ces paramètres en ressources Kubernetes, configure les contraintes matérielles et prépare l'environnement d'exécution. Les chercheurs n'ont ainsi pas besoin de gérer directement l'ensemble des détails propres aux différents clusters.

Le système réalise également des vérifications préalables : erreurs matérielles, problèmes de pilotes, mémoire, communication entre GPU et disponibilité des ressources nécessaires à l'expérience.

Un défaut détecté avant le démarrage peut éviter de mobiliser inutilement un grand nombre de processeurs pour un entraînement condamné à échouer.

Cette interface constitue l'une des réponses de Reve à la complexité de son infrastructure. Les spécialistes des modèles peuvent travailler sur leurs expériences sans devoir maîtriser chaque composant du système qui les exécute. Pourquoi Reve a dû abandonner certaines fonctions de Ray

Le rapport présente aussi des décisions d'architecture motivées par des problèmes rencontrés pendant la montée en charge.

Un entraînement multimodal ne repose pas uniquement sur les GPU chargés de modifier les paramètres du modèle. Il mobilise également des services auxiliaires pour préparer les données, encoder des contenus, effectuer des inférences ou réaliser des évaluations.

Reve a organisé ces opérations comme des services indépendants au sein des clusters Ray. Le système répartit les ressources entre les processus d'entraînement et ces services en fonction de leurs besoins.

Mais l'utilisation initiale de Ray pour toutes les opérations a créé des difficultés.

Chaque processeur d'entraînement nécessitait plusieurs processus chargés de préparer les données. À grande échelle, cette organisation produisait des dizaines de milliers d'acteurs Ray, exerçant une pression importante sur le service central de coordination.

Les ingénieurs ont finalement remplacé cette approche par des processus Python indépendants de Ray pour certaines étapes de chargement des données.

Ils ont également adopté ZeroMQ pour les communications entre les processus d'entraînement et les services auxiliaires, après avoir constaté une amélioration importante des performances par rapport aux appels RPC utilisés auparavant.

Autre choix notable : chaque processus d'entraînement dispose de sa propre file d'attente auprès des services auxiliaires. Cela évite qu'un processus particulièrement actif monopolise les ressources au détriment des autres. Entraîner un même modèle dans plusieurs régions du monde

La disponibilité des GPU ne permet pas toujours de réunir toute la puissance de calcul nécessaire dans un seul centre de données.

Reve a donc développé une méthode permettant de répartir une expérience entre plusieurs régions Google Cloud. Le principal obstacle concerne la communication : les connexions entre régions sont généralement plus lentes que celles reliant