Le moat CUDA — pourquoi l'écosystème software de NVIDIA défend le monopole hardware longtemps après qu'AMD ait rattrapé

La thèse short standard sur $NVDA dit : AMD livre MI300X, puis MI350X, puis MI400 entre 2024-2027, le gap hardware se ferme, les marges brutes 75 % de NVIDIA se compriment, l'action se déprate. La thèse existe depuis 2023. AMD a, de fait, livré chacune de ces pièces à peu près dans les temps. Les marges brutes de NVIDIA sont toujours à ~75 %. Le revenu GPU data-center d'AMD reste environ un dixième de celui de NVIDIA malgré la livraison d'un silicium qui benchmark compétitif sur les FLOPs bruts.

La thèse bear a vu juste sur le hardware et raté tout le reste. Le vrai moat — celui sur lequel vous êtes long quand vous êtes long NVDA — c'est CUDA : un écosystème software de 19 ans qui transforme les puces de NVIDIA en substrat par défaut contre lequel chaque modèle IA est écrit, pas juste dessus. Cet article c'est à quoi ressemble ce moat au niveau technique, pourquoi migrer hors de lui coûte plus que les puces, et ce qui le casserait vraiment.

Ce qu'est vraiment CUDA

Quand quelqu'un dit « CUDA » dans une conversation de trader il veut généralement dire « l'API que tournent les GPU de NVIDIA ». C'est faux d'environ trois couches. CUDA c'est un stack :

Couche 1 — le driver et le runtime. L'interface OS bas niveau qui permet à un process de parler à la mémoire GPU et de soumettre des kernels de compute. AMD a un équivalent fonctionnel (runtime ROCm, anciennement HSA). Cette couche est résolue.

Couche 2 — le langage de kernel et le compilateur. CUDA C++ est le langage ; nvcc le compile en PTX (la représentation intermédiaire de NVIDIA) puis en SASS (code machine). Triton est un langage de kernel embedded Python plus haut niveau que NVIDIA a acquis indirectement via la release open-source d'OpenAI et intégré. AMD a HIP (un langage source-compatible CUDA) et un compilateur HIP→ROCm. La compatibilité est au niveau source mais pas toujours au niveau comportement — des régressions de performance de 20-40 % sur des kernels identiques sont routinières quand on porte de CUDA à HIP.

Couche 3 — le stack de bibliothèques hand-tunées. C'est là que le moat vit réellement :

• cuDNN — les primitives de convolution et d'attention hand-optimisées de NVIDIA. Chaque framework majeur appelle cuDNN pour les boucles internes de chaque transformer, chaque modèle de diffusion, chaque système de recommandation.
• NCCL — communication collective multi-GPU. La bibliothèque qui fait que 8 GPUs dans un serveur, puis 8 serveurs dans un rack, puis 32 racks dans un pod ressemblent à une seule machine pour PyTorch. NCCL a été optimisée contre l'interconnect de NVIDIA (NVLink, NVSwitch, InfiniBand) depuis une décennie. RCCL d'AMD est fonctionnel mais matériellement plus lent sur la même topologie de fabric.
• cuBLAS — algèbre linéaire dense. Les primitives GEMM (multiplication matricielle) qui drivent la boucle interne de l'attention, des MLPs, et des kernels de convolution. cuBLAS a été tuné par architecture (Volta, Turing, Ampere, Hopper, Blackwell) par une équipe qui ne fait rien d'autre.
• CUTLASS — bibliothèque de templates CUDA open-source pour les kernels GEMM et conv. L'implémentation de référence pour « comment j'écris un kernel custom qui atteint 95 % du peak sur une architecture NVIDIA donnée ».
• cuFFT, cuSPARSE, cuRAND, cuSOLVER, Thrust — et 15 bibliothèques domaine-spécifiques de plus qui n'ont aucun équivalent côté AMD, ou ont des équivalents en retard de trois ans.

Couche 4 — les intégrations frameworks. PyTorch, JAX, TensorFlow, vLLM, TensorRT-LLM, DeepSpeed, Megatron-LM, FlashAttention, xFormers, BitsAndBytes — chaque framework ou bibliothèque de kernel dont vous avez entendu parler est CUDA-first. La voie AMD/ROCm est un port maintenu par une équipe plus petite, souvent une release en retard, parfois cassé sur la dernière release de modèle.

Couche 5 — le tooling. Nsight Systems, Nsight Compute, CUDA-GDB, la suite profiler. Les outils qu'un engineer ML utilise pour comprendre pourquoi son kernel est 30 % plus lent que le peak et le fixer. AMD a des équivalents (rocprof, ROCm-GDB) qui marchent mais sont en retard en capacité.

Couche 6 — l'écosystème. Dix-huit ans de réponses Stack Overflow, d'issues GitHub, de forums développeurs NVIDIA, de cours CUDA universitaires, des tutoriels GTC de NVIDIA elle-même. Quand un doctorant rejoint un labo de recherche en 2026 et apprend la programmation GPU, il apprend CUDA. ROCm est une note de bas de page dans le même curriculum s'il apparaît du tout.

Quand AMD ou Google ou Amazon est en concurrence sur le hardware, ils sont en concurrence avec la Couche 1 et (surtout) la Couche 2. Le moat ce sont les Couches 3-6.

Pourquoi le coût de migration compte plus que le prix de la puce

Un hyperscaler qui achète un H100 à 30 000$ ne paie pas 30 000$ pour du silicium. Il paie 30 000$ parce que le reste de son stack — le framework de training, le runtime d'inférence, le format de checkpoint de modèle, la bibliothèque de kernel, le tooling de monitoring, l'équipe qui sait debugger un kernel CUDA — est tout en CUDA. Le coût de migration pour sortir NVIDIA du data center c'est :

1. Revalider le zoo de modèles. Un hyperscaler fait tourner des centaines de modèles internes — search, ads, recommandations, modération de contenu, génératif — chacun tuné pour tourner optimalement sur H100/H200/B200. Porter chacun vers ROCm ou un ASIC custom veut dire revalider l'équivalence numérique (le modèle produit-il le même output bit-équivalent ? sinon, est-ce que la divergence importe pour la métrique ?), refaire tourner les A/B tests, et accepter un risque non-nul de régression sur un système en production. Le coût d'engineering par modèle majeur est multi-trimestriel.

2. Réécrire les kernels custom. Chaque hyperscaler a des kernels internes de fused-attention ou MoE-routing écrits en CUDA. Les porter vers HIP marche en théorie ; en pratique la régression de performance sur le port est assez large pour que l'équipe réécrive from scratch contre l'architecture CDNA d'AMD, qui a des largeurs SIMD, hiérarchies de cache, et primitives de synchro différentes. Les kernel-engineers CUDA seniors sont un talent pool à 4 chiffres globalement. Les équivalents côté AMD sont plus petits.

3. Re-outiller le stack d'inférence. TensorRT-LLM est le runtime d'inférence optimisé de NVIDIA — quantization-aware, kernel-fused, batching-aware. L'équivalent ROCm (MIGraphX, vLLM-ROCm) est fonctionnel mais en retard. Migrer les budgets de latence d'inférence en production vers AMD veut dire accepter (initialement) une tail latency plus haute ou faire tourner plus de silicium pour compenser.

4. Former l'équipe. Les ML platform engineers connaissent CUDA. Passer à ROCm ou custom-ASIC veut dire une courbe d'apprentissage de 6-12 mois par engineer plus un marché du recrutement où le talent AMD-expérimenté commande une prime et est plus dur à trouver.

Le coût cumulé est dans les mi-9 chiffres pour un hyperscaler top-5 pour migrer complètement hors de CUDA, avec un planning projet de 2-3 ans. C'est si la destination est totalement prête, ce qui sur ROCm n'est typiquement pas le cas. C'est pour ça que les achats AMD des hyperscalers sont concentrés sur des workloads spécifiques où le coût de migration a déjà été payé (inférence pour des modèles OSS spécifiques, certaines simulations HPC) plutôt qu'à travers le board.

Quand NVIDIA price H100/H200/B200 à 70-80 % de marge brute, ils pricent contre le coût de migration de l'autre côté, pas contre le BOM par puce d'AMD. Tant que le coût de migration reste au nord de « acheter plus de puces NVIDIA à pricing premium », le moat tient.

Ce qui est en train d'éroder le moat

Le moat CUDA est réel mais pas éternel. Trois choses l'érodent activement :

1. PyTorch 2.x et torch.compile. PyTorch est le framework dans lequel se fait le plus de travail ML. Historiquement PyTorch était étroitement lié à CUDA via la couche extension C++. PyTorch 2.0 (sorti 2023) a introduit torch.compile, un compilateur JIT qui cible plusieurs backends (Inductor → Triton → CUDA, mais aussi → ROCm, aussi → IRs custom). Le shift architectural c'est que l'utilisateur écrit du PyTorch pur et le compilateur émet du code backend-spécifique. À mesure que torch.compile mûrit et que le backend Inductor est battle-tested sur ROCm et silicium AMD, le lock-in au niveau framework vers CUDA s'affaiblit. C'est un process de 2-4 ans.

2. vLLM et la standardisation de l'inférence. vLLM a émergé comme le runtime d'inférence open-source de facto en 2023-2024 pour le serving LLM. Il supporte CUDA, ROCm, et les ASICs custom via une architecture plugin. À mesure que plus d'inférence hyperscaler bouge vers des runtimes style vLLM (ce qui arrive), le côté inférence de la dépendance framework de CUDA s'érode. Le training est toujours lock dans des frameworks CUDA-first ; l'inférence est incrémentalement portable.

3. Triton. OpenAI a sorti Triton en 2021 comme langage de kernel embedded Python plus haut niveau. La promesse : écrire un kernel une fois en Triton, compiler vers CUDA ou ROCm ou autres backends. En pratique le backend CUDA de Triton est excellent, le backend ROCm est réel mais en retard, et les autres backends sont expérimentaux. NVIDIA a coopté Triton dans le stack CUDA (c'est maintenant un projet CUDA-first même s'il est notionnellement portable). Si Triton reste multi-backend en pratique, le lock-in au niveau kernel s'affaiblit. Si NVIDIA le capture pleinement, Triton devient une autre bibliothèque CUDA.

L'effet combiné : le coût de migration pour qu'un hyperscaler sorte NVIDIA décroît de ~10-20 % par an sur une base de mi-9 chiffres. Le moat se corrode du haut (couche framework) vers le bas (couche kernel). Le lock-in couche-bibliothèque (cuDNN, NCCL) est le plus dur à éroder — c'est encore à 5+ ans d'une vraie parité.

Ce que ça veut dire pour le bear case NVDA

Le bear case a trois jambes traditionnelles :

1. Concurrence hardware — AMD et les ASICs livrent un meilleur silicium, les marges se compriment.
2. Concentration client — les top 5 clients sont ~50 % du revenu ; l'un d'eux in-house et le multiple se comprime.
3. Offre HBM — l'oligopole mémoire coréen limite le ramp peu importe le carnet de commandes de NVDA.

Le moat CUDA défend directement contre la jambe 1 et retarde indirectement l'impact de la jambe 2 (parce qu'un ASIC in-house doit quand même passer le coût de migration CUDA, qui est un projet de 2-3 ans avant de pouvoir remplacer pleinement la dépense NVIDIA). Il ne fait rien contre la jambe 3 — voir l'analyse du bottleneck HBM et le dashboard de la bulle mémoire pour la dépendance côté offre qu'aucun moat software ne peut fixer.

Donc le bear case actionnable sur NVDA ce n'est pas « AMD va rattraper » — cette thèse a été fausse pendant trois ans et le moat CUDA explique pourquoi. Les bear cases actionnables sont :

• L'offre HBM plafonne le ramp à un niveau plus bas que le carnet de commandes l'implique (réel mais déjà partiellement pricé)
• Un ASIC custom chez un seul hyperscaler fait baisser sa dépense NVIDIA de 30 %+ en 18 mois (Google l'a fait avec TPU pour les workloads internes ; la question c'est si Microsoft/AWS/Meta répliquent à l'échelle)
• Une vraie abstraction au niveau PyTorch gagne et le coût de migration se comprime sous le premium de puce que NVIDIA charge (timeline 2027-2029 si jamais)

Trois choses à surveiller

Le moat CUDA est la variable unique la plus importante de la thèse NVDA. Trois signaux qui voudraient dire qu'il s'érode plus vite que pricé :

1. Données de part backend PyTorch. Télémétrie PyTorch anonymisée (que Meta publie irrégulièrement) montrant quelle fraction de training de modèles se fait sur les backends ROCm vs CUDA vs custom-ASIC. Si ROCm dépasse 10 % du compute training PyTorch, le moat se corrode. Actuellement estimé sous 3 %.

2. Langage des 10-K hyperscalers. Microsoft, Meta, Google, Amazon divulguent leur capex IA mais break out rarement la part NVIDIA vs custom. Surveillez les shifts de langage dans les 10-Ks et les earnings calls — « diversifier notre substrat de compute IA » est l'indicateur avancé. Quand deux des top quatre le disent dans le même trimestre, le moat s'érode visiblement.

3. Benchmarks MI400 d'AMD ou successeur Instinct sur de vrais modèles. Les MI300X d'AMD benchmarkent super sur les workloads synthétiques, moins super sur le zoo de modèles que les hyperscalers font vraiment tourner. Si MI400 (attendu fin 2026) sort avec une vraie story PyTorch — entendre Meta, Microsoft, ou Anthropic publient des papers training de gros modèles dessus à un throughput proche de NVIDIA — la thèse bear sur le hardware a enfin des dents. À date, aucun tel paper n'existe.

Bottom line

CUDA n'est pas une bibliothèque. C'est dix-huit ans d'investissement composé à travers compilateurs, bibliothèques, frameworks, tooling, et les carrières de chaque ML platform engineer du domaine. AMD a livré du silicium compétitif depuis 2023 et a capturé environ 10 % du pool de revenu GPU data-center — pas parce que les puces sont mauvaises, mais parce que le coût de migration de CUDA → ROCm excède le différentiel de prix de puce chez chaque hyperscaler qui a vraiment fait le calcul.

Le bon short sur NVDA est supply-constrained (HBM, voir la bulle mémoire) ou customer-concentration-driven (ASIC custom chez l'un des top-5 acheteurs). Le mauvais short — celui qui est faux depuis trois ans — c'est « AMD va rattraper sur le hardware ». Sur le hardware ils l'ont fait. Sur le moat, non.

---

Dashboard NVDA live sur QuantAbundancia — le panneau thèse avec les techniques actuelles, fondamentaux, et le mapping bulles.

Les 12 bulles IA classées par réalité empirique — la taxonomie qui sépare compute, mémoire, custom-silicon, et networking en blocs distincts.

CXMT et la bulle DRAM — le côté offre-mémoire de la contrainte NVDA que le moat CUDA ne peut pas fixer.