A bitpontos determinizmus azt jelenti, hogy ha egy előképzési futtatást függetlenül újraindítanak vagy ellenőrzőpontból folytatnak ugyanazon adatrendezéssel, architektúrával, recepttel, párhuzamossági beállításokkal, szoftverrel, futtatási paraméterekkel és hardverrel, akkor minden lépésben ugyanazok a numerikus értékek keletkeznek — bit-szinten azonos paraméterekkel, gradiensekkel és állapotokkal. Az NVIDIA Megatron Core két konkrét garanciát céloz meg:
- Független reprodukálhatóság: két, ugyanazon kezdeti állapotból indított futás minden lépésben bitpontos egyezést tart.
- Bitpontos checkpoint-folytatás: egy vagy több ellenőrzőpontot mentő és visszaállító futás bitpontos egyezést tart egy megszakítás nélküli futással.
Nagy, több trillió paraméteres modellek és ezres nagyságrendű GPU-k esetén a bitpontos determinizmus kritikus előnyöket ad:
- Hibák visszajátszhatók: egy vesztéscsúcsot pontosan ugyanannál a lépésnél reprodukálva komponensenként izolálható a hiba oka.
- Ellenőrzőpont-folytonosság megőrzése: megszakított tréning folytatható anélkül, hogy a numerikus pálya megváltozna.
- Váratlan különbségek detektálása: eltérések feltárhatják az ellenőrzőpont-sérülést, szoftver- vagy hardverhibát.
- Változtatások összehasonlítása: megkülönböztethetővé válik egy szándékos változtatás numerikus hatása a futások közti zajtól.
Hogyan lehet ellenőrizni a bitpontos determinizmust?
A konzolra nyomtatott veszteségértékek nem elég érzékenyek: két futás azonos kerekített veszteséget mutathat, miközben Alsóbb helyi bitekben különböznek a gradiensek vagy a paraméterek. Erre a célra erősebb ellenőrzés szükséges: lépésenként ujjlenyomatokat kell készíteni kiválasztott numerikus metrikákról (például teljes-precision training loss, language-modeling loss, load-balancing loss, multi-token prediction loss, gradient norm). Két azonos konfigurációban indított futást lépésről lépésre össze kell hasonlítani; az első különböző lépés segít lokalizálni a problémát.
A checkpoint-folytatás validálásához egy megszakítás nélküli referenciát kell összevetni checkpointból folytatott futásokkal: minden visszaállítás után bitpontos egyezést kell ellenőrizni a paraméterek, az optimizer állapota, RNG-állapot, az adatpozíció és a következő kimenetek tekintetében. A Nemotron trillió-paraméteres modell mentési útvonala egy teljes-precision "forrást" tart meg, és ugyanazon konverziós úton rekonstruálja a futás-képviselt formát, ahogyan a tréning alatt alkalmazzák.
A GPU-n tartott tenzorok ujjlenyomatához a javasolt eszköz a torch.hash_tensor; naplózni kell a tenzor alakját, dtype-ját és elemszámát együtt a digesztummal. MVFP8 vagy NVFP4 formátumoknál mind a kódolt értékeket, mind a skálapuffereket hitelesíteni kell. Rutin szerint byte-szintű összehasonlítással kell megerősíteni a bitpontos egyenlőséget, mivel az XOR-szerű ujjlenyomatok permutációkat nem érzékelnek — konfigurációtól függően soronkénti vagy chunk-ujjlenyomatokra lehet szükség, például MoE dispatch vagy routing map esetén.
Ha megszakad a determinizmus: hiba lokalizálása és javítása
Nagy skálán a nondeterminizmus lehet intermittáló vagy topológiafüggő, és a látható veszteségdivergencia gyakran sokkal később jelenik meg, mint az első eltérő bit. A Megatron-LM PR #7262 által javasolt munkafolyamat rendezetten, rank-enkénti tenzor-ujjlenyomatok naplózásával dolgozik offline összehasonlítás céljából. Az alapellenőrzések: egyező seedek, adatrend, batch méret, párhuzamosság, konténer és szoftver-stakk.
A nyomkövetés (tracing) fokozatosan finomítandó:
- End-to-end metrikák: észlelik a hibát és azonosítják az első iterációt, ahol a sorosított metrika eltér.
- Széles szemantikus nyomkövetés: gyűjtők, pipeline kommunikáció, recomputation, optimizer műveletek és gradiensek redukciója segít az érintett tréning-fázis meghatározásában.
- Modul- és réteg-szintű nyomkövetés: leszűkíti a hibát egy modellkomponensre (pl. egy adott transformer réteg vagy MoE blokk).
- Operáció-szintű nyomkövetés: ATen műveletek és célzott kiterjesztések ujjlenyomatai azonosítják az első olyan operációt, amelynél azonos inputokhoz eltérő output tartozik.
- Kernel-szintű eszközök: beazonosítják a felelős kernelt, algoritmus-konfigurációt és a nondeterministic mechanizmust.
Fontos: ne csak ott nyomkövessünk, ahol a veszteség szemmel láthatóan elválik; az első eltérő bit korábban jelentkezhet. Először széles ablakban keressük az első divergent iterációt és rangokat, majd csak ezen belül kapcsoljuk be a részletes operáció- és kernel-nyomkövetést.
A trace fájlokat rank-enként írjuk ki, collectives vagy cross-rank sorrend nélkül, hogy ne takarjuk el a vizsgálandó versenyhelyzetet. Az eseményeket run-független azonosítóval igazítsuk (pl. operáció név + előfordulás száma + modul scope). Keressünk olyan eseteket, ahol az inputok ujjlenyomata egyezik, de az outputoké eltér:
hash(input_run_A) == hash(input_run_B) hash(output_run_A) != hash(output_run_B)
Minden ranknál a "first mismatch" fogalmát külön kell értelmezni: a rankok közti eseményszámozás nem hozható össze globális sorrendbe. A rankok első eltérését szerepkör szerint osztályozzuk (producer, receiver, kívül eső eredet), és ennek megfelelően bővítsük a lehatárolást.
A lehetséges álriasztások kizárásához ellenőrizzük a következőket:
- Dispatcher blind spotok: a TorchDispatchMode csak az ATen-en keresztül futó műveleteket figyeli; egyedi, natív custom kernel kibújhat alóla. Ha egy egyszerű view vagy add műveletnél tűnik fel elsőként az eltérés, vizsgáljuk meg a bemenetet előállító egyedi kernelt.
- Olvasási artefaktok: inicializálatlan tenzorok, befejezetlen aszinkron collectives vagy nonblocking másolatok olvashatók még érvényes tartalom nélkül — ezeket zárjuk ki, mielőtt a producer nondeterministicáját feltételezzük.
A javítást páros futásokkal kell validálni: az eredeti pár reprodukálja a divergenciát, a javított pár bitpontos egyezést kell hogy mutasson; továbbá meg kell határozni, hogy a javítás korrigálja-e az implementációt vagy csak megkerüli a problémát, és mérni kell az új teljesítményköltséget. Fontos megjegyezni, hogy a bitpontos validáció adott hardver- és szoftverkörnyezetre vonatkozik; GPU-generációk, hálózati konfigurációk vagy könyvtárváltozatok átlépése kívül esik ezen validálás hatókörén.
Optimálási példák és eredmények a trillió-paraméteres Nemotronon
Egy determinisztikus recept alacsony overhead nélkül nem elegendő: a determinisztikus és a nondeterminisztikus végrehajtást együtt kell co-optimalizálni. A bemutatott munka egy trillió-paraméteres Nemotron modellt használ, amely Mamba-stílusú state-space model (SSM) rétegeket és Transformer attention rétegeket kombinál. Determinisztikus tréningnek le kell fednie az SSM és attention kerneleket, alacsony-precizitású számításokat, elosztott kommunikációt és a rétegtípusok közötti átmeneteket.
Első lépés egy kontrollált baseline felállítása: hasonlítsuk össze a determinisztikus végrehajtást a leggyorsabb támogatott nondeterministic recepttel ugyanazon modell, hardver, batch, párhuzamosság, precizitás és szoftverkörnyezet mellett. Mérendők: átbocsátás (throughput) és lépésidő, csúcs memória- és GPU-kihasználtság, feltárt kommunikációs idő, és a fő kernel-csoportokban töltött idő. A determinizmusadó (determinism tax) így számolható: (deterministic step time / baseline step time – 1) × 100%.
A finomhangolási folyamat során három munkahelyzeten elvégzett optimalizálás csökkentette az overheadet kétszámjegyű kezdeti értékekről alacsony egyjegyű százalékokra. Nagyméretű mérésnél, 2,432 GPU használata mellett, a Nemotron recept körülbelül 2% állandó determinizmus-adót mért egy ~800 lépéses bitpontos demonstráció során.
Egy kernel-szintű optimalizációs példa: a grouped-GEMM epilógusban több N-tile eredetileg ugyanabba a dprob[token] címre gyűjtött, így az eredmény a beérkezési sorrendtől függött. A szerializálás helyreállította a determinizmust, de csökkentette a párhuzamosságot. A megoldás: minden N-tile kapjon privát kimeneti slotot, a kernelon belüli párhuzamosság megmarad, majd a slotokat rögzített sorrendben kombinálják a szerző tők befejezését követően — így megőrizhető a determinizmus nagyobb párhuzam mellett.
Skálán történő validálás: egy kis GPU-készleten mért alacsony determinizmus-adó nem garantálja azonos eredményt produkciós skálán, mivel a kommunikáció, szinkronizáció, pipeline-buborékok és MoE routing befolyásolhatják a relatív overheadet. Egy hipotetikus példa: egy 10,000 GPU-s futás nondeterministic baseline-ja 100 nap; ha az overhead 15%-ról 5%-ra csökken, az 10 nap megtakarítást jelent — azaz 100,000 GPU-nap megtakarítást.
Megőrzés és regresszióvédelem
Új kernek, fúziók, precizitási formátumok vagy párhuzamossági konfigurációk mindig behozhatnak nondeterministic viselkedést. A Megatron-LM védekezései:
- Recept-validáció: a --deterministic-mode kanonikus környezeti beállításokat alkalmaz, engedélyezi a PyTorch determinisztikus algoritmusokat és elutasítja azokat a funkciókat, amelyekhez nincs determinisztikus út.
- Kernel-tesztelés: kernel tesztek ismételik az operációkat azonos bemenetekkel és RNG-állapottal, majd byte-szinten hasonlítják össze az outputokat és gradienseket.
- Modul-validáció: modul-szintű tesztek ismétlik a modelleket és transzformer blokkokat visszaállított RNG-állapottal különböző párhuzamossági konfigurációk mellett, beleértve FP8 és FP4 eseteket. Független end-to-end futtatások ellenőrzik, hogy a teljes-precision metrikák bitpontos egyezést mutatnak.
A cikkben felsorolt ismert források és diagnosztikai módszerek (táblázatok és katalógusok) segítenek az általános vizsgálatok gyors irányításában. Gyakori nondeterministic tünetek közé tartozik a futások már az első lépéstől való eltérése (runtime autotuning miatt választott különböző kernel-konfigurációk), MoE-specifikus divergenciák fuzionált auxiliary loss mellett (nem rögzített redukciós sorrend), vagy a checkpoint visszaállítás után fokozatosan megjelenő eltérések (hiányos RNG-állapot visszaállítás).
Hogyan kezdjünk hozzá
A bitpontos determinizmus jelentősen megkönnyíti a nagy skálájú előképzések hibakeresését és folytathatóságát. A Nemotron esettanulmány bemutatja, hogy kernel- és recept-optimalizációkkal az overhead alacsonyra szorítható. Kezdésként érdemes átnézni a Megatron Core User Guide-ot egy támogatott receptért, majd független és checkpoint-folytatott futásokat összehasonlítani a reprodukálhatóság és overhead validálásához.
