News
Anyscale and Google Cloud said Ray now supports PyTorch on Google TPUs natively on GKE, with one worker per TPU chip and TPU-aware scheduling.
Anyscale and Google Cloud said on Oct. 20, 2026, that Ray now has native support for PyTorch workloads on Google TPUs, extending the PARK stack into TPU-based training and inference on Google Kubernetes Engine. The companies said the integration is built on Google’s TorchTPU project and KubeRay on GKE, and is designed to give PyTorch users a single-device-per-worker model on Cloud TPUs.
Evidence and context
In the announcement, Anyscale said platform and ML teams running on GKE can schedule, scale and operate distributed PyTorch training, vLLM inference and reinforcement learning workloads across GPUs and TPUs on a single Kubernetes control plane. The company said Ray workers on TPUs now map one worker to one TPU chip, using resources={"TPU": 1} and device isolation through TPU_VISIBLE_CHIPS, while switching PyTorch code from cuda to tpu and the distributed backend from nccl to tpu_dist.
The post also said Ray’s SlicePlacementGroup API is used to gang-schedule actors together on the same TPU slice, and that Ray Train’s TorchTrainer can orchestrate distributed data parallel, Fully Sharded Data Parallel v2 and DTensor workloads on single-host and multi-host Cloud TPU slices. The examples in the post specify a 16-worker configuration on a 4×4 TPU-V6E slice, with use_tpu=True, resources_per_worker={"TPU": 1} and automatic setup of PyTorch distributed environment variables.
For inference, Anyscale said vLLM-TorchTPU registers TorchTPU as a vLLM platform plugin, allowing OpenAI-compatible endpoints to run on TPU slices through Ray Serve LLM. The example configuration in the post uses a TPU-V6E 4×4 topology and specifies tensor_parallel_size=16, enable_expert_parallel=True and max_model_len=8192.
What is verified and what remains limited
The announcement is consistent with Google Cloud’s recent TPU guidance and follows Google Developers posts dated July 20 and July 24, 2026 on running Ray on TPUs. Verified background material supplied with this request also notes that Ray Train orchestrates distributed training across machines, but is distinct from the framework runtime that executes tensor operations.
At the same time, the supplied background says the inspected Ray 2.59.0 PyTorch backend recommends exactly one TPU device per worker and explicitly raises an error for training across multiple TPU slices. That means the article should distinguish between multi-host training within a single TPU slice, which is described in the source material, and multi-slice training, which is not verified here for Ray 2.59.0. The supplied material also says a July 24 Google post describes multi-slice scale-out for JaxTrainer, but that should not be generalized to PyTorch.
The source material does not provide pricing, market data, earnings dates or investor positioning. It also does not supply a verified next catalyst date beyond the Oct. 20, 2026 announcement itself.
Be the first to comment