TPU vs GPU en 2026 — le vrai face-à-face Ironwood contre Blackwell

En bref

En 2026, deux puces IA dominent le haut du marché des accélérateurs : le TPU v7 Ironwood de Google, annoncé en avril 2025, et le GB200 NVL72 de Nvidia, disponible en production depuis fin 2024. C’est la première fois depuis le H100 (2022) que les deux leaders lancent leurs générations flagship dans la même fenêtre temporelle — ce qui rend possible un face-à-face inédit avec des chiffres comparables.

Le résultat de ce comparatif n’est pas un vainqueur unique. Les deux systèmes ciblent des problèmes différents : Ironwood mise sur l’inférence à très grande échelle dans des pods de 9 216 chips ; GB200 NVL72 optimise l’entraînement flexible en unités de 72 GPU. Le choix dépend du cas d’usage, de l’écosystème logiciel maîtrisé, et de l’accès au matériel.

Cet article se concentre sur le face-à-face 2025-2026. Pour le profil détaillé de chaque acteur, voir TPU Google et GPU Nvidia et CUDA.

Comprendre le problème : pourquoi 2026 est l’année du comparatif

Imaginez deux routes construites pour transporter des marchandises différentes. La première est une autoroute à voies multiples, conçue pour les convois réguliers et prévisibles — elle est rapide mais ne peut pas faire demi-tour. La seconde est un réseau routier polyvalent, moins optimisé pour chaque type de véhicule, mais capable de s’adapter à n’importe quel trajet. Les TPU sont la première route, les GPU la seconde.

Deux feuilles de route convergent simultanément en 2025-2026 :

• Côté Nvidia : l’architecture Blackwell (B100, B200, GB200 NVL72) est disponible en production depuis fin 2024. Le GB200 NVL72 — 72 GPU B200 interconnectés dans un rack liquide-refroidi de 120 kW — est le système de référence pour l’entraînement de modèles frontier.
• Côté Google : TPU v7 Ironwood annoncé en avril 2025, disponibilité générale prévue fin 2025-début 2026. Premier TPU conçu explicitement pour “l’ère de l’inférence” (source : blog.google, avril 2025).

Un catalyseur externe donne à ce face-à-face une dimension concrète : Gemini 2.5 est entraîné entièrement sur TPU (v5p selon SemiAnalysis) ; Anthropic a signé un contrat massif de ~400 000 TPU v7 achetés et 600 000 loués via GCP, ciblant ~1 GW de capacité de calcul (source : SemiAnalysis 2025). Ces décisions de déploiement industriel, prises par des acteurs qui ont comparé les deux options, sont des signaux forts sur la valeur respective des deux architectures.

En clair : pour la première fois depuis 2022, Google et Nvidia ont des puces flagship comparables à la même date. Ce synchronisme permet un face-à-face sur des chiffres contemporains plutôt que sur des générations décalées.

Architectures — Systolic Array contre SIMT

TPU Ironwood : le flux synchronisé à double chiplet

Le cœur du TPU est le systolic array : une grille de MACs (unités multiply-accumulate) où les données circulent de cellule en cellule sans rechargement mémoire entre chaque opération. Pensez à une chaîne de montage où chaque ouvrier reçoit une pièce du voisin, fait son travail, et la passe au suivant — sans jamais aller chercher lui-même les matériaux.

TPU v7 Ironwood franchit une étape architecturale en adoptant une conception dual-chiplet : 2 chiplets par puce, chacun intégrant un TensorCore, deux SparseCores et 96 Go de HBM3e. Le bus die-to-die (D2D) qui les relie est 6× plus rapide qu’un lien ICI (inter-chip interconnect) standard (source : docs.cloud.google.com).

Les SparseCores (introduits en TPU v4) gèrent les opérations sur embeddings épars — les tables de lookup des modèles de recommandation — avec des gains mesurés de 5-7× sur ces charges spécifiques (Jouppi et al., ISCA 2023).

Vocabulaire

• Systolic array : grille de processeurs simples où les données circulent de voisin en voisin sans accès mémoire central. Très efficace sur des flux prévisibles.
• MACs (multiply-accumulate units) : l’opération de base des réseaux de neurones — multiplier deux nombres et ajouter le résultat à un accumulateur.
• HBM3e (High Bandwidth Memory) : type de mémoire empilée verticalement sur la puce, offrant des bandes passantes 5-10× supérieures à la DDR classique.
• ICI (Inter-Chip Interconnect) : lien haute vitesse reliant les chips TPU entre eux dans un pod.

En clair : le TPU Ironwood est une usine ultra-spécialisée — elle traite des flux de calcul réguliers à vitesse record, mais se montre moins à l’aise face à des graphes de calcul dynamiques ou des opérations irrégulières.

GPU GB200 : le réseau flexible de 72 processeurs

Le GPU (Single Instruction Multiple Threads) exécute des milliers de threads en parallèle, chacun pouvant prendre des chemins d’exécution différents. Cette flexibilité est la fondation de l’écosystème CUDA — contrairement à l’autoroute TPU, le réseau routier GPU peut adapter son chemin à chaque requête.

Le Blackwell B200 adopte une architecture multi-die : deux puces reliées par un bus interne à 10 To/s chip-to-chip. Le GB200 NVL72 connecte 72 B200 via NVLink 5.0 (1,8 TB/s) en topologie all-to-all dans un rack liquide-refroidi de 120 kW (source : nvidia.com/gb200-nvl72, 2024).

Le Transformer Engine (intégré depuis Hopper, version 2 sur Blackwell) est une unité dédiée qui bascule automatiquement entre FP8, FP4 et précisions supérieures selon les besoins de chaque couche du modèle. C’est un mécanisme d’adaptation dynamique que le systolic array TPU, fixe par nature, ne peut pas reproduire tel quel.

En clair : le GB200 NVL72 est un réseau de 72 processeurs polyvalents capables de s’adapter à des architectures de modèles variées. Sa flexibilité a un coût : il n’est pas aussi optimisé que le TPU sur des flux prévisibles, mais il excelle là où le workload évolue souvent.

Interconnect : tore 3D contre NVLink — les règles du jeu changent à l’échelle

C’est ici que les deux systèmes divergent le plus fortement, et que le choix d’architecture devient stratégique.

NVLink offre 1,8 TB/s par lien contre 1,2 TB/s ICI — Nvidia a l’avantage par lien individuel. Mais Google connecte 9 216 chips dans un seul domaine cohérent, contre 72 GPU pour le NVL72. Pour les très grands modèles (au-delà de 1 000 milliards de paramètres), la topologie TPU permet des combinaisons de parallélisme — données, séquence, tenseurs, pipelines — qui sont physiquement inaccessibles sur un NVL72 (source : SemiAnalysis, “TPUv7 The 900lb Gorilla”, 2025).

La bande passante agrégée d’un pod Ironwood complet (9 216 chips) atteint 42,5 ExaFLOPS en FP8 (source : blog.google, avril 2025). Un pod GPU Nvidia en configuration équivalente impliquerait ~128 NVL72, connectés par InfiniBand — avec les latences et la gestion de topologie que cela implique.

En clair : Nvidia gagne sur la bande passante par lien individuel, Google gagne sur l’échelle maximale dans un domaine cohérent. Pour entraîner un modèle de 70B paramètres, les deux systèmes fonctionnent bien. Pour entraîner un modèle de 10 000 milliards de paramètres, le pod TPU offre une cohérence d’interconnect que NVL72 ne peut pas reproduire sans solutions InfiniBand supplémentaires.

Feuilles de route 2024-2026 — Génération par génération

Google TPU : de v5 à Ironwood

Sources : docs.cloud.google.com, cloud.google.com/blog (Trillium GA), blog.google (Ironwood avril 2025).

Le saut Ironwood est spectaculaire : la progression TPU v5e→v7 représente ~23× en FP8 TOPS, 6× en HBM et 4,6× en bande passante mémoire. Google revendique 2× perf/watt vs Trillium et 10× vs v5p [vendor claim — non confirmé indépendamment à ce stade].

Mise à jour de septembre 2026 — la huitième génération est annoncée, et elle se dédouble. Google abandonne la puce unique et annonce deux architectures distinctes : le TPU 8t pour l’entraînement et le TPU 8i pour l’inférence.

Les deux puces sont annoncées à « jusqu’à 2× la performance par watt » d’Ironwood, et à une disponibilité générale « plus tard dans l’année ». [vendor claim — aucune de ces valeurs n’est validée par un banc tiers à ce jour]

En clair : le fait marquant n’est pas le gain de performance, c’est la séparation. Après sept générations de puce unique, Google admet qu’entraîner et servir ne sont plus le même métier — exactement la thèse qu’Ironwood portait déjà en se déclarant « inférence-first », mais désormais gravée dans deux silicium différents. Nvidia continue, lui, de vendre une puce qui fait les deux.

Nvidia : de H100 à GB200

Sources : nvidia.com Blackwell whitepaper 2024, developer.nvidia.com.

Point de croisement 2025 : Ironwood (4 614 TOPS FP8) dépasse le B200 standalone (4 500 TOPS) mais reste en dessous du GB200 (~5 000 TOPS). Ces chiffres sont tous issus de vendors et n’ont pas encore été validés par des benchmarks tiers indépendants pour Ironwood.

En clair : sur les specs chip-à-chip, Ironwood et B200 sont dans le même ordre de grandeur en 2025-2026. La différence se joue à l’échelle (9 216 vs 72), dans l’écosystème logiciel, et dans l’accès au matériel.

Benchmarks MLPerf — Ce que les données indépendantes montrent

Les benchmarks MLPerf (publiés par MLCommons) sont les seules références comparatives indépendantes du secteur. Il est important de noter leurs limites : Google et Nvidia choisissent les configurations qu’ils soumettent, et les résultats reflètent autant l’optimisation logicielle que le matériel lui-même.

MLPerf Training v4.1 — novembre 2024

Premier round officiel incluant Google Trillium (TPU v6e).

• Configuration Google soumise : 2× 256-pod Trillium (2 048 chips)
• Résultat GPT-3 175B : Trillium ~27,6 min vs TPU v5p ~29,6 min sur 2 048 chips — gain ~8%
• Scaling efficiency Trillium : 99% (contre 94% pour v5p) — la puce est quasi-linéaire à l’échelle (source : cloud.google.com Trillium MLPerf 4.1)
• Perf/dollar Trillium : 1,8× vs v5p (soit ~45% de réduction du coût d’entraînement selon Google) [vendor claim]

Sur ce même round, Nvidia H100/H200 tient les temps absolus les plus courts à nombre d’accélérateurs équivalent — l’avantage Nvidia en vitesse brute reste structurel pour GPT-3 (source : analyse xpu.pub novembre 2024).

MLPerf Training v5.0 — juin 2025

Changement majeur : GPT-3 175B est remplacé par Llama 3.1 405B comme benchmark phare, reflétant l’évolution des workloads réels vers les grands modèles denses.

Résultats clés (source : MLCommons juin 2025) :

• 201 résultats de 20 organisations — record absolu de participation
• Matériels présents : AMD MI300X/MI325X, Nvidia B200 et GB200, Google Trillium
• Nvidia est le seul soumissionnaire présent sur tous les benchmarks, y compris Llama 3.1 405B
• Améliorations inter-génération (v4.1 → v5.0) : +2,28× sur Stable Diffusion 8-GPU, +2,10× sur Llama 2 70B LoRA, +3,68× sur Stable Diffusion multi-nœuds

GAP important : les chiffres granulaires TPU vs GPU sur Llama 3.1 405B en MLPerf v5.0 n’étaient pas publiquement disponibles au moment de la rédaction de cet article. MLCommons a confirmé la présence de Trillium mais les performances détaillées n’ont pas encore été publiées au niveau requis pour une comparaison directe.

GAP Ironwood : TPU v7 Ironwood n’a pas encore soumis en MLPerf à la date de rédaction (avril 2026). La soumission est attendue pour 2026. Toute comparaison Ironwood vs GB200 repose donc sur des specs vendor, pas sur des benchmarks indépendants.

MLPerf Inference v5.0 — avril 2025

• Nvidia Blackwell (B200/GB200) présent avec des gains significatifs inter-génération (source : developer.nvidia.com)
• Google TPU non listé en inference MLPerf v5.0

Pour l’inférence, la référence indépendante disponible est le benchmark Artificial Analysis (Llama 3.3 70B, framework vLLM) :

Mise en garde critique : ce chiffre de 5× de désavantage pour Trillium doit être interprété avec précaution. Lucas Beyer (Google Research) note que Google ne sert pas ses workloads de production via vLLM-TPU — le framework vLLM a reçu beaucoup moins d’optimisation pour TPU que pour GPU. Ce benchmark mesure “vLLM non-optimisé sur Trillium”, pas le plafond de l’architecture TPU en inférence. En production, Google utilise ses propres piles d’inférence (JAX/MaxText sur AI Hypercomputer), non mesurées dans ce benchmark.

En clair : les benchmarks MLPerf disponibles à mi-2026 montrent que Trillium rivalise avec les GPU Nvidia en entraînement à grande échelle, avec un léger avantage en scaling efficiency. En inférence, les données indépendantes restent limitées — et les comparaisons vLLM désavantagent structurellement les TPU dont l’écosystème d’inférence n’est pas encore maturé hors de Google.

Écosystème logiciel — Le vrai différenciateur

Si les specs matérielles sont comparables, c’est l’écosystème logiciel qui détermine le choix pour la quasi-totalité des équipes n’appartenant pas à Google.

CUDA : vingt ans d’accumulation impossible à reproduire

CUDA représente un fossé qui va bien au-delà du matériel : 4 millions de développeurs formés, plus de 3 000 applications compatibles, des bibliothèques hautement optimisées (cuBLAS, cuDNN, NCCL, TensorRT). Les frameworks majeurs (PyTorch, TensorFlow, JAX) peuvent tous tourner sur CUDA.

Pour une équipe ML en 2026, démarrer sur GPU signifie : code PyTorch standard, tutorials disponibles, 95% des papers publiés avec du code CUDA/PyTorch reproductible.

JAX/XLA : le chemin natif TPU

JAX + XLA est le chemin d’exécution natif sur TPU. La compilation XLA fusionne les opérateurs et optimise les accès mémoire de façon statique — contrairement aux GPU CUDA où le JIT compiler optimise dynamiquement.

Ironwood (TPU v7) rompt avec TensorFlow : TensorFlow n’est pas supporté sur v7. Seuls JAX et PyTorch/XLA sont supportés (source : docs.cloud.google.com/tpu/docs/tpu7x). Pour les équipes habituées à TensorFlow, c’est une migration supplémentaire.

Pallas (2024-2025) est le nouveau langage de kernels Google pour TPU, analogue à Triton pour GPU. Il permet d’écrire des kernels custom directement en Python, réduisant la dépendance aux kernels XLA pré-compilés.

Convergence en cours (2025-2026)

Deux évolutions réduisent le fossé logiciel :

1. vLLM-TPU redesign (octobre 2025) : JAX devient le chemin de lowering unifié pour tous les modèles vLLM sur TPU, qu’ils soient définis en PyTorch ou JAX (source : blog.vllm.ai, octobre 2025). Cette refonte réduit significativement la friction PyTorch→TPU pour l’inférence.

2. PyTorch/XLA : le support PyTorch sur TPU s’améliore session après session. La plupart des opérations PyTorch standard fonctionnent désormais via ce bridge.

Gap structurel qui persiste : XLA:TPU compiler et MegaScaler (orchestration multi-pod) restent propriétaires (SemiAnalysis 2025). L’open-sourcing de ces composants accélérerait l’adoption externe — ce choix reste entre les mains de Google.

Tableau synthèse écosystème

En clair : si votre équipe travaille en PyTorch et suit des papers académiques, le GPU est le choix naturel en 2026. Si vous travaillez dans l’écosystème Google (GCP, JAX, MaxText) ou que vous êtes prêt à investir dans la transition, Ironwood offre des avantages à grande échelle.

Qui utilise quoi en 2026 — Les décisions réelles

Google : TPU partout, sauf chez ses clients on-prem

• Gemini 2.5 : entraîné sur TPU v5p principalement (source : SemiAnalysis 2025)
• Gemini 3 : Ironwood TPU selon IntuitionLabs (2025) [source secondaire — non confirmée officiellement par Google]
• Inférence Gemini : via AI Hypercomputer + JAX/MaxText, sur TPU
• Exception notable : Gemini 2.5 sur Google Distributed Cloud (déploiements on-prem enterprise) tourne sur Nvidia Blackwell GPU (source : Data Center Dynamics, wionews.com 2025). Logique économique : les clients enterprise n’ont pas accès aux pods TPU — ils achètent du matériel livrable.

Frontier labs hors Google

• Anthropic : contrat massif signé TPU v7 Ironwood (~1M chips au total, achetés + loués via GCP) selon SemiAnalysis 2025. Pivot partiel depuis AWS Trainium en cours.
• OpenAI : Nvidia exclusif (H100/B200). SemiAnalysis note qu’OpenAI a obtenu ~30% de réduction tarifaire sur sa flotte Nvidia du seul fait de la menace compétitive TPU — signe que le levier de négociation est réel.
• Meta : GPU (H100/H200/B200) + AMD MI300X pour Llama 405B en inférence. Aucun déploiement TPU en production connu.
• Mistral, Cohere, startups : GPU via cloud providers (H100/H200). Pas de TPU.

Patterns d’usage émergents

L’inférence à grande échelle est le segment où les ASICs sur mesure (TPU, Trainium, Inferentia) ont l’avantage économique le plus clair : topologie fixe, possibilité de spécialiser chaque composant. L’entraînement de nouvelles architectures reste dominé par les GPU, grâce à la flexibilité CUDA et à l’écosystème de recherche (papers publiés en PyTorch/CUDA).

Coûts cloud — Ce que les prix disent du positionnement

Google revendique un coût d’entraînement TPU 40-60% inférieur au GPU [vendor claim — non confirmé indépendamment] et un TCO 30-44% plus faible que GB200 selon SemiAnalysis (source payante, accès partiel).

Le GB200 est le cas extrême : jusqu’à $21,53/GPU/heure, soit ~$1 550/heure pour un NVL72 complet. Ce positionnement tarifaire reflète son positionnement — formation de modèles frontier, pas inférence standard.

En clair : Trillium est le moins cher par chip en catalogue public. Ironwood n’a pas encore de tarif annoncé. GB200 est le plus cher par GPU mais aussi le plus capable pour les grands entraînements. La comparaison coût/performance réelle dépend du workload et de l’optimisation logicielle — les claims vendor sont à prendre avec précaution.

Matrice de décision — Choisir en 2026

Règles heuristiques

1. Si vous n’êtes pas déjà sur GCP/JAX, le coût de migration vers TPU est élevé — l’avantage économique potentiel doit être calculé en incluant la refonte logicielle.
2. La comparaison perf/watt vendor est incomparable : Google revendique 2× perf/watt pour Ironwood vs Trillium [vendor claim]. Nvidia revendique “25× H100 à même puissance” pour GB200 [vendor claim]. Ces chiffres ne sont pas validés par des tiers indépendants.
3. L’absence d’Ironwood en MLPerf (en avril 2026) est un gap réel — toute décision d’achat sur Ironwood repose sur specs vendor sans validation benchmark indépendante.
4. Pour les très grands clusters, la topologie compte plus que les TOPS/chip : 9 216 chips en tore 3D cohérent vs 9 216 chips en InfiniBand sont deux environnements de parallélisme fondamentalement différents.