Um agente de IA que edita um repositório precisa de um ambiente para executar comandos e manter os resultados entre interações. Em escala de treinamento, milhares desses ambientes podem precisar ser iniciados ao mesmo tempo e, depois, aguardar enquanto um modelo decide o que fazer. O relatório técnico de 19 de setembro da DeepSeek sobre o DeepSeek Elastic Compute, ou DSec, descreve o sistema de sandbox que, segundo a empresa, gerencia essa carga de trabalho.

Os autores descrevem o fluxo das solicitações, o armazenamento de imagens e o que acontece quando um trabalho de treinamento é interrompido. Os números de desempenho e implantação vêm de medições próprias. O relatório ampliado é uma submissão ao arXiv; o resumo informa que uma versão anterior, um resumo estendido de duas páginas, passou pela primeira rodada de avaliação de uma conferência.

A grande mudança

  • O que mudou: A DeepSeek documentou o DSec como uma plataforma compartilhada para treinamento e avaliação de agentes. Uma única biblioteca cliente interna oferece chamadas de funções, contêineres, microVMs e VMs completas.
  • Por que isso importa: O relatório relaciona o treinamento de agentes à infraestrutura que mantém muitos ambientes de tarefas em execução. As solicitações passam por autorização, alocação e admissão local; as camadas são combinadas na criação, e os dados das imagens são buscados quando necessário. O treinamento pode pausar sandboxes com estado quando trabalhos de GPU são interrompidos.
  • O que acompanhar: Os chamadores ainda escolhem o backend. As medições de cargas de trabalho em produção no artigo abrangem contêineres e microVMs, que usam caminhos de armazenamento diferentes e têm custos de recursos distintos. Os números de escala descrevem uma unidade do DSec.

Uma solicitação, quatro tipos de sandbox

Segundo o artigo, os frameworks de treinamento e avaliação da DeepSeek e seus pipelines de dados chamam uma biblioteca Python chamada libdsec. Uma solicitação típica de criação escolhe o backend e o artefato do ambiente, define limites de CPU e memória, duração e regras de rede e fornece um contexto inicial do usuário. Quando o sandbox está pronto, o chamador pode executar comandos ou chamadas de ferramentas, coletar a saída e o status e encerrar a sessão. O exemplo de sessão do artigo usa um contêiner, um limite de memória, um tempo limite de inatividade e regras de rede que permitem PyPI e bloqueiam NPM. O texto documenta uma interface usada dentro da plataforma da DeepSeek, não uma forma de acesso externo.

Os quatro backends atendem a tarefas diferentes. O FnCall executa tarefas curtas e sem estado em contêineres reutilizáveis, criados previamente, evitando iniciar um sandbox a cada chamada. Contêineres atendem a tarefas com repositórios e ao uso geral de ferramentas; iniciam rapidamente e permitem alta densidade, mas compartilham o kernel com outros contêineres na VM hospedeira. MicroVMs Firecracker fornecem um limite de VM para tarefas que exigem isolamento mais forte, com maior custo de inicialização e memória. VMs completas atendem a sistemas operacionais ou cargas gráficas que precisam de recursos indisponíveis nos backends mais leves. Os autores afirmam que contêineres e microVMs respondem pela maioria das instâncias de produção e do uso de recursos. São escolhas de projeto descritas no artigo, não uma comparação de segurança medida.

Por trás do cliente, o DSec autentica uma solicitação de gerenciamento, escolhe um nó com base em uma visão periodicamente atualizada de integridade e carga e encaminha a solicitação ao serviço edge na borda. Esse serviço verifica a capacidade local antes de criar o sandbox e pode rejeitar uma alocação baseada em informações desatualizadas do cluster. Os sandboxes de contêiner e VM em execução usam um proxy chamado aether e processos de sessão de shell chamados chronus para comandos, operações com arquivos e transmissão de saída. O FnCall segue um caminho separado por meio de um contêiner criado previamente. Essa distinção importa porque um único ponto de entrada no cliente não elimina diferenças de execução ou de tratamento de falhas.

Montar um ambiente sem copiar tudo

O artigo identifica três partes de um ambiente típico de agente: uma imagem-base, um espaço de trabalho para a tarefa e um conjunto de ferramentas que pode mudar de forma independente. Se cada combinação fosse incorporada a uma única imagem, uma atualização das ferramentas exigiria reconstruir muitas imagens. Em vez disso, o DSec empilha camadas somente para leitura com uma camada gravável por cima. Para contêineres, um runtime Docker modificado combina as camadas com overlayfs. MicroVMs usam camadas EROFS somente para leitura ao lado de discos graváveis, com outro caminho de armazenamento em blocos quando a compatibilidade do sistema de arquivos exige.

Os autores relatam que, em uma semana de produção, foram usadas 11.266 imagens-base de contêiner e 102.171 áreas de trabalho de contêiner. Essa variedade reduz a vantagem de manter imagens completas em cada nó. O DSec armazena os dados de imagem somente para leitura no sistema de arquivos distribuído 3FS da DeepSeek, mantém as gravações no armazenamento local e busca o conteúdo das imagens quando um sandbox o lê. Os metadados das imagens de contêiner são copiados localmente, para que as consultas rotineiras de caminhos não dependam de leituras remotas. O caminho das microVMs usa OverlayBD, ublk e um cache local para gerenciar leituras de blocos e instantâneos incrementais.

Em uma avaliação separada, com 10 nós, os autores iniciaram 8.192 contêineres sob uma carga de avaliação de agentes. O caminho EROFS sob demanda concluiu as tarefas em cerca de 35 minutos, ante mais de 60 minutos com o download antecipado de imagens sem cache; uma configuração com tudo em cache também terminou em cerca de 35 minutos. As gravações em disco relatadas foram de aproximadamente 700 GB por nó no carregamento sob demanda, contra mais de 1.600 GB no download antecipado. Esses números comparam as configurações testadas pelos autores; não demonstram que os mesmos ganhos se repetiriam com outra coleção de imagens ou outro sistema de armazenamento.

Manter sessões ociosas e retomar execuções interrompidas

Um sandbox de agente pode aguardar entre comandos mantendo arquivos, processos e memória. Na amostra de uma semana dos autores, cerca de 90% dos sandboxes de contêiner e microVM usaram, em média, no máximo 5% da capacidade de CPU solicitada. Por isso, o DSec concentra muitas sessões ativas nos nós, tentando controlar o desperdício de memória e a contenção. Para microVMs, o artigo descreve o compartilhamento do cache de arquivos somente para leitura usando virtio-pmem com DAX e a recuperação de páginas inativas das máquinas convidadas com DAMON e a indicação de páginas livres pelo balão de memória. O sistema também separa tarefas sensíveis à latência do trabalho executado com os recursos disponíveis por meio de controles de escalonamento do Linux. O artigo relata benefícios desses mecanismos em suas próprias avaliações, além de custos, como um aumento temporário do uso de CPU com virtio-pmem.

As interrupções de treinamento criam outro problema: uma execução pode ainda ter estado útil quando o trabalho de GPU é interrompido. Segundo os autores, a partir do DeepSeek-V4.1 o DSec executa o ciclo do agente fora do conjunto de GPUs sujeitas a interrupção, em um contêiner de trabalho e em um sandbox de agente. O trabalho de treinamento pode se reconectar a esse estado. Quando o treinamento pausa, o framework pode pedir ao DSec que pause os sandboxes associados e recupere memória. Contêineres são congelados e liberados; microVMs salvam o estado de execução em um instantâneo antes que o processo Firecracker seja encerrado. Uma operação posterior retoma o sandbox. Esse é o relato do artigo sobre a integração ao treinamento da DeepSeek, não uma garantia geral de recuperação.

O que os números de escala informados mostram — e o que não mostram

A DeepSeek afirma que uma unidade de escala do DSec tem quase 160 nós de CPU, cerca de 30.000 núcleos e aproximadamente 250 TB de DRAM. Segundo a empresa, essa unidade processa cerca de três milhões de instâncias de sandbox em um dia típico, atinge pico de aproximadamente 380.000 instâncias simultâneas e cria mais de 5.000 instâncias por segundo. São números de produção informados pelos autores para uma unidade de escala, não totais auditados de toda a frota da DeepSeek. Os experimentos de avaliação do artigo foram executados em um cluster separado de 10 nós.

O relatório também descreve limites e modos de falha. Os autores relatam agentes buscando respostas por canais não previstos e comandos comuns que travaram um kernel ou encheram o armazenamento com saída. Eles descrevem controles de arquivos e sockets do AppArmor e regras de rede por sandbox como medidas de mitigação, mas dizem explicitamente que esses controles não impedem todo comportamento nocivo. O artigo não oferece endpoint público do DSec, distribuição externa do SDK, condições de acesso ou preço. Documenta o projeto do sistema e as condições dos testes dos autores, mas não fornece um caminho externo para executar o código de exemplo.

Fontes e leitura complementar