NVIDIA senkt Kosten für bitweise deterministisches Pretraining in Megatron Core auf rund 2 Prozent

Was bitweiser Determinismus in Megatron Core bedeutet

Laut NVIDIA verlangt bitweiser Determinismus, dass unabhängige Läufe und von Checkpoints fortgesetzte Läufe derselben numerischen Trajektorie folgen, wenn Datenreihenfolge, Architektur, Rezept, Parallelisierung, Software, Laufzeiteinstellungen und Hardware feststehen. Megatron Core zielt auf zwei Garantien ab.

• Unabhängige Reproduzierbarkeit: Zwei Läufe, die vom selben Anfangszustand starten, müssen in jedem Trainingsschritt bitweise identisch bleiben.
• Bitweise Checkpoint-Wiederaufnahme: Ein Lauf, der einen oder mehrere Checkpoints speichert und wiederherstellt, muss mit einem ununterbrochenen Lauf identisch bleiben.

NVIDIA argumentiert, die Garantie sei vor allem bei Modellen mit Billionen von Parametern wichtig, die auf Tausenden GPUs trainiert werden. Dort erschweren mehrere Parallelisierungsdimensionen, Berechnungen mit niedriger Präzision und verteiltes Checkpointing die Reproduktion von Fehlern und die Überprüfung von Korrekturen. Da Produktions- und Hero-Trainingsläufe teuer seien, brauche man eine belastbare Erfolgsgarantie, so das Unternehmen. Zudem könne selbst eine kleine Verlangsamung bei einer Billion Parametern Tausende GPU-Tage kosten, weshalb deterministisches Training effizient bleiben müsse.

Warum Teams deterministisches Pretraining wollen

NVIDIA nennt vier Vorteile. Teams können Fehler nachstellen, etwa einen Loss-Spike im selben Schritt reproduzieren und jeweils nur eine Komponente ändern, um die Ursache einzugrenzen. Sie können die Checkpoint-Kontinuität wahren, indem sie unterbrochenes Training fortsetzen, ohne die numerische Trajektorie zu verändern. Sie können unerwartete Abweichungen erkennen und Unterschiede zwischen sonst identischen Läufen nutzen, um beschädigte Checkpoints oder Software- und Hardwareprobleme zu untersuchen. Und sie können Änderungen vergleichen, indem sie die numerische Wirkung einer beabsichtigten Änderung von der Schwankung zwischen einzelnen Läufen trennen.

Die Überprüfung erfordert mehr als den Blick auf den Loss. NVIDIA weist darauf hin, dass ausgegebene Loss-Werte nicht empfindlich genug sind: Zwei Läufe können denselben gerundeten Loss anzeigen und sich dennoch in den niederwertigen Bits ihrer Gradienten oder Parameter unterscheiden. Empfohlen wird, ausgewählte Metriken in jedem Schritt zu fingerprinten, etwa Trainings-Loss, Sprachmodellierungs-Loss, Load-Balancing-Loss, Multi-Token-Prediction-Loss (MTP) und Gradientennorm, und zwei Läufe derselben Konfiguration Schritt für Schritt zu vergleichen. Bei der Checkpoint-Wiederaufnahme sollten Parameter, Optimizer-Zustand, RNG-Zustand, Datenposition und nachfolgende Ausgaben nach jeder Wiederherstellung mit einer ununterbrochenen Referenz übereinstimmen.

Nichtdeterminismus aufspüren und beheben

Im großen Maßstab kann Nichtdeterminismus laut NVIDIA sporadisch oder topologieabhängig auftreten, und eine sichtbare Loss-Divergenz kann lange nach dem ersten abweichenden Bit erscheinen. Der in Megatron-LM PR #7262 vorgeschlagene Workflow zeichnet geordnete Tensor-Fingerprints pro Rank für den Offline-Vergleich auf.

Die Methode engt die Suche schrittweise ein, von der End-to-End-Metrik über die Trainingsphase, das Modul und die Operation bis zum Kernel. Betreten zwei Läufe einen Bereich mit bitweise identischen Eingaben und verlassen ihn mit unterschiedlichen Ausgaben, liegt der Ursprung der Divergenz in diesem Bereich. Jeder ausgewählte Rank schreibt seine Spur in eine Datei, ohne zusätzliche Collectives oder rankübergreifende Ordnung einzuführen. Das verringere laut NVIDIA das Risiko, die untersuchte Race Condition zu überdecken.

Die Fingerprints werden auf der GPU mit torch.hash_tensor berechnet. Bei MXFP8- oder NVFP4-Tensoren werden sowohl die kodierten Werte als auch ihre Skalierungspuffer gefingerprintet. Reihenfolgeempfindliche Daten wie Routing-Maps und MoE-Dispatch-Ausgaben sollten zeilen- oder chunkweise gefingerprintet werden, da XOR-Fingerprints über ganze Tensoren Permutationen nicht erkennen können. Ein übereinstimmender Fingerprint garantiert keine bitweise Gleichheit, zur Bestätigung werden daher Vergleiche auf Byte-Ebene empfohlen. Der Beitrag warnt zudem vor Fehlalarmen: Eigene Kernel können dem Tracing des PyTorch-Dispatchers entgehen, und nicht initialisierte Tensoren, unvollständige asynchrone Collectives und nicht blockierende Kopien werden möglicherweise gelesen, bevor ihr Inhalt gültig ist.

Was das für Training im großen Maßstab bedeutet

Laut NVIDIA bewahren Änderungen auf Kernel-Ebene die Parallelität und stellen zugleich deterministische Ergebnisse wieder her, etwa private Ausgabeslots für Grouped-GEMM-Writer und eine feste Reduktionsreihenfolge. Zudem sichert Megatron Core sich mit Rezeptvalidierung, Kernel-Tests und Modulvalidierung über Parallelisierungskonfigurationen hinweg gegen Regressionen ab, einschließlich FP8 und FP4.

Für Teams, die sehr große Pretraining-Jobs betreiben, lautet die Aussage: Reproduzierbarkeit muss nicht mehr mit einem großen Geschwindigkeitsverlust erkauft werden. NVIDIA empfiehlt, im Megatron Core User Guide nach einem unterstützten Rezept zu suchen und unabhängige sowie von Checkpoints fortgesetzte Läufe zu vergleichen, um die Reproduzierbarkeit zu prüfen. Die Angabe von rund 2 Prozent ist NVIDIAs eigene Messung an den Nemotron-Workloads des Unternehmens.