TorchTPU goes open source, and PyTorch's TPU bridge becomes the front door

Google's PyTorch Conference 2026 keynote on 20 October carried one announcement with a longer tail than the rest: TorchTPU, the company's native PyTorch stack for its tensor processors, is now published as open source on GitHub. The post by Mark Lohmeyer and Bill Jia makes the claim plainly. "With TorchTPU, TPUs join GPUs and CPUs as a native option for PyTorch." That sentence is doing two jobs at once. It announces a repository, and it retires a six-year-old arrangement in which PyTorch reached TPUs through a bridge Google now describes as inadequate.

The bridge was already there

PyTorch has run on TPUs since 2020, when Google shipped PyTorch/XLA on lazy tensors. Nobody withdrew that support, and nothing in this week's announcement makes existing PyTorch/XLA jobs stop working. What changed is which stack Google wants you to use. The PyTorch blog's introduction is unusually blunt about the predecessor, listing intrusive source-code changes to mark compilable regions, severe compile-time latency, no support for eager execution and a lag behind PyTorch's own distributed primitives. TorchTPU is the answer to that list: a C++ backend registered through PyTorch's PrivateUse1 dispatcher, eager mode as the default, torch.compile built on Dynamo rather than lazy tensors, and TPU collectives exposed at the process-group level. The pitch to users is a one-line port: model.to("cuda") becomes model.to("tpu"). PyTorch's post adds the caveat in the same breath, warning that the model will run but that "one cannot achieve peak TPU performance with that simple change," because its shapes, sharding and operator choices were tuned for a GPU. The accurate headline, then, is not that PyTorch now works on TPUs. It is that the bridge became the front door.

What open source buys Google

The license is not the interesting part of this release. The default is. Google's post spends its length on integrations, and its most consequential line is a short one about Hugging Face: in Transformers v5, moving a model onto TPUs is device_map="tpu". Diffusers runs natively with eager mode, torch.compile and tensor parallelism, and Google says it built dedicated CI/CD pipelines for nightly Transformers testing on TPU hardware. The PyTorch post puts the validated set at the 5,000 most-downloaded Hub models and roughly 450 Aten operators. None of that needed a permissive license to work. It needed the maintainers of the most-used model library to make one string the supported path. Four repositories went out together, not one: TorchTPU itself, vLLM-TorchTPU, SGLang-TorchTPU and TorchTitan, each with its own tracker and cadence. Two of the integrations are not Google forks at all. The post says Google upstreamed a TPU backend and a GRPO reference recipe into VeRL, and added native TorchTPU support to Ray, which puts the code in those projects' own trees. That is the difference between publishing a backend and being one.

The license field says Other

GitHub's API reports the project's license as Other, with an SPDX identifier of NOASSERTION. That reads like a restriction and is not one. The LICENSE file is the Apache License 2.0, opened by a scope line, Files: ./*, and followed after the appendix by an MIT block covering examples/mingpt/impl/*, Andrej Karpathy's nanoGPT example. The scope header is what defeats GitHub's detector, which expects one license per file. The consequence is bureaucratic rather than legal: dependency scanners and procurement reviews will classify a Google project as unlicensed until a human opens the file. Apache 2.0 with an MIT carve-out is about as uncontroversial as a Google release gets. The metadata simply does not say so.

Four thousand commits, five hundred stars

Signal	Figure
Repository created	9 March 2026
Commits on main	4,480
Stars	574
Forks	31
Open issues	283

The commit count reframes the announcement. The repository was created on 9 March 2026 and main carries 4,480 commits, pushed as recently as 21 October. The PyTorch post dates the effort to mid-2025. Open sourcing, in other words, was a licensing and visibility event for code that had already been under heavy development for most of a year, not the first time anyone wrote it. The star count asks the question the post cannot answer. Five hundred and seventy-four stars is small for a project with Google's name on it and a keynote slot, and 283 open issues against that audience suggests a tracker used by a modest number of committed teams rather than a crowd arriving. Google says TorchTPU is "used in production for both inference and training workloads for some of the largest Google Cloud customers" and names none of them. Stars measure attention, not adoption, but the announcement offers no figure that measures adoption either.

The performance claims and their edges

The headline number lives in the Cloud post: up to 52% model flops utilisation on Qwen 3 8B through TorchTitan, with near-linear scaling to 8,192 Ironwood chips. The PyTorch post's table for Qwen3 235B MoE tops out lower, at 27.1% across eight slices against 28.8% on one. Those numbers are not in conflict so much as in different rooms: a sparse model at 4K sequence length is a harder utilisation case than a dense 8B. The comparison that is not self-referential is still Google's. On 64 TPU v7 chips, TorchTitan reached 1,828 tokens per second against 1,937 for JAX on MaxText, a gap of about 5.6% on the vendor's own smoke test. A SemiAnalysis InferenceX evaluation the post cites puts vLLM-TorchTPU at 2.01 cents per million tokens on an 8K/1K workload, down from 3.6 cents in September. The same posts also disclose, without emphasis, what does not work yet. FlexAttention is unsupported and had to be swapped for vanilla scaled dot-product attention in a ported model, RL colocation cannot be supported out of the box because a TPU device admits one process, and torch.compile on TPU forces dynamic=False as a temporary limitation.

What would settle it

Not more vendor posts. An MFU figure from a team that did not choose the model and the topology; a star count that keeps moving after the keynote cycle ends; a license string that resolves in the scanners people actually run. What is absent is the comparison a buyer would actually want: no GPU price-performance run on an identical workload, and no utilisation figure from anyone who did not also help write the backend. The engineering is not the open question. Seven months and 4,480 commits is a real stack, 450 operators is a real coverage claim, and Google's second open-source drop this week, an agent scaffold the Harness2 write-up covered, came with the same shape of caveat about what its numbers were measured against. The narrower question is whether a native backend changes what a team chooses to rent, or only what Google can say it offers.