---

Le 20 octobre 2026, Google a arrêté de demander aux équipes PyTorch de réécrire leur code

Il y a une scène que connaissent toutes les équipes qui ont tenté, un jour, de faire tourner un modèle PyTorch sur TPU. On clone le dépôt, on installe torch_xla, on remplace les cuda par des xla, on se bat avec le LazyTensor, on découvre qu’un opérateur fusionné maison n’a pas d’équivalent, on regarde les temps de compilation s’allonger à chaque changement de forme, et on finit par revenir sur GPU en se promettant de ne plus jamais y toucher. Ce n’est pas une légende : c’est l’expérience documentée de la plupart des équipes qui ont essayé PyTorch sur TPU avant que l’écosystème ne mûrisse.

Le 20 octobre 2026 (heure américaine), Google a annoncé sur le Google Developers Blog des versions compatibles TPU des deux moteurs d’inférence open source qui comptent aujourd’hui : vLLM et SGLang. Ces versions sont construites sur TorchTPU, un mécanisme qui permet d’utiliser des TPU « en conservant le code PyTorch tel quel ». Le même jour, la conférence PyTorch North America voyait débarquer llm-d 1.0, la pile d’inférence distribuée Kubernetes-native, avec son routage cache-aware TPU/GPU. Deux annonces, un même fil : la pile d’inférence open source devient officiellement hétérogène.

Pourquoi ce n’est pas un portage de plus ? Parce que jusqu’ici, faire du PyTorch sur TPU impliquait d’accepter un contrat implicite : tu écris du PyTorch, mais tu penses XLA. Tu composes avec le LazyTensor, tu acceptes les contraintes de graphe, tu réécris les bouts qui ne passent pas. TorchTPU prétend changer ce contrat : tu écris du PyTorch, et le pont vers XLA se débrouille. C’est une promesse forte, et comme toute promesse forte, elle mérite d’être disséquée.

Ce décryptage suit un fil simple : ce que TorchTPU fait réellement, ce qu’il ne fait pas encore, ce qu’il coûte à migrer, et quand le TPU devient un choix rationnel face à un H100 ou un H200. Avec une réserve d’entrée de jeu : la documentation publique reste mince, et une partie des affirmations techniques repose sur une source secondaire unique (note.com/prodready_ai, citant le blog Google). Nous le signalerons à chaque fois que c’est le cas.

---

Sous le capot : ce que « PyTorch natif » veut dire quand la cible est un ASIC

Un TPU n’est pas un GPU. C’est un ASIC — un circuit conçu pour un type de calcul précis, les opérations matricielles denses, avec une hiérarchie mémoire et un modèle de parallélisme qui n’ont rien à voir avec un SM NVIDIA. Faire tourner PyTorch dessus, c’est donc faire parler deux langages : le graphe dynamique de PyTorch d’un côté, le compilateur XLA et son IR (HLO) de l’autre.

La chaîne historique ressemble à ceci. Vous écrivez du PyTorch. torch_xla capture le graphe — soit en mode eager avec des kernels pré-compilés, soit via le LazyTensor qui accumule les opérations avant de les compiler en bloc. Ce graphe est ensuite loweré vers XLA HLO, où le compilateur fusionne les opérateurs, choisit les layouts mémoire et génère le code machine. L’exécution passe enfin par PJRT, l’API de runtime qui abstrait le matériel et gère la communication entre puces.

TorchTPU se situe dans cette chaîne, mais avec une ambition différente : masquer la couche de réécriture. Concrètement, d’après la source secondaire disponible, trois éléments caractérisent l’approche :

• Le nom de périphérique tpu : on place ses tenseurs sur tpu comme on les placerait sur cuda, sans changer la structure du code.
• L’exécution telle quelle ou via torch.compile : le code peut tourner en eager, ou être compilé par le backend XLA de torch.compile.
• La communication multi-puces via torch.distributed : on reste dans l’API standard de PyTorch pour le distribué, plutôt que dans une abstraction propre à XLA.
• Les noyaux Pallas appelés comme opérations PyTorch personnalisées : Pallas est le langage de kernels de Google pour TPU ; TorchTPU les expose comme des ops PyTorch, ce qui permet d’écrire des kernels performants sans sortir du cadre PyTorch.

La frontière entre code PyTorch natif et code XLA généré se situe donc exactement là où elle se situait avant : à l’entrée du compilateur. Ce que TorchTPU ajoute, c’est de la gomme sur la ligne. Ce qu’il ne peut pas faire, c’est supprimer la ligne : à un moment, votre graphe PyTorch devient du HLO, et ce que XLA ne sait pas faire, XLA ne le fera pas.

C’est le point que la communication de Google tend à estomper. « PyTorch natif » ne veut pas dire « PyTorch identique à CUDA ». Cela veut dire « PyTorch qui n’exige plus de réécriture manuelle pour cibler un TPU ». La nuance est énorme pour un praticien : elle déplace le travail de la réécriture vers le diagnostic.

---

Eager, compilé, hybride : les trois régimes d’exécution et leurs pièges de debugging

C’est ici que se joue la vraie expérience utilisateur, et c’est la section qui parlera aux équipes qui ont souffert du LazyTensor.

Le mode eager exécute les opérations une par une, avec des kernels pré-compilés. Il est idéal pour le prototypage, le débogage pas à pas, les formes dynamiques. Sur TPU, il est plus lent qu’un graphe compilé — les overheads de lancement de kernel s’accumulent — mais il permet de poser un print, un breakpoint, de vérifier une valeur intermédiaire. C’est le régime à privilégier pour valider qu’un modèle charge, que les poids sont bons, que la loss descend.

Le mode compilé (torch.compile avec backend XLA) capture le graphe, le fait passer par XLA, et produit un exécutable optimisé. C’est là que le TPU donne sa pleine mesure : fusion d’opérateurs, layouts mémoire adaptés, pipelines de communication recouvrant le calcul. C’est aussi là que le debugging change de nature. Vous ne déboguez plus des stack traces Python, vous déboguez des erreurs de compilation XLA, des recompilations silencieuses, des formes dynamiques qui cassent la fusion, des temps de compilation qui explosent sur les gros graphes.

Le mode hybride — eager pour certaines parties, compilé pour d’autres — est en pratique le plus fréquent en production, et le plus piégeux : on croit avoir compilé l’ensemble, et une op non supportée déclenche un fallback silencieux qui coûte 10x en performance sans rien dire.

Les heuristiques de diagnostic, dans ce contexte, tiennent en quelques réflexes. Lire les HLO dumps : XLA peut exporter le graphe compilé, et c’est souvent le seul moyen de voir où une op a été décomposée ou rejetée. Repérer les fallbacks : activer les logs de compilation, chercher les messages de type « falling back to eager ». Isoler les ops non supportées : commenter des blocs, réduire le modèle à un module, compiler chaque module séparément. Surveiller les recompilations : chaque changement de forme de tenseur peut déclencher une recompilation complète ; sur un modèle à contexte variable, cela peut représenter des minutes perdues à chaque requête.

Est-ce que TorchTPU change vraiment l’expérience, ou déplace-t-il la douleur ? Honnêtement : il la déplace, et c’est déjà beaucoup. La douleur historique était double — réécriture et debugging. TorchTPU supprime la première, laisse la seconde. Pour une équipe qui n’a jamais touché à XLA, le debugging compilé reste un apprentissage ; pour une équipe qui a déjà souffert du LazyTensor, c’est une amélioration nette mais pas une révolution.

---

La couverture réelle : autograd, bf16, FSDP, DTensor, SPMD — ce qui tient et ce qui craque

C’est la question que tout praticien pose en premier, et la réponse est inconfortable : la couverture officielle n’est pas publiée dans le détail. Google n’a pas livré, avec l’annonce du 20 octobre, une matrice « op par op » du support PyTorch sur TPU. On sait que TorchTPU existe, qu’il permet d’exécuter du code PyTorch tel quel, que torch.distributed gère la communication multi-puces, que Pallas est exposé comme ops personnalisées. On ne sait pas, à la lecture des sources disponibles, quelles APIs sont supportées à quel niveau de performance.

Ce que l’on peut dire avec prudence, en distinguant les trois niveaux :

Ce qui est annoncé : l’exécution de code PyTorch tel quel, le mode eager et compilé, la communication multi-puces via torch.distributed, l’appel de kernels Pallas.

Ce qui est documenté (au sens : présent dans la communication officielle relayée) : le caching de préfixe, l’offloading du cache KV, le tool calling, la sortie structurée, le décodage spéculatif, l’attention data-parallel combinée à l’expert parallelism, le context parallelism pour prefill et decode — mais ces fonctionnalités sont listées pour les moteurs (vLLM, SGLang), pas pour TorchTPU lui-même.

Ce qui est supposé fonctionner : autograd (difficile d’imaginer un framework d’entraînement sans), AMP/bf16 (standard sur TPU), FSDP et DTensor (mentionnés nulle part dans les sources disponibles, mais nécessaires pour tout entraînement distribué sérieux), SPMD (le modèle de parallélisme historique de XLA).

Le vrai sujet n’est pas « est-ce que le code tourne tel quel » — la réponse est oui, c’est la promesse de TorchTPU. Le vrai sujet est « est-ce que le code tourne à performance comparable ». Et là, les divergences avec CUDA sont réelles :

• Sémantique des collectifs : torch.distributed sur TPU ne se comporte pas exactement comme sur NCCL. Les temps de synchronisation, les tolérances aux déséquilibres de charge, les stratégies de recouvrement calcul/communication diffèrent.
• Gestion de la mémoire : la HBM d’un TPU n’est pas gérée comme celle d’un GPU. Les pics mémoire, les stratégies d’offloading, les fragmentations ne se comportent pas pareil.
• Précision numérique : bf16 est le standard sur TPU, mais les chemins de réduction, les accumulations, les normalisations peuvent produire des résultats légèrement différents — ce qui peut faire échouer des tests de non-régression stricts.
• Ops manquantes et fallbacks : toute op non supportée nativement déclenche une décomposition ou un fallback, avec un coût en performance qui n’est pas toujours visible.

Pour un praticien, la conclusion pratique est simple : il faut benchmarker, pas croire. La couverture annoncée n’est pas la couverture utile. Un modèle qui « tourne » sur TPU peut tourner à 40 % de la performance d’un H100 sur le même workload, ou à 120 % — et sans benchmark, on ne le sait pas.

---

vLLM et SGLang sur TPU : la pile d’inférence garde son cerveau, change ses jambes

L’annonce du 20 octobre ne se limite pas à TorchTPU : elle livre des versions TPU des deux moteurs d’inférence open source les plus utilisés. Et c’est peut-être la partie la plus intéressante pour les équipes de serving.

Le principe est élégant : les moteurs conservent leur allocation de tâches, leur ordonnanceur, leur gestion du cache KV et leur serveur API d’origine, en ajoutant des implémentations TPU en dessous. Autrement dit, le cerveau de vLLM et de SGLang ne change pas ; ce sont les jambes qui changent. Pour une équipe qui a déjà construit son pipeline de serving autour de l’API vLLM, la migration vers TPU ne devrait pas impliquer de réécrire la couche applicative.

Les fonctionnalités listées dans l’annonce sont impressionnantes sur le papier : caching de préfixe (y compris sur modèles hybrides), offloading du cache KV vers mémoire hôte ou Managed Lustre, tool calling, sortie structurée, décodage spéculatif (MTP, EAGLE-3, DFlash, DSpark, prédicteurs n-gram), attention data-parallel combinée à l’expert parallelism, context parallelism pour prefill et decode. Réserve importante : l’annonce ne précise pas quel moteur supporte quoi. Il faut donc lire cette liste comme un catalogue d’objectifs, pas comme une matrice de fonctionnalités disponibles.

Deux détails révèlent la stratégie de Google. D’abord, les partenariats : vLLM a été développé en collaboration avec Inferact, SGLang avec RadixArk. Google ne construit pas son propre runtime maison pour TPU — il passe par l’écosystème open source existant. Ensuite, le choix de livrer simultanément les deux moteurs plutôt qu’un seul : c’est un signal d’ouverture, pas de verrouillage. Google veut que les équipes qui ont déjà choisi vLLM ou SGLang puissent cibler TPU sans changer de moteur.

Est-ce que ça marche ? Sans benchmarks publics, impossible de trancher. Mais l’architecture de l’annonce — conserver l’ordonnanceur, remplacer l’exécution — est la bonne. C’est exactement ce qu’il faut faire pour ne pas imposer une réécriture aux équipes de production.

---

Porter un pipeline de fine-tuning existant : le vrai coût, étape par étape

C’est la question à laquelle tout le monde veut une réponse chiffrée, et c’est celle où il faut être le plus honnête : il n’existe pas de benchmark public de migration PyTorch→TPU avec TorchTPU. Ce qui suit est donc une grille de lecture, pas un devis.

Ce qu’on garde tel quel : le code du modèle, la boucle d’entraînement, le tokenizer, les datasets, la logique de logging et d’évaluation. C’est la promesse de TorchTPU, et c’est ce qui change la donne par rapport à l’époque du LazyTensor.

Ce qu’on doit adapter : le placement des tenseurs (.to('tpu') au lieu de .to('cuda')), la distribution (passer de NCCL à la communication TPU via torch.distributed), les checkpoints (formats, stratégies de sauvegarde distribuée), la mixed precision (vérifier que bf16 se comporte comme attendu sur les couches sensibles).

Ce qu’on doit réécrire : les kernels custom CUDA — et c’est là que ça fait mal. FlashAttention, les kernels fusionnés maison, les opérations de quantization spécifiques à NVIDIA : tout cela n’a pas d’équivalent direct sur TPU. Il faut soit trouver une implémentation Pallas, soit accepter une version non optimisée, soit réécrire. Pour les modèles MoE, le parallélisme expert doit être repensé : la topologie de communication d’un TPU n’est pas celle d’un cluster GPU.

La stratégie de portage progressive que je recommanderais : commencer par l’inférence (le chemin le plus simple, avec vLLM ou SGLang sur TPU), puis un fine-tuning mono-puce sur un petit modèle pour valider la chaîne, puis le distribué sur un modèle de taille réelle. Chaque étape doit être benchmarkée contre la baseline GPU avant de passer à la suivante.

Sur les coûts horaires, les ordres de grandeur circulent — mais avec une réserve méthodologique forte : ils proviennent d’une source tierce (void.ma) non recoupée, et certains chiffres sont atypiques.

Accélérateur	Coût horaire indicatif (source tierce, non recoupée)	Mémoire	Bande passante
TPU v4	~8–10 $/h	32 Go HBM	1,2 To/s
TPU v5e	~1,50–2 $/h	16 Go HBM	~600 Go/s
A100	~3–4 $/h	40/80 Go HBM2	1,9 To/s
H100	~8–12 $/h	80 Go HBM3	3 To/s

Chiffres issus d’une source tierce unique (void.ma), non corroborés par des sources officielles Google ou NVIDIA. À traiter comme des ordres de grandeur, pas comme des prix contractuels.

La lecture de ce tableau est instructive : le TPU v5e est l’option la moins chère au token si le workload s’y prête, mais sa mémoire (16 Go) limite les modèles qu’on peut y faire tenir. Le TPU v4 est dans la même gamme de prix qu’un H100, avec moins de mémoire et une bande passante inférieure. Le calcul économique n’est donc pas évident : il dépend du workload, du modèle, et de la disponibilité.

---

llm-d 1.0 et TorchTPU : vers une pile d’inférence volontairement hétérogène

Le même 20 octobre 2026, à la PyTorch Conference North America, la communauté llm-d annonçait llm-d 1.0, une pile d’inférence distribuée Kubernetes-native, avec — c’est le point clé — un routage cache-aware TPU/GPU. IBM Research a relayé l’annonce sur son blog officiel.

Croisons les deux annonces. TorchTPU permet à vLLM et SGLang de tourner sur TPU. llm-d 1.0 route les requêtes vers le bon accélérateur en fonction de la localité du cache. Le résultat est une pile où :

• un routeur décide où envoyer la requête selon la localité du cache (préfixe déjà calculé sur tel accélérateur) ;
• des moteurs (vLLM, SGLang) parlent le même langage sur des accélérateurs différents ;
• un framework d’entraînement (PyTorch, via TorchTPU) ne présuppose plus un seul type de silicium.

C’est une architecture séduisante, et elle répond à un vrai problème : dans un cluster hétérogène, envoyer aveuglément une requête au premier accélérateur disponible gaspille le cache de préfixe déjà calculé ailleurs. Le routage cache-aware corrige cela.

Mais l’hétérogénéité a un prix opérationnel, et il ne faut pas le masquer. Scheduling : un orchestrateur Kubernetes doit gérer des nœuds aux caractéristiques très différentes, avec des contraintes de placement (un pod qui a besoin d’un TPU ne peut pas atterrir sur un nœud GPU). Observabilité : les métriques d’un TPU ne sont pas celles d’un GPU ; il faut instrumenter les deux. Gestion des coûts : un cluster hétérogène est plus difficile à budgéter qu’un cluster homogène. Portabilité des workloads : la promesse « ça tourne partout » mérite d’être confrontée à la réalité des performances par accélérateur — un modèle qui tourne sur les deux ne tourne pas forcément bien sur les deux.

La vraie question, pour une équipe plateforme, est : est-ce que la complexité opérationnelle de l’hétérogénéité est compensée par le gain de disponibilité et de coût ? La réponse dépend de l’échelle. Pour une petite équipe, un cluster homogène reste plus simple. Pour une organisation qui a des workloads divers et des contraintes de disponibilité, l’hétérogénéité devient rationnelle — à condition d’investir dans l’outillage.

---

TPU ou H100/H200 : la grille de décision honnête, et les cas où le TPU ne vaut pas le détour

Terminons par le verdict opérationnel, sans langue de bois.

Le TPU devient rationnel quand :

• Vous faites de gros entraînements distribués sur plusieurs semaines, avec des modèles denses ou MoE bien supportés. Le TPU excelle sur les matmuls denses, et TorchTPU supprime la barrière de réécriture qui rendait l’aventure coûteuse.
• Vous faites du serving à grande échelle avec caching de préfixe intensif. Le caching de préfixe est l’un des leviers de coût les plus puissants, et il est listé dans l’annonce TPU de vLLM/SGLang.
• Vous avez des contraintes de disponibilité GPU. Les H100/H200 sont rares et chers ; le TPU est disponible sur GCP.
• Vous êtes sur un cloud souverain qui n’offre pas de H100/H200. C’est un cas de plus en plus fréquent en Europe, où les contraintes réglementaires poussent vers des offres alternatives.
• Vous êtes déjà chez GCP. La migration est alors largement subventionnée par l’écosystème existant.

Le TPU ne vaut pas le détour quand :

• Vous dépendez lourdement de kernels CUDA custom (FlashAttention maison, quantization spécifique, ops fusionnées propriétaires). La réécriture coûtera plus qu’elle ne rapporte.
• Vous avez besoin de la dernière quantization ou d’un opérateur non couvert. La couverture PyTorch sur TPU n’est pas publiée dans le détail ; le risque de mauvaise surprise est réel.
• Vos cycles d’itération sont courts et le temps de compilation XLA tue la vélocité. Sur un projet de recherche où l’on change le modèle toutes les semaines, le coût de compilation peut dominer.
• Vos workloads sont multi-cloud et exigent une portabilité stricte. L’hétérogénéité a un prix opérationnel.

Ce que TorchTPU change vraiment, c’est la barrière d’entrée. Hier, faire du PyTorch sur TPU était un projet ; aujourd’hui, c’est une configuration. Mais TorchTPU ne supprime pas la spécificité du silicium — il la rend simplement accessible sans réécriture. Et c’est probablement très bien ainsi : un monde où tous les accélérateurs seraient interchangeables serait un monde où aucun ne serait optimisé. La bonne nouvelle du 20 octobre 2026, c’est qu’on peut désormais choisir son silicium sans choisir son framework.

---

Sources

• TorchTPU is now open source: Run native PyTorch on TPUs — Google Cloud Blog, 20 octobre 2026.
• note.com/prodready_ai — source secondaire relayant l’annonce du Google Developers Blog (20 octobre 2026), citée pour les détails techniques de TorchTPU, les partenariats Inferact/RadixArk et la liste des fonctionnalités des moteurs TPU.
• Google Cloud Ships llm-d 1.0 With Cache-Aware Routing for TPU and GPU Fleets — MarkTechPost, 20 octobre 2026.
• IBM-backed llm-d framework adds controls for running AI models in-house — SiliconANGLE, 20 octobre 2026.
• llm-d 1.0 Debuts at PyTorch Conference with Production Inference Stack — Unite.AI, 20 octobre 2026.
• void.ma — comparatif TPU vs GPU (chiffres de coût et de spécifications, source tierce unique, non recoupée).
• PyTorch DDP Tutorial — documentation officielle PyTorch, mise à jour le 23 septembre 2025 (contexte sur torch.distributed et DDP).