Même débit annoncé, nouvelle question
Notre comparaison entre le MI455X et Rubin partait de la mémoire : 432 Go de HBM4 chez AMD, 288 Go chez NVIDIA, puis 3,6 To/s de scale-up annoncés de chaque côté. Ce dossier commence là où le précédent s’arrêtait. Une fois les GPU reliés au même débit de pointe, que fait le fabric avec les données qui le traversent ?
La question est devenue concrète le 7 avril 2026. Le consortium UALink a publié sa spécification Common 2.0 avec une fonction d’in-network compute. Le switch peut participer à certaines réductions, agrégations et synchronisations au lieu de déplacer chaque opérande jusqu’à un accélérateur chargé de terminer l’opération. NVLink possède déjà ce principe sous le nom SHARP ; NVLink 6 le porte à l’intérieur du rack Vera Rubin avec une puissance FP8 annoncée.
Cette évolution ne transforme pas le réseau en GPU. Un switch sait exécuter un jeu borné d’opérations sur les flux qu’il achemine. Il ne lance ni couche d’attention ni multiplication de matrices générale. Son intérêt se trouve précisément dans cette spécialisation : additionner des valeurs qui passent déjà par ses ports coûte moins de mouvements que les livrer intactes à un endpoint, attendre son calcul, puis renvoyer le résultat.
Le duel ne porte donc plus uniquement sur la largeur du lien. Il porte sur trois étages : la sémantique qui décrit une opération, le silicium du switch qui l’exécute et la bibliothèque collective qui décide de l’utiliser. Une spécification sans implémentation ne réduit aucune latence ; un moteur de réduction sans chemin logiciel reste inutilisé.
Ce que le switch retire réellement à l’all-reduce
Un all-reduce combine une valeur détenue par chaque GPU, une somme de gradients par exemple, puis remet le résultat complet à tous les participants. Sans calcul dans le réseau, les GPU ou leurs contrôleurs lisent les buffers, envoient les fragments, additionnent les valeurs reçues et propagent le résultat selon un anneau ou un arbre. Le fabric transporte ; les endpoints réduisent.
Avec l’in-network compute, un switch reçoit plusieurs fragments correspondant à la même position, calcule une somme partielle et ne transmet que cette valeur agrégée vers l’étage suivant. Le chemin ressemble à un arbre d’addition câblé dans l’interconnexion. Il déplace une partie du calcul et de la synchronisation hors des GPU, là où les données passent déjà.
Le gain n’est pas une suppression magique du trafic. Chaque GPU doit encore injecter sa contribution et recevoir le résultat final. Un anneau logiciel mature répartit déjà le calcul entre les participants et approche le plafond de bande passante sur les gros messages. Le moteur dans le switch attaque surtout les copies redondantes, les passages par la HBM et les barrières d’endpoint. Son avantage dépend donc de la taille du message, du nombre de rangs, de la topologie et de la part du collectif que le runtime réussit à recouvrir avec du calcul utile.
Cette limite sépare deux familles de charges. Un gros all-reduce d’entraînement laisse assez de données pour remplir les liens ; la bande passante soutenue décide. Un all-reduce répété à chaque couche de tensor parallelism Découpage d'une même couche de réseau de neurones entre plusieurs accélérateurs. Chaque GPU calcule une sortie partielle, puis une opération collective réunit les fragments avant la couche suivante. Plus le découpage est large, plus la latence et le débit de l'interconnexion pèsent sur le temps d'un token. ajoute des rendez-vous plus courts sur le chemin critique ; la latence de lancement, le débit de paquets et l’offload pèsent davantage. L’in-network compute n’a pas un facteur d’accélération unique, parce qu’il ne retire pas le même coût dans ces deux régimes.
UALink 2.0 : une sémantique avant un produit
UALink Ultra Accelerator Link. Standard ouvert de communication scale-up entre accélérateurs. Il expose des lectures, écritures et opérations atomiques dans un espace d'adressage réparti, avec une cohérence gérée par le logiciel. AMD l'emploie sur Ethernet dans Helios sous le nom UALoE. 200G 1.0 définit un fabric scale-up à sémantique mémoire. Un accélérateur peut émettre des lectures, des écritures et des opérations atomiques vers la mémoire d’un pair. Le livre blanc promet le même modèle d’ordre d’adresses pour la mémoire locale et distante ; il ne décrit pas pour autant un cache matériel cohérent à l’échelle du pod. Le protocole donne ainsi au runtime des primitives plus directes qu’une pile réseau classique sans transformer les HBM distribuées en une mémoire physiquement unique.
Le lien fonctionne à 200 GT/s par lane. Quatre lanes forment une station capable d’émettre 800 Gbit/s et d’en recevoir autant. UALink prend en charge des requêtes de 64, 128, 192 ou 256 octets ; le consortium relie la limite de 256 octets à l’entrelacement de la HBM des accélérateurs. Son livre blanc fixe aussi un objectif de moins d’une microseconde pour un aller-retour requête-réponse dans un pod pouvant atteindre 1 024 accélérateurs. C’est un objectif d’architecture, pas une latence mesurée sur Helios.
Common 2.0 ajoute l’in-network compute au-dessus de ce transport. Le consortium cite les réductions, les agrégations, les synchronisations, les primitives collectives, certaines transformations de données et des optimisations d’ordonnancement. Les pages de présentation librement consultables ne donnent cependant ni débit d’opérations, ni résultat d’un collectif sur une implémentation commerciale. La norme dit comment exposer une capacité. Elle ne prouve pas combien de silicium un fabricant lui consacre.
UALink 2.0 sépare aussi sa couche commune des couches liaison et physique 200G. Le protocole collectif peut ainsi évoluer sans changer à chaque fois la signalisation électrique. Une spécification de manageability distincte décrit un plan de contrôle centralisé fondé sur gNMI, YANG, SAI et Redfish. Cette séparation est le pari d’UALink : plusieurs vendeurs peuvent faire évoluer le PHY, le switch, l’accélérateur et l’administration derrière des interfaces communes.
Le mot ouvert exige pourtant une précision. La spécification est disponible publiquement sous licence d’évaluation, mais l’interopérabilité ne découle pas de sa publication. Le consortium indiquait encore en avril 2026 que ses programmes de conformité et d’interopérabilité seraient introduits ultérieurement. Tant que deux implémentations indépendantes n’ont pas passé la même suite de tests, « standard multi-vendeur » décrit l’objectif de l’écosystème, pas un rack déjà interchangeable composant par composant.
UALoE dans Helios : le chiffre se reconstruit
AMD n’emploie pas un fabric construit directement sur les couches liaison et physique UALink 200G dans Helios. Son architecture UALink over Ethernet, ou UALoE, transporte UALink sur un réseau Ethernet ; AMD et Broadcom présentent la solution commune sur des switches Tomahawk et le cadre eSUN. UALoE désigne ici une architecture produit AMD, pas une révision supplémentaire publiée par le consortium UALink. Les 72 MI455X rejoignent douze ASICs de commutation répartis dans six trays. La topologie est multi-plane et à un seul saut : entre deux GPU, les données traversent un switch, avec plusieurs chemins disponibles.
Chaque GPU possède dix-huit stations UALoE. AMD ne publie pas séparément leur débit sur la page Helios. Si le mot station reprend la largeur x4 définie par UALink 200G 1.0, chacune transporte 800 Gbit/s dans chaque direction, soit 100 Go/s. Dix-huit stations donnent alors 1,8 To/s en émission et 1,8 To/s en réception, ou 3,6 To/s lorsque les deux directions sont additionnées. Le résultat coïncide avec le chiffre AMD, ce qui rend cette reconstruction crédible ; il ne remplace ni une spécification électrique UALoE ni une mesure applicative.
Le total rack suit la même logique. Multiplier 72 GPU par 3,6 To/s donne 259,2 To/s, arrondis à 260 To/s agrégés. Ce nombre compte les interfaces des endpoints dans les deux directions. Il ne donne ni la bissection du réseau, ni le débit utile d’un all-reduce, ni la quantité de trafic supportée par un chemin lorsque plusieurs plans sont chargés en même temps.
AMD documente un mécanisme de résilience : les dix-huit stations sont réparties entre les trays ; la perte d’un lien, d’un câble ou d’un switch déclenche un reroutage sur les chemins restants. AMD Fabric Manager et AMD Fabric OS gèrent le provisionnement, la télémétrie et la reprise. Des vPods découpent les 72 GPU en domaines isolés pour plusieurs charges concurrentes.
Ces fonctions rendent UALoE exploitable comme fabric de rack. Elles ne répondent pas encore à la question de cet article. HPE identifie les ASICs scale-up d’Helios comme des Broadcom Tomahawk 6. Broadcom documente ses collectifs dans le réseau sur une autre famille, Tomahawk Ultra BCM78920. Les pages Helios et les documents techniques AMD consultés ne précisent pas quelle révision de la spécification Common est exposée, ne revendiquent pas ce moteur dans les switches UALoE et ne publient pas son activation dans RCCL. Il serait donc incorrect d’attribuer automatiquement les fonctions de Common 2.0 au rack Helios.
NVLink 6 : SHARP possède déjà un chemin logiciel
NVLink Interconnexion propriétaire NVIDIA entre GPU. NVLink 5 (Blackwell) atteint 1,8 To/s bidirectionnels par GPU ; NVLink 6 (Rubin) double à 3,6 To/s. Avec NVSwitch, elle accélère les échanges GPU-GPU et les collectifs ; les mémoires restent physiquement distribuées et un accès distant n'a pas le coût de la HBM locale. Approfondir dans le glossaire 6 relie les 72 GPU Rubin à 36 ASICs NVLink Switch dans une topologie all-to-all à un seul saut. NVIDIA annonce également 3,6 To/s bidirectionnels par GPU et 260 To/s agrégés sur le NVL72. Une switch tray contient quatre ASICs, fournit 28,8 To/s de bande passante annoncée et 14,4 TFLOPS FP8 d’in-network compute. Le rack atteint ainsi 130 TFLOPS FP8 arrondis.
Cette puissance exécute SHARP, le protocole NVIDIA d’agrégation et de réduction hiérarchique. Les switches prennent en charge une partie de l’all-reduce, du reduce-scatter et de l’all-gather. NCCL expose déjà NVLink SHARP sous le nom NVLS ; la documentation des systèmes NVLink permet de l’activer ou de le désactiver avec NCCL_NVLS_ENABLE. Le chemin entre framework, bibliothèque collective et switch est donc documenté, même si les mesures publiques portent encore sur des générations antérieures ou sur des chiffres NVIDIA.
NVIDIA attribue à SHARP dans NVLink 6 jusqu’à 50 % de trafic d’all-reduce en moins et jusqu’à 20 % de temps gagné en tensor parallelism. Ces nombres restent des résultats constructeur. La page technique ne fournit ni modèle complet, ni taille des messages, ni nombre précis de participants, ni configuration NCCL permettant de les reproduire sur Rubin. Elle précise elle-même que le résultat dépend de l’architecture du modèle, de la stratégie de parallélisme, du nombre de participants et de la configuration NCCL.
La même prudence s’applique à la latence. NVIDIA revendique une latence de bout en bout trois fois plus faible et un débit de paquets dix fois supérieur à des solutions Ethernet « sur étagère ». Le comparateur n’est pas Helios, et aucune valeur absolue n’est donnée. UALoE emploie des ASICs et un protocole spécialisés, pas une configuration Ethernet d’entreprise. Utiliser ces deux ratios comme une mesure NVLink 6 contre UALoE serait une extrapolation sans base commune.
Ce que les fiches permettent de comparer
| Critère | UALink 2.0 / Helios UALoE | NVLink 6 / Vera Rubin | Ce que cela prouve |
|---|---|---|---|
| Débit par GPU | 3,6 To/s bidirectionnels | 3,6 To/s bidirectionnels | Même somme de débits de bord |
| Domaine annoncé | 72 GPU Helios, un saut, multi-plane | 72 GPU NVL72, un saut, all-to-all | Même taille de rack, fabrics distincts |
| Débit rack | 260 To/s agrégés | 260 To/s agrégés | 72 × 3,6 To/s, pas un all-reduce |
| Calcul dans le réseau | Prévu par Common 2.0 ; débit Helios non publié | SHARP ; 130 TFLOPS FP8 annoncés | Intégration mieux documentée chez NVIDIA |
| Gain collectif | Aucun résultat Helios public identifié | Jusqu'à -50 % de trafic et -20 % de temps TP, selon NVIDIA | Pas de comparaison reproductible |
| Latence | Objectif UALink 1.0 inférieur à 1 µs ; aucune mesure Helios | Ratio 3× contre Ethernet sur étagère ; aucune valeur absolue | Chiffres non comparables |
| Logiciel public | RCCL exécute les collectifs ; chemin INC UALoE non documenté | NCCL documente NVLink SHARP / NVLS | Avantage de visibilité pour NVIDIA |
| Interopérabilité | Spécification ouverte ; programme de conformité à venir | Pile NVIDIA intégrée | Ouverture visée contre intégration livrée |
La seule égalité robuste se trouve dans la bande passante bidirectionnelle annoncée aux GPU. Sur tout le reste, les colonnes ne contiennent pas la même nature de preuve. UALink publie des interfaces et des objectifs de protocole ; AMD publie une topologie de produit sans métriques collectives ; NVIDIA publie davantage de détails d’intégration, accompagnés de gains qu’il mesure lui-même.
Cette asymétrie interdit deux raccourcis. Le premier serait de conclure que NVLink gagne parce que SHARP possède un nombre de TFLOPS. Sans workload commun, 130 TFLOPS de réduction ne donnent pas le temps d’un collectif. Le second serait de conclure qu’UALink rattrape NVLink parce que Common 2.0 contient la même catégorie de fonction. Une opération inscrite dans une norme ne donne ni surface de silicium, ni cadence, ni support dans le runtime.
Le benchmark qui manque
Départager les fabrics demande moins de colonnes marketing et davantage de courbes. Le premier axe est la taille de message : de quelques kilo-octets à plusieurs gigaoctets, avec la latence et le débit utile d’all-reduce, reduce-scatter, all-gather et all-to-all. Le deuxième est le nombre de participants : 4, 8, 18, 36 puis 72 GPU. Le troisième est la concurrence : un collectif isolé ne montre ni la congestion créée par plusieurs modèles ni l’isolation entre vPods ou partitions NVLink.
Le test doit ensuite réintroduire le calcul. Un benchmark all_reduce_perf mesure la bibliothèque et le fabric, mais pas la capacité du runtime à recouvrir le collectif avec un kernel. Il faut donc exécuter le même modèle, le même format et le même parallélisme, puis relever le temps GPU consacré à la communication, le TPOT et le débit à latence contrainte. Pour un MoE, l’all-to-all doit rester séparé : une réduction dans le switch n’accélère pas automatiquement le routage d’activations distinctes vers chaque expert.
La résilience appartient au protocole de mesure. Le fabric est chargé, un lien ou une switch tray disparaît, puis la courbe suit le temps de convergence, les requêtes perdues et le débit après reroutage. Une architecture multi-plane peut conserver le service en perdant une fraction de sa capacité ; une topologie intégrée peut isoler le défaut plus vite. Les deux fabricants revendiquent cette continuité, aucun ne publie un essai identique.
De notre point de vue, le gagnant de 2026 n’est donc pas celui qui affiche 260 To/s. C’est celui qui rendra publique la première matrice complète : taille de message, collectif, participants, concurrence, pannes et énergie, avec la configuration logicielle nécessaire pour reproduire le résultat.
L’ouverture devra se mesurer dans le switch
UALink 2.0 change la nature du duel. Le consortium ne cherche plus seulement à fournir une autre liaison rapide ; il standardise le moment où le réseau participe au calcul. C’est la bonne frontière technique, parce que les collectifs sont devenus une partie du programme distribué et non un simple transfert entre deux kernels.
NVLink 6 part avec une avance visible : SHARP possède du silicium chiffré et un chemin NCCL documenté. UALink possède une autre force, la possibilité de séparer les fournisseurs du GPU, du switch, du PHY et du logiciel. Cette force restera théorique tant qu’un produit UALink 2.0 interopérable ne publiera pas ses types d’opérations, son débit et ses résultats collectifs.
La prochaine bataille ne sera donc pas 3,6 contre 3,6 To/s. Elle commencera lorsque deux switches recevront le même buffer, exécuteront la même réduction et exposeront le même compteur de temps. À cet instant, l’ouverture et l’intégration cesseront d’être des architectures promises ; elles deviendront des performances observables.
Sources et méthode
Spécifications UALink, faits vérifiés. Page officielle des spécifications UALink pour la disponibilité de Common 2.0, des couches liaison/physique 200G 2.0 et de Manageability 1.0. Annonce de ratification du 7 avril 2026 pour le périmètre de l’in-network compute, la séparation des couches et le statut futur des programmes de conformité. Livre blanc UALink 200G 1.0 pour les 200 Gbit/s par lane, la station x4 à 800 Gbit/s dans chaque direction, la cible de moins d’une microseconde et le domaine allant jusqu’à 1 024 accélérateurs. Questions techniques du consortium pour les tailles de requêtes, les cibles de latence port à port et l’absence de bornes normatives de latence et de bande passante par interface.
In-network compute UALink, faits vérifiés et limite documentaire. Présentation technique du consortium pour les catégories d’opérations citées : réductions, agrégations, synchronisation, primitives collectives, transformations et ordonnancement. Le constat qu’aucun débit produit ni benchmark Helios n’est publié est limité aux sources officielles librement consultables au 30 août 2026 ; il ne prouve pas l’absence d’une implémentation non publique.
AMD Helios et UALoE, faits constructeur. La fiche officielle AMD Helios donne 72 GPU, 260 To/s agrégés, deux ASICs par switch tray et une topologie UALoE multi-plane. Le blueprint Helios de juillet 2026 et la description technique ROCm documentent six switch trays et douze switches au total. La présentation AMD de la pile réseau fournit les dix-huit stations par GPU, le chemin à un saut, le reroutage, Fabric Manager, Fabric OS et les vPods. La session technique AMD et Broadcom relie Helios à des switches Tomahawk et au cadre eSUN ; l’annonce officielle HPE précise qu’il s’agit de Tomahawk 6. La fiche Broadcom Tomahawk Ultra BCM78920 attribue les collectifs dans le réseau à cette famille distincte. Ces pages sont des sources fabricant ; aucun gain de performance AMD n’est traité comme une mesure indépendante.
NVIDIA NVLink 6 et SHARP, faits constructeur. Fiche officielle NVLink et NVLink Switch pour les 3,6 To/s par GPU, 260 To/s par NVL72, 36 liens maximum et le support SHARP. Description technique de NVLink 6 pour les 36 switch ASICs, les quatre ASICs et 14,4 TFLOPS FP8 par tray, les 130 TFLOPS rack et les fonctions de résilience. Architecture Vera Rubin pour les gains revendiqués de 50 % sur le trafic d’all-reduce et de 20 % sur le temps du tensor parallelism. Ces deux gains sont attribués à NVIDIA et ne sont pas présentés comme indépendants.
Chemin logiciel, faits vérifiés. Guide NVIDIA des systèmes NVLink multi-nœuds pour l’activation de NVLink SHARP avec NCCL_NVLS_ENABLE. Dépôt officiel RCCL pour les collectifs pris en charge et les algorithmes en anneau ou en arbre. La documentation RCCL publique consultée ne décrit pas de commutateur activant l’in-network compute UALoE sur Helios.
Calculs dérivés. Le passage de dix-huit stations UALoE à 3,6 To/s suppose qu’une station UALoE conserve la largeur x4 de la station UALink 200G 1.0 : 800 Gbit/s par direction équivalent à 100 Go/s, puis dix-huit stations donnent 1,8 To/s par direction. Cette interprétation retrouve le chiffre AMD, mais reste une estimation documentée faute de débit UALoE unitaire publié. Le calcul du total rack est, lui, purement arithmétique : soixante-douze interfaces à 3,6 To/s donnent 259,2 To/s, arrondis à 260. Aucun de ces calculs ne prédit un débit utile.
Ce qui n’est pas affirmé. Aucun vainqueur de performance n’est désigné. Aucune mesure publique commune de latence absolue, de débit collectif, d’énergie ou de comportement sous panne n’a été identifiée pour Helios UALoE et Vera Rubin NVLink 6 au 30 août 2026. Le ratio NVIDIA de latence 3× et de débit de paquets 10× compare NVLink 6 à un Ethernet sur étagère non spécifié, pas directement à UALoE ; il n’est donc pas utilisé pour classer les deux fabrics.
