Unter der Autorschaft von Liang Wenfeng hat DeepSeek ein neues Forschungspapier veröffentlicht, das auf das Training großskaliger Agenten abzielt.

Nach Berichten von Zhidxam am 23. September wurde kürzlich das neueste, von Liang Wenfeng, Gründer von DeepSeek, unterzeichnete Forschungspapier veröffentlicht, in dem erstmals die technischen Details von DSec (DeepSeek Elastic Compute), der Sandbox-Plattform für Agententraining von DeepSeek, systematisch vorgestellt werden. Das Einreichungsdatum des Papiers ist der 19. September, die Autorenliste umfasst mehr als 130 Personen, unter denen sich Liang Wenfeng befindet.

Adresse des Forschungspapiers: https://arxiv.org/pdf/2609.22978

Die DSec-Plattform tauchte zum ersten Mal im technischen Bericht von DeepSeek V4 auf. Ihre Hauptfunktion besteht darin, Sandboxes für das Agententraining bereitzustellen, um den stabilen Betrieb des groß angelegten Agententrainings zu realisieren. In dem Papier steht ausdrücklich geschrieben: Beim RL-Training und der Bewertung von DeepSeek V3.2 bis V4.1 liefen alle Sandbox-Lasten auf DSec. Die Offenlegung der technischen Details bedeutet nun praktisch die vollständige Veröffentlichung des zentralen technischen Know-hows.

Laut dem Forschungspapier ist die DSec-Plattform sehr groß dimensioniert. Eine einzelne Produktionseinheit besteht aus etwa 160 CPU-Knoten, 30.000 Kernen und 250 TB Arbeitsspeicher und hostet Images im PB-Bereich.

In Bezug auf die Leistungsfähigkeit bedient die DSec-Plattform täglich etwa 3 Millionen Sandboxes, die Spitzenkonkurrenz überschreitet 380.000, die Erstellungsgeschwindigkeit liegt bei mehr als 5000 Stück pro Sekunde, und ein einzelnes Trainingstask kann maximal 32.000 Sandboxes auf einmal starten.

▲ Verteilung der Anzahl von Sandboxes, die pro Task erstellt werden

Nun stellt sich die Frage: Warum werden im Agententraining so viele Sandboxes benötigt? Und wie löst DSec die Probleme von Skalierung, Planung und Ressourcenverwaltung angesichts komplexer Ausführungsumgebungen?

01.

Agent-RL erfordert von Natur aus eine riesige Anzahl an Sandboxes

Die Trainingsumgebung wird zum Entwicklungsengpass

Das Reinforcement Learning beim Training herkömmlicher LLMs kann sich meist um statische Eingaben, Ausgaben und Belohnungssignale drehen, aber das Agententraining unterscheidet sich grundlegend von dem LLM-Training: Es muss tatsächlich in die echte Umgebung eintreten und Aufgaben wie das Überprüfen von Code, das Aufrufen von Tools, das Ausführen von Befehlen und das Ändern von Dateien durchführen. Jeder Schritt, den das Modell ausführt, kann eine Änderung des Umgebungszustands auslösen, und die nächste Ausführung baut auf den vorherigen Ergebnissen auf.

Das bedeutet, dass die Forscher während des Agententrainings neben Modell und Daten auch eine große Anzahl von "Arbeitszuständen" pflegen müssen. Diese Umgebungen müssen echten Computern ausreichend ähneln, sodass Abhängigkeiten installiert und Software ausgeführt werden kann. Außerdem müssen sie nach Abschluss eines Tasks in einen sauberen Zustand zurückversetzt werden können, um für die nächste Runde des Rollouts weiterverwendet zu werden.

Das Problem liegt darin, dass diese Sandboxes zahlreich und ressourcenintensiv sind.

Laut dem Forschungspapier hat ein Task während des Trainings gleichzeitig 32.000 Sandboxes gestartet, diese Sandboxes werden aber nicht vollständig ausgelastet: Wenn der Agent Aufgaben ausführt, befinden sich die Sandboxes oft im Wartezustand auf den nächsten Schritt, sodass die CPU-Auslastung nicht hoch ist. Dass die CPU im Leerlauf ist, bedeutet aber nicht, dass die Ressourcen freigegeben wurden: Arbeitsspeicher und beschreibbare Zustände müssen weiterhin dauerhaft vorgehalten werden.

▲ Die CPU-Nutzung erfolgt intermittierend, Arbeitsspeicher und Zustände werden dauerhaft belegt

Daher lässt sich die herkömmliche Idee "einen Container starten, einen Task ausführen" kaum weiter aufrechterhalten. Die DSec-Plattform wurde entwickelt, um gleichzeitig die Massenerstellung von Sandboxes, Ressourcenplanung, Umgebungskopie, Zustandsspeicherung, Pause-Wiederaufnahme und sichere Isolierung zu lösen.

02.

Vier Umgebungsanforderungen: Ein einheitliches SDK zur Verwaltung

Funktionen, Container und virtuelle Maschinen

Da die Aufgaben, die der Agent ausführen soll, immer komplexer werden, lassen sich die dahinterliegenden Arbeitsumgebungen kaum mehr mit nur einem einheitlichen Standard bewältigen.

Die leichtesten Aufgaben erfordern möglicherweise nur einen einzigen Funktionsaufruf, um Code auszuführen und Ergebnisse zurückzugeben; Aufgaben im Software-Engineering-Bereich benötigen einen vollständigen Linux-User-Space, in dem Abhängigkeiten installiert, Code geändert und Tests ausgeführt werden können; Sicherheitsangriffe und Computer-Nutzung erfordern höhere Isolierungsgrade; wenn bestimmte kommerzielle Software bedient werden soll, muss die erforderliche Umgebung sogar einem vollständigen Computer nahekommen.

DSec bietet vier Backends an: FnCall, Container, Firecracker microVM und vollständige virtuelle Maschine, die jeweils unterschiedliche Anforderungen von kurzfristigen Funktionsaufrufen über Software-Engineering bis hin zu sicherheitssensitiven Aufgaben und vollständigen Betriebssystemumgebungen abdecken. Das Trainingsframework muss sich nicht darum kümmern, ob die unterste Schicht ein Container oder eine virtuelle Maschine ist: Über das Python SDK (libdsec) kann das Trainingsframework direkt die Erstellung von Sandboxes, Befehlsausführung und Ergebnisabwicklung abschließen, ohne verschiedene Umgebungsarten anpassen zu müssen.

▲ DSec bietet vier Backends an

Die vier Backends von DSec werden über dieselbe Plattform einheitlich geplant. Nachdem das Trainingsframework eine Anfrage gestellt hat, führt die Plattform zuerst die Identitäts- und Berechtigungsüberprüfung durch, wählt dann den geeigneten Knoten entsprechend der Clusterauslastung aus, und das Edge-Modul auf dem Knoten ist für die Erstellung der Sandbox verantwortlich. Nach dem Start der Sandbox sind Aether und Chronus für die Verbindung der Plattform mit dem Ausführungsprozess innerhalb der Sandbox zuständig, und die Imagedaten werden bedarfsgesteuert von 3FS bereitgestellt.

▲ DSec-Architektur

Aber wenn diese Umgebungen von wenigen Typen auf zehntausende Instanzen erweitert werden, tauchen neue Probleme auf: Wie kann man schnell eine riesige Anzahl von Umgebungen verschiedener Typen kopieren?

03.

Je mehr Umgebungen, desto schwieriger die Kopie:

Wie DeepSeek zehntausende Sandboxes schnell bereitstellt

Wie bereits erwähnt, sind die Umgebungen für das Agententraining nicht nur zahlreich, sondern auch sehr komplex kombiniert.

Das Forschungspapier hat Daten einer Produktionswoche ausgewertet: Das Container-Backend umfasst 11266 Basisimages, 102171 Arbeitsbereiche und 103 Toolkits. Im laufenden Betrieb überlagern 67,8 % der Sandboxes den Basisimages zusätzlich Arbeitsbereiche oder Toolkits. DeepSeek Harness ist eine dieser Komponenten, die häufig aktualisiert werden müssen.

Wenn alle diese Komponenten in einem einzigen vollständigen Image abgelegt werden, erfordert jede Änderung auf einer beliebigen Schicht möglicherweise den kompletten Neuaufbau und die Neuverteilung des gesamten Images. Bei einer großen Anzahl von Umgebungen steigen die Kosten für Image-Wartung und Bereitstellung entsprechend an.

DSec teilt Basisimage, Arbeitsbereich und Toolkit in drei unabhängige, schreibgeschützte EROFS-Schichten auf, die beim Start der Sandbox über Overlayfs kombiniert werden. Auf diese Weise muss nur die entsprechende Schicht aktualisiert werden, wenn eine Komponente geändert wird, ohne das gesamte Image neu verarbeiten zu müssen.

Die Image-Verteilung erfolgt über bedarfsgesteuertes Laden. Das Forschungspapier zeigt, dass die Daten, die während des Sandbox-Betriebs tatsächlich gelesen werden, nur 4,2 % bis 13,3 % des vollständigen Images ausmachen. Daher speichert DSec die Imagedaten auf 3FS, liest sie bedarfsgesteuert während des Betriebs und holt gleichzeitig die Metadaten vorab lokal ab, während Schreibvorgänge auf der lokalen Festplatte des Knotens verbleiben. Da 3FS besser für große, zusammenhängende Lesevorgänge geeignet ist, kann diese Methode auch die Effizienzprobleme umgehen, die durch zufällige E/A-Vorgänge in kleinen Blöcken entstehen.

▲ DSec teilt die Umgebungen in kombinierbare Schichten auf

Praktische Tests zeigen: Wenn 8192 Container gleichzeitig plötzlich bereitgestellt werden, dauert das bedarfsgesteuerte Laden 35 Minuten, während das kalte Abrufen per Docker mehr als 60 Minuten dauert. Die gesamte Festplatten-Schreibmenge pro Knoten sinkt zudem von etwa 1600 GB auf etwa 700 GB.

Laut dem Forschungspapier kann auch die Erstellung von Umgebungen in der DSec-Plattform von dem Agenten abgeschlossen werden. Über pack_diff generiert der Agent nach der Konfiguration der Umgebung ein inkrementelles Snapshot, aus dem später neue Sandboxes wiederhergestellt werden können.

04.

Rollout aus der GPU auslagern:

Trennung von Training und Ausführung

In frühen Lösungen teilten die Inferenz und der Rollout des Agenten sich die GPU-Pods mit dem Modelltraining. Sobald GPU-Aufgaben verdrängt wurden, wurde der laufende Rollout zwangsweise unterbrochen.

Ab Version V4.1 trennt DeepSeek den Rollout von der GPU-Trainingsumgebung und lässt ihn unabhängig auf der DSec-Plattform laufen. Die Agent-Sandbox ist für die Ausführung von Umgebungen wie DeepSeek Harness zuständig, und der Worker-Container übernimmt die konkreten Aufgaben – beide sind nicht mehr auf GPU-Ressourcen angewiesen. Auf diese Weise kann der Rollout-Zustand unabhängig erhalten bleiben, wenn das GPU-Training verdrängt wird.

▲ Mechanismen von DSec für CPU-Planung, Arbeitsspeicher-Freigabe, geschichtete Images und bedarfsgesteuertes Laden.

Wenn die Clusterkapazität nicht ausreicht, unterstützt DSec auch die Erweiterung auf die Cloud. Wenn beispielsweise die Clusterauslastung 80 % überschreitet, können geeignete Sandboxes auf virtuelle Maschinen in der Cloud verlagert werden. Um den Aufwand für das erneute Abrufen von Images in der Cloud zu senken, hat DeepSeek im Voraus einen deduplizierten Imagesatz von etwa 30 TB vorbereitet, von dem etwa 70 % der Dateien tatsächlich von Container-Aufgaben aufgerufen werden. In der Produktivumgebung können 200 Cloud-VMs etwa 30 % der Spitzenlast übernehmen.

05.

Je realistischer die Umgebung,

desto größer ist das Risiko, das durch die Aktionen des Agenten entsteht

DSec hat die Probleme von Skalierung und Effizienz gelöst, aber in realen Umgebungen gibt es noch weitere Risiken: Beispielsweise führt der Agent die Aufgaben nicht unbedingt wie erwartet aus.

Das Forschungspapier dokument