NVIDIA meldde op 27 oktober 2026 dat drie optimalisaties de decodeerdoorvoer van Ling-3.0-flash-fp4 op een DGX Spark verhoogden van 37,81 naar 53,89 tokens per seconde. Dat is 42,5% meer op een evaluatie met 1.319 GSM8K-vragen en batchgrootte 1. De datum is die van NVIDIA’s publicatie; de testdatum is niet vermeld.
Wat NVIDIA op DGX Spark mat
De meting betrof het genereren van tokens, de decodeerfase van een taalmodel. NVIDIA beschreef die fase bij deze configuratie als geheugenbandbreedtegebonden: het lezen van modelgewichten bepaalde een groot deel van de uitvoeringstijd.
GSM8K gebruikte vijf voorbeelden in de prompt, een temperatuur van 0,6, top-p 0,95 en top-k 29. NVIDIA zette chain-of-thought aan en stelde het maximum op 32.768 gegenereerde tokens. De gemiddelde latency daalde in de test van 15,21 naar 11,49 seconden. De gemiddelde tijd tot het eerste token steeg licht, van 0,207 naar 0,214 seconden.
Drie ingrepen in de decodeerfase
NVIDIA combineerde drie technieken voor Ling-3.0-flash-fp4:
- Humming MXFP4 MoE-kernels: Humming verving de FlashInfer-backend voor de Mixture-of-Experts-lagen. Een MoE-model heeft meerdere experts, maar activeert voor elk token slechts een deel daarvan. In dit model selecteert een token per MoE-laag acht van de 512 experts, naast één gedeelde expert.
- Online FP8-kwantisering van de LM-head: de LM-head is de uitvoerlaag die de volgende token helpt bepalen. NVIDIA meldt dat FP8-kwantisering de hoeveelheid te lezen gewichten voor die laag halveert ten opzichte van BF16. De instelling
SGLANG_ENABLE_FP8_LM_HEAD=1is niet te combineren met de baseline-optie--enable-fp32-lm-head. - NEXTN-MTP: bij speculatief decoderen stelt een draftmodel meerdere tokens voor, waarna het doelmodel ze verifieert. NVIDIA gebruikte drie draftstappen en een verificatievenster van vier tokens.
De baseline gebruikte de W4A8-configuratie uit de cookbook, FlashInfer MXFP4 MoE-kernels, NVIDIA CUTLASS voor dense GEMM en --enable-fp32-lm-head.
Waarom de synthetische winst anders uitvalt
De gerapporteerde stijging van 185,1% kwam uit een aparte synthetische test, niet uit GSM8K. Die test draaide met batchgrootte 1, een vaste invoer van 32K tokens en een vaste uitvoer van 2K tokens. De decodeerdoorvoer ging daar van 36,09 naar 102,88 tokens per seconde. NVIDIA gebruikte greedy decoding; de gemiddelde MTP-acceptlengte was 3,90 tokens per ronde. Bij GSM8K was die acceptlengte 2,68.
| Evaluatie en condities | Baseline | Met alle drie optimalisaties | Door NVIDIA gemelde stijging |
| GSM8K, 1.319 vragen, batchgrootte 1 | 37,81 tokens/s | 53,89 tokens/s | 42,5% |
| Synthetisch, 32K invoer en 2K uitvoer, batchgrootte 1 | 36,09 tokens/s | 102,88 tokens/s | 185,1% |
De tests meten allebei decodeerdoorvoer, maar hun prompts, uitvoer en decodeerinstellingen verschillen. De synthetische uitkomst is daarom geen voorspelling voor GSM8K of andere workloads.
Promptverwerking en tokengeneratie zijn bovendien verschillende fasen. In de Spaanstalige video legt Codigo gris uit dat promptverwerking rekenkracht kan begrenzen, terwijl tokengeneratie door geheugenbandbreedte kan worden begrensd. Dat onderscheid helpt bepalen welke meting aansluit op een eigen workload.
De integratievoorwaarde voor FP8 en MTP
Bij de combinatie van FP8-kwantisering en MTP moet het draftmodel volgens NVIDIA de volledige LM-headmodule delen met het doelmodel. Alleen de gewichten delen kan ertoe leiden dat het draftmodel FP8-gewichten als BF16 interpreteert. NVIDIA meldt dat de acceptlengte dan kan dalen tot 1,00 token per ronde en de doorvoer onder de baseline kan uitkomen.
