AMD MI455X contre NVIDIA Rubin : la mémoire suffit-elle à battre NVLink ?

Le match a changé au niveau du rack

Le 23 juillet 2026, AMD a remplacé les chiffres préliminaires du MI455X par une fiche produit complète. Le GPU CDNA 5 possède 432 Go de HBM4 HBM High Bandwidth Memory. Mémoire empilée en couches, soudée à proximité immédiate du GPU, avec une bande passante de plusieurs To/s (contre ~50 Go/s pour de la DDR5). Indispensable au-delà d'une certaine taille de modèle. Approfondir dans le glossaire à 23,3 To/s, 40,3 PFLOPS de pointe en OCP MXFP4 MXFP4 Microscaling FP4. Format à blocs où 32 valeurs FP4 partagent un facteur d'échelle commun. C'est ce facteur d'échelle partagé qui permet de tenir en 4 bits sans effondrer la précision. La variante NVFP4 de NVIDIA utilise des blocs plus fins (16 valeurs). Approfondir dans le glossaire et un lien scale-up UALoE à 3,6 To/s. Deux jours plus tôt, NVIDIA avait détaillé Rubin : 288 Go de HBM4 à 22 To/s, 50 PFLOPS NVFP4 en inférence, deux dies de calcul réunis par NV-HBI et NVLink 6 NVLink Interconnexion propriétaire NVIDIA entre GPU. NVLink 5 (Blackwell) atteint 1,8 To/s par GPU ; NVLink 6 (Rubin) double à 3,6 To/s. Permet à plusieurs cartes de partager leur mémoire et de se comporter quasi comme un seul accélérateur. Approfondir dans le glossaire à 3,6 To/s.

Lu trop vite, le match paraît déjà tranché. AMD place 144 Go supplémentaires autour de chaque GPU et déplace 1,3 To de plus par seconde depuis la HBM. NVIDIA répond avec davantage de calcul 4 bits annoncé et une pile NVLink intégrée de bout en bout. Cette lecture rate pourtant le mécanisme qui décide d’une charge distribuée : un octet lu dans la HBM locale n’emprunte pas le même chemin qu’une activation attendue depuis un GPU voisin.

La question n’est donc pas « quelle fiche contient le plus grand nombre ». Elle est : à quel moment la capacité supplémentaire d’AMD évite-t-elle une communication, et que se passe-t-il quand elle ne peut plus l’éviter ?

Un GPU : 50 % de capacité en plus, 6 % de débit en plus

Caractéristique	AMD MI455X	NVIDIA Rubin	Lecture
Architecture	CDNA 5, 8 XCD + 2 IOD	2 dies de calcul reliés par NV-HBI	Deux packages multi-dies
Transistors	320 milliards	336 milliards	Ne prédit pas le débit
Mémoire	432 Go HBM4, 12 piles	288 Go HBM4	+50 % pour AMD
Bande passante HBM	23,3 To/s	22 To/s	+5,9 % pour AMD
Calcul 4 bits publié	40,3 PFLOPS OCP MXFP4	50 PFLOPS NVFP4 inférence ; 35 en entraînement	Formats et modes distincts
Scale-up par GPU	3,6 To/s UALoE, bidirectionnel	3,6 To/s NVLink 6	Égalité de pointe publiée
Disponibilité annoncée	Design Helios, livraisons S2 2026	Rubin en production, systèmes S2 2026	Calendriers constructeur

La capacité est le chiffre le plus robuste du tableau. Elle ne dépend ni d’un kernel ni d’un choix de format marketing. Le MI455X contient 432 Go physiques, Rubin 288 Go. Le rapport vaut exactement 1,5. La bande passante mémoire est elle aussi comparable : les deux constructeurs publient un débit de pointe pour la HBM4 du package complet. Les 23,3 To/s d’AMD dépassent les 22 To/s de NVIDIA de 5,9 %, un écart réel sur le papier, mais bien plus petit que celui de capacité.

Ce contraste compte pour le decode decode Phase de génération autorégressive d'un LLM : un token est produit à la fois, en relisant tout le KV cache. Intensité arithmétique très basse, le GPU passe l'essentiel du temps à attendre la mémoire. Un service d'inférence réel est presque toujours dominé par le decode. Approfondir dans le glossaire . La génération autorégressive relit les poids et le KV cache KV cache Mémoire des vecteurs clé et valeur déjà calculés pour chaque token traité par un LLM. Évite de recalculer l'attention sur tout l'historique, au prix d'une consommation mémoire qui croît avec le contexte. Approfondir dans le glossaire à chaque token. Ajouter 50 % de capacité permet de conserver davantage de poids, de contexte ou de requêtes sur le même GPU. Ajouter 5,9 % de bande passante ne promet, au plafond théorique, qu’un gain du même ordre sur une charge strictement limitée par la mémoire. La capacité change parfois le nombre de GPU nécessaires ; la bande passante change le temps d’une lecture locale.

Ce que 432 Go permettent réellement d’éviter

Une limite de capacité se raisonne avant les benchmarks. À 8 bits, un modèle de N milliards de paramètres occupe au minimum N Go de poids. À 4 bits, le plancher descend à N / 2 Go. Ces valeurs excluent les facteurs d’échelle, les métadonnées de quantification, les buffers du runtime et le KV cache : elles décrivent un minimum physique, pas une configuration déployable.

Sur cette base, 288 Go peuvent contenir au plus 288 milliards de paramètres à 8 bits, contre 432 milliards pour le MI455X. À 4 bits, les plafonds bruts passent respectivement à 576 et 864 milliards de paramètres. Dans les deux cas, il faut garder une marge pour le reste de la pile. La frontière utile se trouve donc plus bas, mais l’écart relatif ne change pas.

Voici ce qui arrive à un modèle dont le working set, c’est-à-dire les poids, le cache et les buffers actifs, occupe 350 Go. Il tient dans la HBM d’un MI455X. Sur Rubin, il faut soit réduire la précision, soit déplacer une partie de l’état, soit répartir le modèle sur au moins deux GPU. La première option peut changer la qualité, la deuxième ajoute un étage mémoire plus lent, la troisième introduit une synchronisation inter-GPU à chaque couche découpée.

Cette suppression d’un saut explique pourquoi la capacité peut compter davantage que les PFLOPS. Elle réduit le degré de tensor parallelism 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. , donc le nombre de fragments qui doivent s’attendre après chaque multiplication de matrice. Elle ne garantit pourtant pas qu’un modèle tenant sur un GPU doive y rester : un objectif de TPOT serré peut imposer plusieurs GPU pour obtenir assez de calcul ou de bande passante. L’avantage de capacité consiste donc le plus souvent à réduire le degré de découpage et à dégager de la place pour le KV cache et la concurrence, pas à supprimer toute communication.

Un calcul d’ordre de grandeur rend cette marge plus concrète. Pour un modèle hypothétique de 80 couches, avec 8 têtes KV de dimension 128 et un cache FP8, chaque token occupe 2 × 80 × 8 × 128 = 163 840 octets pour les clés et les valeurs. Les 144 Go d’écart représentent alors environ 880 000 tokens de cache répartis entre les séquences actives. Il s’agit d’une estimation sous hypothèses, avant alignement mémoire, fragmentation, buffers et métadonnées. Un autre modèle peut produire un résultat très différent.

Le gain n’est donc pas « 50 % de mémoire donne 50 % de tokens en plus ». Il dépend de la position exacte du working set et de l’objectif de service. Sous 288 Go, les deux GPU peuvent éviter un découpage dicté par la capacité. Entre 288 et 432 Go, AMD peut l’éviter seul. Au-delà de 432 Go, les deux basculent dans un régime distribué.

Dès que le modèle déborde, l’interconnexion devient une mémoire

Le tensor parallelism découpe une matrice entre plusieurs GPU. Chaque GPU lit sa tranche de poids depuis sa HBM locale, calcule une sortie partielle, puis participe à un all-reduce ou à un all-gather pour reconstruire les activations nécessaires à la couche suivante. Ce rendez-vous revient des dizaines de fois par token. Le GPU le plus rapide ne peut pas passer à la couche suivante tant que les données attendues ne sont pas arrivées.

Les modèles MoE ajoutent un autre trafic. L’expert parallelism route les activations des tokens vers les GPU qui hébergent les experts sélectionnés, puis les renvoie par un all-to-all. Une HBM plus grande peut garder davantage d’experts locaux ou permettre leur réplication, mais elle ne supprime pas le routage lorsque les experts actifs restent répartis. Pour ces modèles, la latence des petits messages, le débit du all-to-all et le contrôle de la congestion comptent autant que l’all-reduce du tensor parallelism.

La hiérarchie de transport devient alors visible, mais les conventions doivent être alignées. Les 23,3 To/s du MI455X et les 22 To/s de Rubin décrivent le débit maximal d’une lecture ou d’une écriture HBM. Les 3,6 To/s de scale-up additionnent au contraire les deux directions. Diviser directement les fiches donne un écart d’environ 6 à 6,5 fois ; pour un flux dans une seule direction, le lien fournit 1,8 To/s et le rapport approche plutôt 12 à 13 fois. Aucun de ces rapports ne prédit le temps exact d’un collectif, car les données ne suivent pas toutes le même trajet et les liens fonctionnent en parallèle. Ils montrent pourquoi réduire le nombre de GPU reste précieux même lorsque le tissu est rapide.

HBM locale poids du shard 22 à 23,3 To/s

GPU sortie partielle matmul

Scale-up all-reduce 3,6 To/s annoncé

GPU voisins activations réunies synchronisation

Couche suivante calcul reprend chemin critique

Le titre de cet article peut maintenant recevoir une première réponse. La mémoire suffit à battre NVLink seulement lorsqu’elle permet de ne pas utiliser NVLink. Dès que les deux systèmes répartissent le modèle sur plusieurs GPU, l’avantage de capacité réduit encore le nombre de shards possibles, mais il ne remplace plus la qualité du tissu scale-up.

UALoE rejoint NVLink sur le débit annoncé

AMD n’arrive pas à ce match avec la même interconnexion que le MI355X. Helios relie ses 72 MI455X avec UALink 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. over Ethernet, abrégé UALoE. Le protocole UALink fournit des lectures, écritures et opérations atomiques dans un espace d’adressage réparti. La cohérence reste gérée par le logiciel : « domaine load/store unique » ne signifie pas que les 31 To de HBM deviennent un cache matériel uniforme.

Ce choix répond aussi à un calendrier. Le livre blanc UALink de janvier 2026 n’attendait les premiers matériels d’évaluation des switches UALink natifs que pour la fin de 2026. Helios transporte donc dès 2026 les sémantiques UALink sur un tissu Ethernet scale-up co-conçu avec Broadcom, à base de switches Tomahawk et du cadre eSUN. Ce n’est pas l’Ethernet généraliste d’un réseau d’entreprise : AMD décrit un fabric spécialisé, sans perte et à un seul saut. Ce raccourci vers du silicium disponible ne mesure toutefois ni le surcoût protocolaire ni la latence obtenue face à NVLink 6.

Dans Helios, chaque GPU dispose de 18 stations UALoE réparties entre plusieurs switch trays. Le chemin entre deux GPU traverse un seul switch. AMD annonce un basculement automatique vers les liens restants lorsqu’un chemin tombe, puis confie le provisionnement, la télémétrie et la reprise à AMD Fabric Manager et AMD Fabric OS. Les vPods découpent le domaine de 72 GPU en groupes logiques, de quatre GPU à un rack complet.

Le chiffre de pointe est le même que chez NVIDIA : 3,6 To/s bidirectionnels par GPU et 260 To/s agrégés par rack. Le livre blanc UALink 1.0 vise un aller-retour requête-réponse inférieur à une microseconde, mais AMD ne publie pas de latence mesurée pour Helios. Les 260 To/s ne disent pas non plus combien un all-reduce RCCL soutient lorsque 72 GPU échangent en même temps.

NVLink 6 possède une autre stratégie d’intégration. Rubin ajoute des counted writes initiés par le GPU : le destinataire suit l’achèvement d’un transfert avec un compteur, sans enchaîner la même série de barrières, accusés de réception et drapeaux atomiques. La communication peut rester fusionnée dans le kernel pendant que le calcul avance. NVIDIA ne publie pas davantage de latence absolue comparable à celle d’Helios, mais documente le mécanisme qui réduit la synchronisation.

Une étude analytique publiée par l’IEEE en 2025 estime qu’un pod UALink plat peut réduire la contribution des collectifs à petits messages jusqu’à 1 024 GPU, tandis que NVLink 5 conserve un avantage dans les régimes dominés par la bande passante. Ce résultat renforce l’importance de la taille des messages, mais ne mesure ni Helios ni NVLink 6 : c’est un modèle comparatif, pas un benchmark des deux racks de cet article.

L’ouverture ne tranche pas non plus la performance. UALink repose sur une spécification de consortium et UALoE réutilise des switch ASIC Ethernet. Cela ouvre la porte à plusieurs fournisseurs et à des évolutions moins dépendantes d’un propriétaire unique. NVLink lie plus étroitement le GPU, le switch, NCCL, CUDA et les kernels. Le premier modèle optimise la substituabilité des briques ; le second optimise leur co-conception. L’un n’est pas automatiquement rapide parce qu’il est ouvert, l’autre n’est pas automatiquement efficace parce qu’il est intégré.

Les PFLOPS FP4 ne sont pas le juge de paix

Le calcul 4 bits fournit l’exemple le plus net d’une comparaison qui paraît simple et ne l’est pas. AMD publie 40,3 PFLOPS OCP MXFP4 par MI455X. NVIDIA publie 50 PFLOPS NVFP4 en inférence par Rubin, mais 35 PFLOPS NVFP4 en entraînement. À l’échelle du rack, cela donne 2,9 EFLOPS MXFP4 pour Helios, 3,6 EFLOPS NVFP4 en inférence ou 2,52 EFLOPS en entraînement pour Vera Rubin NVL72.

AMD revendique jusqu’à 15 % de calcul en plus que Vera Rubin. Sa note méthodologique compare 2,9 EFLOPS OCP MXFP4 aux 2,52 EFLOPS NVFP4 d’entraînement de NVIDIA. Si l’on prend le chiffre NVFP4 d’inférence, Rubin affiche au contraire 3,6 EFLOPS. Les deux divisions sont arithmétiquement correctes ; aucune ne constitue un benchmark de modèle.

La première raison est le mode. NVIDIA distingue deux enveloppes de fonctionnement pour le même format selon l’inférence ou l’entraînement. La deuxième est le dialecte FP4. MXFP4 regroupe 32 valeurs derrière une échelle partagée selon le standard OCP. NVFP4 utilise des blocs de 16 et un scaling à deux niveaux. Le nombre d’opérations ne dit ni la qualité obtenue après quantification, ni le nombre d’opérateurs qui restent dans ce format, ni le débit du softmax, des communications et du KV cache entre deux matmuls.

Le même piège réapparaît à d’autres précisions. Helios annonce 1,4 EFLOPS OCP MXFP8, contre 1,26 EFLOPS FP8/FP6 dense d’entraînement pour NVL72, soit 11 % d’écart arithmétique sans benchmark commun. En FP32, AMD publie 315 TFLOPS de matrice par GPU ; NVIDIA affiche 130 TFLOPS FP32 natifs et 400 TFLOPS « FP32 SGEMM » obtenus par émulation sur Tensor Cores. Choisir 130 ou 400 change le vainqueur du ratio sans changer le matériel. La méthode de calcul fait partie du chiffre.

NVIDIA a publié des détails qui vont précisément au-delà des Tensor Cores. Rubin peut compresser certaines activations d’attention en sparsité 2:4, accélère les exponentielles du softmax et permet au Tensor Memory Accelerator de mettre à jour ses descripteurs en ligne pour les experts MoE. AMD publie les dimensions de CDNA 5 et les débits de pointe du MI455X, mais pas encore un document de même granularité sur l’exécution d’une couche complète. Cette asymétrie documentaire interdit de déduire un débit soutenu à partir des seules unités de calcul.

Rack contre rack : presque la parité sur le papier

Caractéristique	AMD Helios	NVIDIA Vera Rubin NVL72	Écart
GPU	72 MI455X	72 Rubin	Même échelle
CPU	18 EPYC Venice	36 Vera	Architectures de tray différentes
HBM4 totale	31,1 To	20,7 To	+50 % AMD
Bande passante HBM agrégée	1,67 Po/s	1,58 Po/s	+5,9 % AMD
Scale-up agrégé	260 To/s UALoE	260 To/s NVLink 6	Égalité de pointe
Scale-out agrégé	43,2 To/s bidirectionnels	28,8 To/s bidirectionnels	+50 % AMD en pointe
Calcul 4 bits	2,9 EFLOPS OCP MXFP4	3,6 EFLOPS inférence ; 2,52 entraînement NVFP4	Non directement comparable
Calcul 8 bits	1,4 EFLOPS OCP MXFP8	1,26 EFLOPS FP8/FP6 entraînement	Formats distincts
Statut	Design de référence, livraisons S2 2026	Rubin en production, systèmes S2 2026	Spécifications NVL72 préliminaires

Les totaux mémoire découlent directement des packages : 72 × 432 Go donnent 31,1 To pour Helios ; 72 × 288 Go donnent 20,7 To pour Vera Rubin. Le même calcul produit 1,67 Po/s et 1,58 Po/s de bande passante HBM agrégée. Additionner les GPU suppose que chaque charge distribue effectivement ses lectures sur les 72 mémoires locales. Ce n’est pas une mémoire uniforme capable de livrer 1,67 Po/s à un GPU unique.

La symétrie des 260 To/s mérite la même prudence. Il s’agit de la somme des ports de scale-up du rack, pas du débit qu’une paire de GPU ou un collectif unique reçoit. La topologie, la taille des messages, le routage, la contention et la bibliothèque collective déterminent la fraction atteinte. Un rack n’est pas 72 fiches techniques additionnées ; c’est un graphe de dépendances synchronisées.

Le scale-out se compare plus proprement que le suggéraient les premières fiches. AMD prévoit jusqu’à trois NIC Vulcano à 800 Gb/s par MI455X, soit 2,4 Tb/s dans une direction par GPU. NVIDIA publie 1,6 Tb/s de ConnectX-9 par Rubin. Une fois les deux directions et 72 GPU additionnés, on retrouve 43,2 contre 28,8 To/s, donc 50 % de bande passante de ports en plus pour Helios. Ce résultat décrit les points d’entrée du réseau, pas le débit d’une application multi-rack : les switches, la congestion, le routage et les collectifs restent à mesurer.

Le statut des plateformes est asymétrique. AMD décrit Helios comme un design de référence que les OEM et ODM peuvent adapter, avec des livraisons et déploiements en volume annoncés au second semestre 2026. NVIDIA affirme que Rubin est en pleine production et que des systèmes partenaires sont expédiés ou attendus au second semestre, tout en marquant encore les valeurs de la fiche NVL72 comme préliminaires et sujettes à modification. Cela ne suffit toujours pas à comparer un prix public, un délai réel de livraison ou un coût énergétique.

La réponse NVIDIA dépasse le rack NVL72

NVIDIA ne répond pas aux 432 Go uniquement avec les 288 Go de Rubin. Sa plateforme associe NVL72 à des racks Groq 3 LPX pour désagréger l’inférence : Rubin traite le prefill, l’attention et les charges générales, tandis que les LPU accélèrent les parties du decode sensibles à la latence, notamment les FFN et experts MoE. Un rack LPX rassemble 256 LPU, 128 Go de SRAM, 40 Po/s de bande passante SRAM et 640 To/s de scale-up. Ces valeurs montrent que le match commercial se joue au niveau d’une plateforme hétérogène, pas seulement d’un GPU ou d’un rack.

Elles ne constituent pas un benchmark contre Helios. NVIDIA revendique jusqu’à 35 fois plus de débit par mégawatt pour LPX avec Vera Rubin sur des modèles à mille milliards de paramètres. Pour NVL72 seul, l’entreprise projette jusqu’à 10 fois plus de tokens par mégawatt et un coût par token divisé par dix face à GB200 NVL72 sur Kimi-K2-Thinking en 32K/8K. Elle annonce aussi environ 10 % de consommation moyenne en moins grâce au lissage de puissance et jusqu’à 40 % de GPU supplémentaires dans le même budget électrique avec DSX MaxLPS. Ce sont des projections ou comparaisons internes contre les générations NVIDIA précédentes, pas des mesures indépendantes face à AMD.

AMD documente de son côté le refroidissement liquide, le rack ORW double largeur et la distribution électrique d’Helios, mais pas une consommation au mur comparable. La conclusion énergétique reste donc inchangée : les constructeurs décrivent leurs mécanismes et leurs objectifs, mais aucun test commun ne mesure encore les deux plateformes à qualité et latence égales.

Le verdict honnête, charge par charge

Si le working set reste sous 288 Go, les deux GPU le conservent localement. Les 144 Go supplémentaires d’AMD apportent de la marge pour le KV cache et la concurrence, mais pas un multiplicateur automatique de débit. Le petit avantage de bande passante HBM du MI455X peut aider le decode, à condition que les kernels atteignent une fraction similaire du pic.

Entre 288 et 432 Go, AMD possède son cas le plus favorable. Le MI455X peut éviter un découpage que Rubin doit accepter. La suppression d’une synchronisation vaut alors plus que la comparaison UALoE contre NVLink, puisque le chemin scale-up disparaît du parcours critique.

Au-delà de 432 Go, la comparaison change de nature. La capacité AMD permet de réduire le nombre de shards à working set égal, mais les deux plateformes dépendent de leur tissu et de leur pile logicielle. Les chiffres de pointe sont à égalité. Le départage réel se fera sur RCCL contre NCCL, ROCm contre CUDA, l’efficacité des kernels, la latence des collectifs et la capacité à masquer les communications derrière le calcul.

Pour les charges multi-rack, AMD possède donc un avantage vérifiable de 50 % sur la bande passante de ports scale-out annoncée. Il reste impossible d’en déduire 50 % de débit applicatif en plus : aucun résultat public n’aligne le même modèle, la même topologie de switches, le même collectif et le même niveau de congestion.

Conclusion

Le MI455X retire à NVIDIA deux réponses faciles. Rubin n’a plus la plus grande HBM par GPU, et NVLink 6 n’a plus seul le plus grand chiffre de bande passante scale-up. AMD atteint cette position avec 432 Go de HBM4 et un tissu UALoE qui annonce les mêmes 3,6 To/s par GPU.

La prochaine preuve ne viendra donc pas d’une fiche technique plus longue ni d’une projection contre la génération précédente. Elle viendra d’un même modèle exécuté à qualité égale, avec TTFT, TPOT, tokens par seconde, débit des collectifs et énergie mesurée au mur. Si UALoE et RCCL transforment leurs 260 To/s de pointe en débit soutenu proche de NVLink et NCCL, AMD aura déplacé la concurrence du composant vers le système. Dans le cas contraire, les 432 Go resteront un avantage décisif pour éviter certains découpages, pas la preuve que la mémoire a battu le réseau.

Sources et méthode

Spécifications AMD MI455X. La fiche technique AMD Instinct MI455X, datée de juillet 2026, fournit les 320 milliards de transistors, 8 XCD et 2 IOD, 432 Go de HBM4, 23,3 To/s, 40,265 PFLOPS OCP MXFP4 et 3,6 To/s UALoE. Elle confirme aussi les vPods de quatre GPU jusqu’au rack complet. Aucun document AMD ne compte deux FCD supplémentaires dans les spécifications du package. Ce sont des faits vérifiés au sens de spécifications constructeur, pas des mesures indépendantes. La page produit MI455X confirme la date de lancement du 23 juillet et les 12 piles HBM4.

Architecture AMD Helios. Le blueprint Helios décrit 18 trays de quatre GPU, six switch trays, 31 To de HBM4, 1,67 Po/s de bande passante HBM agrégée, 260 To/s de scale-up et jusqu’à 43 To/s de scale-out bidirectionnel. Les billets AMD sur le scale-up UALoE et le réseau scale-out documentent la topologie à un seul saut, les 18 stations par GPU, le basculement de liens, AFM, AFOS, les vPods et les trois NIC Vulcano à 800 Gb/s par GPU. La session technique AMD et Broadcom identifie Tomahawk et eSUN. La page Helios décrit encore le système comme un design de référence partagé aux partenaires, avec des déploiements en volume attendus au second semestre 2026. Elle conserve aussi plusieurs mentions à 19,6 To/s dans ses sections basses, alors que son en-tête, la fiche MI455X et le blueprint datés de juillet donnent 23,3 To/s. Nous retenons les documents produit les plus récents et signalons cette incohérence au lieu de mélanger les versions.

UALink. Le livre blanc UALink 200G 1.0 définit les stations de quatre lanes, les sémantiques load/store/atomiques, la cohérence logicielle et l’objectif d’un aller-retour requête-réponse inférieur à 1 µs. Le livre blanc de janvier 2026 indiquait des matériels d’évaluation pour switches natifs attendus fin 2026. Ces valeurs sont des objectifs et calendriers de spécification, pas une latence Helios mesurée. L’étude IEEE Communication-Centric UALink and NVLink Comparison est un modèle analytique comparant UALink 1.0 à NVLink 5, pas un résultat sur le silicium Helios ou Rubin.

Spécifications et plateforme NVIDIA Rubin. Le billet technique NVIDIA Inside NVIDIA Rubin GPU Architecture fournit les 336 milliards de transistors, 224 SM, deux dies reliés par NV-HBI, 288 Go de HBM4 à 22 To/s, 50 PFLOPS NVFP4 en inférence, les counted writes NVLink, la sparsité d’activation, les débits d’exponentielle et les mécanismes de lissage de puissance. La fiche Vera Rubin NVL72 donne 72 GPU, 20,7 To de HBM4, 1 580 To/s de bande passante HBM, 260 To/s de NVLink 6, 28,8 To/s de scale-out, 3,6 EFLOPS NVFP4 en inférence et 2,52 EFLOPS NVFP4 en entraînement. NVIDIA marque ces valeurs comme préliminaires, approximatives et sujettes à modification, tout en annonçant Rubin en pleine production. Le billet Inside NVIDIA Groq 3 LPX fournit les caractéristiques du rack LPX et décrit la répartition du decode entre Rubin et les LPU. Les chiffres de tokens par mégawatt et de coût sont des projections NVIDIA contre GB200, pas des mesures indépendantes face à Helios.

Calculs dérivés. Les écarts de capacité (+50 %) et de bande passante (+5,9 %) sont les rapports (432 / 288) et (23,3 / 22). Les plafonds de paramètres supposent exactement 1 octet par paramètre à 8 bits et 0,5 octet à 4 bits, sans facteur d’échelle, buffer, runtime ni KV cache : ce sont des planchers de taille, pas des recommandations de déploiement. L’exemple de KV cache suppose deux tenseurs, 80 couches, 8 têtes, 128 composantes et un octet par composante. Les débits scale-out dérivent de 3 × 800 Gb/s contre 1,6 Tb/s par GPU, doublés pour les deux directions puis multipliés par 72.

Ce qui reste inconnu. Au 24 juillet 2026, le registre officiel MLPerf Inference v6.0 ne contient aucun résultat MI455X ou Rubin, et nous n’avons trouvé aucun benchmark indépendant comparant Helios et NVL72 sur une même charge. Aucun prix public comparable, débit collectif RCCL/NCCL, latence Helios mesurée, tokens par seconde à qualité égale ou consommation système mesurée n’est disponible. Les projections énergétiques NVIDIA et les chiffres de ports réseau ne comblent pas ce manque. Toute affirmation selon laquelle l’une des plateformes est « plus rapide » reste donc une hypothèse non démontrée.