Google Open-Sources TorchTPU: PyTorch Gets TPU as a Native Device

At PyTorch Conference 2026 in San Jose, Google open-sourced TorchTPU, a software stack that makes the TPU a native device for PyTorch. For developers, it comes down to one line in Hugging Face Transformers: device_map="tpu". The main barrier to TPUs has always been software, not hardware. Ordinary PyTorch code needed an intermediate layer and adaptation, and that friction kept the industry inside the CUDA ecosystem. Now Google is trying to remove it. • Previously, PyTorch ran on TPUs through PyTorch/XLA • The entry point is the Hugging Face ecosystem • Google is aiming at Nvidia's deepest moat: developer habit

AI-processed from Jiqizhixin (机器之心); edited by Hamidun News
Google Open-Sources TorchTPU: PyTorch Gets TPU as a Native Device
Source: Jiqizhixin (机器之心). Collage: Hamidun News.
Listen to article
Article Fact Sheet & Key Figures
ParameterDetails
Primary sourceJiqizhixin (机器之心) ↗
Editor-in-Chief
Key metric #1Previously, PyTorch ran on TPUs through PyTorch/XLA
Key metric #2The entry point is the Hugging Face ecosystem
Google is aiming at Nvidia's deepest moatdeveloper habit

Google has open-sourced TorchTPU, a full software stack for running PyTorch on TPUs as a native device. The announcement came at PyTorch Conference 2026 in San Jose. Boil the news down to a single line of code and it looks like this: device_map="tpu". In Hugging Face Transformers, that is enough to send a model to Google's tensor processors.

On paper, it is a small thing. In practice, it is a blow to Nvidia's most durable advantage. The market has spent ten years debating chip performance, but the choice of accelerator is largely determined by how much effort it takes to get already-written code running on it. CUDA's hold rests not only on performance but on inertia: libraries, habits, ready-made training recipes, and engineers' accumulated know-how.

Why TPUs stayed out of reach for so long

Google's TPUs have long been considered serious hardware. The company trains its own models on them, and in recent years it has been renting them out to outside customers more and more aggressively. Large labs have signed deals for big volumes of TPU capacity, and Google has positioned the seventh generation, Ironwood, as a chip for the inference era.

The chip was not the bottleneck. The bridge between it and the PyTorch world was. Inside Google, the native language was JAX, while the rest of the industry wrote in PyTorch. PyTorch/XLA existed for running PyTorch on TPUs, but the average developer saw it as a separate discipline. Code had to be adapted, and behavior differed from the familiar GPU workflow. After a first attempt, many teams went back to CUDA.

TorchTPU is billed as the answer to that problem. Instead of a layer that has to be learned separately, Google offers the TPU as a native PyTorch device. For a Transformers user, the line between a "GPU model" and a "TPU model" shrinks to the value of a single parameter.

What exactly was released

According to Google, this is not a set of examples or a wrapper around an old solution, but a complete chain that lets PyTorch run on TPUs. The code is open, and that matters for trust. Developers do not like tying themselves to closed software built for someone else's hardware, especially after years in an ecosystem with a dominant leader.

Key facts about the release:

  • the project is called TorchTPU and is distributed as open source;
  • the announcement was made at PyTorch Conference 2026 in San Jose;
  • the goal is to make the TPU a native PyTorch device;
  • the interface for Hugging Face Transformers users is device_map="tpu";
  • the main opponent is not a specific chip but developers' habit of using CUDA.

Choosing Hugging Face as the showcase looks deliberate. It is where most engineers first pick up an open model, run it, and decide where to scale. If the path to TPUs there looks as simple as the path to GPUs, Google gains access to a huge audience that previously never even considered its hardware.

How to test it in practice

The news does not mean any pipeline can be moved with one line tomorrow. Running a model from Transformers is one thing; moving production training with custom kernels, non-standard operators, and homegrown distributed code is another. Those are exactly the places where CUDA dependency usually hides.

Teams considering TPUs would be wise to proceed in order:

  • take a standard model from Transformers and compare the cost per hour of work on TPU and GPU, not just speed;
  • check how many custom CUDA kernels and third-party extensions are in the codebase: this is the main source of pain in a migration;
  • test inference and training separately, because the maturity of the stack in these scenarios can differ significantly;
  • keep a fallback path to GPU until TorchTPU has passed a check on your own workload.

Something else matters more for the market. As long as switching to alternative accelerators required rewriting code, Nvidia could hold its prices and supply terms. Every step that lowers the cost of moving gives buyers leverage in negotiations, even if most of them stay on CUDA. The moat has not been filled in, but Google has just shown where it can be crossed.

Story

Key Questions Answered

Why TPUs stayed out of reach for so long?

Google's TPUs have long been considered serious hardware. The company trains its own models on them, and in recent years it has been renting them out to outside customers more and more aggressively. Large labs have signed deals for big volumes of TPU capacity, and Google has positioned the seventh generation, Ironwood, as a chip for the inference era. The chip was not the bottleneck. The bridge between it and the PyTorch world was. Inside Google, the native language was JAX, while the rest of the industry wrote in PyTorch. PyTorch/XLA existed for running PyTorch on TPUs, bu

What exactly was released?

According to Google, this is not a set of examples or a wrapper around an old solution, but a complete chain that lets PyTorch run on TPUs. The code is open, and that matters for trust. Developers do not like tying themselves to closed software built for someone else's hardware, especially after years in an ecosystem with a dominant leader. Key facts about the release: the project is called TorchTPU and is distributed as open source; the announcement was made at PyTorch Conference 2026 in San Jose; the goal is to make the TPU a native PyTorch device; the interface for Huggi

How to test it in practice?

The news does not mean any pipeline can be moved with one line tomorrow. Running a model from Transformers is one thing; moving production training with custom kernels, non-standard operators, and homegrown distributed code is another. Those are exactly the places where CUDA dependency usually hides. Teams considering TPUs would be wise to proceed in order: take a standard model from Transformers and compare the cost per hour of work on TPU and GPU, not just speed; check how many custom CUDA kernels and third-party extensions are in the codebase: this is the main source of

ZK
Zhemal Khamidun — CPO at Alpina Digital, product manager of AlpinaGPT. Building AI products since 2019. Hamidun News is a pet project that grew into a production aggregator with 6,000+ readers.
✦ Hands-On AI Engineering

Build & Ship Production AI Apps with Vibe Coding

Join Zhemal Khamidun's hands-on Vibe Coding Intensive at hamidun.com/vibecoding — master Claude Code, Cursor, and autonomous agentic workflows.

Explore Vibe Coding →Vibe Academy Platform
What do you think?
Loading comments…