Bringing gVisor sandboxes to distributed Ray clusters

The reinforcement learning (RL) ecosystem is rapidly adopting Ray as the unified compute runtime for complex post-training workflows. Across Google Cloud, we see customers using Ray for workloads ranging from multimodal data pipelines to frontier RL.

The reinforcement learning (RL) ecosystem is rapidly adopting Ray as the unified compute runtime for complex post-training workflows. Across Google Cloud, we see customers using Ray for workloads ranging from multimodal data pipelines to frontier RL.

Sandboxes as Ray Primitives Ray has become a common runtime for orchestrating post-training workloads. Frameworks including veRL, NeMo-RL, SLIME, MILES, and SkyRL already use Ray to coordinate distributed trainers, inference engines, rollout workers, and other components.

When we designed Ray Sandboxing, an important goal was to make it fit naturally into the existing Ray programming model rather than introduce a separate abstraction for isolated execution. A sandbox has many of the same properties as other resources managed by Ray: it needs to be placed on a machine, assigned resources, created and destroyed, recovered from failures, and scaled with the surrounding workload. This led us to represent each high-level sandbox through a Ray Actor:

The Ray scheduler decides which node should run a sandbox and reserves the corresponding CPU and memory resources. The sandbox Actor manages its lifecycle, while gVisor provides the isolated execution environment on that node.

Starting in Ray 2.58, framework authors and researchers can manage sandboxed environments using the same Ray APIs and patterns they already use for the rest of their workload. For example:

code_block <ListValue: [StructValue([('code', 'import ray\r\nfrom ray.experimental import sandbox\r\n\r\nray.init()\r\n# Create a gVisor sandbox environment and return an actor handle for a proxy actor\r\nsb = sandbox.create(\r\n cpu=1.0,\r\n memory="512Mi",\r\n image="python:3.12-slim"\r\n)\r\n# Execute code inside the sandbox\r\nresult = ray.get(sb.exec.remote("python -c \'import sys; print(sys.version)\'"))\r\nprint(result.stdout)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f8f2ea7f610>)])]>

In context

• Topic: Cloud y Arquitectura — Nube pública, híbrida, costos y decisiones de infraestructura.
• Source: Google Cloud Blog
• Published: 25/08/2026

Continue reading at the original source →

Excerpt published automatically by the site radar. The full text belongs to its publisher and is linked above.

Por que importa

O discurso da nuvem passou de migrar tudo para decidir o que vai onde. Essa maturidade é bom sinal, mas também torna a conversa mais difícil: já não há resposta única, é preciso argumentar caso a caso e pouquíssima gente tem os números para isso.

O que eu olho nesses anúncios é a portabilidade. Quanto mais confortável é uma plataforma, mais difícil costuma ser sair dela, e esse conforto se paga em poder de negociação três anos depois, justo quando chega a renovação e já não há alternativa crível.

O que costuma dar errado

Onde costuma quebrar é na capacidade da equipe. A plataforma é nova mas as pessoas aprenderam no caminho, sem tempo e sem acompanhamento. Acabam replicando na nuvem as mesmas práticas do centro de dados, ou seja, pagam-se preços de nuvem por benefícios que nunca chegam.

O que observar

• Quem vê a fatura e com que detalhe: sem dono do gasto, o gasto cresce sozinho.
• Onde ficam fisicamente os dados e o que a regulação local exige sobre isso.
• O que acontece quando o fornecedor tem uma queda, porque vai ter, e o que segue operando enquanto isso.

Como leio esta publicação

Eu leria pensando na saída antes da entrada. Não porque alguém planeje sair, mas porque a conversa sobre como sairia é a que revela quanto se está amarrando. Se ninguém na mesa consegue descrever esse caminho, a dependência já é maior do que se imagina.

A notícia original está publicada em outro idioma; o trecho é citado como o veículo o entrega e o comentário é escrito em português.