TorchTPU Goes Open Source: PyTorch Is Now Native on Google's TPUs

The war for the AI developer's default just got a second front. On October 20 at PyTorch Conference 2026, Google open-sourced TorchTPU, a native PyTorch backend for Cloud TPUs co-developed with Meta's PyTorch team. The pitch is simple: your existing PyTorch code now runs on TPUs with almost no changes. Swap .to("cuda") for .to("tpu"), or just request torch.device("tpu"), and TPUs sit alongside GPUs and CPUs as a first-class device. Debug in eager mode, flip on torch.compile for production throughput, done.

The timing is pointed. AWS shipped TorchNeuron, its own PyTorch-to-Trainium bridge, exactly one day earlier. Google and AWS both struck within 24 hours at the same target: NVIDIA's quiet monopoly on "PyTorch just works." We covered the AWS side yesterday; this is Google's answer, and it is the more ambitious of the two.

Native PyTorch on TPUs: what actually changed

To appreciate TorchTPU you have to remember what came before. PyTorch/XLA, the old bridge, made you think in lazy tensors and manual compile regions, a programming model that felt like writing CUDA in 2009. TorchTPU throws that out. Google says it replaces PyTorch/XLA outright and recommends it for all new workloads: no lazy tensors, no manual mark-for-compile, support for around 450 ATen ops, and proper handling of divergent MPMD execution, the thing that made multi-device TPU code painful.

It also meets developers where they already live. TorchTPU works with vLLM, SGLang, Ray, TorchTitan, and Hugging Face out of the box. In Transformers v5, device_map="tpu" moves a model straight onto a TPU, and Google runs the Transformers test suite on TPUs nightly, which is the kind of boring reliability work that actually drives adoption. The code is Apache 2.0 across four GitHub repos (TorchTPU, vLLM-TorchTPU, SGLang-TorchTPU, TorchTitan), v0.2.0 is on PyPI, and it needs Python 3.11 or newer.

Google also shipped the supporting cast: an updated LiteRT runtime so PyTorch apps run on phones and embedded devices, and a TPU agent suite that helps developers port workloads and debug errors. The message is "the whole stack is here," not just a backend.

The endorsement that matters

The loudest voice in the announcement was not Google's. It was Meta's. PyTorch engineering director Jana van Greunen said Meta already runs LLM, ads, and recommendation workloads on TPUs through TorchTPU, adding that "we cannot be constrained by a single hardware architecture." Read that twice. Meta, the company that co-created PyTorch, is publicly running production workloads on Google's chips and saying the quiet part out loud: nobody wants their AI strategy held hostage by one vendor's silicon.

The self-reported numbers back the ambition: 52 percent MFU training Qwen 3 8B with TorchTitan, scaled to 8,192 Ironwood chips (TPU v7), with FP8, MXFP4, and NVFP4 checkpoint formats supported for serving. Vendor numbers, so season to taste, but 52 percent MFU at that scale is not a toy result.

What this means for working developers

• If you train on TPUs today: migrate off PyTorch/XLA. Google is telling you the old bridge is legacy. The new one is simpler and it is where all future work lands.
• If you are CUDA-only: you just gained negotiating leverage. "We could run this on TPUs with a one-line change" is a sentence your cloud rep does not want to hear, which is exactly why you should be able to say it.
• If you maintain libraries: device_map="tpu" support and nightly-tested Transformers compatibility mean TPU support is becoming table stakes, not a nice-to-have.

Zoom out and the pattern is clear. Open-sourcing the tooling layer is the new competitive move: GitHub just made AI code review generally available, AWS bridged PyTorch to Trainium, and now Google has bridged it to TPUs natively. Everyone is racing to own the developer's default path, because whoever owns the path owns the workloads that walk down it. For developers, the practical upshot is the best kind: your code is becoming portable across chips that used to demand rewrites. The hardware wars are heating up, and for once, the developers are winning.