TorchTPU, XLA, JAX : comment Google attaque le verrou logiciel de NVIDIA

Pourquoi la vraie bataille de 2026 n’est pas une guerre de FLOPS

Le compute IA est abondamment commenté, mais ses couches logicielles restent rarement expliquées. On parle des puces — Ironwood, Blackwell, Trainium — comme si le silicium se suffisait à lui-même. Le terrain de jeu s’est pourtant déplacé : ce qui décide aujourd’hui de l’adoption d’un accélérateur, ce n’est plus son pic de FLOPS FLOPS Floating-Point Operations Per Second. Métrique brute de débit de calcul flottant, en téra ou péta. Pour l'inférence LLM, c'est rarement le facteur limitant — la bande passante mémoire le devance presque toujours. , c’est la friction qu’un développeur rencontre pour y faire tourner son code PyTorch existant.

Cette friction a un nom et une adresse. Le chemin par défaut du développement IA passe par CUDA CUDA Compute Unified Device Architecture. La plateforme de calcul GPU de NVIDIA — langage, compilateur et bibliothèques (cuBLAS, cuDNN). Son écosystème logiciel est le principal verrou face aux alternatives comme ROCm ; à l'exécution, son « contexte » réserve aussi une part incompressible de VRAM. : la pile de code, les kernels, l’outillage, la mémoire musculaire du débogage à 2 h du matin — tout est natif NVIDIA. C’est un moat logiciel, pas matériel, et c’est exactement lui que Google a entrepris de démonter. La nouveauté de 2026, c’est que Google a cessé de répondre uniquement par du silicium pour répondre par une pile : un framework que les développeurs aiment (PyTorch), un compilateur qui sert de pivot (XLA), un moteur de serving (vLLM) — et, au sommet, un projet nommé TorchTPU dont l’ambition tient en une phrase de l’équipe : « it should feel like PyTorch ».

Ce dossier prend le problème par cette friction. Il s’adresse à deux lecteurs à la fois : l’ingénieur ML qui veut le détail — modèle d’exécution, chemin de compilation, commandes d’installation, chiffres de bench — et le lecteur qui veut le tableau d’ensemble : qui dépend de qui, et pourquoi cela rebat les cartes face à NVIDIA. Chaque brique est expliquée d’abord pour ce qu’elle fait, ensuite pour la place qu’elle occupe dans l’édifice. On commence par la clé de voûte, parce que sans elle rien ne tient : le compilateur.

XLA : le compilateur qui sert de pivot à tout l’édifice

XLA XLA Accelerated Linear Algebra. Compilateur ML qui prend le graphe de calcul entier au lieu d'exécuter chaque opération l'une après l'autre, et le réécrit pour la cible (TPU, GPU, CPU). Sa transformation reine est la fusion : fondre plusieurs opérations en un seul kernel pour ne jamais réécrire les valeurs intermédiaires en mémoire. (Accelerated Linear Algebra) est un compilateur pour le machine learning. Pour comprendre ce qu’il change, il faut voir comment un framework s’exécute sans lui. PyTorch, par défaut, traite chaque opération l’une après l’autre : un kernel pour l’addition, un kernel pour la multiplication, un kernel pour la réduction. Chaque kernel lit ses entrées depuis la mémoire, calcule, et réécrit son résultat en mémoire — où le kernel suivant ira le relire. Sur un accélérateur, ces allers-retours mémoire coûtent bien plus cher que le calcul lui-même.

XLA, lui, ne reçoit pas une opération : il reçoit le graphe entier du calcul, et le réécrit pour la machine cible. Sa transformation reine s’appelle la fusion. Sur l’exemple canonique de la documentation OpenXLA — un calcul du type reduce_sum(x + y * z) —, trois kernels distincts sont lancés sans compilation : un pour la multiplication, un pour l’addition, un pour la réduction. XLA les fond en un seul kernel, et c’est le détail qui décide de tout : il n’écrit jamais les valeurs intermédiaires (y*z, puis x + y*z) en mémoire. Il les fait « ruisseler » directement d’une étape à la suivante en les gardant dans les registres du GPU. La documentation est explicite, et le mérite d’être citée mot pour mot :

Le fonctionnement de XLA tient en une chaîne. Un framework lui livre un graphe exprimé en StableHLO StableHLO High Level Operations, dans sa version stable et versionnée. Jeu d'opérations qui sert de couche de portabilité entre les frameworks (PyTorch, JAX, TensorFlow) et le compilateur XLA. Un même graphe StableHLO peut viser plusieurs architectures. — le jeu d’opérations versionné qui sert de couche de portabilité entre les frameworks et le compilateur. XLA applique d’abord des passes d’optimisation indépendantes de la cible (élimination de sous-expressions communes, fusion, partitionnement pour le parallélisme), puis des passes spécifiques au matériel, et génère enfin un binaire optimisé pour TPU, GPU ou CPU. C’est cette indépendance vis-à-vis de la cible qui rend XLA portable : le même graphe StableHLO peut viser plusieurs architectures.

Retenez ce point, c’est la clé de tout le dossier. XLA était à l’origine développé dans TensorFlow ; il est désormais le cœur du projet open source OpenXLA, et il supporte trois frontends de framework : TensorFlow, JAX et PyTorch. Le TPU TPU Tensor Processing Unit. L'ASIC d'accélération ML de Google. Ce n'est pas une puce isolée mais un réseau : des chips reliés directement par l'interconnexion ICI en topologie tore, chacun combinant des TensorCores (matmul dense) et des SparseCores (embeddings, collectives). Il ne sait parler qu'au compilateur XLA. , lui, ne sait parler qu’à XLA. Donc tout ce qui veut tourner sur TPU — du code JAX comme du code PyTorch — finit, d’une manière ou d’une autre, par passer par XLA. La question « comment faire tourner PyTorch sur TPU » est donc, au fond, la question « comment amener proprement un graphe PyTorch jusqu’à XLA ». Toute la suite du dossier décrit les chemins concurrents pour y parvenir.

JAX : le framework pour lequel le TPU a été pensé

JAX JAX Framework ML fonctionnel de Google. Compose quatre transformations — grad (dérivées), jit (compilation via XLA), vmap (vectorisation), pmap (parallélisation SPMD) — sur du code qui ressemble à NumPy. Co-conçu avec le TPU. est le framework ML de Google. Pour un lecteur non spécialiste, c’est « NumPy sous stéroïdes » : la même API tableau, augmentée de la capacité à dériver automatiquement et à compiler pour GPU/TPU. Pour l’ingénieur, c’est une bibliothèque de programmation fonctionnelle dont la force est la composabilité de quatre transformations : grad calcule le gradient d’une fonction (la brique de tout apprentissage) ; jit compile la fonction via XLA ; vmap vectorise automatiquement une fonction écrite pour un vecteur afin qu’elle opère sur un batch, sans boucle Python ; pmap la parallélise sur plusieurs accélérateurs selon un modèle SPMD SPMD Single Program, Multiple Data. Modèle de parallélisme où tous les rangs exécutent exactement le même programme sur des fragments de données différents. C'est le modèle pour lequel le TPU est taillé ; sa version divergente, le MPMD (un rang qui fait du logging en plus, par exemple), cassait l'optimisation. .

Le mécanisme interne mérite d’être déplié, parce qu’il explique pourquoi JAX et le TPU s’entendent si bien. JAX ne « voit » pas vos valeurs : il les trace. Quand vous appliquez jit, JAX exécute votre fonction avec des valeurs symboliques — des tracers — pour reconstruire la séquence d’opérations sous forme de jaxpr, sa représentation intermédiaire fonctionnelle, qu’il abaisse ensuite en StableHLO pour XLA. Le code Python décrit un calcul plutôt qu’il ne l’exécute pas à pas. C’est un modèle paresseux assumé — et c’est exactement le genre de graphe entier que XLA sait optimiser.

Pourquoi les TPU ont-ils historiquement été optimisés pour JAX ? Parce que les deux ont été réglés ensemble. Le reporting de Reuters de décembre 2025 le dit sans détour : pendant des années, les TPU étaient d’abord accordés pour JAX, le framework interne favori de Google, ce qui créait un « bottleneck » — le terme est entre guillemets dans l’article — pour les clients déjà bâtis sur PyTorch. La pile JAX de production s’appuie sur Pathways, la couche d’orchestration qui permet à un seul client JAX de piloter des calculs sur des milliers de puces, par-delà les frontières d’un pod TPU. C’est le système qui entraîne Gemini en interne, et des laboratoires comme Anthropic, xAI et Apple utilisent JAX comme l’un de leurs outils de construction de modèles de fondation.

Le problème, du point de vue de Google, c’est l’autre côté de la balance. PyTorch domine la recherche et de plus en plus la production. Selon le rapport Shaping the Future of Generative AI de la Linux Foundation, repris par la PyTorch Foundation, PyTorch mène l’entraînement de modèles avec 63 % d’adoption ; la même fondation chiffre à plus de 70 % la part des implémentations de recherche IA qui reposent dessus. C’est ce déséquilibre que Google cherche à neutraliser : un silicium taillé pour JAX, face à un monde du code qui écrit du PyTorch.

PyTorch/XLA : le pont qui existe déjà aujourd’hui

Avant TorchTPU, faire tourner PyTorch sur TPU passait — et passe encore — par PyTorch/XLA, le paquet torch_xla. C’est un produit public, installable immédiatement (pip install torch==2.8.0 'torch_xla[tpu]==2.8.0'), contrairement à TorchTPU. Comprendre son modèle d’exécution, c’est comprendre la marche que TorchTPU cherche à supprimer.

PyTorch/XLA repose sur les lazy tensors, les tenseurs paresseux. Quand vous écrivez z = x + y sur un tenseur XLA, rien ne s’exécute : l’opération est enregistrée dans un graphe symbolique. Le calcul réel n’a lieu qu’à un point de synchronisation — typiquement l’appel à xm.mark_step(), qui « coupe » le graphe accumulé, le compile et l’exécute sur le TPU. La documentation de HuggingFace résume bien le contraste :

import torch
import torch_xla.core.xla_model as xm

device = xm.xla_device()              # un device XLA, pas CUDA
x = torch.randn(2048, 2048, device=device)

for step in range(100):
    y = x @ x                         # rien ne s'exécute : l'op est enregistrée
    x = torch.tanh(y)                 # le graphe s'allonge, toujours rien sur le TPU
    xm.mark_step()                    # ici : coupe le graphe, compile, exécute

# Un print(x) AVANT mark_step forcerait une matérialisation device -> host
# et casserait le tracing : c'est le talon d'Achille ergonomique du modèle.

C’est puissant — laisser XLA voir un graphe entier, c’est lui laisser fusionner et optimiser — mais c’est aussi le talon d’Achille. Toute opération qui réclame une valeur concrète (un print, un log, un checkpoint) force une matérialisation et un transfert device→host qui casse le tracing. Et si les shapes changent à chaque itération — formes dynamiques —, XLA recompile un nouveau graphe à chaque fois : un gouffre de performance, qu’on évite en paddant à des formes fixes. La frustration historique transparaît dans ce commentaire d’un chercheur sur Hacker News, à propos de l’entraînement de modèles de recherche sur l’ancien pont : « a mess of undocumented behavior and bugs (silently hanging after 8 hours of training!) » — un fouillis de comportements non documentés, avec un entraînement qui se fige silencieusement après huit heures.

Deux précisions de version, parce qu’elles comptent en production. Depuis la release 2.7 (billet officiel daté de mai 2025, le notice C++11 du dépôt portant la date du 18 mars 2025), les builds C++11 ABI sont devenus le défaut ; Google ne fournit plus de wheels en pré-C++11 ABI, et ces nouveaux wheels améliorent les performances de tracing — sur un Mixtral 8x7B en v5p-256, le dépôt documente 39 % de MFU contre 33 % avant. Le support va de Python 3.9 à 3.13, avec des nightlies 2.9 disponibles.

Le point capital pour la suite est écrit noir sur blanc dans le dépôt officiel pytorch/xla : « Once TorchTPU is public it will replace PyTorch/XLA. » PyTorch/XLA n’est pas un concurrent de TorchTPU ; c’est son prédécesseur, appelé à être remplacé.

TorchTPU : faire que le TPU « se comporte comme PyTorch »

Voilà le cœur du dossier. TorchTPU est la nouvelle pile d’ingénierie de Google pour exécuter PyTorch nativement sur TPU. Son histoire est courte : un projet interne d’abord révélé par Reuters le 17 décembre 2025 — le nom de code avait fuité —, puis détaillé officiellement le 7 avril 2026 sur le Google Developers Blog. Le principe directeur, c’est qu’un développeur doit pouvoir prendre un script PyTorch existant, changer son device en tpu, et lancer sa boucle d’entraînement sans toucher une ligne de logique métier.

The TPU should be an obvious choice for any PyTorch user to target. […] Getting access through PyTorch has always been difficult. We are changing that this year.

— Lee Howes, Engineering Lead TorchTPU, Google — propos rapportés par The Stack

Eager First : la rupture de philosophie

Là où PyTorch/XLA imposait le modèle paresseux, TorchTPU établit une philosophie « Eager First ». Techniquement, il s’appuie sur l’interface PrivateUse1 de PyTorch — le point d’extension prévu pour brancher un nouveau type de device. L’intégration se fait à un niveau assez profond pour que vous manipuliez de vrais torch.Tensor qui se trouvent vivre sur un TPU. La formule de l’équipe : « No subclasses, no wrappers; just ordinary, familiar PyTorch Tensors on a TPU. » Pas de sous-classe, pas d’enrobage — un tenseur PyTorch ordinaire, qui répond comme sur CUDA.

import torch

# TorchTPU : interface PrivateUse1 — de vrais torch.Tensor qui vivent sur le TPU
x = torch.randn(2048, 2048, device="tpu")
y = x @ x                 # exécution eager, comme sur CUDA
print(y.sum())            # la valeur est disponible — pas de mark_step

# Kernel custom : on décore une fonction JAX, TorchTPU la branche via Pallas
@torch_tpu.pallas.custom_jax_kernel
def fused_softmax(x):
    ...

Trois modes eager couvrent le cycle de développement. Debug Eager exécute une opération à la fois, avec synchronisation CPU après chaque étape — lent, mais précieux pour traquer les shape mismatches, les NaN, les crashs out-of-memory. Strict Eager dispatche op-par-op mais en asynchrone, pour reproduire l’expérience PyTorch par défaut. Fused Eager est la percée : par réflexion automatique sur le flux d’opérations, TorchTPU fusionne les étapes à la volée en blocs plus denses avant de les remettre au TPU. Le gain annoncé est « a 50% to 100+% performance increase over Strict Eager, with no setup required » — sans configuration de l’utilisateur. Les trois modes partagent un Compilation Cache, mono-host ou persistant multi-host.

La compilation statique : Dynamo → StableHLO → XLA

Pour le pic de performance, TorchTPU s’intègre nativement à torch.compile, et le chemin qu’il emprunte est un choix d’architecture délibéré. Capture du graphe FX via Torch Dynamo, puis — au lieu de router vers Torch Inductor, le backend par défaut de PyTorch — utilisation de XLA comme compilateur backend, via une couche de traduction qui mappe les opérateurs PyTorch directement en StableHLO. La justification de Google : XLA est « rigorously battle-tested for TPU topologies » et sait optimiser nativement le recouvrement entre calcul dense et communications collectives à travers l’ ICI ICI Inter-Chip Interconnect. Le lien propriétaire qui relie directement les puces TPU entre elles, en topologie tore 2D/3D, sans passer par le réseau de l'hôte. C'est lui qui fait qu'un pod de milliers de TPU se comporte comme une seule machine — l'équivalent du NVLink côté Google. . Autrement dit, Google ne réinvente pas un backend TPU pour PyTorch : il rebranche PyTorch sur le backend TPU mûri pendant des années pour JAX.

Le problème MPMD que PyTorch/XLA ne savait pas résoudre

Le vrai progrès architectural se cache ici, et il est moins visible que les chiffres d’eager. PyTorch/XLA ne supportait que du SPMD pur : tous les rangs exécutent exactement le même code. Or le code PyTorch réel diverge légèrement d’un rang à l’autre — le rang 0 fait typiquement un peu de logging en plus. Cette divergence, le MPMD (Multiple Program, Multiple Data), cassait l’optimisation TPU, taillée pour le SPMD. TorchTPU est architecturé pour supporter ces exécutions divergentes en isolant les primitives de communication là où c’est nécessaire, « at minimal cost », tout en préservant la vue globale dont XLA a besoin. Conséquence concrète : les API distribuées DDP, FSDPv2 et DTensor de PyTorch fonctionnent « out of the box ».

La portabilité n’efface pas le matériel, et Google donne l’exemple du piège classique. Beaucoup de modèles codent en dur une dimension de tête d’attention à 64, alors que les TPU actuels atteignent leur pic d’efficacité en matmul matmul Multiplication de matrices, l'opération dominante des couches d'un réseau de neurones. Quand on dit qu'un GPU « calcule », il fait à 90 % des matmul. à 128 ou 256. TorchTPU recommande un flux par paliers : d’abord obtenir une exécution correcte, ensuite refactorer les architectures sous-optimales ou injecter des kernels custom. Le fait que votre code tourne ne veut pas dire qu’il tourne bien — la conscience matérielle reste votre travail.

vLLM : l’étage du serving

Tout ce qui précède concerne l’entraînement et l’exécution générale. vLLM occupe un étage distinct : le serving d’inférence des LLM en production. Né en 2023 au Sky Computing Lab de l’UC Berkeley, c’est le moteur d’inférence open source de référence, et son articulation avec la pile TPU est devenue, fin 2025, un signal sur la direction réelle que prend Google.

Son innovation centrale, PagedAttention PagedAttention Algorithme introduit par vLLM qui gère le KV cache comme la mémoire virtuelle d'un système d'exploitation — par pages, sans exiger un bloc contigu par requête. Élimine la fragmentation interne et externe, permet de servir 2 à 4× plus de requêtes concurrentes sur la même VRAM. , attaque le gaspillage mémoire du serving. Pour générer du texte, un transformer relit à chaque token le KV cache KV cache Mémoire des vecteurs clé et valeur déjà calculés pour chaque token traité par un LLM. Évite de recalculer l'attention sur tout l'historique, au prix d'une consommation mémoire qui croît avec le contexte. de toute la séquence ; le serving naïf pré-réserve un bloc contigu dimensionné pour la longueur maximale, et gaspille l’essentiel de la VRAM réservée. PagedAttention applique l’idée de la mémoire virtuelle d’un système d’exploitation : le KV cache est découpé en blocs — 16 tokens par bloc par défaut, paramétrable —, adressés via une table et stockés de façon non contiguë. La fragmentation s’effondre. Le mécanisme est détaillé dans notre dossier sur le KV cache, objet central du serving.

Deuxième pilier : le batching continu batching continu Ordonnancement à l'itération — ajouter et retirer des requêtes du batch à chaque pas de génération, au lieu d'attendre qu'un batch entier se termine. Formalisé par Orca (OSDI 2022), popularisé par vLLM. Multiplie par 2 à 4 le débit d'un serveur d'inférence sous forte concurrence. . Au lieu d’attendre que toute la fournée finisse, vLLM travaille à l’échelle de l’itération : dès qu’une requête se termine, ses blocs KV sont libérés et la requête suivante de la file est insérée au pas de décodage suivant. L’accélérateur reste saturé. Le concept vient d’Orca (OSDI 2022) ; le chiffre le plus cité — jusqu’à 23× de débit — est la mesure d’Anyscale face au batching statique naïf de HuggingFace, pas un gain général, et il faut le présenter comme tel.

L’articulation avec notre dossier est ici. vLLM est multi-backend — NVIDIA, AMD, Intel (CPU, GPU, Gaudi), IBM Power, AWS Trainium/Inferentia via plugin, et TPU. En octobre 2025, vLLM TPU a été refondu autour de tpu-inference, un plugin matériel qui unifie JAX et PyTorch sous un unique chemin d’abaissement JAX→XLA. Un modèle défini en PyTorch tourne sur TPU sans changement de code, abaissé via Torchax — un pont PyTorch→JAX, aujourd’hui dans son propre dépôt google/torchax —, tandis que JAX est nativement supporté. Le blog vLLM le formule sans ambiguïté :

Les gains documentés sont réels : sur le chemin précédent (PyTorch/XLA), l’équipe avait obtenu +3,6× de débit sur Llama 3.1-8B en v6e-1 et +2,1× sur Llama 3.1-70B en v6e-8 ; la refonte tpu-inference atteint « nearly 5x » le prototype de février 2025. Une limite documentée par Google Cloud encadre l’usage : sur GKE, vLLM sur TPU est en configuration mono-host ; le multi-host n’est pas supporté, ce qui pour les modèles 400B+ oriente vers JetStream, le moteur d’inférence TPU multi-host de Google.

Notez le détail qui résonne avec tout le reste du dossier. Même pour servir du PyTorch, le chemin réel sur TPU passe par JAX→XLA via Torchax. Côté serving, la destination n’est pas « PyTorch sur TPU » : c’est toujours XLA, atteint par JAX.

Comment tout cela s’articule : le modèle mental

Voici l’édifice, du haut vers le bas. C’est le schéma à garder en tête.

Étage 1 — les frameworks, ce que le développeur écrit. Deux mondes : PyTorch (impératif, eager, dominant) et JAX (fonctionnel, paresseux, co-conçu avec le TPU). Concurrents au niveau de l’API, ils convergent vers le même compilateur.

Étage 2 — le compilateur, le pivot. XLA, alimenté en StableHLO. JAX y arrive via jit/jaxpr. PyTorch y arrive par trois chemins historiquement distincts : l’ancien pont PyTorch/XLA (lazy tensors, mark_step) ; le nouveau TorchTPU (eager-first, torch.compile → Dynamo → StableHLO → XLA, MPMD) ; et, pour le serving, Torchax (PyTorch → JAX → XLA) dans vLLM.

Étage 3 — le silicium, où ça s’exécute. Le TPU, qui n’est pas une puce isolée mais un réseau : des chips reliés par l’ICI en topologie tore 2D/3D, chacun combinant des TensorCores Tensor Cores Unités matérielles spécialisées dans les multiplications de matrices à basse précision, introduites par NVIDIA avec Volta (2017). Chaque génération ajoute des formats supportés : FP16 → FP8 (Hopper) → FP6/FP4 (Blackwell). Ce sont elles qui exécutent l'essentiel du calcul d'inférence. (matmul dense) et des SparseCores (embeddings, gather/scatter, collectives). XLA peut aussi viser GPU et CPU — la portabilité vient de là.

Autour, les outils satellites, par étage de besoin. TorchTitan : la plateforme native PyTorch pour l’entraînement à grande échelle (parallélisme composable via DTensor et DeviceMesh) — une cible d’intégration de TorchTPU pour 2026. Pathways : l’orchestrateur côté JAX qui étend un calcul XLA au-delà d’un pod. Helion : un DSL Python « PyTorch with tiles » qui automatise l’autotuning des kernels. Pallas / Mosaic : le langage de kernels custom JAX, qui s’abaisse via Mosaic sur TPU — le moyen d’extraire la dernière goutte de performance là où XLA ne sait pas encore optimiser. MaxText / JetStream : l’implémentation de référence JAX pour l’entraînement de LLM, et le moteur d’inférence TPU multi-host.

La phrase à retenir : PyTorch et JAX se disputent le développeur ; XLA les réconcilie sur le silicium ; vLLM sert le résultat. TorchTPU est le projet qui transforme « PyTorch peut techniquement tourner sur TPU » en « PyTorch tourne sur TPU comme à la maison ».

Le vrai moat de NVIDIA n’est pas le silicium

NVIDIA ne domine pas parce que ses puces feraient une magie inaccessible — elles sont excellentes, point. Il domine parce que le chemin par défaut passe par CUDA, et que ce chemin cumule une décennie d’avance : outillage, kernels optimisés, effet de réseau. Plus de 6,5 millions de développeurs utilisent les logiciels NVIDIA (chiffre communiqué en août 2025), dont plus de 6 millions sur CUDA. C’est un moat logiciel, et c’est lui que TorchTPU vise — pas le pic de FLOPS.

Les chiffres du fossé sont éloquents. Sur l’exercice fiscal 2026 (clos fin janvier 2026), NVIDIA a réalisé environ 178 milliards d’euros de revenus datacenter, en hausse de 68 % sur un an — environ 90 % de son chiffre d’affaires total (≈199 Md€), avec une marge brute non-GAAP de l’ordre de 71 % sur l’exercice (75 % au seul T4). Le revenu réseau seul (NVLink, Ethernet IA) avoisine les 28 milliards d’euros. Côté part de marché, IDC situe NVIDIA autour de 81 % des puces IA datacenter, son rival le plus proche, AMD, n’en détenant qu’environ 10 % — un chiffre d’analyste, à traiter comme tel. Quant à la visibilité de revenus, c’est Jensen Huang, à GTC en octobre 2025, qui l’a chiffrée — « the first technology company in history to have visibility into half a trillion dollars » — à de l’ordre de 460 milliards d’euros de Blackwell + Rubin de début 2025 à fin 2026, montant relevé depuis à quelque 920 milliards d’euros jusqu’à fin 2027.

C’est ce mur que la friction logicielle entretient, et c’est pourquoi le combat se joue au niveau du compilateur, pas du die. Sur la nature exacte de ce verrou et sa comparaison avec ROCm, voir CUDA vs ROCm en 2026.

La réponse de Google : la portabilité comme arme

L’idée de Google est de transformer la puce IA en commodité en supprimant le coût de changement. Trois leviers, déjà tous engagés en 2026.

Le premier : rendre le TPU « PyTorch-friendly » avec TorchTPU, pour que les boutiques PyTorch n’aient plus à réécrire leur stack en JAX. Le deuxième : s’allier à Meta, créateur et gardien de PyTorch. Reuters rapporte que Google travaille étroitement avec Meta et envisage d’open-sourcer des parties de TorchTPU pour accélérer l’adoption — et Meta, l’un des plus gros clients de NVIDIA (≈66 milliards d’euros de capex 2025), a un intérêt direct à faire baisser ses coûts et renforcer son levier de négociation ; le reporting indique qu’il a exploré la location de capacité TPU dès 2026 et leur déploiement dans ses propres datacenters à partir de 2027. Le troisième : la portabilité multi-stack (JAX, PyTorch/XLA, ONNX) qui permet d’entraîner le même modèle sur NVIDIA, Google ou AMD avec des changements minimes.

Le contexte business est explosif. Sundar Pichai a indiqué, aux résultats du T3 2025 d’Alphabet, que Google Cloud avait signé sur les neuf premiers mois de 2025 plus de contrats dépassant 900 millions d’euros que sur les deux années précédentes réunies. Et surtout Anthropic : l’accord du 23 octobre 2025 donne accès à « up to one million TPU chips… well over a gigawatt of capacity coming online in 2026 », chiffré « tens of billions of dollars ». Thomas Kurian, CEO de Google Cloud, l’a justifié ainsi :

Anthropic’s choice to significantly expand its usage of TPUs reflects the strong price-performance and efficiency its teams have seen with TPUs for several years.

— Thomas Kurian, CEO, Google Cloud

L’accord a été étendu en avril 2026 : un investissement de Google dans Anthropic pouvant atteindre 37 milliards d’euros (annoncé le 24 avril, « up to »), et un accord de capacité de nouvelle génération via Broadcom — 3,5 GW selon le dépôt réglementaire de Broadcom, « jusqu’à 5 GW » selon la formulation de Google. Fait nouveau, enfin : Google s’est mis à vendre des TPU pour livraison à un cercle restreint de clients dans leurs propres datacenters, là où historiquement on ne pouvait que les louer sur Google Cloud.

Deux puces pour deux métiers : la 8ᵉ génération

À Google Cloud Next, le 22 avril 2026, Google a dévoilé une 8ᵉ génération de TPU scindée pour la première fois en deux puces distinctes. (À ne pas confondre : Ironwood, la 7ᵉ génération, avait atteint sa disponibilité générale dès fin 2025 ; c’est la scission 8t/8i qui est l’annonce d’avril 2026.) Le rationnel : entraînement et inférence ont divergé en deux profils de charge, et un silicium unique sert mal les deux à la fois — la même logique de spécialisation par phase qu’on a vue côté NVIDIA avec la disaggregation de Vera Rubin.

Le TPU 8t, pour l’entraînement, mise sur l’échelle. Native FP4 FP4 Format à virgule flottante 4 bits — la 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). qui double le débit MXU, host Axion ARM, et surtout une fabric nommée Virgo qui relie plus de 134 000 chips avec jusqu’à 47 Pb/s de bande passante bi-sectionnelle non bloquante, pour plus de 1 700 ExaFlops à scaling quasi linéaire — de quoi dépasser le million de puces dans un cluster d’entraînement, piloté par JAX + Pathways. Le gain annoncé est de jusqu’à 2,7× de performance par dollar vs Ironwood (chiffre Google ; plusieurs médias citent 2,8× voire 2,85×, qui ne sont pas le chiffre primaire). Le superpod compte 9 600 chips, et le billet grand public de Google avance 121 ExaFlops et 2 Po de HBM partagée par superpod.

Le TPU 8i, pour l’inférence et le raisonnement, mise sur la latence. 288 Go de HBM et surtout 384 Mo de SRAM on-chip — ×3 vs la génération précédente, pour loger un plus gros KV cache au plus près du calcul. La nouveauté radicale est topologique : abandon du tore 3D pour Boardfly, qui ramène le diamètre réseau d’une configuration 1 024 chips de 16 sauts à 7 (−56 %), pour une latence améliorée « up to 50% ». Et un bloc fixe nouveau, le CAE (Collectives Acceleration Engine) : deux TensorCores Tensor Cores Unités matérielles spécialisées dans les multiplications de matrices à basse précision, introduites par NVIDIA avec Volta (2017). Chaque génération ajoute des formats supportés : FP16 → FP8 (Hopper) → FP6/FP4 (Blackwell). Ce sont elles qui exécutent l'essentiel du calcul d'inférence. et un CAE par chip remplacent les quatre SparseCores d’Ironwood, et réduisent la latence des collectives on-chip « by 5x » — décisif pour le décodage autorégressif et le chain-of-thought. Gain annoncé : jusqu’à 80 % de performance par dollar vs Ironwood en inférence. Les deux puces partagent l’accès bare-metal et jusqu’à 2× de perf/watt — et toutes deux « run native PyTorch via TorchTPU in preview ». La 8ᵉ génération arrive donc avec TorchTPU comme argument logiciel de premier plan.

Limite structurelle à garder en tête : le TPU a longtemps été louable uniquement sur Google Cloud, jamais achetable en standalone. Les GPU NVIDIA tournent partout — clouds multiples, on-prem, workstations, edge. Google a commencé à corriger cela en vendant des TPU à quelques clients, mais pour une stratégie multi-cloud ou souveraine, l’écart de flexibilité de déploiement reste un facteur décisif. Signe que Google ne cherche pas à remplacer purement NVIDIA : il propose aussi des instances NVIDIA Vera Rubin NVL72 sur sa propre fabric Virgo.

Comment choisir selon votre situation

Vous êtes une boutique PyTorch-first sur GPU et vous évaluez le TPU pour réduire la facture. Ne migrez rien en preview. La voie publique et stable reste PyTorch/XLA (torch_xla[tpu]), pas TorchTPU. Faites un A/B test honnête — le même modèle PyTorch sur un cluster GPU et sur un slice TPU — et comparez débit soutenu, énergie et facture. Surveillez deux signaux qui changent la donne : la sortie du dépôt GitHub public de TorchTPU avec bascule en GA, et la validation du scaling linéaire à taille de Pod. Tant que ces deux jalons ne sont pas franchis, TorchTPU est une promesse crédible, pas une base de production.

Vous faites du serving LLM et cherchez le meilleur coût par token. vLLM est l’option par défaut, multi-backend. Sur TPU, partez de tpu-inference (mono-host sur GKE) ; pour les modèles 400B+ multi-host, basculez sur JetStream. Gardez vos définitions de modèles en PyTorch : Torchax les abaisse sans changement de code. Le seuil qui justifie d’évaluer sérieusement le TPU pour l’inférence : une charge MoE ou raisonnement à forte concurrence et à cible de latence basse — exactement le profil pour lequel le 8i (CAE, gros SRAM) a été conçu.

Vous démarrez un projet de recherche à très grande échelle sur TPU. JAX + MaxText + Pathways reste la voie de moindre résistance et la plus mature — c’est la pile qui entraîne Gemini. N’adoptez PyTorch-sur-TPU que si votre capital de code et de talents est déjà massivement PyTorch.

Vous avez une contrainte multi-cloud, on-prem ou souveraine. Le GPU NVIDIA reste le choix de sécurité tant que les TPU ne sont pas largement achetables hors Google Cloud. Gardez vos pipelines portables (Keras 3, ONNX, modèles agnostiques) pour basculer entre GPU et TPU selon l’évolution des prix et des disponibilités.

Conclusion

TorchTPU ne fera pas tomber le mur de CUDA tout seul. Ce qu’il change, c’est la hauteur de ce mur : il transforme « PyTorch peut techniquement tourner sur TPU » en « PyTorch tourne sur TPU comme à la maison ». Le jour où un responsable d’infrastructure pourra dire « on déplace des charges significatives sans ingénierie héroïque », le levier de négociation s’inverse — et c’est précisément ce que Google cherche à rendre vrai.

Reste la question qui décide de tout, et qu’aucune spec ne tranchera avant les premiers déploiements en GA. La maturité de TorchTPU suffira-t-elle à faire migrer les boutiques PyTorch-first ? Ou JAX/Pathways restera-t-il la voie de moindre résistance pour qui veut le maximum du TPU ? Un indice penche pour TorchTPU : des équipes comme Liquid AI sont passées de JAX à PyTorch en 2023 pour des raisons d’écosystème, pas de code — preuve que le lock-in framework est plus surmontable qu’on ne le croit. Mais un indice penche contre : même vLLM TPU, pour servir du PyTorch, l’abaisse en JAX→XLA via Torchax. Au moins côté serving, la destination réelle reste XLA atteint par JAX. La vraie question pour 2027 n’est donc plus « le TPU peut-il faire tourner PyTorch » — c’est combien de développeurs franchiront le pont une fois qu’il sera stable, et lesquels constateront qu’ils étaient, sans le savoir, déjà du côté JAX.

Sources et méthode

Ce dossier s’appuie sur un travail de vérification arrêté au 9 juin 2026. Chaque chiffre y est, sauf mention contraire, un fait vérifié sur source primaire.

Sources primaires logicielles :

• OpenXLA — architecture et tf2xla : définition de XLA, fusion (« Fusion is XLA’s single most important optimization » — verbatim), exemple reduce_sum(x + y*z), StableHLO comme couche de portabilité, frontends TF/JAX/PyTorch.
• JAX — key concepts : grad/jit/vmap/pmap, tracing → jaxpr → StableHLO.
• PyTorch/XLA — dépôt pytorch/xla (commande d’installation, C++11 ABI, « Once TorchTPU is public it will replace PyTorch/XLA » — verbatim) et billet release 2.7. Le modèle lazy/mark_step et la citation « CPU and CUDA tensors… are lazy » viennent du blog HuggingFace PyTorch/XLA. Le commentaire « mess of undocumented behavior and bugs » est de l’utilisateur in-silico sur Hacker News.
• TorchTPU — Google Developers Blog, 7 avril 2026 : « it should feel like PyTorch », PrivateUse1, trois modes eager, « 50% to 100+% », Dynamo→StableHLO→XLA, MPMD, roadmap, preview. La citation longue de Lee Howes (« The TPU should be an obvious choice… ») est rapportée par The Stack, pas par le billet officiel, qui ne contient aucune citation directe.
• vLLM — blog tpu-inference, 16 octobre 2025 (citation de fallback verbatim, +3,6×/+2,1×, « nearly 5x ») ; PagedAttention (design doc) et papier SOSP 2023 ; Torchax sur google/torchax ; multi-host/JetStream sur Google Cloud GKE.

Sources primaires matériel & business :

• TPU 8t/8i — deep-dive technique Google Cloud (22 avril 2026) et le billet blog.google associé : toutes les specs du Tableau 1, Virgo, Boardfly, CAE, et les chiffres « up to » (2,7× entraînement, 80 % inférence, 5× collectives, 50 % latence, 56 % diamètre). Ironwood : blog Google (avril 2025), GA atteinte fin 2025.
• NVIDIA — résultats FY2026 (8-K / NVIDIA Newsroom) pour les revenus datacenter de ≈178 Md€ (193,7 Md$ au dépôt), +68 %, ~90 % du CA ; la visibilité « half a trillion » est de Jensen Huang à GTC (oct. 2025). Les ~81 % de part de marché (IDC) sont une estimation analyste.
• Deals — communiqué Anthropic/Google (23 oct. 2025, PR Newswire) (citation Kurian verbatim, « up to one million TPU chips ») ; extension d’avril 2026 (investissement Google « up to $40B », capacité 3,5 GW selon le dépôt Broadcom / « jusqu’à 5 GW » selon Google) ; Reuters (déc. 2025) pour la collaboration Meta et l’open-sourcing envisagé de TorchTPU. Liquid AI (JAX→PyTorch 2023) : témoignage public du fondateur.

Notes de méthode et points à manier avec prudence :

• Chiffres constructeur « up to ». Tous les gains 8t/8i (perf/$, latence, perf/watt) sont des claims Google formulés en « up to », non vérifiés par benchmark indépendant. Idem pour les +50 à 100 % de Fused Eager.
• Préci­sions de cohérence. La marge brute 75 % de NVIDIA est le chiffre du T4, pas de l’exercice (≈71 % en non-GAAP sur l’année). Le « 23× » de vLLM est un maximum face au batching statique naïf (mesure Anyscale), pas un gain général ; le concept lui-même vient d’Orca.
• Figures secondaires, hors source primaire Google : les noms de code « Sunfish/Zebrafish », la répartition Broadcom (entraînement)/MediaTek (inférence), le nœud TSMC 2 nm et un calendrier GA « 2027 » ne figurent pas dans le deep-dive officiel (Google annonce une GA « plus tard cette année », soit 2026). Le billet officiel présente lui-même une incohérence interne sur le nombre de chips Boardfly (« up to 1 152 » vs « up to 1 024 active chips »).
• Devises. Les montants sont convertis en euros au taux indicatif 1 USD = 0,92 EUR (mi-2026). Les citations directes (« half a trillion dollars », « tens of billions of dollars ») sont reproduites dans leur devise d’origine, et les chiffres bruts des dépôts SEC sont rappelés en dollars entre parenthèses pour préserver la traçabilité.
• API en preview. Les extraits de code TorchTPU (device="tpu", @torch_tpu.pallas.custom_jax_kernel) sont illustratifs : l’API est en preview et peut évoluer avant la GA.
• Image d’en-tête. Carte TPU v3 de Google photographiée par Zinskauf, Wikimedia Commons, sous licence CC BY-SA 4.0, recadrée pour l’en-tête — image d’illustration d’une génération antérieure de TPU.