Conception de la topologie réseau pour clusters GPU : Architectures Fat-Tree, Dragonfly et Rail-Optimized

Mis à jour le 11 décembre 2025

Mise à jour de décembre 2025 : DGX SuperPOD spécifiant une architecture fat-tree à trois niveaux avec des commutateurs Quantum-2 InfiniBand (400 Gb/s). Une étude Meta révélant que les erreurs de configuration réseau causent 10,7 % des défaillances significatives des tâches GPU. La bande passante de bisection complète est critique pour l'entraînement distribué où les schémas de communication évoluent dynamiquement. Les pods TPU de Google utilisent un torus 3D ; AWS Trainium utilise des topologies optimisées pour les charges de travail.

L'architecture de référence DGX SuperPOD de NVIDIA spécifie une topologie réseau fat-tree à trois niveaux connectant jusqu'à 32 systèmes DGX utilisant des commutateurs Quantum-2 InfiniBand à 400 Gb/s par port.[^1] L'architecture offre une bande passante de bisection complète, ce qui signifie que la bande passante agrégée entre deux moitiés quelconques du cluster égale la bande passante totale entrant dans l'une ou l'autre moitié. Les topologies fat-tree dominent les déploiements de clusters GPU car elles fournissent des performances prévisibles indépendamment des paires de GPU qui communiquent, une propriété critique pour l'entraînement distribué où les schémas de communication évoluent dynamiquement.

Les choix de topologie réseau affectent directement les performances d'entraînement, le coût et la complexité opérationnelle. Une étude Meta a révélé que les erreurs de configuration réseau causaient 10,7 % des défaillances significatives des tâches dans leurs clusters GPU, avec une congestion dépendante de la topologie contribuant à la variabilité des performances.[^2] Les pods TPU de Google utilisent des topologies torus 3D permettant des connexions directes entre accélérateurs voisins, tandis que les clusters AWS Trainium emploient différentes topologies optimisées pour leurs schémas de charge de travail.[^3] Comprendre les compromis topologiques permet aux organisations de sélectionner des architectures correspondant à leurs exigences spécifiques de charge de travail et contraintes budgétaires.

Fondamentaux de la topologie fat-tree

La topologie fat-tree trouve son origine dans les travaux de Charles Leiserson de 1985 montrant que les structures arborescentes pouvaient atteindre une bande passante de bisection complète si la capacité des liens augmentait vers la racine.[^4] Les implémentations modernes utilisent des liens de capacité égale partout, atteignant la pleine bande passante grâce à de multiples chemins parallèles plutôt que des liens plus épais.

Architecture fat-tree à trois niveaux

Un fat-tree à trois niveaux se compose de commutateurs feuilles connectés aux serveurs, de commutateurs spine agrégeant le trafic des feuilles, et de commutateurs core fournissant une connectivité complète entre les spines.[^5] Chaque commutateur feuille se connecte à chaque commutateur spine, et chaque spine se connecte à chaque commutateur core. Le maillage des connexions crée de multiples chemins à coût égal entre deux serveurs quelconques.

NVIDIA recommande le fat-tree pour les clusters DGX en raison des caractéristiques prévisibles de latence et de bande passante.[^6] La topologie garantit que les opérations collectives comme all-reduce bénéficient de performances constantes indépendamment du placement des GPU. Les tâches d'entraînement n'ont pas besoin de considérer la topologie réseau lors de la planification, simplifiant la gestion du cluster.

Ratios de sur-souscription

La bande passante de bisection complète nécessite une capacité de commutation coûteuse aux niveaux supérieurs. De nombreux déploiements acceptent la sur-souscription, où la bande passante agrégée des liaisons montantes des niveaux inférieurs dépasse la capacité disponible aux niveaux supérieurs.[^7] Un ratio de sur-souscription de 2:1 signifie que seulement la moitié du trafic pourrait simultanément traverser les niveaux supérieurs.

La sur-souscription convient aux charges de travail avec localité, où la plupart des communications se produisent au sein des racks ou des pods. Cependant, l'entraînement distribué avec des schémas de communication all-to-all sature les liens sur-souscrits, causant congestion et dégradation des performances. Les clusters d'entraînement IA nécessitent généralement des conceptions non sur-souscrites malgré le coût plus élevé.[^8]

Radix et mise à l'échelle

Le radix du commutateur détermine combien de ports chaque commutateur fournit, affectant à la fois l'échelle et le coût. Un commutateur à 64 ports construisant un fat-tree à trois niveaux avec 32 liens descendants et 32 liens montants peut atteindre 32 768 points de terminaison.[^9] Les commutateurs à radix plus élevé réduisent le nombre de commutateurs nécessaires mais augmentent le coût par commutateur.

Les commutateurs Quantum-2 de NVIDIA fournissent 64 ports à 400 Gb/s, permettant des déploiements fat-tree à grande échelle avec un nombre raisonnable de commutateurs.[^10] La prochaine génération Quantum-X800 augmente les vitesses de port à 800 Gb/s, doublant la bande passante agrégée sans changer la structure de la topologie.

Topologie rail-optimized

La topologie rail-optimized a émergé de la reconnaissance que les serveurs GPU contiennent plusieurs GPU partageant des interconnexions internes à haute vitesse. Plutôt que de traiter chaque GPU indépendamment, les conceptions rail-optimized alignent les connexions réseau avec le placement des GPU au sein des serveurs.[^11]

Comprendre les rails GPU

Un système DGX H100 contient huit GPU connectés via NVLink, chaque GPU se connectant également à une carte d'interface réseau (NIC).[^12] Les huit NIC correspondent à huit "rails" couvrant le cluster. Le rail 0 connecte le GPU 0 de chaque serveur, le rail 1 connecte le GPU 1, et ainsi de suite. La communication au sein d'un rail traverse moins de sauts de commutateurs que la communication inter-rails.

NVIDIA NVLink Switch connecte les GPU au sein et entre les serveurs à 900 Go/s de bande passante agrégée par GPU.[^13] Le domaine NVLink gère la plupart des communications GPU-à-GPU, le réseau InfiniBand gérant les communications entre domaines NVLink. La topologie rail-optimized aligne les chemins InfiniBand avec les domaines NVLink pour minimiser le trafic InfiniBand.

Considérations d'implémentation

Les déploiements rail-optimized nécessitent un câblage soigneux pour maintenir l'alignement des rails entre les racks et les pods.[^14] Les connexions mal câblées brisent la localité des rails, forçant le trafic à traverser des sauts de commutateurs supplémentaires. La discipline de gestion des câbles s'avère essentielle pour réaliser les bénéfices de l'optimisation par rails.

La topologie réduit les besoins en commutateurs par rapport au fat-tree complet à échelle équivalente. Les économies proviennent de l'élimination de la capacité de commutation inter-rails que les charges de travail rail-optimized utilisent rarement.[^15] Les organisations doivent vérifier que leurs schémas de charge de travail présentent réellement une localité de rail avant de s'engager dans des conceptions rail-optimized.

Topologie dragonfly

La topologie dragonfly organise les commutateurs en groupes avec une connectivité intra-groupe dense et des liens inter-groupes clairsemés.[^16] La conception réduit le nombre de commutateurs par rapport au fat-tree tout en maintenant des longueurs de chemin raisonnables entre deux points de terminaison quelconques.

Structure dragonfly

Un dragonfly se compose de groupes, chacun contenant plusieurs commutateurs entièrement connectés au sein du groupe. Des liens globaux connectent chaque commutateur à des commutateurs dans d'autres groupes.[^17] Deux points de terminaison quelconques se connectent en au plus trois sauts : commutateur local vers commutateur de groupe vers commutateur de groupe distant vers destination.

Le nombre réduit de sauts diminue la latence pour les déploiements à grande échelle. Moins de commutateurs réduisent le coût en capital et la consommation d'énergie. Cependant, le dragonfly fournit une bande passante de bisection inférieure au fat-tree, le rendant plus susceptible à la congestion sous certains schémas de trafic.[^18]

Exigences de routage adaptatif

Les performances du dragonfly dépendent fortement du routage adaptatif qui distribue le trafic sur les chemins disponibles.[^19] Le routage statique concentre le trafic sur des liens spécifiques, causant de la congestion tandis que d'autres chemins restent sous-utilisés. Les commutateurs doivent surveiller l'utilisation des liens et déplacer dynamiquement le trafic vers des chemins moins chargés.

NVIDIA InfiniBand prend en charge le routage adaptatif adapté aux déploiements dragonfly.[^20] Cette capacité nécessite une configuration et des tests pour s'assurer que les algorithmes de routage répondent de manière appropriée aux schémas de trafic des charges de travail. Un routage adaptatif mal configuré peut performer moins bien que le routage statique.

Sensibilité à la charge de travail

Le dragonfly convient aux charges de travail avec des schémas de communication localisés qui maintiennent la plupart du trafic au sein des groupes.[^21] Les charges de travail générant du trafic aléatoire uniforme sur tous les points de terminaison sollicitent les liens inter-groupes au-delà de leur capacité. La topologie fonctionne bien pour le service d'inférence avec affinité de requête mais peut avoir des difficultés avec l'entraînement à grande échelle utilisant des opérations collectives globales.

Les organisations évaluant le dragonfly devraient caractériser les schémas de communication attendus des charges de travail avant le déploiement. Des outils de simulation peuvent modéliser les performances attendues sous un trafic réaliste, identifiant les points de congestion potentiels nécessitant un ajustement de la topologie.[^22]

Topologies torus et mesh

Les topologies torus connectent les nœuds selon des schémas de grille réguliers avec des connexions de bouclage aux frontières. Les pods TPU de Google utilisent des topologies torus 3D fournissant des connexions directes aux voisins sans commutation.[^23]

Réseaux directs versus commutés

Les réseaux torus connectent chaque nœud directement à ses voisins, éliminant les commutateurs du chemin de communication.[^24] La connexion directe réduit la latence pour la communication voisin-à-voisin commune dans de nombreux algorithmes parallèles. Cependant, la communication entre nœuds distants traverse plusieurs nœuds intermédiaires, augmentant la latence et consommant de la bande passante à chaque saut.

Les réseaux commutés comme le fat-tree fournissent une latence égale entre deux points de terminaison quelconques indépendamment du placement physique. L'uniformité simplifie la programmation et l'équilibrage de charge. Les réseaux torus nécessitent un placement conscient de la topologie pour minimiser les distances de communication.[^25]

Sélection des dimensions

Les topologies torus de dimension supérieure réduisent le diamètre (nombre maximum de sauts) au prix d'un nombre accru de connexions par nœud.[^26] Un torus 3D avec N nœuds par dimension a un diamètre de 3N/2, tandis qu'un torus 2D a un diamètre de N. Le choix de Google d'un torus 3D équilibre le nombre de connexions par rapport au diamètre.

Les contraintes physiques affectent la sélection des dimensions. Un torus 2D se mappe naturellement aux rangées et colonnes dans une salle de machines. Un torus 3D nécessite soit des racks empilés soit des connexions couvrant des distances substantielles. Les longueurs de câbles dans un torus de haute dimension peuvent devenir problématiques à grande échelle.[^27]

Cadre de sélection de topologie

La sélection de la topologie réseau nécessite d'évaluer les caractéristiques de la charge de travail, les exigences d'échelle, les contraintes budgétaires et les capacités opérationnelles.

Analyse de la charge de travail

Différentes charges de travail sollicitent les réseaux différemment. L'entraînement de grands modèles de langage génère des schémas de communication all-to-all nécessitant une bande passante de bisection élevée.[^28] Le service d'inférence avec mise en lots présente une communication plus localisée au sein des groupes de GPU servant les requêtes. Le prétraitement des données peut générer des schémas de shuffle avec communication aléatoire.

Les organisations devraient profiler les charges de travail attendues pour comprendre les schémas de communication. La surveillance des clusters de production révèle les schémas de trafic réels pour les charges de travail existantes. Les nouveaux types de charges de travail peuvent nécessiter une estimation basée sur l'analyse des algorithmes ou les conseils des fournisseurs.

Considérations d'échelle

Les petits clusters de dizaines de GPU peuvent ne pas nécessiter d'optimisation de topologie sophistiquée. Un seul commutateur à haut radix connectant tous les GPU fournit une connectivité complète sans complexité multi-niveaux.[^29] La sélection de topologie importe le plus pour les clusters couvrant des centaines à des milliers de GPU où les coûts de commutation et les passages de câbles deviennent significatifs.

La croissance future affecte la sélection de topologie. Un fat-tree se met à l'échelle en ajoutant des commutateurs feuilles et des serveurs tout en maintenant une bande passante de bisection complète. Un dragonfly se met à l'échelle en ajoutant des groupes mais peut nécessiter un rééquilibrage des liens globaux. Planifier la croissance évite les changements de topologie qui perturbent les opérations.[^30]

Facteurs économiques

Les coûts des commutateurs et des câbles varient significativement entre les topologies. Le fat-tree nécessite plus de commutateurs que le dragonfly à échelle équivalente. Les conceptions rail-optimized réduisent la commutation InfiniBand mais nécessitent des systèmes NVLink Switch.[^31] L'analyse du coût total doit inclure les commutateurs, câbles, optiques, alimentation, refroidissement et espace rack.

Les coûts opérationnels varient également. Les topologies complexes nécessitent des capacités de surveillance et de dépannage plus sophistiquées. Former le personnel d'exploitation aux considérations spécifiques à la topologie ajoute des coûts. Des topologies plus simples peuvent justifier des compromis de performance modestes grâce à une charge opérationnelle réduite.

Implémentation et déploiement

L'implémentation de la topologie réseau nécessite une planification soigneuse couvrant l'infrastructure physique, la configuration de la commutation et les tests de validation.

Planification de l'infrastructure physique

Les déploiements de réseau à haute vitesse nécessitent un câblage structuré supportant des milliers de connexions à 400 Gb/s ou plus.[^32] Le routage des câbles doit minimiser les violations de rayon de courbure et la dégradation du signal. Les dispositions allées chaudes/allées froides doivent accommoder les chemins de câbles sans ob

[Contenu tronqué pour la traduction]