Réseaux évolutifs GPU basés sur Ethernet

Le lancement récent du Gaudi-3 d'Intel, qui utilise RoCE pour l'interconnexion Scale-UP, ainsi que les discussions de Jim Keller sur le remplacement de NVLink par Ethernet, ont attiré l'attention sur cette approche innovante. Notamment, Tenstorrent, dans lequel Jim Keller est impliqué, a intelligemment implémenté l'interconnexion réseau inter-puces via Ethernet. Il est donc pertinent d'aborder les défis et les exigences pour qu'Ethernet remplace NVLink.

Remplacer NVLink par Ethernet ne consiste pas simplement à adopter un nouveau protocole de transport ; cela nécessite une série de modifications de l’architecture GPU. Essentiellement, le problème revient à trouver comment accrocher une mémoire à large bande passante (HBM) sur un réseau Ethernet et réaliser à la fois une mise à l'échelle et une série d'optimisations de communication pour répondre aux demandes de calcul, telles que l'informatique en réseau illustrée par SHARP. À l'échelle mondiale, seules quelques personnes sont capables de résoudre ce problème aux multiples facettes, et il est clair qu'UltraEthernet n'a pas pleinement saisi le concept.

Pour avancer, les questions clés suivantes doivent être abordées :

• Limite de latence : quelle est la limite de latence acceptable ? La latence de liaison causée par le SerDes FEC à haut débit et à grande vitesse et par l'interconnexion au-delà de l'échelle de dizaines de milliers de cartes est inévitable. Ces problèmes ne peuvent pas être résolus simplement en modifiant un protocole de paquets ou en introduisant HPC-Ethernet.
• Sémantique de transmission : Quelle est la sémantique de la transmission ? Les professionnels du réseau comprennent généralement les opérations de base SEND/RECV. Par exemple, la définition de l’UEC de Reliable Unordered Delivery for Idempotent Operations (RUDI) est un faux pas technique. Bien qu'il satisfasse aux lois commutatives et idempotentes, il ne parvient pas à expliquer comment certaines opérations, comme l'idempotence de l'addition de réduction, peuvent être mises en œuvre. De plus, des optimisations basées sur la loi associative, qui ne sont pas prises en charge pour l'accès mémoire fin sur NVLink, sont également nécessaires. Plus largement, la sémantique doit évoluer vers celle d'un Semi-Lattice.
• Mise en commun d'une mémoire plus importante sur NVLink : comment gérer la mise en commun d'une mémoire plus importante sur NVLink ? Cela implique de résoudre les compromis temps/espace pour les opérateurs Compute Bound dans les problèmes de calcul, tels que KV Cache.
• Routage dynamique et contrôle de la congestion : la capacité à acheminer et à contrôler dynamiquement la congestion dans un réseau sans perte 1:1 non convergent n'est pas un problème majeur pour les clusters comportant des dizaines de milliers de cartes grâce à un réglage codé en dur. Cependant, pour les clusters à l'échelle de centaines de milliers, voire de millions de cartes, qui peuvent même nécessiter du RDMA pour la transmission longue distance, aucun fournisseur commercial n'a encore résolu ces problèmes.

Présentation des solutions d'interconnexion ScaleUP actuelles

Intel Gaudi3

Selon le livre blanc Gaudi3, le Gaudi Die est structuré comme suit : Il intègre 24 liaisons RoCE 200Gbps, dont 21 sont utilisées pour le FullMesh interne et trois pour les connexions externes.

La topologie des réseaux à très grande échelle a été calculée et la bande passante du commutateur Leaf est équivalente à celle d'un commutateur de 25.6 T.

Contrôle de la congestion

Le livre blanc d'Intel indique qu'au lieu d'utiliser le PFC, un mécanisme ACK sélectif est utilisé. De plus, l'algorithme SWIFT est utilisé pour le contrôle de la congestion (CC) afin d'éviter d'utiliser ECN. Il s'agit essentiellement d'une réutilisation du moteur de transport fiable de Google Falcon sur l'IPU d'Intel.

Réduction des trajets multiples et en réseau

Intel prétend prendre en charge le Packet Spraying, mais il n'est pas clair quelle société est utilisée ; ce n'est certainement pas leur propre Tofino. Il doit donc s'agir de Broadcom. De plus, In-Network Reduction prend en charge FP8/BF16, etc., les opérateurs prenant uniquement en charge Sum/Min/Max. En combinaison avec les groupes de travail de l'UEC sur l'informatique en réseau (INC), la situation devient plus claire.

Microsoft Maia100

Des informations limitées sont disponibles, mais il existe une bande passante monopuce de 4800 100 Gbit/s. Un châssis de serveur unique contient quatre cartes Maia32 et une armoire entière avec huit serveurs forme un cluster de XNUMX cartes.

En examinant les commutateurs agrandis et les câbles d'interconnexion, il y a trois commutateurs, chaque serveur disposant de 24 interfaces réseau de 400 Gbit/s. Il existe des connexions de bouclage entre les ports (indiqués en noir dans le schéma) et les lignes d'interconnexion externes (indiquées en violet).

Cela suggère une topologie qui forme une interconnexion en forme de bouche au sein de la carte mère, créant un anneau dans la direction X et se connectant à trois commutateurs dans trois plans dans la direction Y.

Les liaisons montantes des commutateurs effectuent des connexions Scale-Out entre les armoires, chaque plan de chaque armoire ayant un total de 32 400G interfaces. En ajoutant une convergence 1:1, les commutateurs de liaison montante se connectent pour former un commutateur 25.6T, ce qui rend théoriquement possible une extension multicouche. Cela représente une fusion de réseaux Scale-Up et Scale-Out. Quant au protocole, un simple RoCE point à point ne devrait pas poser de problème pour le Torus Ring. Toutefois, des capacités multivoies seront nécessaires lors de l’interconnexion aux commutateurs scale-out.

L’inconvénient est le potentiel d’une latence plus élevée. Cependant, pour les puces personnalisées qui ne suivent pas le modèle SIMT comme CUDA mais utilisent plutôt une approche de réseau systolique, la latence n'est pas un problème important. De plus, avec seulement quatre groupes Torus, l’impact de la latence de communication collective est minime. Personnellement, je pense que ces puces sont probablement utilisées principalement à des fins d'inférence, car les CSP développent généralement une puce d'inférence avant de former les puces. D'autres CSP font également une distinction claire entre la formation et l'inférence, comme AWS Trainium/Inferentia et V5p/V5e de Google.

Google TPU

L'interconnexion Google TPU est bien comprise, avec une topologie Torus Ring et des commutateurs optiques pour la commutation de liaison.

La commutation de circuits optiques (OCS) répond à deux objectifs : un partitionnement dynamique en fonction de l'échelle des ventes et une optimisation de la bande passante en bissection pour les communications tout-à-tout comme MoE.

Par exemple, une seule puce TPUv5p prend en charge une connexion Inter-Chip Interconnect (ICI) de 4800 3 Gbit/s avec une topologie 8960D-Torus. Un cluster de 5 6144 unités TPUv3p peut être partitionné dynamiquement par OCS pour vendre à différentes échelles, la configuration maximale vendable étant de XNUMX XNUMX unités formant un XNUMXD-Torus.

La tolérance aux pannes est une considération essentielle pour la topologie 3D Torus.

De plus, Google prend en charge l'extension de deux pods via le réseau du centre de données pour créer une formation multislice, avec un parallélisme Data Parallel (DP) entre les pods.

Formation AWS

L'architecture AWS Trainium se compose de 16 puces formant un petit cluster interconnecté dans une structure Torus Ring 2D.

Dojo Tesla

Tesla Dojo a développé son propre protocole de transport Tesla pour unifier les extensions Wafer/NOC et Ethernet externes.

Grâce au système sur plaquette de TSMC, 25 unités de calcul D1 sont encapsulées sur une seule plaquette, interconnectées dans un réseau maillé 5D 5 × 2, chaque plaquette formant une tuile contenant 40 matrices d'E/S.

Les Tiles sont interconnectées à un débit de 9 To/s.

Le routage réseau sur puce peut contourner les cœurs ou tuiles D1 défaillants.

Pour Ethernet évolutif externe, il existe une carte DIP (Dojo Interface Processor), chaque moteur de calcul D1 ayant sa propre SRAM et une autre mémoire placée sur la carte DIP équipée du HBM.

Chaque carte réseau est connectée au Die I/O du Dojo via un bus spécial à 900 Go/s, le Tesla Transport Protocol (TTP), correspondant au 800GB Bande passante HBM, chaque matrice d'E/S pouvant se connecter à cinq cartes DIP.

En raison de la communication interne du réseau 2D Mesh, la communication longue distance est coûteuse, c'est pourquoi des conceptions de routage spéciales ont été mises en œuvre.

Le routage fournit plusieurs chemins sur la puce et est dans le désordre. Pour les communications à grande échelle sur de longs trajets, une utilisation intelligente de la carte d'interface Dojo construit un bus Ethernet TTPoE à 400 Gbit/s comme raccourci.

Dojo construit un réseau sur puce à haute densité à l'échelle d'une tranche via System-on-Wafer et un réseau de communication inter-wafer privé à haut débit et à courte distance à 9 To/s. Les E/S et la mémoire sont intégrées sur la carte DIP, fournissant 900 Go/s par carte connectée au réseau à l'échelle de la tranche, formant un réseau maillé 2D à grande échelle. Cependant, compte tenu du contrôle de la congestion dû à la longue distance de communication sur le réseau sur puce, un canal d'échappement de 400 Gbit/s basé sur la carte DIP a été conçu, qui envoie la communication via un commutateur Ethernet externe vers la tranche de destination.

Tensorrent

Dans la conception d'interconnexion puce à puce chez Tenstorrent, Jim Keller a utilisé Ethernet, qui a une structure simple. L'en-tête de contrôle Tensor + forme un paquet Ethernet et peut déclencher des capacités d'exécution conditionnelle, comme indiqué ci-dessous :

Interconnexion complète puce à puce via Ethernet

Prend en charge plusieurs langues sources de communication fonctionnelles

Ensuite il y a le partitionnement du graphe. Il semble que le nombre d'instructions par étape puisse être estimé, ainsi que la bande passante des opérateurs entrant et sortant.

Les contraintes finales de mappage sur les cœurs semblent également simples :

Une structure maillée 2D simple

Peut être étendu jusqu'à 40,960 XNUMX cœurs pour des interconnexions à grande échelle

Exigences techniques pour la mise à l'échelle

Sélection de topologie

Dans la sélection de topologies de réseau ScaleUp, nous pouvons observer que Nvidia utilise actuellement une structure Fat Tree convergente 1:1, tandis que d'autres sociétés utilisent principalement des topologies Torus Ring ou 2D Mesh. Nvidia évoluera plus tard vers DragonFly.

La logique derrière ce choix peut être vue dans l'article de hammingMesh :

Pour la bande passante Allreduce, Torus est le plus rentable et peut essentiellement atteindre des performances maximales. Cependant, pour les modèles comme MoE qui nécessitent AlltoAll, la bande passante de bissection doit être prise en compte. DragonFly fonctionne bien en termes de complexité de câblage, de bande passante globale et de diamètre de réseau.

Routage dynamique et transmission fiable

Alors que tout le monde critique les défauts de RoCE, le fait est que BF3+Spectrum-4 dispose d'un routage adaptatif, Broadcom dispose du DLB/GLB pour faire évoluer le Packet Spraying, et il existe également des technologies VoQ similaires à celles de Cisco. Meta dispose également d'un routage statique multi-chemins pour l'ingénierie du trafic ou la planification d'affinité dans le plan de contrôle.

Toutefois, ces solutions ne peuvent résoudre qu’une partie des problèmes à l’échelle de dizaines de milliers de cartes. Le véritable défi réside dans la mise à l’échelle de centaines de milliers de cartes. Comment pouvons-nous résoudre ce problème ?

La résolution algorithmique des sursauts est une tâche difficile, et le plus difficile est que personne n’essaie de comprendre la cause profonde des sursauts. Au lieu de cela, ils essaient constamment de tester les tampons de commutation pour atténuer les salves, et certains explorent même les réseaux déterministes et l'analyse de Fourier. C’est tout simplement passer à côté de l’essentiel.

Il s’agit d’un problème très difficile, et il reste à voir quand les autres acteurs de l’industrie le comprendront. Un autre aspect est la défaillance du système et la mise à l’échelle élastique. L'article NSDI24 de Google mentionne les raisons de la fragmentation.

Si ces problèmes ne sont pas pris en compte, cela entraînera des problèmes de planification. Un bon choix pourrait être l’implémentation de la table de routage au sein d’ICI, couplée à des commutateurs OCS.

Pourquoi est-il important qu’Ethernet prenne en charge ScaleUP ? Parce qu'Ethernet doit implémenter ici une couche de routage pour prendre en charge DragonFly et les capacités de commutation de liaison défaillante.

La latence est-elle importante pour la mise à l’échelle ?

L'essence de cette question est de savoir comment les GPU effectuent le masquage de latence et les différences de latence entre NVLink et RDMA. Il est important de noter que les GPU sont par nature des processeurs à débit optimisé, et s'ils devaient rechercher une faible latence, cela indiquerait des problèmes de mise en œuvre. Le problème fondamental est que NVLink utilise la sémantique de la mémoire, tandis que RDMA utilise la sémantique des messages, et la mise en œuvre de RDMA pour l'informatique hétérogène présente également des défis.

Lacunes de la mise en œuvre du RDMA

Le facteur clé provoquant une latence plus élevée dans RDMA par rapport à NVLink est le processeur.

Nvidia résout ce problème via GDA-KI, qui permet de masquer plus efficacement de nombreuses latences d'accès à la mémoire.

Accès à la mémoire à grain fin

Un autre problème est que NVLink est basé sur la sémantique de la mémoire et dispose d'un grand nombre d'accès Load/Store à granularité fine, ce qui rend l'efficacité de la transmission et la latence très importantes. Mais comment cela peut-il être réalisé avec Ethernet RDMA ? Cela nécessiterait HPC Ethernet, car les paquets seraient trop volumineux.

C'est le problème dont j'ai discuté dans NetDAM : la nécessité d'une sémantique semi-treillis pour les messages RDMA :

• La commutativité garantit que les données peuvent être soumises de manière désordonnée.
• L'idempotence résout le problème d'ambiguïté des paquets abandonnés et des retransmissions, mais pour des opérations telles que la réduction avec effets secondaires, une idempotence basée sur les transactions ou les données est requise.
• L'associativité contribue à améliorer l'efficacité de la transmission pour des accès mémoire précis grâce à la planification.

Pour les besoins d'accès à la mémoire, le protocole interne à l'hôte est généralement de taille FLIT. Pour prendre en charge cela tout en permettant des interconnexions ScaleUP à ultra-échelle, la fiabilité, les en-têtes de routage, les en-têtes Ethernet, l'isolation multi-tenant (en-têtes VPC), etc., la clé est de tirer parti de l'associativité. Cependant, l’UEC semble avoir complètement manqué cela, se contentant de prendre en charge la commutativité et l’idempotence dans RUDI.

La solution de Nvidia est le codage associativité, qui résout le problème d'accès à granularité fine.

La prochaine génération de NVLink convergera probablement avec Infiniband, et les réseaux ScaleOut et ScaleUP finiront par fusionner.

Mise en pool de mémoire pour ScaleUP

De nombreux grands modèles souffrent aujourd'hui de la capacité limitée de la HBM (High-Bandwidth Memory). Bien que NVIDIA ait résolu ce problème en connectant Grace et NVLink C2C pour étendre la mémoire, le problème fondamental est que la mise en réseau ScaleUP nécessite un pool de mémoire.

Conclusions

1. Toute entreprise souhaitant mettre en œuvre Ethernet ScaleUP doit prendre en compte les principaux défis suivants :
2. La latence n'est pas aussi critique. En modifiant les modèles d'accès à la mémoire GPU pour les aligner sur la sémantique des messages, puis en mettant en cache le traitement, la latence peut être masquée.
3. Les capacités de routage dynamique et d’isolation des locataires du réseau ScaleUP sont cruciales. Des solutions de routage efficaces sont nécessaires, notamment pour résoudre les problèmes de fragmentation provoqués par les défaillances de liaison.
4. La sémantique RDMA (Remote Direct Memory Access) est imparfaite, et la simple copie de SHARP (Scalable Hierarchical Aggregation and Reduction Protocol) présente de nombreux pièges. Une sémantique Semi-Lattice est requise, prenant en charge une série d'opérations à effets secondaires pour atteindre l'idempotence.
5. Le transfert multivoies de la structure et le contrôle de la congestion sont nécessaires pour améliorer l’utilisation globale de la structure.
6. Une mise en commun de mémoire à grande échelle est essentielle.