Kimi und kvcache-ai Teams veröffentlichen AgentENV als Open Source – eine verteilte Plattform für das Training von Agent RL im Kimi K3 Maßstab

Das Moonshot AI-Team (Entwickler des Kimi K3-Modells) hat gemeinsam mit kvcache-ai die AgentENV-Plattform unter der MIT-Lizenz quelloffen gemacht – ein verteiltes System zur großflächigen Ausführung von Agent-Umgebungen, das für das Verstärkungslernen (Reinforcement Learning, RL) ihres 2,8-Billionen-Parameter-Mixture-of-Experts-Modells (MoE) Kimi K3 verwendet wird. Jede Sandbox ist eine Firecracker-Mikro-VM mit eigenem Linux-Kernel, Dateisystem und Netzwerk-Namensraum und bietet Kernel-Isolation. Die Sandbox-Lebenszyklusverwaltung erfolgt über eine Axum HTTP-API, die Anfragen an einen Orchestrator weiterleitet. Das Rootfs-Dateisystem läuft über ublk im Userspace und verwendet overlaybd für geschichtete Images: Basisschichten sind schreibgeschützt und werden von Sandboxes gemeinsam genutzt, während jede Sandbox eine eigene beschreibbare obere Schicht besitzt. Innerhalb der Gast-VM verwaltet der envd-Daemon (Port 49983) Befehle, Dateioperationen und Statusberichte; ein Reverse-Proxy leitet HTTP- und WebSocket-Datenverkehr von Clients zu VM-Diensten weiter. Besonderes Augenmerk liegt auf der Reduzierung von Overhead: Der Host-Page-Cache wird zwischen Speicherdaten und Speicher-Snapshots geteilt, und ein Memory-Ballooning-Mechanismus ermöglicht die Rückgewinnung überschüssigen Gästespeichers an den Host, was Überbelegung unterstützt, wenn Umgebungen auseinanderdriften. Zu den wichtigsten Funktionen gehören Snapshotting, Pausieren, Fortsetzen und Forken. Snapshots sind inkrementell, nicht vollständig. Berichteten Daten zufolge dauert das Laden oder Fortsetzen eines Snapshots weniger als 50 ms, das Pausieren weniger als 100 ms, und inkrementelle Snapshots werden selbst bei starker Schreiblast in unter 100 ms abgeschlossen. Die Fork-Funktion, die spezifisch für RL ist, ermöglicht das Klonen einer laufenden Sandbox in bis zu 16 unabhängige Child-Sandboxes auf demselben Knoten. Die Parent-Sandbox wird während der Aufnahme kurz pausiert und dann fortgesetzt. Alle Child-Instanzen erben das Dateisystem, den Speicher und die Ressourcenkonfiguration des Parents. Dadurch kann eine teure Einrichtung (Installation von Abhängigkeiten, Klonen von Repositorys) einmal durchgeführt und der Zustand dann in parallele Läufe geforkt werden. Snapshots werden in S3-kompatiblem Objektspeicher oder einem verteilten Dateisystem gespeichert. Standardmäßig hat jede Sandbox eine TTL (Time-to-Live); nach Ablauf wird sie nicht gelöscht, sondern pausiert; zum Löschen muss bei der Erstellung autoPause: false übergeben werden. Images werden bei Bedarf über overlaybd mit einem lokalen Festplatten-Cache geladen, der heiße Daten speichert und kalte Daten auslagert. Dies vermeidet das Vorheizen jedes Images auf allen Knoten und kann die lokale Festplattenkapazität übersteigen. Der Zustand ist in drei Schichten organisiert: ein Collector-Arbeitsbereich für Artefakte, ein Snapshot-Repository (persistenter Speicher) und ein lokaler Laufzeit-Cache für abgeleitete Konfigurationen. Es werden zwei Repository-Backends unterstützt: posix_fs (Standard) und oss (über einen gemeinsamen S3-kompatiblen Client, Region muss explizit angegeben werden). Ein optionaler P2P-Transport basierend auf iroh kann Artefakte an benachbarte Knoten weitergeben, ist aber standardmäßig deaktiviert. Für gemeinsam genutzten Speicher wird eine Mindestbandbreite von 1 Gbit/s empfohlen, und 10 Gbit/s oder mehr werden dringend empfohlen. Für einen einfachen Umstieg bietet AgentENV eine E2B-kompatible HTTP-API: Setzen Sie einfach die E2B_API_URL auf Ihren eigenen Server, und die offiziellen E2B Python-/TypeScript-SDKs funktionieren ohne Codeänderungen an den Agents. Eine native CLI, aenv, ist ebenfalls verfügbar. Die Bereitstellung erfordert Linux 6.8+ und /dev/kvm; das Installationsskript zielt auf Ubuntu 24.04 ab. Die CLI unterstützt Linux und macOS auf x86_64 und arm64, während der Server Linux benötigt (KVM erforderlich). Fünf Bereitstellungsmethoden sind dokumentiert: ein Installationsskript mit systemd, ein Docker-Image, Docker Compose zur Cluster-Simulation, Kubernetes-Manifeste mit Gateway, Scheduler und DaemonSet sowie Bau aus Rust-Quellcode. Bei Mehrknoten-Bereitstellungen werden ein Gateway auf Port 8080 und ein Scheduler auf Port 9090 hinzugefügt.