CoreWeave Sandboxes startet als Public Preview für RL- und Agenten-Workloads

Warum Agenten abgeschottete Ausführung brauchen

CoreWeave stellt das Produkt in den Kontext eines Wandels in der Modellentwicklung. Früher lernten Modelle, indem sie Text lasen und das jeweils nächste Token vorhersagten. Die leistungsfähigsten Modelle von heute handeln: Sie erzeugen Code, rufen Tools auf, steuern Browser und führen Aktionen für Nutzer aus. Laut CoreWeave erfordert das Training agentischer KI inzwischen Ausführung, denn Agenten erkunden Handlungsräume und führen den von ihnen erzeugten Code aus.

Dieser Code kann Schaden anrichten. CoreWeaves Beispiel ist ein Agent, der rm -rf / ausführt, weil er glaubt, das sei das Richtige. Die Löschung soll eingegrenzt bleiben, der Agent soll lernen, was die Aktion bewirkt, und der umgebende Cluster soll unversehrt bleiben. Das Unternehmen nennt dies Containment auf Sandbox-Ebene: Tausende Sandboxes laufen parallel, ohne dass ein Fehler auf die nächste übergreift.

Teams, die RL im großen Maßstab betreiben, agentische Workflows bauen und kontinuierlich evaluieren, haben laut CoreWeave derzeit drei unbefriedigende Optionen: eine eigene Sandbox-Infrastruktur aufbauen, Kapazität bei einem separaten Anbieter einkaufen oder einschränken, was ihre Agenten ausprobieren dürfen. Jede dieser Optionen häufe mit wachsender Forschung operative Schulden an, so das Unternehmen, und zwar durch Engineering-Zeit für Infrastrukturarbeit, ungenutzte Rechenleistung und Governance-Lücken.

So funktionieren die beiden Betriebsmodi

Auf CKS läuft jede Sandbox in einem eigenen Kubernetes-Pod, gesteuert über ein Profil, das Netzwerkrichtlinien, Ressourcenlimits und Namespace-Grenzen festlegt. Administratoren definieren die Grenzen einmal, und jede aus einem Profil erzeugte Sandbox erbt sie. Profile bestimmen zudem den Rechenumfang, den eine Sandbox nutzen darf, darunter Instanztyp, CPU und Arbeitsspeicher sowie Speicher. Speicherspitzen, Endlosschleifen und Out-of-Memory-Fehler bleiben laut CoreWeave auf den Pod beschränkt, der sie verursacht hat.

Die Serverless-Runtime richtet sich an Forschende ohne CKS-Cluster oder an Teams, die vorhandene Rechenleistung erweitern wollen. CoreWeave verwaltet den Cluster und führt jede CPU-Sandbox standardmäßig in einem Kata Container aus. Jede Sandbox erhält einen eigenen hardwarevirtualisierten Kernel, ein eigenes Dateisystem und ein eigenes Netzwerk. Das Unternehmen bezeichnet dies als eines der stärksten verfügbaren Isolationsmodelle für solche Workloads.

Beide Wege nutzen denselben Python-Client und dieselbe von CoreWeave verwaltete Control Plane. Für Plattformteams bei CoreWeave werden Sandboxes in einem bestehenden CKS-Cluster mit einem einzigen CLI-Befehl aktiviert. CoreWeave betreibt die Control Plane für Authentifizierung und Request-Routing und stellt im Cluster einen Runner bereit, der jede Sandbox plant und verwaltet. Forschende installieren den Client mit pip install cwsandbox. Serverless-Nutzer installieren pip install wandb[sandbox] und authentifizieren sich mit einem vorhandenen API-Schlüssel von Weights & Biases (W&B).

Debugging und Kapazität

CoreWeave verweist auf ein häufiges Problem, wenn Agenten-Rollouts im großen Maßstab scheitern: Lifecycle-Ereignisse, Trainingsmetriken und LLM-Traces liegen in getrennten Systemen. Die Antwort des Unternehmens lautet, jede Sandbox zum Teil des Trainingslaufs zu machen. Lifecycle-Ereignisse der Sandbox erscheinen in derselben W&B-Run-Timeline wie die Metriken, und W&B-Weave-Traces verknüpfen jeden Modellaufruf, Tool-Aufruf und Rückgabewert mit der Sandbox, die ihn erzeugt hat. Code, Eingaben und Ausgaben des Agenten werden pro Sandbox erfasst und lassen sich später abfragen.

Bei der Kapazität werden Sandboxes auf CKS laut CoreWeave über die Cluster verteilt, die ein Kunde bereits betreibt, einschließlich ungenutzter CPUs auf GPU-Knoten, wenn sie zusammen mit SUNK laufen. Damit entfallen nach Darstellung des Unternehmens die Latenz zwischen Clustern, das zweite Abrechnungsmodell und die zusätzliche Kapazitätsgrenze, die bei einem separaten Sandbox-Anbieter anfallen.

Bei der Serverless-Nutzung sind Sandboxes bereits gegenüber der W&B-Identität des Nutzers authentifiziert, und Secrets werden aus dem W&B-Team-Secrets-Store eingespeist. Die Nutzung wird pro Organisation erfasst und ist im W&B-Tarif enthalten, sodass laut CoreWeave keine separate Abrechnungsbeziehung nötig ist.

Erste Kundenstimmen und Einordnung

Die Ankündigung enthält Aussagen von zwei Kunden. Brian Belgodere von IBM Research sagte, das Produkt schließe „eine echte Lücke in unserem KI-Forschungs-Stack“, und ihre RL-Workflows starteten pro Trainingsschritt Tausende Sandboxes parallel. Roman Soletskyi von Mistral erklärte, sein Team betreibe nun über ein einziges Setup Hunderte gleichzeitige Sandboxes auf CPU-Knoten und neben Slurm-Trainingsjobs auf GPU-Knoten.

Für KI-Teams lautet das Angebot: eine einzige Ausführungsebene, die riskanten Agenten-Code isoliert hält und die Ergebnisse zugleich mit dem Experiment-Tracking verknüpft. Bestehende CoreWeave-Kunden können Sandboxes in der Cloud Console aktivieren, und Teams, die Self-Service-Zugang wünschen, können über Weights & Biases starten. Zu Preisen macht die Quelle keine Angaben, außer dass die Serverless-Nutzung im W&B-Tarif enthalten ist.