Google ouvre TorchTPU aux développeurs PyTorch

Google publie TorchTPU le 21 octobre 2026 pour exécuter nativement des modèles PyTorch sur ses unités de traitement tensoriel. Le projet est disponible gratuitement sur GitHub. Google annonce aussi la prise en charge des TPU dans vLLM, SGLang, TorchTitan, Ray et les bibliothèques Hugging Face. Les équipes qui développent en PyTorch et utilisent principalement des processeurs graphiques sont directement concernées. Selon Google, leurs charges peuvent passer sur TPU avec peu de changements de code. Cette promesse permettrait de tester les puces conçues par Google sans reconstruire entièrement les logiciels existants. Elle reste toutefois formulée comme une possibilité à vérifier en pratique selon les modèles et les usages.

Le flux PyTorch reste standard avec TorchTPU. Les développeurs peuvent déboguer en mode eager, où chaque opération s’exécute dès son appel. Ils peuvent ensuite utiliser torch.compile pour transformer le modèle en graphe optimisé destiné à la production. Les primitives d’entraînement distribué sont intégrées. Hugging Face réduit aussi le changement à un argument dans Transformers v5. La valeur device_map=“tpu” envoie alors un modèle vers un TPU. Google exécute chaque nuit la suite de tests de Transformers sur ces puces. La bibliothèque Diffusers fonctionne également nativement. Elle prend en charge le parallélisme tensoriel entre plusieurs puces. Ces intégrations couvrent donc l’entraînement, l’inférence et les modèles génératifs.

PyTorch étend ses supports matériels

Meta utilise déjà TorchTPU pour certains cas de production liés aux modèles de langage, à la publicité et aux recommandations. Jana van Greunen, directrice de l’ingénierie PyTorch chez Meta, explique que l’entreprise ne peut pas dépendre d’une seule architecture matérielle. Cette déclaration accompagne l’ouverture de TorchTPU et son intégration dans plusieurs outils de l’écosystème PyTorch. Google indique aussi que TorchTitan avec TorchTPU atteint jusqu’à 52 % d’utilisation des capacités théoriques de calcul sur Qwen 3 8B. Le résultat conserve une mise à l’échelle presque linéaire jusqu’à 8 192 TPU Ironwood. Ce chiffre mesure la part des capacités de calcul utilisées pour l’entraînement utile.

Les résultats d’inférence progressent aussi avec llm-d, un routeur en code ouvert qui répartit les requêtes entre plusieurs grappes. Google a publié llm-d 1.0 avec Red Hat et IBM. Zenteiq.ai indique que llm-d sur Google Kubernetes Engine a fait passer sa production quotidienne de 1,47 milliard à 5,97 milliards de jetons pour 1 000 TPU v6e. Cette hausse représente environ un facteur quatre. Zenteiq attribue ce résultat au routage des requêtes vers une réplique conservant déjà leur contexte. Le chiffre concerne donc une configuration précise, avec un nombre défini de puces et une architecture de routage particulière. Il ne constitue pas une mesure générale de tous les déploiements TPU.

Deux composants restent en aperçu

Deux intégrations restent en aperçu dans l’écosystème présenté par Google. La première est le backend TPU apporté à VeRL, un framework utilisé pour l’apprentissage par renforcement. La seconde est une suite d’agents TPU destinée aux outils de programmation assistée par IA. Elle doit automatiser l’intégration, le diagnostic et l’optimisation de l’inférence pour les modèles PyTorch. Google a également intégré LiteRT, auparavant appelé TensorFlow Lite, à l’écosystème PyTorch. LiteRT vise l’exécution de modèles sur des téléphones et d’autres appareils. Les développeurs disposent ainsi d’un parcours couvrant les TPU de centre de données et certains usages sur appareils périphériques, tandis que deux briques restent en phase d’aperçu.