Liang Wenfeng ist als Autor aufgeführt, und DeepSeek hat erneut ein neues Forschungspapier veröffentlicht.

DeepSeek hat wieder eine neue Arbeit veröffentlicht.

Diesmal konzentrieren sie sich auf einen Bereich, der von der Außenwelt kaum wahrgenommen wird, aber den Umfang des Agent-Trainings zunehmend beeinflusst: die Sandbox-Infrastruktur.

Titel der Arbeit: DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale

Link zur Arbeit: https://arxiv.org/pdf/2609.22978v1

Dies ist eine 31-seitige Systemarbeit mit über hundert Autoren, darunter Liang Wenfeng. Die Arbeit stellt die produktionsreife Sandbox-Plattform DSec (DeepSeek Elastic Compute) vor, die DeepSeek intern für das großskalige Agent-Training und die Bewertung verwendet.

Zuerst zu dem Umfang: Eine DSec-Produktionseinheit besteht aus etwa 160 CPU-Knoten, 30.000 CPU-Kernen und rund 250 TB DRAM und verwaltet Images und Umgebungsschichten im PB-Bereich. An einem typischen Tag bedient sie rund 3 Millionen Sandbox-Instanzen; zu Spitzenzeiten sind mehr als 380.000 Sandboxes gleichzeitig online, die Erstellungsrate liegt bei über 5000 Stück pro Sekunde.

Besonders erwähnenswert ist die klare Angabe in der Arbeit: Von DeepSeek V3.2 bis V4.1 laufen alle Sandbox-Workloads für das RL-Training und die Bewertung von DeepSeek auf DSec.

Das heißt, diese Arbeit stellt im Grunde die „Trainingsstätte“ vor, die DeepSeek für Modelle im Zeitalter des Agentic-RL aufgebaut hat.

Wenn der Trainingsumfang auf Hunderttausende gleichzeitige Agenten ansteigt, wird ein scheinbar einfaches Problem schnell schwierig: Wo laufen all diese zahlreichen Agenten eigentlich?

Die Agenten werden immer leistungsfähiger bei der Arbeit,

das Trainingssystem hält dem zunächst nicht mehr stand

Bei der Inferenz herkömmlicher großer Modelle besteht die Kernaufgabe darin, Token zu generieren. Bei Agenten hingegen beginnt das Modell, wirklich „aktiv zu werden“: Es öffnet Code-Repositories, durchsucht Dateien, ruft Tools auf, führt Befehle aus, ändert Code und führt Tests durch. Eine einzelne Aufgabenrunde kann Dutzende von Minuten oder sogar Stunden dauern.

In der Phase des verstärkenden Lernens müssen diese Vorgänge zudem in einer echten Umgebung ausgeführt werden. Jeder Agent benötigt eine eigene unabhängige Sandbox mit Code, Abhängigkeiten, Testtools und laufenden Diensten; die von dem Agenten geänderten Dateien und gestarteten Prozesse müssen über mehrere Interaktionsrunden hinweg erhalten bleiben.

Wenn der Umfang steigt, verlagert sich der Druck schnell von der Modellseite auf die Infrastruktur.

DeepSeek hat beobachtet, dass eine einzelne Trainingsaufgabe sofort 32.000 Sandboxes anfordern kann. Diese Umgebungen weisen zudem ein sehr besonderes Ressourcennutzungsmuster auf: Sie laufen lange, sind aber die meiste Zeit nicht ausgelastet.

Daten aus der Arbeit zeigen, dass bei rund 90 % aller Container und microVM die durchschnittliche CPU-Auslastung unter 5 % der zugewiesenen Ressourcen liegt. Gleichzeitig beträgt die mediale Lebensdauer von Containern 17,4 Minuten, die von microVM 15,5 Minuten; bei dem p99-Perzentil laufen beide über drei Stunden lang.

Der Grund ist leicht verständlich: Agenten befinden sich oft in dem Zyklus „Modell denkt – führt einige Befehle aus – wartet weiter auf das Modell“. Dadurch können Hunderttausende Ausführungsumgebungen gleichzeitig im Cluster vorhanden sein, die die meiste Zeit ruhig Speicher und Zustände belegen, und plötzlich gleichzeitig mit der Ausführung von Aufgaben beginnen.

Diese Art von Workload stellt herkömmliche Rechenplattformen vor eine neue Herausforderung: Wie lassen sich Hunderttausende zustandsbehaftete Ausführungsumgebungen langfristig online halten und gleichzeitig die plötzlichen, massiven Anforderungen an Erstellung und Rechenleistung bewältigen?

DSec ist genau die Infrastruktur, die DeepSeek für dieses Problem entwickelt hat.

Vier Arten von Sandboxes für immer vielfältigere Agentenaufgaben

Agenten erledigen immer mehr verschiedene Aufgaben, sodass eine einzelne Lösung nicht mehr alle Anforderungen an Ausführungsumgebungen erfüllen kann. Daher bietet DSec vier verschiedene Ausführungs-Backends an: FnCall, Container, MicroVM und FullVM.

Das leichteste FnCall eignet sich für kurze Aufgaben wie Online-Judge, Code-Kompilierung und GPU-Kernel. Aufgaben der Softwareentwicklung und allgemeine Tool-Aufrufe laufen hauptsächlich in Containern, die schnell starten und eine hohe Bereitstellungsdichte aufweisen. Aufgaben mit höheren Isolationsanforderungen werden an die auf Firecracker basierenden microVM übergeben. Szenarien, die ein vollständiges Betriebssystem erfordern, wie Android, GUI und Grafikrendering, nutzen FullVM.

Alle vier Umgebungen sind einheitlich in dasselbe SDK und dasselbe Lebenszyklus-Management-System integriert. Für den übergeordneten Agenten stellt sich weiterhin eine einheitliche Schnittstelle dar; auf der unteren Ebene kann je nach Aufgabeneigenschaft die passende Laufumgebung ausgewählt werden.

Die einheitliche Schnittstelle ist relativ einfach zu realisieren. Das eigentliche schwierige Problem besteht darin, Hunderttausende solcher Umgebungen gleichzeitig zu erstellen, auszuführen und ihre Zustände zu speichern.

Hunderttausende Sandboxes –

Wie bringt DeepSeek sie alle zum Laufen?

Tausende Sandboxes strömen pro Sekunde herein – das Scheduling-System steht zuerst vor einer Flutwelle

Die Scheduling-Kette von DSec ist nicht besonders komplex.

Nachdem der Benutzer eine Anfrage eingereicht hat, führt das System zunächst die Identitäts- und Berechtigungsprüfung durch, danach sucht die Placement-Engine anhand der Cluster-Auslastung nach geeigneten Knoten. Sobald die Aufgabe auf einem Rechner eingegangen ist, prüfen lokale Komponenten weiter die Kapazität und erstellen dann Container, microVM oder andere Ausführungsumgebungen. Während des Betriebs ist eine weitere Gruppe von Komponenten für die Aufrechterhaltung der Sitzung zuständig und verarbeitet Befehlsausführungen, Dateizugriffe, HTTP-Anfragen und gepufferte Ein-/Ausgabe.

Die Schwierigkeit liegt im Umfang. Zu Spitzenzeiten muss das Produktionscluster von DeepSeek mehr als 5000 Sandboxes pro Sekunde erstellen. Die Anzahl gleichzeitig aktiver Instanzen einer einzelnen Produktionseinheit übersteigt 380.000. Bei dieser Geschwindigkeit wird die Verteilung der Umgebungsimages schnell zum Engpass.

Statistiken aus der Arbeit zeigen, dass die Gesamtmenge der aktiven Umgebungs-Artefakte innerhalb einer Woche über 130 TB beträgt. Zudem sind diese Images stark verteilt: Die mediale Anzahl von Knoten, die ein einzelnes Container-Image nutzen, beträgt nur 3; bei microVM-Images ist sie noch niedriger und liegt bei nur 1. Das heißt, viele Umgebungen werden nach dem Herunterladen auf einen Rechner möglicherweise nur ein- oder zweimal verwendet.

Wenn bei jedem Start einer Sandbox ein vollständiges Image von mehreren GB oder sogar mehr als zehn GB heruntergeladen werden müsste, würden Netzwerk, Festplatte und Startzeit massiv belastet.

Daher platziert DSec die Images auf dem verteilten Dateisystem 3FS von DeepSeek und liest sie bei der Ausführung bei Bedarf aus.

Hinter dieser Wahl steht noch ein sehr wichtiger Datensatz.

Bei einem Image von mehreren GB greift der Agent möglicherweise nur auf wenige hundert MB davon zu

DeepSeek hat die tatsächlich zugegriffene Datenmenge verschiedener Programmierumgebungen analysiert. Das Ergebnis zeigt, dass der Agent bei der Ausführung einer gesamten Aufgabe oft nur einen kleinen Teil des Images nutzt: In der C++-Umgebung sind es etwa 8,7 %, bei Go 13,3 %, bei Java 9,2 %, bei Python 6,0 % und bei JavaScript sogar nur 4,2 %. Ein vollständiges Herunterladen des Images ist offensichtlich verschwenderisch.

Daher setzt DSec auf On-Demand-Loading: Container nutzen EROFS, microVM kombinieren EROFS mit OverlayBD, wobei nur die benötigten Datenblöcke aus 3FS abgerufen werden.

Das funktioniert ähnlich wie das Streamen von Online-Videos: Früher musste man einen ganzen Film herunterladen, bevor man ihn abspielen konnte, heute liest man nur den aktuell benötigten Teil aus. Auf Dateien, auf die der Agent letztendlich nicht zugreift, fallen keine entsprechenden Netzwerk- und Festplattenkosten an.

Dieses Design bringt in späteren Experimenten sehr deutliche Vorteile.

Zu viele Umgebungen – DeepSeek zerlegt sie in „Bausteine“

Die große Anzahl an Images bringt ein weiteres Problem mit sich: Die Kombinationsmöglichkeiten von Umgebungen werden immer vielfältiger.

In einer Agentenaufgabe treten normalerweise gleichzeitig das Basisbetriebssystem, Code-Repositories, Testtools und verschiedene Abhängigkeiten auf. Bei einer anderen Aufgabe ändert sich der Workspace; bei einer Aktualisierung der Toolchain ändert sich wiederum das Toolkit. Wenn jede Kombination als vollständiges Image gespeichert würde, würden die Aktualisierungskosten schnell stark ansteigen.

DSec zerlegt eine Umgebung in mehrere Schichten: Base Image, Workspace, Toolkit und die oberste beschreibbare Schicht.

Das Base Image stellt das Basissystem bereit, im Workspace liegen Code und Aufgabendaten, das Toolkit speichert die Toolchain. Die Änderungen, die während der Ausführung des Agenten entstehen, werden in die eigene beschreibbare Schicht geschrieben. Verschiedene Schichten können unabhängig voneinander aktualisiert und über OverlayFS zu einem vollständigen Dateisystem kombiniert werden.

Die Arbeit zeigt eine sehr anschauliche Änderung der Komplexität: Angenommen es gibt N Umgebungen, dann können die Wiederherstellungskosten bei der Aktualisierung von m Base Images von O(m·N) auf O(m) gesenkt werden; bei der Aktualisierung von k Toolkits sinken sie ebenfalls von O(k·N) auf O(k).

Wenn die Anzahl der Trainingsumgebungen in die Zehntausende oder Hunderttausende geht, wirkt sich dieser Unterschied direkt auf die Erstellungszeit, den Speicherbedarf und die Verteilungskosten aus.

3200 Container auf einem einzigen Rechner – das Problem lautet: Wie verhindert man, dass der Arbeitsspeicher überlastet wird?

Wie bereits erwähnt, weisen Agent-Sandboxes eine besondere Eigenschaft auf: Sie sind sehr zahlreich, aber die CPU ist oft nicht ausgelastet. Das gibt DSec Spielraum für eine Überbereitstellung.

In der Produktivumgebung hat DeepSeek bereits stabil einen Betrieb erreicht: Auf einem einzelnen Knoten laufen mindestens 3200 Container oder 800 microVM. Die Arbeit betont, dass dies nur ein praktisch erprobter Betriebspunkt ist und noch nicht die Obergrenze des Systems darstellt.