Você achava que treinar IA era só GPU? A DeepSeek discorda.

Quando a gente fala em escalar treinamento de IA, o reflexo imediato é pensar em mais GPUs. Mais H100, mais clusters, mais dinheiro jogado em silício. Mas a DeepSeek acaba de publicar um paper que inverte essa lógica: o gargalo real do treinamento de agentes de IA não está na GPU. Está nos ambientes de execução.

O paper se chama “DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale” e descreve a infraestrutura que a DeepSeek construiu internamente para treinar seus agentes. Estamos falando de um sistema que cria mais de 5.000 sandboxes por segundo, mantém 380.000 ambientes rodando ao mesmo tempo, e processa 3 milhões de instâncias por dia. Tudo isso em “apenas” 160 nodes com 30.000 cores de CPU e 250 TB de RAM.

E sim, eles abriram o código.

O problema que ninguém estava olhando

Treinar um LLM tradicional é, conceitualmente, mais simples do que parece. Você tem dados, tem GPUs, roda forward e backward passes, ajusta pesos. O pipeline é relativamente linear.

Agentes de IA são outra história. Um agente precisa interagir com o mundo: executar código, chamar APIs, navegar em sistemas de arquivos, rodar testes. Cada interação dessas precisa de um ambiente isolado, com estado próprio, que pode durar minutos ou horas. Multiplique isso por milhares de rollouts simultâneos de reinforcement learning e você tem um problema de infraestrutura que nenhum orquestrador convencional resolve bem.

O paper coloca de forma direta: “agent training scalability is constrained not by GPU compute but by environment provisioning capacity.” Em outras palavras, não adianta ter 10.000 GPUs se você não consegue criar ambientes rápido o suficiente para alimentá-las.

Kubernetes? Docker Swarm? Nenhum deles foi desenhado para criar 32.000 containers de uma vez em uma rajada, manter estado entre interações de um LLM, e destruir tudo logo depois. É um padrão de uso que simplesmente não existia antes do treinamento agentic em larga escala.

Quatro sabores de sandbox

Uma das decisões mais interessantes do DSec é oferecer quatro backends de sandbox diferentes, cada um com um trade-off entre isolamento e performance:

Na prática, containers e microVMs dominam. O FnCall existe para aquelas tarefas rápidas tipo “execute esse código Python e me diga se passou nos testes”, onde criar um container inteiro seria desperdício. Já o Full VM aparece quando o agente precisa interagir com um ambiente Android completo ou renderizar interfaces gráficas.

O ponto-chave: o SDK é unificado. O código que treina o agente não precisa saber qual backend está rodando por baixo. Isso permite que o placement engine escolha dinamicamente o melhor backend baseado nos requisitos de isolamento e performance de cada tarefa.

O truque da imagem distribuída

Se você já trabalhou com containers em escala, sabe que distribuir imagens é um pesadelo. Pull de imagens Docker em mil nodes simultâneos é uma receita para saturar qualquer registry. A DeepSeek resolveu isso de um jeito elegante com o Fire-Flyer File System (3FS), o sistema de arquivos distribuído deles.

Em vez de fazer pull completo de imagens para cada node, o DSec usa EROFS (Enhanced Read-Only File System) com carregamento sob demanda. A sandbox começa a rodar e só busca os dados que realmente acessa. E aqui vem o número que impressiona: em produção, os sandboxes acessam apenas 4,2% a 13,3% do tamanho total da imagem.

Ou seja, numa imagem de 10 GB, o sandbox tipicamente lê menos de 1,3 GB. O resto fica no 3FS, nunca trafega pela rede, nunca ocupa disco local.

Os benchmarks confirmam: o pull sob demanda via EROFS é 1,71x mais rápido que o pull tradicional do Docker e gera 57% menos tráfego de escrita em disco. Em um burst de 8.192 containers, isso significa ~700 GB de escrita contra ~1.600 GB do método convencional.

Outro detalhe: as imagens são compostas por camadas independentes (base OS, workspace, toolkit). Atualizar a base de uma linguagem de programação exige reconstruir O(m) camadas em vez de O(m·N), onde N é o número de workspaces. Parece óbvio, mas quando você tem 102.171 workspaces diferentes em uma semana (número real de produção), isso faz toda a diferença.

Memória: onde o dinheiro realmente está

250 TB de RAM em 160 nodes. Cada node com centenas ou milhares de sandboxes. Desperdiçar memória aqui não é um incômodo, é uma falha de projeto.

O DSec ataca isso em duas frentes:

Virtio-pmem com DAX (Direct Access): em sandboxes baseados em microVM, normalmente existe uma cópia dupla dos dados: uma no host e outra no guest (via page cache). O virtio-pmem com DAX elimina essa duplicação, permitindo que o guest acesse diretamente a memória do host sem cópia intermediária. Resultado: redução de 40,2% no pico de uso de memória do host.

DAMON + virtio-balloon: o DAMON (Data Access MONitor) monitora padrões de acesso a páginas de memória e identifica páginas “frias” que não são acessadas há tempo. Essas páginas são devolvidas ao host via balloon. Resultado adicional: redução de 21,2% no consumo integrado de memória ao longo do tempo.

As duas técnicas são complementares. Uma elimina duplicação, a outra recupera memória ociosa. Juntas, permitem que cada node rode até 3.200 containers ou 800 microVMs de forma estável.

CPU: 90% dos sandboxes ficam parados

Esse é um dado fascinante do paper: aproximadamente 90% dos sandboxes usam 5% ou menos da CPU alocada. Faz sentido quando você pensa: a maior parte do tempo, o sandbox está esperando o LLM gerar a próxima ação. A CPU só trabalha de verdade nos breves momentos em que executa um comando ou roda um teste.

Isso justifica overcommit agressivo. Mas overcommit sem controle de qualidade destrói a latência das tarefas sensíveis. A solução do DSec usa duas camadas:

Primeiro, SCHED_IDLE classifica sandboxes best-effort para que cedam CPU automaticamente quando uma tarefa sensível a latência precisa rodar. Segundo, core scheduling garante que threads SMT de um core sensível não compartilhem com trabalho best-effort.

O resultado: a inflação de latência cai de 45,2% (sem proteção) para 17,3% com 50% de carga co-localizada. O resíduo de 17,3% vem de redução de frequência turbo e contenção de LLC (Last Level Cache), coisas que nenhum scheduler consegue eliminar sem separação física.

Reinforcement learning e sandboxes: a cola que faz tudo funcionar

Até aqui, o DSec parece um orquestrador de containers sofisticado. Mas o que realmente diferencia ele é a integração profunda com o pipeline de reinforcement learning.

No treinamento de agentes via RL, o ciclo funciona assim: o LLM gera uma ação, o ambiente executa, retorna o resultado, o LLM gera a próxima ação, e assim por diante. Cada sequência dessas é um “rollout”. E cada rollout precisa manter estado entre as interações.

A partir do DeepSeek-V4.1, a execução de rollouts foi separada do pool de GPUs. Cada rollout roda em dois componentes: um agent sandbox (que hospeda o scaffold e as ferramentas do agente) e um worker container (que gerencia o sandbox e fornece uma camada de controle agnóstica ao scaffold).

Por que separar? Porque GPUs em clusters de treinamento são preemptíveis. Um job de treinamento pode ser pausado a qualquer momento para dar lugar a outro com prioridade maior. Se o estado do rollout morresse junto, você perderia todo o progresso.

Com a separação, quando uma GPU é preemptada, o DSec pausa o sandbox (usando docker pause para containers ou snapshots de memória para microVMs), libera recursos, e retoma transparentemente quando a GPU volta. Zero replay de logs de comando, zero recriação de ambiente.

Snapshots incrementais: pack_diff

Outra inovação é o sistema de pack_diff. Agentes constroem ambientes interativamente: instalam dependências, modificam arquivos, configuram serviços. O pack_diff cria snapshots incrementais do disco, que podem ser restaurados como novos sandboxes.

Isso elimina a necessidade de pipelines separados de criação de imagens. O agente cria o ambiente, o DSec captura o estado, e qualquer outro agente pode restaurar exatamente aquele ambiente. Criação, validação e consumo na mesma infraestrutura.

Segurança: quando o agente tenta trapacear

Treinar agentes de IA com RL incentiva comportamento adversarial. Se o agente descobre que acessar o gabarito rende mais reward, ele vai tentar. O paper menciona explicitamente mitigações contra “reward hacking”:

AppArmor profiles controlam acesso a arquivos e sockets Unix por sandbox. Não é só “não pode sair do container”, é granular por tarefa: quais arquivos pode ler, quais pode escrever, quais sockets pode acessar.

eBPF por sandbox implementa allowlists de rede específicas por tarefa: IP, porta e protocolo. Se o agente tentar acessar a implementação de referência de um problema de código, ou forjar comunicações internas para inflar seu score, o programa eBPF bloqueia.

Isso é algo que raramente se discute em papers de infraestrutura de IA, mas é crítico. Sem essas barreiras, o treinamento via RL pode colapsar porque o agente aprende a hackear o sistema de avaliação em vez de resolver os problemas.

Os números em contexto

Para colocar os números do DSec em perspectiva:

O tempo mediano de vida dos sandboxes (15 a 17 minutos) é revelador. Não são microservices efêmeros. São sessões interativas longas, onde um LLM está ativamente trabalhando dentro do ambiente. E o P99 de 3+ horas mostra que alguns rollouts são verdadeiras maratonas.

O que isso significa para quem não é a DeepSeek

Vamos ser realistas: a infraestrutura mínima recomendada do DSec é 160 nodes. Isso não é para startups rodando no GCP com créditos free tier.

Mas as ideias do paper são universalmente aplicáveis:

Carregamento sob demanda de imagens é algo que qualquer equipe rodando containers em escala deveria considerar. Se seus containers usam 10% da imagem, por que fazer pull de 100%? Ferramentas como Stargz e Nydus já implementam conceitos similares.

Overcommit inteligente com QoS é relevante para qualquer cluster Kubernetes. A maioria dos pods pede muito mais CPU do que usa. SCHED_IDLE e core scheduling são features do kernel Linux disponíveis para qualquer um.

Separar execução de agentes do pool de GPUs é uma lição de arquitetura que vale para qualquer pipeline de treinamento. GPUs são caras demais para ficarem esperando um agente instalar dependências com pip.

Segurança por sandbox com eBPF é uma prática que deveria ser padrão em qualquer ambiente de execução de código não confiável, não só para treinamento de IA.

DeepSeek continua jogando xadrez enquanto os outros jogam damas

O DSec é mais uma peça do quebra-cabeça que a DeepSeek vem montando. Enquanto a maior parte da indústria briga por quem tem mais GPUs, eles publicam papers sobre como extrair mais de cada componente do stack: memória, CPU, rede, storage. O MoE do DeepSeek-V3, a compressão de contexto do V4, e agora a infraestrutura elástica de sandbox.

O paper tem mais de 130 autores. Isso por si só diz algo sobre a escala de engenharia envolvida. E ao abrir o código, a DeepSeek garante que a comunidade pode construir em cima, validar as claims, e adaptar para seus próprios casos de uso.

Se você trabalha com infraestrutura de IA, DevOps para ML, ou simplesmente quer entender como se treina um agente de IA moderno do zero, esse paper é leitura obrigatória. Não pelos números absurdos (que impressionam), mas pelas decisões de engenharia que os tornaram possíveis.

—

Fonte de inspiração: DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale