TorchTPU: native PyTorch on Google TPUs, and the price of a one-line port
Google and Meta open-sourced TorchTPU at PyTorch Conference 2026: eager-first PyTorch on TPUs, torch.compile through Dynamo, validated against the 5,000 most-downloaded Hugging Face models. I read the PyTorch and Google Cloud posts and the repo - what shipped, why it is not PyTorch/XLA, and which claims stay the vendors'.
TorchTPU: native PyTorch on Google TPUs, and the price of a one-line port
On October 20, at PyTorch Conference 2026, Google and Meta open-sourced TorchTPU, a native PyTorch backend for Google TPUs where the port, in the best case, is changing .to("cuda") to .to("tpu"). I read the PyTorch blog post, the Google Cloud announcement and the repository on October 26, 2026. The architecture is documented in unusual detail; the performance claims are the vendors' own, and the two companies paying for the bridge are also the ones with the most to gain from a world where model code moves freely.
What shipped
TorchTPU is a Google effort started in mid-2025 with Meta's PyTorch team, released as open source at PyTorch Conference 2026 on October 20, per the PyTorch blog and the Google Cloud post by Mark Lohmeyer and Bill Jia. It is a from-scratch TPU backend rather than another shim over JAX: eager execution is a first-class mode, torch.compile goes through Torch Dynamo rather than Lazy Tensors, and distributed PyTorch idioms (DDP, FSDP, DTensor) get TPU collectives at the Process Group level. The repository, google-pytorch/torch_tpu, held 741 stars when I read it on October 26 and carries the Apache License 2.0 in its LICENSE file, applied to every file - GitHub's detector flags it as nonstandard only because of a header line. The blog lists what exists today: about 450 Aten ops with forward and backward passes for the Core ATen ops behind the major architectures, a DeferAndFuse eager mode, and custom kernel authoring through JAX/Pallas or the Helion DSL.
Why this attempt is not PyTorch/XLA
The most honest part of the announcement is its autopsy of the previous attempt. PyTorch/XLA, introduced in 2020, compiled through Lazy Tensors: the TorchTPU authors say it required intrusive source edits to mark compilable regions, suffered severe compile-time latency, had no real eager mode and lagged PyTorch's distributed primitives. That is the new team describing the old team's work, and both teams sit inside Google - but the criticism matches what anyone who fought XLA graphs remembers, and it explains the three design principles they published. PyTorch citizenship: no JAX dependencies in the runtime, solid eager mode and Dynamo-based compile with performance targets similar to JAX compile. Focus on the user: a model should run out of the box after the one-line device change, with the caveat, stated in the post itself, that peak performance still needs shape and sharding work because models are tuned to GPU architecture. Improve the state of the art: JIT compilation for eager execution, and bounded dynamism so XLA stops recompiling on every shape change.
What "validated" covers
The compatibility claims are specific enough to test. The posts say TorchTPU runs the 5,000 most-downloaded Hugging Face models out of the box - the named families include Qwen, DeepSeek, Gemma, Llama, Mistral, Whisper, CLIP, ViT, ResNet, BERT and T5 - and that Transformers v5 exposes it as device_map="tpu", with Diffusers running natively and nightly CI of the Transformers suite on TPU infrastructure. Serving runs through vLLM and SGLang with multi-host inference, training through TorchTitan, orchestration through Ray, plus TorchRec, llm-d and LiteRT. The strongest claim is that TorchTPU already runs production inference and training for some of the largest Google Cloud customers. Those customers are unnamed, so that sentence stays a vendor claim rather than a reference.
The economics, attributed
Reuters reported in December 2025 that Google was working with Meta to erode Nvidia's software advantage, and this release is what that reporting looks like as code. Meta's quote in the Google post, from PyTorch engineering director Jana van Greunen, says Meta "cannot be constrained by a single hardware architecture" and frames TorchTPU as hardware flexibility for LLM, ads and recommendation workloads. Hugging Face's Jeff Boudier frames it as hardware neutrality. Google's framing is customer choice across TPUs, GPUs and CPUs under one operational model - worth remembering that Google is also the company renting the TPUs, so the bridge comes with a toll booth on the far side. Nvidia's moat was never only the chip; it was the assumption that CUDA code cannot move. TorchTPU is a funded, engineered attack on that assumption. Whether it works gets decided by migrations, not announcements: the first public postmortem of a real training run moved from GPUs to TPUs will be worth more than everything published this week.
What I did not verify
I have not run a PyTorch workload on a TPU. Every performance statement here - "industry-competitive" throughput, the eager-to-compiled gap closing, Dynamo compile matching JAX - is the vendor's, as are the 5,000-model compatibility list and the production-customer claim. The PyTorch/XLA criticism comes from the TorchTPU authors themselves. The star count and license were read from the repository on October 26, 2026.