Par Tsuky 
AMD a publié ROCm 10 le 27 août, dix ans après la première version de sa pile de calcul GPU.
La nouveauté la plus mise en avant n’est pourtant ni un nouveau compilateur ni une bibliothèque mathématique.
C’est ROCm.AI, désormais annoncé en disponibilité générale.
AMD le présente comme une nouvelle couche de développement destinée à utiliser des agents IA pour construire, exécuter, diagnostiquer et surtout optimiser les workloads fonctionnant sur ses plateformes.
ROCm.AI repose sur trois outils différents
AMD regroupe sous ce nom trois expériences : Hyperloom, AMD Skills et ROCm CLI.
Elles ne font pas exactement le même travail.
Hyperloom est la partie chargée de l’optimisation autonome des workloads.
AMD Skills injecte des procédures et connaissances spécifiques à AMD dans des assistants de programmation existants.
ROCm CLI fournit enfin une interface commune pour installer, gérer et surveiller les environnements.
Le fil conducteur est le même : réduire le nombre d’étapes où un ingénieur doit connaître manuellement chaque outil de la pile ROCm.
Hyperloom cherche lui-même pourquoi un modèle est lent
Hyperloom est probablement la composante la plus ambitieuse.
AMD le décrit comme un système agentique autonome capable d’optimiser un workload d’inférence de bout en bout, aussi bien dans le code exécuté par le CPU hôte que dans les kernels GPU.
Il commence par profiler l’exécution.
Il cherche ensuite les goulets d’étranglement, explore différentes optimisations, modifie le code, lance des benchmarks puis vérifie que les changements n’ont pas cassé le résultat.
La documentation décrit une boucle itérative de type Think, Decide, Implement, Benchmark.
L’important est que l’agent ne s’arrête pas à proposer une optimisation dans une fenêtre de chat : il peut modifier le workload et vérifier concrètement si la modification fonctionne.
L’agent travaille aussi bien sur HIP que Triton
Avec ROCm 10, Hyperloom prend en charge les workloads utilisant notamment vLLM et SGLang.
Les optimisations peuvent cibler du code HIP, Triton ou FlyDSL.
Le système produit également des rapports décrivant les modifications proposées ainsi que les améliorations mesurées ou attendues.
AMD fournit des workflows autonomes mais permet aussi d’appeler Hyperloom à travers AMD Skills.
La documentation officielle montre par exemple comment déclencher une session d’optimisation directement depuis Claude Code.
Il ne s’agit pas uniquement d’optimiser un kernel isolé
C’est l’un des points sur lesquels AMD insiste.
Un modèle peut être ralenti par son kernel GPU, mais aussi par la gestion mémoire, la planification des requêtes, les échanges avec le CPU ou la manière dont le moteur d’inférence organise son travail.
Hyperloom vise donc le workload complet.
Sa chaîne de profilage s’appuie notamment sur TraceLens pour analyser les traces et identifier les limites de performance à explorer.
L’optimiseur peut ensuite tester plusieurs branches plutôt que supposer que la première modification est forcément la bonne.
La quantification peut même entrer dans la boucle
La documentation Hyperloom prévoit une intégration facultative avec AMD Quark.
Un développeur peut demander une quantification avant la phase principale d’optimisation.
Les schémas documentés comprennent notamment FP8, PTPC FP8, MXFP4 et MXFP4 avec FP8.
Les deux variantes MXFP4 sont réservées aux MI355X dans cette configuration.
Si un format demandé n’est pas compatible avec le GPU sélectionné, Hyperloom peut ignorer cette étape et continuer sur le modèle non quantifié plutôt que faire échouer automatiquement toute la procédure.
AMD Skills apporte la documentation AMD directement dans les agents de code
La deuxième brique adopte une approche différente.
AMD Skills fournit des workflows préparés et testés pour des assistants de programmation comme Claude Code, Cursor et Codex.
L’idée est d’éviter qu’un agent générique invente une commande ROCm approximative ou ignore une procédure spécifique à une plateforme AMD.
AMD organise actuellement ces Skills autour de trois catégories.
Les workflows client concernent notamment l’IA locale et l’intégration dans les applications.
Les workflows cross-stack couvrent diagnostics, routage, analyse de traces et optimisation.
Les workflows serveur ciblent les GPU Instinct et les processeurs EPYC pour le serving, le profiling et l’analyse de performances.
Les Skills sont déjà distribués dans plusieurs écosystèmes
Les Skills montrés initialement lors d’Advancing AI 2026 sont désormais disponibles via les marketplaces de Claude Code, Codex et Cursor ainsi que dans un catalogue ouvert sur GitHub.
AMD affirme que chaque Skill publié passe des tests structurels et comportementaux avant sa diffusion.
Cela ne garantit évidemment pas que l’agent prendra toujours la meilleure décision.
Le but est plutôt de fournir à ces assistants des chemins de travail validés pour l’environnement AMD au lieu de les laisser reconstruire seuls toute la procédure à partir de documentation dispersée.
ROCm CLI veut cacher une partie du chaos des versions
La troisième composante, ROCm CLI, s’attaque davantage à l’administration.
Une même interface permet d’inspecter la machine, installer et gérer des environnements ROCm, servir des modèles, exécuter des diagnostics, mettre à jour des composants ou contrôler différents runtimes.
Les mêmes commandes peuvent être utilisées manuellement, par un agent IA ou dans une chaîne d’intégration continue.
Le CLI existe sous Linux et Windows sous la forme d’un binaire précompilé et peut fonctionner sans qu’une installation ROCm complète soit déjà présente.
Il sait également maintenir plusieurs environnements côte à côte, les activer et effectuer un rollback.
Mais le ROCm CLI n’est pas encore réellement en GA
C’est une nuance importante dans l’annonce.
AMD dit que ROCm.AI est désormais généralement disponible, mais qualifie encore ROCm CLI de Technology Preview.
La documentation précise qu’il fournit actuellement une expérience indépendante des versions à partir de ROCm 7.13 et que le support officiel de ROCm 10 doit arriver prochainement.
Il ne faut donc pas interpréter la disponibilité générale de l’ensemble comme signifiant que chacune de ses briques a atteint exactement le même niveau de maturité.
Une console affiche désormais jusqu’aux tokens par watt
ROCm CLI inclut également ROCm Console, anciennement appelée dash.
Elle fournit une vue en temps réel de l’état du runtime, du serving, de l’utilisation GPU et de différents benchmarks.
Sur les systèmes Instinct compatibles, AMD cite notamment la mémoire HBM, la consommation électrique et les tokens par watt parmi les métriques disponibles.
Ce dernier indicateur traduit assez bien l’évolution du marché.
Pour un opérateur de cluster IA, le meilleur GPU n’est plus forcément celui qui produit le plus de tokens par seconde, mais celui qui en produit suffisamment sans faire exploser l’électricité et le coût d’exploitation.
AMD annonce 3,3 fois plus de performances en inférence
Le chiffre le plus spectaculaire de l’annonce est une amélioration moyenne de 3,3x en inférence.
AMD annonce également 2,4x en entraînement.
L’entreprise attribue ces gains à l’optimisation des kernels, de la mémoire, du parallélisme et de la planification.
Présentés seuls, ces deux chiffres peuvent néanmoins donner une impression incorrecte de ce qui est réellement comparé.
Ce n’est pas un benchmark simple de ROCm 10 contre ROCm 7
Les notes méthodologiques d’AMD sont essentielles.
Pour le chiffre d’inférence, les tests ont été réalisés sur un serveur équipé de huit Instinct MI355X.
AMD compare une configuration ROCm 7.0 à une preview de ROCm.AI reposant sur ROCm 7.2.2 et comprenant des kernels optimisés ainsi que des changements de parallélisme et de scheduling.
Les trois modèles utilisés sont GLM-5, Kimi-K2.5 et DeepSeek-R1-0528.
Le 3,3x représente la moyenne combinée du débit en tokens par seconde obtenu sur ces trois workloads.
Il ne s’agit donc pas d’un facteur que l’on peut appliquer automatiquement à n’importe quel modèle simplement en installant ROCm 10.
Le 2,4x en entraînement dépend lui aussi d’un scénario précis
AMD utilise encore une plateforme de huit MI355X pour ses mesures d’entraînement.
Les tests passent cette fois par Megatron-LM avec DeepSeek-V2-Lite, DeepSeek-V3-16B et Qwen3-30B-A3B.
Le résultat publié correspond là encore à une moyenne en tokens par seconde entre plusieurs configurations optimisées.
AMD précise elle-même que les performances réelles peuvent varier selon le matériel, les versions logicielles, les moteurs utilisés et les optimisations appliquées.
Ces chiffres démontrent donc surtout la marge qu’AMD affirme pouvoir récupérer grâce au travail logiciel, pas une garantie universelle de multiplication des performances.
Et c’est justement le problème qu’AMD doit résoudre face à Nvidia
La question logicielle est particulièrement sensible pour AMD.
Nvidia ne domine pas uniquement le marché des accélérateurs grâce aux caractéristiques de ses GPU.
CUDA, ses bibliothèques, ses outils de profiling et les habitudes accumulées par les développeurs constituent une barrière considérable pour un concurrent.
Un MI355X très performant n’aide pas beaucoup une équipe si elle doit consacrer davantage de temps à porter, profiler et régler son application.
Avec ROCm.AI, AMD essaie donc d’utiliser les modèles de programmation eux-mêmes comme moyen de réduire la complexité de son écosystème.
ROCm 10 refond aussi ce qui se trouve sous les agents
L’agentique n’est pas la seule évolution de ROCm 10.
AMD poursuit sa réorganisation de la pile autour du ROCm Core SDK, avec une architecture plus modulaire.
TheRock, son système automatisé et open source de build et de publication passé en production avec ROCm 7.14, sert désormais de fondation au lancement complet.
Les versions nightly, release candidate et stables utilisent ainsi des artefacts distribués selon un format commun.
AMD explique notamment que cela doit simplifier les dépôts, les installations automatisées, les images de conteneurs et les environnements déconnectés.
ROCm essaie moins d’imiter CUDA que de réduire le besoin de le connaître
Pendant plusieurs années, la comparaison entre AMD et Nvidia tournait autour de la question de compatibilité : tel framework fonctionne-t-il sur ROCm, tel kernel a-t-il une implémentation HIP, tel modèle démarre-t-il correctement ?
ROCm 10 ajoute une couche différente.
AMD part du principe qu’une partie de cette complexité peut être absorbée par des outils capables d’installer l’environnement, consulter une procédure spécialisée, profiler le code puis essayer eux-mêmes plusieurs optimisations.
Cela ne fait pas disparaître dix années d’avance d’écosystème d’un concurrent.
Mais si Hyperloom tient sa promesse, une partie du travail que les ingénieurs devaient auparavant apprendre à faire manuellement pourra être déléguée.
Le pari de ROCm 10 est donc assez ironique : AMD compte maintenant sur l’IA pour rendre ses GPU plus faciles à utiliser pour l’IA.