Announcing Ray support for PyTorch on Google TPUs

Earlier this year at Ray Summit 2026, we covered how the PARK stack (PyTorch, AI models, Ray, and Kubernetes) is emerging as an industry standard for production AI. Ray has long been the ubiquitous distributed runtime for PyTorch workloads on GPUs.

Today Anyscale and Google Cloud are announcing native Ray support for PyTorch on Google TPUs, the foundational supercomputing infrastructure powering Gemini and large-scale AI workloads on Google Cloud.

Building on Google's TorchTPU project and KubeRay on Google Kubernetes Engine (GKE), this integration brings a native, single-device-per-worker PyTorch experience to Cloud TPUs. Platform and ML teams running on GKE can now schedule, scale, and operate distributed PyTorch training, vLLM inference, and reinforcement learning (RL) workloads across GPUs and TPUs on a single Kubernetes control plane.

LinkNative PyTorch on Google TPUs

Historically, running TPU workloads on Ray required adapting to a Single-Program, Multiple Data (SPMD) execution model designed primarily for JAX, where a single Ray worker process per host VM managed all of the machine's attached TPU chips. , introduced last year as Google's native PyTorch backend for Tensor Processing Units,brings an eager-first, native TPU integration and a torch.distributed extension for running distributed workloads on TPUs.

Following TorchTPU, we’ve evolved Ray to run one worker per TPU chip, matching the single-device-per-worker model that PyTorch developers are used to on GPUs.

When scheduling tasks or actors with Ray and TorchTPU, each worker requests a single logical TPU device (resources={"TPU": 1}) just as a GPU worker requests num_gpus=1:

• Device Isolation: Just as Ray automatically sets CUDA_VISIBLE_DEVICES for GPU workers, Ray isolates and assigns individual TPU devices to workers using TPU_VISIBLE_CHIPS

Device Isolation: Just as Ray automatically sets CUDA_VISIBLE_DEVICES for GPU workers, Ray isolates and assigns individual TPU devices to workers using TPU_VISIBLE_CHIPS

• Native PyTorch Device & Collectives: Inside a Ray task or actor, migrating existing PyTorch code from GPUs to TPUs is as simple as changing "cuda" to "tpu" and switching the distributed communications backend from "nccl" to "tpu_dist".

Native PyTorch Device & Collectives: Inside a Ray task or actor, migrating existing PyTorch code from GPUs to TPUs is as simple as changing "cuda" to "tpu" and switching the distributed communications backend from "nccl" to "tpu_dist".

• Topology-Aware Gang Scheduling: GKE provisions multi-host TPU slices as node pools connected over high-speed Inter-Chip Interconnects (ICI). To take advantage of this physical layout, Ray’s SlicePlacementGroup API provides a native scheduling implementation that guarantees actors are gang-scheduled together on the same TPU slice.

Topology-Aware Gang Scheduling: GKE provisions multi-host TPU slices as node pools connected over high-speed Inter-Chip Interconnects (ICI). To take advantage of this physical layout, Ray’s API provides a native scheduling implementation that guarantees actors are gang-scheduled together on the same TPU slice.

Below is an example of a distributed PyTorch all_reduce using Ray actors on TPUs. Aside from the resource request and device/backend strings, the code is identical to a Ray actor running on GPUs:

LinkTorchTrainer on TPUs

For distributed training and fine-tuning, many teams rely on Ray Train’s TorchTrainer to orchestrate Distributed Data Parallel (DDP), Fully Sharded Data Parallel (FSDPv2), and DTensor workloads without writing manual boilerplate for distributed process groups.

With native TorchTPU support in Ray Train, you can now run your existing TorchTrainer scripts on single-host and multi-host Cloud TPU slices with zero changes to your PyTorch training loop.

When you configure TorchTrainer for TPUs via ScalingConfig, Ray Train handles all of the underlying TPU orchestration automatically:

• Atomic TPU Slice Reservation: By specifying use_tpu=True alongside your target topology (e.g., "4x4") and accelerator_type (e.g., "TPU-V6E" or "TPU-V7X"), TorchTrainer automatically provisions a SlicePlacementGroup under the hood. This guarantees that all training workers are gang-scheduled onto contiguous physical TPU slices over high-speed ICI, preventing resource fragmentation.

Atomic TPU Slice Reservation: By specifying use_tpu=True alongside your target topology (e.g., "4x4") and accelerator_type (e.g., "TPU-V6E" or "TPU-V7X"), TorchTrainer automatically provisions a SlicePlacementGroup under the hood. This guarantees that all training workers are gang-scheduled onto contiguous physical TPU slices over high-speed ICI, preventing resource fragmentation.

• Automated tpu_dist Bootstrap: Ray Train spawns one worker per TPU device (resources_per_worker={"TPU": 1}), automatically configures PyTorch distributed environment variables (RANK, WORLD_SIZE, LOCAL_RANK, MASTER_ADDR, MASTER_PORT) alongside TorchTPU’s slice-builder addresses and mesh topology, and initializes the tpu_dist process group.

Automated tpu_dist Bootstrap: Ray Train spawns one worker per TPU device (resources_per_worker={"TPU": 1}), automatically configures PyTorch distributed environment variables (RANK, WORLD_SIZE, LOCAL_RANK, MASTER_ADDR, MASTER_PORT) alongside TorchTPU’s slice-builder addresses and mesh topology, and initializes the tpu_dist process group.

• Drop-in Ray Train Utilities: Standard Ray Train helper functions like ray.train.torch.get_device() and ray.train.torch.prepare_model() automatically detect the TorchTPU runtime, move your model to the assigned tpu device, and wrap it in PyTorch’s DistributedDataParallel class.

Drop-in Ray Train Utilities: Standard Ray Train helper functions like ray.train.torch.get_device() and ray.train.torch.prepare_model() automatically detect the TorchTPU runtime, move your model to the assigned tpu device, and wrap it in PyTorch’s DistributedDataParallel class.

Here is a complete example of scaling a PyTorch training loop across a 16-chip multi-host Trillium (TPU-V6E, 4x4 topology) slice using TorchTrainer:

For a complete end-to-end walkthrough on Google Kubernetes Engine (GKE), see Train models on multi-host TPUs with Ray and TorchTPU.

LinkvLLM-TorchTPU with Ray Serve

For online inference,

registers TorchTPU as a vLLM platform plugin so PyTorch models compile and execute on Cloud TPUs without rewriting model definitions in JAX. Combined with

, you can deploy OpenAI-compatible vLLM endpoints across single-host and multi-host TPU slices using the same declarative LLMConfig API used on GPUs.

When accelerator_type and accelerator_config specify a TPU slice, Ray Serve reserves a topology-aware SlicePlacementGroup for each replica and launches vLLM engine workers across the slice:

For a complete end-to-end walkthrough on Google Kubernetes Engine (GKE), see Serve LLMs on multi-host TPUs with Ray and TorchTPU.

LinkExtending the PARK stack to TPUs

As AI workloads evolve from standalone training jobs to compound systems combining training, high-throughput inference, and reinforcement learning, organizations are standardizing on the open-source PARK stack (PyTorch, AI models, Ray, and Kubernetes). Bringing TorchTPU to Ray and GKE completes this vision on Google Cloud: PyTorch developers keep the eager execution model and Ray APIs they already know, while platform teams get the topology-aware autoscaling, resilience, and multi-accelerator governance of GKE.

To get started today, explore the end-to-end GKE tutorials for Serving LLMs or Training models with Ray and TorchTPU, and stay tuned as we expand this foundation to large-scale RL post-training frameworks and next-generation Ironwood (TPU v7x) slices on GKE.