Topologies de fabric GPU

Le réseau d’un cluster IA se construit en couches, et chaque couche utilise des interconnexions différentes — et des optiques différentes. Comprendre ces couches explique pourquoi un cluster comporte autant de transceivers, et où un module défaillant fait le plus mal.

Scale-up vs scale-out

	Scale-up	Scale-out
Connecte	des GPU au sein d’un serveur ou d’une baie	des serveurs entre eux
Technologie	liaisons GPU-à-GPU propriétaires (p. ex. NVLink/NVSwitch)	InfiniBand ou Ethernet/RoCE
Support	fonds de panier et câbles cuivre, de plus en plus d’optiques entre les baies	optiques enfichables : OSFP 400G/800G, QSFP-DD
Bande passante par GPU	la plus élevée	élevée, partagée avec le fabric

Les transceivers enfichables se trouvent surtout dans la couche scale-out — chaque serveur GPU a plusieurs ports 400G/800G vers le fabric, plus un réseau front-end/stockage séparé.

Fat-tree et non bloquant

Le fabric scale-out est généralement un fat-tree (Clos) : les commutateurs leaf connectent les serveurs, les commutateurs spine connectent les leaves, avec suffisamment de liaisons montantes leaf-spine pour que n’importe quel serveur puisse parler à n’importe quel autre à plein débit (non bloquant). La plupart des optiques d’un cluster sont ces liaisons leaf-spine et serveur-leaf — des milliers de modules DR4/DR8 identiques.

Conception optimisée par rail

Le trafic d’entraînement est dominé par des opérations collectives entre les GPU de même rang sur différents serveurs. Une topologie optimisée par rail exploite cela : le GPU 0 de chaque serveur se connecte au commutateur leaf 0, le GPU 1 au leaf 1, et ainsi de suite, si bien que les GPU de même rang ne sont séparés que d’un saut et que les opérations collectives ne traversent jamais le spine. Conséquence pour l’optique : un défaut sur un seul rail affecte une position de GPU dans chaque serveur — un motif qu’il vaut la peine de reconnaître.

Réseaux séparés

Un cluster fait généralement tourner plusieurs fabrics physiquement séparés :

Fabric de calcul — GPU-à-GPU (IB ou RoCE), le plus grand et le plus gourmand en optiques.
Fabric de stockage — vers les systèmes de fichiers parallèles et le stockage objet, souvent en Ethernet (réseaux de stockage).
Front-end / gestion — accès utilisateur, orchestration, télémétrie.

Chacun a son propre inventaire d’optiques et ses propres règles de validation constructeur.

Pourquoi une seule mauvaise liaison compte autant

Une opération collective se termine à la vitesse de son participant le plus lent. Un seul transceiver avec une voie qui se dégrade — plus de corrections FEC, des retransmissions occasionnelles — allonge la latence de queue de chaque étape et peut coûter une fraction mesurable du débit de tout le cluster. C’est pourquoi les opérateurs IA suivent la tendance du DDM par voie sur l’ensemble du parc et remplacent les optiques de manière proactive (Transceivers dans les clusters IA).

Dans CodingBox

Qualifiez les optiques sur l’établi avant leur installation dans un rail : identité selon CMIS, référence de DDM par voie sur l’écran DDM, et un enregistrement dans la code database pour que l’historique d’un module soit disponible quand un rail commence à montrer des erreurs.

Les adaptateurs à l’extrémité GPU de ces fabrics — BlueField, ConnectX-8 SuperNIC, Pensando — et leurs optiques OSFP à double port : SmartNIC et DPU.

Si vous trouvez une inexactitude ou une erreur dans cet article, sélectionnez le passage concerné et appuyez sur Ctrl+Enter pour .