Le jour de la PyTorch Conference 2026, Google Cloud a annoncé que TorchTPU, développé avec l'équipe PyTorch de Meta, est désormais en open source sur GitHub. Selon Google, le TPU devient, comme le GPU et le CPU, une option de périphérique native de PyTorch, et le code existant fonctionne presque sans modification.
L'annonce est signée de Mark Lohmeyer, vice-président IA et infrastructure de calcul de Google Cloud, et de Bill Jia, vice-président de l'ingénierie. Le dépôt de code se trouve dans l'organisation google-pytorch ; les backends vLLM et SGLang qui l'accompagnent ont été intégrés aux organisations de leurs projets respectifs.
Un seul code ouvert, une série de frameworks raccordés
TorchTPU prend en charge le débogage en mode eager et peut aussi passer par torch.compile pour mieux exploiter le TPU et réduire l'empreinte mémoire. De nombreux projets en amont et en aval ont été intégrés le même jour :
- Inférence : vLLM et SGLang disposent chacun d'un backend PyTorch natif. Le premier gère le batching continu, la quantification et le parallélisme multipuce ; le second s'appuie sur RadixAttention pour réutiliser le cache KV. llm-d 1.0, publié avec Red Hat et IBM, assure le routage sensible au cache de préfixes ainsi que la séparation du prefill et du decode.
- Entraînement : TorchTitan a validé des modèles tels que Llama 3 70B/405B, Qwen 3 8B/32B, Qwen 3 235B (MoE) et FLUX.1 12B ; le framework d'apprentissage par renforcement VeRL a intégré un backend TPU et une recette de référence GRPO, actuellement en préversion.
- Écosystème : Hugging Face Transformers v5 charge un modèle sur TPU en une ligne,
device_map="tpu", et dispose en plus d'une intégration continue TPU exécutée chaque nuit ; Ray peut assembler CPU, GPU et TPU dans un même pipeline.
Google présente deux séries de chiffres de performance. TorchTitan atteint 52 % de MFU sur Qwen 3 8B et passe à l'échelle de façon quasi linéaire jusqu'à 8 192 puces Ironwood (TPU v7x). Le partenaire Zenteiq, avec llm-d et GKE, a vu la génération quotidienne pour 1 000 TPU v6e passer de 1,47 milliard à 5,97 milliards de tokens, soit plus de 4 fois plus. Les deux séries proviennent de mesures de Google ou de ses partenaires, et l'annonce ne fournit pas la configuration complète permettant de les reproduire.
Pourquoi Meta soutient le projet
Jana van Greunen, directrice de l'ingénierie PyTorch chez Meta, livre une déclaration dans l'annonce :
« We cannot be constrained by a single hardware architecture. »
Nous ne pouvons pas être enfermés dans une seule architecture matérielle.
Elle indique que TorchTPU soutient déjà des « scénarios de production critiques » dans les grands modèles, la publicité et les systèmes de recommandation de Meta. Le nombre de TPU utilisés et la part qu'ils représentent dans la puissance de calcul de Meta n'ont pas été dévoilés cette fois. Hugging Face, Inferact (derrière vLLM) et RadixArk (derrière SGLang) ont eux aussi réagi, tous en insistant sur la « diversité matérielle ».
La même semaine, AWS a aussi sorti sa version
En rapprochant TorchTPU de TorchNeuron, annoncé la veille par AWS, on voit que les deux géants suivent la même voie. TorchNeuron est le backend PyTorch natif de Trainium, en open source sous licence Apache 2.0, en bêta publique depuis le 20 octobre, et prend en charge Trainium2 et Trainium3 ; l'utilisateur n'a qu'à écrire .to('neuron'). Il met lui aussi en avant Transformers v5 et TorchTitan, et le même directeur de l'ingénierie PyTorch de Meta a également signé un témoignage pour AWS.
La différence tient aux détails. AWS a rendu public son protocole de test : un test en aveugle sur 100 000 modèles Hugging Face, avec environ 154 000 résultats issus des tests amont de PyTorch, dont environ 39 000 ont été volontairement ignorés par Neuron, notamment des fonctions que la première version ne gère pas, comme les tenseurs creux et les formes dynamiques. Google, de son côté, se contente de lister les éléments pris en charge ; quels opérateurs retombent sur le CPU et quelles fonctions manquent, l'annonce ne le détaille pas avec la même précision.
Les deux s'appuient sur les interfaces indépendantes du périphérique que la communauté PyTorch a construites ces dernières années, comme le point d'extension PrivateUse1 et torch.accelerator. Jusqu'ici, les utilisateurs de PyTorch qui voulaient exploiter un TPU passaient surtout par PyTorch/XLA, qui traduit le code via le compilateur XLA, et dont l'expérience de débogage a toujours été critiquée. Avec un backend natif, la barrière de migration passe de « modifier le code » à « changer le nom du périphérique ».
Pour les développeurs, le test le plus concret concerne les modèles absents de la liste de validation officielle. La documentation de TorchTPU ne mentionne que les TPU v6e et Ironwood ; les générations plus anciennes fonctionnent-elles, et avec quelles performances, Google ne l'a pas encore précisé. Le plugin d'agent TPU qui l'accompagne en est lui aussi à un stade très précoce de préversion.
Sources : blog officiel de Google Cloud, blog officiel de PyTorch (annonce de TorchNeuron), CocoLoop, dépôt GitHub de TorchTPU ; les chiffres de MFU et de débit reposent sur les mesures propres de Google et de ses partenaires.