Neue Veröffentlichung von DeepSeek-Papieren: Das "Hauptquartier" für das Training von V4.1 Agent wird erstmals öffentlich bekannt gegeben, Liang Wenfeng ist als Autor aufgeführt.

DeepSeek veröffentlicht gemeinsam mit der Tsinghua-Universität den neuesten technischen Bericht „DeepSeek Elastic Compute (DSec): Eine Sandbox-Infrastruktur für effektives Agententraining im großen Maßstab“, in dem erstmals die „industrielle Grundlage“ – DSec – öffentlich vorgestellt wird, die das Training von DeepSeek von V3.2 bis V4.1 unterstützt.

Das Autorenteam des Papers umfasst mehr als 130 Personen, wobei Liang Wenfeng an letzter Stelle der Liste steht. Daraus geht hervor, dass DeepSeek die Infrastruktur für das Agententraining als zentrales Ingenieursprojekt einstuft.

DSec ist eine eigenentwickelte produktionsreife elastische Compute-Sandbox-Plattform von DeepSeek, eine interne spezielle Infrastruktur, die bereits im Bericht zu DeepSeek-V4 vorgestellt wurde. Ihre Aufgabe besteht darin, eine sichere und stabile Sandbox-Laufzeitumgebung für das großskalige Training und die Bewertung von Large-Model-Agenten bereitzustellen.

Laut dem Paper besteht eine Produktionseinheit aus etwa 160 CPU-Knoten, 30.000 CPU-Kernen und 250 TB Arbeitsspeicher und hostet Images im PB-Bereich. In Bezug auf die Kapazität kann DSec an einem einzigen Tag etwa 3 Millionen Sandboxes bedienen, mit einem Spitzenwert von mehr als 380.000 gleichzeitigen Instanzen und einer Erstellungsgeschwindigkeit von über 5000 Sandboxes pro Sekunde. Ein einzelner Trainingsauftrag kann maximal 32.000 Sandboxes in einem einzigen Aufruf starten.

Dieses Paper liefert nicht nur eine systemweite Architekturlösung, sondern dokumentiert auch eine große Anzahl dramatischer Spielarten, bei denen Modelle im Sandboxinneren „versuchen, auszubrechen, Antworten auszuspähen und das System zum Absturz zu bringen“.

Wenn das frühere Scaling von Large-Modellen darin bestand, mehr Parameter, Daten und Token in GPU-Cluster zu laden, dann zeigt DSec die stark unterschätzte Expansion im Agent-Zeitalter: Modelle treten in echte Umgebungen ein, und die Anzahl der wiederholten Aufgabenausführungen und Versuch-und-Irrtum-Lernprozesse wird ebenfalls skaliert.

Die Generierung von Code durch Modelle ist nicht das Endziel. Der eigentliche Engpass liegt in der physischen Infrastruktur, die diesen Code sicher, schnell und gleichzeitig ausführen kann.

Das Versagen traditioneller Cloud-Architekturen

Um DSec zu verstehen, muss man zuerst den grundlegenden Unterschied in der zugrundeliegenden Logik zwischen Agentischem Reinforcement Learning (Agentic RL) und traditionellem Large-Modell-Training erkennen.

Beim früheren Training von Sprachmodellen war die Interaktionslogik näher am „Beantworten von Fragen“: Man gibt dem Modell Prompt-Wörter oder mathematische Aufgaben ein, das Modell generiert eine Ableitung oder eine Antwort, und das System berechnet die Belohnung nach Regeln und aktualisiert die Parameter durch Backpropagation.

Aber Agenten, die auf echtes Software-Engineering (SWE) oder Systemoperationen (Computer-Use) ausgerichtet sind, sind völlig anders. Nachdem ein Agent eine Aufgabe erhalten hat, muss er Code-Repositories durchsuchen, Kontext lesen, Abhängigkeitsumgebungen konfigurieren, Codelogik ändern, Tests im Terminal ausführen und basierend auf Fehlermeldungen weiter debuggen. In diesem Prozess gibt das Modell nicht statisch Text aus, sondern bedient tatsächlich einen Computer.

Kumulative Verteilungsfunktion (CDF) der Sandbox-Erstellungsmenge pro Aufgabe, die die transiente Impulsmerkmale von gleichzeitigen Anforderungen von Tausenden bis Zehntausenden Sandboxes pro Aufgabe im Produktionsbetrieb zeigt

Bei einem einzelnen Rollout im Reinforcement Learning muss das System, wenn Tausende von Agenten gleichzeitig explorieren, sofort Zehntausende voneinander isolierte Ausführungsumgebungen bereitstellen. Noch wichtiger ist, dass diese Umgebungen zustandsbehaftet und hochgradig kohärent sein müssen. Der Befehl, den der Agent im zehnten Schritt ausführt, muss streng auf den Dateien, kompilierten Binärdateien und gestarteten Dienstprozessen basieren, die in den ersten neun Schritten modifiziert wurden.

Allerdings stoßen traditionelle Container-Orchestrierung und zustandsloses Serverless, vertreten durch Kubernetes, deren zugrundeliegende Annahmen auf glatter Skalierung und zustandslosen Microservices basieren, direkt auf dreifache strukturelle Fehlanpassungen bei dieser hochfrequenten impulsiven, lang andauernden und extrem heterogenen Computing-Last:

Kurven der Sandbox-Lebenszyklusverteilung, die das Phänomen des lang andauernden Verbleibs von Sandboxes mit einer Lebensdauer von mehr als 3 Stunden direkt veranschaulichen

Transiente Impulsgleichzeitigkeit: Eine einzelne Aufgabe kann innerhalb weniger Sekunden Zehntausende Sandboxes anfordern (Spitzenwert von 32.000). Das vollständige Abrufen und Entpacken führt sofort zu schwerem Schreib-I/O-Stau, verlängert die Startverzögerung erheblich und lässt GPU-Cluster leerlaufen;

Massive Heterogenität und extrem geringe Wiederverwendung: Bei Umgebungsdaten von über 130 TB beträgt der Median der Image-Wiederverwendungs-Fanout nur 1 bis 3, wodurch herkömmliche lokale Caching-Mechanismen vollständig unwirksam werden;

Langer Verbleib und Computing-Gezeiten: Sandboxes leben Dutzende von Minuten oder sogar Stunden, aber in 90 % der Zeit beträgt die CPU-Auslastung weniger als 5 %, was zu extremer Verschwendung von exklusiv zugewiesenen Ressourcen führt, während grobes Overcommitment leicht zu Speicherüberläufen und Hyperthreading-Konflikten führt.

Herkömmliche Cloud-Computing-Lösungen können nicht gleichzeitig hohe Gleichzeitigkeit, starken Zustand und niedrige Kosten berücksichtigen. DSec ist genau der „spezielle digitale Übungsplatz“, den DeepSeek zur Lösung dieser Widersprüche aufgebaut hat.

Abwägungen zwischen vier Arten von Backends

Da allgemeine Container-Cluster nicht direkt angewendet werden können, besteht die intuitivste Idee möglicherweise darin, eine „ultimative Sandbox mit der besten Leistung und den vollständigsten Funktionen“ zu erstellen. Die Ingenieurspraxis von DeepSeek beweist jedoch, dass eine einzelne virtualisierte Laufzeit nicht gleichzeitig sichere Isolation und Ressourcenaufwand berücksichtigen kann.

Unterschiedliche Aufgaben haben natürliche Lücken in den Anforderungen an die Umgebung: Das Ausführen eines Operator-Skripts dauert nur wenige Millisekunden, Systemangriffe und -verteidigungen erfordern strenge hardwarebasierte Virtualisierung, und das Ausführen eines Android-Emulators hängt von einem vollständigen Betriebssystem und Grafiktreibern ab. Wenn alle schwergewichtigen virtuellen Maschinen verwendet werden, geraten die Hardwarekosten schnell außer Kontrolle; wenn alle leichtgewichtigen Container verwendet werden, können Sicherheit und Umgebungskompatibilität nicht erfüllt werden.

Daher gibt DSec die Illusion einer universellen Sandbox auf und teilt die Umgebungen in vier hierarchische Ebenen ein:

Topologie des gesamten DSec-Architektur, die die schichtweise Interaktion zwischen libdsec, der Cluster-Verwaltungsebene (IAM, Placement Engine), der Einzellaufzeit (Edge, Aether, Chronus) und 3FS zeigt

FnCall (Funktionsaufruf): Ausgerichtet auf kurzzeitige zustandslose Aufgaben (z. B. algorithmische Aufgabenbewertung oder GPU-Operator-Benchmarktests), läuft es auf einem residenten Vorwärm-Pool, beseitigt Kaltstartverzögerungen und unterstützt exklusive oder gemeinsam genutzte GPUs;

Container (Standard-Container): Trägt hauptsächlich Software-Engineering und Tool-Interaktionen. Auf einem einzelnen Rechner können 3.200 Instanzen mit hoher Dichte bereitgestellt werden, wodurch Leichtigkeit und Kompatibilität mit der grundlegenden Linux-Toolchain berücksichtigt werden;

MicroVM (leichtgewichtige virtuelle Maschine): Baut einen unabhängigen Kernel auf Basis von Firecracker auf, bietet hardwarebasierte Isolation für sichere Angriffs- und Verteidigungsaufgaben und verhindert das Entkommen zwischen Mietern;

Full VM (voll funktionsfähige virtuelle Maschine): Baut auf QEMU auf und bindet virtualisierte GPU-Treiber ein, und ist ausschließlich für fortgeschrittene Umgebungen vorgesehen, die vollständige kommerzielle Betriebssysteme, grafische Oberflächen, Android-Emulatoren oder Spiel-Rendering erfordern.

Vergleich der vier Sandbox-Backends (FnCall, Container, MicroVM, Full VM) in Bezug auf Leistung, Aufwand, Isolationsstufe und Szenenkompatibilität

Der Kern dieses Designs besteht darin, dass die Umgebungen nicht einheitlich sein müssen, sondern die Steuerschnittstelle für den Zugriff auf die Umgebungen einheitlich ist. Die Plattform verbirgt die Umgebungsunterschiede für die oberen Ebenen über ein einheitliches Python-SDK (libdsec). Algorithmenentwickler müssen nur den erforderlichen Berechnungstyp und die Ressourcenobergrenze der Aufgabe in der Anforderung angeben, und das Schedulingsystem leitet die Aufgabe automatisch an den geeigneten Berechnungsträger weiter.

Overcommitment von Computing-Gezeiten

Die Festlegung von vier Sandbox-Backends ist nur der Aufbau der „Räume“ für Aufgaben. Das echte Problem, das das System an seine Grenzen bringt, tritt auf: Bei herkömmlichen Ressourcenkontingenten können 160 physische Maschinen nicht gleichzeitig 380.000 gleichzeitige Sandboxes aufnehmen.

Um zu erreichen, dass ein einzelner Berechnungsknoten stabil bis zu 3.200 Container oder 800 MicroVMs tragen kann, liegt der Kern darin, das spezielle Verhaltensmuster des Agentencomputings zu erfassen: Sandboxes verbrauchen nicht ununterbrochen CPU.

In der tatsächlichen Interaktion wartet die Sandbox still, während das Modell nachdenkt; nachdem das Modell Anweisungen ausgegeben hat, steigt die CPU-Auslastung sofort an; nach Abschluss der Ausführung fällt die Computing-Leistung schnell wieder auf ein Tief zurück. Daten zeigen, dass 90 % der Sandboxes in ihrem Lebenszyklus eine durchschnittliche CPU-Auslastung von weniger als 5 % des beantragten Kontingents aufweisen. Da die Computing-Leistung hochgradig impulsiv und gezeitenbedingt ist, verfügt das System über die objektive Grundlage für die Implementierung von extremem Ressourcen-Overcommitment (Overcommit).

Kurven von CPU-Impulsen und residentem Speicher während des Sandbox-Lebenszyklus

Extrem spärliche Verteilungsmerkmale der tatsächlichen CPU-/Speicherauslastung

Allerdings führt hochvergrößertes Overcommitment leicht zu systemweiten Kollisionen. DSec hat drei kritische Absicherungen auf Kernel-Ebene implementiert:

- Durchdringende gemeinsame Nutzung von Nur-Lese-Speicher: In MicroVMs wird Virtio-pmem in Kombination mit DAX-Technologie aktiviert, um Nur-Lese-Platteninhalte direkt in den Host-Speicher abzubilden und den eigenen Seitencache des Gastbetriebssystems zu umgehen. Dadurch teilen Hunderte von virtuellen Maschinen auf einem einzelnen Rechner vollständig denselben physischen Host-Speicher, wodurch der Spitzenwert des Host-Speichers um 40,2 % sinkt;