Um agente de IA que edita um repositório precisa de um ambiente onde possa executar comandos e manter os resultados entre interações. À escala do treino, milhares destes ambientes podem ter de ser iniciados ao mesmo tempo e, depois, ficar à espera 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 sandbox que, segundo a empresa, gere esta carga de trabalho.

Os autores descrevem o fluxo dos pedidos, o armazenamento de imagens e o que acontece quando uma tarefa de treino é interrompida. Os números de desempenho e implementação resultam de medições próprias. O relatório ampliado foi submetido ao arXiv; o resumo indica que uma versão anterior, um resumo alargado de duas páginas, passou a primeira ronda de avaliação de uma conferência.

A grande mudança

  • O que mudou: A DeepSeek documentou o DSec como uma plataforma partilhada para o treino e a avaliação de agentes. Uma única biblioteca cliente interna disponibiliza chamadas de funções, contentores, microVMs e VMs completas.
  • Porque é importante: O relatório relaciona o treino de agentes com a infraestrutura que mantém muitos ambientes de tarefas em execução. Os pedidos 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 obtidos quando necessário. O treino pode pausar sandboxes com estado quando as tarefas de GPU são interrompidas.
  • O que acompanhar:Os processos clientes continuam a escolher o backend. As medições de cargas de trabalho em produção no artigo abrangem contentores e microVMs, que utilizam percursos de armazenamento diferentes e têm custos de recursos distintos. Os números de escala descrevem uma unidade do DSec.

Um pedido, quatro tipos de sandbox

Segundo o artigo, os frameworks de treino e avaliação da DeepSeek e os seus pipelines de dados chamam uma biblioteca Python denominada libdsec. Um pedido típico de criação escolhe o backend e o artefacto do ambiente, define limites de CPU e memória, duração e regras de rede, e fornece um contexto inicial do utilizador. Quando o sandbox está pronto, o cliente pode executar comandos ou chamadas de ferramentas, recolher os resultados e o estado e terminar a sessão. O exemplo de sessão do artigo usa um contentor, 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 no interior da plataforma da DeepSeek, não um método de acesso externo.

Os quatro backends respondem a tarefas diferentes. O FnCall executa tarefas curtas e sem estado em contentores reutilizáveis, pré-criados, evitando iniciar um sandbox a cada chamada. Os contentores servem tarefas com repositórios e a utilização geral de ferramentas; iniciam rapidamente e permitem elevada densidade, mas partilham o kernel com outros contentores na VM anfitriã. As microVMs Firecracker proporcionam um limite de máquina virtual para tarefas que exigem maior isolamento, com um custo superior de arranque e memória. As VMs completas servem sistemas operativos ou cargas gráficas que precisam de recursos indisponíveis nos backends mais leves. Os autores afirmam que os contentores e as microVMs representam a maioria das instâncias em produção e da utilização de recursos. São opções de conceção descritas no artigo, não uma comparação de segurança medida.

Por detrás do cliente, o DSec autentica um pedido de gestão, escolhe um nó com base numa visão periodicamente atualizada da integridade e da carga e encaminha o pedido para o serviço edge na periferia. 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 contentor e de VM em execução usam um proxy denominado aether e processos de sessão de shell denominados chronus para comandos, operações com ficheiros e transmissão de resultados. O FnCall segue um percurso separado através de um contentor pré-criado. Esta distinção é importante 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 num ambiente típico de agente: uma imagem-base, uma área de trabalho para a tarefa e um conjunto de ferramentas que pode mudar independentemente. Se cada combinação fosse incorporada numa única imagem, qualquer atualização das ferramentas exigiria reconstruir muitas imagens. Em vez disso, o DSec sobrepõe camadas apenas de leitura com uma camada gravável por cima. Nos contentores, um runtime Docker modificado combina as camadas com overlayfs. As microVMs usam camadas EROFS apenas de leitura ao lado de discos graváveis, com outro percurso de armazenamento em blocos quando a compatibilidade do sistema de ficheiros o exige.

Os autores relatam que, numa semana de produção, foram utilizadas 11 266 imagens-base de contentor e 102 171 áreas de trabalho de contentor. Esta variedade reduz a vantagem de manter imagens completas em cada nó. O DSec armazena os dados das imagens apenas de leitura no sistema de ficheiros distribuído 3FS da DeepSeek, mantém as gravações no armazenamento local e obtém o conteúdo das imagens quando um sandbox o lê. Os metadados das imagens de contentor são copiados localmente, para que as consultas normais de caminhos não dependam de leituras remotas. O percurso das microVMs usa OverlayBD, ublk e uma cache local para gerir leituras de blocos e instantâneos incrementais.

Numa avaliação separada, com 10 nós, os autores iniciaram 8 192 contentores sob uma carga de avaliação de agentes. O percurso EROFS a pedido concluiu as tarefas em cerca de 35 minutos, contra mais de 60 minutos com o descarregamento 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 comunicadas foram de cerca de 700 GB por nó no carregamento a pedido, contra mais de 1 600 GB no descarregamento antecipado. Estes 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 inativas e retomar execuções interrompidas

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

As interrupções do treino criam outro problema: uma execução pode ainda ter estado útil quando a tarefa de GPU é interrompida. Segundo os autores, a partir do DeepSeek-V4.1 o DSec executa o ciclo do agente fora do conjunto de GPUs sujeito a interrupções, num contentor de trabalho e num sandbox de agente. A tarefa de treino pode voltar a ligar-se a esse estado. Quando o treino é pausado, o framework pode pedir ao DSec que pause os sandboxes associados e recupere memória. Os contentores são congelados e libertados; as microVMs guardam o estado de execução num instantâneo antes de o processo Firecracker terminar. Uma operação posterior retoma o sandbox. Este é o relato do artigo sobre a integração no treino da DeepSeek, não uma garantia geral de recuperação.

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

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 num dia típico, atinge um 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 divulgados pelos autores para uma unidade de escala, não totais auditados de toda a frota da DeepSeek. As experiências de avaliação do artigo foram executadas num cluster separado de 10 nós.

O relatório também descreve limites e modos de falha. Os autores relatam agentes a procurar respostas por canais não previstos e comandos comuns que bloquearam um kernel ou encheram o armazenamento com resultados. Descrevem controlos de ficheiros e sockets do AppArmor e regras de rede por sandbox como medidas de mitigação, mas afirmam explicitamente que esses controlos não impedem todos os comportamentos nocivos. O artigo não oferece um endpoint público do DSec, distribuição externa do SDK, condições de acesso ou preços. Documenta a conceção do sistema e as condições dos testes dos autores, mas não proporciona um meio externo de executar o código de exemplo.

Fontes e leituras complementares