LLM auto hébergées · 28 October 2026

TorchTPU passe open source : PyTorch natif sur TPU, et si votre prochain serveur LLM local n’était plus un GPU ?

Le 20 octobre 2026, à la PyTorch Conference, Google a ouvert le code de TorchTPU : le pont qui fait tourner du PyTorch natif sur TPU sans bricoler JAX/XLA à la main. Sur le papier, c’est un changement de backend. En pratique, c’est une question qui va hanter tous ceux dont la VRAM est saturée : et si le prochain rack d’inférence n’était plus une pile de cartes graphiques ?

Il y a une scène que tout le monde connaît dans le petit monde du self-hosting de LLM. Vous avez téléchargé les poids d’un modèle open weights un peu trop ambitieux, vous regardez votre RTX avec ses 24 Go (ou votre 5090 avec ses 32 Go) et vous comprenez que ça ne rentrera pas. Alors vous quantifiez plus fort, vous coupez le contexte, vous priez pour que le KV cache tienne. Puis vous regardez le prix d’une deuxième carte, d’un serveur Strix Halo à mémoire unifiée, d’un mini-PC à 128 Go unifiés — et vous vous demandez si vous ne vous êtes pas trompé de métier.

C’est dans ce décor que tombe l’annonce du 20 octobre 2026 : TorchTPU est désormais open source, sur le dépôt github.com/google-pytorch/torch_tpu, avec un paquet torch-tpu publié en version 0.2.0 sur PyPI. Google présente l’opération comme un co-développement avec l’équipe PyTorch de Meta, et comme le moment où « le TPU devient un backend nativement supporté pour PyTorch, aux côtés du GPU et du CPU ». Côté écosystème, le partenariat avec Hugging Face est mis en avant : Transformers v5 supporterait device_map="tpu", Diffusers tournerait nativement sur TPU, et les CI/CD nightly seraient exécutées sur infrastructure TPU.

La vraie question n’est pas « est-ce que Google aime PyTorch ». Elle est : le TPU redevient-il une option crédible pour faire tourner des modèles chez soi, ou reste-t-il un pari réservé aux équipes qui ont déjà un compte Cloud ? Et pour y répondre honnêtement, il faut séparer ce que TorchTPU fait vraiment de ce qu’il promet, ce qu’il ne fait pas encore, et ce qu’il coûte réellement.

Ce que TorchTPU fait vraiment : du graphe PyTorch au silicium TPU

Commençons par le concret, celui qu’on peut lire dans le README du dépôt plutôt que dans un communiqué. TorchTPU n’est pas un nouveau framework : c’est une couche de compatibilité qui branche PyTorch sur le compilateur XLA et le runtime PJRT de Google, lesquels parlent ensuite au silicium TPU. Le pipeline ressemble, dans les grandes lignes, à ce que fait déjà torch.compile sur GPU : capture du graphe par TorchDynamo, abaissement via TorchInductor, puis passage à XLA/PJRT pour la compilation et l’exécution sur TPU.

Ce que le dépôt documente explicitement, et qui est vérifiable parce que c’est un artefact public :

• Support Python 3.11 et supérieur ;
• des kernels ATen custom pour TPU — autrement dit, les opérations de base de PyTorch ont des implémentations dédiées, pas seulement un fallback générique ;
• un cache de compilation XLA, ce qui est loin d’être un détail : sans lui, chaque changement de forme de tenseur relance une compilation, et la latence explose ;
• le support du data parallelism et du tensor parallelism, c’est-à-dire la capacité à répartir un modèle ou un batch sur plusieurs puces ;
• des exemples fournis : Llama, Qwen, ResNet, DLRM, minGPT, UNet.

Cette liste est courte mais elle dit l’essentiel : on n’est pas sur une démo qui fait tourner un hello-world de tenseurs, mais sur un stack qui couvre à la fois l’inférence de LLM (Llama, Qwen), la vision (ResNet, UNet) et les modèles de recommandation (DLRM). Le support du tensor parallelism est le signal le plus intéressant pour quiconque vise des modèles qui ne tiennent pas sur une puce.

En revanche, il faut être clair sur ce que la matière ne dit pas. Aucune source fournie ne détaille la couverture exacte des opérateurs — combien sont natifs, combien sont émulés, combien déclenchent un fallback CPU. Aucune ne documente la stratégie de gestion de la mémoire HBM (allocation, fragmentation, offload), ni les précisions réellement supportées en pratique (bf16 oui, sans doute ; fp8 et int8, on ne peut pas l’affirmer sur la base des extraits disponibles). C’est un point à garder en tête : le README est un artefact vérifiable, le blog est un communiqué. Là où les deux divergent, c’est le dépôt qu’il faut croire — et le dépôt, pour l’instant, est avare en détails sur les points qui fâchent.

Un détail technique mérite qu’on s’y arrête : le fallback. Dans tout stack de compilation de graphes, la question n’est pas « est-ce que ça compile », mais « que se passe-t-il quand une opération n’est pas supportée ». Sur GPU, PyTorch a des années d’ingénierie pour que le graphe se casse proprement et retombe sur du code non compilé. Sur TPU, la chaîne XLA est plus rigide, et le comportement en cas de dynamic shapes (formes de tenseurs qui changent à chaque requête, ce qui est la norme en inférence avec des prompts de longueurs variables) est précisément le genre de détail qui décide si un stack est utilisable en production ou seulement en benchmark. TorchTPU annonce un cache de compilation, ce qui suggère que le problème a été pris au sérieux. Mais sans retours d’expérience indépendants, on reste sur une présomption favorable, pas sur une certitude.

Ce que TorchTPU ne fait pas encore : la liste honnête des angles morts

La version 0.2.0 est le premier aveu. Un projet qui sort en 0.2.0 n’est pas un projet qui sort en 1.0 : c’est un projet qui existait avant l’open source, qui a été suffisamment mûr pour être publié, mais qui n’a pas encore stabilisé son API ni son périmètre. Cela signifie concrètement que les interfaces peuvent bouger, que les breaking changes sont probables, et que bâtir une infrastructure de production dessus en octobre 2026 demande soit du courage, soit un plan de repli.

Ensuite, il y a les angles morts documentés — ou plutôt non documentés, ce qui est tout aussi parlant :

• La licence du dépôt n’est pas confirmée dans les extraits disponibles. C’est un point bloquant pour toute entreprise : avant de faire tourner votre stack sur un projet, vous voulez savoir si vous pouvez le modifier, le redistribuer, le vendre intégré. Apache 2.0 ? BSD ? À vérifier directement sur le repo avant d’aller plus loin.
• Aucune roadmap publique n’apparaît dans les sources. On ne sait pas quand arrivera une v1.0, ni quel périmètre elle couvrira. Pour un projet qui prétend devenir un backend de premier plan, c’est un manque de signal fort.
• Le fine-tuning et la quantisation ne sont pas documentés dans les extraits fournis. Or c’est précisément là que se joue une grande partie de l’usage réel : un homelabber qui veut LoRA-fine-tuner un modèle sur ses propres données, ou faire tourner un modèle en int8 pour tenir dans la mémoire, n’a aucune garantie que TorchTPU le supporte aujourd’hui.
• Les opérateurs custom (ceux qu’on écrit soi-même, ou ceux de bibliothèques tierces) sont l’ennemi juré de tout compilateur de graphes. Sans documentation claire sur la procédure pour enregistrer un opérateur custom sur TPU, on peut supposer que c’est possible mais coûteux en effort.
• Les intégrations revendiquées — vLLM, SGLang, llm-d, TorchTitan, Ray, TorchRec, LiteRT — relèvent du communiqué marketing. Aucune n’est recoupée par une source indépendante dans la matière disponible. Cela ne veut pas dire qu’elles sont fausses ; cela veut dire qu’il faut les vérifier soi-même, en clonant le repo et en lançant un pip install avant de bâtir une architecture dessus.

Un mot sur le contexte de l’annonce, aussi. TorchTPU arrive après plusieurs années où PyTorch sur TPU existait déjà — Google documente officiellement PyTorch sur Cloud TPU — mais via une chaîne XLA/PJRT qui n’était pas exactement « native », et qui demandait de composer avec l’écosystème JAX. L’ouverture de TorchTPU, c’est la promesse de réduire cette friction. La réalité de la friction restante, elle, n’est pas encore mesurée publiquement.

Le vrai prix d’un token : TPU contre RTX, Strix Halo et le watt-heure

C’est ici que l’article devrait pouvoir dérouler des tableaux de tokens par seconde, des coûts par million de tokens, des comparaisons v5e/v5p/v6e contre RTX 4090/5090. Et c’est ici qu’il faut être honnête : la matière disponible ne contient aucun benchmark indépendant de TorchTPU ou de TPU d’inférence face à des GPU grand public. Pas de débit Llama 3.x sur TPU v5e, pas de latence Qwen sur v6e, pas de coût par million de tokens vérifié. Les seuls chiffres TPU disponibles dans nos sources sont des chiffres marketing relayés par des médias secondaires : TPU 8t annoncé « jusqu’à 2,8× plus rapide que les TPU Ironwood » pour l’entraînement, TPU 8i annoncé à « +80 % de performance par dollar » pour l’inférence LLM. Ces chiffres sont invérifiables en l’état, et la métrique « perf/$ » est notoirement dépendante du workload.

Ce qu’on peut dire sans inventer, en revanche, c’est la structure du problème. Un GPU grand public, c’est un achat unique, une consommation électrique connue, et un écosystème logiciel mature. Un TPU, c’est aujourd’hui principalement une location à l’heure via Cloud TPU, ou un accès via un fournisseur tiers, ou — pour les plus aventureux — du matériel déclassé via des marketplaces. Ces trois modèles économiques n’ont rien à voir :

Le point clé, c’est que le TPU n’est pas en concurrence frontale avec une RTX sur le terrain du « je veux faire tourner un 8B chez moi ce soir ». Il est en concurrence avec un serveur GPU loué ou un rack multi-GPU, c’est-à-dire sur le terrain du batch serving et du multi-modèles. Et sur ce terrain, le calcul n’est pas « combien coûte la carte », mais « combien coûte le million de tokens produit sur douze mois, électricité et amortissement inclus ». Sans benchmarks indépendants, on ne peut pas trancher — mais on peut au moins poser la bonne équation.

HBM, ICI et XLA : l’anatomie d’un match TPU vs GPU

La comparaison structurelle, elle, est plus solide que la comparaison chiffrée, parce qu’elle repose sur des différences d’architecture documentées.

La mémoire. Un GPU grand public, c’est de la VRAM soudée à la carte : 24 Go sur une 4090, 32 Go sur une 5090. Un mini-PC à mémoire unifiée type Strix Halo, c’est 96 à 128 Go partagés entre CPU et GPU — plus de capacité, mais une bande passante inférieure à de la GDDR dédiée. Un TPU, c’est de la HBM par puce, avec la possibilité d’agréger plusieurs puces. La conséquence pratique est simple : pour un modèle qui ne tient pas sur une carte, le TPU offre une voie de passage là où le GPU grand public bute. C’est exactement le scénario des modèles open weights qui grossissent — et l’actualité récente ne contredit pas cette tendance, avec des modèles de plus en plus ambitieux publiés en open weights.

L’interconnexion. Les TPU sont conçus pour être interconnectés via ICI, ce qui permet de faire du tensor parallelism à l’échelle d’un pod. Sur GPU grand public, le multi-carte passe par NVLink (quand il est disponible) ou par PCIe, avec des performances très variables. Pour du batch serving ou de l’entraînement distribué, l’avantage structurel du TPU est réel.

L’écosystème. Ici, le GPU écrase tout. CUDA, c’est quinze ans d’outils, de bibliothèques, de forums, de Stack Overflow. XLA, c’est puissant mais c’est un monde à part, avec ses propres abstractions, ses propres messages d’erreur, sa propre communauté. TorchTPU réduit la friction, mais il ne la supprime pas : vous restez dans un univers où le débogage d’un graphe qui ne compile pas demande des compétences différentes de celles d’un débogueur CUDA.

Où le TPU gagne : batch serving à grande échelle, modèles qui dépassent la capacité d’une carte unique, workloads multi-chips, entraînement distribué. Où le GPU reste roi : mono-utilisateur interactif, latence au token, quantisation mature (GGUF, int4/int8), écosystème logiciel, et — surtout — le coût d’entrée pour un particulier.

Batch serving, agents, RAG : les scénarios où le TPU tient déjà la corde

Ici, il faut être très clair : aucun retour d’expérience documenté de self-hosting TPU n’est disponible dans nos sources. Pas de startup qui raconte son migration, pas de labo qui publie ses benchmarks, pas de homelabber qui poste son rack. C’est une lacune majeure, et elle doit tempérer tout enthousiasme.

Cela dit, on peut raisonner par scénario, en s’appuyant sur ce que TorchTPU supporte explicitement (data/tensor parallelism, exemples Llama et Qwen) et sur la structure des workloads.

Le batch serving est le scénario le plus favorable. Vous avez un corpus de requêtes à traiter, la latence par requête compte moins que le débit global, et vous pouvez saturer plusieurs puces. C’est exactement le terrain de jeu du tensor parallelism et du multi-chips. Si vous produisez des millions de tokens par jour pour un pipeline de génération, de résumé ou d’annotation, la location à l’heure d’un TPU devient une option à évaluer sérieusement — à condition de mesurer le coût réel par token, ce que personne ne peut faire sans benchmark.

Les agents sont un cas intermédiaire. Un agent, c’est une boucle avec des appels d’outils, de la mémoire, du contexte long. Le débit compte, mais la latence au premier token compte aussi, parce que l’utilisateur attend. Et surtout, un agent fait souvent tourner plusieurs modèles : un gros pour le raisonnement, un petit pour le routage, un autre pour l’extraction. Le multi-modèles est un scénario où la capacité mémoire agrégée du TPU peut aider — mais où la complexité opérationnelle augmente aussi.

Le RAG est le scénario le plus ambigu. Le RAG, c’est de l’inférence avec du contexte long, ce qui sollicite énormément le KV cache et donc la mémoire. Un TPU avec de la HBM par puce peut avoir un avantage structurel sur ce point. Mais le RAG, c’est aussi un pipeline complet avec une base vectorielle, un reranker, un orchestrateur — et là, on est dans du logiciel classique, où le TPU n’apporte rien de spécifique.

Les pièges opérationnels sont réels et mal documentés : le réseau (un TPU dans le cloud, c’est de la bande passante à provisionner), le stockage (les poids de modèles pèsent des dizaines ou centaines de Go), l’orchestration (Kubernetes sur TPU, c’est un sujet en soi), le monitoring (les outils classiques ne connaissent pas XLA). Aucun de ces points n’est traité dans les sources disponibles, et c’est précisément ce qui manque pour passer de « ça marche dans un notebook » à « ça tourne en production ».

Le verdict nuancé : pour qui c’est déjà pertinent, pour qui c’est encore un pari

Après tout ça, la synthèse décisionnelle se dessine assez nettement.

TorchTPU est déjà actionnable en 2026 pour :

• Les équipes qui font du batch serving à grande échelle et qui ont déjà un compte Cloud, parce que la location à l’heure est un modèle économique qui leur est familier et que le tensor parallelism est supporté.
• Les équipes déjà sur XLA ou JAX, parce que TorchTPU leur ouvre PyTorch sans les sortir de leur écosystème de compilation.
• Les budgets GPU saturés : quand une RTX 5090 ne suffit plus et qu’un rack multi-GPU coûte plus cher qu’une location TPU à l’usage, l’arbitrage mérite d’être posé.
• Les projets qui font tourner des modèles qui ne tiennent pas sur une carte — Llama, Qwen de grande taille — et qui ont besoin de tensor parallelism.

TorchTPU est encore un pari pour :

• Le homelabber mono-GPU qui veut faire tourner un 8B quantifié en int4 ce soir. TorchTPU ne lui apporte rien aujourd’hui, et la quantisation n’est pas documentée.
• Les équipes qui font du fine-tuning intensif : rien dans les sources ne confirme que TorchTPU supporte le fine-tuning de manière satisfaisante.
• Ceux qui dépendent de la quantisation agressive (int4, GGUF) pour tenir dans la mémoire : c’est l’angle mort le plus criant.
• Ceux qui ont besoin d’une licence claire avant de s’engager : à vérifier sur le repo avant tout.

Les signaux à surveiller avant de migrer son rack :

1. Le passage en v1.0, qui signalerait une stabilisation de l’API.
2. La clarification de la licence du dépôt.
3. La publication d’une roadmap publique, notamment sur le fine-tuning et la quantisation.
4. Des benchmarks indépendants — MLPerf, retours communautaires, tests tiers — sur les débits et coûts réels.
5. La disponibilité de TPU déclassés via des marketplaces, qui changerait l’équation économique pour les particuliers.

Ce que ça change : la fin du monopole CUDA dans le self-hosting ?

TorchTPU n’est pas qu’un projet technique. C’est un signal.

Le premier signal, c’est celui de la diversification du silicium d’inférence. Pendant des années, « faire tourner un LLM chez soi » signifiait « acheter une NVIDIA ». CUDA était le péage obligatoire. L’ouverture de TorchTPU, c’est Google qui dit : PyTorch est un standard, et nous voulons que le TPU soit un backend de premier plan pour ce standard. C’est une pression directe sur NVIDIA, dont la position repose autant sur son silicium que sur son écosystème logiciel.

Le deuxième signal, c’est la stratégie Cloud TPU de Google. En ouvrant TorchTPU, Google réduit la friction d’entrée vers son infrastructure. C’est un pari classique : ouvrir le logiciel pour vendre le matériel. Et cela s’inscrit dans une actualité plus large — la huitième génération de TPU annoncée à Google Cloud Next en avril 2026, avec deux puces distinctes (TPU 8t pour l’entraînement, TPU 8i pour l’inférence), et l’abandon d’x86 au profit de cœurs Axion (Arm) pour coupler ces puces. Ces informations proviennent de sources secondaires (The Register relayé par MulerTech) et ne sont pas recoupées par un communiqué Google primaire dans notre matière — il faut donc les prendre avec les précautions d’usage. Mais la direction est claire : Google industrialise son silicium d’inférence.

Le troisième signal concerne l’écosystème open weights. Le partenariat avec Hugging Face — device_map="tpu" dans Transformers v5, Diffusers natif sur TPU, CI/CD nightly sur infra TPU — est une manière de dire aux développeurs : vos modèles Hugging Face tourneront sur TPU sans que vous ayez à réécrire quoi que ce soit. Si ça marche, c’est un changement de paradigme pour le self-hosting. Si ça ne marche qu’à moitié, c’est un argument marketing de plus.

Et pour le homelabber qui regarde son compte en banque avant sa VRAM ? La réponse honnête est : pas encore. TorchTPU ne remplace pas votre RTX ce soir. Il ouvre une porte que beaucoup pensaient fermée — celle d’un silicium d’inférence qui n’est pas NVIDIA — et il faudra quelques mois, une v1.0, une licence claire et des benchmarks indépendants pour savoir si cette porte mène quelque part. En attendant, la meilleure chose à faire est peut-être la plus simple : cloner le repo, lire le README, vérifier la licence, et lancer un exemple Llama sur un Cloud TPU à l’heure. Pour le prix de quelques heures de location, vous saurez si le pari en vaut la chandelle.

Sources

• TorchTPU is now open source: Run native PyTorch on TPUs — Google Cloud Blog
• PyTorch on Cloud TPU — Google Cloud Documentation
• google-pytorch/torch_tpu — GitHub
• Google TPU 8 : faut-il miser sur ces nouveaux accélérateurs IA ? — MulerTech (citant The Register, 22 avril 2026)
• The Best Open Source and Open-Weight LLM Models to Run Locally in 2026 — Hugging Face
• Best Hardware for Running Open-Source AI Models Locally in 2026 — Memeburn
• LLM Inference Optimization: 2026 Update — Wei’s Learning Notes
• Local AI Performance & Optimization (2026 Admin Guide) — FOSS Linux

Article recherché et rédigé automatiquement · Magazine Electrosens