L'analyse Roofline révèle pourquoi ZeRO-3 échoue pour DeepSeek-V3 sur Hopper

Les ingénieurs en infrastructure analysant la configuration d'entraînement de DeepSeek-V3 sur des clusters H800 ont utilisé l'analyse Roofline pour déterminer les stratégies de parallélisme optimales. Publiée en octobre 2026, cette analyse technique approfondie démontre que le Fully Sharded Data Parallelism (FSDP), également connu sous le nom de ZeRO-3, crée un sévère goulot d'étranglement de communication lors de la mise à l'échelle de cette architecture de modèle spécifique.

L'analyse conclut que le parallélisme de pipeline est nécessaire pour maintenir le système limité par la puissance de calcul plutôt que par la communication. En comparant les limites théoriques du matériel aux performances réelles mesurées, les auteurs proposent une méthode permettant de prédire l'efficacité de l'entraînement sans avoir à construire et à tester plusieurs systèmes à pleine échelle.

Ce qui s'est passé

Dans la deuxième partie d'une série consacrée à l'entraînement de DeepSeek-V3, les auteurs ont examiné comment les choix de parallélisme, le checkpointing des activations et l'arithmétique basse précision affectent les besoins en mémoire. Ils ont identifié une configuration permettant au modèle de tenir sur un cluster H800 de 2048 nœuds. Les auteurs notent que ce résultat n'est pas fortuit ; fixer l'architecture du modèle et cibler le matériel spécifique utilisé par DeepSeek conduit naturellement à la configuration choisie par l'équipe originale.

Le défi central abordé est la sélection d'une stratégie de parallélisme qui maximise les opérations flottantes utiles par seconde (FLOPs/s) sans le coût prohibitif lié à l'implémentation et au benchmarking de multiples systèmes sur un cluster de taille complète. L'implémentation du parallélisme de pipeline est considérablement plus complexe que celle de FSDP, les ingénieurs ont donc besoin d'un moyen fiable de trancher entre les deux avant d'écrire du code. Les auteurs soutiennent que même si l'on construisait les deux systèmes, les erreurs de benchmarking pourraient invalider la comparaison.

Pour résoudre ce problème, ils ont appliqué l'analyse Roofline, une technique classique de modélisation des performances. Cette méthode considère le nombre total de FLOPs requis comme fixe et identifie si le système est limité par la vitesse de calcul ou par la bande passante de communication distribuée. L'analyse révèle que FSDP est un mauvais choix pour DeepSeek-V3 car il devient limité par la bande passante InfiniBand, tandis que d'autres stratégies permettent de maintenir les GPU occupés par le calcul.

Comment cela fonctionne

L'analyse Roofline repose sur le concept de performance « speed of light » (SOL), qui représente la limite supérieure stricte de ce que le matériel peut atteindre. En physique, rien ne dépasse la vitesse de la lumière ; en informatique, aucun logiciel ne peut dépasser le pic théorique du silicium sous-jacent. Cependant, utiliser les pics spécifiés dans les documents marketing est souvent trompeur. Les chiffres TFLOP/s annoncés par NVIDIA supposent des conditions idéales, telles que des tenseurs nuls et une planification parfaite des instructions, ce qui se produit rarement dans les multiplications matricielles réelles.

Les performances réelles divergent des fiches techniques en raison du chargement en mémoire, de la latence de la hiérarchie de cache et des limites de puissance. Par exemple, l'exécution de données non nulles peut déclencher des plafonds de puissance qui réduisent les fréquences d'horloge, signifiant que les performances dépendent des valeurs des données d'entrée. Pour remédier à cela, les auteurs utilisent des FLOPs atteignables mesurés via des microbenchmarks issus du Smol Training Playbook de HuggingFace. Pour la précision BF16, le H800 atteint 758 TFLOP/s, soit 76,6 % de son pic théorique de 989 TFLOP/s. Pour FP8, il atteint 1,46 PFLOP/s, soit 73,6 % du pic de 1,98 PFLOP/s.

La bande passante réseau est traitée de manière similaire. Bien que les spécifications InfiniBand revendiquent 50 GB/s, ce qui est largement atteignable, les performances NVLink sur les H800 sont inférieures à celles des H100. DeepSeek a rapporté n'avoir atteint que 160 GB/s de bande passante unidirectionnelle sur NVLink H800, contre les 200 GB/s spécifiés. L'analyse utilise ces valeurs mesurées pour calculer le temps consacré à la communication par rapport au calcul.

Dans l'entraînement distribué, le goulot d'étranglement passe de la mémoire à large bande passante (HBM) à la bande passante inter-nœuds. Le nombre total de FLOPs requis pour une étape d'entraînement reste constant quelle que soit la stratégie de parallélisme, tout comme découper une pizza n'en change pas la taille totale. Cependant, la surcharge de communication varie drastiquement. Si le temps de communication dépasse le temps de calcul, le système est limité par la communication, et les GPU restent inactifs en attendant les données. L'objectif est de garantir que le calcul prenne plus de temps que la communication, permettant à l'entraîneur de superposer ces opérations et de masquer la latence.

Détails clés

• Cible matérielle : L'analyse se concentre sur un cluster de 2048 nœuds équipé de GPU NVIDIA H800.
• Puissance de calcul atteignable : La performance BF16 mesurée est de 758 TFLOP/s (76,6 % du pic), et celle en FP8 est de 1,46 PFLOP/s (73,6 % du pic).
• Contraintes réseau : La bande passante InfiniBand est estimée à 50 GB/s par GPU, tandis que NVLink est plafonné à 160 GB/s selon les rapports de DeepSeek.
• Verdict sur le parallélisme : FSDP (ZeRO-3) est rejeté car il devient limité par la bande passante InfiniBand pour cette taille de modèle.
• Méthodologie : L'approche compare les temps « speed of light » calculés pour les FLOPs et les transferts d'octets afin de déterminer si une étape est limitée par le calcul ou par la communication.
• Simplification : La Multi-Token Prediction (MTP) est omise de cette analyse spécifique pour maintenir la clarté.

Pourquoi c'est important

Pour les équipes d'infrastructure d'apprentissage automatique, cette analyse fournit un cadre rigoureux pour prendre des décisions architecturales critiques sans investissement initial massif. Construire et tester plusieurs stratégies de parallélisme sur des milliers de GPU est prohibitivement coûteux et long. L'analyse Roofline offre une alternative basée sur des feuilles de calcul capable de prédire les goulots d'étranglement avec une précision raisonnable. Elle empêche les équipes de poursuivre des voies d'implémentation, telles que des configurations complexes de parallélisme de pipeline, seulement pour découvrir plus tard qu'une approche plus simple comme FSDP aurait échoué en raison des limites réseau.

De plus, la distinction entre les spécifications marketing et les performances atteignables est cruciale pour une planification précise de la capacité. Se fier aux pics théoriques peut conduire à une surestimation significative du débit d'entraînement. En utilisant des microbenchmarks mesurés, les ingénieurs peuvent créer des calendriers réalistes et des attentes budgétaires. Cela est particulièrement important à mesure que les modèles deviennent plus grands et que la précision diminue, ce qui accélère le calcul mais ne réduit pas le volume de communication, pouvant ainsi exacerber les goulots d'étranglement de bande passante.

Ce que vous pouvez faire

• Testez les performances GEMM de votre propre matériel en utilisant des bibliothèques comme cuBLAS pour déterminer les FLOP/s atteignables plutôt que de vous fier aux fiches techniques.
• Mesurez la bande passante réelle NVLink et InfiniBand dans votre environnement de cluster, car la topologie réelle et les plafonds de puissance peuvent réduire le débit.
• Utilisez l'analyse Roofline pour comparer les stratégies de parallélisme avant l'implémentation, en vous concentrant sur le fait que le temps de communication dépasse ou non le temps de calcul.
• Tenez compte des limites de puissance dans vos modèles, en reconnaissant que les entrées de données non nulles peuvent ralentir les fréquences d'horloge des GPU pendant l'entraînement.
• Priorisez les configurations limitées par le calcul lorsque possible, en veillant à ce que la surcharge de communication puisse être superposée au calcul.
• Réévaluez les hypothèses lors du changement de niveaux de précision, car une précision inférieure augmente la vitesse de calcul mais peut déplacer le goulot d'étranglement vers la bande passante réseau.