L'entraînement décentralisé pourrait-il résoudre le problème énergétique de l'IA ?

Planifier un entraînement de dix gigawatts

Tout d'abord, nous devons comprendre où la capacité énergétique pour les datacenters pourrait être disponible aux États-Unis aujourd'hui.

Bien qu'il existe peu d'endroits qui pourraient gérer un nouveau datacenter de 5 à 10 GW, il existe une capacité sous-utilisée existante considérable dans l'infrastructure énergétique. La grille est loin d'être saturée, mais dans de nombreux endroits, les charges de pointe sont relativement rares. Ainsi, l'utilisation de la grille peut être faible, et il y a plus de capacité disponible pendant les périodes de faible charge.

Nous avons compilé une liste de centrales électriques à gaz aux États-Unis avec une capacité de réserve élevée, comme proxy pour la disponibilité énergétique globale dans la zone (voir l'appendice pour plus de détails). La plus grande installation à capacité ajustée trouvée est la Rock Springs Generation Facility en Wyoming — qui dispose d'environ 800 MW de capacité de réserve. Cette centrale électrique est inactive la plupart de l'année, ne produisant que 2% de sa capacité nominale pendant les charges de pointe d'été.

Pour faire évoluer le cluster à 10 GW, nous envisagerons 23 centrales électriques avec une capacité de réserve comprise entre 300 MW et 800 MW à travers les États-Unis, allant de l'Illinois à Philadelphie en passant par la Géorgie. Hypothétiquement, des datacenters pourraient être construits sur ces sites et connectés par 4 800 km de câbles à fibres optiques alimentant 6 gigawatts de puissance.

En pratique, il est peu probable que ces centrales électriques spécifiques soient prêtes à prêter autant de capacité aux datacenters, mais cela suggère que les entreprises devraient être capables d'obtenir autant de puissance à partir d'emplacements proches.

Quel type de modèle entraînerions-nous ?

10 GW pourraient alimenter environ 51 000 serveurs NVIDIA GB200 NVL72. Selon les calculs de Semianalysis, un cluster comme celui-ci pourrait effectuer une exécution d'entraînement de 5e28 FLOP en quelques mois.

Pour référence, Llama 3 405B a utilisé 4e25 FLOP. Nous estimons que les plus grandes exécutions d'entraînement aujourd'hui — en supposant qu'OpenAI entraîne des modèles sur Colossus — utilisent environ 2e27 FLOP. Bien que notre estimation de 5e28 FLOP dépasse largement toute exécution d'entraînement existante, il est possible que ce soit l'échelle que les modèles de frontière atteindront dans quelques années.

Nous concluons que de telles exécutions nécessiteront probablement plusieurs trillions de tokens de données d'entraînement. Epoch AI estime que l'internet public accessible et de haute qualité contient moins de 100 trillions de tokens. L'entraînement à cette échelle devrait donc puiser dans d'autres sources de données. Comme Elon Musk l'a récemment déclaré, "les livres ont probablement environ cinq trillions de tokens et l'internet a probablement environ 100 trillions de tokens, donc vous pouvez épuiser ça, puis vous ne savez pas vraiment quoi faire."

Par conséquent, nous nous attendons à ce qu'une exécution d'entraînement à cette échelle complète les données internet existantes avec des données synthétiques ou vidéo — le pré-entraînement sur des données synthétiques est utilisé aujourd'hui. Les deux nécessiteraient de grandes quantités de calcul en dehors du cluster d'entraînement principal pour générer ou filtrer les données. Pour cette raison, nous modélisons la génération de données comme une exécution d'entraînement de modèle, plutôt qu'un pré-entraînement traditionnel à grande échelle.

L'exécution d'entraînement sur 10 GW pourrait être conceptualisée comme un "run" de génération de données synthétiques alimentant un pré-entraînement de frontière plus petit qui s'exécute sur quelques gigawatts dans un seul datacenter. Alternativement, cela pourrait être l'entraînement d'un modèle qui améliore de manière itérative ses capacités de raisonnement avec test-time compute et auto-amélioration.

Comment décentraliserions-nous l'entraînement ?

Un cluster à grande échelle peut être distribué entre plusieurs datacenters en utilisant le parallélisme de données : différentes copies du modèle sont entraînées sur différents datacenters en utilisant différents lots de données. Périodiquement, les gradients de chaque lot sont synchronisés entre les datacenters et les copies du modèle sont mises à jour en synchronisation.

Nous supposerons que chaque datacenter entraîne un modèle indépendant utilisant le parallélisme de données sur le WAN, chaque datacenter nécessitant une connexion stable et rapide à tous les autres. Voir Besiroglu et al. 2024 et Gu et al. 2024 pour plus de détails.

Nous modélisons notre scénario de manière conservatrice en supposant que chaque datacenter doit se connecter à tous les autres, mais en pratique, une architecture hiérarchique pourrait réduire les coûts d'infrastructure. Les calculs détaillés et les hypothèses sont présentés dans l'annexe B.

L'entraînement décentralisé peut-il maintenir un débit suffisant à très grande échelle ?

Lorsque vous distribuez l'entraînement sur plusieurs datacenters, le débit du système — la vitesse à laquelle il traite les données d'entraînement — dépend de deux facteurs principaux :

• Temps de calcul : Le temps nécessaire à chaque datacenter pour traiter son lot de données
• Temps de synchronisation réseau : Le temps nécessaire pour synchroniser les gradients entre tous les datacenters via le réseau

Si le temps de synchronisation réseau devient trop important par rapport au temps de calcul, le système passera la plupart de son temps à attendre la synchronisation réseau plutôt qu'à effectuer des calculs utiles. Cela réduirait considérablement le débit global.

Pour maintenir un débit élevé, nous devons nous assurer que le temps de calcul domine le temps de synchronisation. Cela peut être accompli de deux manières :

1. Augmenter la taille du lot de données traitées entre les synchronisations (augmentant ainsi le temps de calcul)
2. Réduire le temps de synchronisation réseau grâce à une infrastructure réseau plus rapide

Dans les sections suivantes, nous examinerons ces deux aspects en détail pour déterminer si un cluster décentralisé de 10 GW peut maintenir un débit suffisant.

Combien de temps pour traiter chaque batch ?

Le temps de calcul par batch dépend de la taille du batch et de la puissance de calcul disponible. Des batchs plus grands signifient plus de temps de calcul, ce qui aide à amortir le coût de la synchronisation réseau.

Cependant, il existe une limite à la taille du batch : si le batch est trop grand, l'efficacité de l'entraînement diminue. C'est ce qu'on appelle la taille de batch critique — la taille de batch au-delà de laquelle augmenter davantage la taille n'améliore plus l'efficacité de l'entraînement de manière significative.

Pour notre cluster de 10 GW avec environ 51 000 GB200, nous estimons qu'avec une taille de batch critique de 5 millions de tokens, chaque datacenter traiterait son batch en environ 15 à 30 secondes de temps de calcul.

Cela signifie que le temps de synchronisation réseau doit être significativement inférieur à 15-30 secondes pour maintenir un débit élevé. Idéalement, le temps réseau devrait représenter moins de 10% du temps total par batch.

Combien de temps passerons-nous sur le réseau ?

Le temps de synchronisation réseau dépend de deux facteurs clés :

• Latence de propagation : Le temps nécessaire pour qu'un signal voyage sur la distance physique entre les datacenters
• Temps de transmission de bande passante : Le temps nécessaire pour transférer toutes les données de gradient à travers le réseau

Examinons chacun de ces facteurs pour déterminer s'ils constitueraient un goulot d'étranglement.

La latence de propagation serait-elle suffisamment faible ?

La latence de propagation est déterminée par la distance physique entre les datacenters et la vitesse de la lumière dans la fibre optique (environ 200 000 km/s, soit les deux tiers de la vitesse de la lumière dans le vide).

Dans notre scénario avec 23 datacenters répartis sur 4 800 km à travers les États-Unis, la distance maximale entre deux datacenters pourrait atteindre environ 3 000 km. Cela se traduit par une latence aller-retour d'environ 30 millisecondes.

Avec 23 datacenters, le protocole de synchronisation all-reduce nécessite plusieurs tours de communication. En utilisant un algorithme optimisé comme ring all-reduce, le temps de latence total serait d'environ 60-100 ms.

Comparé à notre temps de calcul de 15-30 secondes par batch, cette latence de ~100 ms représente moins de 1% du temps total. La latence de propagation ne devrait donc pas constituer un goulot d'étranglement majeur.

La bande passante pourrait-elle être un goulot d'étranglement ?

La bande passante détermine la vitesse à laquelle nous pouvons transférer les gradients du modèle entre les datacenters. Pour un modèle de plusieurs trillions de paramètres, la quantité de données à synchroniser est substantielle.

Supposons un modèle avec 10 trillions de paramètres (une taille plausible pour une exécution de 5e28 FLOP). En utilisant une précision de 16 bits, chaque paramètre nécessite 2 octets, donc nous devons synchroniser environ 20 téraoctets de données de gradient par synchronisation.

Pour transférer 20 TB en moins de 1-2 secondes (pour rester bien en dessous de notre budget de 15-30 secondes), nous aurions besoin d'une bande passante d'environ 100-200 Gbps entre chaque paire de datacenters.

Heureusement, les connexions en fibre optique modernes peuvent facilement atteindre 400 Gbps ou plus. Des entreprises comme Amazon et Google déploient déjà des connexions intercontinentales à 400 Gbps.

Avec une bande passante de 400 Gbps entre les datacenters, le temps de transmission serait d'environ 0,4 à 0,8 seconde, soit environ 2-5% du temps de calcul total. La bande passante ne devrait donc pas constituer un obstacle majeur.

Le coût du réseau est-il réalisable ?

Bien que techniquement faisable, le coût de construction de l'infrastructure réseau pour connecter 23 datacenters à travers les États-Unis serait substantiel. Examinons les composants principaux :

Le coût du réseau — environ 410 millions de dollars — peut sembler élevé en valeur absolue. Cependant, comparé au coût total du datacenter de 77 milliards de dollars, il ne représente qu'une augmentation de 0,5% du coût global.

Cette augmentation marginale suggère que le coût du réseau ne devrait pas être un obstacle majeur à l'adoption de l'entraînement décentralisé, du moins d'un point de vue économique.

De plus, l'infrastructure de fibre optique pourrait servir à plusieurs exécutions d'entraînement au fil du temps, amortissant davantage le coût initial.

Les entreprises adopteront-elles réellement l'entraînement décentralisé à grande échelle ?

Notre analyse montre que l'entraînement décentralisé est techniquement faisable et économiquement viable pour des clusters de 10 GW. Mais cela ne signifie pas que les entreprises l'adopteront nécessairement. Plusieurs facteurs pourraient influencer cette décision :

Notre conclusion : Les entreprises adopteront probablement l'entraînement décentralisé uniquement lorsque les contraintes énergétiques rendront impossible la construction de datacenters centralisés plus grands.

En d'autres termes, tant qu'il sera possible de construire des datacenters de 5 GW, 7 GW ou même 10 GW en un seul emplacement, les entreprises privilégieront probablement cette approche. L'entraînement décentralisé deviendra une nécessité plutôt qu'un choix — une solution de secours lorsque la croissance centralisée atteindra ses limites physiques.

Cependant, une fois que ces limites seront atteintes — et notre analyse suggère que cela pourrait arriver dans les prochaines années — l'entraînement décentralisé pourrait devenir la seule voie viable pour continuer à faire évoluer les clusters d'entraînement d'IA.

Appendices

Notes