CoreWeave: Distributed File Storage hält in Tests 1 GiB/s pro GPU durch

Wie das I/O-Muster beim Training im großen Maßstab aussieht

CoreWeave geht zunächst von einem repräsentativen Workload aus: dem Training eines Modells mit mehreren Milliarden Parametern auf 4096 NVIDIA H100 GPUs. Den Angaben des Unternehmens zufolge zeigen die ersten zwei Trainingsstunden zwei unterschiedliche Muster.

• Initiales Laden der Daten: Beim Start lädt das Modell Daten in den GPU-Speicher, was einen intensiven Schub umfangreicher, teils zufälliger Lesezugriffe auslöst. CoreWeave weist darauf hin, dass zur Optimierung der Daten gehört, sie so abzulegen, dass zufällige Lesezugriffe minimiert und sequenzielle maximiert werden.
• Checkpoint-Operationen: Periodische Schreibspitzen entstehen, wenn der Modellzustand in den Speicher geschrieben wird. Im Beispiel kommen synchrone Schreibvorgänge zum Einsatz, die ausgeprägte I/O-Spitzen erzeugen, auch wenn einige Frameworks asynchrones Checkpointing unterstützen.

Der Workload erreicht Spitzen bei den Leseraten von etwa 70 GiB/s und Schreibspitzen von bis zu 50 GiB/s. Laut CoreWeave sind die Schreibraten bei Checkpoints durch die Zahl der Ranks, die Checkpoints schreiben, und durch die Anbindung dieser Hosts begrenzt; diese Werte skalieren in der Regel mit der GPU-Anzahl. Die den Cluster versorgende Speicherinfrastruktur verfüge über erhebliche Reserven oberhalb dieser beobachteten Spitzen, ergänzt das Unternehmen.

Architektur auf Basis von VAST Data

CoreWeave Distributed File Storage nutzt die Speicherarchitektur von VAST Data, ein disaggregiertes System mit zwei Ebenen. CNodes (Controller Nodes) übernehmen Datenverwaltung, I/O-Scheduling und Speicheroperationen. DNodes (Data Nodes) stellen die physische Speicherkapazität bereit und sorgen für die Datenpersistenz. Beide Ebenen sind über eine NVMe-Fabric verbunden.

Der für die Benchmarks verwendete Cluster hat eine 24x16-Konfiguration, also 24 CNodes und 16 DNodes. Nach Angaben von CoreWeave lässt sich mit diesem Design die Leistung unabhängig durch zusätzliche CNodes und die Kapazität durch zusätzliche DNodes skalieren.

Das Unternehmen verweist zudem auf Daten zur GPU-Auslastung aus seiner Monitoring-Infrastruktur. Demnach liegt die Kernauslastung dauerhaft bei 100 Prozent, mit nur geringen Einbrüchen beim initialen Laden der Daten und bei Checkpoint-Operationen. CoreWeave sieht darin einen Beleg dafür, dass die GPUs nicht auf Daten warten müssen.

So liefen die Tests ab

CoreWeave setzte Flexible I/O (fio) ein, das das Unternehmen als branchenüblichen Benchmarking-Standard für Speichersysteme beschreibt. Die Tests liefen in der Standard-Umgebung von CoreWeave mit Ubuntu 22.04 und wurden über Slurm in der hybriden Slurm/Kubernetes-Infrastruktur orchestriert.

• Lesetests: simulieren gemischte sequenzielle und zufällige I/O-Zugriffe bei Blockgrößen von 32M bis 1k. Die berichteten Ergebnisse sind der Durchschnitt aus sequenzieller und zufälliger Leistung.
• Schreibtests: konzentrieren sich auf sequenzielle Schreibvorgänge, um Checkpoint-Operationen nachzubilden, ebenfalls bei Blockgrößen von 32M bis 1k.

Die Benchmarks nutzten CPU-gesteuerte I/O statt GPU-Direct-Speicherzugriff. Sie liefen auf GPU-Rechenknoten mit NVIDIA H200 und jeweils acht GPUs, damit die Konfiguration mit Produktionsumgebungen übereinstimmt. CoreWeave zufolge stehen vollständige Testkonfigurationen und Ausführungsskripte in einem öffentlichen Repository bereit, damit andere die Ergebnisse reproduzieren können.

Was das für KI-Teams bedeutet

CoreWeave warnt, dass sich die Speicherleistung verschiedener Plattformen selten, wenn überhaupt, eins zu eins vergleichen lasse, da Zugriffsmuster, Datensatzgröße und zugrunde liegende Infrastruktur eine Rolle spielten. Ziel sei es, Kunden eigene Benchmarks zu ermöglichen, damit sie die Speicherleistung bewerten und Optimierungspotenziale finden können.

Das Unternehmen argumentiert, dass Speicher, der mit den GPUs Schritt hält, die Trainingseffizienz verbessern und Kosten durch ungenutzte GPU-Zeit senken kann. Der hier zugrunde liegende Quelltext bricht vor den detaillierten Ergebnistabellen der Benchmarks ab, weshalb Zahlen jenseits der Kernaussage von einem GiB/s pro GPU in diesem Bericht nicht behandelt werden.