Google ouvre TorchTPU : PyTorch traite désormais le TPU comme un périphérique natif

Google a publié en accès libre TorchTPU, un stack logiciel complet pour exécuter PyTorch sur TPU comme sur un périphérique natif. L'annonce a eu lieu à la PyTorch Conference 2026, à San José. Si l'on réduit la nouvelle à une seule ligne de code, elle donne ceci : device_map="tpu". Dans Hugging Face Transformers, cela suffit pour que le modèle s'exécute sur les processeurs tensoriels de Google.

Sur le papier, c'est un détail. En pratique, cela vise l'avantage le plus durable de Nvidia. Le marché débat depuis dix ans de la puissance des puces, mais le choix d'un accélérateur dépend largement de l'effort nécessaire pour y faire tourner du code déjà écrit. CUDA ne tient pas seulement par ses performances, mais aussi par l'inertie : bibliothèques, habitudes, recettes d'entraînement toutes prêtes, savoir-faire des ingénieurs.

Pourquoi les TPU sont restés si longtemps réservés à une élite

Les TPU de Google passent depuis longtemps pour du matériel sérieux. L'entreprise y entraîne ses propres modèles et, ces dernières années, les loue de plus en plus à des clients externes. De grands laboratoires ont signé des accords portant sur d'importants volumes de capacité TPU, et Google a présenté la septième génération, Ironwood, comme une puce pour l'ère de l'inférence.

Ce qui freinait, ce n'était pas la puce, mais le pont entre elle et l'univers PyTorch. En interne, Google utilisait JAX, tandis que le reste de l'industrie écrivait en PyTorch. Pour exécuter PyTorch sur TPU, il existait PyTorch/XLA, mais le développeur lambda le percevait comme une discipline à part. Il fallait adapter le code, et le comportement différait du scénario habituel sur GPU. Beaucoup d'équipes revenaient à CUDA après une première tentative.

TorchTPU est présenté comme la réponse à ce problème. Plutôt qu'une couche intermédiaire à apprendre séparément, Google propose le TPU comme périphérique natif de PyTorch. Pour un utilisateur de Transformers, la frontière entre « modèle pour GPU » et « modèle pour TPU » se réduit à la valeur d'un seul paramètre.

Ce que Google a exactement ouvert

Selon Google, il ne s'agit ni d'un ensemble d'exemples ni d'un wrapper autour d'une ancienne solution, mais d'une chaîne complète qui permet à PyTorch de fonctionner sur TPU. Le code est ouvert, et c'est essentiel pour la confiance. Les développeurs n'aiment pas dépendre d'un logiciel fermé conçu pour le matériel d'un autre, surtout après de longues années passées dans un écosystème dominé par un leader incontesté.

Les faits clés de cette publication :

• le projet s'appelle TorchTPU et est distribué en open source ;
• l'annonce a été faite à la PyTorch Conference 2026, à San José ;
• l'objectif est de faire du TPU un périphérique natif de PyTorch ;
• l'interface pour l'utilisateur de Hugging Face Transformers : device_map="tpu" ;
• le principal adversaire n'est pas une puce précise, mais l'habitude des développeurs de travailler avec CUDA.

Le choix de Hugging Face comme vitrine semble délibéré. C'est là que la plupart des ingénieurs récupèrent pour la première fois un modèle ouvert, le lancent et décident où passer à l'échelle. Si le chemin vers le TPU y paraît aussi simple que celui vers le GPU, Google accède à une vaste audience qui n'avait jusque-là même pas envisagé son matériel.

Comment le vérifier en pratique

La nouvelle ne signifie pas qu'il sera possible dès demain de migrer n'importe quel pipeline en une ligne. Lancer un modèle de Transformers est une chose ; faire passer un entraînement de production avec des kernels personnalisés, des opérateurs non standard et du code distribué maison en est une autre. C'est précisément dans ces zones que se cache d'ordinaire la dépendance à CUDA.

Pour les équipes qui regardent du côté des TPU, il est raisonnable de procéder par étapes :

• prendre un modèle standard de Transformers et comparer, sur TPU et sur GPU, le coût de l'heure de calcul, et pas seulement la vitesse ;
• vérifier combien de kernels CUDA personnalisés et d'extensions tierces contient la base de code : c'est la principale source de douleur lors d'une migration ;
• tester séparément l'inférence et l'entraînement, car la maturité du stack peut différer fortement selon ces scénarios ;
• conserver une solution de repli sur GPU tant que TorchTPU n'a pas fait ses preuves sur votre charge de travail.

Pour le marché, l'enjeu est ailleurs. Tant que passer à des accélérateurs alternatifs obligeait à réécrire le code, Nvidia pouvait maintenir ses prix et ses conditions de livraison. Chaque mesure qui réduit le coût du changement donne aux acheteurs un levier de négociation, même si la plupart d'entre eux restent sur CUDA. Le fossé n'est pas comblé, mais Google vient de montrer où il est possible de le franchir.