Roofline-Analyse zeigt, warum ZeRO-3 für DeepSeek-V3 auf Hopper scheitert

Infrastruktur-Ingenieure, die die Trainingskonfiguration für DeepSeek-V3 auf H800-Clustern analysierten, nutzten die Roofline-Analyse, um optimale Parallelisierungsstrategien zu bestimmen. Die im Oktober 2026 veröffentlichte technische Tiefenanalyse belegt, dass Fully Sharded Data Parallelism (FSDP), auch bekannt als ZeRO-3, beim Skalieren dieser spezifischen Modellarchitektur einen schweren Kommunikationsengpass verursacht.

Die Analyse kommt zu dem Schluss, dass Pipeline-Parallelismus erforderlich ist, um das System rechenlastig (compute-bound) statt kommunikationslastig (communication-bound) zu halten. Durch den Vergleich der theoretischen Hardware-Grenzen mit der tatsächlich gemessenen Leistung bieten die Autoren eine Methode zur Vorhersage der Trainingseffizienz, ohne mehrere vollständige Systeme bauen und benchmarken zu müssen.

Was passiert ist

Im zweiten Teil einer Serie zum Training von DeepSeek-V3 untersuchten die Autoren, wie sich Parallelisierungswahl, Aktivierung-Checkpointing und Arithmetik mit niedriger Präzision auf den Speicherbedarf auswirken. Sie identifizierten eine Konfiguration, die es ermöglicht, das Modell auf einem 2048-Knoten-H800-Cluster unterzubringen. Die Autoren weisen darauf hin, dass dieses Ergebnis kein Zufall war; die Fixierung der Modellarchitektur und die Ausrichtung auf die spezifische Hardware, die DeepSeek verwendet, führen naturgemäß zu der Konfiguration, die das ursprüngliche Team ausgewählt hat.

Die zentrale Herausforderung besteht darin, eine Parallelisierungsstrategie auszuwählen, die die nützlichen Gleitkommaoperationen pro Sekunde (FLOPs/sec) maximiert, ohne die prohibitiven Kosten für die Implementierung und das Benchmarking mehrerer Systeme auf einem Vollcluster. Die Implementierung von Pipeline-Parallelismus ist deutlich komplexer als FSDP, daher benötigen Ingenieure eine zuverlässige Methode, um vor dem Schreiben des Codes zwischen den beiden zu entscheiden. Die Autoren argumentieren, dass selbst wenn man beide Systeme bauen würde, Fehler im Benchmarking den Vergleich ungültig machen könnten.

Um dies zu lösen, wandten sie die Roofline-Analyse an, eine klassische Technik der Leistungsmodellierung. Diese Methode betrachtet die insgesamt erforderlichen FLOPs als festgelegt und ermittelt, ob das System durch die Rechengeschwindigkeit oder die Bandbreite der verteilten Kommunikation begrenzt wird. Die Analyse zeigt, dass FSDP für DeepSeek-V3 eine schlechte Wahl ist, da es durch die InfiniBand-Bandbreite begrenzt wird, während andere Strategien die GPUs mit Berechnungen beschäftigt halten können.

Wie es funktioniert

Die Roofline-Analyse basiert auf dem Konzept der "Speed of Light" (SOL)-Leistung, die die strikte Obergrenze dessen darstellt, was die Hardware erreichen kann. In der Physik überschreitet nichts die Lichtgeschwindigkeit; in der Computing-Welt kann keine Software die theoretische Spitze des zugrunde liegenden Siliziums überschreiten. Allerdings sind die in Marketing-Spezifikationen angegebenen Spitzenwerte oft irreführend. Die von NVIDIA beworbenen TFLOP/s-Werte gehen von idealen Bedingungen aus, wie etwa nullgesetzten Tensoren und perfekter Befehlsplanung, was bei realen Matrixmultiplikationen selten vorkommt.

Die reale Leistung weicht aufgrund von Ladevorgängen im Speicher, Latenzen der Cache-Hierarchie und Leistungslimits von den Datenblättern ab. Zum Beispiel kann das Verarbeiten von Nicht-Null-Daten Leistungslimits auslösen, die die Taktfrequenzen reduzieren, was bedeutet, dass die Leistung von den Eingabedatenwerten abhängt. Um dies zu berücksichtigen, verwenden die Autoren die erreichbaren FLOPs, die über Microbenchmarks aus HuggingFace’s Smol Training Playbook gemessen wurden. Bei BF16-Präzision erreicht der H800 758 TFLOP/s, was 76,6 % seiner theoretischen Spitze von 989 TFLOP/s entspricht. Für FP8 erreicht er 1,46 PFLOP/s, also 73,6 % der Spitze von 1,98 PFLOP/s.

Die Netzwerkbandbreite wird ähnlich behandelt. Während die InfiniBand-Spezifikationen 50 GB/s angeben, was weitgehend erreichbar ist, liegt die NVLink-Leistung auf H800s niedriger als auf H100s. DeepSeek berichtete, nur eine unidirektionale Bandbreite von 160 GB/s auf H800-NVLink erreicht zu haben, verglichen mit der Spezifikation von 200 GB/s. Die Analyse nutzt diese gemessenen Werte, um die Zeit zu berechnen, die für Kommunikation im Vergleich zu Berechnung aufgewendet wird.

Beim verteilten Training verschiebt sich der Engpass vom Hochbandbreiten-Speicher (HBM) zur Knotenübergreifenden Bandbreite. Die Gesamtzahl der für einen Trainingsschritt erforderlichen FLOPs bleibt unabhängig von der Parallelisierung konstant, ähnlich wie das Schneiden einer Pizza ihre Gesamtgröße nicht ändert. Der Kommunikationsaufwand variiert jedoch drastisch. Wenn die Kommunikationszeit die Berechnungszeit übersteigt, ist das System kommunikationsgebunden, und die GPUs warten untätig auf Daten. Das Ziel ist sicherzustellen, dass die Berechnung länger dauert als die Kommunikation, damit der Trainer diese Operationen überlappen und die Latenz verbergen kann.

Wichtige Details

• Hardware-Ziel: Die Analyse konzentriert sich auf einen 2048-Knoten-Cluster mit NVIDIA H800 GPUs.
• Erreichbare Rechenleistung: Die gemessene BF16-Leistung beträgt 758 TFLOP/s (76,6 % der Spitze), und FP8 liegt bei 1,46 PFLOP/s (73,6 % der Spitze).
• Netzwerkbeschränkungen: Die InfiniBand-Bandbreite wird mit 50 GB/s pro GPU angenommen, während NVLink basierend auf den Berichten von DeepSeek auf 160 GB/s begrenzt ist.
• Parallelisierungs-Urteil: FSDP (ZeRO-3) wird verworfen, da es bei dieser Modellgröße durch die InfiniBand-Bandbreite begrenzt wird.
• Methodik: Der Ansatz vergleicht berechnete "Speed of Light"-Zeiten für FLOPs und Byte-Übertragungen, um festzustellen, ob ein Schritt rechen- oder kommunikationsgebunden ist.
• Vereinfachung: Multi-Token Prediction (MTP) wurde aus dieser spezifischen Analyse ausgelassen, um die Klarheit zu wahren.

Warum es wichtig ist

Für Teams im Bereich Machine-Learning-Infrastruktur bietet diese Analyse einen rigorosen Rahmen für hochriskante architektonische Entscheidungen ohne massive Vorabinvestitionen. Das Bauen und Benchmarking mehrerer Parallelisierungsstrategien auf Tausenden von GPUs ist prohibitiv teuer und zeitaufwendig. Die Roofline-Analyse bietet eine Tabellenkalkulations-basierte Alternative, die Leistungsengpässe mit angemessener Genauigkeit vorhersagen kann. Sie verhindert, dass Teams Implementierungspfade verfolgen, wie etwa komplexe Pipeline-Parallelismus-Setups, nur um später festzustellen, dass ein einfacherer Ansatz wie FSDP aufgrund von Netzwerklimits gescheitert wäre.

Darüber hinaus ist die Unterscheidung zwischen Marketing-Spezifikationen und erreichbarer Leistung entscheidend für eine genaue Kapazitätsplanung. Das Vertrauen auf theoretische Spitzenwerte kann zu einer erheblichen Überschätzung des Training-Durchsatzes führen. Durch die Verwendung gemessener Microbenchmarks können Ingenieure realistische Zeitpläne und Budgeterwartungen erstellen. Dies ist besonders wichtig, da Modelle größer werden und die Präzision sinkt, was die Berechnung beschleunigt, aber das Kommunikationsvolumen nicht reduziert, wodurch Bandbreitenengpässe potenziell verschärft werden.

Was Sie tun können

• Benchmarken Sie die GEMM-Leistung Ihrer eigenen Hardware unter Verwendung von Bibliotheken wie cuBLAS, um die erreichbaren FLOP/s zu bestimmen, anstatt sich auf Datenblätter zu verlassen.
• Messen Sie die tatsächliche NVLink- und InfiniBand-Bandbreite in Ihrer Cluster-Umgebung, da die reale Topologie und Leistungslimits den Durchsatz reduzieren können.
• Nutzen Sie die Roofline-Analyse, um Parallelisierungsstrategien vor der Implementierung zu vergleichen, wobei der Fokus darauf liegt, ob die Kommunikationszeit die Berechnungszeit übersteigt.
• Berücksichtigen Sie Leistungslimits in Ihren Modellen und erkennen Sie, dass Eingabedaten mit Nicht-Null-Werten die GPU-Taktfrequenzen während des Trainings drosseln können.
• Priorisieren Sie nach Möglichkeit rechenlastige Konfigurationen, um sicherzustellen, dass der Kommunikationsaufwand mit der Berechnung überlappt werden kann.
• Überprüfen Sie Ihre Annahmen neu, wenn Sie die Präzisionsstufen ändern, da niedrigere Präzision die Rechengeschwindigkeit erhöht, aber den Engpass möglicherweise zur Netzwerkbandbreite verschiebt.