Anyscale, Google Cloud adiciona suporte nativo ao Ray para PyTorch em TPUs

A Anyscale e o Google Cloud disseram em 20 de outubro de 2026 que o Ray agora tem suporte nativo para cargas de trabalho do PyTorch em TPUs do Google, estendendo a pilha PARK para treinamento e inferência baseados em TPUs no Google Kubernetes Engine. As empresas disseram que a integração é construída sobre o projeto TorchTPU do Google e o KubeRay no GKE, e foi projetada para oferecer aos usuários do PyTorch um modelo de dispositivo único por trabalhador em TPUs em nuvem.

Evidências e contexto

No anúncio, a Anyscale afirmou que as equipes de plataforma e ML rodando no GKE podem agendar, escalar e operar cargas de trabalho distribuídas de treinamento PyTorch, inferência vLLM e aprendizado por reforço entre GPUs e TPUs em um único plano de controle Kubernetes. A empresa disse que os trabalhadores Ray em TPUs agora mapeiam um trabalhador para um chip TPU, usando resources={"TPU": 1} e isolando o dispositivo através TPU_VISIBLE_CHIPSde , enquanto trocam o código do PyTorch de cuda para tpu e o backend distribuído de nccl para tpu_dist.

O post também dizia que a API SlicePlacementGroup do Ray é usada para agendar atores juntos na mesma fatia TPU, e que o TorchTrainer da Ray Train pode orquestrar cargas de trabalho paralelas de dados distribuídos, Fully Sharded Data Parallel v2 e DTensor em slices de TPU Cloud de host único e multi-host. Os exemplos no post especificam uma configuração 16-worker em um slice V6E TPU- 4x4, com use_tpu=True, resources_per_worker={"TPU": 1} e configuração automática das variáveis de ambiente distribuído do PyTorch.

Para inferência, a Anyscale disse que o vLLM-TorchTPU registra o TorchTPU como um plugin de plataforma vLLM, permitindo que endpoints compatíveis com OpenAI rodem em fatias TPU através do Ray Serve LLM. A configuração de exemplo no post usa uma topologia TPU-V6E 4x4 e especifica tensor_parallel_size=16, enable_expert_parallel=True e max_model_len=8192.

O que é verificado e o que permanece limitado

O anúncio está em conformidade com as recentes orientações do Google Cloud para TPUs e segue as publicações do Google Developers datadas de 20 e 2026-07-24 de julho sobre rodar o Ray em TPUs. Material de fundo verificado fornecido com este pedido também observa que o Ray Train orquestra o treinamento distribuído entre máquinas, mas é distinto do runtime do framework que executa operações tensoriais.

Ao mesmo tempo, o background fornecido diz que o backend inspecionado do Ray 2.59.0 PyTorch recomenda exatamente um dispositivo TPU por trabalhador e explicitamente gera um erro para treinamento entre múltiplos slices de TPU. Isso significa que o artigo deve distinguir entre treinamento multi-host dentro de um único slice TPU, que está descrito no material original, e treinamento multi-slice, que não é verificado aqui para Ray 2.59.0. O material fornecido também diz que um post do Google de julho de 24 descreve a escalonabilidade multi-slice para o JaxTrainer, mas isso não deve ser generalizado para o PyTorch.

O material de origem não fornece preços, dados de mercado, datas de lucros ou posicionamento dos investidores. Também não fornece uma data verificada para o próximo catalisador após o anúncio de 20 de outubro de 2026 .