AMD a organisé son plus grand événement Advancing AI à ce jour, mettant l'accent sur l'évolutivité. L'entreprise a présenté le GPU Instinct MI455X, le rack Helios à 72 GPU et les processeurs EPYC Venice de 6e génération. Le MI455X embarque 432 Go de mémoire HBM4, soit 50 % de plus que les puces NVIDIA B300 ou Rubin, avec une bande passante mémoire de 23.3 To/s et une puissance de calcul MXFP4 pouvant atteindre 40.26 PFLOPS. Un rack Helios complet multiplie ces chiffres par 72, atteignant 2.9 exaFLOPS en FP4, 31 To de mémoire HBM4, une bande passante mémoire de 1.7 Po/s, une capacité d'extension verticale de 260 To/s et une capacité d'extension horizontale de 43 To/s vers le datacenter. Sur tous les indicateurs, AMD ambitionne de devenir leader du secteur. Cet article examine le MI455X et Helios ; le lancement de Venice fait l'objet d'une analyse distincte.

L'autre thème central est l'ouverture, présente à tous les niveaux, à commencer par l'interconnexion. À l'intérieur du rack, les 72 GPU partagent la mémoire via UALink, une architecture ouverte du consortium qu'AMD exploite sur Ethernet sous le nom d'UALink-over-Ethernet (UALoE). Une fois le trafic sorti du rack, il transite par Ultra Ethernet, la norme ouverte d'extension horizontale du consortium Ultra Ethernet. Le même système Instinct est déployé à tous les niveaux de l'architecture. Les calculs à faible précision utilisent les formats de données ouverts MXFP4, MXFP6 et MXFP8 d'OCP, et le rack qui l'héberge est conçu selon l'architecture Open Rack Wide de l'Open Compute Project. Même le logiciel est développé en open source : le compilateur, l'environnement d'exécution et les bibliothèques de ROCm sont tous disponibles en code source.

Comme toutes les spécifications de la pile technologique sont publiées et téléchargeables dès aujourd'hui, un hyperscaler peut utiliser Helios comme modèle et créer une version sur mesure, adaptée à ses infrastructures et à ses charges de travail, en modifiant le réseau, l'alimentation ou la gestion selon ses besoins. Cela signifie que tout ce que nous décrivons dans cet article correspond à la conception de référence présentée par AMD ; les unités déployées par les clients peuvent différer considérablement. Les utilisateurs sont déjà au rendez-vous : AMD annonce qu'OpenAI, Meta, Anthropic, Microsoft , Oracle et d'autres entreprises adoptent Helios.

AMD Instinct MI455X : le fleuron de la gamme CDNA 5

Le MI455X est le premier accélérateur CDNA 5, intégrant 320 milliards de transistors. Il comprend huit puces d'accélération (XCD) gravées en N2 par TSMC, ainsi que deux puces d'E/S et deux puces de cache et de mémoire (Fabric) gravées en N3, et douze modules HBM4. Il s'agit de la plus grande puce jamais réalisée avec le boîtier CoWoS-L de TSMC.

La mémoire est l'un des points forts. Ces douze modules HBM4 totalisent 432 Go à 23.3 To/s, la technologie HBM4 doublant l'interface par module à 2 048 bits, et les deux puces Fabric et Cache ajoutent un cache L2 de 192 Mo fonctionnant à 54 To/s.

Le MI455X ne lésine pas non plus sur les E/S. Il prend en charge 72 lignes UALoE pour une bande passante bidirectionnelle extensible de 3.6 To/s vers le reste d'un rack, 256 Go/s d'Infinity Fabric bidirectionnel vers son processeur hôte, et un choix de deux liaisons PCIe Gen6 x16 ou de trois cartes réseau AMD AI-NIC pour l'extension horizontale.

Comparé à la puce qu'il remplace et aux offres de NVIDIA, le MI455X domine tous les indicateurs.

Spécifications	AMD MI455X	NVIDIA Rubin	AMD MI355X	Nvidia B300
Architecture	ADNc 5	Rubin	ADNc 4	Blackwell Ultra
Transistors	320B	336B	185B	208B
Capacité HBM	432GB HBM4	288GB HBM4	288 Go HBM3E	288 Go HBM3E
Bande passante HBM	23.3 To / s	22 To / s	8 To / s	8 To / s
Évolutivité par GPU	3.6 To / s	3.6 To / s	1.08 To / s	1.8 To / s
Extension horizontale par GPU	2,400 Gb / s	1,600 Gb / s	400 Gb / s	800 Gb / s
Lien CPU-GPU	Tissu Infinity 256 Go/s	1.8 To/s C2C (1:2)	PCIe 5	900 Go/s C2C (1:2)

 

Commençons par les points forts d'AMD. Avec 432 Go de mémoire HBM, la MI455X embarque 50 % de plus que les MI355X, B300 et Rubin, toutes plafonnées à 288 Go. Sa bande passante mémoire de 23.3 To/s est également la plus élevée du groupe. Côté performances, la tendance est la même : 2 400 Gbit/s par GPU contre 1 600 pour Rubin et 800 pour B300. Chaque MI455X offre donc 50 % de bande passante réseau supplémentaire par rapport à son concurrent le plus proche.

AMD a finalement rattrapé son retard en matière de montée en charge. NVLink a longtemps été la technologie de référence pour les GPU et, pendant deux générations, était la seule solution pour obtenir des performances optimales sur les modèles MoE avec WideEP. UALoE comble cet écart en une seule génération : avec 3.6 To/s, le MI455X égale le NVLink 6 de Rubin. NVIDIA conserve une nette avance au niveau de la liaison hôte. Un processeur Vera alimente deux GPU Rubin via une liaison C2C de 1.8 To/s, tandis que chaque MI455X communique avec son hôte Venice via une liaison Infinity Fabric de 256 Go/s. Cette différence explique en grande partie la divergence entre les deux architectures rack, abordée plus loin dans cet article.

En termes de puissance de calcul brute, le MI455X domine sur tous les plans, avec une précision toutefois : les formats OCP MX d’AMD et NVFP4 de NVIDIA fonctionnent différemment, il faut donc considérer ces valeurs comme des pics annoncés ; les performances réelles sont une autre question.

Format	AMD MI455X	NVIDIA Rubin	AMD MI355X	Nvidia B300
MXFP4 / NVFP4	40.26 PF	35 PF	10.1 PF	15 PF
MXFP6 / FP6	20.13 PF	17.5 PF	10.1 PF	5 PF
MXFP8 / FP8	20.13 PF	17.5 PF	5 PF	5 PF
FP16 / BF16	5.03 PF	4 PF	2.5 PF	2.5 PF
FP32	315 TF	130 TF	157.3 TF	75 TF

 

Par rapport à la MI355X, la MI455X offre un débit MXFP4 et MXFP8 quatre fois supérieur et des performances FP16/BF16 et FP32 deux fois plus élevées. La comparaison avec NVIDIA se divise en deux parties. Face à la B300, la MI455X affiche un débit FP4 2.7 fois supérieur et des performances FP6 et FP8 quatre fois plus élevées. Rubin constitue le benchmark de référence, et face à lui, la MI455X conserve un avantage constant : 15 % en FP4, 15 % en FP6 et FP8, et 26 % en FP16/BF16. L’écart le plus important se situe en FP32, où les 315 TF de la MI455X représentent environ 2.4 fois les 130 TF de Rubin et plus de quatre fois les 75 TF de la B300. Ce chiffre provient de l'héritage HPC d'Instinct et reste pertinent pour les travaux d'IA, car les poids maîtres, l'accumulation de haute précision et les charges de travail scientifiques continuent de s'exécuter au-dessus des formats à faible nombre de bits.

À l'intérieur de CDNA 5

Double-cliquons sur l'architecture pour voir ce qui est réellement à l'origine de ces performances exceptionnelles.

Du XCD au SIMD

En parcourant la hiérarchie depuis le processeur, on constate l'ampleur des modifications apportées, car CDNA 4 a profondément remanié l'organisation des puces de calcul. Sur le MI355X, chaque XCD intégrait 32 unités de calcul actives et un cache L2 privé de 4 Mo qui centralisait le trafic de la puce avant son acheminement vers l'Infinity Fabric. CDNA 5 conserve les huit XCD, mais reconstruit leur architecture interne, en empruntant structure et terminologie à la gamme graphique RDNA d'AMD. Chaque XCD du MI455X est désormais divisé en deux moteurs de shaders. Chaque moteur de shaders comprend physiquement 17 processeurs de groupe de travail, dont 16 sont activés, un étant réservé pour le rendement. Le cache L2 par XCD a complètement disparu, étant déplacé de la puce de calcul vers les puces de base sous-jacentes, où se trouve la section mémoire.

Ce qui importe, c'est ce qui n'a pas changé au niveau des calculs. Un XCD compte toujours 32 unités actives, et le GPU en totalise toujours 256, soit le même nombre que le MI355X en unités de calcul. Le gain de débit en basse précision, multiplié par quatre d'une génération à l'autre, ne provient pas de l'ajout d'unités d'exécution ; il résulte entièrement de l'augmentation du travail effectué par chaque WGP par cycle, et c'est précisément au niveau du WGP que la refonte se concentre.

Un WGP est composé de quatre unités SIMD 32 voies et de quatre unités scalaires partageant un cache constant. Le changement majeur réside dans le flux des threads : le passage de Wave64 à Wave32. Une vague est un ensemble de threads exécutés de manière synchrone par une unité SIMD. CDNA 4 utilisait Wave64, acheminant chaque vague de 64 threads à travers une unité SIMD 16 voies sur quatre cycles d'horloge. CDNA 5 abandonne totalement la prise en charge de Wave64, une première pour une architecture Instinct, et exécute Wave32 nativement. Une vague de 32 threads est mappée un à un sur chacune des quatre unités SIMD 32 voies du WGP, est émise en un seul cycle et permet à chaque unité SIMD de démarrer une nouvelle instruction à chaque cycle d'horloge.

Des vagues plus étroites et plus rapides modifient la façon dont le travail circule dans la machine. La latence des instructions diminue car une vague se termine plus rapidement. La divergence des branches coûte moins cher car une division binaire (prise ou non) bloque désormais au maximum 32 threads au lieu de 64. La pression sur les registres diminue, ce qui permet à un plus grand nombre de vagues de rester résidentes, jusqu'à 64 par WGP contre la moitié auparavant. Cela permet au planificateur de traiter davantage de petites tâches indépendantes pour masquer la latence mémoire. Wave32 facilite également le mappage de différentes tailles de tuiles pour les opérations tensorielles sur le matériel, simplifiant ainsi le développement du noyau.

Single-cycle issue is only the start of the throughput story. The SIMDs co-execute, starting new instructions while earlier multi-cycle operations drain underneath, and packed vector instructions carry 64 threads' worth of work in a single issue, details AMD's architects confirmed in the post-briefing Q&A. The vector pipeline also gains native BF16 support and a set of new data-conversion instructions for moving tensors between formats. The transcendental units double their throughput over the MI355X and add a native tanh instruction, so the softmax and activation math inside attention keeps pace with the tensor hardware around it. That path is becoming a habit: CDNA 4 doubled the transcendental rates to accelerate attention, and CDNA 5 doubles them again.

La hiérarchie de la mémoire

Derrière les unités d'exécution se cache une hiérarchie reconstruite de haut en bas, et la manière la plus claire de la voir est de la comparer niveau par niveau au MI355X.

Niveau	MI455X (CDNA 5)	MI355X (CDNA 4)
registres vectoriels	128 Ko par SIMD ; 1,024 2 par thread ; bande passante doublée	128 Ko par SIMD ; 256 par thread
Magasin local WGP/CU	384 Ko (320 Ko LDS + 64 Ko de cache vectoriel) ; bande passante doublée	192 Ko (160 Ko LDS + 32 Ko L1)
Cache d'instructions/constantes	64 Ko + 16 Ko par WGP	64 Ko partagés par deux unités de calcul + 16 Ko
L2	2 × 96 Mo sur les disques FCD ; 54 To/s	8 × 4 Mo, un par XCD
Cache côté mémoire	Eliminé	Cache infini de 256 Mo
HBM	432 Go HBM4 ; 12 blocs de 2 048 bits ; 23.3 To/s	288 Go HBM3E ; 8 blocs de 1 024 bits ; 8 To/s

 

C'est au niveau des lignes de cache que l'architecture a connu une transformation majeure. CDNA 4 utilisait une architecture à trois niveaux : chaque XCD disposait d'un cache L2 privé de 4 Mo qui centralisait le trafic de sa puce avant qu'il n'atteigne l'Infinity Fabric, tandis qu'un cache Infinity partagé de 256 Mo, situé dans les puces d'E/S, se trouvait côté mémoire, en amont des contrôleurs HBM. CDNA 5 supprime ces deux niveaux et les remplace par deux caches L2 indépendants de 96 Mo, un par puce et par Infinity Fabric, chacun composé de 96 blocs d'un mégaoctet. L'agencement est vertical : quatre XCD, soit huit moteurs de shaders, sont liés par liaison hybride au-dessus de chaque FCD, qui contient également six des douze emplacements HBM4. Les deux FCD se rejoignent au niveau d'un Infinity Fabric central, au milieu du boîtier, les puces d'E/S occupant chaque extrémité. Chaque cache L2 peut contenir n'importe quelle adresse de la mémoire du GPU, et l'Infinity Fabric assure la cohérence des deux caches. La raison invoquée par AMD est la bande passante : l’un de ces caches offre à lui seul 1.5 fois la bande passante totale du cache Infinity complet du MI355X, la paire offre trois fois cette bande passante, et aucun de ces flux de trafic n’a besoin de traverser la bisection entre les puces qui limitait l’ancienne configuration.

Le cache se voit également confier de nouvelles tâches. Les opérations atomiques au niveau du périphérique, auparavant exécutées dans le réseau, s'exécutent désormais dans le cache L2 à des débits bien plus élevés, tandis que les opérations atomiques au niveau du système restent dans l'Infinity Fabric comme auparavant. Un nouvel arbitre de diffusion complète le dispositif, en multidiffusant les tuiles tensorielles à chaque nœud WGP coopérant sur la même matrice. Ainsi, un poids récupéré une seule fois est utilisé par tous, ce qui multiplie par quatre la bande passante de lecture effective.

Les niveaux ci-dessus s'adaptent en conséquence. Le stockage local par WGP double pour atteindre 384 Ko, répartis en 320 Ko de LDS et un cache de données vectorielles de 64 Ko, avec une bande passante de lecture doublée. Cela permet à FlashAttention de stocker les requêtes, les clés, les valeurs et les réductions partielles sur la puce, au lieu d'écrire la matrice d'attention complète. Il prend également en charge les noyaux MoE fusionnés pour conserver l'état de routage et les accumulateurs en mémoire. Le fichier de registres vectoriels conserve sa capacité de 128 Ko par SIMD, mais est réorganisé pour Wave32. Il en résulte deux fois plus de vagues, la possibilité pour un seul thread d'adresser 1 024 registres au lieu de 256, et une bande passante des registres doublée pour alimenter les SIMD plus larges et leurs unités de co-exécution.

La partie scalaire est reconstruite en conséquence, avec 128 registres scalaires par vague et 32 ​​Ko par WGP. À la base, la HBM4 passe de huit piles de 1 024 bits à douze piles de 2 048 bits, augmentant la capacité de 50 % à 432 Go et la bande passante de 2.9 fois à 23.3 To/s sur une interface à 192 canaux.

L'ensemble est alimenté par un nouveau module de déplacement de données tensorielles (un par groupe de travail), capable de gérer les schémas de pavage tensoriel jusqu'à cinq dimensions et de transférer les tuiles de manière asynchrone entre la DRAM et le stockage local, sans transit de registres intermédiaires. Les transferts sont décrits par des descripteurs chargés depuis les registres scalaires et leurs limites sont vérifiées matériellement pour des raisons de sécurité. La prise en charge du chargement multicast évite aux unités SIMD d'être bloquées en attente d'une copie ou de consommer des registres lors de leur exécution. Il s'agit de la réponse de CDNA 5 aux accélérateurs de mémoire tensorielle des processeurs NVIDIA récents. Un ensemble de fonctionnalités d'utilisation complète l'interface : les clusters de groupes de travail offrent aux noyaux un contrôle précis sur le placement et la concurrence pour les charges de travail de partage de données ; les barrières fractionnées et nommées permettent à un producteur de signaler la fin d'une tâche et de poursuivre sans attendre la réponse du consommateur ; les préchargeurs à chaque niveau de la hiérarchie préparent les données pour leur point de consommation ; et une interface de commande repensée réduit la latence de lancement et de distribution des noyaux courts, prédominants dans l'inférence.

Le système DMA a été reconstruit selon la même philosophie. Le logiciel planifie les transferts en fonction des interfaces DMA, tandis que les interfaces dorsales, physiquement conscientes et situées à proximité des liaisons UALoE, répartissent chaque tâche, équilibrent la charge sur toutes les liaisons disponibles et extraient les données directement de la mémoire, sans les faire transiter par un moteur distant. Ces interfaces dorsales réagissent également à la congestion du réseau et contournent les chemins surchargés, permettant ainsi aux bibliothèques de communication de bénéficier d'un trafic réseau équilibré sans avoir à connaître la topologie sous-jacente.

Découpage du GPU : NPS et SR-IOV

L'architecture physique à deux caches L2 offre un second avantage en matière de partitionnement du GPU. Dans NPS1, la puce entière forme un seul domaine NUMA : les adresses s'entrelacent sur les douze piles HBM et les deux moitiés pour une bande passante uniforme, facilitant ainsi le portage et assurant une répartition homogène des accès mémoire. NPS2 divise le GPU en deux domaines NUMA, chacun possédant six piles HBM, une puce d'E/S et de cache, ainsi que les XCD empilés dessus. Chaque référence mémoire reste alors confinée à sa propre moitié, et chaque domaine bénéficie ainsi d'un cache L2 privé de 96 Mo. Cela ne se limite pas à raccourcir le chemin physique. Sans lignes de cache partagées entre les moitiés, le trafic de cohérence Infinity Fabric entre les deux caches L2 disparaît quasiment, ce qui, selon AMD, se traduit par une latence réduite et une meilleure efficacité pour les applications NUMA. CDNA 4 proposait le même compromis, NPS2 conservant le trafic au sein d'une seule puce d'E/S, mais CDNA 5 l'affine car l'élément localisé est désormais l'intégralité du cache L2 et non plus une portion de tampon mémoire.

Le partitionnement des calculs s'empile en superposition. Les huit XCD permettent au GPU de démarrer avec une, deux, quatre ou huit partitions spatiales, divisant les 432 Go de HBM en tranches égales de 432, 216, 108 ou 54 Go, chacune étant gérée par un XCD. L'association des partitions aux domaines NUMA permet au système d'exécution de répartir et d'allouer spatialement les ressources, de sorte qu'une tâche soit exécutée sur les XCD les plus proches de sa mémoire. SR-IOV virtualise ensuite les partitions en jusqu'à huit machines virtuelles isolées matériellement, l'isolation étant assurée au niveau du système mémoire lui-même, indépendamment du mode NUMA utilisé. Le MI355X offrait déjà les mêmes options de partitionnement (de une à huit), cette granularité n'est donc pas nouvelle. La nouveauté de CDNA 5 réside dans le comportement du cache L2 privé et, au-dessus, dans les modules virtuels au niveau du rack, abordés dans la section Helios.

AMD Helios

Un seul MI455X est rapide. Mais avec ce lancement, AMD rejoint le club des solutions à grande échelle et à montée en charge massive.

Physiquement, Helios abandonne les racks traditionnels de 19 et 21 pouces au profit du format Open Rack Wide, développé avec la collaboration d'AMD et de Meta lors du salon OCP : une baie de 1.2 mètre de large et 1.3 mètre de profondeur offrant 44 unités d'organisation verticale. À l'intérieur, les 72 GPU sont répartis dans deux groupes de neuf plateaux de calcul, entre lesquels sont empilés les six plateaux de commutation. Chaque liaison GPU-commutateur est assurée par un câble en cuivre passant par quatre cartouches à connexion invisible à l'arrière, permettant ainsi l'extraction des plateaux pour la maintenance sans avoir à débrancher manuellement les câbles.

L'ensemble du rack consomme entre 225 et 245 kW selon la charge, fournis par une barre omnibus 50 V refroidie par liquide. Les collecteurs arrière refoulent environ 385 litres de liquide de refroidissement par minute depuis le circuit de l'installation. Les plateaux eux-mêmes sont des composants robustes : chacun pèse environ 77 kg et l'insertion des 1 728 connexions différentielles d'un plateau nécessite une force d'environ 313 kg, ce qui explique pourquoi ses poignées à came s'étendent sur presque toute la largeur du plateau.

Les blocs de construction

Plateau informatique

Dans la configuration de référence, chaque plateau de calcul est un nœud autonome composé de quatre modules MI455X et d'un processeur Venice SP7 à 96 cœurs haute fréquence, cadencé jusqu'à 5 GHz. Ses 16 emplacements DIMM accueillent 1 To de mémoire vive (16 barrettes RDIMM DDR5 ECC de 64 Go), et cinq emplacements NVMe E1.S sont connectés au processeur. La plateforme offre des performances bien supérieures : les 16 canaux mémoire du Venice prennent en charge une bande passante allant jusqu'à 1.6 To/s, et avec les barrettes RDIMM de 256 Go, actuellement en haut de la gamme DDR5, une configuration à 16 canaux (1 barrette par canal) atteint une capacité maximale de 4 To.

À l'instar de NVIDIA, le processeur intègre la mémoire cohérente via Infinity Fabric au lieu de se limiter à une simple interface PCIe derrière les GPU. AMD justifie ce ratio CPU/GPU de 1:4 par un choix délibéré : le cœur lui-même surpasse la concurrence. Selon les estimations d'AMD, à performances égales, le cœur Zen 6 à 5 GHz offre environ 20 % de performances par cœur supérieures à celles du Vera de NVIDIA. De plus, grâce à son socket SP7 standard, les clients souhaitant une puissance de calcul accrue peuvent installer n'importe quelle configuration Venice, jusqu'au modèle phare à 256 cœurs. Un socket Venice offre également une capacité DDR5 bien supérieure à celle d'une architecture LPDDR, et sa bande passante mémoire est pleinement exploitée par les quatre GPU via les liaisons Infinity Fabric.

Cette liaison Infinity Fabric mérite une analyse plus approfondie. Lors d'une discussion avec George Cozma de Chips and Cheese concernant la connexion entre la carte mère Venice et la MI455X , il a suggéré que cette liaison cohérente utilise les lignes PCIe du processeur, à l'instar des liaisons xGMI des sockets EPYC via les interfaces physiques PCIe (PHY) depuis des années. Les chiffres confirment cette hypothèse. Le PCIe Gen 6 émet à 64 Gb/s par ligne, et une liaison x16 à ce débit correspond à 128 Go/s dans chaque sens, soit exactement les 256 Go/s bidirectionnels annoncés par AMD par GPU. Le schéma fonctionnel du livre blanc CDNA 5 indique d'ailleurs une interface Infinity Fabric hôte à 64 Gb/s par ligne, soit le débit exact du PCIe Gen 6. Cette théorie explique également la présence de la carte mère Venice : ses 4 GPU consomment 64 des 128 lignes PCIe Gen 6 du processeur, laissant le reste disponible pour les DPU, le stockage et les autres besoins du système.

Chaque plateau de calcul est traversé par trois réseaux distincts, chacun dédié à une tâche différente. Le plus classique est le réseau frontal : une seule unité de traitement numérique (DPU) Pensando Salina 400G connecte le nœud au réseau standard du centre de données, que nous examinerons plus en détail ultérieurement.

Le second aspect est l'extension horizontale, le réseau qui relie les racks en clusters. La manière la plus simple de le comprendre est de compter les SerDes. L'extension horizontale du MI455X peut utiliser soit PCIe Gen 6 à 64 Gb/s par voie, soit UALink128 à 128 Gb/s. Une carte réseau Vulcano 800 nécessite environ 128 Gb/s de bande passante dans chaque sens pour alimenter son port 800 GbE. À des débits Gen 6, cela requiert une liaison x16 complète par carte réseau ; le GPU prend donc en charge deux cartes réseau. Avec le débit de signalisation doublé d'UALink128, une liaison x8 remplit la même fonction sur la moitié des SerDes ; le GPU en prend donc trois, ce qui correspond à la configuration livrée par Helios. Dans les deux cas, le saut UALink128 n'est rien de plus qu'une liaison privée entre le GPU et la carte réseau ; le réseau lui-même commence au niveau du Vulcano. Chaque carte réseau (NIC) gère un port 800 GbE compatible UEC, notamment MRC, le protocole multipath développé par OpenAI en collaboration avec AMD et d'autres partenaires. Physiquement, les cartes réseau sont installées sur deux cartes personnalisées par plateau, chacune intégrant quatre ou six ASIC Vulcano, correspondant aux configurations à deux ou trois ASIC par GPU. Au final, on obtient douze cartes réseau par plateau et une bande passante extensible de 2 400 Gb/s par GPU. Grâce à la connexion directe des cartes réseau aux GPU, le CPU étant totalement hors du chemin de transmission, le trafic entre les racks n'emprunte jamais la liaison hôte.

Le troisième élément est la montée en charge, l'architecture qui fait d'Helios un véritable système à l'échelle d'un rack. Chaque GPU dispose de 36 liaisons UALoE qui exécutent la sémantique mémoire UALink sur l'Ethernet ESUN, chaque liaison supportant un débit de 400 Gbit/s, soit une bande passante bidirectionnelle totale de 3.6 To/s par GPU. Ces liaisons sortent à l'arrière du plateau vers les plateaux de commutation, acheminant le trafic de chargement et de stockage qui fusionne les 72 GPU en un seul module de mémoire partagée.

Changer de plateau

Vient ensuite les plateaux de commutation, et ce qui frappe le plus, c'est la banalité de leurs puces. Chacun des six plateaux contient deux ASIC Broadcom Tomahawk 6, les mêmes puces de commutation Ethernet commerciales que les hyperscalers déploient dans leurs réseaux leaf-spine, chacune prenant en charge 512 voies à 200 Gbit/s.

Chaque GPU envoie 3 liaisons UALoE (chaque liaison UALoE étant composée de 2 voies de 200 Gbit/s) à chacun des 12 commutateurs, 144 liaisons quittant chaque plateau de calcul via les connecteurs de câbles arrière. Chaque Tomahawk gère ainsi 216 liaisons à 400 Gbit/s, soit une bande passante bidirectionnelle de 21.6 To/s, tandis que chaque GPU conserve ses 36 liaisons (72 voies de 200 Gbit/s) et sa bande passante de 3.6 To/s. Les commutateurs n'ont besoin d'aucune technologie complexe pour cela : l'encapsulation UALoE repose sur un protocole L2 standard, le transfert utilise la programmation MAC statique, une fonctionnalité des puces Ethernet depuis vingt ans, et le contrôle de flux est un contrôle de flux prioritaire standard.

Avec une architecture à un seul niveau, des pans entiers de problèmes de congestion des centres de données sont éliminés : il n'y a pas d'interconnexion multi-niveaux et chaque GPU est situé à une distance fixe de tous les autres, avec une latence de saut précise. Comparée à une architecture maillée directe, cette approche commutée permet également à un flux unique d'accaparer la totalité de la bande passante d'un chemin lorsqu'une charge de travail le requiert, et maintient chaque GPU à égale distance. Ainsi, la planification n'a pas à se soucier de la localité et chaque liaison bénéficie de la même protection contre les pannes.

Tolérance aux pannes

Helios intègre les pannes matérielles dès sa conception. À cette échelle, les défaillances sont fréquentes : câble défectueux, paquet perdu, commutateur mis hors service pour une mise à jour du firmware, baie de calcul hors service. L’architecture est conçue pour qu’aucun de ces événements n’interrompe une tâche. Les paquets perdus sont récupérés par retransmission, et en cas de défaillance d’une liaison, d’un câble ou d’un commutateur, le trafic est automatiquement redirigé après une brève interruption, la charge de travail se poursuivant sur la bande passante restante au lieu de redémarrer à partir d’un point de contrôle.

La topologie à 12 plans assure une dégradation progressive, et le découpage en trois voies détermine l'amplitude de la dégradation. Si l'une des trois liaisons reliant un GPU à un commutateur tombe en panne, ce plan conserve les deux tiers de sa bande passante. En cas de panne d'un Tomahawk entier, chaque GPU perd 1/12 de sa bande passante de montée en charge, tandis que la communication globale continue de fonctionner sur les 11 autres plans. Même la perte d'un plateau de commutateurs complet (2 des 12 commutateurs) ne coûte à chaque GPU qu'un sixième de sa bande passante, sans interruption de connectivité, car aucun GPU ne dépend d'un seul commutateur pour communiquer avec un autre. À titre de comparaison, la Vera Rubin NVL72 répartit chaque GPU sur 36 ASIC NVSwitch 6 dans 9 plateaux ; la panne d'un plateau de commutateurs y entraîne donc une perte d'environ un neuvième de bande passante. NVIDIA compense cette dégradation par un nombre d'ASIC de commutateurs trois fois supérieur ; AMD rétorque que 12 commutateurs à plus grande capacité réduisent le nombre de composants, de câbles et de connecteurs susceptibles de tomber en panne. Pour une période d'entraînement se mesurant en semaines, la différence entre perdre un sixième de la bande passante du réseau et perdre le travail représente la totalité du coût économique du rack.

Capsules virtuelles

Le même mécanisme qui partitionne l'infrastructure en cas de panne peut également la partitionner intentionnellement. AMD nomme ce concept « Pods virtuels » (vPods), et l'unité de base est le nœud de calcul : toute combinaison des 18 nœuds 4 GPU du rack peut être isolée dans un pod, allant d'un seul nœud pour un petit client à la quasi-totalité du rack pour une tâche d'entraînement importante. L'isolation est assurée au niveau matériel, en deçà de toute décision du planificateur. Un vPod est lié à son client ; les autres pods n'ont aucun accès à sa mémoire ni à son trafic. Le chiffrement AES-256-GCM à débit maximal sur chaque liaison UALoE, avec prise en charge des clés de cluster appartenant au client, garantit l'opacité des tenseurs d'un client pour les autres. Une machine virtuelle invitée répartie sur plusieurs GPU voit son domaine de sécurité étendu de manière transparente à l'ensemble de ces derniers, sans qu'il soit nécessaire de faire confiance au système d'exploitation hôte. NVIDIA résout le même problème sur ses racks NVL72 en divisant le domaine NVLink en partitions, son service IMEX assurant la liaison entre les nœuds qui peuvent exporter et importer de la mémoire ; les vPods sont l'équivalent dans l'univers UALoE, les opérateurs venant de flottes GB200 ou GB300 trouveront donc le concept familier.

En cas de panne d'un plateau de calcul, l'impact s'arrête à son vPod : la charge de travail redémarre à partir d'un point de contrôle tandis que tous les autres pods continuent de fonctionner sans interruption, la limite du locataire servant également de limite de panne. Le partitionnement s'imbrique également à tous les niveaux, puisqu'un seul MI455X peut être divisé en jusqu'à 8 machines virtuelles SR-IOV. Ainsi, un même rack peut prendre en charge un client utilisant les 72 GPU dans un seul pod, ou jusqu'à 576 locataires répartis sur plusieurs tranches de GPU, avec une isolation matérielle à chaque niveau de cette hiérarchie.

Le plan de gestion

L'ensemble du système repose sur une pile logicielle dédiée, fidèle au principe d'ouverture du matériel. AMD Fabric Manager (AFM) constitue le plan de contrôle : il détecte et provisionne l'infrastructure 72 GPU avec une mise en service automatique (sans intervention), la simple mise sous tension du rack suffisant à activer les 72 GPU. Il vérifie ensuite le câblage des cartouches pour détecter les erreurs d'assemblage, divise le rack en vPods et coordonne le réacheminement et la récupération décrits précédemment. Il n'y a pas de baie de gestion dédiée. AFM s'exécute sur les processeurs de gestion des baies de commutation, sous la forme de 3 instances redondantes réparties sur les 6 baies, avec une base de données distribuée. Ainsi, la perte d'une baie de commutation n'affecte pas le plan de contrôle. Une API REST accessible au nord permet aux contrôleurs de cluster de gérer plusieurs racks d'accéder à l'infrastructure.

Sous le capot, AFM emprunte son architecture au monde du cloud natif, reposant sur des contrôleurs standard de type Kubernetes avec des agents sur chaque baie. Il gère les détails techniques de l'infrastructure que les utilisateurs ne souhaitent jamais voir, jusqu'à l'attribution des identifiants d'accélérateur utilisés par UALink pour adresser chaque GPU. Il constitue également la couche d'observabilité du rack. Un tableau de bord unique suit l'utilisation des GPU et de l'infrastructure, l'état des liaisons et les incidents. En cas de problème, il affiche la résolution en cours et génère des alertes que les opérateurs peuvent intégrer à leurs outils. La capture d'écran ci-dessus montre AFM supervisant un cluster Helios dans les laboratoires d'AMD. La gestion fonctionne en bande ou hors bande, de sorte que les diagnostics et la configuration n'interrompent jamais les charges de travail en cours d'exécution. Les commutateurs sous-jacents à AFM exécutent un système d'exploitation réseau basé sur SONiC, le système d'exploitation réseau open source. AMD précise que ses ajouts UALoE seront intégrés au noyau et exposés via les API gNMI standard. Au-dessus du rack, un gestionnaire d'infrastructure de rack couvre le cycle de vie des nœuds et des commutateurs, l'alimentation et la détection des fuites, et un contrôleur de cluster connecte Helios à Kubernetes et Slurm pour la planification.

Helios contre NVIDIA Vera Rubin NVL72

Voyons donc comment cela se compare à l'offre NVIDIA que Helios rencontrera réellement sur le marché : la Vera Rubin NVL72.

Rack métrique	AMD Helios	Vera Rubin NVL72
GPU	72 MI455X	72 rubis
CPU	18 Venise	36 Véra
Capacité HBM	31TB	20.7TB
Bande passante HBM	1.7 PB/s	1.58 PB/s
Évolutivité par GPU	3.6 To / s	3.6 To / s
Extension de rack	260 To / s	260 To / s
Extension horizontale par GPU	2,400 Gb / s	1,600 Gb / s
Commutateurs de mise à l'échelle	12 Tomahawk 6	36 NVSwitch 6
Format rack	ORW double largeur	MGX à une seule largeur

Sur le papier, la donne penche en faveur d'AMD : 50 % de mémoire HBM en plus, une capacité de montée en charge de 3.6 To/s par GPU identique grâce à un tiers d'ASIC de commutation en moins, et une bande passante d'extension horizontale 50 % supérieure par GPU. Les tests internes d'AMD transforment ces spécifications en performances annoncées, avec 10 à 15 % de jetons supplémentaires par seconde et par GPU sur Kimi K2 Thinking, et jusqu'à 30 % de jetons supplémentaires par dollar dépensé. Il s'agit des chiffres d'AMD comparés à ceux publiés par NVIDIA, et non de mesures indépendantes, mais ils définissent le niveau de référence auquel AMD souhaite être évalué. Les différences les plus intéressantes résident dans la manière dont chaque architecture connecte ses GPU au monde extérieur.

Commençons par l'architecture à extension horizontale. Les cartes réseau du MI455X sont directement connectées au GPU. Selon SemiAnalysis, ce n'est pas le cas de celles du Rubin : toujours selon SemiAnalysis, le boîtier ne dispose pas du port PCIe nécessaire pour alimenter les deux cartes réseau ConnectX-9, qui sont donc connectées au processeur Vera. Le trafic du GPU emprunte alors un long chemin : Rubin → NVLink-C2C → Vera → PCIe → ConnectX-9. Ce détour engendre une latence et surcharge la liaison C2C. Lorsque le calcul, le trafic hôte et le réseau sont tous saturés simultanément, une partie de la bande passante C2C de Vera est utilisée pour transporter les données des cartes réseau, et la bande passante hôte effective dont bénéficie le GPU chute en dessous des 1.8 To/s annoncés.

Le calcul de la bande passante amplifie encore la situation. Chaque MI455X offre une capacité de montée en charge de 2 400 Gbit/s contre 1 600 Gbit/s pour le Rubin ; Helios transporte donc davantage de ressources réseau par unité de puissance de calcul (FLOP). Les simulations d'AMD d'une session d'entraînement sur 8 000 GPU attribuent à la troisième carte réseau un gain d'environ 13 % sur l'exécution des tâches.

Rubin riposte sur le plan du stockage, et la raison tient encore une fois à l'emplacement de la carte réseau. ConnectX-9 intègre un commutateur PCIe, permettant ainsi aux périphériques NVMe de se connecter directement à la carte réseau et à un GPU de récupérer des données via GPUDirect Storage sans solliciter le CPU. Le MI455X ne dispose d'aucun équivalent : son stockage est rattaché à l'hôte Venice, ce qui signifie que toute donnée utilisant GPUDirect doit transiter par le CPU et revenir via la liaison Infinity Fabric. AMD a optimisé le chemin réseau au détriment du chemin de stockage ; NVIDIA a fait le choix inverse. Le choix le plus important dépend de la nature de la charge de travail : transfert d'activations entre GPU ou streaming de données depuis le disque.

Ce que les clients peuvent changer

En résumé, tout ce qui précède décrit la conception de référence d'AMD, et plusieurs des chiffres indiqués correspondent à des configurations minimales que les clients peuvent dépasser. Le cas le plus évident est celui du processeur hôte. La Vera de Rubin est proposée dans une configuration fixe ; la Venice, intégrée à un châssis Helios, est un processeur SP7 standard, et AMD a confirmé que toutes les références Venice sont compatibles sans aucune personnalisation spécifique à Helios. Le châssis de référence utilise le processeur 96 cœurs à 5 GHz, car la vitesse monocœur permet de privilégier l'alimentation des GPU. Toutefois, rien n'empêche un client de configurer sa version avec le modèle haut de gamme à 256 cœurs, ou avec la Venice-X et ses 1 152 Mo de cache L3 empilé pour le prétraitement gourmand en ressources.

La mémoire et le réseau suivent la même logique d'emplacement et de socket. La mémoire DRAM de référence de 1 To est composée de 16 modules RDIMM de 64 Go ; des modules DIMM plus denses permettent d'atteindre 4 To par plateau, et les MRDIMM-12800 exploitent pleinement le débit de 1.6 To/s de Venice. Côté réseau, une configuration peut passer de 3 cartes réseau par GPU à 2 via PCIe Gen 6 standard ; chaque port Vulcano peut fonctionner en 1x800G, 2x400G, 4x200G ou 8x100G avec les architectures Tomahawk 5 ou Tomahawk 6, et le pipeline P4 laisse le choix du protocole de transport (RoCEv2, MRC ou une solution propriétaire) à l'opérateur. Même le plan de gestion est interchangeable, car le système d'exploitation du commutateur est SONiC (open source) et AFM expose l'ensemble de l'architecture via son API nord.

La consommation électrique est également liée au socket. Les superpuces NVIDIA partagent une même enveloppe thermique : la Vera est un composant de 450 W avec une limite de consommation, et les générations récentes répartissent la puissance vers les GPU en cas de forte charge. AMD n'a pas précisé si la conception de référence limite ou répartit la consommation du processeur, mais avec cette approche, le choix revient au client, qui peut ainsi personnaliser son système pour une consommation plus élevée sans répartition de la puissance.

L'architecture PCIe sous-jacente de la liaison hôte, dissimulée dans le compartiment de calcul, ouvre une dernière possibilité, certes hypothétique. Venice prend en charge les configurations 2P, et certaines plateformes hôtes d'IA peuvent fonctionner en 2P avec jusqu'à 160 lignes PCIe utilisables en privilégiant les E/S au détriment de la largeur des interfaces xGMI inter-sockets. Un client pourrait théoriquement concevoir un compartiment à deux sockets pour atteindre le ratio CPU/GPU de 1:2 de NVIDIA, ou optimiser les liaisons xGMI afin d'augmenter la bande passante effective entre le CPU et le GPU. Rien n'indique que ce type de configuration soit actuellement développé, et aucune de ces solutions ne permet de combler l'écart de débit avec NVLink-C2C (1.8 To/s). En réalité, le client a le contrôle total : sur Helios, l'hôte, sa mémoire, son alimentation et potentiellement sa topologie sont à sa discrétion, tandis que la puce NVIDIA ne lui laisse aucune liberté de choix.

Le DPU de Salina

Revenons-en au réseau frontal que nous avons évoqué précédemment. La Salina, DPU Pensando de 3e génération d'AMD, est une carte 400G dotée d'un chemin de données entièrement programmable P4. Ainsi, toute nouvelle encapsulation, connexion de télémétrie ou protocole de transport est implémentée via une simple mise à jour du firmware, appliquée en temps réel sans interruption de trafic. Les services inclus couvrent déjà l'ensemble des besoins du réseau frontal : SDN avec VXLAN ou NVGRE, pare-feu dynamique capable de gérer des millions de règles, IPsec à débit maximal, PSP, DTLS ou chiffrement personnalisé, NAT et répartition de charge. C'est également le composant le plus éprouvé du marché. Les DPU Pensando équipent les hyperscalers depuis 2019 ; la Salina est aujourd'hui déployée chez Microsoft, Oracle et IBM. Oracle attribue à cette gamme un gain de performance SDN multiplié par cinq, et un hyperscaler a récupéré 22 cœurs de processeur par serveur en lui déchargeant les E/S.

Le stockage constitue la deuxième étape. Salina expose les périphériques NVMe-over-Fabrics à l'hôte, virtualisant les pools SSD distants via TCP ou RDMA, le chiffrement, les condensés et la compression étant effectués sur la carte. Sur Helios, elle ajoute une astuce héritée de l'ère des agents : un moteur de mémoire contextuelle présente un périphérique KV émulé, de sorte que le cache KV saturé se déverse dans la DRAM du processeur, le SSD local ou le stockage distant, puis est réinjecté dans la HBM à débit de ligne au lieu d'être recalculé. Comme indiqué dans la comparaison avec Rubin, la MI455X ne prend pas en charge GPUDirect Storage ; ce déchargement KV représente la réponse partielle d'AMD pour le trafic le plus important pour le service.

C'est également là que résident nos réserves. L'écart de bande passante est flagrant : Salina est une carte 400 Gbit/s, tandis que la BlueField-4, installée dans les baies Vera Rubin, double ce débit à 800 Gbit/s grâce à un processeur Grace 64 cœurs et une interface ConnectX-9 intégrée. L'écart logiciel est plus discutable, mais bien réel. La plateforme DOCA de NVIDIA offre aux développeurs des services conteneurisés et préconfigurés, programmables en C et C++ classiques ; le P4, quant à lui, est un langage de plan de données spécialisé que la plupart des équipes n'ont jamais utilisé. La comparaison ne se résume pas à « le catalogue DOCA contre le P4 brut », car Salina est livrée avec ses principaux services complets, et les hyperscalers qui l'utilisent l'ont choisie notamment parce que le P4 permet d'intégrer de nouveaux protocoles comme MRC au firmware avant même la sortie des puces. La véritable différence réside dans le public cible de cette programmabilité. La flexibilité de Salina est un atout majeur pour AMD et les équipes hyperscale maîtrisant le P4 ; DOCA est une boîte à outils accessible à tout développeur d'entreprise. Pour le grand public, la solution logicielle de NVIDIA est plus facile à prendre en main, et AMD en est conscient.

ROCm.IA

Côté logiciel, AMD a réservé l'une de ses annonces les plus importantes à sa plateforme elle-même. ROCm.AI, disponible en août, est la tentative d'AMD de rendre sa plateforme GPU entièrement automatisée. Grâce à AI Skills, ROCm s'intègre aux agents de programmation déjà utilisés par les développeurs (Claude, Codex, Cursor et Gemini), permettant ainsi une installation, un déploiement et un débogage sur Instinct en langage naturel. Hyperloom est la nouveauté la plus audacieuse : un optimiseur entièrement automatisé qui profile une charge de travail, ajuste sa configuration de déploiement, réécrit les noyaux du GPU et valide les résultats pendant que l'opérateur dort. AMD affirme optimiser en continu quelque 14 000 modèles actuellement, et une démonstration en direct a permis d'obtenir un débit supérieur de 38 % sur MiniMax M3. Sous les agents, FlyDSL apporte un contrôle quasi-assembleur à Python, ROCm adopte un cycle de publication fixe de 6 semaines, et AMD affirme que ROCm.AI offre un gain moyen de 3.3x en inférence et de 2.4x en entraînement par rapport à ROCm 7 sur un matériel identique. ROCm 7 avait déjà marqué une réelle amélioration ; AMD mise désormais sur l’IA pour accélérer le rythme.

La diapositive la plus importante de la session logicielle était sans doute celle consacrée au matériel. AMD a insisté sur le fait que chaque chiffre affiché avait été mesuré, sous-entendant que la puce MI455X est opérationnelle et performante sous ROCm dès aujourd'hui. Les chiffres : 20 To/s en décodage FP8 MLA, 20 PFLOPS en calcul FP4, 3.2 To/s de bande passante pour l'extension verticale et 190 Go/s pour l'extension horizontale. Lors de la séance de questions-réponses, AMD a reconnu que le résultat FP4 correspondait à une mesure MAMF (Max-Achievable-Matmul-FLOPS), effectuée avec la configuration de matrice la plus avantageuse pour le dispositif, une pratique courante pour ce type de benchmark. C'est également une révélation audacieuse : AMD admet ouvertement que la MI455X atteint environ 50 % de sa puissance de calcul maximale MXFP4 de 40.26 PFLOPS, un chiffre que la plupart des fournisseurs auraient tendance à dissimuler.

AMD affirme qu'il s'agit de la puissance de calcul la plus élevée démontrée pour un accélérateur sur le marché, mais il convient d'être prudent. Le FP4 d'AMD est OCP MXFP4 ; celui de NVIDIA est NVFP4. Leurs méthodes de calcul diffèrent : NVFP4 applique une mise à l'échelle FP8 fractionnaire à chaque bloc de 16 éléments, plus une mise à l'échelle au niveau du tenseur, tandis que le MXFP4 de base utilise une mise à l'échelle plus grossière, de type puissance de deux, tous les 32 éléments. Par conséquent, un FLOP NVFP4 représente une puissance de calcul supérieure à un FLOP MXFP4. CDNA 5 peut également appliquer une mise à l'échelle fractionnaire au MXFP4, mais AMD n'a pas précisé la méthode utilisée pour la mesure. Les tests MAMF sur Rubin et MI455X ne mesurent pas les mêmes calculs ; les comparaisons FP4 entre constructeurs se limitent donc au niveau de l'application : le nombre de jetons par seconde à précision égale. Les mesures dépassent les projections, mais ces chiffres sont plus pertinents par rapport à la génération précédente d'AMD, où les gains de 3 à 4 fois sont incontestables.

Il existe cependant un argument en faveur d'AMD. Ces résultats préliminaires de ROCm.AI, obtenus sur des puces flambant neuves, sous-estiment probablement les performances qu'atteindra un déploiement en production optimisé manuellement. Le verdict définitif sera rendu lorsque ces serveurs seront déployés dans les centres de données des hyperscalers.

Réflexions de clôture

Helios est le système le plus complet jamais commercialisé par AMD, et le premier à affronter directement NVIDIA à l'échelle d'un rack plutôt que puce par puce. Le bilan est sans appel : AMD domine les domaines qui déterminent aujourd'hui la capacité d'IA : 50 % de mémoire HBM en plus par GPU, une parité de montée en charge avec Rubin, une bande passante d'extension horizontale supérieure de 50 % et, selon les propres modélisations d'AMD, jusqu'à 30 % de jetons supplémentaires par dollar. La manière dont ce système a été conçu est tout aussi importante : commutateurs Tomahawk pour les revendeurs, standards ouverts des formats numériques jusqu'à l'armoire, et un hôte à sockets laissant la configuration finale au client. NVIDIA conserve des avantages indéniables au niveau de la liaison hôte C2C, du DPU et de son interface logicielle, mais pour la première fois, sur le papier, l'argument matériel global penche en faveur d'AMD.

Et les acheteurs le confirment. OpenAI, Meta, Anthropic, Microsoft et Oracle figurent parmi les entreprises qui, selon AMD, adoptent Helios, et AMD souligne que les racks sont déjà en production. À l'instar de NVIDIA, le calendrier de développement est désormais annuel : la série MI500, basée sur l'architecture CDNA 6, arrivera en 2027 avec de la mémoire HBM de nouvelle génération, ainsi que des interconnexions cuivre et optiques, et la série MI600 est déjà en développement pour 2028.

Reste donc le logiciel, et pour la première fois depuis des années, nous n'allons pas conclure un article sur les GPU AMD sur cette seule réserve. ROCm 7 a comblé de véritables lacunes, ROCm.AI arrive en août avec des gains significatifs, et le rythme de publication est désormais fixe à six semaines. L'identité des acheteurs compte également. Les laboratoires et les hyperscalers qui signent ces contrats collaborent avec AMD à la conception et emploient suffisamment d'ingénieurs pour résoudre les éventuels problèmes rencontrés. Les entreprises qui ont besoin d'une solution clé en main représentent un cas différent, et ce marché reste pour l'instant celui de NVIDIA. Mais Helios a été conçu pour les hyperscalers et les laboratoires d'IA, et pour eux, le matériel est prêt, le logiciel suit le rythme et les serveurs sont livrés. AMD n'a jamais été aussi bien positionné.