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. Samen vormen ze de gids LLMs draaien op de DGX Spark.

Daardoor is deze post eigenlijk veranderd. Hij gaat minder over “wat is quantization?” en meer over wat er gebeurt als quantization van een model-card-term verandert in een architectuurkeuze.

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. Een modelnaam en een model card zijn papierwerk; de gewichten moeten echt in memory. 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.

Eén request draaien is de demo. Meerdere requests draaien is de workflow.

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 is geen los trucje onderaan de stack. Het beïnvloedt hoe de hele stack zich gedraagt.

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.

Voor on-prem AI is dat precies het punt. Je koopt hardware voor workflow, niet voor één mooie prompt. Je wilt weten hoeveel echt werk je op die doos kwijt kunt.

Als NVFP4 betekent dat je meer requests tegelijk kunt draaien, meer ruimte overhoudt en minder snel tegen geheugenlimieten botst, dan is dat geen detail in een tabel. Dan verandert je architectuur.

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. Eén trage stap is vervelend. Drie trage stappen achter elkaar voelen alsof het systeem nadenkt over zijn levenskeuzes.

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.

Dat is een andere vraag. En eerlijk gezegd ook de enige die telt.

De split wordt duidelijker

Mijn verwachting is nog steeds dat de beste on-prem setup een mix wordt. “Alles lokaal” klinkt stoer, maar meestal ook onnodig streng.

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.

Een on-prem setup is geen geloofsovertuiging. Het is een verdeling van werk.

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.

Voor productie maakt dat verschil uit. Niemand koopt iets aan “tokens per seconde” alleen. Je koopt ruimte in een workflow.

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.

Dat is precies waarom ik deze metingen wilde doen. Een universele ranglijst helpt weinig; betere architectuurkeuzes wel.

De vraag is niet: welk quantization-niveau wint?

De vraag is: welke taak mag op welke precisie, op welke machine, met hoeveel risico?

Daar begint on-prem AI voor mij interessant te worden: bij de verdeling van werk.