TorchTPU : Google et Meta ouvrent PyTorch aux TPU

Google a publié TorchTPU le 20 octobre 2026 à la conférence PyTorch, en open source, avec l'équipe PyTorch de Meta. Le projet fait tourner PyTorch directement sur les puces TPU de Google, sans passer par la couche intermédiaire qui servait jusqu'ici. Quatre dépôts sortent d'un coup : TorchTPU, vLLM-TorchTPU, SGLang-TorchTPU et TorchTitan.

Votre PME ne va pas acheter de TPU. L'effet vous atteindra par la facture : pendant dix ans, entraîner et servir un modèle supposait des cartes Nvidia et la bibliothèque CUDA. Quand un deuxième matériel devient utilisable sans réécrire le code, les prix d'inférence bougent, et vos fournisseurs d'IA achètent moins cher.

Ce que Google a publié, en clair

PyTorch est la bibliothèque avec laquelle la majorité des équipes de recherche écrivent leurs modèles. Jusqu'ici, faire tourner du PyTorch sur un TPU passait par PyTorch/XLA, une passerelle qui traduisait le code.

Google décrit sans détour les limites de cette passerelle : elle exigeait des modifications intrusives du code source pour délimiter les parties compilables, souffrait d'une latence de compilation sévère, et ne supportait pas le mode eager, celui où chaque opération s'exécute à la ligne, qui est la façon normale de déboguer en PyTorch.

TorchTPU supprime la traduction. Google annonce qu'un passage sur TPU doit se résumer à remplacer `model.to("cuda")` par `model.to("tpu")`, et précise dans la même phrase qu'on n'atteint pas les performances maximales avec ce seul changement. L'honnêteté de cette nuance vaut mieux que la promesse.

Les chiffres annoncés, et ce qu'ils mesurent

Google publie des mesures sur ses propres puces. Sur TPU v7x, baptisée Ironwood, TorchTitan entraîne un Llama 3 405B réparti sur 1 024 puces, avec une fenêtre de 8 000 tokens en BF16 : 500 tokens par seconde et par puce, et plus de 50 % de MFU. Le MFU mesure la part de la puissance théorique de la puce réellement utilisée, et dépasser 50 % sur un entraînement de cette taille est un bon résultat.

Google évalue aussi Qwen3 235B, un modèle à mélange d'experts, sur 8 192 puces de la même génération.

Ces chiffres sortent du fournisseur du matériel, sur ses propres machines, sur des modèles qu'il a choisis. Ils montrent que la chaîne fonctionne à grande échelle. Ils ne disent pas ce que coûtera votre jeton chez un hébergeur tiers.

Pourquoi le verrou CUDA tient depuis si longtemps

CUDA n'est pas une puce, c'est la couche logicielle qui permet d'écrire du calcul pour les cartes Nvidia. Nvidia l'a lancée en 2007 et a passé quinze ans à la rendre indispensable.

Le verrou ne tient pas au matériel, il tient aux habitudes. Un chercheur écrit son code avec CUDA parce que tous ses exemples sont en CUDA. Une bibliothèque nouvelle sort d'abord pour CUDA parce que c'est là que sont ses utilisateurs. Une entreprise qui veut recruter cherche des gens qui connaissent CUDA. Chaque maillon renforce le suivant.

Casser ce cercle demande qu'un matériel concurrent devienne utilisable sans réapprendre. C'est exactement ce que vise un backend natif : garder le code PyTorch et changer une ligne.

Ce que ça change pour le prix que vous payez

Vous n'achetez pas de calcul, vous achetez des jetons. Quand OpenAI, Anthropic ou Mistral vous facturent au million de tokens, le prix de leurs machines se retrouve dans ce tarif.

Un fournisseur qui peut arbitrer entre deux matériels négocie mieux ses achats et encaisse moins les tensions d'approvisionnement. Sur deux ou trois ans, cet arbitrage pousse les tarifs d'inférence vers le bas, comme il l'a fait sur l'hébergement web quand les fournisseurs de serveurs se sont multipliés.

Ne comptez pas sur une baisse ce trimestre. Les prix publics des modèles bougent par paliers, au rythme des nouvelles générations. Ce qui change dès maintenant, c'est la direction.

Le signal industriel : Meta travaille avec Google

Le détail le plus intéressant n'est pas technique. Meta maintient PyTorch. Google vend des TPU et a tout intérêt à ce que PyTorch y tourne bien. Les deux entreprises se concurrencent sur à peu près tout le reste.

Elles ont quand même travaillé ensemble sur ce backend depuis mi-2025. Une collaboration de ce type coûte cher et n'arrive pas par hasard. Elle indique que les deux considèrent la dépendance à un fournisseur unique de calcul comme un problème à traiter, pas comme un inconvénient à subir.

Pour une PME, ce signal vaut une ligne dans vos arbitrages : la couche sur laquelle tourne l'IA se banalise, donc l'avantage durable ne viendra pas de votre fournisseur de modèle.

Ce que vous avez à faire, et ce que vous pouvez ignorer

Vous pouvez ignorer la technique. TorchTPU s'adresse aux équipes qui entraînent des modèles, pas à celles qui les utilisent.

Gardez trois réflexes de gestion. Écrivez vos automatisations de façon à pouvoir changer de modèle : si votre chaîne appelle une API directement depuis vingt scénarios Make ou n8n, passer d'un fournisseur à l'autre vous coûtera des jours. Un point de passage unique rend l'arbitrage possible.

Évitez les engagements longs à prix fixe sur l'inférence. Dans un marché où les coûts baissent, un contrat de trois ans vous enferme au tarif d'aujourd'hui.

Et vérifiez une fois par an ce que vous payez, modèle par modèle. Le prix d'un service vieux de dix-huit mois dans vos automatisations a souvent une version plus récente et moins chère chez le même fournisseur. C'est la partie du travail que nous reprenons à chaque point d'étape sur les chaînes d'automatisation que nous maintenons.