Markdown-Ausgabe

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

# DeepSeek erläutert seine DSec-Sandbox-Plattform für das Agententraining

> Ein Forschungsbericht vom September beschreibt DSec, DeepSeeks Sandbox-Plattform für das Agententraining. Dazu gehören mehrere Backend-Systeme, kombinierbare Umgebungen und eine von den Autoren angegebene Einsatzgröße.

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.

Ein KI-Agent, der ein Repository bearbeitet, braucht einen Ort, an dem er Befehle ausführen und Ergebnisse über mehrere Gesprächsrunden hinweg behalten kann. Beim Training in großem Maßstab müssen möglicherweise Tausende solcher Umgebungen gleichzeitig gestartet werden und anschließend warten, während ein Modell über den nächsten Schritt entscheidet. DeepSeeks [technischer Bericht vom 19. September zu DeepSeek Elastic Compute, kurz DSec](https://arxiv.org/html/2609.22978), beschreibt das Sandbox-System, das laut Unternehmen diese Arbeitslast bewältigt.

Die Autoren beschreiben den Anfrageweg, die Speicherung von Images und den Umgang mit Unterbrechungen eines Trainingslaufs. Ihre Angaben zu Leistung und Einsatzumfang beruhen auf eigenen Messungen. Der erweiterte Bericht ist eine arXiv-Einreichung; laut Abstract erhielt zuvor ein zweiseitiger erweiterter Abstract eine erste Begutachtungsrunde auf einer Konferenz.

## Die große Änderung

- **Was sich geändert hat:** DeepSeek hat DSec als gemeinsame Plattform für Agententraining und Evaluierung dokumentiert. Funktionsaufrufe, Container, MicroVMs und vollständige virtuelle Maschinen stehen über eine interne Client-Bibliothek zur Verfügung.
- **Warum das wichtig ist:** Der Bericht verknüpft Agententraining mit der Infrastruktur, die zahlreiche Aufgaben-Umgebungen gleichzeitig am Laufen hält. Anfragen durchlaufen Autorisierung, Platzierung und lokale Zulassung; Umgebungsschichten werden beim Erstellen zusammengesetzt und Image-Daten bei Bedarf abgerufen. Wenn GPU-Aufträge verdrängt werden, kann das Training zustandsbehaftete Sandboxes pausieren.
- **Worauf es ankommt:** Die aufrufenden Dienste wählen weiterhin das Backend. Die Messungen produktiver Arbeitslasten im Bericht umfassen Container und MicroVMs, die unterschiedliche Speicherpfade verwenden und verschieden viele Ressourcen benötigen. Die Angaben zum Umfang beziehen sich auf eine einzelne DSec-Einheit.

## Eine Anfrage, vier Arten von Sandboxes

Laut Bericht rufen DeepSeeks Trainings- und Evaluierungsframeworks sowie Datenpipelines eine Python-Bibliothek namens `libdsec`. Eine typische Erstellungsanfrage wählt Backend und Umgebungsartefakt aus, legt CPU- und Speichergrenzen, Laufzeit und Netzwerkregeln fest und übergibt einen anfänglichen Benutzerkontext. Sobald die Sandbox bereit ist, kann der Aufrufer Befehle oder Werkzeugaufrufe ausführen, Ausgaben und Status abrufen und die Sitzung beenden. In der Beispielssitzung des Berichts wird ein Container mit Speicherlimit und Leerlauf-Zeitüberschreitung verwendet; Netzwerkregeln erlauben PyPI und sperren NPM. Dokumentiert wird eine Schnittstelle innerhalb der DeepSeek-Plattform, kein externer Zugangsweg.

Die vier Backends sind auf unterschiedliche Aufgaben ausgelegt. FnCall führt kurze, zustandslose Arbeiten in wiederverwendbaren, vorab erstellten Containern aus und vermeidet so eine neue Sandbox für jeden Aufruf. Container eignen sich für Arbeiten an Repositories und allgemeine Werkzeugnutzung; sie starten schnell und lassen sich dicht packen, verwenden auf ihrer Host-VM aber denselben Kernel wie andere Container. Firecracker-MicroVMs bieten für Aufgaben mit höherem Isolationsbedarf eine VM-Grenze, benötigen jedoch mehr Startzeit und Speicher. Vollständige VMs übernehmen Betriebssystem- oder Grafikaufgaben, die Fähigkeiten erfordern, welche die leichteren Backends nicht bereitstellen. Die Autoren zufolge machen Container und MicroVMs den Großteil der produktiven Instanzen und Ressourcennutzung aus. Das sind im Bericht beschriebene Entwurfsentscheidungen, kein gemessener Sicherheitsvergleich.

Im Hintergrund authentifiziert DSec eine Verwaltungsanfrage, wählt anhand regelmäßig aktualisierter Angaben zu Zustand und Auslastung einen Knoten aus und leitet die Anfrage an dessen `edge` Dienst weiter. Die Edge-Komponente prüft vor dem Erstellen der Sandbox die lokale Kapazität; sie kann eine Platzierung ablehnen, die auf veralteten Clusterinformationen beruht. Laufende Container- und VM-Sandboxes verwenden einen Proxy namens `aether` und Shell-Sitzungsprozesse namens `chronus` für Befehle, Dateioperationen und gestreamte Ausgaben. FnCall nimmt über einen vorab erstellten Container einen eigenen Weg. Der Unterschied ist wichtig, denn ein gemeinsamer Einstiegspunkt für den Client beseitigt weder Unterschiede bei der Ausführung noch beim Umgang mit Fehlern.

## Umgebungen erstellen, ohne alles zu kopieren

Der Bericht unterscheidet drei Bestandteile einer typischen Agentenumgebung: ein Basis-Image, einen Aufgaben-Arbeitsbereich und ein Toolkit, die sich jeweils unabhängig ändern können. Würde jede Kombination in ein einzelnes Image integriert, müsste ein Toolkit-Update zahlreiche Images neu erstellen lassen. DSec stapelt stattdessen schreibgeschützte Ebenen mit einer beschreibbaren Ebene darüber. Bei Containern setzt eine modifizierte Docker-Laufzeit diese Ebenen mit overlayfs zusammen. MicroVMs verwenden schreibgeschützte EROFS-Ebenen neben beschreibbaren Datenträgern und – wenn die Dateisystemkompatibilität es erfordert – einen anderen Blockspeicherpfad.

Die Autoren berichten von 11.266 Container-Basis-Images und 102.171 Container-Arbeitsbereichen in einer produktiven Woche. Eine solche Vielfalt mindert den Nutzen, vollständige Images auf jedem Knoten vorzuhalten. DSec speichert schreibgeschützte Image-Daten im verteilten 3FS-Dateisystem von DeepSeek, hält Schreibvorgänge lokal vor und ruft Image-Inhalte ab, wenn eine Sandbox sie liest. Container-Image-Metadaten werden lokal kopiert, damit gewöhnliche Pfadabfragen keine entfernten Lesezugriffe erfordern. Der MicroVM-Pfad verwendet OverlayBD, `ublk` und einen lokalen Cache für Blocklesevorgänge und inkrementelle Snapshots.

In einer gesonderten Evaluierung mit zehn Knoten starteten die Autoren unter einer Agenten-Evaluierungsarbeitslast 8.192 Container. Der EROFS-Pfad mit bedarfsabhängigem Laden erledigte die Aufgaben in etwa 35 Minuten, gegenüber mehr als 60 Minuten beim kalten, vollständigen Vorabladen der Images. Auch eine vollständig zwischengespeicherte Vergleichskonfiguration war nach etwa 35 Minuten fertig. Die gemeldeten Schreibvorgänge auf Datenträgern betrugen rund 700 GB pro Knoten beim bedarfsabhängigen Laden und mehr als 1.600 GB beim Vorabladen. Die Werte vergleichen die Konfigurationen im Test der Autoren. Sie belegen nicht denselben Vorteil bei einer anderen Image-Sammlung oder einem anderen Speichersystem.

## Leerlaufende Sitzungen und unterbrochene Trainingsläufe nutzbar halten

Eine Agenten-Sandbox kann zwischen Befehlen warten und dabei Dateien, Prozesse und Arbeitsspeicher behalten. In einer Stichprobe über eine Woche nutzten rund 90 Prozent der Container- und MicroVM-Sandboxes im Tagesmittel höchstens fünf Prozent ihrer angeforderten CPU-Kapazität. Deshalb bündelt DSec viele aktive Sitzungen auf Knoten und versucht zugleich, verschwendeten Speicherplatz und Ressourcenkonflikte zu begrenzen. Für MicroVMs beschreibt der Bericht das gemeinsame Nutzen eines schreibgeschützten Datei-Caches über `virtio-pmem` mit DAX und das Zurückgewinnen ungenutzter Gast-Systemseiten mit DAMON und der Meldung freier Seiten durch den Balloon-Treiber. Außerdem trennt das System latenzempfindliche Aufgaben mithilfe von Linux-Scheduling-Kontrollen von Best-Effort-Arbeiten. Laut Bericht zeigten die eigenen Evaluierungen Vorteile dieser Mechanismen, aber auch Zielkonflikte wie eine höhere vorübergehende CPU-Auslastung mit `virtio-pmem`.

Unterbrechungen beim Training schaffen ein weiteres Problem: Ein Rollout kann noch nützlichen Zustand enthalten, wenn sein GPU-Auftrag vorzeitig beendet wird. Den Autoren zufolge führt DSec ab DeepSeek-V4.1 die Agentenschleife außerhalb des unterbrechbaren GPU-Pools in einem Worker-Container und einer Agenten-Sandbox aus. Der Trainingsauftrag kann sich wieder mit diesem Zustand verbinden. Bei einer Trainingspause kann das Framework DSec auffordern, die zugehörigen Sandboxes anzuhalten und Speicher zurückzugewinnen. Container werden eingefroren und freigegeben; MicroVMs speichern ihren Ausführungszustand in einem Snapshot, bevor ihr Firecracker-Prozess endet. Ein späterer Vorgang setzt die Sandbox fort. Das ist der Bericht der Autoren zur Integration in DeepSeeks Training und keine allgemeine Wiederherstellungsgarantie.

## Was die angegebenen Größenordnungen zeigen – und was nicht

DeepSeek zufolge umfasst eine DSec-Größeneinheit fast 160 CPU-Knoten, rund 30.000 Kerne und etwa 250 TB DRAM. Das Unternehmen berichtet für diese Einheit von rund drei Millionen Sandbox-Instanzen an einem typischen Tag, einer Spitzengleichzeitigkeit von etwa 380.000 und einer Erstellungsrate von mehr als 5.000 Instanzen pro Sekunde. Diese Angaben zur Produktion stammen von den Autoren und betreffen eine DSec-Größeneinheit; sie sind keine unabhängig geprüften Gesamtzahlen für die gesamte DeepSeek-Infrastruktur. Die Evaluierungsexperimente des Berichts liefen auf einem separaten Cluster mit zehn Knoten.

Der Bericht beschreibt auch Fehlergrenzen. Die Autoren schildern, wie Agenten Antworten über unbeabsichtigte Wege suchten und gewöhnliche Befehle einen Kernel zum Absturz brachten oder den Speicher mit Ausgaben füllten. Als Gegenmaßnahmen nennen sie Dateisystem- und Socket-Kontrollen mit AppArmor sowie Netzwerkregeln pro Sandbox. Zugleich stellen sie ausdrücklich fest, dass diese Kontrollen nicht jedes schädliche Verhalten verhindern. Der Bericht nennt weder einen öffentlich zugänglichen DSec-Dienstendpunkt noch eine externe SDK-Verteilung, Nutzungsbedingungen oder Preise. Er dokumentiert Systementwurf und Testbedingungen, bietet aber keinen externen Zugang zum Ausführen des Beispielcodes.

## Quellen und weiterführende Informationen

- [Huang et al., *DeepSeek Elastic Compute (DSec): Eine Sandbox-Infrastruktur für effektives Agententraining in großem Maßstab*, arXiv:2609.22978v1, 19. September 2026](https://arxiv.org/html/2609.22978). Der vollständige technische Bericht ist die Primärquelle für SDK, Backends, Architektur, Umgebungsspeicher, Trainingsintegration, Einschränkungen und die von den Autoren durchgeführte Evaluierung. Die Abschnitte 2 und 3 beschreiben den Anfrageweg, die Abschnitte 5 und 6 die Mechanismen sowie Abschnitt 8 Testaufbau und Ergebnisse. Die Betriebskennzahlen wurden für diesen Artikel nicht unabhängig überprüft.
- [arXiv-Abstract und Einreichungsnachweis zu Version 1](https://arxiv.org/abs/2609.22978). Verzeichnet das Einreichungsdatum, den Umfang des Berichts von 31 Seiten und die begrenzte Begutachtungsgeschichte eines früheren zweiseitigen erweiterten Abstracts. Daraus folgt nicht, dass der erweiterte Bericht einem Peer-Review unterzogen wurde.

## Sources

- [Huang et al., DeepSeek Elastic Compute (DSec): Eine Sandbox-Infrastruktur für effektives Agententraining in großem Maßstab, arXiv:2609.22978v1](https://arxiv.org/abs/2609.22978) — Primärer technischer Bericht; Systementwurf und Betriebskennzahlen stammen von den Autoren. Version 1 des erweiterten Berichts wird nicht als peer-reviewte Veröffentlichung ausgewiesen.