Anyscale und CoreWeave untertiteln 600 TB Video in 95 Minuten auf 1.600 GPUs

Zwei Ebenen, eine Pipeline

CoreWeave argumentiert, die Datenverarbeitung für multimodale KI sei zu einer GPU-Aufgabe geworden. Video-, Audio-, LiDAR- und Satellitendaten müssten decodiert, gefiltert, mit Merkmalen versehen und normalisiert werden, und im Exabyte-Maßstab brauche man dafür nach Angaben des Unternehmens GPUs. Eine solche Infrastruktur aufzusetzen koste ein Team laut dem Beitrag üblicherweise Wochen oder Monate.

Der Test teilte die Arbeit in zwei Ebenen auf. Ray OSS und Anyscale kümmern sich um die Workload: Sie planen Tasks und Actors, streamen Daten durch die Pipeline und skalieren die Worker je nach Bedarf. Hardwareprobleme wie einen drosselnden Knoten oder eine langsame GPU kann Ray nicht erkennen. Hier kommt CoreWeave ins Spiel.

CoreWeave Kubernetes Service betreibt Kubernetes auf Bare-Metal-Knoten, auf denen GPU-Treiber, Netzwerk- und Speicherschnittstellen sowie Observability-Plug-ins bereits installiert sind. Deshalb, so CoreWeave, dauerte die Installation von Anyscale eine Stunde statt eines Quartals. CoreWeave Mission Control überwacht den Zustand von Knoten und Cluster und ersetzt defekte Knoten automatisch. CoreWeave AI Object Storage (CAIOS) hält die Daten in einem einzigen globalen Namespace ohne Egress-, Anfrage- oder Transaktionsgebühren, und seine Komponente LOTA legt abgerufene Objekte im lokalen NVMe-Speicher zwischen.

Vom Signup in unter 24 Stunden in die Produktion

CoreWeave schlüsselte den Zeitplan stundenweise auf:

• Stunde 0: Eine Reservierung wurde bereitgestellt, skalierbar auf 1.600 GPUs, mit 200 AMD-Turin-9655P-Knoten zu je 192 vCPUs und CAIOS als Data Lake.
• Stunde 1: Anyscale wurde auf CKS als Operator installiert.
• Stunde 2: Ein Orchestrierungstest deckte Knotenverwaltung und Lebenszyklus des Ray-Clusters ab.
• Stunde 10: Die Pipeline wurde in Ray Data als einzelner Streaming-Job geschrieben.
• Stunde 15: Feintuning für GPU-Auslastung und Durchsatz.
• Stunde 20: Derselbe Code wurde ohne Umschreiben in einen fehlertoleranten Anyscale Job überführt.

Die Pipeline bestand aus einer CPU-Stufe für Videodecodierung, Aufteilung an Szenengrenzen und Filterung sowie einer GPU-Stufe, die mit Qwen3-VL-8B Inferenz für Beschreibungen und Annotationen ausführte.

Die erste Version nutzte Ray Core mit manuell verwalteten Actors, die jeweils eine GPU und eine vLLM-Engine hielten, auf einer festen Liste. Der Wechsel zu Ray Data ersetzte das durch Streaming-Ausführung, Autoscaling und integrierte Batch-Inferenz. Bei einem 600-GB-Datensatz, in dem 43.700 Clips zu 1 Million Beschreibungen verarbeitet wurden, benötigte Ray Data laut Beitrag 73 Prozent der GPU-Zeit von Ray Core und lieferte 3,7-mal mehr Beschreibungen pro GPU-Stunde.

Die Daten um den Faktor 1.000 hochskaliert

Um die Kosten im großen Maßstab zu testen, vergrößerte das Team den 600-GB-Datensatz auf 600 TB, indem es mit FFmpeg 1.000 synthetische Varianten jedes Videos erzeugte. In der Spitze machten 35.820 CPU-Kerne aus 43.700 Originalclips 70 Millionen. CAIOS nahm die Schreibzugriffe mit 40 GB/s auf und sättigte damit die Netzwerkbandbreite, bei einer PUT-Latenz von 9,1 s im Median (p50) und 18,8 s im 99. Perzentil (p99).

Beim Captioning des gesamten Datensatzes von 600 TB lieferte CAIOS ohne Caching 110 bis 120 GB/s an rund 46 CPU-Knoten, und der Job war in 95 Minuten abgeschlossen. Als der GPU-Cluster um etwa den Faktor 6 von 256 auf 1.600 GPUs wuchs, blieb die Zahl der Beschreibungen pro GPU-Stunde stabil. Der Gesamtdurchsatz stieg um das 10,2-Fache, von 1.273 auf 12.666 Beschreibungen pro Sekunde. Laut CoreWeave sorgte der größere CPU-Pool dafür, dass die Decodierung den GPUs stets voraus blieb.

Modelle laden ohne Speicherengpass

Wird Qwen3-VL gleichzeitig auf jede GPU geladen, werden etwa 4,3 TB an Tensordaten bewegt, wobei bis zu 255 Peers gleichzeitig dieselben Bytes anfordern. CoreWeave zufolge legt dieses Muster herkömmlichen Objektspeicher lahm. Weil LOTA auf knotenlokalem NVMe zwischenspeichert, greifen spätere Engines, die denselben Tensor anfordern, nicht mehr auf das Backend zu.

Beim 17 GB großen Modell Qwen3-VL las jede Engine mit 8,68 GB/s, und das vollständige Modell war in etwa zwei Sekunden geladen. CoreWeave beziffert das auf das 1,88-Fache der Geschwindigkeit von Objektspeicher eines Drittanbieters und das 1,28-Fache eines Kaltzugriffs auf CAIOS. Bei der reinen Datenaufnahme lasen 1.357 parallele Tasks 677 GB an MP4-Dateien mit etwa 4,5 GB/s ein und waren nach 140 Sekunden fertig.

Was das für Teams bedeutet

Die Ergebnisse stammen aus Benchmarks der beteiligten Unternehmen, doch sie stützen die zentrale These des Beitrags: Nicht der Pipeline-Code, sondern der Aufbau der Infrastruktur sei oft der langsame Teil bei der Vorbereitung multimodaler Trainingsdaten. Für Teams, die Videodatensätze für Bereiche wie Physical AI aufbauen, deuten die genannten Zahlen darauf hin, dass eine verwaltete GPU-Cloud in Kombination mit Ray Data die Einrichtung von Wochen auf einen Tag verkürzen und die GPUs auch dann ausgelastet halten kann, wenn die Datenmenge um Größenordnungen wächst.