NVIDIA démontre le déterminisme au bit près dans Megatron Core pour le pré-entraînement sur des milliers de GPU

Entraîner un modèle de milliers de milliards de paramètres sur des milliers de GPU coûte des millions de dollars et prend des semaines. Lorsqu'un pic de loss ou un NaN apparaît en plein milieu d'un run, il est généralement impossible de le reproduire : l'ordre des opérations change d'une exécution à l'autre et l'erreur ne se manifeste plus. NVIDIA a publié sur son Developer Blog un article expliquant comment obtenir un déterminisme au bit près lors du pré-entraînement dans Megatron Core. Deux runs avec les mêmes données et la même configuration doivent produire des résultats identiques jusqu'au dernier bit.

Pourquoi le déterminisme est si rare en pré-entraînement

La racine du problème se trouve dans l'arithmétique à virgule flottante : l'addition n'y est pas associative. Si l'on additionne les mêmes nombres dans un ordre différent, le résultat change légèrement. Sur un seul GPU, l'écart passe presque inaperçu. Dans un cluster, l'ordre dépend d'une multitude de facteurs : opérations atomiques dans les kernels, choix de l'algorithme de réduction dans les communications collectives, ordonnancement des threads, répartition du travail entre les appareils.

La source énumère les facteurs qui compliquent la tâche :

• plusieurs dimensions de parallélisme à la fois (données, tenseurs, pipeline et autres), chacune avec ses propres réductions et échanges ;
• des calculs en basse précision, où les erreurs d'arrondi sont plus importantes et dépendent davantage de l'ordre des opérations ;
• des checkpoints distribués, qu'il faut sauvegarder et charger de façon à ce que la reprise de l'entraînement ne modifie pas la trajectoire ;
• l'échelle : des milliers de milliards de paramètres et des milliers de GPU, où la probabilité d'une panne rare au cours d'un run approche 1.

Les techniques précises par lesquelles Megatron Core garantit l'ordre des opérations, ainsi que le coût du déterminisme en vitesse, ne figurent pas dans l'extrait disponible. Ces données sont à chercher dans la version complète de l'article.

Ce qu'apporte la reproductibilité au bit près

L'annonce met en avant trois bénéfices pratiques : le débogage, la validation et la reprise reproductible de l'entraînement.

Le premier concerne la recherche des causes d'une panne. Si le run est déterministe, on peut le relancer depuis le dernier checkpoint précédant l'anomalie et retrouver la même anomalie. Une erreur « fantôme » devient alors un bug ordinaire, sur lequel on peut poser des vérifications et procéder par bissection sur les couches ou les étapes.

Le deuxième concerne la validation des correctifs. Avec un entraînement non déterministe, deux runs divergent toujours, et l'on ne peut savoir si un correctif a influencé le résultat que par des méthodes statistiques. Avec la reproductibilité au bit près, tout écart par rapport à la référence signifie que la modification a eu un effet. L'absence d'écart prouve qu'un refactoring ou une optimisation n'a pas modifié le comportement numérique.

Le troisième concerne les redémarrages. Sur de grands clusters, les pannes matérielles surviennent régulièrement. Si, après le chargement d'un checkpoint, l'entraînement suit exactement la même trajectoire que sans interruption, les ingénieurs peuvent être sûrs que le redémarrage n'a introduit aucune dérive cachée.

Le prix à payer et les cas d'usage

Le déterminisme s'achète généralement au prix de la performance : les kernels rapides mais non déterministes et les réductions atomiques sont souvent remplacés par des versions plus lentes, mais prévisibles. La question clé est donc de savoir de combien le débit chute sur des configurations réelles. L'extrait fourni n'y répond pas, et sans mesures il est trop tôt pour évaluer le gain.

La logique d'usage reste toutefois claire. Il n'est pas nécessaire de maintenir en permanence le mode déterministe dans les runs les plus coûteux. Il est en revanche utile dans plusieurs scénarios :

• reproduire et analyser des pannes, lorsqu'une répétition exacte est nécessaire ;
• valider de nouveaux kernels, un changement de précision (par exemple le passage à une précision plus basse) ou une modification du schéma de parallélisme ;
• effectuer des tests de régression du code d'entraînement : un run de référence sur un petit nombre d'étapes, auquel chaque build est comparé bit à bit.

Conclusion pratique pour les équipes

Les équipes qui entraînent leurs propres modèles sur Megatron Core ont intérêt à mettre en place un court run de contrôle en mode déterministe et à l'intégrer à leur CI. Toute modification du code, des pilotes ou de la configuration du parallélisme est d'abord comparée à la référence, à partir des hachages des poids après un nombre fixe d'étapes. Un écart montre immédiatement que la modification a touché le comportement numérique.

Avant le déploiement, il faut mesurer les surcoûts sur son propre cluster et avec sa propre précision. Il faut aussi vérifier que le redémarrage depuis un checkpoint donne bien une trajectoire identique sur votre topologie. Il est raisonnable d'activer le déterminisme complet de façon ciblée : pour le débogage, la validation et l'audit des runs. L'entraînement principal peut alors tourner en mode rapide, si les mesures révèlent une perte de vitesse sensible.