Entropi-bonusen frøs 4-bits GLM-5.2 under RL-trening

Oppgaven var lett å formulere. Ta GLM-5.2, en mixture-of-experts-modell på 744 milliarder parametere med rundt 40 milliarder aktive, kvantisert til 4-bits NVFP4, heng på en LoRA-adapter i bf16 med rang 64, og tren den til den spiller seg gjennom første brett i Super Mario Bros. Patronus AI kjørte det på to noder med åtte B200-kort hver, én til trening i Megatron og én til rollouts i SGLang.

Regnestykket sviktet først. Transformer Engine lagrer to NVFP4-kvantiseringer av hver vekt, én per kontraksjonsakse, så «4-bits»-basen la beslag på 110 GB per GPU. Å beholde bare fremoverlayouten og dekvantisere til bf16 for bakoverpasset tok det ned til 56 GB, og dermed inn på én node.

Verre var kollapsen i belønning. Den klatret forbi 1000 og falt så rett ned på én konstant verdi, rollout etter rollout, uten svingninger. At tallet var eksakt til fire signifikante siffer, var hele ledetråden: når alle 16 utvalgene i en GRPO-gruppe er identiske, blir hver enkelt fordel belønningen minus gruppegjennomsnittet, altså null, og policy-gradienten forsvinner. Igjen står bare de svake regularisererne, som flyttet modellen mellom nesten identiske deterministiske moduser.

Kuren gikk motsatt vei av intuisjonen. Entropi-bonusen på 0,1 er nettopp ment å hindre slik kollaps, men så snart gruppene var degenererte, ble den den dominerende gradienten og dyttet policyen dypere inn i det frosne moduset. Patronus fjernet entropi-leddet og lot DAPOs dynamiske sampling luke ut gruppene uten varians. På femlags-testoppsettet holdt belønningen seg oppe gjennom hele rollout-budsjettet.

Presisjonen var ikke problemet. Kjører du samme oppskrift på en bf16-base og en NVFP4-base, følger belønningskurvene hverandre: 4 bit koster i praksis ingenting for verken finjustering eller forsterkningslæring i denne størrelsen. Begrensningen ligger i skala og i trening mot én enkelt prompt, ikke i kvantiseringen. Endringene ligger i to offentlige forker, miles-nvfp4 og megatron-lm-nvfp4.