AMD SemiAnalysis : le défi CUDA d’AMD se heurte aux réalités de l’échelle rack

AMD a présenté son défi le plus convaincant à CUDA lors d’Advancing AI 2026, malgré deux problèmes opérationnels qui continuent de distinguer une concurrence crédible d’un déploiement fiable. La dernière évaluation d’AMD SemiAnalysis relève d’importants progrès logiciels, des améliorations de kernels générées par des agents et une architecture MI455X bien plus compétitive. Elle pointe également des clusters de développement internes instables et une montée en production difficile de Helios.

Cette combinaison constitue le véritable enjeu. AMD ne semble plus bloqué par une pile logicielle intrinsèquement inutilisable. L’entreprise paraît désormais limitée par son exécution, sa capacité de test et la difficulté de transformer 72 accélérateurs avancés en un système de production fiable.

Nvidia reste le principal adversaire, car CUDA est plus qu’une interface de programmation. Il comprend des bibliothèques matures, des frameworks éprouvés, des recettes de déploiement, du réseau et des années de connaissances accumulées par les développeurs. AMD doit réduire la pertinence de ces avantages tout en livrant un matériel fonctionnel à l’échelle du rack.

AMD Advancing AI 2026 a changé les termes de la compétition

AMD est passé de promesses d’améliorations sur des accélérateurs individuels à la présentation d’une alternative complète pour l’infrastructure d’IA de pointe.

Lors de son événement des 22 et 23 juillet à San Francisco, AMD a centré son argumentaire sur l’Instinct MI455X, la conception de rack Helios et ROCm.AI. L’entreprise a également mis en avant ses partenariats avec Anthropic, Microsoft, OpenAI, Cerebras et d’autres grands acheteurs d’infrastructures d’IA.

L’événement Advancing AI a positionné le MI455X comme l’accélérateur le plus performant d’AMD et ROCm.AI comme une plateforme de développement pilotée par l’IA. AMD a indiqué qu’Anthropic prévoit de déployer jusqu’à deux gigawatts de GPU de la série MI450. Microsoft prévoit également de déployer une infrastructure basée sur Helios.

Ces engagements clients sont importants, car ils font passer AMD au-delà de démonstrations de benchmarks isolées. Les laboratoires de pointe et les fournisseurs de cloud doivent exploiter des milliers d’accélérateurs sur des modèles, frameworks et configurations réseau évolutifs. Une puce performante dans un test contrôlé ne devient pas automatiquement viable à l’échelle d’une flotte.

Helios est la réponse d’AMD à cette exigence au niveau de la flotte. La conception associe 72 GPU MI455X, 18 CPU EPYC « Venice », le réseau Pensando et une interconnexion scale-up commutée. Le réseau scale-up relie les accélérateurs au sein d’un rack afin qu’ils puissent collaborer sur une même charge de travail de grande taille.

AMD affirme qu’un rack complet fournit 31 To de mémoire HBM4 et 260 To/s de bande passante scale-up agrégée. L’entreprise annonce 2,9 exaFLOPS de calcul FP4 et 1,4 exaFLOPS de calcul FP8. Il s’agit de spécifications de pointe communiquées par l’entreprise, et non de mesures indépendantes de performances applicatives soutenues.

La conception physique représente également une transition architecturale importante. Les MI300X à MI355X reposaient sur une topologie point à point à huit GPU. Helios relie 72 GPU via 12 commutateurs Broadcom Tomahawk 6 dans un réseau à un seul niveau, entièrement maillé.

Cela fait du MI455X la première réponse sérieuse d’AMD à l’échelle du rack face aux systèmes Nvidia à 72 GPU. Cela expose également AMD à une autre catégorie de problèmes d’ingénierie. L’intégrité du signal, le câblage, le refroidissement, l’intégration des commutateurs, le rendement de fabrication et la maintenabilité influencent désormais les performances autant que l’accélérateur.

L’événement a donc modifié la question centrale. Les acheteurs n’ont plus besoin de se demander si AMD peut produire une puce d’IA rapide. Ils doivent se demander si AMD peut fournir un système complet avec un comportement logiciel prévisible.

Cette distinction explique pourquoi la nouvelle analyse d’AMD SemiAnalysis est plus favorable sans devenir acritique. L’analyse attribue à AMD une probabilité bien plus élevée de gagner des parts de marché qu’auparavant. Elle identifie également deux risques susceptibles de faire dérailler ces progrès.

Un risque se situe sous les démonstrations logicielles : l’infrastructure de test interne d’AMD reste instable. L’autre se trouve dans le rack physique : Helios ferait face à une montée en production lente et complexe.

Ces risques sont directement liés. AMD a besoin de clusters matériels fiables pour tester ses logiciels en continu, tandis que les clients ont besoin de logiciels fiables avant d’adopter du nouveau matériel à grande échelle. Une faiblesse de l’un ou l’autre côté ralentit l’ensemble de la plateforme.

Pourquoi le fossé CUDA de Nvidia est enfin sous pression

Le développement agentique réduit l’avantage de main-d’œuvre derrière CUDA, mais n’efface pas l’avance de Nvidia dans les systèmes validés.

CUDA est devenu un fossé défensif parce que les développeurs pouvaient obtenir des performances opérationnelles sans devoir reconstruire chaque couche. Nvidia a investi dans des compilateurs, des bibliothèques optimisées, des outils de débogage, des logiciels de communication et des intégrations avec des frameworks largement utilisés. Chaque déploiement réussi a ajouté de la documentation, des exemples et des ingénieurs formés.

Cette accumulation a créé une boucle de rétroaction. Davantage de clients ont attiré davantage d’investissements logiciels, ce qui a rendu le matériel Nvidia plus sûr pour le client suivant. Même lorsque des puces concurrentes proposaient des spécifications attractives, la migration entraînait des coûts techniques et organisationnels.

Le nouvel argument d’AMD vise la composante travail de cette boucle. Les agents de programmation peuvent parcourir des dépôts, identifier des défaillances, proposer des correctifs, exécuter des tests et répéter des expériences de performance. Ils peuvent accomplir de nombreuses tâches ciblées en parallèle, réduisant l’importance des effectifs bruts d’ingénierie.

SemiAnalysis décrit l’utilisation de petites équipes équipées d’agents de programmation pour rendre de nouveaux modèles compatibles avec vLLM et SGLang. Les agents récupèrent des recettes de déploiement, créent l’infrastructure de test, surveillent les exécuteurs physiques, diagnostiquent les erreurs du moteur et soumettent des correctifs en amont. Selon le rapport, ce flux de travail n’était pas réalisable à la même vitesse il y a plusieurs mois.

Cela est particulièrement pertinent pour les kernels. Un kernel GPU est du code de bas niveau qui associe une opération mathématique aux unités d’exécution et à la hiérarchie mémoire d’un processeur. La qualité du kernel peut déterminer si de solides spécifications matérielles se traduisent par des performances applicatives utiles.

AMD a présenté GEAK, pour Generating Efficient AI-Centric Kernels, afin d’automatiser certaines parties de ce travail. Le système profile une charge de travail, propose des implémentations, les mesure sur du matériel réel, vérifie leur exactitude et conserve les modifications réussies.

Le framework GEAK d’AMD peut cibler les backends Triton, TileLang, FlyDSL, HIP et Composable Kernel. Sa quatrième version étend le processus des kernels individuels à des charges complètes de serving vLLM ou SGLang.

Cette distinction est importante. Accélérer une opération produit peu de valeur lorsque l’application se retrouve simplement limitée ailleurs. L’optimisation de bout en bout permet à l’agent de localiser le goulot d’étranglement suivant et de déterminer si une accélération locale améliore le débit total de serving.

Hyperloom ajoute une orchestration autour de ce processus. Il profile un service d’inférence, sélectionne les goulots d’étranglement, lance des agents d’optimisation et valide les candidats par des comparaisons de bout en bout. AMD le présente comme faisant partie du workflow ROCm.AI plus large.

SemiAnalysis a trouvé des éléments indiquant que cette approche peut générer des gains mesurés. Son rapport cite une amélioration de bout en bout d’environ 21,8 % grâce à une réécriture dense-linéaire sur MI355X. Il note également des charges de travail pour lesquelles les améliorations ont plafonné à un niveau bien plus faible.

Ces réserves sont importantes, car le code généré peut exploiter les faiblesses d’un benchmark. Un agent pourrait modifier un test, appeler une bibliothèque optimisée interdite ou mesurer accidentellement une référence inchangée. Un résultat plus rapide ne signifie rien lorsque la comparaison est invalide.

AMD a ajouté des protections contre ces comportements. GEAK peut empêcher les modifications de fichiers de test protégés, tandis que des outils d’évaluation connexes détectent les signaux de réussite codés en dur et les appels à des bibliothèques interdites. Ces contrôles transforment l’optimisation agentique en un système d’ingénierie plutôt qu’en une démonstration de génération de code.

C’est le mécanisme le plus puissant qui affaiblit le fossé CUDA. Le code ouvert donne aux agents davantage de matière à inspecter, modifier et tester. Les composants de compilateur, les kernels et les contributions aux frameworks d’AMD offrent une surface accessible à l’amélioration automatisée.

Toutefois, l’accès ouvert ne garantit pas à lui seul la qualité de production. Les agents accélèrent à la fois les changements utiles et les erreurs plausibles. La plateforme qui valide le travail généré devient plus importante à mesure que le volume de changements augmente.

Nvidia subit donc une pression sur une partie de son avantage : le débit d’ingénierie. L’entreprise reste protégée par une autre : la profondeur de sa validation et de son expérience des systèmes déployés.

Le verdict logiciel d’AMD SemiAnalysis est meilleur, mais incomplet

ROCm a réalisé des progrès mesurables, mais AMD ne dispose toujours pas de la discipline de test continu nécessaire pour inspirer une confiance par défaut.

L’amélioration la plus nette est le rapprochement d’AMD avec les frameworks en amont. Le support en amont signifie que les modifications intègrent les projets principaux de vLLM ou SGLang au lieu de rester dans des forks spécifiques à AMD. Cela réduit le travail de maintenance et offre aux utilisateurs un parcours de déploiement plus familier.

SemiAnalysis note que le support ROCm stable est entré dans les versions vLLM en amont en janvier 2026, puis dans les builds nocturnes. Des modifications de juin ont ajouté des miroirs et des portes AMD pour huit groupes de tests importants. Ceux-ci comprenaient la couverture de l’attention, du moteur, de la correction des API, du multimodal et du décodage spéculatif.

SGLang a également ajouté des tests nocturnes pour l’inférence distribuée MI355X. Les tests couvraient le serving désagrégé pour les modèles émergents, puis ont inclus des combinaisons d’attention, de parallélisme d’experts et de décodage spéculatif. Cela a fait passer certaines configurations AMD de recettes ponctuelles à une validation répétée.

L’inférence désagrégée sépare les étapes du serving de modèle sur différentes ressources. Le préremplissage traite le prompt d’entrée, tandis que le décodage génère les jetons suivants. Les opérateurs peuvent ajuster ces étapes indépendamment, mais ils doivent transférer de manière fiable les données du cache clé-valeur entre les nœuds.

Le logiciel MoRI d’AMD gère une partie de ce transport et de la communication entre experts. ATOMesh ajoute le routage, l’équilibrage de charge tenant compte du cache et l’orchestration. Ensemble, ces composants montrent qu’AMD comprend l’orientation de l’inférence en production.

Les performances se sont également améliorées. L’évaluation de SemiAnalysis cite une amélioration par 18 de l’interactivité pour une configuration Kimi K2.5 après des correctifs en amont dans AITER et vLLM. AMD rapporte séparément des hausses de débit plus modestes sur plusieurs configurations de référence.

Le point important n’est pas le plus grand chiffre sélectionné. Le changement significatif est que les optimisations apparaissent de plus en plus dans les frameworks publics, les recettes et l’intégration continue. Les clients peuvent examiner le parcours au lieu de s’appuyer sur une démonstration privée.

Pourtant, l’intégration continue, ou CI, demeure la faiblesse logicielle la plus visible d’AMD. La CI compile et teste automatiquement les modifications afin que les régressions soient détectées avant la fusion du code. Les tests bloquant la fusion offrent une protection plus forte, car un échec empêche la modification.

SemiAnalysis rapporte qu’AMD n’a pas atteint son objectif de parvenir à au moins 90 % de la couverture de validation vLLM de CUDA avant Advancing AI 2026. Le rapport attribue en partie cet échec à des clusters internes instables et à une réaffectation par la direction de capacités auparavant dédiées à l’équipe vLLM.

Le rapport indique également que les tests d’AMD pour l’inférence Kubernetes avec son interface réseau Pollara restaient très en retard sur la couverture ConnectX de Nvidia. Kubernetes est important, car de nombreux services d’inférence de production l’utilisent pour planifier et gérer des charges de travail distribuées.

Ces affirmations proviennent de l’évaluation détaillée, et non d’AMD. AMD n’a pas confirmé publiquement les réaffectations de clusters signalées ni les décisions internes de capacité qui les sous-tendent.

Pourtant, les symptômes externes étayent cette préoccupation plus large. Les tableaux de bord publics ne démontrent pas encore une parité CUDA complète. Certains parcours AMD à forte valeur ajoutée ne disposent pas de garde-fous automatiques de performance, de tests de précision ou de runners matériels.

Cette faiblesse devient plus grave à mesure que les agents génèrent davantage de code. La création plus rapide de correctifs accroît le nombre de combinaisons à tester. Les modèles, formats numériques, tailles de lot, topologies réseau et stratégies de parallélisme peuvent interagir de manière inattendue.

Une configuration peut produire un résultat fluide tout en renvoyant des réponses erronées. SemiAnalysis a identifié des défaillances de précision antérieures impliquant l’attention distribuée et les parcours parallèles par experts. Plusieurs ont été corrigées, mais au moins une baisse de précision propre à une taille de lot restait ouverte au moment de la publication.

Cet exemple illustre la différence entre disponibilité fonctionnelle et maturité de plateforme. Une optimisation peut fonctionner dans une recette donnée sans être fiable dans l’ensemble des conditions de production. L’avantage défensif de CUDA réside en partie dans ces cas limites peu glamour.

AMD a amélioré sa posture logicielle, son rythme de publication, sa documentation et sa participation aux projets amont. La prochaine étape est organisationnelle. Les clusters de test doivent devenir une infrastructure stable, et non une capacité temporaire que les équipes perdent lors des pics de demande internes.

Helios MI455X transforme un défi de puce en défi de production

Helios est techniquement crédible, mais la complexité de sa conception de rack crée un défi de fabrication qu’AMD n’a jamais affronté à cette échelle.

La conception du rack Helios s’appuie sur des normes ouvertes pour le rack, le réseau scale-up et le réseau scale-out. Elle offre aux clients davantage de choix de composants qu’un système fortement propriétaire.

Cette ouverture engendre aussi des coûts de coordination. Nvidia conçoit ses GPU, son interconnexion NVLink, ses composants NVSwitch, ses produits réseau et ses systèmes de référence comme une plateforme verticalement intégrée. AMD s’appuie davantage sur des composants standards du marché et des partenaires de fabrication externes.

Helios utilise des commutateurs Broadcom Tomahawk 6 pour son fabric scale-up. Selon SemiAnalysis, chaque GPU se connecte via 72 voies Ethernet à 200 gigabits, fournissant 1,8 To/s de bande passante scale-up unidirectionnelle. Douze puces de commutation relient les 72 accélérateurs du rack.

Cette topologie constitue une amélioration substantielle par rapport aux précédents systèmes AMD à huit GPU. Elle devrait permettre à des charges de travail plus importantes de fonctionner au sein d’un même domaine scale-up. Elle laisse également une partie de la capacité des commutateurs inutilisée, car le composant standard n’a pas été conçu spécifiquement autour de 72 GPU.

La préoccupation majeure porte sur la transmission physique des signaux. SemiAnalysis rapporte que de nombreuses liaisons scale-up nécessitent des retimers, qui restaurent des signaux électriques dégradés sur de longs parcours en cuivre. Son analyse de la chaîne d’approvisionnement estime à plus de 550 le nombre de retimers Ethernet Broadcom par rack.

Le rapport indique en outre qu’environ 85 % des liaisons concernées dans un déploiement prévu nécessitent un retiming. Cela ajoute des composants, de la consommation électrique, de la chaleur, du travail de validation et des points de défaillance potentiels. AMD n’a pas confirmé indépendamment ces estimations.

Helios utilise également un fond de panier en cuivre complexe et des câbles flyover. Les câbles flyover peuvent améliorer l’intégrité du signal en évitant des traces plus longues sur les circuits imprimés. Ils peuvent toutefois compliquer l’assemblage, la circulation de l’air, l’accès pour la maintenance et la fabrication en grand volume.

SemiAnalysis estime qu’un rack contient 10 368 paires différentielles en cuivre dans ses connexions scale-up. Même si chaque connexion individuelle est comprise, assembler et valider ce système de manière répétée représente un problème de production significatif.

C’est ce que signifie l’expression « enfer de la montée en production » employée dans le brief. Cette formule n’établit pas qu’Helios a échoué. Elle décrit la transition difficile entre un système de référence opérationnel et des systèmes reproductibles fabriqués en grand volume par plusieurs partenaires.

AMD présente Helios comme une conception de référence, et non comme un produit fini vendu directement par AMD. Des partenaires OEM et ODM construiront des systèmes de marque autour de ce plan. Ce modèle élargit la base de fournisseurs, mais répartit la responsabilité entre davantage d’organisations.

L’entreprise prévoit des déploiements en volume au cours du second semestre 2026. L’engagement de Microsoft offre à la plateforme une importante occasion de validation. Anthropic et d’autres partenaires annoncés ajoutent des signaux de demande, bien que la capacité annoncée ne soit pas synonyme de capacité installée et acceptée.

Le MI455X lui-même présente des spécifications solides. AMD annonce 432 Go de mémoire HBM4 par accélérateur, une architecture CDNA 5 et une prise en charge native de plusieurs formats de faible précision. L’architecture adopte également une taille de vague de 32 threads, rapprochant certaines parties de son modèle d’exécution de celui de Nvidia.

Cette convergence peut réduire les frictions pour les développeurs de kernels. Une hiérarchie mémoire simplifiée et une largeur d’exécution familière peuvent faciliter le transfert des connaissances d’optimisation existantes. La prise en charge native de NVFP4 aide également AMD à exécuter des checkpoints de modèles développés autour du format de Nvidia.

Aucune de ces fonctionnalités ne résout le problème du rack. Un accélérateur compétitif ne devient commercialement précieux qu’une fois que les clients peuvent recevoir, installer, refroidir, mettre en réseau et exploiter les systèmes avec des rendements acceptables.

Les conditions financières entourant les engagements majeurs ajoutent une autre dimension. SemiAnalysis caractérise un accord avec OpenAI comme offrant des remises fondées sur des actions pouvant atteindre 105 % selon des résultats spécifiés. De telles incitations peuvent stimuler l’adoption sans prouver une demande de marché ordinaire.

Les mécanismes économiques liés aux actions diffèrent d’une remise directe sur le matériel. Leur valeur dépend de déclencheurs contractuels, de la valeur future des actions, de jalons de déploiement et du traitement comptable. Les informations publiques ne fournissent pas assez de détails pour considérer le chiffre maximal mis en avant comme un avantage réalisé.

Cette structure complique également les comparaisons concurrentielles. L’économie effective d’un client peut refléter un financement stratégique plutôt que le seul coût de l’accélérateur ou son efficacité opérationnelle. Les acheteurs devraient distinguer les incitations contractuelles de la performance mesurée par dollar.

Le test pertinent est donc physique et opérationnel. Helios doit quitter les usines des partenaires, réussir les tests d’acceptation, rejoindre les clusters de production et maintenir sa disponibilité sous des charges de travail soutenues. D’ici là, ses spécifications décrivent un potentiel plutôt qu’une capacité installée.

AMD doit gagner l’inférence distribuée, pas le benchmark d’hier

Le prochain avantage défensif réside dans la capacité à combiner réseau, ordonnanceur, déplacement de mémoire et kernels sans cas particuliers fragiles.

La performance sur un seul nœud offrait autrefois un raccourci utile pour comparer les accélérateurs. Cette comparaison reflète désormais une part moindre de la charge de travail en production. L’inférence de pointe répartit de plus en plus les composants de modèles et les étapes de service sur de nombreux nœuds.

Les modèles clairsemés de type mixture-of-experts accentuent ce changement. Ces modèles contiennent de nombreux réseaux experts spécialisés, mais n’en activent qu’un sous-ensemble pour chaque token. Un service efficace exige d’acheminer les tokens, d’échanger les données, d’équilibrer les experts et de préserver assez de mémoire pour le cache.

Un parallélisme étendu par experts répartit ces experts sur davantage de GPU. Le prefill et le decode désagrégés placent différentes phases de service sur des ressources spécialisées. Le déport de cache déplace le contexte stocké entre HBM, mémoire système et stockage.

Chaque technique peut produire un résultat isolé attractif. Le véritable défi est leur composition. La quantification, les kernels d’attention, le décodage spéculatif, le routage des experts, le transfert de cache et le comportement réseau doivent fonctionner ensemble, quel que soit le modèle.

SemiAnalysis soutient que cette composabilité constitue le nouvel avantage défensif de Nvidia. CUDA reste pertinent, mais l’unité concurrentielle est passée d’un environnement de programmation à un système d’inférence distribuée.

AMD dispose de composants crédibles. MoRI prend en charge l’accès à la mémoire distante pour la communication entre experts et le déplacement de cache. AITER fournit des kernels d’inférence optimisés. ATOM et ATOMesh offrent des fonctions d’exécution et de routage. SGLang et vLLM proposent les environnements de service grand public attendus par les clients.

Le problème est une intégration inégale. Certaines configurations AMD combinent désagrégation, attention distribuée, parallélisme par experts et décodage spéculatif. D’autres exigent de désactiver la capture de graphes, d’appliquer des correctifs propres à certains modèles ou de choisir des tailles de lot précises.

Le logiciel Helios reste particulièrement précoce. SemiAnalysis a constaté une activation initiale de l’architecture dans PyTorch, mais des tests limités pour les parcours à plus forte valeur. Certaines images de framework pouvaient être compilées pour MI455X sans exécuter de contrôles complets de précision ou de performance sur des runners physiques MI455X.

Le rapport a également constaté une prise en charge précoce du transfert de cache clé-valeur sans intégration complète de WideEP. Cela signifie qu’AMD possède des éléments de la pile distribuée, mais pas encore une configuration par défaut fiable couvrant l’ensemble du rack.

Cela ne rend pas ROCm sans importance. Cela définit plus précisément le travail restant. AMD n’a plus besoin de prouver que chaque composant individuel existe. L’entreprise doit prouver que ces composants restent corrects lorsque les clients les combinent.

Nvidia fait également face à une pression sur ce front. Les frameworks ouverts réduisent l’intérêt de conserver des capacités importantes au sein de logiciels propriétaires. Les projets amont peuvent intégrer la prise en charge de plusieurs accélérateurs, interfaces réseau et systèmes de transfert de cache.

SemiAnalysis décrit son aide pour connecter les contributions d’AMD à NIXL, une bibliothèque associée au travail de Nvidia sur l’inférence distribuée. La prise en charge d’AMD a ensuite intégré le projet amont, montrant que certaines parties de la frontière logicielle peuvent devenir une infrastructure partagée.

Cette évolution affaiblit un récit simpliste de verrouillage fournisseur. Les clients bénéficient de couches de transport et d’orchestration qui acceptent plusieurs backends matériels. AMD en bénéficie car l’entreprise peut consacrer moins d’heures d’ingénierie à maintenir des forks parallèles.

Nvidia contrôle toujours le rythme de sa propre plateforme intégrée. Ses équipes matérielles et logicielles peuvent se coordonner autour d’une architecture de rack définie. AMD doit faire en sorte que l’ouverture produise une amélioration collective plus rapide que l’intégration de Nvidia ne produit en interne.

La génération agentique de kernels aide à l’optimisation locale. Elle peut aussi aider à diagnostiquer les défaillances des frameworks et à produire des correctifs amont. Elle ne peut pas décider des priorités organisationnelles, garantir une capacité de test stable ou fabriquer un rack complexe.

L’équilibre concurrentiel repose donc sur deux formes d’exécution différentes. AMD doit automatiser l’amélioration logicielle tout en industrialisant la production matérielle. Nvidia doit défendre son avance intégrée sans laisser ses processus et sa taille organisationnelle ralentir sa réaction.

Trois signaux montreront si AMD peut éroder l’avantage défensif de CUDA

Les annonces d’AMD ne deviennent stratégiquement importantes que lorsque les tests, les livraisons et les charges de travail distribuées progressent ensemble.

Le premier signal est la couverture CI publique. AMD a besoin de runners MI455X stables et de tests bloquant les fusions dans vLLM, SGLang, PyTorch, le réseau et l’inférence distribuée. Une parité de validation visible répondrait directement à la préoccupation concernant des clusters internes instables.

Un résultat plus solide inclurait des contrôles de précision et de performance couvrant plusieurs modèles, tailles de lot, formats numériques et topologies réseau. Exécuter avec succès des scripts de démonstration ne suffit pas. Les régressions doivent bloquer les changements avant qu’ils n’atteignent les utilisateurs.

Si AMD met en place cette couverture, la thèse du logiciel agentique devient bien plus solide. Les agents peuvent générer et optimiser du code rapidement parce que le système de validation peut rejeter le travail incorrect. Une instabilité persistante transformerait une vitesse de développement accrue en risque qualité plus important.

Le deuxième signal est la montée en production de Helios au cours du second semestre 2026. Les lecteurs devraient surveiller les livraisons des partenaires, l’acceptation par les clients, les clusters installés et l’exploitation soutenue, plutôt que de nouvelles annonces de capacité.

Le déploiement de Microsoft sera particulièrement utile, car il associe des accélérateurs AMD, des processeurs EPYC, du réseau et ROCm au sein d’un environnement cloud majeur. Une disponibilité en production validerait bien plus que les performances du MI455X. Elle mettrait à l’épreuve l’ensemble de la chaîne d’approvisionnement et de l’écosystème logiciel.

Des retards, des volumes limités ou d’importantes refontes confirmeraient les inquiétudes liées aux retimers, au câblage et à la coordination des partenaires. Des livraisons prévisibles montreraient qu’AMD a transformé une conception de référence ambitieuse en infrastructure reproductible.

Le troisième signal concerne l’inférence distribuée composable sur MI455X. AMD doit démontrer que WideEP, la séparation prefill-decode, le transfert de cache, la quantification et le décodage spéculatif fonctionnent ensemble dans les frameworks amont.

Les meilleures preuves viendront de configurations reproductibles, avec des contrôles de précision et des résultats obtenus sur un trafic réaliste. Une charge de travail agentique comprend de longs contextes, des appels d’outils répétés, la réutilisation du cache et un rythme de requêtes irrégulier. De simples prompts synthétiques ne reflètent pas ces exigences.

Si ces configurations offrent des performances fiables, AMD participera à la bataille des systèmes actuels plutôt qu’à une compétition passée centrée sur un seul nœud. Si elles restent spécifiques à certains modèles, l’avantage de CUDA perdurera, même lorsque des kernels ROCm individuels paraissent compétitifs.

Les développeurs devraient s’y intéresser, car une seconde plateforme crédible peut améliorer la portabilité et réduire la dépendance à la feuille de route d’un seul fournisseur. Elle peut aussi élargir l’accès à des accélérateurs riches en mémoire alors que la capacité de Nvidia reste contrainte.

Les acheteurs en entreprise devraient s’y intéresser pour une autre raison. Les remises annoncées, les spécifications de pointe et les engagements des partenaires ne déterminent pas le risque opérationnel. Les acheteurs ont besoin de preuves sur les taux de régression logicielle, l’effort de déploiement, la disponibilité et la portabilité des charges de travail.

Les travailleurs du savoir en ressentiront les effets indirectement. Une infrastructure d’inférence plus compétitive peut influencer la disponibilité des modèles, la latence et l’économie des agents de longue durée. Ces bénéfices dépendent de la fiabilité en production, et non des comparaisons lors de keynotes.

Le verdict de SemiAnalysis sur AMD est donc prudemment important. AMD a trouvé un mécanisme crédible pour réduire une partie de l’écart avec CUDA. Les logiciels ouverts et les agents de programmation peuvent condenser des années d’optimisation manuelle en cycles d’ingénierie parallèles plus rapides.

Les obstacles restants sont moins spectaculaires, mais plus décisifs. AMD a besoin de clusters de test stables, d’une composition distribuée fiable et d’un rack Helios industrialisable. Le fossé défensif de Nvidia perdure partout où ces détails opérationnels restent difficiles à maîtriser.

Surveillez d’abord les jalons de test publics, ensuite les installations Helios réelles, puis les charges de travail distribuées complètes. Si les trois progressent de concert, AMD aura construit plus qu’un accélérateur compétitif. L’entreprise aura bâti une plateforme alternative crédible.