Miles Blackwell RL sostituisce l’uniformità BF16 con MXFP8 e NVFP4 nativi

Il supporto Miles Blackwell ora include due ricette native di apprendimento per rinforzo a bassa precisione, testate in sei configurazioni su otto GPU NVIDIA B200. Una utilizza MXFP8 durante rollout e addestramento. L’altra applica NVFP4 per token ai pesi mixture-of-experts, mantenendo una precisione più elevata altrove.

Il risultato mette in discussione un’assunzione comune sull’apprendimento per rinforzo, o RL. Una precisione inferiore non richiede necessariamente di accettare una curva di apprendimento visibilmente più debole. Nell’ablation di Miles su Qwen3-30B-A3B, tutte e cinque le configurazioni a bassa precisione hanno seguito da vicino le ricompense grezze della baseline BF16.

Questa conclusione comporta un’importante precisazione. L’esperimento era un’ablation controllata della ricetta, non un benchmark di addestramento completamente ottimizzato né una garanzia generale di accuratezza. Miles ha inoltre mantenuto BF16 nei layer sensibili, conservato una copia aggiuntiva dei pesi in BF16 e osservato occasionali picchi nei gradienti NVFP4.

La vera sfida non è quindi semplicemente tra quattro e sedici bit. È tra un contratto di precisione coerente e selettivo e una pipeline BF16 uniforme. Miles sostiene che i formati nativi di Blackwell diventano utili quando addestramento, campionamento, conversione e aggiornamenti live dei pesi quantizzano gli stessi tensori nello stesso modo.

Il supporto Miles Blackwell ora copre l’intero ciclo RL

Miles ha portato MXFP8 e NVFP4 oltre i kernel isolati, collegandoli lungo l’intero percorso dell’apprendimento per rinforzo.

Il team Miles ha pubblicato le ricette il 29 luglio 2026. I suoi risultati a bassa precisione coprono conversione dei checkpoint, addestramento Megatron, rollout SGLang ed esportazione live dei pesi. L’implementazione dipende anche da componenti forniti da TransformerEngine, FlashInfer, cuDNN frontend e progetti correlati.

La prima ricetta usa MXFP8 lungo l’intero percorso computazionale principale. MXFP8 è un formato microscaling a otto bit, in cui ogni blocco di 32 valori E4M3 condivide una scala E8M0. Rollout, propagazione in avanti, moltiplicazioni di matrici dei gradienti dei pesi e moltiplicazioni dei gradienti dei dati possono tutti utilizzarlo.

Questa ampia copertura è importante perché un sistema RL contiene due policy strettamente collegate. La policy di addestramento calcola gli aggiornamenti, mentre la policy di rollout genera le risposte usate per calcolare le ricompense. Se quantizzano i pesi in modo diverso, non rappresentano più esattamente lo stesso modello.

Miles supportava in precedenza un design FP8 in stile DeepSeek-V3 basato su blocchi di scaling più grandi. Questo approccio resta rilevante, soprattutto sull’hardware Hopper. Tuttavia, applica lo scaling via software attorno al percorso Tensor Core anziché usare l’hardware microscaling nativo di Blackwell.

La seconda ricetta adotta un approccio più selettivo. Applica NVFP4 ai pesi e alle attivazioni degli esperti instradati nei layer mixture-of-experts, o MoE. NVFP4 memorizza valori E2M1 in quattro bit, con una scala E4M3 per ogni blocco di 16 valori.

Una seconda scala FP32 copre un ambito più ampio. Miles calcola questa scala separatamente per ogni token, anziché condividerne una tra un tensore o un batch. Questo dettaglio mira a evitare che la rappresentazione di un token cambi in base alla composizione del batch.

Il resto del modello NVFP4 rimane in BF16, salvo quando le regole di configurazione selezionano un altro formato. Questo design concentra il calcolo a quattro bit dove i modelli MoE memorizzano gran parte dei dati dei pesi. Evita inoltre di forzare attenzione e altri componenti sensibili nella rappresentazione più ristretta disponibile.

NVIDIA descrive lo scaling NVFP4 come un sistema a due livelli progettato per i Tensor Core Blackwell. I blocchi da 16 valori offrono un adattamento locale più fine rispetto ai formati che usano gruppi da 32 valori. La scala FP32 a livello di tensore estende l’intervallo utilizzabile.

Miles ha modificato l’ambito della scala più ampia da per tensore a per token. Questa scelta separa la sua ricetta RL da un semplice deployment per l’inferenza. Mostra inoltre perché aggiungere un tipo di dati FP4 non sia sufficiente per creare un sistema RL stabile.

Entrambe le ricette supportano modalità backward ad alta precisione e dequantizzate. Il backward ad alta precisione usa gli operandi BF16 originali per le moltiplicazioni di matrici backward. Il backward dequantizzato, invece, ricostruisce gli operandi BF16 dagli esatti valori a bassa precisione usati durante il passaggio forward.

La seconda opzione sacrifica parte del dettaglio numerico, ma preserva una maggiore coerenza con la policy forward. Nessuna modalità NVFP4 esegue le proprie moltiplicazioni di matrici backward in FP4. Miles sta quindi testando una bassa precisione selettiva, non affermando di avere un ciclo di addestramento universalmente a quattro bit.

Le curve delle ricompense spostano l’onere della prova

Il risultato più significativo non è il throughput di picco dei Tensor Core, ma l’assenza di un’evidente penalità nelle ricompense per il carico di lavoro testato.

Miles ha valutato Qwen3-30B-A3B con RL sincrono in stile GRPO sul dataset dapo-math-17k. Il sistema utilizzava otto GPU B200, divise equamente tra rollout e addestramento. Ogni prompt riceveva otto campioni di rollout, con risposte limitate a 8.192 token.

Lo studio ha confrontato una baseline BF16 con cinque configurazioni a bassa precisione. Queste includevano MXFP8 end-to-end e due modalità backward per ciascun formato a bassa precisione. Le varianti NVFP4 limitavano l’operazione a quattro bit al percorso degli esperti MoE.

Tutte e cinque le curve delle ricompense grezze a bassa precisione hanno seguito da vicino la curva BF16. Questo non dimostra equivalenza tra attività, seed o esecuzioni di addestramento più lunghe. Suggerisce però che il rollout a precisione inferiore non abbia sopraffatto il segnale di apprendimento in questo specifico esperimento.

Si tratta di una soglia significativa per l’RL. L’addestramento supervisionato può mediare i segnali di ottimizzazione su un dataset ampio e relativamente stabile. L’RL lavora spesso con ricompense più rumorose e aggiornamenti della policy più piccoli, rendendo più difficile distinguere l’errore di quantizzazione aggiuntivo dall’apprendimento reale.

Miles ha inoltre riferito che MXFP8 e NVFP4 hanno ridotto il tempo di rollout rispetto a BF16. L’articolo pubblicato presenta il confronto in forma grafica, ma non fornisce una singola percentuale adatta a un titolo di portata universale. La direzione del risultato è più chiara della sua trasferibilità.

Il miglioramento del rollout è importante perché la generazione spesso domina i carichi di lavoro dell’apprendimento per rinforzo. Una policy deve produrre risposte complete prima che possano essere calcolate ricompense e aggiornamenti. Contesti lunghi e campioni multipli rendono questa fase particolarmente costosa.

MXFP8 ha migliorato anche il tempo di addestramento rispetto a BF16 nella configurazione misurata. Il lato addestramento di NVFP4 si è mosso nella direzione opposta. Entrambe le varianti NVFP4 con override backward erano più lente di BF16 durante l’addestramento, nonostante il rollout più rapido.

Miles attribuisce questo divario alla sua integrazione attuale anziché ai Tensor Core FP4 di Blackwell. Il percorso TransformerEngine misurato esegue lo scaling FP32 per token come operazione PyTorch separata. Esistono kernel cuDNN frontend fusi, ma la loro integrazione in TransformerEngine è ancora in attesa.

Questo risultato diviso mantiene l’analisi con i piedi per terra. NVFP4 non è automaticamente più veloce semplicemente perché i suoi valori sono più piccoli. La fusione dei kernel, i layout dei dati, le operazioni di scaling e i confini del framework decidono se il throughput teorico raggiunge l’applicazione completa.

Le configurazioni a bassa precisione hanno inoltre mostrato una maggiore discrepanza tra addestramento e rollout rispetto a BF16. NVFP4 è iniziato con una misurazione KL di riferimento più alta, che confronta le distribuzioni delle policy. Tuttavia, Miles ha calcolato tale diagnostica rispetto a un modello di riferimento Megatron BF16.

La metrica contiene quindi fin dall’inizio la differenza di formato. Il suo coefficiente era impostato a zero, perciò non agiva come penalità di ottimizzazione. Miles invita a non trattare la misurazione come un segnale isolato di fallimento dell’apprendimento.

Le curve delle ricompense producono un utile ribaltamento. La discrepanza di precisione è aumentata, eppure le ricompense osservate non si sono discostate materialmente da BF16 durante l’ablation. Questa combinazione sostiene ulteriori test, lasciando però aperta la questione della stabilità a lungo termine.

Un quantizzatore condiviso è il vero meccanismo

Miles tratta l’RL a bassa precisione come un problema di coerenza distribuita, non semplicemente come una richiesta di numeri più piccoli.

Ogni parte dello stack RL può quantizzare i tensori in modo indipendente. Megatron gestisce l’addestramento, mentre SGLang e FlashInfer si occupano delle operazioni di rollout. La conversione dei checkpoint e gli aggiornamenti live dei pesi introducono altre due opportunità di divergenza tra valori o layout.

Anche piccole differenze possono accumularsi attraverso aggiornamenti ripetuti della policy. Un worker di addestramento può ottimizzare una rappresentazione quantizzata, mentre i worker di rollout campionano da un’altra. Le ricompense descrivono quindi il comportamento di una policy che l’ottimizzatore non vede mai esattamente.

Miles affronta questo problema tramite un contratto di quantizzazione bit-esatto. I test FlashInfer confrontano il suo output byte per byte con un riferimento in stile TransformerEngine. Gli input di test includono valori casuali, casi limite, tensori zero e valori massimi rappresentabili.

Il team disabilita inoltre un’opzione FlashInfer fast-math per il percorso di quantizzazione FP4 rilevante. La matematica approssimata può essere ragionevole nel serving ordinario, dove differenze minime non si ripercuotono sui pesi futuri. L’RL trasforma queste differenze in parte del ciclo di apprendimento.

MXFP8 presenta un altro problema di layout. I Tensor Core Blackwell si aspettano che i blocchi microscaling seguano la dimensione di riduzione della matrice. Le operazioni forward e backward possono usare orientamenti diversi, quindi una copia quantizzata non può sempre servire correttamente entrambi i percorsi.

La documentazione MXFP8 spiega che TransformerEngine crea copie per righe e per colonne a partire dall’input originale ad alta precisione. Questo consuma più memoria, ma evita di dequantizzare e requantizzare una copia già a bassa precisione.

Miles accetta questo costo di memoria nel suo percorso MXFP8 completo. Le sue alternative backward ad alta precisione e dequantizzate evitano di conservare la seconda copia quantizzata. La scelta diventa un equilibrio tra coerenza numerica, uso della memoria, lavoro di dequantizzazione e velocità di moltiplicazione delle matrici.

NVFP4 introduce un diverso problema di coerenza. Condividere una scala di attivazione tra più token rende il valore quantizzato di un token dipendente dai suoi vicini. Cambiamenti nella pianificazione del rollout, nella lunghezza delle sequenze o nel packing dei batch possono quindi alterare la rappresentazione della policy.

Miles calcola online una scala di attivazione FP32 per ogni token. FlashInfer fonde questo calcolo nel kernel di quantizzazione delle attivazioni di rollout. La stessa operazione produce attivazioni FP4 compattate, scale di blocco e scale dei token.

Addestramento e rollout devono inoltre usare partizioni tensor-parallel degli esperti corrispondenti. Altrimenti, ciascun sistema vede porzioni diverse del tensore quando calcola la scala per token. Formule identiche non possono produrre policy identiche da input diversi.

I layer esperti SwiGLU aggiungono un altro caso speciale. Le loro proiezioni gate e up entrano comunemente in un’unica moltiplicazione di matrici fusa, sebbene i checkpoint possano memorizzarle separatamente. Miles quantizza insieme ogni coppia gate-and-up, affinché entrambe ricevano una scala più ampia coerente.

Questi dettagli di implementazione spiegano perché il lavoro Miles Blackwell si estenda su più repository. Nessuna singola libreria controlla ogni rappresentazione tra un checkpoint salvato e un rollout generato. Il contratto di precisione deve sopravvivere a ogni passaggio di consegne.

Questo lavoro sui sistemi distingue inoltre la ricetta dalla quantizzazione post-addestramento. Un checkpoint statico per l’inferenza può essere calibrato una volta e servito ripetutamente. L’apprendimento per rinforzo modifica continuamente i pesi, quindi ogni esportazione live crea di fatto un nuovo evento di quantizzazione.

I team che valutano sistemi simili avranno bisogno di prove tracciabili di tali eventi. Una base di conoscenza ingegneristica interna può collegare configurazioni, versioni del kernel, curve di valutazione e note sugli incidenti. Questa documentazione diventa importante quando una regressione numerica emerge diversi aggiornamenti più tardi.

NVFP4 per token mette sotto pressione il default uniforme BF16

L’approccio Miles Blackwell spinge i team a giustificare l’uso di BF16 ovunque, pur continuando a considerare il BF16 selettivo uno strumento di stabilità.

BF16 resta il riferimento più semplice. Offre un intervallo numerico più ampio, meno vincoli di quantizzazione e confronti più agevoli tra addestramento e rollout. Il suo punto debole è che ogni peso degli esperti e ogni attivazione consuma più larghezza di banda di memoria di quanto richiedano i formati più stretti.

I modelli MoE rendono questo compromesso più evidente. Contengono numerosi parametri degli esperti, anche se ogni token ne attiva solo un sottoinsieme. Durante il rollout, spostare i pesi degli esperti attraverso la memoria può diventare più limitante della capacità aritmetica pura.

Miles prende quindi di mira innanzitutto il percorso degli esperti. La strategia assomiglia più a un budget finanziario che a un impegno ideologico verso l’addestramento a quattro bit. Riserva la precisione ai tensori che più probabilmente influenzano la stabilità e comprime le strutture ripetute più grandi.

L’esperimento ha mantenuto in BF16 il 15 percento finale dei layer del modello per ogni configurazione a bassa precisione. Miles afferma che questa scelta ha ridotto il disallineamento tra addestramento e inferenza e migliorato la stabilità dei gradienti. Mantenere in BF16 i layer iniziali non ha prodotto una riduzione altrettanto significativa.

Anche gli esperti condivisi sono rimasti a maggiore precisione. A differenza degli esperti instradati, elaborano ogni token. I loro errori di quantizzazione si propagherebbero quindi attraverso ogni blocco MoE, anziché solo lungo i percorsi selezionati.

Anche alcune proiezioni di attenzione latente multi-head hanno ricevuto eccezioni BF16. I loro assi di contrazione possono cambiare con la modalità di esecuzione, mentre MXFP8 usa blocchi di scaling unidimensionali. Un asse modificato può raggruppare i valori con scale diverse.

Queste eccezioni sono centrali nella ricetta, non una pulizia marginale. Un titolo che descrivesse un modello interamente FP4 rappresenterebbe in modo inaccurato il lavoro. Miles ha invece realizzato controlli granulari che preservano ogni eccezione durante conversione, addestramento, rollout e aggiornamenti live.

Questo mette sotto pressione le pipeline BF16 convenzionali in due modi. In primo luogo, l’ablazione sulle ricompense suggerisce che i percorsi di rollout più stretti meritano di essere valutati su Blackwell. In secondo luogo, il sistema di configurazione offre un’alternativa alla scelta di un unico formato per ogni layer.

Mette inoltre sotto pressione i precedenti approcci FP8 progettati intorno a Hopper. DeepSeek-V3 utilizza blocchi da 128 per 128 per i pesi e tile da 1 per 128 per le attivazioni. Miles descrive questo design come efficace, ma non può sfruttare l’hardware di microscaling di Blackwell nello stesso modo nativo.

Il confronto non rende obsoleto il metodo precedente. I cluster Hopper restano ampiamente distribuiti e l’FP8 a blocchi scalati vanta una storia operativa più lunga. I formati nativi di Blackwell creano inoltre confini di compatibilità per i team che supportano generazioni GPU miste.

La guida TransformerEngine di NVIDIA ora supporta FP8, MXFP8 e NVFP4 tramite blocchi costruttivi ottimizzati. Tuttavia, il solo supporto del framework non determina quali layer debbano usare ciascun formato. L’architettura del modello e la forma del carico di lavoro continuano a governare tale decisione.

I beneficiari più diretti sono le organizzazioni che eseguono grandi job di reinforcement learning MoE su Blackwell. Possono testare un rollout più rapido senza spostare immediatamente ogni operazione backward in bassa precisione. Questo percorso graduale riduce il costo della raccolta di evidenze.

I team più piccoli affrontano un calcolo diverso. Riprodurre la configurazione richiede otto GPU B200, diverse librerie coordinate e un’attenta parità di configurazione. Il carico ingegneristico può superare i risparmi del rollout su scala modesta.

La principale linea competitiva è quindi la coerenza selettiva contro la semplicità uniforme. Miles offre maggiore controllo e un percorso verso minore traffico di memoria. BF16 offre meno interfacce attraverso cui un disallineamento inosservato può entrare nel processo di apprendimento.

Cosa non dimostra l’ablazione Qwen3

L’esperimento pubblicato supporta una ricetta promettente, ma non dimostra un’ampia parità qualitativa né un’efficienza completa a quattro bit.

La limitazione più immediata è l’ambito. Miles ha testato un modello, un dataset orientato alla matematica, una configurazione hardware e una principale configurazione del carico di lavoro. Un monitoraggio ravvicinato delle ricompense in quel contesto non può prevedere il comportamento su coding, uso di strumenti, dialogo o attività multi-agente.

La configurazione fissa utilizzava RL sincrono e una suddivisione su quattro GPU sia per il rollout sia per l’addestramento. I sistemi asincroni possono introdurre un maggiore ritardo della policy tra generazione dei dati e ottimizzazione. Tale ritardo potrebbe interagire diversamente con il disallineamento di quantizzazione.

Il grafico delle ricompense pubblicato copre inoltre un’ablazione della ricetta, anziché un’esecuzione di addestramento completamente ottimizzata. Miles lo descrive esplicitamente in questi termini. I lettori non dovrebbero interpretare il grafico come una vittoria di benchmark contro sistemi BF16 ottimizzati.

La ricompensa grezza può nascondere cambiamenti comportamentali. Due policy possono raggiungere punteggi simili usando però schemi di ragionamento, lunghezze di risposta o modalità di fallimento differenti. Una validazione più solida includerebbe valutazioni held-out, più seed casuali e analisi degli errori specifiche per attività.

I picchi occasionali dei gradienti di NVFP4 restano un’altra preoccupazione. La variante backward ad alta precisione ha mostrato picchi durante l’esecuzione riportata. Il backward dequantizzato ha ridotto gli esempi più ampi, ma non li ha eliminati.

Questo è coerente con le preoccupazioni più ampie sull’addestramento a quattro bit. La ricerca sugli outlier NVFP4 ha rilevato una sensibilità persistente in specifici componenti architetturali. Tale lavoro riguarda il preaddestramento, non la ricetta RL di Miles, ma rafforza la necessità di monitoraggio a livello di layer.

Anche l’attuale quadro della memoria è incompleto. Megatron conserva ancora una copia aggiuntiva dei pesi in BF16, nonostante esegua addestramento e rollout tramite ricette a bassa precisione. Questa copia limita quanta memoria del modello il sistema recuperi effettivamente.

La raccolta di parametri a bassa precisione nativa di Blackwell è ancora in maturazione. Miles osserva che il percorso pertinente di raccolta dei parametri NVFP4 non supporta ancora il suo layout dei pesi unidimensionale 1 per 16. La rimozione della copia BF16 dipende in parte da questa infrastruttura.

Le prestazioni di addestramento NVFP4 presentano una seconda area incompleta. Il rollout è migliorato, ma l’addestramento è diventato più lento nell’implementazione testata. La prevista integrazione fused di TransformerEngine deve colmare questo divario prima che NVFP4 possa rivendicare un vantaggio end-to-end più chiaro.

Anche il movimento live dei pesi resta complicato. I backend di serving spesso effettuano padding, shuffle o swizzle dei pesi in layout ottimizzati per kernel specifici. I sistemi di addestramento mantengono in genere una diversa rappresentazione canonica dei tensori.

Queste trasformazioni possono ostacolare aggiornamenti a bassa latenza o l’accesso remoto diretto alla memoria. Ogni layout specifico del backend aggiunge un ulteriore passaggio che deve restare verificabile. Un kernel veloce offre valore limitato se ogni aggiornamento della policy innesca un costoso repacking.

La specificità hardware crea un rischio commerciale. MXFP8 e NVFP4 ricevono accelerazione nativa su Blackwell, ma molte organizzazioni utilizzano ancora hardware Hopper. L’adozione delle nuove ricette può dividere il supporto dell’infrastruttura tra più percorsi di precisione.

Nelle evidenze pubblicate manca inoltre una replica indipendente. I risultati provengono dal team che ha progettato e implementato le ricette. Ciò è appropriato per un rapporto ingegneristico iniziale, ma riproduzioni di terze parti rafforzerebbero la fiducia.

Nessuno di questi limiti cancella il risultato osservato. Definiscono cosa significa il risultato. Miles ha mostrato che una bassa precisione attentamente controllata può seguire le ricompense BF16 in una configurazione impegnativa, riducendo al contempo il tempo di rollout.

Lo standard successivo è più difficile. Le ricette devono restare stabili su esecuzioni più lunghe, attività diverse, aggiornamenti asincroni, modelli più grandi e differenti layout di parallelismo. Devono inoltre preservare i propri guadagni dopo che tutto l’overhead del framework entra nella misurazione.

Tre segnali decideranno se la ricetta si diffonderà

I prossimi tre segnali sono l’addestramento NVFP4 fused, la replica indipendente delle ricompense e la rimozione della copia aggiuntiva dei pesi BF16.

Primo, osservate la prevista integrazione TransformerEngine per lo scaling NVFP4 fused per token. Miles utilizza già lo scaling fused nel percorso di rollout di FlashInfer, ma il suo percorso di addestramento misurato esegue un’operazione separata. L’integrazione dovrebbe rivelare se NVFP4 può migliorare il tempo di addestramento oltre a quello di rollout.

Un risultato end-to-end più rapido rafforzerebbe il caso a favore del formato. Un rallentamento continuo nell’addestramento ne limiterebbe l’attrattiva ai carichi di lavoro dominati dal rollout. Entrambi gli esiti chiarirebbero dove il calcolo a quattro bit produce valore pratico.

Secondo, cercate riproduzioni indipendenti su modelli e attività differenti. I test di maggior valore includerebbero coding, ragionamento a lungo contesto, uso di strumenti e RL asincrono. Più seed aiuterebbero a separare il comportamento del formato dalla normale varianza delle ricompense.

Curve delle ricompense simili su questi carichi di lavoro sosterrebbero la tesi di coerenza di Miles. Divergenze in layer o attività specifici identificherebbero invece dove le eccezioni BF16 devono espandersi. Entrambi i risultati sarebbero più utili di un’unica regola di precisione universale.

Terzo, osservate se Megatron può rimuovere la copia aggiuntiva dei pesi BF16 supportando al contempo il layout dei pesi della ricetta. Tale cambiamento renderebbe visibile il vantaggio di memoria attualmente nascosto dai requisiti di compatibilità. Verificherebbe inoltre se la policy a bassa precisione possa diventare la principale rappresentazione memorizzata del sistema.

Il lavoro Miles Blackwell ha superato un’importante soglia ingegneristica. MXFP8 e NVFP4 per token partecipano ora a un unico ciclo RL connesso, anziché apparire solo in test isolati di inferenza o addestramento.

La domanda più precisa non è più se Blackwell possa eseguire operazioni a quattro e otto bit. È se i team possano preservare una sola policy in ogni sistema che tocca tali valori. Seguite le integrazioni, le riproduzioni e i cambiamenti nella memoria prima di trattare le curve Qwen3 come un risultato generale.