Les liens entre AMD et Google mettent le partenariat IA de Meta à l’épreuve face à Nvidia

AMD a transformé une vitrine de partenaires de 2024 en campagne d’infrastructure pour 2026, malgré l’emprise durable de Nvidia sur les logiciels utilisés pour construire des modèles d’IA. La relation entre AMD et Google apporte une crédibilité cloud, tandis que Meta engage des charges de travail, des contributions d’ingénierie et jusqu’à six gigawatts de capacité GPU prévue.

Cette combinaison compte davantage qu’une nouvelle victoire dans les benchmarks. AMD demande aux grands créateurs de modèles et fournisseurs cloud d’aider à optimiser l’ensemble de la pile informatique, du silicium et du réseau jusqu’aux frameworks et au code des modèles. Cette stratégie défie Nvidia là où son avantage a historiquement été le plus fort : une plateforme intégrée que les développeurs connaissent déjà.

L’annonce initiale réunissait Meta, Google Cloud, Microsoft, Oracle et plusieurs développeurs d’IA autour du matériel d’AMD et de son logiciel ROCm. Ces partenariats n’ont pas immédiatement effacé les coûts de migration ni établi une large parité de performances. Toutefois, les engagements ultérieurs de Meta et d’autres créateurs de modèles montrent que l’initiative a dépassé le stade d’un lancement de produit d’une journée.

Ce qu’AMD et ses partenaires ont réellement changé

La décision importante d’AMD a été d’ouvrir sa feuille de route produit à des clients dont les charges de travail peuvent façonner le matériel et les logiciels.

Lors de son événement Advancing AI d’octobre 2024, AMD a présenté l’accélérateur Instinct MI325X, les processeurs serveur EPYC de cinquième génération, de nouveaux composants réseau et les puces Ryzen AI pour entreprises. L’entreprise a également décrit la poursuite de ses travaux sur ROCm, sa plateforme logicielle open source destinée à programmer les GPU AMD.

Les informations communiquées par les partenaires ont donné un contexte concret à cette annonce matérielle. Selon le lancement des produits IA d’AMD, Meta faisait tourner l’ensemble du trafic en direct de son modèle Llama 3.1 405B sur des accélérateurs MI300X. AMD a également indiqué que plus d’un million de modèles pouvaient fonctionner sur sa plateforme sans travail de portage distinct.

Le rôle de Meta allait au-delà de l’achat de puces. Les entreprises optimisaient les performances à travers le silicium, les systèmes complets, le réseau, les logiciels et les applications. Cette étendue est importante, car un processeur rapide ne peut pas sauver un cluster limité par les mouvements de mémoire, la congestion des interconnexions ou des noyaux logiciels immatures.

Google jouait un rôle différent. L’entreprise a mis en avant les processeurs AMD EPYC au sein de l’infrastructure Google Cloud, y compris pour des charges de travail liées à son architecture AI Hypercomputer. Google prévoyait également des machines virtuelles cloud basées sur les nouveaux processeurs EPYC 9005 d’AMD.

Il ne s’agissait pas d’affirmer que Google avait remplacé ses propres unités de traitement tensoriel, ou TPU, par des GPU AMD. Google conçoit des TPU pour certaines charges de travail IA internes et cloud. L’entreprise exploite également une plateforme cloud diversifiée où les clients attendent plusieurs architectures de processeurs.

La relation entre AMD et Google représente donc un choix d’infrastructure, et non une alliance exclusive. Google peut proposer des capacités informatiques alimentées par AMD tout en continuant à développer des TPU, des processeurs Axion basés sur Arm et des services construits autour des accélérateurs Nvidia.

Microsoft et Oracle ont apporté des éléments supplémentaires attestant de la demande des clients. Microsoft a décrit l’utilisation des MI300X avec Azure et des charges de travail GPT, tandis qu’Oracle a évoqué les CPU, GPU et produits réseau d’AMD au sein de sa plateforme cloud.

Databricks a fourni l’une des affirmations de performances les plus précises. Ses tests auraient montré une amélioration de plus de 50 % sur des modèles Llama et propriétaires avec du matériel MI300X. Ce chiffre provenait d’un test partenaire mis en avant par AMD ; il ne doit donc pas être considéré comme un résultat universel.

Le changement central allait au-delà d’une série de soutiens. AMD créait des boucles de retour avec des entreprises exploitant de grands modèles en production. Ces entreprises pouvaient identifier les goulets d’étranglement, influencer la conception des produits et apporter des optimisations dont les utilisateurs ultérieurs bénéficieraient.

Cette approche est depuis devenue plus concrète. AMD a déclaré en 2025 que sept des dix plus grands créateurs de modèles et entreprises d’IA exécutaient des charges de travail de production sur des accélérateurs Instinct. Meta a fait état d’un déploiement plus large des MI300X pour l’inférence de Llama 3 et Llama 4.

Les partenariats couvrent désormais plusieurs générations successives de matériel. Cette continuité distingue un déploiement stratégique d’une expérimentation temporaire menée lorsque l’approvisionnement en accélérateurs était limité.

Pourquoi l’infrastructure AMD Google compte désormais

Le lien entre AMD et Google est important parce qu’une concurrence crédible exige de la distribution, l’accès des développeurs et des opérations cloud reproductibles, et pas seulement des puces plus rapides.

Google Cloud a continué d’élargir son portefeuille de CPU AMD depuis l’événement de 2024. Ses machines virtuelles C4D associent des processeurs EPYC de cinquième génération à l’infrastructure Titanium de Google, qui décharge le CPU hôte de certaines tâches de réseau, de stockage et de gestion.

Google a rapporté un débit de service web jusqu’à 80 % plus élevé et des performances de calcul général 30 % meilleures que la génération précédente basée sur AMD. Ses résultats de performances C4D ont également cité une latence de stockage local jusqu’à 35 % plus faible.

Il ne s’agit pas de mesures directes de l’entraînement d’IA générative. Toutefois, les systèmes d’IA dépendent de plus que des accélérateurs. La préparation des données, les services de récupération, les bases de données, l’ordonnancement et les serveurs d’applications consomment tous une capacité CPU conventionnelle.

Une application IA peut générer des réponses sur un GPU tout en utilisant des CPU pour authentifier les utilisateurs, récupérer des documents, filtrer les résultats et acheminer les requêtes. L’amélioration de ces tâches environnantes peut augmenter le débit du système même si le modèle lui-même reste inchangé.

Le partenariat entre AMD et Google élargit également les endroits où les équipes d’ingénierie peuvent rencontrer du matériel AMD. Cette familiarité compte, car les entreprises hésitent à introduire une deuxième plateforme d’accélérateurs lorsque les développeurs n’y ont pas accès pour les tests et l’optimisation.

La disponibilité dans le cloud réduit cet obstacle. Une équipe peut profiler une charge de travail, vérifier la prise en charge des bibliothèques et comparer le comportement opérationnel avant de prendre un engagement d’infrastructure plus important. Elle peut aussi conserver ses charges de travail CPU sur un cloud familier tout en évaluant ailleurs un environnement d’accélérateurs différent.

L’opportunité d’AMD a grandi à mesure que l’inférence représente une part plus importante du calcul IA. L’inférence est le processus qui consiste à exécuter un modèle entraîné pour produire une réponse, une classification, une image ou une autre sortie. Contrairement à une phase d’entraînement limitée, les dépenses d’inférence se répètent à chaque interaction utilisateur.

Ce coût récurrent donne aux opérateurs de modèles une raison d’optimiser le matériel pour des charges de travail particulières. Un accélérateur polyvalent offre de la flexibilité, mais il peut inclure des ressources de mémoire ou de calcul dont une tâche de production étroitement définie n’a pas besoin.

Les systèmes de recommandation de Meta illustrent ce point. Ils fonctionnent à une échelle immense et utilisent des schémas de charge de travail relativement stables. Un processeur adapté à ces schémas peut privilégier le coût, la consommation énergétique ou la latence plutôt que les capacités étendues exigées par la recherche sur les modèles de pointe.

Google fait face à la même logique économique, même s’il traite en partie le problème à l’aide de ses propres TPU. Sa volonté de déployer des CPU AMD montre que les hyperscalers n’ont pas besoin d’une architecture de processeur unique à chaque couche.

La relation entre AMD et Google constitue par conséquent une partie d’une évolution plus large vers le calcul hétérogène. Dans de tels systèmes, les opérateurs attribuent chaque charge de travail au processeur, à l’accélérateur ou à la puce sur mesure qui lui convient le mieux.

Cette évolution met Nvidia sous pression sans obliger les clients à abandonner Nvidia. Un fournisseur cloud peut continuer à proposer des systèmes Nvidia tout en ajoutant du matériel AMD ou conçu en interne pour certains travaux. Même une diversification partielle peut améliorer le pouvoir de négociation et réduire la dépendance à une seule feuille de route.

Pour les développeurs, la question pratique est de savoir si les charges de travail restent portables. Un modèle qui ne fonctionne correctement qu’après une réécriture poussée et spécifique à un fournisseur crée des coûts de changement qui peuvent l’emporter sur un benchmark matériel favorable.

ROCm est la réponse d’AMD à ce problème. Sa valeur dépend de la compatibilité avec les frameworks, de la documentation, des outils de débogage, des bibliothèques optimisées et d’une prise en charge rapide des nouveaux modèles publiés. La disponibilité du matériel a peu de valeur lorsqu’une équipe de production ne peut pas reproduire le comportement de ses logiciels existants.

Meta transforme le discours sur le partenariat en test de six gigawatts

Meta a transformé l’argument d’écosystème d’AMD en un test de déploiement assorti d’étapes mesurables et d’un risque d’exécution significatif.

En février 2026, AMD et Meta ont annoncé un accord pluriannuel couvrant jusqu’à six gigawatts de déploiements de GPU AMD Instinct. Les gigawatts décrivent une capacité électrique, et non un nombre fixe d’accélérateurs, car la configuration des systèmes et leurs besoins énergétiques peuvent varier.

Le premier gigawatt doit commencer à être expédié au cours du second semestre 2026. Il utilisera un accélérateur sur mesure basé sur l’architecture MI450, des processeurs EPYC de sixième génération, le logiciel ROCm et la conception à l’échelle du rack Helios d’AMD.

Un système à l’échelle du rack considère une baie serveur entière comme une unité de calcul intégrée. Accélérateurs, CPU, mémoire, réseau, refroidissement et logiciels doivent fonctionner ensemble afin de fournir des performances utiles pour les modèles.

AMD a déclaré que Helios avait été développé conjointement avec Meta dans le cadre de l’Open Compute Project. La spécification Open Rack Wide de Meta a influencé la conception physique, offrant à AMD une voie d’accès à une infrastructure organisée autour des exigences opérationnelles de Meta.

L'accord de déploiement avec Meta aligne également les feuilles de route des entreprises en matière de silicium, de systèmes et de logiciels. Cette formulation signale une coordination plus profonde que l’achat de cartes accélératrices standard après le début de la production.

Meta agira comme client de lancement pour les processeurs serveur Venice et Verano d’AMD. Verano devrait inclure des modifications spécifiques aux charges de travail, conçues autour des performances, de la consommation énergétique et du coût d’exploitation.

L’accord contient un bon de souscription fondé sur les performances couvrant jusqu’à 160 millions d’actions AMD. L’acquisition dépend des volumes d’expédition, de seuils du cours de l’action AMD ainsi que de conditions techniques et commerciales. Le dépôt d’AMD pour le premier trimestre indiquait qu’aucune de ces actions n’était acquise au 28 mars 2026.

Ces conditions comptent parce que la capacité annoncée n’équivaut pas à un déploiement achevé. AMD doit fabriquer les produits, assembler les systèmes, assurer la prise en charge logicielle et satisfaire aux exigences de Meta. Meta doit ensuite installer cette capacité et y orienter des charges de travail significatives.

L’accord démontre également pourquoi AMD a besoin de la participation des créateurs de modèles. Meta connaît les caractéristiques, au niveau de l’opérateur, de l’inférence Llama, des systèmes publicitaires, des modèles de classement et de son assistant IA en expansion. Cette connaissance des charges de travail peut influencer la capacité mémoire, la conception des interconnexions et les priorités logicielles.

AMD gagne un client de référence exigeant. Meta gagne un fournisseur alternatif et une plateforme adaptée à certaines tâches. Les deux parties gagnent du levier face à un marché des accélérateurs toujours façonné par Nvidia.

Cet accord n’implique pas une migration complète de Meta. Meta a également pris des engagements substantiels envers Nvidia et continue de développer son propre Meta Training and Inference Accelerator, ou MTIA.

Cette combinaison est rationnelle. L’entraînement de pointe, l’inférence de recommandation et les services d’IA généralistes n’imposent pas des exigences identiques. Meta peut utiliser Nvidia pour certaines charges de travail, des produits AMD sur mesure pour d’autres et MTIA lorsque le silicium interne offre la bonne économie.

La concurrence principale n’oppose donc pas AMD à Nvidia pour chaque tâche d’IA. Elle oppose une solution Nvidia intégrée par défaut à une stratégie informatique multifournisseurs assemblée autour de charges de travail spécifiques.

Le plan de six gigawatts permettra de vérifier si cette alternative reste gérable à l’échelle de la production. Faire fonctionner deux plateformes d’accélérateurs accroît les exigences en matière de qualification, d’observabilité, de personnel et de maintenance logicielle.

Meta peut absorber davantage de cette complexité qu’une entreprise classique. Si ses optimisations remontent vers ROCm et les frameworks courants, les plus petits utilisateurs pourront en bénéficier. Si elles restent fortement personnalisées, l’accord en dira moins sur l’accessibilité plus large d’AMD.

Le mécanisme repose sur la co-conception matériel-logiciel

AMD peut réduire l’écart de performances lorsque les clients contribuent à optimiser ensemble les modèles et les systèmes, mais la co-conception doit produire des logiciels réutilisables pour transformer le marché.

Les performances d’un modèle ne dépendent pas uniquement des spécifications nominales de la puce. Les opérateurs doivent coordonner l’architecture du modèle, la précision numérique, le placement de la mémoire, les bibliothèques de communication, le comportement du compilateur et l’ordonnancement.

La précision numérique détermine le nombre de bits utilisés pour représenter les poids du modèle et les valeurs intermédiaires. Une précision réduite peut diminuer l’utilisation de mémoire et augmenter le débit, à condition que le modèle conserve une qualité de sortie acceptable.

Le placement de la mémoire est tout aussi important. Les grands modèles déplacent constamment les poids et les données temporaires entre la mémoire à large bande passante, les accélérateurs et les liens réseau. Un processeur peut rester inactif lorsque ces transferts ne parviennent pas à maintenir ses unités de calcul occupées.

Les noyaux logiciels exécutent des opérations individuelles comme la multiplication matricielle, l’attention et la conversion de données. Les fournisseurs règlent ces noyaux pour des matériels et des formes de modèles spécifiques. De petites améliorations peuvent s’additionner sur des milliards d’opérations répétées.

Nvidia a établi son avantage en associant le matériel à CUDA, à des bibliothèques optimisées, à des outils de développement et à une prise en charge des frameworks de longue date. Les organisations ont accumulé du code CUDA, de l’expertise et des pratiques de dépannage pendant de nombreuses années.

ROCm adopte un modèle open source et prend en charge des frameworks largement utilisés tels que PyTorch. L’ouverture peut aider les développeurs à examiner le code, à contribuer aux modifications et à éviter de dépendre d’une seule couche de programmation propriétaire.

Un code ouvert ne garantit pas automatiquement une maturité opérationnelle. Les équipes ont toujours besoin de versions stables, d’une installation prévisible, d’une couverture fonctionnelle complète, de diagnostics clairs et de performances sur des charges de travail variées.

Les partenariats d’AMD avec les créateurs de modèles ciblent directement ces lacunes. Meta apporte son expérience de PyTorch, Triton et de l’inférence à grande échelle. Microsoft et Oracle apportent leur connaissance des déploiements cloud. Des développeurs indépendants peuvent optimiser des moteurs tels que vLLM et SGLang.

La mise à jour de plateforme d’AMD pour 2025 faisait état d’améliorations de ROCm 7, d’une compatibilité élargie et de nouveaux outils de développement. L’entreprise a également indiqué que sa génération MI350 offrait de forts gains par rapport à MI300X, même si les comparaisons des fournisseurs dépendent fortement du modèle, de la taille des lots, de la précision et de la configuration du système.

La participation à des benchmarks indépendants offre une meilleure voie d’examen. MLPerf publie des résultats soumis selon des charges de travail et des règles définies, ce qui aide les acheteurs à comparer les systèmes sans s’appuyer uniquement sur des présentations de lancement.

La base de données des résultats MLPerf inclut des soumissions AMD Instinct aux côtés de systèmes utilisant Nvidia et d’autres accélérateurs. Les résultats exigent toujours une lecture attentive, car les quantités de matériel, les versions logicielles, les contraintes de latence et les divisions du benchmark peuvent différer.

Un résultat gagnant dans une catégorie n’établit pas une domination universelle. Il montre toutefois si les fournisseurs peuvent soumettre des systèmes fonctionnels selon des règles communes et divulguer suffisamment de détails de configuration pour permettre une comparaison éclairée.

Google ajoute une autre dimension à ce mécanisme. Son cloud utilise des processeurs AMD EPYC tandis que Google développe des TPU et ses propres logiciels de support. Cette coexistence montre que les entreprises d’infrastructure peuvent optimiser à plusieurs niveaux sans choisir un seul fournisseur pour tout.

La relation entre AMD et Google ne résout pas directement l’adoption de ROCm. Elle normalise toutefois la diversité architecturale au sein d’un grand cloud et crée des opportunités pour la technologie AMD dans des charges de travail connexes à l’IA.

Meta constitue l’argument le plus solide concernant les accélérateurs. En servant le trafic Llama sur MI300X et en co-concevant des systèmes basés sur MI450, l’entreprise offre à AMD un retour d’expérience réel en production qu’un benchmark synthétique ne peut pas fournir.

La question décisive est de savoir si AMD peut transformer ces enseignements propres à chaque client en capacités par défaut. La prise en charge des modèles dès leur lancement, c’est-à-dire une prise en charge utilisable au moment de la sortie d’un modèle, en sera un indicateur.

La qualité de la documentation en sera un autre. Les développeurs évaluent les plateformes lors d’installations échouées, d’erreurs de mémoire, d’opérateurs non pris en charge et de régressions de performances. Une plateforme doit rendre ces échecs compréhensibles et réparables.

La co-conception fonctionne lorsqu’elle raccourcit le chemin entre un nouveau modèle et un service de production fiable. Elle échoue lorsque chaque déploiement exige qu’une équipe privée du fournisseur de puces reconstruise la pile logicielle.

Ce que l’histoire des partenariats d’AMD ne prouve pas

Les engagements de grands clients valident la demande, mais ils ne prouvent pas encore une parité logicielle étendue, une livraison à l’échelle ou une économie supérieure.

Les annonces d’AMD comprennent plusieurs niveaux de performances rapportées par l’entreprise. Les affirmations sur le débit, l’efficacité énergétique et les gains générationnels reposent souvent sur des configurations sélectionnées. Les acheteurs devraient comparer leurs propres modèles selon les exigences de latence et de qualité qui comptent pour eux.

Les performances d’inférence sont particulièrement sensibles à la taille des lots. Un système peut afficher un débit total élevé en traitant de nombreuses requêtes ensemble, tout en engendrant un délai inacceptable pour un assistant interactif.

La longueur du modèle modifie également le résultat. Les contextes longs consomment davantage de mémoire et augmentent le travail d’attention. Une plateforme adaptée aux recommandations courtes peut se comporter différemment lors du traitement de longs documents ou de sessions d’agents prolongées.

L’utilisation du système affecte aussi l’économie. Un accélérateur qui semble efficace à pleine charge peut devenir coûteux lorsque la demande est irrégulière. Les opérateurs doivent tenir compte de la capacité inutilisée, du réseau, de l’alimentation électrique, du refroidissement et de la main-d’œuvre d’ingénierie.

Le plan Meta de six gigawatts introduit un risque de fabrication. AMD dépend de fonderies et de fournisseurs externes pour les puces avancées, l’encapsulation, la mémoire et d’autres composants. Un goulot d’étranglement à n’importe quel niveau peut ralentir la livraison de systèmes complets.

Helios ajoute un risque d’intégration, car les produits à l’échelle du rack nécessitent une coordination entre les CPU, les GPU, les cartes d’interface réseau, les commutateurs, les logiciels et le refroidissement. La validation de composants individuels ne garantit pas un fonctionnement stable du cluster.

Le rapport annuel 2025 d’AMD indiquait que les livraisons de production pour MI400 et Helios restaient en bonne voie pour le second semestre 2026. Il s’agit d’une déclaration importante sur le calendrier, mais pas d’une confirmation que le premier gigawatt prévu est opérationnel.

L’accélérateur personnalisé de Meta crée une autre incertitude. La personnalisation peut améliorer l’efficacité pour une charge de travail connue en supprimant des capacités inutiles ou en modifiant l’équilibre entre calcul, mémoire et réseau.

La même spécialisation peut limiter la flexibilité. Si Meta modifie ses modèles ou son architecture de service, un accélérateur réglé de manière étroite pourrait offrir moins d’options qu’un système généraliste. Le compromis final dépendra de spécifications non divulguées et du comportement réel des charges de travail.

Nvidia continue également d’améliorer son matériel, son réseau, ses logiciels d’inférence et ses systèmes à l’échelle du rack. AMD est en concurrence avec une plateforme en mouvement, et non avec les produits disponibles lors du lancement de MI300X.

La stratégie de Google ajoute une pression venue d’une autre direction. Les TPU offrent à Google une alternative verticalement intégrée pour Gemini et certains clients cloud. Amazon développe également les accélérateurs Trainium et Inferentia, tandis que Microsoft a introduit ses propres puces d’IA.

Ces plateformes personnalisées signifient qu’AMD se bat pour la part du calcul IA que les hyperscalers préfèrent s’approvisionner à l’extérieur. Son marché accessible peut croître rapidement tout en faisant face à une concurrence plus intense pour chaque charge de travail.

Le mot-clé AMD Google peut aussi conduire à une conclusion inexacte. L’utilisation de processeurs EPYC par Google n’établit pas une adoption à grande échelle par Google des GPU Instinct pour Gemini. La relation vérifiée porte sur les CPU cloud et une coopération d’infrastructure plus large.

De même, l’adoption par Meta ne démontre pas qu’une entreprise ordinaire peut passer de CUDA à ROCm sans friction. Meta dispose de ressources d’ingénierie, contrôle ses modèles et bénéficie d’un accès direct à la feuille de route d’AMD.

L’interprétation la plus solide est plus limitée. AMD a acquis suffisamment de confiance pour que de grands clients placent des charges de travail de production et des capacités futures sur sa technologie. L’entreprise doit désormais transformer une collaboration sur mesure en une plateforme que d’autres développeurs peuvent utiliser de manière fiable.

Cette distinction devrait guider les évaluations des entreprises. Les acheteurs ont besoin de tests au niveau des charges de travail, de coûts d’exploitation totaux, d’engagements de support logiciel et d’un plan de migration crédible. Ils ne devraient pas considérer le logo d’un partenaire comme un substitut à une validation technique.

Trois signaux détermineront si AMD peut mettre Nvidia sous pression

Les livraisons, les performances de modèles portables et les déploiements tiers reproductibles détermineront si la coalition d’AMD modifie l’équilibre concurrentiel.

Le premier signal sera le déploiement initial de Meta basé sur MI450. AMD a programmé des livraisons prenant en charge le premier gigawatt pour le second semestre 2026. Des preuves de capacité installée, de charges de travail de production et de jalons atteints renforceraient l’idée que la co-conception peut atteindre une échelle physique.

Un retard compterait pour plus d’un client. Helios est la plateforme sur laquelle AMD compte s’appuyer pour réaliser ses ambitions à l’échelle du rack, de sorte que des problèmes pourraient affecter les déploiements ultérieurs et la confiance au sein de son réseau de partenaires.

Le deuxième signal concerne la prise en charge des modèles en dehors des projets privés de clients. Les développeurs devraient suivre la rapidité avec laquelle ROCm prend en charge les nouveaux modèles Llama, les modèles ouverts liés à Claude et Gemini, ainsi que d’autres sorties largement adoptées.

Une prise en charge utile ne se limite pas au lancement d’un conteneur. Les équipes ont besoin d’une latence compétitive, d’une qualité de sortie prévisible, d’un comportement multi-GPU stable et de bibliothèques maintenues. Les soumissions aux benchmarks publics devraient préciser les configurations matérielles et logicielles à l’origine de chaque résultat.

AMD a étendu cette stratégie en juillet 2026 grâce à un accord permettant à Anthropic de déployer jusqu’à deux gigawatts de GPU de la série MI450. Les entreprises prévoient également d’utiliser Claude dans des travaux visant à améliorer les charges de travail AMD et le développement de ROCm.

Cet accord offre un nouveau test. Si les optimisations produites avec Meta, Anthropic et les développeurs open source convergent dans des logiciels publics, la plateforme d’AMD deviendra plus facile à adopter. Si chaque client exige une branche distincte, le passage à l’échelle restera coûteux.

Le troisième signal sera l’utilisation reproductible par des organisations ne disposant pas d’équipes d’ingénierie au niveau des hyperscalers. Oracle, les fournisseurs de cloud, les fabricants de systèmes et les éditeurs de logiciels peuvent révéler si Helios et ROCm fonctionnent comme des produits plutôt que comme des projets d’intégration sur mesure.

Les preuves les plus convaincantes incluront un trafic de production soutenu, des détails opérationnels publiés et des mesures indépendantes. Des annonces de capacité supplémentaires révéleront la demande, mais pas la facilité d’utilisation.

L’élargissement de la gamme de CPU AMD de Google Cloud reste pertinent ici. La relation entre AMD et Google donne aux clients un accès mature à des systèmes basés sur EPYC et démontre une confiance continue dans la feuille de route serveur d’AMD. Elle rappelle également que l’infrastructure cloud est de plus en plus multifornisseur par conception.

Pour les développeurs et les acheteurs en entreprise, l’action immédiate consiste à tester des charges de travail représentatives plutôt que de débattre de manière abstraite des affirmations des fournisseurs. Utilisez le même modèle, les mêmes types de données, les mêmes longueurs de contexte, les mêmes objectifs de latence et les mêmes conditions de défaillance sur toutes les plateformes.

Les équipes devraient également préserver les éléments probants derrière chaque décision. Une base de connaissances d’ingénierie consultable peut relier les résultats de benchmarks, les notes de déploiement, les changements de modèles et la documentation des fournisseurs à mesure que les plateformes évoluent.

L’histoire entre AMD, Google et Meta porte en définitive sur la capacité des concepteurs de modèles à créer une deuxième voie viable grâce à une ingénierie conjointe. Surveillez le premier déploiement de Meta, l’état de préparation public des modèles sur ROCm et les déploiements chez des clients classiques. Si ces trois éléments progressent, Nvidia fera face à un concurrent durable sur le plan des plateformes. Si l’un d’eux cale, les partenariats d’AMD resteront importants, mais incomplets.