TorchTPU : PyTorch natif sur les TPU de Google, et le prix d'un portage en une ligne
Google et Meta ont ouvert TorchTPU à la PyTorch Conference 2026 : PyTorch sur TPU avec l'eager d'abord, torch.compile via Dynamo, validé sur les 5 000 modèles Hugging Face les plus téléchargés. J'ai lu les billets PyTorch et Google Cloud et le dépôt - ce qui a été livré, pourquoi ce n'est pas PyTorch/XLA, et quelles affirmations restent aux fournisseurs.
TorchTPU : PyTorch natif sur les TPU de Google, et le prix d'un portage en une ligne
Le 20 octobre, lors de la PyTorch Conference 2026, Google et Meta ont ouvert le code de TorchTPU, un backend PyTorch natif pour les TPU de Google où le portage consiste, dans le meilleur des cas, à remplacer .to("cuda") par .to("tpu"). J'ai lu le billet du blog PyTorch, l'annonce Google Cloud et le dépôt le 26 octobre 2026. L'architecture est documentée avec un détail inhabituel ; les affirmations de performance appartiennent aux fournisseurs, et les deux entreprises qui financent le pont sont aussi celles qui ont le plus à gagner d'un monde où le code des modèles circule librement.
Ce qui a été livré
TorchTPU est un effort de Google lancé mi-2025 avec l'équipe PyTorch de Meta, publié en open source à la PyTorch Conference 2026 le 20 octobre, selon le blog PyTorch et le billet Google Cloud signé Mark Lohmeyer et Bill Jia. C'est un backend TPU écrit de zéro, et non une énième couche au-dessus de JAX : l'exécution eager est un mode de premier rang, torch.compile passe par Torch Dynamo et non par Lazy Tensors, et les idiomes distribués de PyTorch (DDP, FSDP, DTensor) reçoivent des collectifs TPU au niveau Process Group. Le dépôt google-pytorch/torch_tpu comptait 741 étoiles à ma lecture du 26 octobre et porte la licence Apache 2.0 dans son fichier LICENSE, appliquée à tous les fichiers - le détecteur de GitHub la signale comme non standard uniquement à cause d'une ligne d'en-tête. Le blog liste ce qui existe aujourd'hui : environ 450 ops Aten avec passages avant et arrière pour les ops Core ATen des architectures majeures, un mode eager DeferAndFuse, et l'écriture de noyaux personnalisés via JAX/Pallas ou le DSL Helion.
Pourquoi cette tentative n'est pas PyTorch/XLA
La partie la plus honnête de l'annonce est son autopsie de la tentative précédente. PyTorch/XLA, introduit en 2020, compilait via Lazy Tensors : selon les auteurs de TorchTPU, il exigeait des modifications invasives du source pour marquer les régions compilables, souffrait d'une latence de compilation sévère, n'avait pas de vrai mode eager et accusait un retard sur les primitives distribuées de PyTorch. C'est la nouvelle équipe décrivant le travail de l'ancienne, et les deux siègent chez Google - mais la critique correspond à ce que retient quiconque s'est battu avec les graphes XLA, et elle explique les trois principes de conception publiés. Citoyenneté PyTorch : aucune dépendance JAX dans le runtime, un mode eager solide et une compilation basée sur Dynamo avec des objectifs de performance similaires à la compilation JAX. Focus utilisateur : un modèle doit tourner tel quel après le changement d'une ligne, avec la réserve, énoncée dans le billet lui-même, que la performance de pointe exige toujours un travail sur les formes et le sharding, car les modèles sont optimisés pour l'architecture GPU. Améliorer l'état de l'art : une compilation JIT pour l'exécution eager, et un dynamisme borné pour que XLA cesse de recompiler à chaque changement de forme.
Ce que couvre la « validation »
Les affirmations de compatibilité sont assez précises pour être testées. Les billets disent que TorchTPU exécute directement les 5 000 modèles les plus téléchargés de Hugging Face - les familles citées incluent Qwen, DeepSeek, Gemma, Llama, Mistral, Whisper, CLIP, ViT, ResNet, BERT et T5 - et que Transformers v5 l'expose via device_map="tpu", avec Diffusers en natif et une CI nocturne de la suite Transformers sur infrastructure TPU. Le serving passe par vLLM et SGLang avec inférence multi-hôte, l'entraînement par TorchTitan, l'orchestration par Ray, plus TorchRec, llm-d et LiteRT. L'affirmation la plus forte est que TorchTPU fait déjà tourner de l'inférence et de l'entraînement en production pour certains des plus gros clients de Google Cloud. Ces clients ne sont pas nommés, donc cette phrase reste une affirmation du fournisseur et non une référence.
L'économie, attribuée
Reuters rapportait en décembre 2025 que Google travaillait avec Meta à éroder l'avantage logiciel de Nvidia, et cette version est à quoi ressemble ce reportage traduit en code. La citation de Meta dans le billet de Google, de la directrice de l'ingénierie PyTorch Jana van Greunen, dit que Meta « ne peut pas être contrainte par une seule architecture matérielle » et présente TorchTPU comme une flexibilité matérielle pour les charges LLM, publicitaires et de recommandation. Jeff Boudier de Hugging Face le présente comme une neutralité matérielle. Le cadrage de Google est le choix du client entre TPU, GPU et CPU sous un modèle opérationnel unique - en gardant à l'esprit que Google est aussi l'entreprise qui loue les TPU, donc le pont a son péage sur l'autre rive. Le fossé de Nvidia n'a jamais été seulement la puce ; c'était l'hypothèse que le code CUDA ne peut pas déménager. TorchTPU est une attaque financée et ingénierée contre cette hypothèse. Son succès sera décidé par les migrations, pas par les annonces : le premier post-mortem public d'un vrai run d'entraînement déplacé de GPU vers TPU vaudra plus que tout ce qui a été publié cette semaine.
Ce que je n'ai pas vérifié
Je n'ai pas exécuté de charge PyTorch sur un TPU. Chaque affirmation de performance ici - débit « compétitif pour l'industrie », réduction de l'écart entre eager et compilé, compilation Dynamo à la hauteur de JAX - appartient au fournisseur, comme la liste de compatibilité des 5 000 modèles et l'affirmation des clients en production. La critique de PyTorch/XLA émane des auteurs de TorchTPU eux-mêmes. Le nombre d'étoiles et la licence ont été lus dans le dépôt le 26 octobre 2026.