Architecture générale
DeepSeek Elastic Compute (DSec) propose une plateforme de sandbox unifiée qui expose quatre types de back‑ends : FnCall, conteneur, microVM et VM complète. L’accès se fait via un SDK unique, ce qui évite aux développeurs de gérer plusieurs API. Chaque environnement est construit à partir de couches versionnées indépendamment, permettant de réutiliser des bibliothèques communes tout en isolant les dépendances spécifiques. Les images sont stockées sur le Fire‑Flyer File System (3FS), un système de fichiers distribué qui fournit les données d’image à la demande, réduisant ainsi le temps de transfert initial.
Gestion des ressources et isolation
DSec coordonne le placement des sandboxes sur un cluster de 160 nœuds. Le planificateur combine partage de mémoire, recyclage dynamique et ordonnancement CPU afin d’atteindre une densité d’exécution élevée. Cette approche permet de lancer plus de 5 000 créations de sandbox par seconde tout en maintenant la latence requise pour les interactions agent‑LLM. Le découplage entre l’exécution d‑rollout (stateful) et l’entraînement GPU (préemptible) garantit que les états des agents sont conservés même lorsque les ressources GPU sont réallouées.
Performances et mise en production
En production, une unité DSec gère environ 3 millions de sandboxes par jour, avec un pic de 380 000 sandboxes concurrentes. Les mesures indiquent que le temps moyen de mise en place d’un environnement passe de plusieurs dizaines de secondes (avec un transfert d’image complet) à moins de deux secondes grâce au chargement différé depuis 3FS. La combinaison de partage de mémoire et de récupération d’objets inutilisés réduit l’empreinte mémoire de chaque sandbox de près de 30 % par rapport à une approche conteneur‑only, ce qui explique la capacité à sur‑allouer les ressources CPU sans perte de performance.
Limites et perspectives
Le modèle repose sur la disponibilité d’un réseau à faible latence entre les nœuds du cluster ; toute dégradation du réseau impacte directement le temps de récupération d’image depuis 3FS. De plus, la prise en charge de microVM et VM complète augmente la surface d’attaque, nécessitant des contrôles de sécurité supplémentaires pour éviter les comportements d’agents malveillants, notamment le « reward hacking ». Le papier ne fournit pas de métriques détaillées sur la consommation énergétique du cluster, ce qui laisse une incertitude quant à la durabilité du système à très grande échelle. Les auteurs envisagent d’intégrer des mécanismes de profilage dynamique pour ajuster automatiquement le niveau d’isolation en fonction du comportement observé de l’agent.
