AMD a publié ROCm 10.0 le 27 août 2026, en passant de la version de production ROCm 7.14 directement à une nouvelle version majeure, ce qui referme une séquence de numérotation devenue illisible. La nouveauté principale s'appelle ROCm.AI et regroupe trois éléments livrés ensemble : une commande rocm unifiée, un catalogue d'AMD Skills qui apporte des procédures validées aux agents de développement comme Claude, Cursor et Codex, et Hyperloom, un système agentique qui profile une charge d'inférence puis réécrit le code hôte et les noyaux GPU pour l'accélérer. ROCm 10.0 inaugure aussi une cadence de six semaines, et met fin à la séparation entre les piles Windows et Linux.
The short answer
AMD a publié ROCm 10.0 le 27 août 2026, en laissant derrière elle le reste de la série 7.x depuis la version de production ROCm 7.14. La publication s'organise autour de ROCm.AI, qui réunit une commande rocm unifiée, un catalogue d'AMD Skills donnant aux agents de développement comme Claude, Cursor et Codex des procédures ROCm validées, et Hyperloom, un optimiseur agentique qui profile une charge d'inférence puis réécrit le code hôte et les noyaux GPU. ROCm 10.0 est la première version sur une cadence de six semaines, et elle retire le HIP SDK Windows au profit d'un ROCm Core SDK partagé avec Linux.
Quiconque a tenté d'installer ROCm cet été comprendra pourquoi le numéro de version a bougé ainsi. ROCm 7.2 était la version stable, les moutures 7.9 et suivantes des préversions techniques, puis 7.14 est arrivée en juillet comme version de production bâtie sur le système de compilation TheRock. Savoir quel numéro méritait confiance prenait plus de temps que de raison.
Le numéro relève du ménage, le contenu non
ROCm 10.0 remet de l'ordre et tombe sur les dix ans de la pile, argument qu'AMD utilise sans surprise dans son annonce. Ce n'est pas une rupture de compatibilité, et y voir une réécriture serait une erreur.
Ce qui est réellement neuf, c'est l'endroit où AMD a dépensé cette version. Pas sur un chiffre de bibliothèque de noyaux, mais sur la partie du travail qui coûte le plus de temps depuis toujours : installer, vérifier, servir.
ROCm.AI, ce sont trois outils concrets
La marque est vague, le contenu ne l'est pas.
La ligne de commande ROCm couvre tout le cycle de vie. rocm serve <modele> monte un modèle en inférence sur PyTorch, et rocm examine diagnostique les problèmes d'environnement et de pilote. La seconde est plus utile qu'elle n'en a l'air. Une bonne part des fils d'assistance ROCm sont une variante du pilote et de l'exécutif en désaccord sur le matériel présent, et disposer d'une commande officielle qui répond à cette question vaut mieux qu'un tutoriel de plus.
Les AMD Skills empaquettent des procédures validées au format Agent Skills, donc portables plutôt que liées à un éditeur. AMD cite Claude, Cursor et Codex. Le catalogue couvre GPU et CPU : rocm-doctor, serving-llms-on-instinct, serving-llms-on-epyc et quantize-for-zentorch. Le problème visé est précis et familier : un agent qui a lu bien plus de CUDA que de ROCm produira avec assurance des réponses de forme CUDA, et un fichier de compétence est un moyen économique de lui donner la bonne procédure.
Hyperloom est la brique ambitieuse. Il profile une charge d'inférence, identifie le goulot, planifie et applique une optimisation sur le code hôte et les noyaux GPU, puis valide performance et justesse, sans humain dans la boucle à chaque cycle. Il orchestre plusieurs composants, dont TraceLens-Agent pour l'identification des goulots, Magpie pour l'évaluation des noyaux, IntelliKit pour le profilage conversationnel, GEAK pour l'optimisation de noyaux et Arbor pour la recherche. L'annonce d'AMD parle de semaines de réglage manuel ramenées à des heures. Le matériel pris en charge est MI300X, MI325X, MI350X et MI355X : c'est une fonction Instinct, pas de quoi occuper une Radeon de station de travail.
La partie ingrate est la plus importante
Sous l'histoire des agents se cache un ensemble de changements qui pèseront davantage au quotidien.
L'empaquetage Linux est consolidé. Il existe des conteneurs prêts pour la production et des roues Python pour vLLM, ce qui supprime toute une catégorie de problèmes de compilation pour qui monte une pile de service. L'ajustement fin local est pris en charge sur Ryzen AI Max, ce qui met un chemin d'entraînement modeste mais réel sur du matériel achetable. Et la cadence de publication passe à environ six semaines, ROCm 10.0 étant la première version sous ce régime.
Une cadence prévisible vaut plus qu'il n'y paraît. Le reproche historique fait à ROCm n'était pas seulement qu'une fonction manquait, c'était que personne ne pouvait dire quand elle arriverait. Un rythme fixe de six semaines transforme cela en question de planification plutôt qu'en pari.
Windows cesse d'être une seconde pile
AMD a retiré le HIP SDK sous Windows. Le ROCm Core SDK couvre désormais Windows et Linux avec une numérotation unifiée et la même cadence.
C'est la bonne décision structurelle, assortie d'une réserve honnête : le paquet Windows est aujourd'hui un paquet statique plutôt qu'un vrai installateur, la prise en charge d'un installateur natif étant prévue plus tard dans l'année. L'architecture est donc corrigée avant l'expérience.
Cela s'inscrit dans une période où le récit calcul d'AMD avance sur plusieurs fronts à la fois, depuis une réécriture en Rust du chemin d'ordonnancement Slurm pour les grappes ROCm jusqu'à la feuille de route MI400 et EPYC Venice présentée à Advancing AI 2026, en passant par le travail d'inférence sur NPU des puces Ryzen AI.
Ce que nous en ferions
Si vous utilisez déjà ROCm, la ligne de commande et les paquets consolidés sont la raison de regarder, pas la marque agentique. rocm examine fait partie de ces outils qui se rentabilisent la première fois qu'un déploiement refuse de voir une carte.
Si vous évaluez AMD face à l'alternative, notez soigneusement ce qui manque à cette annonce : aucun chiffre de performance publié. Le passage de semaines à heures promis par Hyperloom est une affirmation sur le flux de travail, pas sur le débit, et il concerne quatre puces Instinct. Mesurez sur votre charge avant d'en faire un argument budgétaire.
Et si vous utilisez des agents de développement au quotidien, AMD Skills est ici la chose la moins coûteuse à essayer. Pointer un agent vers un fichier de procédure validée ne coûte rien, et le mode d'échec que cela évite, un agent qui écrit avec assurance des idiomes CUDA dans un projet ROCm, la plupart d'entre nous l'ont déjà rencontré.
Sources et pour aller plus loin
- AMD Jumps From ROCm 7.14 To ROCm 10.0 With ROCm.AI, Phoronix, 27 août 2026
- ROCm 10.0: A Decade of Open Compute, Built for the Age of Agentic AI, blogs ROCm d'AMD
- ROCm.AI: The AI-Native Developer Experience for Building on AMD, AMD
- What is Hyperloom?, documentation ROCm
- Dépôt source de Hyperloom, AMD-AGI sur GitHub
Questions fréquentes
Pourquoi AMD est il passé de ROCm 7.14 à ROCm 10.0 ?
Surtout pour mettre fin à une numérotation devenue impossible à expliquer. ROCm 7.2 était la version stable pendant que les moutures 7.9 et suivantes étaient des préversions techniques, puis ROCm 7.14 est arrivée en juillet comme version de production bâtie sur le système de compilation TheRock, avec la prise en charge des Ryzen AI série 400. Comprendre quel numéro signifiait pris en charge et lequel signifiait préversion demandait un effort disproportionné. Un saut majeur vers 10.0 remet les compteurs à zéro, et cela tombe sur les dix ans de la pile, argument qu'AMD met en avant dans son annonce. Cela ne signale pas en soi une rupture de compatibilité : il faut y voir du ménage et de la communication, pas une réécriture.
Que sont les AMD Skills et faut il un agent de développement précis ?
Les AMD Skills sont des procédures empaquetées au format Agent Skills, donc portables entre les agents qui lisent ce format plutôt que liées à un seul éditeur. AMD cite Claude, Cursor et Codex. Le catalogue couvre les chemins GPU et CPU : rocm-doctor pour diagnostiquer un environnement cassé, serving-llms-on-instinct pour les accélérateurs Instinct, serving-llms-on-epyc pour l'inférence sur processeur, et quantize-for-zentorch pour le chemin ZenDNN. Le problème visé est réel et peu spectaculaire : un agent qui connaît mal ROCm produit avec assurance des réponses de style CUDA, et un fichier de compétence est un moyen économique de lui fournir la procédure validée plutôt que d'espérer qu'il lise la bonne page de documentation.
Qu'apporte Hyperloom qu'un profileur n'apporte pas ?
Il ferme la boucle. Un profileur indique où le temps est passé puis s'arrête, laissant un humain formuler une hypothèse, modifier le code, relancer et comparer. Hyperloom automatise ce cycle entier sur le code hôte et les noyaux GPU : il profile, identifie les goulots, planifie une optimisation, l'applique, puis valide la performance et la justesse avant de continuer. Il orchestre plusieurs composants, dont TraceLens-Agent pour l'identification des goulots, Magpie pour l'évaluation des noyaux, IntelliKit pour le profilage conversationnel, GEAK pour l'optimisation autonome de noyaux et Arbor pour la recherche. AMD annonce des semaines de réglage manuel ramenées à des heures. Le matériel pris en charge au lancement est MI300X, MI325X, MI350X et MI355X : c'est donc une fonction Instinct, pas quelque chose pour une station de travail Radeon.
Cela change t il l'écart pratique avec CUDA ?
Cela attaque une partie précise de cet écart. Le plus dur dans l'adoption de ROCm a rarement été les noyaux eux mêmes, mais la friction autour : quel paquet pour quelle carte, pourquoi le pilote et l'exécutif ne s'accordent pas, quel conteneur fonctionne vraiment, et comment monter une pile de service sans y passer une semaine. Une ligne de commande unifiée, des paquets consolidés, des conteneurs de production et des roues Python pour vLLM visent directement cette friction. Ce que cela ne fait pas, c'est combler l'écart de bibliothèques et d'écosystème, et AMD n'a publié aucun chiffre de performance avec cette version : traitez donc le volet performance comme non démontré tant que vous ne l'avez pas mesuré sur votre propre charge.
Qu'est ce qui change pour ROCm sous Windows ?
Le HIP SDK est retiré et le ROCm Core SDK couvre désormais Windows et Linux avec la même numérotation et la même cadence de publication. C'est le point important : Windows cesse d'être une ligne de produit distincte et en retard. La réserve, c'est que le paquet Windows reste pour l'instant un simple paquet statique plutôt qu'un véritable installateur, la prise en charge d'un installateur natif étant prévue plus tard en 2026. La direction est donc la bonne, et l'expérience de développement sous Windows reste un chantier.