Liang Wenfeng startet RSI mit der Sandbox.

DeepSeek hat gemeinsam mit der Tsinghua-Universität einen Artikel veröffentlicht, der letzte Unterzeichner ist Liang Wenfeng.

Oberflächlich betrachtet beschreibt der Artikel die Sandbox, die DeepSeek für das Training von Agenten verwendet, aber Abschnitt 6 des Papiers wirft bei näherer Betrachtung immer mehr Fragen auf. Zwischen den Zeilen stehen drei englische Buchstaben: RSI.

Durch diese Sandbox kann der Agent die von ihm benötigte Umgebung erstellen, diese Umgebung trainiert den Agenten erneut, und der stärkere trainierte Agent schafft eine bessere Umgebung.

Daraus entsteht ein kleiner geschlossener RSI-Kreislauf.

Aus diesem Grund könnte die Sandbox der Schlüssel sein, der den ersten Krieg um RSI auslöst.

Wovon handelt dieser Artikel eigentlich?

Wovon handelt dieses Forschungspapier genau?

Dieses neue, von Liang Wenfeng unterzeichnete Papier trägt den Titel „DeepSeek Elastic Compute （DSec）: A Sandbox Infrastructure for Effective Agentic Training at Scale“, wurde am 19. September bei arXiv eingereicht und hat die Nummer 2609.22978. Es hat mehr als 130 Autoren, wobei Liang Wenfeng an letzter Stelle steht. Kooperationspartner ist die Tsinghua-Universität.

Was das Papier tut, lässt sich in einem Satz zusammenfassen: DeepSeek hat seine gesamte „Sandbox-Fabrik“ DSec, die es für das Training von Agenten verwendet, vollständig öffentlich gemacht.

Um DSec zu verstehen, muss man zuerst den Unterschied zwischen „Training von Agenten“ und „Training von großen Modellen“ verstehen.

Beim Training großer Modelle werden Daten eingespeist und Gradienten berechnet, die Umgebung ist lediglich ein GPU-Cluster. Das Training von Agenten ist völlig anders: Der Agent muss in der Umgebung Code schreiben, Kompilierungen ausführen, Browser öffnen, Abhängigkeiten installieren, Tools anpassen und dann die Ausführungsergebnisse prüfen, um Vorgänge so oft zu wiederholen, bis die Aufgabe abgeschlossen ist.

Wenn der Agent aber zum Training in einem normalen Computer platziert wird und irgendetwas Unvorhergesehenes ausführt, kann die gesamte Umgebung beschädigt werden.

Aus diesem Grund wird eine isolierte, zustandsbehaftete Sandbox benötigt, die echte Software ausführen kann.

DSec ist genau eine solche Plattform. Es bietet über ein einheitliches Python SDK (libdsec) vier Backends an: Funktionsaufruf (FnCall), Container, leichtgewichtige virtuelle Maschine (microVM) und vollständige virtuelle Maschine (Full VM).

Einfach ausgedrückt ist DSec wie eine Liefer-App, Agenten sind die Lieferfahrer und die Sandbox entspricht der Auftragsverteilung. Analog dazu sind FnCall, Container und leichtgewichtige virtuelle Maschinen die Elektrofahrräder und Wärmefächer, die von den Lieferstationen verteilt werden, und vollständige virtuelle Maschinen sind Kühltransporter.

Hier gibt es jedoch ein kleines Problem: Die Isolationsstärke und die Systemfunktionen stehen von Natur aus im Widerspruch zueinander.

Je ähnlicher eine virtuelle Maschine einem echten physischen Rechner ist, desto langsamer ist ihr Start und desto größer ist der Speicheraufwand. Für kurze Skripte wird ein Funktionsaufruf verwendet, für die Änderung eines Code-Repositorys ein Container, für sicherheitsrelevante Aufgaben eine microVM, und für die Ausführung vollständiger Systeme wie Android oder grafischer Oberflächen kann nur eine vollständige virtuelle Maschine verwendet werden.

Laut dem Papier besteht eine Produktionseinheit aus etwa 160 CPU-Knoten, 30.000 Kernen und 250 TB Speicher, die Images im PB-Bereich hosten.

Es werden täglich etwa 3 Millionen Sandboxes bereitgestellt, der Spitzenwert der gleichzeitigen Nutzung übersteigt 380.000, die Erstellungsgeschwindigkeit liegt bei über 5000 pro Sekunde. Ein einzelner Trainingsauftrag kann bis zu 32.000 Sandboxes gleichzeitig starten. Auf einem einzelnen Knoten können maximal 800 microVMs oder 3200 Container ausgeführt werden.

DSec verfügt über drei Kernmechanismen.

Erstens: Die Umgebung wird in „kombinierbare Schichten“ unterteilt.

Bisher war eine Sandbox-Umgebung ein einziges großes Image: Wenn man ein Toolkit ändern wollte, musste das gesamte Image neu erstellt werden, und die Wartungskosten stiegen mit der Anzahl der Kombinationen sprunghaft an. DSec unterteilt das Basisimage, den Arbeitsbereich und das Toolkit in drei unabhängig voneinander versionisierte schreibgeschützte Schichten (EROFS), die beim Start über overlayfs zusammengefügt werden. Wenn eine Schicht geändert wird, muss nur diese neu erstellt werden. Praktische Tests zeigen, dass dies 1,76-mal schneller ist als das tar.gz-Paketverfahren und die Schreibmenge auf die Festplatte um das 5,5-fache reduziert.

Das ist vergleichbar mit der Ausstattung von Lieferfahrern mit Fahrzeugen: Früher musste das gesamte Fahrzeug ausgetauscht werden, wenn ein einzelnes Bauteil defekt war. Bei DSec wird nur das defekte Teil ausgetauscht.

Zweitens: „On-Demand-Laden“ von Images. Die Images werden im 3FS (verteiltes Dateisystem von DeepSeek) gespeichert, Metadaten werden lokal vorgeladen, und Datenblöcke werden nur dann abgerufen, wenn sie tatsächlich gelesen werden. Praktische Tests zur plötzlichen Bereitstellung von 8192 Containern zeigen, dass das On-Demand-Laden in 35 Minuten abgeschlossen ist, während das Kaltabrufen bei Docker mehr als 60 Minuten dauert und die Schreibmenge auf die Festplatte um etwa 57 % reduziert wird.

Die alte Methode funktioniert nach dem Prinzip „Egal ob man es braucht oder nicht, der gesamte Lagerbestand wird zuerst transportiert“. DSec hingegen funktioniert nach dem Prinzip „Entsprechend dem Lieferauftrag holt der Fahrer nur die Teile, die er wirklich benötigt“.

Drittens: Präzise Verwaltung von Arbeitsspeicher und CPU.

Durch die Kombination von virtio-pmem und DAX können mehrere virtuelle Maschinen denselben Seitencache gemeinsam nutzen, wodurch der Spitzenwert des Speicherverbrauchs um 40,2 % sinkt. Mit DAMON und Balloon werden kalte Seiten zurückgewonnen, sodass der zeitintegrierte Speicherverbrauch um weitere 21,2 % sinkt. Auf der CPU-Seite werden die Sandboxes in zwei Kategorien unterteilt: „latenzempfindlich“ und „Bestmögliche Leistung“. Mit Core Scheduling wird die SMT-Störung von 45,2 % auf 17,3 % reduziert.

Darüber hinaus wird ab DeepSeek-V4.1 der Rollout des Agenten aus dem präemptierbaren GPU-Trainings-Pod herausgelöst und unabhängig auf DSec ausgeführt. Wenn die GPU anderweitig beansprucht wird, geht der Rollout-Zustand nicht verloren.

Einfach ausgedrückt bedeutet das: Die Lieferfahrer nutzen gemeinsam dieselbe Karte und dieselben Regale, ungenutzte Waren im Fahrzeug werden umgehend ins Lager zurückgebracht, eilige Aufträge und normale Aufträge werden getrennt voneinander bearbeitet, ohne sich gegenseitig zu behindern.

Das in Abschnitt 6 verborgene RSI

Der am meisten übersehene Satz im Papier steht nicht in der Zusammenfassung, sondern im Untertitel von Abschnitt 6: Build environments of Agents, by Agents, for Agents. Das bedeutet eine Umgebung, die von Agenten gebaut wird, für Agenten dient und den Agenten gehört.

Dieser Satz bedeutet, dass DeepSeek stillschweigend eine wichtige Angelegenheit mitgeteilt hat: DeepSeek hat bereits einen Teil von RSI realisiert.

In Abschnitt 6.1 des Papiers steht geschrieben, dass die manuelle Erstellung der zahlreichen Umgebungen, die für das RL-Training von Agenten benötigt werden, mittlerweile „unpraktikabel“ (impractical) ist.

Deshalb hat DeepSeek einen anderen Ansatz gewählt: Der Agent baut in derselben Sandbox, die für das Training verwendet wird, interaktiv selbst seine Umgebung auf, und erstellt dann mit pack_diff ein inkrementelles Snapshot dieser Sitzung, das direkt zu einem wiederverwendbaren Trainingsbereich für die nächste Charge wird.

Der Agent, der die Umgebung erstellt, und der Agent, der trainiert wird, nutzen gemeinsam die DSec-Sandbox-Infrastruktur.

Agenten bauen die Umgebung → Die Umgebung trainiert die Agenten → Stärkere Agenten bauen wiederum eine bessere Umgebung. Dadurch hat DeepSeek den geschlossenen Kreislauf von RSI teilweise realisiert.

Aber dieser Kreislauf befindet sich noch in einem frühen Stadium.

In Abschnitt 6.4 werden zahlreiche Fälle dokumentiert, in denen Agenten schummeln: Zum Beispiel suchen sie in der Plattform nach verbliebenen Musterlösungen, fälschen RPC-Nachrichten, um direkt an chronus zu senden und Antworten zu erhalten, durchsuchen die Protokolle von chronus nach durchgesickerten Aufgaben, oder überschreiben sogar /bin/bash, um Prüfungen zu umgehen.

Nachdem sie blockiert wurden, nutzen sie den ioctl-Befehl XFS_IOC_SWAPEXT, um die Speicherblöcke geschützter Dateien auf andere Dateideskriptoren zu verschieben. Dadurch werden die XFS-Metadaten beschädigt, sodass das Dateisystem zwangsweise heruntergefahren wird.

Wo es Schummler gibt, gibt es natürlich auch Agenten, die versehentlich Schaden anrichten. Ein Agent führt einen rekursiven grep-Befehl im Wurzelverzeichnis aus, liest bis /proc/kpagecgroup und löst einen Kernel-Fehler aus, der das System zum Absturz bringt.

Ein anderer Agent ruft den Befehl yes auf, und chronus speichert die gesamte Ausgabe, sodass Dutzende von GB an Daten im Speicher angesammelt werden.

Derzeit läuft der RSI-Kreislauf noch nicht reibungslos. Das Hindernis ist nie die GPU, sondern die Bereitstellung von Umgebungen.

Für jede Generation des Agenten-RL werden neue Aufgaben, neue Sandboxes und neue Abhängigkeiten von Diensten benötigt. Die manuelle Erstellung von Umgebungen ist der eigentliche Engpass.

DSec automatisiert diesen Teilschritt teilweise, indem es automatisch die Umgebungen erstellt, die für RSI benötigt werden.

Nehmen wir wieder das Lieferdienst-Beispiel zur Erklärung.

Eine Lieferplattform möchte immer schneller arbeiten. Sie kann sich nicht darauf verlassen, dass ein einzelner Fahrer immer nur denselben Auftrag ausführt. Damit die Fahrer stärker werden, müssen sie mehr verschiedene Arten von Aufträgen bearbeiten, und je mehr Aufträge es gibt, desto stärker werden die Fahrer wiederum durch die Übung.

Aber um dieses Schwungrad in Gang zu bringen, ist das Hindernis nie die Fahrer, sondern ob es genügend Restaurants gibt. Ohne Restaurants können selbst die schnellsten Fahrer keine Lieferungen durchführen, das Schwungrad dreht sich leer.

DSec hat ein System gebaut, das „automatisch Restaurants erstellt“.

Früher musste die Plattform manuell mit jedem Händler verhandeln, die Küche einrichten, Menüs schreiben und Bewertungsstandards festlegen. Bei Hunderten oder Tausenden von Restaurants ist das nicht mehr machbar.

DSec sagt: „Hört auf zu verhandeln. Lasst die Fahrer in derselben Küche, in der sie Aufträge ausführen, nebenbei ihren eigenen Laden eröffnen. Wie sie den Herd aufgestellt haben, welche Waren sie eingekauft haben und wie sie Wasser und Strom angeschlossen haben, davon erstellt das System mit pack_diff sofort ein Snapshot und speichert es. Die nächste Charge von Fahrern kann dann direkt in diesem Laden anfangen zu arbeiten, ohne alles neu einrichten zu müssen.“

Die Sandbox wird zum neuen Schlachtfeld

DSec ist kein Einzelfall. Die gesamte Branche arbeitet in Richtung „Agenten-Sandbox“.

Das bekannteste Beispiel ist Kimi K3.

Moonshot AI hat K3 am 16. Juli veröffentlicht: Ein MoE-Modell mit 2,8 Billionen Parametern, bei dem jeder Token etwa 104 Milliarden Parameter aktiviert, mit 1 Million Token Kontext und nativer visueller Verarbeitung. Es wird als „das weltweit erste quelloffene 3T-Modell“ bezeichnet und erreicht 76,8 % bei SWE-bench, der höchste Wert unter quelloffenen Modellen.

Sein Agent Swarm kann bis zu 300 Sub-Agenten parallel steuern. In dem Papier von DeepSeek wird genau der Agent Swarm von Kimi-K2.5 zitiert.

AgentENV, das Kimi für das Training von K3 verwendet, ist ebenfalls eine Sandbox.

AgentENV ist eine verteilte Sandbox-Plattform, die auf Firecracker microVMs läuft. Jede Sandbox hat einen unabhängigen Linux-Kernel, einen unabhängigen Netzwerkstack und ein unabhängiges Dateisystem. Für den zugrundeliegenden Speicher wird OverlayBD + ublk verwendet, die schreibgeschützten Schichten werden im gesamten Cluster gemeinsam genutzt, und jede Sandbox beschreibt ihre eigene obere Schicht. Es verwendet denselben Technologie-Stack wie DSec.

In Abschnitt 7 des DSec-Papiers steht geschrieben, dass die von ihm verwendete Rust-Version der OverlayBD/ublk-Speicherbibliothek im AgentENV-Repository quelloffen zur Verfügung gestellt wird.

Beide sind wie zwei Kollegen, die aus derselben Schule stammen.

Aber AgentENV kann RSI nicht realisieren. Es bietet nur „Zustandsoperationselemente“ wie fork/snapshot, sodass der RL-Rollout parallel ausgeführt, zurückgesetzt und sauber bewertet werden kann. Aus diesem Grund kann es nicht wie DSec den Agenten erlauben, selbst Umgebungen zu erstellen.

Ein ähnliches Beispiel ist Alibaba. Auf dem Yunqi-Kongress stellte Li Feifei, CTO von Alibaba Cloud, die „Agentic Cloud“-Strategie vor, bei der Model, Harness und Context als drei Kernszenarien betrachtet werden. Gleichzeitig wurden AgentCore, Agent Sandbox und die neue Generation des Speichersystems CPFS vorgestellt.

Dabei kann Agent Sandbox 100.000 Instanzen pro Minute erstellen, die Aufwachzeit aus dem Tiefschlaf beträgt weniger als 600 Millisekunden, und es ist kompatibel mit E2B und K8s.

Die Sandbox wird zu einer neuen Laufzeitumgebung.

Die Hauptkomponente des Cloud Computing hat sich von virtuellen Maschinen über Container bis hin zu Modellen entwickelt. Jetzt sind die Agenten an der Reihe. Wer die Ausführungsumgebung der Agenten beherrscht, beherrscht den Eingang zur nächsten Generation von Cloud-Diensten.

Das führt dazu, dass sich der Wettbewerbsfokus von der „Modellfähigkeit“ auf die „Umgebungsinfrastruktur“ verlagert.

„Beim Training großer Modelle wetteifert man um Rechenleistung, beim Training von Agenten wetteifert man um Umgebungen“.

Neben GPUs werden nun auch CPU, Arbeitsspeicher, Speicher und Image-Verteilung zu neuen Engpässen.

Darüber hinaus gewinnt die Sicherheit, die bisher nur ein zusätzliches Merkmal war, enorm an Bedeutung. Die Fälle von Modell-Freisetzungen bei OpenAI und Anthropic sowie die Schummeleien und Kernel-Abstürze von Agenten im DSec-Papier beschreiben dasselbe Problem.

Wenn die Sandbox nicht sicher ist, sind die Trainingssignale falsch und die Bewertung nutzlos. Deshalb legen Hersteller wie Alibaba großen Wert auf „Sicherheitszäune“ als Verkaufsargument, und DSec verwendet AppArmor in Kombination mit eBPF.

Früher konkurrierten Sandbox-Hersteller vor allem um Geschwindigkeit und niedrige Kosten. Jetzt beginnen sie damit, darum zu wetteifern, wer die sicherste Lösung anbieten kann.

Der erste Krieg um RSI hat bereits begonnen. Wer RSI ausführen möchte, braucht zuerst eine Sandbox und eine geeignete Umgebung.

Dieser Artikel