NVIDIA face aux ASIC custom — ce que TPU, Trainium et MTIA font vraiment (et pourquoi la plupart visent l'inférence, pas le training)

Le bull case sur $NVDA c'est « CUDA défend ». Le bear case c'est « les ASIC custom bouffent ». Les deux ont raison à différentes couches de la stack. Les ASIC custom bouffent de la part — sur des workloads spécifiques, dans des patterns de déploiement spécifiques, avec des profils économiques spécifiques. Ils ne bouffent pas (encore) la partie du workload IA qui drive le carnet de commandes de $NVDA.

Comprendre lequel est lequel exige de décomposer ce que chaque grand programme ASIC custom fait réellement. La plupart des takes de traders publiés regroupent les quatre comme « silicium custom » et traitent la catégorie comme un seul concurrent. La catégorie est hétérogène : TPU et Trainium-le-flagship sont dual-purpose training-et-inférence, MTIA et Maia et Inferentia et le reste de la famille Trainium ciblent l'inférence. La distinction c'est là où le bear case a du mordant et là où il n'en a pas.

Cet article cartographie chaque programme majeur, à quel workload il est réellement déployé, et comment lire les disclosures.

Pourquoi le training est différent de l'inférence

La première étape de toute évaluation silicium custom c'est de séparer le compute IA en deux régimes :

Training — runs à grande échelle, multi-semaines, multi-milliards de dollars sur des clusters de milliers de GPU. Le workload est dynamique (le paysage de perte change, les hyperparamètres sont tunés, le mix kernel shifte à mesure que le modèle converge), l'architecture du modèle évolue (de nouvelles variantes d'attention, de nouveaux optimiseurs, de nouvelles fonctions d'activation sont testés chaque semaine dans les labs frontière), et les modes de défaillance sont subtils (un seul bit-flip dans un gradient de paramètre peut corrompre le run). La stack software doit être flexible, debuggable et extensible. C'est là que la stack de librairies CUDA — cuDNN, NCCL, l'outillage kernel — capitalise depuis 15 ans. Le silicium custom pour le training est difficile parce que le substrat doit suivre une cible mouvante.

Inférence — serving en production de modèles entraînés. Le workload est statique (l'architecture du modèle est gelée, les poids sont chargés une fois), les kernels sont connus à l'avance (vous optimisez une fois, déployez pour la durée de vie de serving du modèle), et la cible d'optimisation des coûts c'est le throughput-par-watt et la latence-par-token. C'est là que le silicium custom a le case économique le plus fort — un modèle à architecture fixe qui tourne 24/7 n'a pas besoin de la flexibilité CUDA complète ; il a besoin du silicium le moins cher possible qui fait tourner cette forme spécifique de calcul efficacement.

Les maths économiques :

• Le spend training chez un hyperscaler est ~25-30% du capex compute IA
• Le spend inférence est ~70-75%, en croissance à mesure que le nombre de modèles déployés grandit
• Le silicium custom cible majoritairement le pool inférence plus gros et plus facile à attaquer

C'est pourquoi le « silicium custom hyperscaler » doit être lu au niveau workload, pas au niveau programme.

Google TPU — la success story du training

Google a commencé le développement TPU en 2013, déployé TPU v1 en interne en 2015, et l'a annoncé publiquement en 2016 avec un papier à ISCA. L'architecture système est un moteur matmul à systolic-array avec l'interconnect chip-mesh désormais iconique, optimisé d'abord pour l'inférence (TPU v1, v2) puis pour training-et-inférence (v3 et après).

TPU v5e a shippé en 2024. Ironwood (TPU v7) a shippé en 2025. Chaque génération a étendu :

• Parité training à l'échelle. Les runs de training de modèles frontière (Gemini, Claude d'Anthropic sur le pool TPU de Google annoncé en 2024) sur TPU à un throughput proche de NVIDIA. La combinaison compiler XLA + JAX est devenue une alternative crédible à PyTorch + CUDA pour les nouveaux projets de training.
• Dominance inférence pour les workloads internes de Google. Search ranking, prédiction de click-through pour les ads, recommandation YouTube — tout tourne sur TPU à échelle production.
• Disponibilité cloud externe. TPU est vendu sur Google Cloud à un pricing compétitif vs instances NVIDIA sur workloads équivalents.

Pourquoi TPU a réussi là où d'autres ont galéré :

1. Le temps. 10+ ans d'investissement composé dans la stack software (XLA, JAX, orchestration Pathways).
2. Co-design serré modèle-substrat. Les équipes de recherche Google shippent des modèles qui marchent parce qu'ils sont co-designés avec les forces du TPU (gros tiles matmul, sparsité hardware-supportée, l'interconnect chip-mesh).
3. Client interne captif. L'équipe plateforme ML de Google est le premier client. Ils n'ont aucune raison politique de préférer NVIDIA à TPU. La traction interne valide le substrat avant que les clients externes ne le voient.

Le résultat : le spend NVIDIA interne de Google est matériellement plus bas (en fraction du compute interne) que le spend NVIDIA des autres top-4 hyperscalers. TPU est la preuve d'existence qu'un hyperscaler peut internaliser la full-stack. C'est le canari pour le risque de concentration client sur NVDA.

AWS Trainium et Inferentia — le pari inference-first

AWS a commencé avec Inferentia en 2019 — un chip d'inférence pure optimisé pour les modèles type transformer à basse latence et price/perf compétitif. Inferentia 2 (2023) a étendu l'architecture. AWS utilise Inferentia massivement pour les workloads d'inférence internes (Alexa, Rekognition, Comprehend, le service LLM managé Bedrock) et propose les instances EC2 Inf1/Inf2 aux clients externes.

Trainium a lancé en 2020 comme contrepartie training. La première génération était matériellement à la traîne de NVIDIA sur le throughput training ; Trainium2 (2024) a comblé une bonne partie de l'écart sur des workloads spécifiques. Anthropic a annoncé un engagement de capacité Trainium2 majeur en 2024 — le second lab frontière (après le partenariat Google TPU/Anthropic) à s'engager sur du silicium training non-NVIDIA à échelle matérielle.

Le positionnement stratégique :

• AWS optimise Inferentia pour les workloads AWS internes (gros volume, formes de modèle fixes, latency-sensitive).
• Trainium cible les workloads training de clients externes où l'avantage price/perf est assez large pour surmonter la courbe d'apprentissage de la stack software. L'engagement d'Anthropic est le proof point.
• Le SDK Neuron + l'intégration PyTorch AWS est l'effort sur la stack software. Il est derrière CUDA mais devant toute alternative non-Google.

Impact concentration sur NVDA :

• Le spend inférence interne AWS est la ligne la plus vulnérable à NVDA. Inferentia l'absorbe déjà.
• Le spend training interne AWS est partiellement vulnérable à NVDA selon le ramp Trainium2 et le timing Trainium3.
• Le spend NVIDIA des clients AWS Cloud (instances EC2 P-series et G-series) est la partie qui croît avec la demande IA et est structurellement protégée — les clients externes choisissent NVIDIA parce qu'ils ont déjà construit sur CUDA.

Effet net sur le revenu NVDA depuis AWS sur 2026-2028 : probablement flat-à-baisse sur la part interne, hausse sur la demande customer-cloud. L'agrégé est dépendant du mix de workloads et seulement partiellement sous contrôle d'AWS.

Meta MTIA — le programme de rattrapage

Meta a lancé MTIA (Meta Training and Inference Accelerator) v1 en 2023, focalisé inférence à l'origine. MTIA v2 (2024-2025) a ciblé l'inférence à plus grande échelle pour les modèles internes de ad-ranking et content-recommendation de Meta — des workloads qui consomment un compute énorme à des formes de modèle connues, exactement le sweet spot de l'inférence.

Meta a explicitement dit dans les earnings calls que MTIA ne remplacera pas (initialement) NVIDIA pour le training de modèles frontière. La série Llama — la famille LLM frontière de Meta — a entraîné sur H100 et B200 NVIDIA jusqu'en 2025. Le mandat de MTIA c'est le workload recommendation et ad-stack, qui est la plus grosse part du spend compute de Meta mais moins visible en externe.

La menace concurrentielle sur NVDA depuis MTIA :

• Court terme (2025-2026) : matérielle ; Meta absorbe plausiblement 20-30% de son compute inférence interne sur MTIA, ce qui déplace directement du spend NVIDIA à ce workload.
• Moyen terme (2027-2028) : inconnu ; dépend de si MTIA v3 atteint la parité training, ce que Meta n'a pas engagé publiquement. Le substrat de training de Llama 4 / Llama 5 est le signal canonique.
• Long terme (2029+) : si Meta suit le chemin Google, MTIA devient une réduction structurelle du TAM NVDA chez Meta. Si elles le font dépend de la politique interne Meta et de l'allocation capex qui est dure à prévoir.

L'analyse de concentration hyperscaler cadre Meta comme le second hyperscaler le plus probable (après Google) à atteindre « majorité interne sur silicium custom » étant donné la taille et le profil économique de leur workload.

Microsoft Maia — le dernier entrant

Microsoft a annoncé Maia 100 en 2023 et l'a shippé en 2024-2025. L'architecture est purpose-built pour l'inférence transformer à grande échelle, avec un positionnement explicite autour du workload OpenAI-partenaire d'Azure (ChatGPT et serving de modèles downstream).

Maia est le plus jeune des quatre programmes et le moins mature en stack software. Microsoft n'a pas (à mi-2026) divulgué publiquement la capacité Maia en pourcentage du compute IA Azure. Le read directionnel depuis les sources industrielles : Maia absorbe une partie du workload d'inférence interne Azure mais Microsoft reste fortement NVIDIA-dépendant à la fois pour le training (le partenariat OpenAI tourne sur Blackwell NVIDIA à l'échelle) et la majorité de l'inférence client.

La position de Microsoft est structurellement différente de celle de Meta ou d'Amazon :

• Le partenariat OpenAI est un engagement de capacité multi-années sur des workloads training et inférence frontière spécifiques, majoritairement sur NVIDIA.
• Le workload IA client d'Azure est fortement NVIDIA-par-défaut parce que la proposition de vente d'Azure inclut « vous pouvez entraîner sur le même substrat que celui sur lequel vous avez déjà construit » (NVIDIA + CUDA).
• Le chemin de Maia vers une part matérielle est le workload Microsoft-interne uniquement — inférence Office Copilot, Bing AI, features IA Microsoft 365. C'est une part substantielle mais pas majoritaire du spend compute IA de Microsoft.

Read net : Microsoft est le plus lent des quatre hyperscalers sur le silicium custom, ce qui rend Microsoft structurellement NVDA-bullish pour le moyen terme. Le scénario bear pour NVDA chez Microsoft exige que Maia v2 ou v3 ramp significativement en 2027-2028, et Microsoft n'a pas signalé publiquement ce calendrier.

Où ça laisse la thèse NVDA

Les quatre programmes silicium custom hyperscaler, triés par menace concurrentielle sur NVDA :

| Rang | Programme | Statut | Impact NVDA 2026-2028 | |------|-----------|--------|----------------------| | 1 | Google TPU | Mature, training + inférence | Matériel ; le spend NVDA interne Google déjà structurellement réduit | | 2 | AWS Trainium/Inferentia | Inférence mature, training en ramp | Matériel sur l'inférence, partiel sur le training (ramp Trainium2) | | 3 | Meta MTIA | Inférence en scaling, training TBD | Part inférence active ; training neutre jusqu'à 2027 | | 4 | Microsoft Maia | Inférence, stade précoce | Limité ; le partenariat OpenAI maintient le spend NVDA haut |

Oracle n'a pas de programme silicium custom et reste structurellement long NVDA à la fois training et inférence.

Une manière propre de lire le paysage : le TAM NVDA chez les top-4 hyperscalers se bifurque. La part training — protégée par le moat CUDA — reste largement NVDA. La part inférence est plus poreuse et est activement absorbée par le silicium custom, surtout chez Google et AWS. Meta est en milieu de cycle. Microsoft est en retard.

Trois signaux qui forceraient une révision de thèse

1. Un second hyperscaler shippe un papier de training de modèle frontière sur silicium custom. Anthropic sur TPU a été le premier (2024). Si un second lab publie un équivalent sur Trainium, MTIA ou Maia d'ici 2027, la thèse « CUDA défend le training » s'affaiblit. Surveillez les papiers académiques d'Anthropic-sur-Trainium2, Llama-X-sur-MTIA, ou tout lab frontière sur Microsoft Maia.

2. La télémétrie backend PyTorch shifte. Données de part de backend PyTorch publiées par Meta (rarement divulguées) montrant plus de 5% du compute training PyTorch sur des backends non-CUDA. Actuellement estimé sous 3%.

3. Le mix revenu « compute » vs « networking » de NVDA. NVDA divulgue le split chaque trimestre. Si la part compute commence à se compresser pendant que le networking croît (parce que les clients continuent à acheter du fabric Mellanox/InfiniBand pour leurs propres clusters ASIC), c'est le signal précoce que le substrat client shifte loin des GPU NVDA pendant que le networking NVDA reste le fabric par défaut.

Bottom line

Les ASIC custom sont de vrais concurrents à NVDA, mais la surface concurrentielle est inference-first pour trois des quatre programmes. Le training — le workload le plus CUDA-dépendant — reste structurellement NVDA. TPU est l'exception qui confirme la règle : Google a démontré que la migration est possible avec une décennie d'investissement software composé, et le playbook implicite est suivi à profondeurs variables par AWS, Meta et Microsoft.

Le read thèse : long NVDA sur le revenu training et le moat CUDA ; bearish sur la trajectoire de marge à mesure que l'inférence shifte vers le silicium custom chez les top-4 hyperscalers. Net : une compression de multiple multi-année plutôt qu'un décrochage step-function. La contrainte côté supply borne le ramp peu importe. La concentration client est la variable qui détermine où dans cette bande l'action s'imprime.

---

Dashboard NVDA sur QuantAbundancia — panneau thèse avec les marks actuels.

Le moat CUDA — l'écosystème software qui défend le training mais fuit sur l'inférence.

Le bottleneck HBM de NVIDIA — le plafond côté supply qui borne le ramp peu importe la composition client.

Concentration client hyperscaler — le risque de concentration côté demande que les ASIC custom sont designés pour exploiter.