Wat quantization werd na drie benchmarkrondes

Dit was de eerste blogpost die ik live zette op deze site. Toen ik hem schreef, had ik net twee modellen op de DGX Spark draaien: Gemma-4-26B-A4B-it, een MoE-model, en een 31B dense model. Allebei lokaal, allebei via vLLM.

Op dat moment was quantization voor mij nog vooral een vraag. Ik kende de term, ik snapte ongeveer waar het over ging, maar ik had nog te weinig eigen metingen om er hard iets over te zeggen.

Inmiddels zijn we een paar benchmarkrondes verder. Eerst Gemma-4 op de DGX Spark. Daarna NVFP4 vs BF16 op datzelfde model. En daarna Nemotron-3 in BF16, FP8 en NVFP4. De bijbehorende benchmarkkaarten zijn Gemma-4 BF16, Gemma-4 NVFP4, en Nemotron-3 in BF16, FP8 en NVFP4. Samen vormen ze de gids LLMs draaien op de DGX Spark.

Ik heb deze post daarom aangevuld met wat die metingen betekenen voor mijn keuze van precisie en hardwaregebruik.

De eerste vraag was gewoon: past het?

Bij hosted modellen begin je vaak bij kwaliteit. Welke is slimmer, welke volgt instructies beter, welke schrijft betere code?

Lokaal begin je botter: past het?

Dat klinkt bijna te simpel, maar op eigen hardware is dat de eerste grens. De modelgewichten moeten in het beschikbare geheugen passen. Daarna wil je ook nog context kwijt, meerdere requests tegelijk verwerken, en liefst binnen seconden iets terugzien.

Bij de DGX Spark voel je dat meteen. Je ziet vLLM bezig: downloaden, laden, memory reserveren, warm worden. Daarna pas begint de discussie over throughput, latency en bruikbaarheid.

Dat is een ander gevoel dan een API-call naar Claude of GPT-5.5. Daar bestaat de infrastructuur vooral als abstractie. Je stuurt tekst heen en krijgt tekst terug. Bij lokaal draaien zie je de achterkant. Soms is dat leuk. Soms duurt het vooral lang.

Precies daar komt quantization binnen.

Mijn eerste beeld was te smal

Mijn eerste werkdefinitie was netjes genoeg: quantization slaat modelgewichten compacter op. FP16 of BF16 gebruikt meer ruimte dan 8-bit of 4-bit. Minder bits betekent minder geheugen. Minder geheugen betekent dat een model eerder past, sneller geladen kan worden, of ruimte overlaat voor meer context en meer requests.

Dat klopt, maar het is te klein.

Na de benchmarks kijk ik er anders naar. De vraag “past dit model op deze machine?” is pas het begin. Daarna komt de vraag wat je met die machine kunt doen zodra het model past.

Ik wil ook weten hoe het model reageert wanneer meerdere verzoeken tegelijk binnenkomen.

Daar zit voor mij het verschil. Een lokaal model dat één prompt netjes beantwoordt, is leuk. Een lokaal model dat meerdere gebruikers, agents of taken tegelijk aankan zonder dat latency instort, wordt bruikbaar.

Quantization bepaalt dus hoeveel speelruimte je overhoudt.

vLLM maakt het concreet

Ik gebruik vLLM omdat één request tegelijk niet de situatie is waar ik naartoe wil. Een lokale chatbot starten is prima om te testen, maar zodra je over agents praat krijg je ander verkeer.

Een agent haalt context op, roept tools aan, splitst werk op, vraagt soms parallel dingen uit en wacht tussendoor op resultaten. Ondertussen wil je dat een tweede request niet hoeft te wachten tot de eerste helemaal klaar is.

Daar wordt serving belangrijk.

vLLM is de laag die dit concreet maakt: batching, scheduling, memory efficiënter gebruiken en meerdere concurrent requests afhandelen. Het maakt ook zichtbaar dat lokaal draaien een systeem is. Het model, de precisie, de context-lengte, het aantal gelijktijdige requests en de scheduler trekken allemaal aan dezelfde hardware.

Dat was voor mij de eerste echte les. Quantization beïnvloedt zowel het geheugenverbruik als de manier waarop de server verzoeken kan verwerken.

BF16 voelde eerst als de veilige keuze

Als je nog niet gemeten hebt, voelt hogere precisie al snel veiliger. BF16 klinkt degelijk. Meer detail, minder kwaliteitsrisico, minder kans dat het model vreemd gedrag gaat vertonen.

Dat was ook mijn eerste reflex. Als de hardware het aankan, waarom zou je dan lager gaan zitten?

De metingen maakten dat minder vanzelfsprekend. Op de DGX Spark bleek BF16 in de latere runs vaak de minst praktische keuze. BF16 is niet “slecht”; de hardware en workload wegen alleen zwaarder dan het nette gevoel van hogere precisie.

Als een lagere precisie veel meer ruimte geeft voor concurrency, context of throughput, dan kan dat in de praktijk beter zijn. Zeker voor workloads waar snelheid en gelijktijdigheid zwaarder tellen dan het laatste beetje modelkwaliteit.

Dat vond ik de interessante draai. De hoogste precisie voelt intuïtief als de serieuze keuze. Op deze machine was dat vaak vooral de duurste keuze.

NVFP4 veranderde de Spark

De grootste verschuiving kwam bij NVFP4. In de benchmarkposts en de arena zie je dat NVFP4 de DGX Spark voor veel workloads bijna verdubbelt. Dat is geen kleine optimalisatie meer. Dat verandert wat je met dezelfde machine durft te proberen.

Bij de hardwarekeuze wil ik weten hoeveel verzoeken mijn toepassing tegelijk kan verwerken en hoe lang gebruikers daarbij moeten wachten.

Als NVFP4 meer geheugen vrijlaat, kan dat ruimte geven voor langere context of extra gelijktijdige verzoeken. Dat beïnvloedt hoe ik taken over de hardware verdeel.

Je kunt taken anders verdelen. Je kunt meer lokaal houden. Je kunt sneller experimenteren met agent-stappen die anders meteen naar een hosted model zouden gaan.

Daarmee werd quantization voor mij praktischer dan ik vooraf dacht. Het ging niet meer over een kleiner model, maar over een andere workflow mogelijk maken.

FP8 had een ander soort voordeel

FP8 zat niet simpelweg “tussen BF16 en NVFP4 in”. In de Nemotron-3-runs werd vooral tail-latency interessant. Dat trekt minder aandacht dan een grote throughput-sprong, maar in gebruik telt het minstens zo hard.

Gemiddelden liegen niet per se, maar ze stellen je gerust op de verkeerde momenten. Een workflow voelt traag door de paar requests die blijven hangen.

Daarom is tail-latency zo praktisch. Als een agent-workflow uit meerdere stappen bestaat, stapelen vertragingen. Meerdere trage stappen achter elkaar kunnen de totale wachttijd flink verhogen.

FP8 lijkt in die hoek nuttig: minder extreem dan NVFP4, maar interessant wanneer voorspelbaarheid belangrijker is dan maximaal zoveel mogelijk tegelijk draaien.

Dat is de nuance die ik in de eerste versie nog niet had. Precision is geen ladder waarbij lager altijd sneller en slechter is. Het is een set keuzes met verschillende trade-offs.

Kwaliteit blijft de open vraag

De benchmarks geven antwoord op memory, throughput en latency. Ze zeggen minder over gedrag.

Dat blijft de lastige kant van quantization. Je ziet kwaliteitsverlies niet altijd netjes in één metric. Soms wordt een antwoord vlakker. Soms gaat code net vaker mis. Soms kiest een agent de verkeerde tool. Soms merk je niets, tot je taak net anders is dan je testset.

Voor simpele taken kan dat prima zijn. Denk aan classificatie, routing, eerste samenvattingen, embeddings of een lichte pass over interne documenten. Daar hoeft niet altijd het zwaarste model op.

Voor code-generatie en agent-workflows ligt dat gevoeliger. Kleine fouten stapelen. Eén matige redenering is vervelend. Een verkeerde tool-call is een ander soort probleem.

Daarom wil ik quantized modellen niet alleen benchmarken op snelheid. Ik wil weten waar ik ze durf in te zetten.

Daarvoor zijn naast snelheidsmetingen ook inhoudelijke evaluaties nodig.

De split wordt duidelijker

Mijn verwachting is nog steeds dat de beste on-prem setup een mix wordt. Ik wil per taak bepalen waar die het best kan draaien.

De logische split wordt eerder:

• embeddings lokaal
• gevoelige documenten lokaal
• routing en classificatie lokaal
• simpele agent-stappen lokaal
• zware redenering naar Claude of GPT-5.5 wanneer dat nodig is

Quantization bepaalt hoe groot dat lokale deel kan worden. Hoe meer taken lokaal betrouwbaar en snel genoeg draaien, hoe minder je naar buiten hoeft te sturen.

Dat is voor klantwerk belangrijk. Niet omdat elke token per se binnen vier muren moet blijven, maar omdat sommige data daar wel hoort te blijven. En omdat latency, kosten en controle in productie gewoon meetellen.

Die afweging maak ik per taak en per soort gegevens.

Wat ik nu anders zou meten

In de eerste versie van deze post had ik vooral een lijst vragen. Hoe lang duurt downloaden? Hoe lang duurt laden? Hoeveel VRAM blijft over? Hoeveel concurrent requests kan ik sturen voordat latency vervelend wordt?

Die vragen blijven nuttig, maar ze zijn het begin. Hoe ik die metingen op de Spark precies opzet, staat in de arena-methodologie.

Nu zou ik per precisie drie dingen naast elkaar leggen:

• systeemgedrag: laden, memory, throughput, latency en tail-latency
• modelgedrag: Nederlandse output, codevragen, langere context, tool-use
• workflowgeschiktheid: welke taken durf ik hiermee lokaal te draaien

Dat laatste mis je snel als je alleen naar benchmarktabellen kijkt. Een model kan technisch draaien en toch onhandig zijn. Of juist minder mooi scoren, maar precies goed genoeg zijn voor routing of samenvatten.

Naast tokens per seconde beoordeel ik dus of de toepassing het werk goed uitvoert en hoeveel tijd controle en correctie kosten.

Wat ik nu snap

Mijn werkdefinitie is verschoven.

Quantization maakt een model kleiner, maar dat is slechts de ingang. Het verandert hoeveel werk je uit dezelfde hardware krijgt, welke latency je accepteert en welke taken je lokaal durft te houden.

Op de DGX Spark lijkt de hoogste precisie zelden automatisch de beste keuze. NVFP4 maakt de machine voor veel workloads veel bruikbaarder. FP8 is interessant wanneer tail-latency belangrijk wordt. BF16 blijft nuttig als referentiepunt, maar voelt op deze hardware minder vaak als de praktische default.

Ik gebruik deze metingen om voor mijn toepassingen een precisie en verdeling van taken te kiezen.

Er is geen precisie die ik voor alle taken zou kiezen.

Ik beoordeel per taak welke precisie voldoende kwaliteit en snelheid oplevert op de beschikbare machine.

Die inhoudelijke vergelijking wil ik in volgende tests verder uitwerken.