Le pari d'AMD et Google sur les standards face à Nvidia dans le test de réseau IA de Vulcano

AMD a présenté sa carte réseau IA Pensando Vulcano à 800 Gbps, malgré l'avance de Nvidia dans les réseaux étroitement intégrés pour les grands clusters de GPU. Le lien entre amd et google est important, car les deux entreprises soutiennent des standards d'interconnexion ouverts visant à offrir davantage de choix matériels aux acheteurs d'infrastructures. Google n'a toutefois pas annoncé de plans de déploiement de Vulcano.

Vulcano s'attaque à un problème coûteux au sein des centres de données IA. Les accélérateurs peuvent rester inactifs lorsque la congestion réseau, la perte de paquets ou une récupération lente retardent les communications entre serveurs. AMD affirme que trois cartes Vulcano peuvent fournir 2,4 térabits par seconde de bande passante scale-out pour chaque GPU.

Ce chiffre offre à AMD un argument clair, mais pas une victoire automatique. Nvidia commercialise déjà une combinaison éprouvée de GPU, Ethernet Spectrum-X, InfiniBand, NVLink, commutateurs et logiciels de réseau. Vulcano doit démontrer qu'une approche Ethernet ouverte et programmable peut offrir une cohérence opérationnelle comparable sans exiger la pile complète d'un seul fournisseur.

Ce qui change avec AMD Pensando Vulcano 800

Vulcano fait du réseau un élément central de la plateforme IA d'AMD à l'échelle du rack, plutôt qu'un accessoire ajouté après le choix des GPU.

AMD a présenté publiquement la carte réseau IA Pensando Vulcano 800 le 23 juillet 2026. L'adaptateur est conçu pour les réseaux scale-out, qui relient les accélérateurs entre serveurs et racks lorsque leurs liaisons locales scale-up atteignent leurs limites pratiques.

Chaque carte fournit une connexion réseau de 800 Gbps. AMD prend en charge des configurations pouvant attribuer jusqu'à trois cartes réseau à un GPU, créant ainsi la bande passante agrégée annoncée de 2,4 Tbps.

Cette organisation diffère d'une approche où un adaptateur réseau est utilisé comme point d'accès partagé par plusieurs accélérateurs. Plusieurs liaisons indépendantes peuvent accroître la bande passante disponible tout en offrant au trafic plusieurs itinéraires au sein du cluster.

AMD appelle cela une architecture multi-plan. Un plan réseau est un chemin de données indépendant, avec ses propres liaisons et ressources de commutation. Répartir le trafic entre plusieurs plans peut limiter l'impact d'une liaison défaillante ou d'un itinéraire congestionné.

L'entreprise affirme également que Vulcano peut réduire les coûts de commutation jusqu'à 33 %. AMD attribue cette estimation à un nombre réduit de câbles et de transceivers dans sa configuration de référence, et non à une réduction universelle pour tous les déploiements.

Son affirmation en matière de performances mérite la même réserve. AMD indique que Vulcano peut améliorer le temps d'exécution des tâches IA jusqu'à 13 %. Ce résultat provient d'un benchmark de l'entreprise lié à des charges de travail et à des hypothèses système spécifiques.

Aucun de ces pourcentages ne doit être considéré comme une performance vérifiée de manière indépendante pour chaque cluster. Les acheteurs ont besoin de tests au niveau des charges de travail, incluant les commutateurs, l'optique, la topologie, les versions logicielles, le comportement en cas de panne et l'utilisation des accélérateurs.

Le mécanisme sous-jacent reste néanmoins crédible. L'entraînement distribué échange à répétition des paramètres de modèle et des résultats intermédiaires entre accélérateurs. Un seul chemin retardé peut bloquer une opération collective et laisser des GPU coûteux attendre leurs homologues.

L'inférence distribuée génère un autre modèle de trafic. Elle peut déplacer des requêtes, des états de modèle et des données mises en cache entre systèmes lorsque la demande des utilisateurs évolue. Une latence prévisible peut compter autant que le débit de pointe.

Vulcano répond à ces schémas au moyen d'une logique de transport programmable, de contrôles de congestion, d'une isolation des pannes et de diagnostics en service. AMD indique que les opérateurs peuvent mettre à jour certaines parties de ce comportement par logiciel plutôt que de remplacer le silicium réseau.

La carte réseau utilise des moteurs P4 programmables de troisième génération. P4 est un langage et une architecture servant à définir la manière dont les équipements réseau traitent les paquets. Il permet aux fournisseurs de modifier certains comportements de transfert et de transport dans les limites prises en charge par le matériel.

La conception de Vulcano d'AMD inclut également des options de connectivité PCIe et UALink. Cette flexibilité permet à l'adaptateur de se connecter à des CPU ou à des accélérateurs selon différentes conceptions de racks.

Le produit représente donc davantage qu'un port Ethernet plus rapide. AMD tente de coordonner les GPU, les CPU, le silicium réseau, les transports ouverts et les logiciels de gestion en un seul système à l'échelle du rack.

Pourquoi le lien entre AMD, Google et les standards est important

La relation entre amd et google relève d'une alliance autour des standards, et non d'une preuve que Google Cloud a choisi Vulcano pour la production.

AMD et Google figuraient parmi les entreprises à l'origine du groupe de promotion Ultra Accelerator Link en 2024. Broadcom, Cisco, Hewlett Packard Enterprise, Intel, Meta et Microsoft y ont également participé.

UALink cible les communications scale-up entre accélérateurs au sein d'un pod de calcul. Le réseau scale-up crée un domaine d'accélérateurs étroitement connecté, tandis que le réseau scale-out relie plusieurs serveurs ou domaines au sein d'une infrastructure plus vaste.

Ces rôles se recoupent à la frontière du système, mais ils ne sont pas interchangeables. Vulcano gère principalement le trafic scale-out et scale-across. Son interface UALink l'aide à se connecter directement aux accélérateurs dans les architectures de racks ouverts émergentes.

Le mot-clé amd google peut donc donner une impression trompeuse. Aucune annonce vérifiée n'indique que Google a co-conçu Vulcano, acheté la carte réseau ou engagé de la capacité Google Cloud pour celle-ci.

L'importance de Google découle de sa position d'opérateur hyperscale et de participant aux standards. Son implication rend les travaux sur les interconnexions ouvertes plus pertinents, car Google connaît les exigences de trafic, de fiabilité et de gestion de flotte des grands systèmes IA.

Le consortium UALink a publié sa première spécification pour connecter jusqu'à 1 024 accélérateurs au sein d'un même pod. Le soutien de plusieurs opérateurs cloud et fournisseurs de puces peut réduire le risque que le standard dépende d'un seul fournisseur.

Vulcano prend également en charge Ultra Ethernet pour les communications entre systèmes. La spécification UEC définit une pile de communication basée sur Ethernet pour l'IA et le calcul haute performance.

Ultra Ethernet modifie davantage que la vitesse brute des liaisons. Il traite de la livraison des paquets, de la gestion de congestion, du multipathing, de la sécurité et des sémantiques de communication requises par les charges de travail étroitement synchronisées.

AMD fait aussi progresser Multipath Reliable Connection, ou MRC. Ce transport peut répartir les données entre plusieurs chemins tout en maintenant une livraison fiable et en réagissant à la congestion ou aux pannes.

AMD indique avoir co-développé MRC avec OpenAI pour de vastes environnements d'entraînement. L'entreprise a implémenté ce transport sur sa précédente carte réseau Pollara 400 et affirme que Vulcano le prendra en charge lorsque la nouvelle plateforme sera généralement disponible.

Selon l'implémentation MRC d'AMD, Pollara a été validé dans les laboratoires de l'entreprise avec des clusters Instinct MI350 et MI355. AMD indique qu'OpenAI a participé à cette validation.

MRC peut fonctionner avec le routage de segments sur IPv6, ce qui donne aux opérateurs un contrôle explicite sur les chemins des paquets. Il peut également fonctionner avec le routage à chemins multiples à coût égal et l'équilibrage de charge dynamique.

Cette adaptabilité soutient l'argument plus large d'AMD. Les opérateurs devraient pouvoir adopter de nouveaux comportements de transport sans remplacer chaque commutateur, câble et processus de gestion autour du cluster d'accélérateurs.

La participation de Google aux standards renforce cet argument, mais elle ne valide pas les affirmations d'AMD concernant son produit. Les spécifications définissent un comportement commun, tandis que les déploiements en production révèlent la qualité de l'implémentation.

Un standard écrit ne peut garantir des durées de tâche stables en cas de congestion. Il ne prouve pas que les outils de diagnostic identifient rapidement les pannes ni que différents fournisseurs interprètent chaque fonctionnalité facultative de façon identique.

Pour les acheteurs, l'histoire amd google concerne donc l'alignement stratégique. Les deux entreprises ont soutenu des alternatives aux infrastructures d'accélérateurs fermées, mais Vulcano doit gagner son adoption grâce à des performances mesurables en cluster.

Cette distinction importe aux équipes d'approvisionnement. Elles devraient évaluer Vulcano comme un produit AMD dans un environnement multi-fournisseurs émergent, et non comme une carte réseau approuvée par Google.

Le mécanisme de Vulcano associe bande passante et programmabilité

L'argument technique le plus solide de Vulcano ne repose pas seulement sur ses 800 Gbps, mais sur sa combinaison de chemins multiples, de transport programmable et de récupération rapide après panne.

Les réseaux IA impliquent des communications synchronisées entre de nombreux points d'extrémité. Durant l'entraînement, les opérations collectives combinent ou redistribuent les données produites par chaque accélérateur participant.

Si un flux rencontre de la congestion, une étape entière d'entraînement peut ralentir. Les GPU restants peuvent terminer leur travail local, mais ne peuvent progresser tant que la communication collective n'est pas achevée.

L'Ethernet conventionnel répartit souvent les flux entre les chemins en hachant leurs informations d'identification. Un flux important peut rester bloqué sur un itinéraire congestionné même lorsqu'un autre chemin dispose de capacité inutilisée.

MRC est conçu pour utiliser plusieurs chemins de manière plus délibérée. Il peut séparer le trafic en portions, réagir aux conditions des chemins et assurer la récupération sans obliger une application à redémarrer l'intégralité de la communication.

Les moteurs de traitement de paquets programmables de Vulcano placent une partie de ce contrôle près de la périphérie du réseau. Cet emplacement est important, car la carte réseau observe le trafic entrant et sortant de chaque serveur.

La carte peut également isoler les pannes et effectuer des diagnostics tout en maintenant un cluster actif. AMD affirme que ces fonctions réduisent le temps de réparation et évitent certaines fenêtres de maintenance à l'échelle du cluster.

Ces capacités prennent de la valeur à mesure que la taille des clusters augmente. Un système comptant des milliers de composants connaît régulièrement des défaillances de liaisons, d'optiques, de firmware et de commutateurs, même lorsque chaque composant présente une forte fiabilité individuelle.

Le réseau doit se dégrader de manière prévisible plutôt que de transformer une panne en tâche bloquée. Les multiples plans offrent des chemins alternatifs, tandis que la logique de transport détermine comment le trafic doit circuler entre eux.

Trois cartes réseau de 800 Gbps par GPU créent une capacité physique substantielle. Toutefois, la bande passante agrégée ne signifie pas que chaque charge de travail transférera continuellement 2,4 Tbps de données utiles.

Le GPU, l'interface hôte, la bibliothèque collective, la topologie et les points d'extrémité distants doivent tous alimenter le trafic efficacement. La surcharge protocolaire et la synchronisation des charges de travail réduisent également le débit au niveau applicatif.

L'architecture d'AMD prend en charge les connexions hôtes PCIe et UALink. PCIe reste une interface familière pour les CPU et les périphériques. UALink cible une connectivité directe aux accélérateurs avec une moindre dépendance envers un seul fournisseur de GPU.

Vulcano est également lié à AMD Helios, la conception à l'échelle du rack de l'entreprise utilisant des accélérateurs Instinct de série MI400 et des processeurs EPYC Venice. AMD a positionné la carte réseau comme composant de réseau scale-out par défaut de Helios.

Cette intégration donne à AMD davantage de contrôle sur la validation. L'entreprise peut tester le firmware, les bibliothèques de communication ROCm, le comportement des accélérateurs et la télémétrie réseau en tant que plateforme coordonnée.

La programmabilité comporte toutefois des coûts opérationnels. Un pipeline de paquets modifiable exige des processus rigoureux de contrôle des versions, de test, d'observabilité et de retour en arrière.

Les équipes réseau doivent savoir quels paramètres de firmware et de transport étaient actifs lors d'une tâche défaillante. Elles ont également besoin d'outils qui corrèlent les événements de congestion avec les performances applicatives.

L'étiquette P4 ne supprime pas ces exigences. Elle donne simplement à AMD et aux opérateurs approuvés davantage de latitude pour modifier le comportement des fonctions de traitement de paquets prises en charge.

Les standards ouverts créent un autre défi d’implémentation. Deux produits peuvent prétendre prendre en charge la même spécification tout en différant par leurs fonctionnalités optionnelles, leurs limites de performance ou leurs interfaces de gestion.

Les tests d’interopérabilité seront donc décisifs. Les acheteurs ont besoin de preuves que Vulcano fonctionne de manière fiable avec des commutateurs, des optiques, des logiciels de routage et des systèmes de supervision tiers.

La page AMD AI NIC met l’accent sur les hyperscalers et les fournisseurs de cloud. Ces clients disposent des équipes d’ingénierie nécessaires pour tester des comportements réseau complexes à grande échelle.

L’adoption en entreprise pourrait progresser plus lentement. De nombreuses entreprises achètent des systèmes complets parce qu’elles ne disposent pas des effectifs nécessaires pour intégrer indépendamment accélérateurs, NIC, commutateurs, micrologiciels et paramètres de transport.

Vulcano peut néanmoins aider ces organisations via des systèmes Helios validés ou des services cloud. Le degré d’ouverture dépendra du nombre de fournisseurs qui proposeront des configurations prises en charge.

C’est l’épreuve pratique du produit. La programmabilité doit réduire le coût d’adaptation d’un réseau sans transférer au client une charge d’intégration excessive.

La pile intégrée de Nvidia reste le principal concurrent

AMD conteste le contrôle de Nvidia sur l’architecture des systèmes d’IA, et ne se contente pas de rivaliser avec un autre adaptateur Ethernet 800 Gbps.

Nvidia peut relier ses accélérateurs via NVLink au sein d’un domaine scale-up. L’entreprise propose ensuite Quantum InfiniBand ou Spectrum-X Ethernet pour les communications entre serveurs et racks.

Spectrum-X combine les commutateurs Nvidia, les SuperNIC, le contrôle de congestion, la télémétrie et les logiciels. Nvidia teste ces composants comme un système de bout en bout étroitement lié à sa plateforme GPU.

Cette intégration peut simplifier l’attribution des responsabilités. Lorsqu’une tâche d’IA affiche de mauvaises performances, un client peut demander à un seul fournisseur d’examiner l’accélérateur, l’adaptateur réseau, le commutateur, le micrologiciel et les bibliothèques de communication.

Nvidia affirme que Spectrum-X Ethernet peut améliorer les performances réseau d’un facteur 1,6 par rapport à l’Ethernet conventionnel. Comme les chiffres d’AMD, il s’agit d’une affirmation du fournisseur fondée sur des configurations spécifiées.

Spectrum-X prend également en charge des systèmes d’exploitation réseau ouverts, dont SONiC. La concurrence n’est donc pas un simple affrontement entre Ethernet ouvert et une alternative entièrement fermée.

La différence réelle concerne le contrôle et le choix des composants. Nvidia optimise une combinaison définie de ses puces et logiciels, tandis qu’AMD met l’accent sur des appareils programmables et des spécifications industrielles multi-fournisseurs.

Une intégration étroite peut produire un comportement cohérent, mais elle peut accroître la dépendance au calendrier de publication d’un seul fournisseur. Une conception multi-fournisseurs peut offrir davantage de choix, mais le travail de qualification devient plus difficile.

Vulcano doit prouver que son approche ouverte ne sacrifie pas la prévisibilité des performances. Le débit maximal seul ne tranchera pas cette question.

Les exploitants de clusters d’IA examinent le temps d’exécution des tâches, la latence de queue, la reprise après incident, l’utilisation effective des GPU et l’isolation des performances entre locataires. Ils suivent également la consommation électrique et le nombre d’optiques requises.

L’affirmation d’AMD sur une amélioration de 13 % du temps d’exécution est pertinente, car elle mesure un résultat applicatif. Toutefois, les documents publics n’établissent pas un avantage universel sur Spectrum-X ou InfiniBand.

L’affirmation d’une réduction de 33 % des coûts de commutation exige également une interprétation prudente. Moins de câbles et de transceivers peuvent réduire les dépenses d’équipement, le travail d’installation et les points de défaillance.

Cependant, une configuration de trois NIC par GPU peut ajouter des adaptateurs, des interfaces hôtes et de la complexité de gestion ailleurs. Le résultat total dépend de la topologie et de la base de comparaison.

Nvidia possède un autre avantage grâce aux systèmes déjà déployés. Ses produits réseau fonctionnent déjà dans de grands clusters d’IA, fournissant aux clients des références d’implémentation et des pratiques de support établies.

AMD n’arrive pas sans expérience. Pensando a précédemment livré des DPU et des Pollara AI NIC, tandis qu’AMD a travaillé avec des fournisseurs de cloud et des fabricants de systèmes sur les réseaux de centres de données.

Vulcano arrive néanmoins avec plusieurs autres éléments en mouvement. Helios introduit de nouveaux accélérateurs Instinct, des processeurs EPYC, des connexions UALink et une pile logicielle ouverte en évolution.

Un problème à n’importe quel niveau peut retarder la qualification. Les clients peuvent choisir une configuration mature même lorsqu’une autre conception promet une meilleure flexibilité des composants.

Le risque est le plus élevé pour les organisations qui cherchent à obtenir rapidement de la capacité d’entraînement. Leur priorité est souvent de mettre un cluster en ligne rapidement, et non de maximiser le choix futur de fournisseurs.

Les acheteurs à plus long terme peuvent davantage valoriser l’approche ouverte. L’infrastructure traverse plusieurs générations d’accélérateurs, tandis que les modèles et les schémas de communication évoluent bien plus vite.

La programmabilité P4 de Vulcano pourrait aider AMD à répondre à ces changements. De nouveaux contrôles de congestion ou comportements de transport pourraient être apportés par logiciel, dans les limites des capacités matérielles.

Nvidia peut aussi mettre à jour sa pile. L’entreprise bénéficie également du contrôle d’un plus grand nombre de composants, ce qui peut accélérer les changements coordonnés dans l’ensemble du système.

La principale compétition est donc opérationnelle. AMD doit montrer que le choix fondé sur les standards peut égaler la fiabilité, les outils et la validation de la plateforme intégrée de Nvidia.

La présence de Google dans les groupes d’interconnexion ouverts renforce la confiance dans le sérieux du soutien industriel à l’alternative. Elle n’efface pas la base installée ni l’avantage d’exécution de Nvidia.

Ce qu’AMD doit encore prouver

La plus grande incertitude est de savoir si les gains publiés de Vulcano résistent à des tests indépendants sur des clusters multi-fournisseurs réalistes.

Les chiffres publics d’AMD décrivent des capacités maximales et des comparaisons sélectionnées. Ils ne fournissent pas encore un large ensemble de résultats tiers couvrant l’entraînement, l’inférence distribuée et les charges de travail mixtes.

Le chiffre de 2,4 Tbps correspond à la bande passante scale-out agrégée de trois NIC 800 Gbps. Il ne garantit pas qu’une application GPU recevra continuellement ce débit.

Les évaluations indépendantes devraient mesurer le débit utile en situation de congestion. Elles devraient aussi présenter les distributions de latence, le comportement de récupération des paquets et le temps d’inactivité des accélérateurs.

Les tests de défaillance comptent tout autant que la vitesse en régime établi. Les évaluateurs devraient désactiver des liens, introduire des pertes de paquets, redémarrer des commutateurs et faire varier la latence des chemins alors qu’une tâche distribuée reste active.

MRC doit ensuite fournir des preuves d’interopérabilité. AMD indique que le transport prend en charge plusieurs approches d’acheminement, mais les clients voudront des combinaisons vérifiées de NIC, commutateurs, micrologiciels et logiciels de routage.

La disponibilité générale est un autre détail sans réponse. AMD a indiqué que Vulcano est en cours de qualification pour les clusters Instinct de la série MI400, tandis que la disponibilité d’Helios est attendue au cours de 2026.

La qualification n’est pas la même chose qu’un déploiement à grande échelle. Un produit peut atteindre ses objectifs de conception alors que les fabricants de systèmes, les fournisseurs de cloud et les entreprises exigent encore des mois de validation.

La question de Google reste particulièrement importante, car le mot-clé principal suggère une relation directe. Google a soutenu UALink, mais aucune preuve publique ne confirme que Google Cloud proposera des instances basées sur Vulcano.

Un déploiement chez Google fournirait un signal d’adoption significatif. Il montrerait qu’un hyperscaler disposant d’une expertise interne en réseau a jugé Vulcano adapté à un usage en production.

L’absence d’une telle annonce ne constitue pas une preuve contre le produit. Les hyperscalers évaluent souvent plusieurs architectures et ne divulguent que certains déploiements.

La maturité logicielle exige également un examen attentif. ROCm doit coordonner les communications collectives avec le réseau tout en exposant une télémétrie utile aux ordonnanceurs et aux équipes d’exploitation.

Une NIC rapide ne peut compenser des bibliothèques collectives inefficaces ou un mauvais placement des charges de travail. La prise en compte du réseau doit atteindre la couche d’orchestration si les opérateurs veulent des temps d’exécution cohérents.

La sécurité mérite également de l’attention. Les appareils programmables élargissent les possibilités de configuration, et chaque chemin de micrologiciel exige des contrôles autour de la signature, des mises à jour, des accès et du retour en arrière.

Les spécifications ouvertes ne créent pas automatiquement une gestion ouverte. Les clients devraient examiner quelles fonctions requièrent les outils d’AMD et si les produits d’observabilité tiers peuvent accéder à la télémétrie essentielle.

L’affirmation de coût exige une comptabilité complète du système. Une comparaison équitable devrait inclure les adaptateurs, les commutateurs, les câbles, les optiques, l’espace en rack, l’énergie, le support et la main-d’œuvre d’ingénierie.

Les équipes qui évaluent Vulcano devraient conserver les enregistrements de benchmark dans une base de connaissances d’ingénierie consultable. Les versions de micrologiciel et les détails de topologie peuvent déterminer si les comparaisons ultérieures restent utiles.

Les équipes achats devraient également distinguer les exigences scale-up des exigences scale-out. UALink, Ultra Ethernet, MRC et PCIe traitent de différentes parties du chemin de données.

Confondre ces couches peut produire des spécifications impressionnantes sans déploiement cohérent. Les acheteurs ont besoin d’une architecture montrant comment le trafic circule d’un accélérateur vers chaque point de terminaison pertinent.

L’orientation technique d’AMD est plausible. Son défi consiste à transformer cette orientation en systèmes reproductibles que les clients peuvent commander, déployer, superviser et réparer.

Trois signaux détermineront la position de Vulcano dans les réseaux d’IA

La position de Vulcano deviendra plus claire grâce à des résultats indépendants sur des clusters, à des clients de production nommés et à une interopérabilité multi-fournisseurs vérifiée.

Le premier signal est un test indépendant sur des systèmes Helios complets. Les résultats devraient comparer les temps d’exécution des tâches, l’utilisation des GPU, la latence de queue et la reprise dans plusieurs conditions réseau.

Un test utile identifiera chaque composant et chaque version logicielle. Il devra distinguer la bande passante mesurée sur le lien du débit fourni à l’application d’IA.

De solides résultats sur plusieurs charges de travail soutiendraient l’affirmation d’AMD selon laquelle Vulcano élimine les goulets d’étranglement de communication. Des résultats faibles ou incohérents réduiraient la valeur de sa bande passante mise en avant.

Le deuxième signal est un déploiement hyperscale ou cloud nommé. Oracle a évoqué une infrastructure AMD à l’échelle du rack, tandis qu’OpenAI a travaillé avec AMD sur la validation de MRC.

Google serait particulièrement significatif en raison de l’intérêt de recherche amd google et de son rôle dans les efforts d’interconnexion ouverte. Toutefois, les lecteurs devraient attendre une annonce directe de déploiement.

Un client doit décrire davantage qu’une simple évaluation. La disponibilité en production, la taille du cluster, les charges de travail prises en charge et les attentes en matière de niveau de service apporteraient des preuves plus solides.

Le troisième signal est l’interopérabilité au-delà d’une conception de référence entièrement AMD. Vulcano devrait fonctionner avec plusieurs fournisseurs de commutateurs, systèmes d’exploitation réseau, optiques et plateformes de gestion.

Une interopérabilité réussie renforcerait l’argument économique en faveur des réseaux d’IA ouverts. Elle permettrait aux clients de changer certains composants sans reconcevoir l’ensemble du cluster.

Une compatibilité limitée affaiblirait cet argument, même si Helios fonctionne bien comme configuration de référence fermée. Le système pourrait devenir intégré en pratique malgré son recours à des spécifications ouvertes.

Nvidia ne restera pas immobile pendant qu’AMD achève cette validation. Spectrum-X combine déjà un Ethernet fondé sur les standards avec le contrôle de Nvidia sur la plateforme environnante.

Les comparaisons futures doivent donc utiliser les produits actuels des deux entreprises. Une victoire face à un Ethernet plus ancien ne prouve pas un avantage sur la dernière fabric de Nvidia.

Pour les développeurs, l’effet immédiat restera indirect. La plupart rencontreront Vulcano via des instances cloud, des clusters gérés ou des systèmes sélectionnés par les équipes d’infrastructure.

Le réseau influence néanmoins le temps d’entraînement, la latence d’inférence, la disponibilité des capacités et le coût du service. Les améliorations au niveau de la fabric peuvent modifier les charges de travail d’IA qui restent économiquement viables.

Les acheteurs en entreprise devraient demander aux fournisseurs des preuves au niveau des charges de travail plutôt que des résumés de vitesse de port. Ils devraient également demander des tests de défaillance et une frontière de support claire entre les fournisseurs.

La question essentielle n’est plus de savoir si Ethernet peut transporter le trafic d’IA. Elle est de savoir si un système Ethernet ouvert peut fournir des résultats constants à une échelle où un seul chemin retardé gaspille des milliers d’accélérateurs.

AMD a désormais présenté une réponse concrète à travers Vulcano, MRC, Ultra Ethernet et Helios. Google et d’autres partenaires de normalisation rendent la voie ouverte plus crédible, mais ils ne garantissent pas l’exécution d’AMD.

Surveillez les premiers benchmarks indépendants de Helios, le premier déploiement cloud de Vulcano annoncé nommément et les premiers rapports d’interopérabilité à grande échelle. Ces trois signaux détermineront si le pari d’AMD sur les normes devient une alternative prête pour la production ou reste une spécification attrayante.