AMD Helios réunit 72 GPU, mais Nvidia fixe la barre
AMD a lancé Helios comme un seul système de 72 GPU, et non comme un ensemble disparate de serveurs accélérateurs reliés au sein d’une baie. L’article d’architecture d’AMD ServeTheHome est important, car l’entreprise contrôle désormais presque toutes les grandes couches de son rack d’IA.
Helios associe des accélérateurs Instinct MI455X, des processeurs EPYC Venice, la mise en réseau Pensando, les logiciels ROCm et une infrastructure d’alimentation refroidie par liquide. Broadcom fournit les puces de commutation Ethernet standard qui relient les GPU au moyen d’un seul fabric scale-up.
Cette combinaison crée le véritable affrontement. AMD ne défie plus Nvidia avec une simple carte accélératrice. L’entreprise remet en cause le modèle de rack de Nvidia tout en rejetant l’approche réseau fermée qui a contribué à rendre les systèmes de Nvidia difficiles à reproduire.
Helios paraît crédible sur le papier. Toutefois, les spécifications de pointe ne permettent pas d’établir les performances applicatives réellement fournies, la maturité logicielle, les volumes d’approvisionnement ou l’économie d’exploitation. Ces questions non résolues détermineront si l’ouverture devient un avantage à l’achat ou une simple préférence architecturale.
Ce que révèle la couverture d’AMD ServeTheHome à l’intérieur de Helios
Helios fait passer l’unité de concurrence d’AMD d’un GPU à un rack d’IA intégré.
Le système comprend 72 accélérateurs Instinct MI455X répartis sur 18 plateaux de calcul refroidis par liquide. Chaque plateau embarque quatre GPU et un socket pour un processeur EPYC 9006 de sixième génération, baptisé Venice.
AMD attribue 432 Go de mémoire HBM4 à chaque MI455X. À l’échelle du rack, cela représente environ 31 To de mémoire à large bande passante disponible au sein du domaine scale-up.
La mémoire à large bande passante, ou HBM, est placée à proximité du GPU et fournit des données à des débits bien supérieurs à ceux de la mémoire serveur conventionnelle. Cette capacité compte pour les grands modèles, les contextes longs, les caches d’inférence et les charges de travail qui exigeraient autrement davantage de partitionnement.
AMD indique jusqu’à 23,3 To/s de bande passante mémoire pour chaque MI455X dans sa documentation sur l’architecture CDNA 5. Le rack agrège ces appareils dans un système mémoire offrant plus d’un pétaoctet par seconde de bande passante théorique.
L’agencement physique est aussi important que le nombre d’accélérateurs. Helios utilise un châssis Open Rack Wide de l’Open Compute Project, plus large qu’une baie conventionnelle. Cette conception libère de l’espace pour des plateaux de calcul denses, le câblage, l’équipement d’alimentation et le matériel de refroidissement liquide.
Le rack comprend six plateaux de commutateurs scale-up. Chaque plateau contient deux puces de commutation Broadcom Tomahawk 6, ce qui porte le total à 12 puces de commutation dans le système.
Chaque composant Tomahawk 6 offre une capacité de commutation de 102,4 Tb/s. Ses voies Ethernet constituent le fabric interne qui permet à chaque accélérateur de communiquer avec tous les autres via un seul saut de commutation.
Ce fabric transporte UALink sur Ethernet, souvent abrégé en UALoE. UALink définit une connexion scale-up pour les accélérateurs, tandis qu’Ethernet fournit le transport sous-jacent et le matériel de commutation standard.
AMD affirme que chaque MI455X bénéficie de 3,6 To/s de bande passante scale-up bidirectionnelle. Sur 72 appareils, le chiffre agrégé atteint environ 260 To/s.
C’est le mécanisme qui soutient l’affirmation d’AMD selon laquelle Helios se comporte comme un seul système de 72 GPU. Les clusters traditionnels répartissent souvent la propriété de la mémoire entre des serveurs distincts, puis font transiter les données par plusieurs niveaux de réseau.
Helios réduit ces frontières à l’intérieur du rack. Il contient toujours des processeurs et des dispositifs mémoire distincts, mais son fabric à saut unique offre au logiciel un domaine d’accélérateurs plus étroitement connecté.
Les spécifications du MI455X d’AMD montrent également à quel point la mise en réseau a été intégrée au boîtier du GPU. Chaque module accélérateur comprend deux dies d’E/S améliorés et 36 liens UALoE bidirectionnels.
Cette évolution fait du réseau une partie de l’architecture de l’accélérateur. Il ne s’agit plus d’un accessoire choisi une fois la plateforme de calcul conçue.
Helios utilise également du matériel Pensando pour les communications au-delà du domaine scale-up. Chaque GPU peut se connecter à trois cartes d’interface réseau Vulcano de 800 Gb/s, offrant jusqu’à 2,4 Tb/s de bande passante scale-out par accélérateur.
Le réseau scale-out relie plusieurs racks dans un déploiement plus vaste. Une unité de traitement des données Pensando Salina gère le trafic frontal, notamment la gestion, l’accès au stockage et les requêtes applicatives.
Le rack contient donc deux couches réseau distinctes. Les puces Broadcom relient les accélérateurs à l’intérieur de Helios, tandis que les appareils AMD Pensando connectent Helios au stockage, aux services et aux autres racks.
L’alimentation complète le système. Une barre omnibus de courant continu de 50 volts, située à l’arrière, alimente le rack, tandis que le refroidissement liquide évacue la chaleur de ses composants denses.
Des reportages issus de l’événement Advancing AI d’AMD ont situé la charge du rack entre 225 kW et 245 kW. Cette exigence rend Helios inadapté aux salles de données ne disposant pas d’une alimentation haute densité et d’un support de refroidissement liquide.
Le rack peut aussi peser environ 5 000 livres, selon les détails publiés sur la plateforme. Les acheteurs doivent considérer son déploiement comme un projet d’infrastructure, et non comme un simple renouvellement de serveurs.
L’accent mis par ServeTheHome sur l’architecture est donc justifié. Le produit central est l’intégration elle-même, y compris le calcul, la mémoire, le réseau, l’alimentation, le refroidissement, la mécanique et les logiciels.
Pourquoi AMD devait construire dès maintenant le rack complet
Nvidia a contraint chaque fournisseur sérieux d’accélérateurs à concourir à l’échelle du système.
Les charges de travail d’IA modernes passent beaucoup de temps à déplacer des données entre accélérateurs. Des calculs plus rapides ne sont utiles que lorsque les modèles, les activations et les résultats intermédiaires peuvent atteindre les moteurs de calcul sans provoquer de longues périodes d’attente.
Cette réalité favorise les systèmes conçus comme des unités coordonnées. Nvidia a établi ce modèle avec ses plateformes NVL72, qui associent 72 GPU, des CPU, de la commutation NVLink, du réseau, du refroidissement et des logiciels.
AMD vendait auparavant des accélérateurs compétitifs que les fournisseurs de systèmes assemblaient en serveurs et en clusters. Ce modèle offrait un choix aux clients, mais laissait davantage de travail d’intégration hors du contrôle direct d’AMD.
L’entreprise pouvait améliorer un GPU tout en perdant au niveau du système. La topologie réseau, les communications collectives, les limites de refroidissement, l’optimisation logicielle et la conception des serveurs pouvaient effacer un avantage mesuré sur l’accélérateur.
Helios remédie à cette faiblesse en fournissant une architecture de référence complète. AMD spécifie le plateau de calcul, la topologie scale-up, le réseau scale-out, le format du rack, l’alimentation, l’approche de refroidissement et les logiciels associés.
Le calendrier reflète également l’arrivée de CDNA 5, la dernière architecture de calcul dédiée aux centres de données d’AMD. MI455X utilise huit chiplets de calcul fabriqués selon un procédé de 2 nm et les place au-dessus de deux dies de fabric et de cache en 3 nm.
Deux dies d’E/S supplémentaires gèrent les communications externes. Douze piles HBM4 entourent la logique, tandis qu’un packaging avancé relie les composants en un seul module accélérateur.
Cette conception en chiplets permet à AMD d’optimiser différentes fonctions avec différents procédés de fabrication. La densité de calcul, les interfaces mémoire, le cache et le réseau n’ont pas tous besoin des mêmes caractéristiques de silicium.
MI455X contient 320 milliards de transistors et 256 processeurs de groupes de travail. Un processeur de groupe de travail organise les ressources d’exécution qui traitent des groupes d’opérations d’IA et de calcul scientifique.
AMD cible les calculs d’IA à faible précision avec des formats tels que MXFP4, MXFP6, MXFP8 et FP8. Ces formats représentent les valeurs des modèles avec moins de bits, ce qui accroît le débit lorsqu’une application peut préserver une précision acceptable.
L’accélérateur atteint un pic annoncé de 40,3 pétaflops pour les opérations MXFP4. À l’échelle du rack, AMD annonce jusqu’à 2,9 exaflops de performances FP4 de pointe et 1,4 exaflops en FP8.
Ces chiffres correspondent à des pics théoriques, et non à des résultats mesurés pour un modèle complet. Ils expliquent néanmoins pourquoi l’intégration du rack est arrivée parallèlement au MI455X.
Un seul accélérateur déplace désormais suffisamment de données et consomme suffisamment d’énergie pour que le système qui l’entoure détermine si les applications peuvent exploiter la puissance de calcul disponible. AMD avait besoin de Helios pour exposer les capacités de CDNA 5 à une échelle significative.
L’entreprise a également acquis ZT Systems en 2025, obtenant une expérience d’ingénierie dans la conception de racks hyperscale. AMD a ensuite séparé l’activité de fabrication, limitant ainsi la concurrence directe avec les partenaires serveurs établis.
Cette opération a apporté à AMD une expertise système plus poussée sans l’obliger à devenir l’unique fournisseur de Helios. HPE, Supermicro, les fournisseurs cloud et d’autres partenaires peuvent concevoir des produits à partir de l’architecture de référence.
Microsoft a annoncé son intention de déployer Helios dans ses centres de données. HPE s’était auparavant engagé à adopter l’architecture, donnant à AMD des voies d’accès aux infrastructures hyperscale comme aux infrastructures d’entreprise.
AMD a déclaré au CES que Helios servirait de plan directeur pour des systèmes d’IA bien plus vastes. Son aperçu du rack à grande échelle a relié la conception à l’entraînement, à l’inférence et aux futurs déploiements multi-racks.
La pression s’étend donc au-delà de Nvidia. Les fabricants de serveurs doivent décider dans quelle mesure adopter l’ingénierie d’AMD, tandis que les fournisseurs cloud doivent déterminer si une plateforme de référence ouverte réduit le risque d’intégration.
Les fournisseurs de puces sont également confrontés à un nouveau modèle d’achat. Les clients évaluent de plus en plus les accélérateurs comme des éléments de systèmes complets, et non comme des cartes interchangeables avec des scores de benchmark isolés.
L’Ethernet ouvert est le principal défi d’AMD à Nvidia
La compétition centrale oppose le rack Ethernet ouvert d’AMD à la plateforme NVLink contrôlée verticalement par Nvidia.
Helios ressemble à la Vera Rubin NVL72 de Nvidia sur plusieurs points importants. Les deux intègrent 72 accélérateurs sur 18 plateaux de calcul refroidis par liquide, et les deux utilisent des plateaux de commutation dédiés aux communications à large bande passante.
La différence tient au contrôle du réseau scale-up. Nvidia intègre NVLink et la commutation NVLink dans sa plateforme, ce qui lui donne une autorité directe sur le protocole, le silicium, la topologie et l’intégration logicielle.
AMD utilise une liaison d’accélérateurs ouverte transportée par Ethernet. Broadcom fournit les puces de commutation Tomahawk 6, tandis qu’UALink définit la manière dont les accélérateurs communiquent à travers ce fabric.
Ce choix permet à AMD d’utiliser une technologie réseau standard plutôt qu’une architecture de commutation propriétaire. Les fournisseurs de systèmes et les hyperscalers peuvent travailler avec des outils Ethernet, des fournisseurs et des pratiques opérationnelles familiers.
L’ouverture ne signifie pas que chaque composant peut être échangé sans travail d’ingénierie. Les réseaux scale-up imposent des exigences strictes de latence, de congestion, de fiabilité, de synchronisation et de logiciels.
Toutefois, les interfaces publiées donnent davantage de latitude aux partenaires pour personnaliser le rack. Un fournisseur cloud peut ajuster les choix de réseau, de gestion ou de déploiement sans dépendre d’un seul fournisseur pour chaque couche.
Le rôle de Broadcom rend cette affirmation plus concrète. Tomahawk 6 fournit 512 voies à 200 Gb/s, avec une capacité suffisante pour alimenter les 72 GPU au débit scale-up annoncé par AMD.
Le rapport d’architecture de Helios montre pourquoi ce partenariat est important. Le portefeuille matériel d’AMD est vaste, mais l’entreprise n’a pas besoin de fabriquer chaque composant pour contrôler la conception du système.
Cela crée une alternative à Nvidia fondée sur une coalition. AMD apporte les GPU, les CPU, les appareils réseau Pensando, les logiciels et l’ingénierie de la plateforme. Broadcom apporte les puces centrales de commutation scale-up.
HPE et d’autres fabricants peuvent ensuite transformer ce plan directeur en systèmes. Les opérateurs cloud peuvent déployer ces systèmes tout en conservant davantage d’influence sur les choix de réseau et de logiciels.
Nvidia propose l’approche inverse. Son intégration plus étroite réduit le nombre de variables externes et offre aux clients une plateforme optimisée par un seul fournisseur.
Ce contrôle peut simplifier le réglage des performances. Nvidia peut coordonner le comportement des GPU, les puces de commutation, les bibliothèques de communication, les pilotes, le réseau et les frameworks applicatifs au moyen d’une feuille de route unique.
AMD parie que des standards ouverts peuvent atteindre une efficacité comparable sans qu’une seule entreprise possède chaque maillon. Cette proposition doit résister aux charges de travail réelles, et pas seulement aux schémas de topologie.
Les deux systèmes diffèrent également hors du rack. Helios attribue trois interfaces Vulcano de 800 Gbps à chaque accélérateur, atteignant 2,4 Tbps de bande passante scale-out par GPU.
Les configurations Vera Rubin publiées associent chaque GPU à une interface ConnectX-9 de 1,6 Tbps. AMD revendique donc 50 pour cent de bande passante scale-out supplémentaire par accélérateur.
Cette comparaison favorise les charges de travail réparties sur plusieurs racks, à condition que les logiciels puissent exploiter efficacement les liaisons. Les grands entraînements et les services d’inférence distribués dépendent de cette couche lorsqu’un seul rack ne peut pas contenir l’intégralité de la charge de travail.
AMD revendique également davantage de capacité et de bande passante mémoire. Helios offre 31 TB de HBM4 dans le rack, ce qui représente selon AMD 50 pour cent de capacité supplémentaire par rapport à la plateforme Nvidia concurrente.
Une capacité mémoire supérieure peut réduire le partitionnement des modèles et laisser davantage d’espace aux caches clé-valeur. Un cache clé-valeur stocke les données d’attention afin qu’un système d’inférence puisse générer des tokens ultérieurs sans recalculer le contexte précédent.
Cet avantage est particulièrement pertinent pour l’inférence à contexte long et les modèles traitant de nombreuses requêtes simultanées. Toutefois, la capacité seule ne détermine ni la latence ni le débit.
La planification logicielle, la qualité des kernels, l’efficacité des communications et la forme de la charge de travail déterminent encore quelle part de performances utiles parvient réellement aux clients. L’environnement CUDA de Nvidia reste la référence établie pour de nombreuses équipes d’IA.
ROCm s’est amélioré au fil des générations récentes d’Instinct, et les principaux frameworks prennent désormais en charge le matériel AMD. Helios impose toutefois à AMD une responsabilité accrue pour faire fonctionner 72 accélérateurs de manière prévisible comme une seule plateforme.
La concurrence entre l’ouverture et le contrôle n’est donc pas philosophique. C’est une question mesurable : une architecture fondée sur des partenaires peut-elle égaler les performances effectives et la fiabilité d’une plateforme intégrée ?
Les spécifications ne tranchent pas les performances
Les chiffres les plus impressionnants d’AMD restent des affirmations du fournisseur tant que des tests indépendants au niveau du rack ne les confirment pas.
AMD affirme que Helios fournit 15 pour cent de performances FP4 de pointe supplémentaires par accélérateur par rapport au principal système concurrent. L’entreprise projette également jusqu’à 30 pour cent de meilleurs coûts par token.
Ces affirmations exigent une mise en contexte prudente. L’arithmétique FP4 de pointe décrit l’opération basse précision prise en charge la plus rapide dans des conditions idéales, et non la vitesse soutenue d’un modèle déployé.
Une comparaison de tokens par dollar requiert encore davantage d’hypothèses. L’utilisation du matériel, l’électricité, le refroidissement, les licences logicielles, les effectifs, la précision des modèles, la taille des lots et la disponibilité du système influencent tous le résultat.
AMD n’a pas communiqué de tarification publique sous une forme permettant une comparaison neutre du coût de possession. Les acheteurs négocieront également le matériel, le support, le réseau et les accords de déploiement à des échelles différentes.
Les chiffres au niveau du rack compliquent l’analyse des performances. AMD indique 2,9 exaflops de performances FP4 de pointe pour Helios, tandis que Nvidia a publié un chiffre supérieur de 3,6 exaflops par rack pour Vera Rubin NVL72.
Les définitions derrière ces chiffres peuvent différer. Le résultat de Nvidia peut intégrer un comportement de compression adapté à certaines tâches d’inférence, tandis qu’AMD met l’accent sur les débits bruts de précision prise en charge.
La comparaison de racks de The Register a relevé cette distinction. Certaines charges de travail peuvent bénéficier de la compression adaptative de Nvidia, tandis que d’autres exigent des calculs davantage alignés sur le chiffre non compressé d’AMD.
Aucune de ces comparaisons ne désigne un vainqueur universel. L’entraînement, le fine-tuning, l’inférence dense, les modèles mixture-of-experts et le traitement à contexte long sollicitent le matériel différemment.
Un modèle mixture-of-experts n’active que certains groupes de paramètres pour chaque token. Il peut réduire les calculs, mais crée également des schémas de communication exigeants entre les GPU.
Helios peut bien fonctionner lorsque la capacité mémoire ou la bande passante scale-out limite une application. Nvidia peut conserver un avantage lorsque sa pile logicielle extrait davantage de travail à partir de ressources nominales moindres.
La même prudence s’applique au discours d’AMD sur la mémoire à un seul saut. Helios fournit un domaine HBM étroitement connecté, mais ne transforme pas 72 pools de mémoire physiques en un seul dispositif conventionnel à mémoire uniforme.
Les logiciels doivent toujours comprendre le placement des données, la propriété des accélérateurs, la synchronisation et les coûts de communication. Un accès HBM distant via un commutateur ne se comporte pas comme un accès local au sein d’un package GPU.
La latence compte aussi, en parallèle de la bande passante. AMD publie un débit agrégé impressionnant, mais des résultats applicatifs détaillés montreront comment le fabric se comporte sous contention et avec un trafic irrégulier.
La fiabilité crée un autre défi. Un rack de 72 GPU rassemble accélérateurs, processeurs, commutateurs, interfaces réseau, connexions de refroidissement, composants d’alimentation, câbles et logiciels dans un même domaine opérationnel.
Les défaillances deviennent plus coûteuses lorsque les charges de travail traitent le rack comme un seul système. Les opérateurs ont besoin d’isolation des pannes, de télémétrie, de points de contrôle, de facilité de maintenance et de procédures de récupération prévisibles.
Le rack double largeur impose également des contraintes d’infrastructure. Sa plage de puissance de 225 kW à 245 kW dépasse la capacité de nombreuses salles de données d’entreprise existantes.
Le refroidissement liquide est obligatoire à cette densité. Les acheteurs ont besoin d’une distribution de liquide de refroidissement adaptée, d’une conversion électrique, d’une capacité de charge au sol, d’un accès pour la maintenance et d’équipes d’exploitation formées.
Ces exigences ne désavantagent pas Helios par rapport à tous les concurrents. Les systèmes Nvidia à l’échelle du rack imposent des contraintes d’infrastructure similaires.
Elles limitent toutefois le marché adressable. Helios s’adresse initialement aux centres de données hyperscale, aux installations IA spécialisées, aux laboratoires nationaux et aux sites conçus pour des équipements denses refroidis par liquide.
Le logiciel demeure la plus grande variable d’incertitude. ROCm doit prendre en charge la topologie du rack tout en offrant la facilité d’utilisation et les performances que les développeurs attendent de déploiements Nvidia matures.
Les clients auront besoin de communications collectives stables, de kernels optimisés, d’intégration aux frameworks, d’observabilité, d’orchestration et d’une prise en charge rapide des nouvelles architectures de modèles.
AMD contrôle davantage cette chaîne qu’auparavant. Posséder le processeur, l’accélérateur, les interfaces réseau et le système de référence donne à ses ingénieurs davantage d’occasions d’éliminer les problèmes entre fournisseurs.
Pourtant, le contrôle ne crée pas instantanément la maturité. Les premiers déploiements en production révéleront des problèmes que les benchmarks de présentation et les conceptions de référence ne peuvent anticiper.
Helios met autant les acheteurs sous pression que Nvidia
Helios offre aux acheteurs d’infrastructure une deuxième voie à l’échelle du rack, mais rend aussi leur travail d’évaluation plus exigeant.
Une alternative crédible peut améliorer le pouvoir de négociation. Les hyperscalers n’ont plus besoin de comparer un rack Nvidia intégré à un assortiment de serveurs AMD assemblés indépendamment.
Ils peuvent comparer deux architectures de racks de 72 GPU aux ambitions physiques similaires. Toutes deux arrivent comme des plateformes coordonnées pour l’entraînement et l’inférence à l’échelle d’un centre de données.
Cela rend les comparaisons d’approvisionnement plus significatives. Les acheteurs peuvent examiner la mémoire par rack, la bande passante scale-up, la bande passante scale-out, l’alimentation, le refroidissement, la maturité logicielle, la facilité de maintenance et les résultats par charge de travail.
L’analyse approfondie d’AMD par ServeTheHome souligne également l’importance du choix dans la chaîne d’approvisionnement. Les commutateurs Broadcom et un standard de rack ouvert donnent davantage de possibilités aux fabricants pour différencier leurs implémentations.
HPE peut associer Helios à sa propre ingénierie système et à l’expertise réseau de Juniper. Supermicro peut cibler les clients qui exploitent déjà ses plateformes refroidies par liquide.
Les fournisseurs de cloud peuvent proposer de la capacité MI455X via des services managés, réduisant ainsi la nécessité pour les petits clients d’installer eux-mêmes les racks physiques.
AMD gagne en portée grâce à ce modèle, mais dépend également de ses partenaires pour une exécution cohérente. Une mauvaise intégration par un fabricant pourrait nuire à la perception de la plateforme dans son ensemble.
La conception contrôlée de Nvidia limite cette variation. Les clients disposent de moins de choix architecturaux, mais bénéficient également d’une cible plus uniforme pour l’optimisation et le support des applications.
Les acheteurs en entreprise devraient donc éviter de considérer l’ouverture comme une réduction automatique des coûts. La personnalisation ne crée de valeur que lorsque l’organisation possède la capacité d’ingénierie nécessaire pour l’exploiter.
Une entreprise exécutant des modèles standards via un service cloud managé peut accorder plus d’importance aux tokens effectivement fournis et à la disponibilité qu’au fournisseur de commutateurs sous-jacent.
Un hyperscaler développant des logiciels personnalisés de réseau et de planification peut attribuer bien plus de valeur aux interfaces publiées et aux puces disponibles sur le marché.
Les chercheurs travaillant avec des modèles dépassant la mémoire d’un serveur peuvent bénéficier du domaine HBM de 31 TB de Helios. Cette même capacité peut prendre en charge des caches d’inférence plus grands et davantage de requêtes simultanées.
Les développeurs devraient s’y intéresser car la diversité matérielle affecte la portabilité des logiciels. Une deuxième architecture viable à l’échelle du rack donne aux projets de frameworks et aux fournisseurs de modèles de meilleures raisons d’optimiser en dehors de CUDA.
Ce processus ne se produira pas automatiquement. Les équipes applicatives doivent valider les kernels, le comportement numérique, les bibliothèques de communication, les images de conteneurs, les outils de supervision et les workflows de déploiement.
L’ensemble du secteur bénéficie également d’une compétition entre standards. UALink et Ultra Ethernet disposent désormais d’un système très visible où leurs performances peuvent être mesurées sous des charges de travail IA exigeantes.
Le succès encouragerait davantage de fournisseurs de commutateurs, de concepteurs d’accélérateurs et de constructeurs de systèmes à participer. Des résultats faibles renforceraient les arguments en faveur d’une intégration propriétaire.
AMD se met également elle-même sous pression. Des sorties annuelles d’accélérateurs exigent que la conception du rack, le réseau, les logiciels et la chaîne de fabrication progressent au même rythme.
Un composant retardé peut freiner l’ensemble du système. La plateforme n’est prête que lorsque les accélérateurs, les CPU, les commutateurs, les interfaces réseau, le refroidissement, le firmware, les pilotes et les frameworks fonctionnent ensemble.
L’entreprise indique que Helios est entré en production, avec des livraisons attendues d’ici la fin du troisième trimestre 2026. Ce calendrier le place près du déploiement de Vera Rubin de Nvidia, plutôt qu’une génération entière derrière.
Le calendrier réduit le désavantage traditionnel d’AMD. Il élimine également les excuses si les logiciels ou l’approvisionnement ne répondent pas aux attentes des clients.
L’annonce de production a fait état de déploiements prévus par de grands partenaires. Le prochain test consiste à déterminer si ces engagements se transforment en capacité de production accessible.
Un rack installé à des fins d’évaluation n’est pas la même chose qu’une flotte traitant des charges de travail génératrices de revenus. Les acheteurs devraient demander des résultats reproductibles sur plusieurs semaines, et non de brèves démonstrations dans des conditions contrôlées.
Trois signaux détermineront si Helios fonctionne
Le volume des livraisons, les résultats indépendants sur les charges de travail et la fiabilité multi-rack détermineront si Helios transforme le marché.
Le premier signal est la livraison en production. AMD prévoit des livraisons de Helios d’ici la fin du troisième trimestre, les clients devraient donc surveiller quels systèmes arrivent avant la fin septembre.
Les installations nommées comptent, mais les quantités comptent davantage. Plusieurs flottes opérationnelles montreraient qu’AMD et ses partenaires peuvent obtenir de la HBM4, empaqueter les composants MI455X, assembler les racks et mettre en service des sites refroidis par liquide.
Des retards affaibliraient l’argument d’AMD sur le calendrier. La base installée et l’expérience de production de Nvidia gagnent en valeur à chaque trimestre durant lequel Helios reste rare.
Le deuxième signal concerne les benchmarks d’applications indépendants. Les évaluateurs ont besoin de résultats complets au niveau du rack pour les modèles de langage actuels, les charges de travail mixture-of-experts, les tâches de fine-tuning et l’inférence à long contexte.
Les tests utiles doivent rendre compte de la latence, du débit, de la consommation électrique, de l’utilisation, de la précision et du comportement en cas de défaillance. Le pic de calcul théorique ne suffit pas à déterminer si 72 GPU restent occupés pendant une charge de travail réelle.
Les benchmarks doivent également comparer l’effort logiciel requis. Une plateforme qui demande des semaines de travail sur des kernels personnalisés peut afficher des résultats matériels séduisants tout en augmentant le risque du projet.
Les comparaisons les plus instructives utiliseront des modèles, tailles de lots, formats numériques et objectifs de niveau de service identiques. Sans cela, les fournisseurs peuvent choisir des paramètres favorables à leur architecture.
Les résultats doivent couvrir les charges de travail intensives en mémoire comme celles intensives en calcul. Les affirmations de Helios en matière de capacité et de bande passante gagnent en crédibilité si les applications peuvent exploiter les deux sans surcoût excessif de communication.
Le troisième signal est une montée en charge fiable sur plusieurs racks. Un rack Helios teste UALink sur Ethernet, tandis que les déploiements plus importants mettent également à l’épreuve les interfaces Pensando Vulcano et le réseau Ultra Ethernet environnant.
AMD doit démontrer que les performances restent prévisibles lorsque les tâches franchissent les limites entre racks. La congestion, les opérations collectives, l’ordonnancement des tâches et les défaillances de composants deviennent plus complexes à cette échelle.
Les grands clients observeront la rapidité avec laquelle un accélérateur ou une liaison réseau défaillante peut être isolé. Ils mesureront également si une tâche peut se poursuivre, redémarrer ou récupérer à partir d’un checkpoint récent.
De solides résultats sur plusieurs racks soutiendraient la thèse d’AMD en faveur des réseaux ouverts. Ils montreraient que des commutateurs standards, des spécifications ouvertes et l’ingénierie des partenaires peuvent fournir un système d’IA coordonné.
Une faible montée en charge favoriserait l’intégration plus étroite de Nvidia. Cela suggérerait que le contrôle de l’ensemble de la fabric procure toujours un avantage opérationnel que les spécifications ne peuvent pas capturer.
Ces signaux devraient orienter la manière dont les lecteurs interprètent les futurs rapports d’AMD ServeTheHome. Les nouveaux schémas et chiffres de performance de pointe seront utiles, mais les preuves en production pèsent désormais davantage que l’intention architecturale.
Helios n’est pas simplement un autre serveur Instinct. C’est la tentative d’AMD de réunir ses actifs accumulés dans les centres de données au sein d’un produit compétitif.
Le MI455X fournit des capacités de calcul basse précision et 432 Go de HBM4. Venice assure le traitement hôte, Pensando fournit la mise à l’échelle réseau, et ROCm relie le système aux frameworks d’IA.
Le silicium Tomahawk 6 de Broadcom fournit la liaison centrale entre les 72 accélérateurs. Le matériel Open Rack Wide offre aux fabricants une base physique commune.
Cette combinaison fait de Helios le défi le plus complet lancé par AMD à la stratégie d’infrastructure IA de Nvidia. Elle soumet également AMD à une exigence plus élevée.
Les clients ne jugeront plus l’entreprise uniquement sur les spécifications de ses accélérateurs. Ils évalueront comme un tout la disponibilité des racks, les performances applicatives, la qualité logicielle, les exigences des installations, la fiabilité et le support.
La prochaine question est pratique : les opérateurs indépendants reproduiront-ils les affirmations d’AMD après l’arrivée de Helios dans les centres de données de production ? Suivez les premiers grands déploiements, comparez les résultats de charges de travail complètes et observez si l’Ethernet ouvert demeure efficace au-delà d’un rack.
