CoreWeave verknüpft Inferenz und Post-Training in Forge mit Destillations- und RL-Werkzeugen

Post-Training beginnt mit dem Einsatz

CoreWeave argumentiert, dass mit der Auslieferung eines Modells der Entwicklungszyklus nicht mehr endet. Sobald ein Modell echten Datenverkehr verarbeitet, zeigen sich Fehler, Randfälle und Nutzerbedürfnisse, die Benchmarks und Evaluierungen vor dem Einsatz nicht vollständig abbilden können. Laut Unternehmen kann dieses Signal sowohl die Qualität als auch die Kosten verbessern. Es kann etwa zeigen, dass ein kleineres Modell das Verhalten eines teureren nachbilden kann, dass mehr Supervision helfen würde oder dass Reinforcement Learning besser geeignet ist.

Die Schwierigkeit liege darin, den Kreislauf zu schließen, so CoreWeave. Produktions-Traces müssen zu brauchbaren Trainingsdaten werden, das Post-Training braucht Rechenleistung und Orchestrierung, und das entstandene Modell muss evaluiert und zurück in den Betrieb gebracht werden. Das Unternehmen kündigte die drei Funktionen auf der Fully Connected 2026 an. Die programmierbare Training-API befindet sich in der Preview-Phase, der offizielle Start ist für später in diesem Jahr geplant.

CoreWeave rät außerdem, nicht beim Werkzeug, sondern beim Fehlerbild anzusetzen. Retrieval, fehlender Kontext, Prompts, Tool-Fehler und das Serving-Verhalten können alle wie Qualitätsprobleme des Modells aussehen, und eine Änderung der Gewichte behebt kein Problem, das an anderer Stelle im System liegt. Muss das Modell tatsächlich verändert werden, sollte die Technik laut Unternehmen den Belegen folgen: Destillation, wenn ein stärkeres Modell das gewünschte Verhalten bereits zeigt, Supervised Fine-Tuning (SFT), wenn hochwertige Beispiele vorliegen, und Reinforcement Learning (RL), wenn sich Ergebnisse zuverlässig bewerten lassen, die ideale Antwort aber schwer zu beschreiben ist.

Model Distillation und die programmierbare Training-API

CoreWeave Model Distillation wird als der verwaltete Weg durch diesen Kreislauf beschrieben. Inferenz-Datenverkehr kann in CoreWeave Agent Lens erfasst und in Trainingsdaten umgewandelt werden. Der Workflow kann anschließend schwache Ausgaben neu labeln, verschiedene Basismodelle und Hyperparameter testen, Kandidaten auf Serverless Inference bereitstellen und mit dem produktiv laufenden Modell vergleichen.

Als Beispiel nennt CoreWeave Method. Das Unternehmen trainierte 2024 mit dem Vorgängerprodukt OpenPipe ein Llama-3.1-8B-Modell darauf, mithilfe von GPT-4o-Ausgaben durch IVR-Systeme von Banken zu navigieren. Im August 2026 nahm es sich den Anwendungsfall mit frischen Produktionsdaten erneut vor, labelte sie mit GPT-5.6 Sol neu und iterierte noch einmal. Laut CoreWeave gewann das neue Modell 57,5 % der direkten Vergleichsevaluierungen gegen die produktiv laufende Version, bei unverändertem Basismodell.

Für Teams, die mehr Kontrolle wollen, können Nutzer mit der programmierbaren Training-API für Serverless Training, die derzeit in einer begrenzten Preview läuft, die Trainingsschleife in Python schreiben, während CoreWeave Rechenleistung und Trainingsinfrastruktur betreibt. Das Beispiel des Unternehmens kombiniert RL auf Agenten-Trajektorien mit periodischem überwachtem Lernen auf verifizierten Demonstrationen. SFT, RL und Destillation bauen demnach auf denselben Trainingsbausteinen auf.

Als Anwender wird Willow genannt, das zunächst mit überwachtem Lernen begann und dann Scorer für Reinforcement Learning entwickelte. Die Scorer zielten auf Verhaltensweisen wie weniger Füllwörter, bessere Lesbarkeit und das Entfernen selbstkorrigierter Formulierungen. Willow-CTO und Mitgründer Lawrence Liu sagte: "I'm insanely impressed. This model genuinely has a much better grasp on text styling."

RL Rollouts auf CoreWeave Inference

Beim Reinforcement Learning ist die Inferenz Teil des Trainings selbst. Die aktuelle Policy erzeugt Rollouts, das Training liefert neue Gewichte, und diese müssen schnell wieder in den Betrieb zurückgelangen. CoreWeave Inference unterstützt nun RL Rollouts auf Basis von NVIDIA Dynamo mit vLLM-Unterstützung. Trainer, Reward-Logik und Umgebung bleiben dort, wo sie sind.

Laut CoreWeave kann der Trainer neue Checkpoints, sobald er sie schreibt, per Hot-Loading auf ein laufendes Deployment laden, ohne laufende Anfragen oder die Verfügbarkeit des Endpunkts zu beeinträchtigen. Checkpoints werden als vollständige Snapshots oder als inkrementelle Deltas geladen, was nach dem ersten Upload die Synchronisationszeit verkürze, so das Unternehmen. Die Serving-Schicht liefert Metadaten in Trainingsqualität, darunter Logprobs, Token-IDs und Expert-Routing für MoE-Modelle.

CoreWeave arbeitete mit NVIDIA und you.com zusammen, um die Funktion zu validieren. Dazu wurde NVIDIA Nemotron 3.5 Lightning für die Websuche nachtrainiert, mit SFT und RL und den Suchwerkzeugen von you.com in der Schleife. Die Genauigkeit bei BrowseComp stieg um 22,94 %, von einer Basis von 36,97 % auf 45,45 %, während die durchschnittliche Zahl der Tool-Aufrufe um 30,24 % sank. Das Hot-Loading von Checkpoints war laut Unternehmen etwa 15-mal schneller als herkömmliche Redeploy-Zyklen. Die Zugewinne führt CoreWeave auf das Zusammenspiel von besseren Suchwerkzeugen, Verfeinerung im Post-Training und Verbesserungen am Harness zurück.

Was das für Teams bedeutet

Das Versprechen lautet, dass Teams, die Modelle in der Produktion betreiben, diese anhand ihres eigenen Datenverkehrs verbessern können, ohne immer auf ein neueres oder größeres Modell umzusteigen und ohne die verteilten Systeme unter dem Training selbst zu betreiben. CoreWeave Forge soll der Ort sein, an dem diese Workflows zusammenlaufen. Die genannten Ergebnisse von Method, Willow und aus der Zusammenarbeit mit you.com sind eigene Beispiele des Unternehmens und keine unabhängigen Benchmarks.