NVIDIA riporta +42,5% nel test GSM8K su DGX Spark

Nel post pubblicato il 27 ottobre 2026, NVIDIA ha riportato un aumento del 42,5% del throughput di decodifica di Ling-3.0-flash-fp4 su DGX Spark: da 37,81 a 53,89 token al secondo in una valutazione con 1.319 quesiti GSM8K e batch size 1. Il risultato riguarda tre ottimizzazioni applicate insieme; la data delle prove non è indicata.

Che cosa misura il risultato GSM8K

NVIDIA ha usato prompting a cinque esempi, temperatura 0,6, top-p 0,95, top-k 29, un massimo di 32.768 token generati e chain-of-thought attivo. Il throughput misura quanti token vengono generati al secondo durante la decodifica. NVIDIA ha riportato anche una latenza media passata da 15,21 a 11,49 secondi; il tempo medio al primo token è invece passato da 0,207 a 0,214 secondi.

Il modello testato, Ling-3.0-flash-fp4, è un modello MoE, cioè a esperti misti: per ogni token attiva una parte degli esperti invece dell’intero insieme. NVIDIA gli attribuisce 124 miliardi di parametri complessivi e 5,1 miliardi attivi per token. Ogni livello MoE seleziona otto esperti tra 512 esperti instradati, oltre a un esperto condiviso.

Tre interventi sulla generazione dei token

NVIDIA ha combinato tre tecniche che agiscono su parti diverse dell’inferenza:

• Humming sostituisce il backend FlashInfer per i kernel MoE MXFP4. Usa NVRTC, il compilatore CUDA a runtime, per compilare kernel adatti alle dimensioni, ai tipi di dato e all’architettura GPU.
• La quantizzazione online FP8 dell’LM head riduce la precisione numerica del livello finale che produce i punteggi dei token. NVIDIA afferma che, rispetto ai pesi BF16, FP8 dimezza il volume di pesi da leggere in quel livello. L’opzione SGLang SGLANG_ENABLE_FP8_LM_HEAD=1 è incompatibile con --enable-fp32-lm-head, usata nella configurazione di riferimento.
• MTP con NEXTN usa la previsione di più token per accelerare la decodifica speculativa: il modello draft propone token che il modello principale verifica. La configurazione descritta da NVIDIA usa tre passaggi draft e una finestra di verifica di quattro token.

La configurazione di riferimento impiegava W4A8, kernel MoE MXFP4 di FlashInfer, NVIDIA CUTLASS per le moltiplicazioni dense e l’opzione --enable-fp32-lm-head. I valori del confronto dipendono da questa base e dall’uso simultaneo delle tre ottimizzazioni.

Il +185,1% arriva da un carico diverso

NVIDIA ha riportato il +185,1% su un test sintetico con batch size 1, 32.000 token in ingresso e 2.000 in uscita. In quel test, il throughput è passato da 36,09 a 102,88 token al secondo. La valutazione GSM8K ha usato invece quesiti con prompting a cinque esempi e campionamento: sono due carichi distinti, non due stime dello stesso risultato.

Nel test sintetico l’accettazione MTP è stata di 3,90 token per round; su GSM8K è stata di 2,68. NVIDIA avverte che il risultato sintetico sovrastima i vantaggi della decodifica speculativa rispetto ad altri carichi. La differenza è rilevante perché l’accettazione dei token draft cambia con il tipo di testo e il metodo di generazione.

Il video in spagnolo di Codigo gris distingue l’elaborazione del prompt, che può essere limitata dalla capacità di calcolo, dalla generazione dei token, che può dipendere dalla larghezza di banda della memoria. Per valutare un carico locale, conviene quindi misurare separatamente l’elaborazione del prompt e la decodifica: il dato GSM8K riguarda quest’ultima.

La condivisione completa dell’LM head è essenziale

Quando FP8 e MTP vengono usati insieme, NVIDIA richiede che il modello draft condivida con quello principale il modulo completo dell’LM head, non soltanto i pesi. Se il draft riceve pesi FP8 ma li interpreta come BF16, la lunghezza di accettazione può scendere a 1,00 token per round e il throughput può risultare inferiore a quello della configurazione di riferimento.