Le débat a changé de nature
Pendant des années, « CUDA vs ROCm » se résumait à une question binaire : est-ce que la pile AMD fonctionne ? La réponse honnête tenait en trois mots : pas sans souffrance. Des kernels qui crashaient sur des modèles de référence, des versions de PyTorch qui supportaient une carte sur deux, un compilateur HIP qui demandait des patchs manuels pour transformer un kernel CUDA non trivial. Ce n’est plus le débat de 2026.
Aujourd’hui, la question est devenue quantitative : quel écart reste-t-il, et où ? Le changement n’est pas cosmétique. Il déplace la décision du registre technique (« est-ce que ça compile, est-ce que ça plante ») vers le registre économique : « est-ce que l’écart de quelques pourcents justifie de payer la prime NVIDIA, ou de la fuir ». On passe d’un test binaire à un arbitrage coût/performance, et c’est un terrain où AMD peut enfin se battre.
L’état des versions
Le rythme de ROCm s’est accéléré, et son périmètre s’est élargi : la pile couvre désormais le datacenter, les Radeon grand public et les puces Ryzen AI, avec des intégrations jusque dans des outils comme ComfyUI. Concrètement, un développeur peut prototyper sur une Radeon de bureau et redéployer le même code sur un MI300, sans réécrire ni recompiler, ce qui n’était vrai que côté NVIDIA depuis dix ans. AMD ne traite plus ROCm comme un sous-produit mais comme un produit à part entière, ce qui est la condition pour exister face à un écosystème qui a dix ans d’avance.
La parité au niveau framework
Le point décisif : au niveau des frameworks, la parité est essentiellement atteinte. PyTorch et les runtimes d’inférence vLLM, SGLang et llama.cpp tournent tous correctement sur ROCm. Un développeur qui écrit du PyTorch standard et sert ses modèles avec vLLM n’a, presque toujours, pas à savoir sur quel matériel il tourne : le backend ROCm absorbe la traduction CUDA→HIP au moment de la compilation, et l’API qu’il manipule reste identique.
Ce résultat n’est pas seulement le fait d’AMD. Il vient surtout d’une décision communautaire : les runtimes majeurs ont intégré ROCm comme cible de première classe parce que leurs utilisateurs le demandaient. PyTorch maintient deux backends en parallèle, vLLM compile des kernels HIP en CI à chaque release, llama.cpp publie des binaires ROCm dès la sortie d’une nouvelle carte AMD. La portabilité ne vient pas du compilateur d’AMD seul : elle vient d’un écosystème open source qui a décidé de ne plus dépendre d’un seul fournisseur, et qui finance l’effort d’intégration que ce choix implique.
Là où l’écart persiste
La parité framework ne veut pas dire parité totale. Quatre zones d’écart subsistent.
| Zone | État côté ROCm | Contournable ? |
|---|---|---|
| Frameworks (PyTorch, vLLM…) | Parité de fait | Sans objet |
| Performance brute (charges intensives) | ~10–30 % en retrait | Partiellement (kernels) |
| Runtimes propriétaires (TensorRT-LLM, NIM) | Absents, NVIDIA uniquement | Non |
| Kernels de pointe (FlashAttention récent) | Décalage de quelques mois | Oui, avec délai |
| Kernels CUDA sur mesure | À réécrire en HIP | Oui, avec effort |
L’écart de performance brute, soit 10 à 30 % sur les charges les plus intensives en calcul, est réel mais variable. Il dépend du modèle, de la charge et de la maturité des kernels : un FlashAttention Implémentation tile-by-tile de l'attention qui évite de matérialiser la matrice d'attention complète en HBM. Réduit drastiquement la consommation mémoire et accélère le calcul, particulièrement sur longs contextes. Trois versions (v1/v2/v3), chacune optimisée pour une génération de GPU. Approfondir dans le glossaire récemment publié peut sortir avec une implémentation CUDA optimisée à la main et une version HIP générée automatiquement qui laisse 25 % sur la table, jusqu’à ce qu’AMD ou un contributeur ré-optimise le kernel. À la release suivante, l’écart se referme, et un nouveau kernel l’ouvre à nouveau ailleurs. C’est un retard de quelques mois qui se résorbe par cycles, pas une dette compilateur insurmontable.
Les runtimes propriétaires de NVIDIA (TensorRT-LLM, NIM), eux, restent structurellement hors de portée. C’est un choix de NVIDIA, pas une limite d’AMD, et tant que ce choix tient, certaines équipes resteront sur Hopper ou Blackwell pour cette raison seule.
Le vrai verrou : l’écosystème, pas le compilateur
Pour voir d’où vient cet écart, il faut déplier ce que recouvre « écosystème ». Trois couches s’empilent. La première est l’outillage périphérique : profileurs (Nsight Systems, Nsight Compute), débogueur graphique, bibliothèques mathématiques (cuBLAS, cuDNN) maintenues depuis quinze ans, intégrations IDE : tout l’attirail qui transforme un travail d’optimisation kernel d’une semaine en travail d’une journée. ROCm a un équivalent pour chacune de ces briques (rocBLAS, MIOpen, rocprof), mais la couverture est plus jeune, la documentation plus mince et la communauté Stack Overflow incomparablement plus petite. Quand un ingénieur tape une erreur dans Google, l’asymétrie de résultats est elle-même une partie du verrou.
La deuxième couche est constituée des kernels de pointe co-conçus avec le silicium. FlashAttention, les fused kernels d’attention, les noyaux de matmul micro-tunés pour chaque génération : ils sortent toujours en CUDA d’abord, parce que c’est là que sont les ingénieurs de recherche qui les écrivent et les GPU qui leur servent à mesurer. ROCm récupère ces kernels avec quelques mois de décalage, le temps qu’AMD ou la communauté les porte et les ré-optimise pour la microarchitecture CDNA. Concrètement, un kernel de pointe publié en CUDA en début d’année arrive avec une efficacité comparable sur MI300 quelques mois plus tard, assez vite pour une équipe qui n’a pas besoin du tout dernier kernel, trop tard pour un labo qui pousse l’état de l’art. Avec une réserve : certains kernels sont liés à une microarchitecture précise. FlashAttention-3, par exemple, repose sur des primitives propres à Hopper (TMA, WGMMA, FP8 asynchrone) et n’a pas de portage ROCm de même niveau ; AMD s’aligne sur un équivalent de génération FA-2.
La troisième couche, la plus rigide, ce sont les runtimes propriétaires : TensorRT-LLM et NIM, co-conçus avec le silicium et explicitement réservés à NVIDIA. Là, il ne s’agit plus d’un retard de mois mais d’une absence assumée. AMD ne peut pas combler ce vide en accélérant ROCm : il devrait construire un équivalent fonctionnel, et le promouvoir suffisamment pour qu’il devienne la norme dans la chaîne d’outils des intégrateurs. C’est faisable, c’est un projet de plusieurs années.
C’est précisément ce cumul qui rend la situation intéressante. Un verrou technique se brise avec un bon compilateur. Un verrou d’écosystème se brise avec du temps, des parts de marché et une communauté qui a décidé de migrer. AMD a manifestement choisi cette seconde voie : rendre ROCm omniprésent, du portable au datacenter, financer le port des projets open source et attendre que la base utilisateurs critique apparaisse. Le matériel suit : la prochaine génération Instinct (MI450) est attendue au second semestre 2026, et chaque release qui maintient la parité framework rend le statu quo NVIDIA un peu plus coûteux à justifier pour qui n’a pas de dépendance propriétaire. Et AMD n’est pas seul à pousser : côté TPU, Google attaque le même verrou logiciel en rendant PyTorch natif via TorchTPU.
Comment décider
La décision se joue sur trois questions, prises dans l’ordre.
Votre pile est-elle standard ? Si vous vivez dans PyTorch + vLLM ou SGLang, sans kernels CUDA écrits maison, ROCm est une option crédible, et le matériel AMD haut de gamme est compétitif en mémoire et en débit basse précision FP4 Format à virgule flottante 4 bits, frontière 2026 de l'inférence à haut débit. Quatre fois moins de mémoire que le FP16, mais une portée dynamique très étroite : ne tient qu'avec un scaling fin via formats à blocs (MXFP4, NVFP4). Approfondir dans le glossaire . Le portage demande de vérifier les versions, pas de réécrire le code.
Dépendez-vous d’une brique NVIDIA-only ? Si TensorRT-LLM ou NIM sont dans votre chemin critique (par contrat avec un intégrateur, par exigence de latence p99 obtenue uniquement via leurs kernels propriétaires, ou par dépendance d’une intégration NVIDIA Inception), la question est tranchée avant de la poser.
Quelle est votre tolérance à l’écart de perf ? 10 à 30 % est rédhibitoire à très grande échelle, où ce delta se paie en MW supplémentaires sur la facture mensuelle. Le même delta est négligeable pour une charge modérée où la disponibilité du matériel et le prix à l’achat comptent davantage, et où un MI300X livré en six semaines vaut mieux qu’un H100 promis pour le trimestre suivant.
Conclusion
La question intéressante n’est plus « ROCm peut-il rattraper CUDA », mais « quand cet écart cessera-t-il de justifier la prime NVIDIA ». Au rythme actuel (release ROCm tous les trois mois, parité framework déjà acquise, MI450 attendu pour le second semestre), la fenêtre où un acheteur peut encore choisir AMD purement sur le prix sans concession technique se rétrécit dans l’autre sens : c’est l’écart de prix qui devient l’argument, plus la performance qui devient l’objection. De notre point de vue, l’arbitrage à surveiller en 2026 n’est pas logiciel ; il est dans la livrabilité du matériel et dans la solidité des contrats d’approvisionnement.
Pour la comparaison côté silicium, voir MI355X vs B200/B300.
Sources et méthode
Versions : notes de version CUDA Toolkit et notes de version ROCm, consultées le 14 mai 2026. Parité framework et support ROCm de vLLM/SGLang/llama.cpp : documentation publique des projets concernés et de ROCm pour l’IA. L’écart de performance « ~10–30 % » est une estimation crédible synthétisée à partir de comparatifs publics 2025–2026 (Spheron, Thunder Compute) : il dépend fortement de la charge et de la maturité des kernels, et n’a pas valeur de mesure absolue. Calendrier MI450 : communications publiques AMD, 2026.
