Édition Markdown

AI-translated from English; not yet reviewed by a fluent editor.

# DeepSeek détaille le système bac à sable DSec pour entraîner ses agents

> Un rapport de recherche publié en septembre décrit DSec, la plateforme de DeepSeek qui isole les environnements d’entraînement des agents. Il présente plusieurs moteurs, des environnements composables et des chiffres de déploiement rapportés par les auteurs.

By BIG CHANGE Editorial

Published: 2026-09-27T06:48:31.966Z
Updated: 2026-09-27T06:48:31.966Z
Canonical: https://bigchange.ai/blog/deepseek-dsec-agent-training-sandbox-platform

![Conceptual charcoal illustration of an open, unbranded equipment cabinet with connected cables entering a floor channel; two closed cabinets recede behind it.](https://bigchange.ai/api/media/file/dsec-cabinet-hero-v2.png)
AI-generated conceptual illustration by BIG CHANGE.

Un agent d’IA qui modifie un dépôt de code a besoin d’un endroit où exécuter des commandes et conserver les résultats d’un tour à l’autre. À l’échelle de l’entraînement, des milliers de ces environnements peuvent devoir démarrer simultanément, puis attendre pendant qu’un modèle décide de la suite. Le [rapport technique de DeepSeek du 19 septembre sur DeepSeek Elastic Compute, ou DSec](https://arxiv.org/html/2609.22978), décrit le système de bac à sable qui, selon ses auteurs, prend en charge cette charge de travail.

Les auteurs décrivent le cheminement des requêtes, le stockage des images et le comportement du système lorsqu’un travail d’entraînement est interrompu. Les mesures de performance et de déploiement proviennent de leurs propres essais. Le rapport complet a été soumis sur arXiv ; son résumé indique qu’un résumé étendu de deux pages, publié auparavant, a fait l’objet d’un premier tour d’évaluation par une conférence.

## Le changement majeur

- **Ce qui a changé :** DeepSeek présente DSec comme une plateforme commune d’entraînement et d’évaluation d’agents, qui met à disposition des appels de fonctions, des conteneurs, des microVM et des machines virtuelles complètes par l’intermédiaire d’une même bibliothèque cliente interne.
- **Pourquoi c’est important :** Le rapport relie l’entraînement des agents à l’infrastructure qui maintient simultanément de nombreux environnements de tâche. Les requêtes passent par l’autorisation, le placement et l’admission locale ; les couches sont assemblées à la création et les données des images récupérées à la demande. L’entraînement peut suspendre les bacs à sable avec état lorsque des tâches GPU sont préemptées.
- **À surveiller :** L’appelant choisit toujours le moteur. Les mesures de charge de production du rapport portent sur les conteneurs et les microVM, qui utilisent des chemins de stockage différents et entraînent des coûts de ressources différents. Les chiffres d’échelle concernent une seule unité DSec.

## Une requête, quatre types de bac à sable

Selon le rapport, les frameworks d’entraînement et d’évaluation de DeepSeek ainsi que ses pipelines de données appellent une bibliothèque Python nommée `libdsec`. Une requête de création classique choisit le moteur et l’artefact d’environnement, définit les limites de processeur et de mémoire, la durée de vie et les règles réseau, puis fournit un contexte utilisateur initial. Une fois le bac à sable prêt, l’appelant peut exécuter des commandes ou des appels d’outils, recueillir la sortie et l’état, puis arrêter la session. L’exemple de session du rapport utilise un conteneur, une limite mémoire, un délai d’inactivité et des règles réseau qui autorisent PyPI tout en refusant NPM. Il décrit une interface interne à la plateforme de DeepSeek, et non un moyen d’accès externe.

Les quatre moteurs répondent à des tâches différentes. FnCall exécute les tâches brèves sans état dans des conteneurs réutilisables créés à l’avance, évitant d’instancier un nouveau bac à sable à chaque appel. Les conteneurs servent au travail sur des dépôts et à l’usage général d’outils : ils démarrent vite et permettent une forte densité, mais partagent un noyau avec les autres conteneurs de leur machine virtuelle hôte. Les microVM Firecracker fournissent une frontière de machine virtuelle pour les tâches qui nécessitent une séparation plus forte, au prix d’un démarrage plus lent et d’une consommation mémoire accrue. Les machines virtuelles complètes prennent en charge les systèmes d’exploitation ou les tâches graphiques qui nécessitent des capacités absentes des moteurs plus légers. Selon les auteurs, les conteneurs et les microVM représentent la plupart des instances et des ressources en production. Ce sont des choix d’architecture décrits dans le rapport, et non les résultats d’une comparaison mesurée de leur sécurité.

Derrière le client, DSec authentifie une requête de gestion, choisit un nœud en fonction d’une vue périodiquement actualisée de son état et de sa charge, puis dirige la requête vers le composant `edge`. Le composant vérifie la capacité locale avant de créer le bac à sable ; il peut refuser un placement effectué à partir d’informations obsolètes sur le cluster. Les bacs à sable exécutés dans des conteneurs ou des machines virtuelles utilisent un proxy appelé `aether` et des processus de session shell appelés `chronus` pour les commandes, les opérations sur fichiers et la diffusion des résultats en continu. FnCall emprunte un chemin distinct passant par un conteneur créé à l’avance. Cette distinction est importante : un point d’entrée client unique n’efface pas les différences d’exécution et de gestion des défaillances.

## Créer un environnement sans en copier l’intégralité

Le rapport distingue trois composants dans un environnement d’agent classique : une image de base, un espace de travail associé à une tâche et une boîte à outils qui peut évoluer indépendamment. Si chaque combinaison était intégrée à une image unique, toute mise à jour d’une boîte à outils obligerait à reconstruire de nombreuses images. DSec empile plutôt des couches en lecture seule surmontées d’une couche inscriptible. Pour les conteneurs, une version modifiée de Docker compose ces couches avec overlayfs. Les microVM utilisent des couches EROFS en lecture seule et des disques inscriptibles, avec un chemin de stockage par blocs différent lorsque la compatibilité du système de fichiers l’exige.

Les auteurs indiquent qu’au cours d’une semaine de production, le système a utilisé 11 266 images de base de conteneurs et 102 171 espaces de travail de conteneurs. Cette diversité réduit l’intérêt de conserver des images complètes sur chaque nœud. DSec stocke les données d’image en lecture seule dans le système de fichiers distribué 3FS de DeepSeek, conserve les écritures sur le stockage local et récupère le contenu d’une image lorsqu’un bac à sable le lit. Les métadonnées des images de conteneurs sont copiées localement afin que les recherches de chemins courantes n’exigent pas d’accès distant. Le chemin des microVM utilise OverlayBD, `ublk` et un cache local pour gérer les lectures de blocs et les instantanés incrémentiels.

Dans une évaluation distincte sur 10 nœuds, les auteurs ont lancé 8 192 conteneurs dans le cadre d’une charge de travail d’évaluation d’agents. Avec le chargement à la demande d’EROFS, les tâches ont pris environ 35 minutes, contre plus de 60 minutes avec le téléchargement intégral et anticipé des images à froid ; une configuration de référence où les images étaient entièrement en cache a également terminé en environ 35 minutes. Les écritures sur disque rapportées étaient d’environ 700 Go par nœud avec le chargement à la demande, contre plus de 1 600 Go avec le téléchargement anticipé. Ces chiffres comparent les configurations de l’essai des auteurs. Ils ne démontrent pas le même gain avec une autre collection d’images ou un autre système de stockage.

## Garder les sessions inactives et les déploiements interrompus exploitables

Un bac à sable d’agent peut rester inactif entre deux commandes tout en conservant ses fichiers, ses processus et sa mémoire. L’échantillon d’une semaine présenté par les auteurs indique qu’environ 90 % des bacs à sable en conteneur ou microVM n’utilisaient en moyenne pas plus de 5 % de leur capacité processeur demandée. DSec regroupe ainsi de nombreuses sessions actives sur des nœuds, tout en essayant de limiter le gaspillage de mémoire et la contention. Pour les microVM, le rapport décrit le partage du cache de fichiers en lecture seule via `virtio-pmem` avec DAX, ainsi que la récupération de pages froides dans les machines invitées grâce à DAMON et au signalement des pages libres par ballooning. Il distingue également les tâches sensibles à la latence des tâches exécutées au mieux des ressources disponibles grâce aux contrôles d’ordonnancement Linux. Les auteurs rapportent des gains liés à ces mécanismes dans leurs propres évaluations, ainsi que des compromis, comme une hausse temporaire de l’utilisation du processeur avec `virtio-pmem`.

Les interruptions d’entraînement posent un autre problème : un déploiement peut conserver un état utile lorsque la tâche GPU qui l’exécute est préemptée. Selon les auteurs, depuis DeepSeek-V4.1, DSec fait tourner la boucle de l’agent hors du pool de GPU préemptibles, dans un conteneur de travail et un bac à sable d’agent. Le travail d’entraînement peut ensuite se reconnecter à cet état. Lorsqu’il est suspendu, le framework peut demander à DSec de mettre en pause les bacs à sable associés et de récupérer leur mémoire. Les conteneurs sont figés puis récupérés ; les microVM enregistrent leur état d’exécution dans un instantané avant l’arrêt de leur processus Firecracker. Une opération ultérieure reprend le bac à sable. Il s’agit de la description par l’article de l’intégration à l’entraînement de DeepSeek, et non d’une garantie générale de récupération.

## Ce que les chiffres d’échelle rapportés montrent — et ne montrent pas

DeepSeek indique qu’une unité DSec comprend près de 160 nœuds processeur, environ 30 000 cœurs et quelque 250 To de mémoire vive. Pour cette unité, l’entreprise rapporte environ trois millions d’instances de bacs à sable lors d’une journée typique, un pic de simultanéité proche de 380 000 instances et un rythme de création supérieur à 5 000 instances par seconde. Ces chiffres de production sont rapportés par les auteurs pour une unité DSec ; ils ne constituent pas un décompte vérifié de manière indépendante de l’ensemble du parc de DeepSeek. Les expériences d’évaluation décrites dans le rapport ont été menées sur un cluster distinct de 10 nœuds.

Le rapport décrit aussi les limites en matière de défaillances. Les auteurs racontent que des agents ont cherché des réponses par des voies imprévues et que des commandes ordinaires ont fait planter un noyau ou rempli un espace de stockage de résultats. Ils décrivent les contrôles de fichiers et de sockets d’AppArmor ainsi que les règles réseau propres à chaque bac à sable comme des mesures d’atténuation, tout en précisant explicitement qu’elles n’empêchent pas tous les comportements nuisibles. L’article ne fournit aucune adresse de service DSec publique, aucun SDK distribué à l’extérieur, aucune condition d’accès et aucun tarif. Il documente la conception du système et les conditions des essais réalisés par les auteurs, mais ne donne aucun moyen d’accès externe pour exécuter son code d’exemple.

## Sources et lectures complémentaires

- [Huang et al., *DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale*, arXiv:2609.22978v1, 19 septembre 2026](https://arxiv.org/html/2609.22978). Le rapport technique complet est la source principale pour le SDK, les moteurs, l’architecture, le stockage des environnements, l’intégration à l’entraînement, les limites et les évaluations menées par les auteurs. Les sections 2 et 3 décrivent le cheminement des requêtes ; les sections 5 et 6 présentent les mécanismes ; la section 8 détaille le protocole et les résultats. Les chiffres opérationnels de l’article n’ont pas été vérifiés de manière indépendante pour cet article.
- [Résumé arXiv et fiche de soumission de la version 1](https://arxiv.org/abs/2609.22978). Cette fiche indique la date de soumission, la longueur de 31 pages du rapport et l’historique limité de l’évaluation d’un résumé étendu de deux pages publié auparavant. Elle n’établit pas que le rapport complet a été évalué par les pairs.

## Sources

- [Huang et al., DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale, arXiv:2609.22978v1](https://arxiv.org/abs/2609.22978) — Rapport technique principal ; la conception du système et les chiffres opérationnels sont rapportés par les auteurs. La version complète 1 n’est pas présentée comme ayant été évaluée par les pairs.