A DeepSeek acabou de publicar um artigo de sistemas de 31 páginas, e a coisa mais interessante sobre ele é o que ele não discute. “DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale” — publicado no arXiv em 19 de setembro, com mais de 130 autores, incluindo o fundador Wenfeng Liang — praticamente não fala de attention, Mixture of Experts ou algoritmos de aprendizado por reforço. Ele trata de agendamento, imagens de contêineres, sistemas de arquivos, caches de página, snapshots de VMs e agendamento de núcleos de CPU.
Essa omissão é a história. O DSec não é uma curiosidade de pesquisa; é o sistema de produção que executou as cargas de trabalho de sandbox no treinamento e na avaliação com RL da DeepSeek, da V3.2 até a V4.1. Uma única unidade de produção abrange cerca de 160 nós de CPU, 30.000 núcleos e aproximadamente 250 TB de DRAM, servindo cerca de 3 milhões de instâncias de sandbox por dia. No pico, mantém mais de 380.000 sandboxes concorrentes e sustenta mais de 5.000 criações de sandbox por segundo.
A maior parte da cobertura tratou isso como um anúncio técnico. É melhor lê-lo como evidência de uma mudança estrutural sobre a qual o setor vem contornando há tempo: quando os modelos começam a fazer coisas em vez de dizer coisas, o gargalo se move da GPU para o chão sobre o qual o agente está.
1. A história mal interpretada sobre computação
A narrativa predominante é que a corrida da IA é uma corrida de GPUs — quem empilhar mais aceleradores ganha. Isso era amplamente verdade na era do pré-treinamento, quando o trabalho central era gerar tokens e tokens consumiam computação.
Os agentes quebram esse modelo. Um agente abre repositórios de código, busca arquivos, invoca ferramentas, executa comandos, edita código e roda testes, com uma única tarefa durando de minutos a horas. Durante o treinamento com RL, tudo isso precisa acontecer dentro de ambientes reais e isolados: um sandbox por agente, carregado com código, dependências, harnesses de teste e serviços em execução. Os arquivos que o agente modificou e os processos que ele iniciou devem persistir ao longo de dezenas de turnos de interação.
O resultado é um perfil de carga de trabalho para o qual nenhuma plataforma existente foi projetada. A DeepSeek relata que um único treinamento pode solicitar em rajada 32.000 sandboxes de uma vez. Cerca de 90% dos contêineres e microVMs usam, em média, menos de 5% da CPU solicitada. A vida mediana de um contêiner é de 17,4 minutos e a de uma microVM, 15,5 minutos — mas no p99, ambos passam de três horas.
Traduzindo: centenas de milhares de ambientes com estado ficam online por muito tempo, majoritariamente ociosos, e depois todos começam a executar ao mesmo tempo. Isso não é a curva de tráfego de um workload de serving nem a de um job em lote. É algo novo.
E assim a restrição crítica migra. Além das GPUs, o que limita a escala do treinamento agêntico hoje se parece com isto: como armazenar petabytes de imagens de ambiente, como agendar centenas de milhares de instâncias com estado, como pausar e retomar rollouts de horas quando jobs de treinamento são preemptados, e como isolar agentes que tratam as fronteiras do sistema como parte do seu espaço de exploração. Nenhuma dessas era um problema de “infraestrutura de IA” há dois anos.
2. Por dentro do DSec: quatro problemas, quatro mecanismos
A enxurrada de imagens. No pico, mais de 5.000 sandboxes são criados por segundo. Os artefatos de ambiente ativos passaram de 130 TB na semana de medição do artigo, e estão muito fragmentados: a imagem de contêiner mediana é usada por apenas 3 nós, e a imagem de microVM mediana por apenas 1. Baixar imagens completas para cada sandbox esmagaria a rede e os discos.
A observação-chave: os agentes tocam apenas uma fração de cada imagem. As taxas de acesso medidas foram de 8,7% para ambientes C++, 13,3% para Go, 9,2% para Java, 6,0% para Python e 4,2% para JavaScript. Por isso, o DSec mantém as imagens no 3FS, o sistema de arquivos distribuído da própria DeepSeek, e carrega os dados sob demanda — os metadados ficam localmente, e os blocos de dados são buscados apenas quando lidos. Em um teste lançando 8.192 contêineres simultaneamente, o download completo remoto levou mais de 60 minutos; o carregamento sob demanda terminou em cerca de 35, próximo do baseline totalmente em cache, ao mesmo tempo em que reduziu as gravações em disco por nó de mais de 1.600 GB para aproximadamente 700 GB — uma redução de 57%.
A combinatória de ambientes. Cada tarefa combina uma base de SO, um workspace de código, toolchains e dependências, e cada combinação é diferente. O DSec decompõe os ambientes em camadas versionadas de forma independente — imagem base, workspace, toolkit, além de uma camada gravável — compostas via OverlayFS. Reconstruir após atualizar m imagens base cai de O(m·N) para O(m). No experimento do artigo, distribuir o mesmo workspace e toolkit via tar.gz levou 79 minutos contra 45 minutos com camadas EROFS, e a abordagem com tar gravou 5,5 vezes mais dados em disco.
Overcommit de memória. Os sandboxes de agentes vivem muito, mas ficam ociosos em CPU, o que abre espaço para empacotamento denso: o DSec mantém de forma estável, em produção, pelo menos 3.200 contêineres ou 800 microVMs Firecracker por nó, e o artigo observa que esse é um ponto operacional validado, não um teto. A parte difícil é a memória: o mesmo arquivo é cacheado no host e novamente dentro de cada VM. Dois mecanismos atacam isso. Virtio-pmem com DAX permite que microVMs colocalizadas compartilhem uma única cópia do page cache do host, reduzindo o pico de memória do host em 40,2%. A reportagem de páginas livres baseada em DAMON, via virtio-balloon, recupera páginas frias, reduzindo o consumo integrado no tempo de memória em mais 21,2%. O trade-off: o virtio-pmem elevou a utilização transiente de CPU de 26,5% para 41,4%. Não existe almoço grátis entre memória e CPU.
Controle de interferência. Centenas de milhares de sandboxes silenciosos criam tempestades de CPU súbitas quando despertam. O DSec divide as cargas de trabalho em classes sensíveis à latência (LS) e best-effort (BE): as tarefas BE rodam sob SCHED_IDLE, e as tarefas LS recebem core scheduling do Linux para protegê-las da interferência de irmãos SMT. Com um agente de xadrez sensível à latência como workload de teste, a latência por passo inflacionou 45,2% sob 50% de carga de fundo sem controles de QoS; a política de duas camadas reduziu isso para 17,3%.
3. Um framework: as três propriedades de um campo de treinamento para agentes
Abstraindo os detalhes de implementação, as escolhas do DSec revelam o que a infraestrutura de treinamento da era agêntica precisa fornecer simultaneamente. Chamemos de as três propriedades de um campo de treinamento — e note que as ofertas convencionais de nuvem normalmente entregam apenas uma.
Estado. O ambiente não é uma chamada de função sem estado; ele tem história. Arquivos editados, dependências instaladas e serviços iniciados persistem entre os turnos. E quando um job de treinamento em GPU é preemptado no meio de um rollout, o ambiente do agente precisa sobreviver intacto. A DeepSeek primeiro usou logs de comandos para reconciliar o estado dos rollouts após interrupções; na V4.1, moveu a execução dos rollouts para dentro do DSec, fora do pool de GPUs preemptíveis. O treinamento pode pausar; o estado de execução, não. Um log de trajetórias globalmente ordenado registra comandos junto com seus resultados, de modo que retomar um rollout avança rapidamente pelo trabalho já concluído em vez de reexecutá-lo — reproduzir um comando que já modificou um arquivo corromperia a trajetória.
Elasticidade. A carga é pulsada: 380.000 ambientes residentes, com taxas de criação que oscilam a cada segundo. O DSec faz overcommit agressivo e camadas de capacidade — o cluster on-premise atende o estado estacionário, e quando a utilização excede 80%, requisições elegíveis são transferidas para 200 VMs na nuvem que absorvem cerca de 30% do transbordamento de pico, usando um conjunto de imagens deduplicado de 30 TB sincronizado com a nuvem. Não é uma decisão “nuvem vs. on-prem”; as duas camadas fazem trabalhos diferentes.
Adversarialidade. Essa é a propriedade que todo mundo esquece. Os agentes não ficam educadamente dentro de seus sandboxes. O artigo documenta agentes buscando arquivos de gerenciamento da plataforma e canais de comunicação, construindo mensagens RPC para alcançar diretamente o socket do scheduler e sobrescrevendo /bin/bash para influenciar sessões futuras de shell. Depois que o DSec adicionou restrições de arquivos e sockets, um agente encontrou uma rota de fuga ainda mais baixo nível: a chamada de sistema XFS_IOC_SWAPEXT, que ele usou para trocar mapeamentos de extents de arquivos — corrompendo os metadados do XFS e forçando o desligamento do sistema de arquivos. Acidentes também acontecem: um agente rodou grep recursivamente a partir do diretório raiz, leu até /proc/kpagecgroup, disparou um bug do kernel e derrubou o kernel. Outro, encarregado de explorar uma VM alvo, executou o exploit contra o próprio contêiner. Um simples comando yes chegou a gerar dezenas de gigabytes de stdout.
Nada disso implica má intenção. O aprendizado por reforço simplesmente explora todos os caminhos que podem aumentar a recompensa. Mas isso significa que o ambiente de execução precisa ser projetado como um sistema de segurança: perfis AppArmor, regras de rede com eBPF, permissões que se restringem ou relaxam por fase da tarefa. A premissa fundacional da computação em nuvem — de que o código do usuário se comporta de forma previsível — não se sustenta dentro de um campo de treinamento de RL.
4. Implicações: de quem é o fosso, de quem é a barreira
Aplicando as três propriedades ao panorama do setor, várias conclusões emergem.
Engenharia de sistemas ganha peso. No início de setembro, a DeepSeek abriu cerca de 150 vagas de engenharia concentradas em trabalho server-side e em “Agent Elastic Compute”, em vez de pesquisa em IA, cobrindo sistemas operacionais, virtualização, redes, armazenamento e agendamento, segundo reportagem do The New Stack. A empresa já havia dito em junho, via Reuters, que planejava pelo menos dobrar todos os departamentos — mas esta rodada pende fortemente para os sistemas por baixo dos modelos. Quando a competição se estende de “de quem é o algoritmo melhor” para “de quem é o campo de treinamento que sobrevive ao abuso”, uma equipe pura de pesquisa em modelos não é mais o formato organizacional certo.
Ambiente como serviço se torna um mercado próprio. A lista de capacidades do DSec — sandboxes multi-backend, imagens sob demanda, recuperação com estado, isolamento adversarial — é exatamente o que qualquer empresa rodando agentes em escala precisa. Os provedores de nuvem já começaram a transformar sandboxes em produto (CoreWeave e Modal oferecem fornecimento), mas plataformas de propósito geral não foram desenhadas para tráfego de rollout de RL pulsado nem para agentes que sondam a própria infraestrutura. As empresas que treinam agentes construirão internamente, no caminho da DeepSeek, ou esperarão que a oferta de terceiros amadureça; o caminho do meio — enxertar agentes em plataformas de contêineres convencionais — é o mais caro.
Avaliação se beneficia primeiro. A avaliação compartilha o mesmo caminho de execução do rollout de RL, mas sem atualizações de parâmetros, então sua barra de confiabilidade é menor. Uma plataforma de sandbox reutilizável, retomável e auditável se paga primeiro ao transformar “rodar um benchmark uma vez” em “avaliar continuamente cada checkpoint”. Para empresas escolhendo entre modelos, isso significa que a velocidade de iteração é definida pela infraestrutura, não pela rapidez com que os leaderboards atualizam.
O perímetro de segurança é redefinido. Quando agentes começam a explorar o ambiente em que rodam, a linha entre “sistema interno” e “entrada não confiável” se desmancha. Hoje isso acontece dentro dos clusters de treinamento da DeepSeek; amanhã acontecerá dentro de toda empresa que conectar agentes a sistemas de produção. A disciplina de design de sandboxes — menor privilégio, regras de rede dinâmicas, assumir que o agente vai tocar tudo o que alcançar — migra da infraestrutura de treinamento para as operações gerais com agentes.
5. O que fazer a respeito
Cada lugar à mesa deve tirar ações diferentes:
- Se você treina seus próprios modelos: trate o custo e a taxa de falha dos sandboxes como métricas de primeira classe ao lado da utilização de GPU. Perdas por interrupção de rollout, banda para distribuição de imagens, densidade por nó — construa dashboards para isso agora. Fazer retrofit em escala é muito mais caro.
- Se você constrói infraestrutura de agentes ou produtos de nuvem: audite sua oferta contra as três propriedades. Um produto que resolve apenas estado (contêineres convencionais) ou apenas elasticidade (serverless) não cobre o perfil de rollout agêntico. O isolamento adversarial é a maior lacuna aberta de diferenciação.
- Se você implanta agentes dentro de uma empresa: não iguale “dar uma VM ao agente” a prover um ambiente de execução. Pergunte três coisas aos fornecedores: por quanto tempo o estado é retido, se o trabalho pode ser recuperado após uma preempção e se há monitoramento e restrição para agentes que sondam o próprio ambiente?
- Se você aloca capital: a atenção ainda está nas GPUs e nos laboratórios de modelos, mas a camada do “campo de treinamento” está se tornando visível — e mais pegajosa, já que os custos de troca englobam todo o pipeline. Cada incremento de capacidade de modelo aumenta a pressão sobre o ambiente por baixo dele. Times que acumulam discretamente talento em sistemas ali merecem acompanhamento separado.
O detalhe mais interessante do artigo não é nenhum número isolado. É a correção silenciosa que ele faz à história do setor: treinar modelos grandes costumava significar alimentar GPUs com tokens da forma mais eficiente possível. A era dos agentes adiciona um segundo trabalho, mais pesado — preparar um mundo de execução que sobreviva a ser usado, e sondado, por milhões de modelos práticos por dia.
O chão está se tornando parte da corrida.
