Django de Vreng

Gemma-4 v23 op de DGX Spark

2026-06-23T00:00:00.000Z

NVFP4 blijft de praktische default voor Gemma-4 op de DGX Spark, maar MTP is nu de interessante middenpositie. In de nieuwe vLLM v0.23.0-runs zit NVFP4 nog steeds bovenaan bij chat en multi-turn, terwijl MTP de BF16-run duidelijk voorbij loopt zonder naar de NVIDIA re-quant te wisselen.

Ik heb dezelfde Gemma-4-26B-A4B-familie opnieuw gedraaid op de DGX Spark, nu met vllm/vllm-openai:v0.23.0-aarch64-cu129-ubuntu2404. De ruwe data staat in de benchmark-repo bij commit 605faab6a599. De Arena heeft er drie nieuwe entries bij: BF16 v23, MTP v23 en NVFP4 v23.

De vorige Gemma-post ging vooral over de prijs van context in BF16. Deze run beantwoordt een andere vraag: wat verandert er als dezelfde machine, hetzelfde modelgebied en dezelfde workloads op vLLM v0.23.0 draaien, met drie serve-profielen naast elkaar?

De setup die gelijk bleef

Alle drie de runs draaien op dezelfde machine en dezelfde benchmarkvorm:

Onderdeel	Waarde
Hardware	DGX Spark NVIDIA GB10, 128 GB unified memory
vLLM image	`vllm/vllm-openai:v0.23.0-aarch64-cu129-ubuntu2404`
KV-cache	`fp8`
Prefix caching	uit
Max model length	131072
Benchmark commit	`605faab6a599`

De drie profielen:

Profiel	Model	Served name	Generated
BF16 v23	`google/gemma-4-26B-A4B-it`	`gemma-4-26b-a4b`	2026-06-22T23:16:36+02:00
MTP v23	`google/gemma-4-26B-A4B-it`	`gemma-4-26b-a4b-mtp`	2026-06-23T03:29:52+02:00
NVFP4 v23	`nvidia/Gemma-4-26B-A4B-NVFP4`	`gemma-4-26b-a4b-nvfp4`	2026-06-23T01:35:33+02:00

MTP gebruikt dus hetzelfde Google-modelpad als BF16, maar served met het MTP-profiel. NVFP4 gebruikt de NVIDIA re-quant. Dat onderscheid is belangrijk, want anders vergelijk je stiekem twee dingen tegelijk: enginegedrag en modelartefact.

Chat: NVFP4 bovenaan, MTP haalt BF16 in

De eerste nuttige vergelijking is Run C: 1024 prompttokens, 1024 outputtokens, tien gelijktijdige requests. Dat is een nette chatvorm: niet triviaal kort, maar ook geen contextmonster.

Profiel	TTFT c10	Decode/user c10	Decode totaal c10
BF16 v23	1342.98 ± 449.90 ms	11.47 ± 0.45 tok/s	90.83 ± 7.87 tok/s
MTP v23	1400.13 ± 142.07 ms	17.79 ± 1.55 tok/s	138.97 ± 6.68 tok/s
NVFP4 v23	1138.26 ± 385.15 ms	21.59 ± 0.98 tok/s	151.22 ± 15.96 tok/s

Dit is de kern. MTP geeft op deze chat-run ongeveer 55 procent meer per-user decode dan BF16. NVFP4 zit daar nog boven, maar het gat tussen MTP en NVFP4 is veel kleiner dan het gat tussen BF16 en MTP.

De latency voor de eerste token blijft in dezelfde orde. NVFP4 is hier het snelst, MTP is niet sneller in TTFT dan BF16. Dat past bij het beeld dat deze profielen vooral decode-doorvoer beïnvloeden. Prefill blijft gewoon werk.

Multi-turn is waar NVFP4 echt losloopt

Run E is voor mij de meest productie-achtige closed-loop test: vijf beurten per gesprek, tien gesprekken parallel, 2048 starttokens en 512 outputtokens per beurt.

Profiel	TTFT c10	Decode/user c10	Decode totaal c10
BF16 v23	2154.60 ± 858.63 ms	10.69 ± 0.25 tok/s	98.35 ± 3.95 tok/s
MTP v23	2368.00 ± 789.47 ms	16.57 ± 1.32 tok/s	143.47 ± 4.67 tok/s
NVFP4 v23	1966.10 ± 735.30 ms	20.01 ± 0.80 tok/s	182.90 ± 6.67 tok/s

Hier wordt NVFP4 gewoon lekker. 182.90 tok/s totaal voor tien multi-turn gesprekken op een Spark is geen demo-cijfer, dat is een werkbaar lokaal inference-profiel.

MTP blijft nuttig. Niet als winnaar, wel als antwoord op: wat als ik het Google BF16-model wil blijven serveren en toch meer decode wil? Dan is 16.57 tok/s per gebruiker een groot verschil met 10.69.

Lange output: meer tokens, niet automatisch meer pijn

Voor agents en code-generatie is Run G relevant: 256 prompttokens, 4096 outputtokens, tien gelijktijdige requests. Dit is de vorm waarbij je vooral wilt weten of lange generaties de machine laten instorten.

Profiel	TTFT c10	Decode/user c10	Decode totaal c10
BF16 v23	490.95 ± 4.88 ms	12.47 ± 0.94 tok/s	87.16 ± 3.88 tok/s
MTP v23	564.16 ± 14.86 ms	17.67 ± 1.92 tok/s	127.52 ± 9.05 tok/s
NVFP4 v23	368.83 ± 54.97 ms	23.69 ± 1.65 tok/s	120.96 ± 50.17 tok/s

Let op de rare vorm: NVFP4 heeft de hoogste per-user decode, maar de totale decode heeft veel meer spreiding. MTP is lager per gebruiker, maar stabieler in deze specifieke run. Ik zou hier dus niet alleen naar de hoogste balk kijken. Voor agents wil je ook voorspelbaarheid, zeker als meerdere runs lang blijven streamen.

25k context blijft de muur

Quantization en MTP veranderen niet dat grote context vooral prefill is. Bij 25k prompttokens en c10 ziet het er zo uit:

Profiel	TTFT c10	Decode/user c10	Decode totaal c10
BF16 v23	39281.43 ± 20075.74 ms	5.28 ± 2.13 tok/s	28.49 ± 0.62 tok/s
MTP v23	45640.37 ± 23247.85 ms	6.05 ± 3.24 tok/s	27.62 ± 0.27 tok/s
NVFP4 v23	38575.15 ± 19624.30 ms	7.40 ± 4.24 tok/s	33.54 ± 0.03 tok/s

Dit is geen chat meer. Bij tien gelijktijdige 25k-prompts wacht je gemiddeld rond de 39 tot 46 seconden op de eerste token. NVFP4 helpt decode nog een beetje, maar de gebruiker voelt vooral leegte voor de stream begint.

Dat is dezelfde les als in de eerdere Gemma-4 benchmarkpost, alleen nu met vLLM v0.23.0 erbij: context is geen gratis invoerveld. Als je een lokale agent 25k tokens laat meeslepen, betaal je dat in TTFT.

Open-loop: de kantoorvorm blijft bruikbaar

De open-loop tests zijn belangrijker voor gevoel dan de closed-loop tabellen. Ze sturen requests volgens een arrival pattern in plaats van alles tegelijk te laten starten.

H: kantoor-baseline

200 random prompts, request rate 0.3, burstiness 0.7.

Profiel	OK	Output tok/s	P95 TTFT	P95 TPOT
BF16 v23	200/200	129.92	2835.43 ms	197.57 ms
MTP v23	200/200	132.35	3394.53 ms	178.77 ms
NVFP4 v23	200/200	139.05	2393.78 ms	77.98 ms

NVFP4 is hier duidelijk prettiger. Niet door veel meer output-throughput, want 139.05 versus 129.92 tok/s is geen wereldschok. Het verschil zit in TPOT: 77.98 ms p95 tegenover 197.57 ms bij BF16. De stream voelt veel sneller zodra hij loopt.

I: ShareGPT replay

250 echte gesprekken, zelfde request rate.

Profiel	OK	Output tok/s	P95 TTFT	P95 TPOT
BF16 v23	250/250	60.93	456.10 ms	115.31 ms
MTP v23	250/250	61.47	576.82 ms	77.32 ms
NVFP4 v23	250/250	61.99	225.09 ms	45.30 ms

Dit is de beste proxy voor normale chat. Korte, echte gesprekken. NVFP4 geeft p95 TTFT van 225.09 ms en p95 TPOT van 45.30 ms. Dat voelt lokaal niet als een compromis.

J: maandagochtend-piek

300 random prompts, target 1.5 rps, max concurrency 25.

Profiel	OK	Output tok/s	P95 TTFT	P95 TPOT
BF16 v23	300/300	132.04	3006.73 ms	199.23 ms
MTP v23	300/300	172.32	3870.47 ms	235.91 ms
NVFP4 v23	300/300	218.90	2390.17 ms	124.58 ms

Bij overload blijft NVFP4 ook het meest bruikbaar. Alle requests slagen, maar de queue bepaalt wie pijn voelt. BF16 en MTP leveren hier minder fijne tails op. MTP heeft wel meer output-throughput dan BF16, maar de p95 TTFT en p95 TPOT zijn slechter. Dat is precies waarom ik percentielen wil zien en niet alleen tokens per seconde.

Wat ik hiermee in de Arena zet

Ik heb drie nieuwe Arena entries toegevoegd in plaats van de oude Gemma-4 entries te overschrijven. De oude v0.20.1-runs blijven nuttig als historisch vergelijkingspunt. Deze nieuwe entries zijn expliciet v23:

De korte rangorde voor mijn eigen gebruik:

NVFP4 v23 voor lokale chat, agents en kantoor-load.
MTP v23 als je bij het Google-modelartefact wilt blijven, maar BF16-decode te traag vindt.
BF16 v23 als controlelijn en voor vergelijkingen waar precisie belangrijker is dan serve-snelheid.

Voor 25k context lost geen van de drie het echte probleem op. Daar moet je aan promptbudget, retrieval, memory compaction en agent-architectuur werken. Niet hopen dat een serve-profiel de wachttijd wegtovert.

De drie getallen achter een snelle DGX Spark

2026-05-22T00:00:00.000Z

Kun je serieus large language models lokaal draaien op een DGX Spark? Ja. Dat is het saaie antwoord, en het is ook het antwoord dat elke review je geeft: een modelnaam, een getal, tokens per seconde, klaar.

Het bruikbare antwoord is lastiger. Een model dat één demo-prompt netjes afhandelt zegt niks over een maandagochtend met tien mensen, grote context, agent-flows en iemand die een halve roman in een ticket plakt. Daar gaat het schuren, of niet. En dat hangt niet af van de Spark, het hangt af van je workload.

Ik heb een Spark in het lab staan en er een stapel modellen op gedraaid, in BF16, FP8 en NVFP4. Negen workloads, twee meetmethodes, en een paar runs opnieuw omdat de eerste verdacht goed was. Wat na al dat meten overbleef is geen scorebord. Het is één manier van kijken die elke keer klopte, en die staat hieronder. De harde cijfers per model staan in de losse posts, en de complete gids met de setup, de kosten en voor wie het werkt staat op LLMs draaien op de DGX Spark. Dit stuk gaat over die ene lens.

Wat het ding eigenlijk is

De DGX Spark is NVIDIA's kleinste Blackwell-machine. Een GB10-superchip, 128 GB unified memory, klein genoeg voor een serverkast. Geen losse videokaart met een eigen geheugenpoel, maar één geheugen dat de CPU en de GPU samen delen. Onthoud dat getal van 128 GB. Het is je hele budget, en alles wat hierna komt is een verdeelsom binnen die 128.

Eén ding moet je vooraf weten, want het verklaart later de helft van de cijfers. De Spark draait op desktop-Blackwell, SM12.1, en die chip kan niet native in 4-bit rekenen. De grote datacenter-Blackwell, de B200, wel. Gevolg: van 4-bit quantization krijg je op de Spark de volle geheugenwinst, maar niet de volle rekenwinst. vLLM vangt dat op door 4-bit gewichten tijdens het rekenen terug te pakken naar hogere precisie.

Dat werkt prima. Maar het is precies de reden dat je de mooie FP4-cijfers van een B200 niet zomaar op je eigen Spark moet plakken.

Wat past er in 128 GB

Kort: de gewichten gaan er eerst in, de rest is KV-cache voor alle gebruikers samen. Precisie is daarom een ontwerpkeuze vooraf, geen knopje achteraf, en ik schreef er een aparte post over. De vraag is nooit of een model past, maar wat er overblijft als het past. De volledige verdeelsom staat in de gids.

Hoe snel het echt is

Hier gaan de meeste DGX Spark-reviews de fout in. Ze pakken één prompt, meten tokens per seconde, en noemen dat "de snelheid". Maar snelheid is op deze machine geen getal. Het zijn drie dingen, ze voelen anders en ze gedragen zich anders. Haal ze uit elkaar en de hele Spark valt op zijn plek.

Decode is bijna gratis

Decode is de tekst die binnenkomt zodra het model eenmaal genereert. Op de Spark is dat saai stabiel, en saai is hier een compliment. Eén gebruiker op een 26B-model haalt tussen de 23 en 24 tokens per seconde in BF16, of je nu 4k of 25k context meegeeft. Tien gebruikers tegelijk: een stuk of 9 à 12 per persoon, en daar blijft het plakken. Decode hangt dus aan hoeveel mensen er tegelijk bezig zijn, niet aan hoe lang hun prompt is.

En quantization tilt die hele lijn omhoog. NVFP4 won op decode in alle negen tests, met 22 tot 92 procent afhankelijk van de workload. Op een lichter MoE-model als Nemotron-3 tikt single-user decode zelfs tegen de 60 t/s aan. Decode is, kortom, het probleem niet.

Prefill is de rekening

Prefill wel. Prefill is de stilte vóór het eerste token, en dat is wat een gebruiker als "traag" ervaart, niet de tokens daarna.

Prefill schaalt mee met je promptgrootte, en dat doet pijn. Een korte prompt is binnen een halve seconde verwerkt, ook met tien man tegelijk. Gooi er 25k context tegenaan met diezelfde tien gebruikers en je wacht 35 seconden op het eerste teken. Zelfde machine, zelfde concurrency, alleen een langere prompt. Verdubbel de prompt, verdubbel grofweg de wachttijd.

En quantization? Helpt hier nauwelijks. Prefill is rekenwerk, en rekenwerk is precies waar die SM12.1-handicap zit. NVFP4 maakt je decode sneller. Je prefill blijft prefill.

Onder druk queue't hij, hij crasht niet

Blijft de vraag: wat doet hij als je er gewoon te veel op gooit? Het antwoord is geruststellend saai. Hij valt niet om. Hij gaat in de rij staan.

In de zwaarste test wilde ik 1,5 requests per seconde door de machine duwen. Hij haalde daar bijna zes keer minder van. En toch faalde geen enkele van de 300 requests. De vertraging ging ook niet naar iedereen, hij ging naar de staart: de doorsnee-gebruiker merkte weinig, de ongelukkige één procent wachtte zes seconden op zijn eerste token.

Voor on-prem is dat de beste uitkomst die je kunt hopen. Een crash is een telefoontje. Een rij is even geduld. Een kantoor leeft met het tweede, niet met het eerste.

Dat is het hele model. Decode is bijna gratis, prefill is de rekening, queueing is je vangnet. De cijfers eronder, negen workloads per model en twee meetmethodes, staan in de arena en in de losse posts: de BF16-baseline, NVFP4 tegen BF16 en Nemotron-3 in drie precisies.

De rest staat in de gids

Welke engine ik draai (vLLM), wat een Spark kost, en voor wie dit wel of niet werkt: dat is het complete plaatje, en dat hoort in de gids, niet in dit ene lens-verhaal. De korte versie van "voor wie": lokaal wordt pas interessant als de data niet de deur uit mag. Heb je die eis niet en wil je puur de snelste, goedkoopste tokens, dan is een cloud-API het eerlijkere antwoord.

Lokaal draaien is geen principe. Het is een verdeling: wat moet binnen blijven, en wat mag naar buiten.

Doe het zelf na

Alles wat hieronder ligt is open. De modellen staan op Hugging Face, vLLM is open source, en de ruwe benchmark-output plus de scripts staan op GitHub. De methodologie legt uit welke negen workloads ik draai en waarom.

Heb je zelf een Spark, dan zou je dezelfde route moeten kunnen lopen en ongeveer dezelfde cijfers moeten krijgen. Lukt dat niet, dan wil ik dat juist weten. Mail gerust.

Waarom deze blog en arena bestaan

2026-05-05T00:00:00.000Z

Voor klanten van Kamoo zet ik AI-systemen op die soms dicht bij huis moeten blijven. Accountants, administraties, kantoren met persoonsgegevens en financiële stukken. Precies het soort data waar je auditor niet rustiger van wordt als je zegt: “we sturen het even naar Amerika”.

Daarom staat er bij ons een DGX Spark. 128 GB unified memory, klein genoeg voor een serverkast, groot genoeg om serieus lokale modellen te draaien via vLLM. Wat er praktisch op past, verzamel ik op de overzichtspagina over lokale modellen op de DGX Spark.

Toen begon de praktische vraag.

Welk model gebruik je waarvoor op deze machine? Welke precisie kies je? Hoeveel context past nog? Waar valt concurrency om? Wat gebeurt er op een gewone maandag met tien mensen die niet tegelijk een benchmark draaien, maar gewoon hun werk doen?

Ik zocht cijfers voor precies die vragen. Geen algemene leaderboard met een score die vooral goed staat in een screenshot. Gewoon: deze chip, deze modellen, deze engines, deze workloads, deze grenzen.

Die vond ik niet.

Dus bouw ik ze zelf op.

De arena is de meetbank

Op dit moment staan er tien benchmarkprofielen in de arena, met runs voor onder meer context-scaling, concurrency, output-throughput, RAG-achtige workloads en Maandagochtend-piek.

Die arena moet één ding goed doen: laten zien wat je op een DGX Spark praktisch kunt verwachten. Niet welk model “het beste” is in abstracte zin, maar welk model op deze hardware bruikbaar blijft onder de workloads die ik in klantwerk tegenkom.

Bij een paar runs schreef ik al op wat er misging en wat ik eruit haalde. Bijvoorbeeld waar Gemma-4 op de Spark begint te schuren, wat NVFP4 wint van BF16 als de bugs eenmaal weg zijn, en hoe drie precisies van Nemotron-3 zich verhouden.

De ruwe output staat publiek op GitHub: djangodevreng/dgx-spark-benchmarks. Dat is bewust. Als je zelf een Spark hebt, moet je dezelfde route kunnen lopen en ongeveer dezelfde cijfers kunnen krijgen. Als dat niet lukt, is dat ook interessante data.

De arena is dus geen statisch lijstje. Het is een werkbank. Nieuwe modellen erin, andere precisies ernaast, workloads aanscherpen, rare resultaten opnieuw draaien. Precies saai genoeg om nuttig te worden.

De blog is de context eromheen

Cijfers zijn handig, maar ze vertellen niet het hele verhaal.

Een benchmark kan zeggen dat NVFP4 sneller is dan BF16. De blog kan vertellen dat de eerste runs stukliepen op vLLM-bugs, dat een parameter verkeerd stond, dat een model pas bruikbaar werd nadat de contextlengte omlaag ging, of dat de tail-latency erger voelde dan het gemiddelde deed vermoeden.

Dat is de laag die ik zelf miste toen ik begon. Niet alleen “hier is een score”, maar: dit probeerde ik, dit brak, dit heb ik aangepast, en dit zou ik de volgende keer anders doen.

Daarom staan de blog en arena naast elkaar. De arena geeft de meetpunten. De blog geeft de redenering, de fouten en de praktische keuzes erachter.

Waarom lokaal

Privacy is meestal de nette uitleg. Die klopt ook. De praktischere reden: sommige klanten hebben geen keuze.

Een accountantskantoor kan klantdata niet behandelen alsof het voorbeeldtekst in een demo is. Gemeentes hebben regels. Financiële documenten hebben regels. Persoonsgegevens hebben regels. In de praktijk komt dat allemaal neer op dezelfde vraag: kun je dit opzetten zonder dat legal, compliance en audit meteen de deur dichttrekken?

Dan heb je twee opties. AI past daar niet, of je maakt het lokaal.

Wij kiezen voor lokaal waar dat nodig is. De Spark maakt dat ineens minder exotisch. Hij is niet goedkoop, maar wel behapbaar voor een MKB-kantoor dat iets serieus wil doen zonder meteen een eigen datacenter te bouwen.

Daar zit voor mij het interessante werk: modellen draaien, latency meten, prompts testen, documenten door een pipeline trekken, en kijken waar het breekt.

Meestal breekt het ergens saais. Dat zijn de beste plekken.

Wat ik wil kunnen beantwoorden

De arena moet uiteindelijk antwoord geven op vragen die in projecten steeds terugkomen.

Welk model is snel genoeg voor interne documentvragen? Welke precisie geeft genoeg ruimte voor meerdere gebruikers tegelijk? Wanneer is NVFP4 prima, wanneer wil je FP8, en wanneer is BF16 vooral een dure default? Hoeveel context kun je geven voordat latency vervelend wordt? Welke engine past beter bij welke workload: vLLM, TensorRT-LLM of SGLang?

Dat zijn geen academische vragen. Ze bepalen hoe je een on-prem setup ontwerpt. Hoeveel hardware je nodig hebt. Welke data lokaal blijft. Welke stappen je eventueel naar een hosted model stuurt. En waar je de grens trekt tussen “werkt in een demo” en “houdt stand op maandagochtend”.

Die laatste grens is de hele reden dat deze site bestaat.

Waarom ik dit publiek opschrijf

Alles wat ik hiervoor gebruik is open of publiek: vLLM, modellen op Hugging Face, benchmark-scripts, losse JSON, de site zelf. Het geheim zit niet in toegang tot een magisch dashboard. Het zit in uren proberen, meten, opnieuw draaien, bugs zoeken en daarna nog eens meten omdat je eerste run verdacht goed was.

Dat kostte mij inmiddels tientallen uren. Modellen laten draaien, runs herhalen, rare resultaten uitvogelen, en daarna nog een keer meten omdat de eerste run verdacht goed was.

Als iemand anders dezelfde route loopt, hoeft die niet opnieuw door alle stoeptegels heen. En als iemand mijn cijfers tegenspreekt met betere runs: mooi. Dan wordt de arena beter.

Er zit ook een tweede reden onder. Deze site is zelf onderdeel van het experiment. De blog, de arena, de flow van benchmark-output naar gestructureerde JSON naar pagina’s: dat is grotendeels in een paar weken gebouwd met agents die meeschrijven en meebouwen. De kleine versie daarvan beschreef ik eerder in de OpenClaw-setup op een Raspberry Pi.

Die workflow is inmiddels onderdeel van het werk. Ik dump ruwe bevindingen in Slack, laat een agent de repo en schrijfgids lezen, krijg een branch met voorstel terug, draai checks en review zelf de diff. Dat scheelt geen denken. Het verplaatst wel veel voorbereiding naar een laag die gewoon doorwerkt.

Schrijven over dat proces dwingt me om het minder rommelig te maken dan mijn terminal history. Dat helpt. Niet altijd leuk, wel nodig.

Wat ik hierna wil bouwen

Eerst meer benchmarks. vLLM was het startpunt, omdat het snel werkt en breed gebruikt wordt. TensorRT-LLM ligt al op de werkbank voor Nemotron-3. SGLang wil ik daarna naast dezelfde workloads leggen. Pas met meerdere engines zie je of je model traag is, je engine dwarsligt, of jij gewoon iets doms hebt gedaan.

Daarna wil ik bench-spark publiek maken: de benchmark-runner zoals ik hem nu gebruik. Geen perfect framework. Wel iets waarmee iemand met dezelfde hardware dezelfde vragen kan stellen zonder eerst mijn fouten na te bouwen.

Ook wil ik een Nederlandse eval-suite voor lokale LLMs maken. Geen Engelse reasoning-benchmark erbij, maar kantoorwerk: accountancy-jargon, juridische teksten, financiële stukken, documenten met rare opmaak. Precies de dingen waar lokale AI in Nederland op afgerekend wordt.

En er komt meer werk rond lokaal RAG op grote documentsets. Geen platform-pitch. Gewoon uitzoeken hoe je meer dan een miljoen documenten door een on-prem setup krijgt zonder dat opslag, retrieval of OCR je langzaam gaat haten.

Wat ik oversla

Geen dagelijkse AI-nieuwsbrief. Daar zijn al genoeg plekken voor, sommige zelfs expres.

Geen general-purpose “wij doen alles met AI”-verhaal. Te breed, en meestal betekent het niets.

Geen thought-leader-act. Ik bouw liever iets dat kraakt dan een mening die soepel klinkt.

Ook geen platform bouwen zoals OpenClaw. Ik gebruik het, ik schrijf erover, ik bouw er flows mee. Maar die laag zelf laat ik aan de mensen die daar elke dag in zitten.

Wat dit moet worden

Voor klanten moet dit laten zien wat lokale AI praktisch kost: hardware, latency, precisie, onderhoud, rare randgevallen. Voor mij is het de plek waar ik mijn eigen aannames vastzet voordat de volgende benchmark ze onderuit haalt.

Ik probeer het ritme vast te houden. Geen belofte per week. Als er niets te melden is, staat hier niets. Als er bugs, runs en rare grafieken zijn, staat hier waarschijnlijk te veel.

Gemma-4 op de DGX Spark: NVFP4 vs BF16

2026-05-03T00:00:00.000Z

import BenchCard from "../../components/post/BenchCard.astro"; import BenchCardRow from "../../components/post/BenchCardRow.astro"; import Note from "../../components/post/Note.astro";

In de BF16-baseline van Gemma-4 op de DGX Spark deed ik negen benchmarks met Gemma-4-26B-A4B in BF16. Decode-snelheid hield prima stand, prefill bepaalde wanneer de muur kwam, en het systeem queue'de netjes onder druk in plaats van te crashen. Dat verhaal leek af, totdat NVIDIA een NVFP4-quantized versie van datzelfde model uitbracht.

Zelfde architectuur en fine-tune, zelfde server-config, alleen de precisie verandert. Van BF16 (16 bits per parameter) naar NVFP4 (4 bits per parameter, NVIDIA's variant op FP4). Vier keer kleiner per gewicht, en als de Blackwell-kernels meewerken ook flink sneller op compute-zware taken.

Op papier dus mooi. In de praktijk: de officiële vLLM v0.20.1-release herkent dit checkpoint zonder gedoe, en de cijfers waren over de hele linie sneller dan de BF16-baseline. Beide tests vallen onder de gids LLMs draaien op de DGX Spark.

Waarom dit überhaupt onderzoeken

Voor een kantoor met een lokale AI-machine is geheugen-budget het meest beperkende ding na rekenkracht. Een 26B model in BF16 neemt ~48 GB GPU-geheugen voor weights alleen. Op een Spark met 128 GB unified memory blijft er zo'n 65 GB over voor KV-cache. Voldoende voor het kantoorscenario uit de eerste blog, maar niet veel ruimte om bijvoorbeeld 30+ gebruikers met grote context naast elkaar te draaien.

NVFP4 reduceert dat tot ~18 GB voor weights. Niet vier keer minder dan BF16 (de vision-encoder blijft BF16, en scale-factors kosten ook ruimte), maar wel ongeveer 2.7× minder. Dat geeft je richting 95 GB KV-cache headroom, wat in theorie veel hogere concurrency moet ondersteunen. Daar komt nog bij dat er minder geheugenverkeer per forward pass nodig is, dus per definitie minder bandwidth-druk, en dat was in BF16 al de bottleneck bij multi-user load. De vraag was dus simpel: hoeveel van die theoretische winst overleeft de praktijk?

Wat NVFP4 eigenlijk is

NVFP4 is NVIDIA's variant op FP4: floating-point getallen met 4 bits per waarde. Vier bits, niet vier bytes, dus een factor 4 minder per parameter dan BF16. Door per groep gewichten een scaling factor mee op te slaan blijft de accuracy redelijk overeind.

Voor Blackwell ligt het zo. NVIDIA's datacenter-kaarten (B100, B200, SM10.0) hebben tensor cores die natively met 4-bit waarden kunnen rekenen, en dat is veel sneller dan dezelfde berekening in FP16 of BF16. De DGX Spark daarentegen is desktop-Blackwell (GB10, SM12.1) en die architectuur heeft géén native FP4-compute.<Note>Op een datacenter B200 (SM10.0) zou je hier nog 2 tot 3× bovenop verwachten dankzij native FP4 tensor cores. Spark mist die hardware-pad, dus alle winst komt uit geheugen-bandwidth, niet uit compute.</Note> Wat je in dat geval krijgt is "weight-only" FP4: de gewichten zijn fysiek 4-bit opgeslagen (vandaar de geheugen-winst), maar tijdens compute worden ze on-the-fly gedecodeerd naar FP16 voor de matrix-multiplications. Een vLLM-warning maakt dat expliciet:

Your GPU does not have native support for FP4 computation but FP4 quantization
is being used. Weight-only FP4 compression will be used leveraging the Marlin kernel.
This may degrade performance for compute-heavy workloads.

Geheugen-winst krijg je dus volledig, compute-winst maar gedeeltelijk. De Marlin INT4 GEMM kernel is geoptimaliseerd, maar niet zo snel als native FP4 op SM10.0 zou zijn. Goed om in te calculeren bij de cijfers verderop.

De testopstelling

Server-config identiek aan de eerste blog, alleen het model wisselt:

docker run -d --name vllm-bench \
  --gpus all --ipc=host \
  -v appliance_hf-cache:/root/.cache/huggingface \
  -p 8000:8000 \
  vllm/vllm-openai:v0.20.1 \
  --model nvidia/Gemma-4-26B-A4B-NVFP4 \
  --served-model-name gemma-4-26b-a4b-nvfp4 \
  --max-model-len 131072 \
  --gpu-memory-utilization 0.95 \
  --kv-cache-dtype fp8 \
  --limit-mm-per-prompt '{"image":0,"audio":0}' \
  --async-scheduling \
  --no-enable-prefix-caching \
  --host 0.0.0.0 \
  --port 8000

Tests zijn één-op-één gelijk aan de eerste blog: zelfde commands, zelfde concurrency-niveaus, zelfde datasets voor de open-loop tests, zelfde seed. Dat is opzettelijk, want wil je het effect van een geïsoleerde variabele meten (in dit geval de precisie), dan moet alles eromheen gelijk blijven. Hoe ik die concurrency-niveaus, seeds en open-loop-aankomsten precies meet staat in de meetmethode van de Arena.

Vergelijking	BF16	NVFP4
Model	google/gemma-4-26B-A4B-it	nvidia/Gemma-4-26B-A4B-NVFP4
Active params	4B	4B
Total params	26B	26B
Model memory	~48 GB	~18 GB
KV-cache headroom	~65 GB	~95 GB
MoE backend	(default)	MARLIN (geforceerd)

Drie cijfers vatten waar het op uitkomt samen. Klik door voor de volledige run in de Arena, met alle seeds, concurrency-niveaus en commands:

Een interactieve versie van alle cijfers staat op de arena-pagina van Gemma-4-26B-A4B-NVFP4, inclusief commands en TTFT-percentielen voor alle 9 tests.

<details> <summary>Run A: context-scaling van 4k naar 25k</summary>

Decode per gebruiker bij groeiende context, c=1/5/10:

Context	Users	BF16 d/u	NVFP4 d/u	Winst
4k	1	24.08	29.80	+24%
4k	5	12.55	22.01	+75%
4k	10	9.48	16.94	+79%
8k	1	23.69	29.31	+24%
8k	5	11.48	19.28	+68%
8k	10	8.52	14.35	+68%
16k	1	23.34	28.55	+22%
16k	5	10.05	15.67	+56%
16k	10	6.79	10.06	+48%
25k	1	22.75	27.70	+22%
25k	5	8.46	12.46	+47%
25k	10	5.40	7.55	+40%

Bij c=1 is de winst stabiel rond +22-24% door alle contexts heen. Geheugen-bandwidth speelt bij single-user nauwelijks, dus de winst zit hier in het compute-pad zelf. Marlin's INT4-decode plus FP16-matmul is iets sneller dan BF16's directe FP16-matmul, ondanks dat het twee stappen zijn.

Bij c=10 schaalt het verschil veel sterker met workload-type, van +40% bij 25k context tot +79% bij 4k. Dat komt doordat bij multi-user de geheugen-bandwidth de bottleneck wordt, en NVFP4 leest minder bytes per forward pass. Hoe meer concurrent, hoe meer dat telt, totdat je weer aan de KV-cache memory limits zit (25k context met meerdere users) en de winst afvlakt.

TTFT (eerste token) is ook beter:

Context	Users	BF16 TTFT	NVFP4 TTFT
4k	10	4.46s	4.20s
8k	10	7.99s	7.84s
16k	10	18.92s	18.69s
25k	10	35.67s	35.65s

Op TTFT is de winst klein. Dat is logisch: prefill is compute-zwaar, en op SM12.1 zonder native FP4-tensorcores moet Marlin de gewichten on-the-fly decoderen voor de matmul. Dat kost terug wat de geheugen-bandwidth opleverde. Voor decode telt bandwidth zwaarder dan compute, voor prefill andersom.

</details>

<details> <summary>Run B: 25k context, concurrency tot 20</summary>

De stress-test uit deel één:

Users	BF16 d/u	NVFP4 d/u	BF16 TTFT	NVFP4 TTFT
5	8.51 t/s	12.43 t/s	19.86s	19.72s
10	5.37 t/s	7.56 t/s	35.44s	35.51s
20	3.16 t/s	4.26 t/s	67.37s	67.40s

Aggregate decode plateau verschuift van 32 t/s naar 36 t/s op c=20: een 12% hoger plafond bij 25k context onder maximale druk. TTFT is praktisch identiek tussen BF16 en NVFP4 omdat prefill hier de muur is en die niet veel sneller wordt op SM12.1. Decode per gebruiker is wel duidelijk beter: bij twintig parallelle 25k-prompts haal je 4.26 in plaats van 3.16 t/s, +35%. Nog steeds geen chat-snelheid, maar wel een merkbaar verschil zodra de tokens beginnen te stromen.

</details>

<details> <summary>Run C: 1k prompt, 1k output</summary>

De korte-prompt + lange-antwoord workload, dichtbij agent-flows en code-generatie:

Users	BF16 d/u	NVFP4 d/u	Winst
1	23.86	29.45	+23%
5	13.59	24.69	+82%
10	10.92	20.88	+91%

Bij c=10 zit per-user decode op ruim 20 t/s, boven leessnelheid en dichtbij comfortabele streaming-UI. Aggregate decode bij c=10 tikt op 209 t/s in plaats van 86 t/s in BF16, bijna een verdubbeling.

</details>

<details> <summary>Run E: multi-turn (depth 4)</summary>

Vijf opeenvolgende beurten per gesprek, tien gesprekken parallel: de meest realistische kantoor-shape.

Users	BF16 d/u	NVFP4 d/u	BF16 TTFT	NVFP4 TTFT
1	23.97	29.61	0.53s	0.33s
5	13.07	23.98	1.32s	1.11s
10	10.43	19.51	2.13s	1.94s

Voor tien parallelle 5-turn gesprekken: 1.94 seconden tot eerste token, 19.51 t/s per gebruiker. Dat past comfortabel binnen wat een lezer als chat ervaart, en is 87% sneller per token dan BF16 in dezelfde test.

</details>

<details> <summary>Run F: RAG-mix (8k prompt)</summary>

Users	BF16 d/u	NVFP4 d/u	BF16 TTFT	NVFP4 TTFT
5	12.11	20.91	4.32s	4.28s
10	9.31	15.96	7.99s	8.00s
20	6.05	10.57	14.61s	14.45s

8k context is ongeveer wat een RAG-flow met vier chunks van 2k tokens binnenkrijgt. Bij tien gebruikers wacht je 8 seconden tot eerste token (vrijwel gelijk aan BF16, want compute-bottleneck), daarna 16 t/s streamen. Voor "vraag iets over je documenten"-flows ruim werkbaar, en waar de winst zit: in decode-snelheid, niet in TTFT.

</details>

<details> <summary>Run G: korte instructie, 4096 outputtokens</summary>

De agent / code-generatie shape:

Users	BF16 d/u	NVFP4 d/u	BF16 TTFT	NVFP4 TTFT
1	24.17	29.59	0.24s	0.11s
5	14.32	25.79	0.38s	0.23s
10	11.75	22.54	0.48s	0.37s

TTFT van 110 milliseconden bij single-user is heel laag, lager dan de meeste hosted APIs over het netwerk halen. En 22.54 t/s per user bij c=10 is ruim genoeg voor agent-streams. Aggregate decode bij c=10 in deze test komt uit op 225 t/s versus 84 t/s in BF16, bijna 2.7× zo veel. Voor een team dat tien gelijktijdige agents draait die elk lange gestructureerde output produceren is dit het belangrijkste cijfer.

</details>

<details> <summary>Run H: open-loop, random 4k workload</summary>

De synthetische kantoor-baseline met Poisson-aankomsten:

Metric	BF16	NVFP4
Achieved RPS	0.27	0.29
Peak concurrent	36	16
TTFT P50	1286 ms	1006 ms
TTFT P99	3316 ms	2893 ms
TPOT P50	182 ms	64 ms
Total tok/s	1215	1302

Wat opvalt is dat de peak concurrent zakt van 36 naar 16 bij identieke arrival rate (0.3 rps) en identieke prompts. Doordat NVFP4 elk verzoek sneller afhandelt blijft de queue korter, en dat is een belangrijk inzicht voor capaciteits-planning: NVFP4 geeft je niet alleen lagere latency per request, maar ook minder queue-druk bij dezelfde arrival rate. Tegelijk zakt TPOT P50 van 182ms naar 64ms. Mediaan inter-token latency dus bijna drie keer sneller. Voor een chat-UI die token-streaming toont is dat het verschil tussen kunstmatig wachten op een antwoord en gewoon meelezen.

</details>

<details> <summary>Run I: ShareGPT replay (echte gesprekken)</summary>

Echte multi-turn conversation data:

Metric	BF16	NVFP4
Peak concurrent	17	10
TTFT P50	353 ms	152 ms
TTFT P99	637 ms	265 ms
TPOT P50	95 ms	39 ms

P99 TTFT van 265 milliseconden, voor 99 procent van de gebruikers. TPOT van 39 ms komt neer op 25.6 t/s per gebruiker. Dat mag je gerust realtime chat noemen voor 25 medewerkers met realistische ShareGPT-stijl prompts.

</details>

<details> <summary>Run J: Maandagochtend-piek</summary>

Het zwaarste scenario uit deel één: overbelaste server, 1.5 rps target met max 25 gelijktijdige requests.

Metric	BF16	NVFP4
Configured RPS	1.50	1.50
Achieved RPS	0.26	0.44
TTFT P50	1132 ms	920 ms
TTFT P99	6157 ms	6054 ms
TPOT P50	187 ms	108 ms
Total tok/s	1173	1984

Het meest meetbare cijfer van de hele dag is dat de achieved RPS van 0.26 naar 0.44 gaat. Hetzelfde target, dezelfde concurrency-cap, dezelfde Poisson-aankomsten, en NVFP4 verwerkt 69% meer verzoeken per seconde voordat de queue dichtslibt.

P99 TTFT verschuift maar marginaal (6.16s naar 6.05s). Dat klopt met het patroon: prefill is compute-bound op SM12.1, en daar is NVFP4 niet veel sneller. Maar TPOT P50 zakt van 187ms naar 108ms, en aggregate token throughput groeit van 1173 naar 1984 t/s. Voor een 25-persoons-kantoor in piekuren is dat het verschil tussen genoeg en knel: meer requests per seconde verwerkt, met snellere streaming voor wie aan de beurt is.

</details>

Wat dit betekent voor on-prem AI

Als je een Spark hebt en Gemma-4-26B draait, dan is NVFP4 de upgrade. In alle 9 tests is NVFP4 de winnaar, en het laat 30 GB geheugen vrij voor andere doeleinden zoals meer KV-cache, een tweede klein model ernaast, of batch-jobs. Bij Kamoo staat deze NVFP4-config nu naast de BF16-baseline in bench-spark/, en één commando schakelt tussen de twee.

Voor een 25-persoons-kantoor met realistische ShareGPT-achtige prompts merk je het direct. TPOT P50 zakt van 95 ms naar 39 ms, P99 TTFT van 637 ms naar 265 ms. En als er piekbelasting komt, levert het systeem 69% meer verzoeken per seconde voordat het vol komt te staan. Voor agent-flows en code-generatie (Run G shape) staat de Spark in NVFP4 op zijn sterkst: tien parallelle agents, elk 4096 tokens output, 22.5 t/s per gebruiker met TTFT onder 400 ms.

Voor 25k context-stress (Run B) blijft het de muur. NVFP4 verlaagt 'm nauwelijks (TTFT verschilt minder dan een seconde), want prefill blijft prefill, en tien parallelle 25k-prompts wachten 35 seconden op het eerste token. Daar verandert quantization niets aan op deze hardware. Wel decode-snelheid: 7.56 t/s/user in plaats van 5.37, dus zodra de tokens komen, lopen ze sneller.

Wat deze run niet zegt

Dit is geen NVFP4 op SM10.0 (datacenter Blackwell). Daar zou native FP4-compute het verschil veel groter maken, met een verwachting van een verdere 2-3× speedup bovenop wat we hier zien. Op een H100 of B200 zijn deze cijfers dus niet representatief; de Spark heeft een specifieke SM12.1-handicap (geen native FP4) die in de cloud niet bestaat.

Dit is ook geen vergelijking met dense Gemma-4-31B in NVFP4. Dense ondergaat een ander code-pad door vLLM's loader. Voor een vervolg-blog zou dense-NVFP4 met dezelfde testsuite een derde datapunt opleveren.

En dit is geen lange-termijn accuracy-vergelijking. NVFP4 quantization heeft potentieel kleine accuracy-effecten. Voor de typische taken in een kantoor (samenvatting, ticket-classificatie, RAG) zelden merkbaar, voor edge-cases mogelijk wel.

Wat NVIDIA wél heeft gepubliceerd staat in de NVFP4-model-card: op MMLU-Pro, GPQA-Diamond en LiveCodeBench zit NVFP4 binnen 0.2 tot 0.7 punten van hun eigen BF16-baseline.<Note>NVIDIA's eigen BF16-baseline wijkt zelf af van Google's officiële Gemma-4-card cijfers. Eval-harnesses verschillen meer dan precisie zelf, dus kruisvergelijking tussen vendors zonder identieke harness is wankel.</Note> Dat valt binnen run-to-run-variance, geen echte degradatie. Curieus aan diezelfde tabel is dat NVIDIA's BF16-baseline weer afwijkt van wat Google in de officiële Gemma-4-card publiceert: MMLU-Pro 85.0 vs 82.6, GPQA 80.3 vs 82.3, LiveCodeBench 80.5 vs 77.1. Niet omdat quantization beter wordt dan het origineel, maar omdat eval-harness blijkbaar meer uitmaakt dan de precisie zelf. Andere prompts, andere temperature, andere stop-criteria. Kruisvergelijkingen tussen vendors zijn dus zonder dezelfde harness lastig hard te maken.

Wat blijft hangen

Decode verkoopt de benchmark, prefill bepaalt de ervaring. Dat klopte in deel één en dat klopt nog steeds. Wat NVFP4 toevoegt is dat decode in elke workload sneller wordt, en het meest waar het ertoe doet: bij grotere context en meer gebruikers tegelijk. TTFT blijft op SM12.1 grofweg gelijk omdat prefill compute-bound is en de Spark geen native FP4-tensorcores heeft. Voor wat de gebruiker voelt zodra de tokens beginnen te stromen, is NVFP4 op deze hardware fors beter dan BF16, en het kost niets aan setup-pijn: één officiële vLLM-image, één model-flag, en het draait.

Nemotron-3 op de DGX Spark: BF16 vs FP8 vs NVFP4

2026-05-03T00:00:00.000Z

In de vorige posts draaide ik Gemma-4 op de DGX Spark. Eerst alleen BF16 als baseline, daarna NVFP4 vs BF16 over dezelfde test-suite. Dat gaf één model in twee precisies. Nuttig, maar nog geen echt beeld van de keuze die je in productie moet maken.

Voor dit stuk draai ik drie varianten van hetzelfde model naast elkaar: BF16, FP8 en NVFP4 van Nemotron-3-Nano-Omni-30B-A3B-Reasoning. Zelfde Spark. Zelfde vLLM-versie. Zelfde prompts. Zelfde benchmark-suite. Zo dicht bij een eerlijke quantization-vergelijking als ik hem op deze machine kan krijgen.

De korte versie: NVFP4 wint op snelheid en throughput, FP8 wint vaker op tail-latency, BF16 is vooral nog nuttig als baseline. Dat is minder netjes dan "4 bit is altijd beter". Gelukkig maar, anders was deze post kort geweest. Onderdeel van de gids LLMs draaien op de DGX Spark.

Waarom dit experiment

De Gemma-post liet vooral zien dat NVFP4 op de Spark werkt. Wel met pijn. Vijf vLLM-bugs, een nightly build en genoeg flags om een command-regel eruit te laten zien als een kleine bekentenis.

Maar Gemma beantwoordde niet de vraag die ik voor klanten nodig heb: wat kies je als je vandaag een lokaal model op een Spark wil draaien? BF16 omdat dat de originele weights zijn? FP8 omdat Blackwell daar native goed in is? Of NVFP4 omdat je veel meer model en KV-cache in hetzelfde geheugen krijgt?

Daarom deze run. Eén model in drie precisies. Geen leaderboard-score, maar workloads die lijken op kantoorwerk: chat, RAG, langere antwoorden, meerdere gebruikers tegelijk en een maandagochtend waarop iedereen ineens denkt dat AI toch handig is.

Wat BF16, FP8 en NVFP4 hier betekenen

BF16 is de baseline: 16 bits per parameter, ongeveer 2 bytes. Voor dit model betekent dat grofweg 61,5 GB aan checkpoint-size. Dat past op de Spark, maar het eet veel van je 128 GB unified memory op voordat er ook maar één gebruiker context in de KV-cache heeft staan.

FP8 halveert dat gewicht ongeveer. De checkpoint is 32,8 GB. Op Blackwell is FP8 een logische keuze: minder geheugen, native ondersteuning, en meestal weinig gedoe in vLLM.

NVFP4 gaat nog verder. De checkpoint is 20,9 GB. Niet vier keer kleiner dan BF16, omdat de vision- en audio-encoders in BF16 blijven, maar klein genoeg om de Spark anders te laten voelen. Meer ruimte voor KV-cache, meer batching, meer concurrency.

De nuance: de DGX Spark draait op desktop Blackwell SM12.1. Daar is NVFP4 niet hetzelfde feest als op datacenter-Blackwell. vLLM gebruikt Marlin om FP4 weights te decoderen richting FP16 tijdens compute. Je krijgt de geheugenwinst volledig. De compute-winst is minder zuiver.

Voor deze post maakt dat juist interessant. Dit is geen theoretische quantization-post. Dit is: wat gebeurt er op deze machine, met deze stack, als je de drie opties echt draait?

Precisie	Model size	Geheugen-budget over van 128 GB
BF16	61.5 GB	~66 GB
FP8	32.8 GB	~95 GB
NVFP4	20.9 GB	~107 GB

De testopstelling

Alle runs draaien via Docker op de DGX Spark met vllm/vllm-openai:v0.20.0. Officiële release, geen patches.

docker run -d --name vllm-bench \
  --gpus all --ipc=host \
  -v appliance_hf-cache:/root/.cache/huggingface \
  -p 8000:8000 \
  -e HF_TOKEN="***" \
  vllm/vllm-openai:v0.20.0 \
  vllm serve nvidia/Nemotron-3-Nano-Omni-30B-A3B-Reasoning-NVFP4 \
  --max-model-len 131072 \
  --gpu-memory-utilization 0.95 \
  --max-num-seqs 256 \
  --max-num-batched-tokens 8192 \
  --trust-remote-code \
  --video-pruning-rate 0.5 \
  --reasoning-parser nemotron_v3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder \
  --limit-mm-per-prompt '{"image":0,"audio":0}'

Voor FP8 gebruik ik hetzelfde profiel met --kv-cache-dtype fp8. BF16 draait zonder die KV-cache-flag. Verder blijft de test gelijk.

De benchmark-suite staat beschreven op de arena-methodologie. Kort gezegd: closed-loop tests voor decode en TTFT per gebruiker, plus open-loop tests met Poisson-aankomsten om te zien hoe de server zich gedraagt als requests niet netjes op elkaar wachten.

Setup

Ik begon verkeerd met nvcr.io/nvidia/vllm:26.02-py3, NVIDIA's eigen vLLM-container. Die had vLLM 0.15.1 en kende de NemotronH_Nano_Omni_Reasoning_V3 architectuur nog niet.

De oplossing was saaier: vllm/vllm-openai:v0.20.0. Officiële release, juiste flashinfer-versies, eerste run werkend.

Onze eigen bench-spark CLI had nog twee kleine fixes nodig: de NVIDIA-entrypoint omzeilen met --entrypoint vllm, en HF_TOKEN automatisch doorgeven aan de container. Daarna liep de suite.

Les: begin met de stable release die de architectuur ondersteunt.

<details> <summary>Run A: context-scaling</summary>

Deze run is de basis: wat gebeurt er als de prompt langer wordt, terwijl het aantal gebruikers oploopt van één naar tien? Dat raakt direct aan kantoorwerk. Een korte chat is makkelijk. Een RAG-vraag met 25k context en meerdere mensen tegelijk is waar de Spark laat zien hoeveel ruimte er echt over is.

Hier kijk ik naar twee dingen. Eerst decode per gebruiker: hoe snel komt tekst terug zodra de generatie loopt? Daarna TTFT: hoe lang wacht je op het eerste token? Bij lange context is TTFT vaak de pijn die gebruikers als eerste voelen. Ze zien geen tokens, dus het voelt alsof het systeem vastzit.

Single-user is vooral een pure snelheidsmeting. Daar verdubbelt NVFP4 bijna BF16. Bij tien gebruikers wordt het interessanter: de kleinere weights geven vLLM meer ruimte om te batchen, en dan wordt BF16 gewoon zwaar.

Decode/user (tg256), c=1

Context	BF16	FP8	NVFP4	NVFP4 vs BF16
4k	29.23	51.68	60.30	+106%
8k	28.59	49.82	55.72	+95%
16k	28.24	47.52	55.24	+96%
25k	28.24	48.85	54.98	+95%

BF16 blijft netjes vlak rond 28-29 tokens per seconde. Dat is stabiel, maar niet snel. FP8 zet daar ongeveer 50 t/s tegenover. NVFP4 zit rond 55-60 t/s. Voor één gebruiker is dat het verschil tussen "prima" en "dit voelt lokaal maar niet lokaal-traag".

Decode/user (tg256), c=10

Context	BF16	FP8	NVFP4	NVFP4 vs BF16
4k	7.76	13.45	19.69	+154%
8k	7.13	11.14	17.90	+151%
16k	6.30	10.73	14.99	+138%
25k	5.56	8.59	12.99	+134%

Bij tien gebruikers is NVFP4 niet "wat sneller". Het is een andere klasse. Op 25k context doet BF16 5,56 tok/s/user. NVFP4 doet 12,99. Dat is nog steeds geen cloud-GPU-cluster, maar het verschil in gevoel is groot: BF16 wordt wachten, NVFP4 blijft werken.

TTFT (eerste token), c=10

Context	BF16	FP8	NVFP4
4k	3.90s	2.91s	2.45s
8k	6.49s	5.93s	4.03s
16k	12.63s	10.55s	8.01s
25k	19.82s	16.89s	12.71s

Dit is de tabel die ik voor echte gebruikers het meest serieus neem. Bij 25k context en tien gebruikers wacht je met BF16 bijna 20 seconden op het eerste token. Met NVFP4 is dat 12,7 seconden. Nog steeds lang, maar niet hetzelfde soort lang.

</details>

<details> <summary>Run B: 25k context, concurrency tot 20</summary>

Run A laat zien hoe contextlengte schaalt. Run B houdt de context zwaar en verhoogt alleen de concurrency. Dit is de "iedereen stelt tegelijk een grote vraag"-test.

In de praktijk gebeurt dit niet elk uur. Tien tot twintig mensen klikken zelden exact tegelijk met 25k context op verzenden. Maar als je een lokale AI-machine voor een team neerzet, wil je weten hoe hij faalt. Rustig langzamer worden is acceptabel. Een queue die voelt alsof hij dood is, niet.

NVFP4 houdt hier de meeste lucht. Niet omdat het model slimmer wordt, maar omdat de server met kleinere weights meer ruimte heeft voor batching en KV-cache.

Gebruikers	BF16 d/u	FP8 d/u	NVFP4 d/u	NVFP4 vs BF16
5	9.06	15.33	20.75	+129%
10	5.65	9.18	12.99	+130%
20	3.70	5.97	7.79	+110%

Gebruikers	BF16 TTFT	FP8 TTFT	NVFP4 TTFT
5	11.01s	8.89s	7.21s
10	19.75s	15.82s	12.74s
20	37.88s	29.91s	24.08s

Twintig gebruikers met 25k context is expres onaardig. Toch is het nuttig. BF16 zit op 37,88 seconden TTFT. Dat voelt stuk. NVFP4 zit op 24,08 seconden. Ook niet gezellig, maar nog steeds ruim dertien seconden sneller.

Aggregate decode laat hetzelfde beeld zien:

Gebruikers	BF16	FP8	NVFP4
5	34 t/s	53 t/s	71 t/s
10	38 t/s	59 t/s	77 t/s
20	44 t/s	66 t/s	84 t/s

Het plafond verschuift van 44 t/s naar 84 t/s. Voor een enkele gebruiker is dat abstract. Voor een team betekent het dat de queue sneller leegloopt.

</details>

<details> <summary>Run C: korte prompt, lange output</summary>

Dit is de workload voor agents, code-generatie en langere antwoorden: weinig input, veel output. De prompt is maar 1024 tokens, dus prefill is hier niet het probleem. De vraag is vooral hoe snel het model blijft doortikken zodra de output lang wordt.

Daarom kijk ik hier naar decode per gebruiker. TTFT moet laag blijven, maar het echte verschil voel je pas na een paar honderd tokens. Een model dat snel begint maar daarna op 8 tok/s blijft hangen, voelt alsnog traag.

NVFP4 wint hier duidelijk. Bij tien parallelle gebruikers blijft het model op 22,90 tok/s/user zitten. BF16 zakt naar 7,84. Dat is nog leesbaar, maar voor een agent-flow voelt het alsof iemand met de hand meetypt.

Gebruikers	BF16 d/u	FP8 d/u	NVFP4 d/u
1	28.65	49.85	55.55
5	12.19	21.32	30.97
10	7.84	15.26	22.90

Voor deze workload is NVFP4 de logische default. FP8 is netjes, maar je levert hier vooral snelheid in zonder dat tail-latency de hoofdrol speelt.

</details>

<details> <summary>Run E: multi-turn, depth 4</summary>

Multi-turn is dichter bij echt gebruik dan één losse prompt. Vijf beurten per gesprek, meerdere gesprekken parallel. Dat lijkt op een medewerker die niet één vraag stelt, maar doorvraagt, corrigeert en context meeneemt.

Hier wil ik niet alleen hoge throughput zien. Ik wil vooral dat de server niet elke beurt opnieuw voelt alsof hij uit een koude start komt. Bij tien gesprekken tegelijk wordt dat relevant: de context groeit per gesprek, de scheduler moet blijven delen, en de gebruiker verwacht dat de chat blijft lopen.

Dit is voor mij de belangrijkste kantoor-run. Niet omdat hij perfect echt is, maar omdat hij het dichtst in de buurt komt van "25 mensen gebruiken dit verspreid over de dag".

Gebruikers	BF16 d/u	FP8 d/u	NVFP4 d/u	NVFP4 TTFT
1	28.69	49.72	56.18	596 ms
5	11.50	20.87	30.55	1032 ms
10	7.68	14.88	21.58	1359 ms

Bij tien parallelle gesprekken zit NVFP4 op 21,58 tok/s/user. FP8 zit op 14,88. BF16 op 7,68. Dat laatste werkt technisch, maar het voelt niet meer als een vlotte chat. NVFP4 blijft ruim boven de grens waar je antwoord als vloeiend ervaart.

</details>

<details> <summary>Run F: RAG-mix met 8k prompt</summary>

RAG is meestal geen 25k context, maar ook geen korte chat. Deze run gebruikt 8k prompt en 512 outputtokens. Denk aan vier chunks van ongeveer 2k tokens, plus vraag en instructie.

Bij RAG telt prefill meer dan bij Run C. Je stopt elke keer een flinke lap context in het model voordat er iets terugkomt. Daarna wil je genoeg decode overhouden om het antwoord bruikbaar snel te maken.

De vraag is dus: blijft quantization helpen als de prompt zwaarder wordt? Ja. NVFP4 blijft duidelijk voor, ook bij twintig gebruikers.

Gebruikers	BF16 d/u	FP8 d/u	NVFP4 d/u
5	12.50	21.02	27.77
10	8.11	14.37	19.65
20	5.51	9.82	14.09

Bij twintig gebruikers levert NVFP4 14,09 tok/s/user. BF16 zit op 5,51. Voor batch-processing kan dat nog. Voor real-time RAG op een kantoor voelt BF16 krap, zeker als documenten rommelig zijn en prompts langer worden dan je had gehoopt. Dat worden ze altijd.

</details>

<details> <summary>Run G: korte instructie, 4096 outputtokens</summary>

Run G lijkt op Run C, maar trekt de output veel verder door: 4096 tokens. Dit is de shape van agents die plannen uitschrijven, code genereren, lange analyses maken of meerdere bestanden samenvatten.

Bij dit soort workloads is de eerste token bijna bijzaak. Als het antwoord lang is, bepaalt decode-snelheid de ervaring. Tien seconden verschil aan het begin is vervelend. Minutenlang op output wachten is erger.

NVFP4 blijft hier het sterkst. Belangrijker: het blijft ook bij tien gebruikers boven 25 tok/s/user. Dat is voor lokale hardware op een bureau-machine gewoon bruikbaar.

Gebruikers	BF16 d/u	FP8 d/u	NVFP4 d/u	NVFP4 TTFT
1	28.68	49.75	55.44	179 ms
5	14.32	25.56	34.63	427 ms
10	9.51	18.40	25.18	363 ms

Voor agent-flows is dit vrij hard: BF16 is niet stuk, maar je betaalt elke lange output dubbel. Eerst in geheugen, daarna in wachttijd.

</details>

<details> <summary>Run H: open-loop kantoor-baseline</summary>

Vanaf hier verandert de interpretatie. De vorige runs sturen gecontroleerde batches door het model. Run H gebruikt open-loop traffic: requests komen binnen volgens een Poisson-verdeling. De server moet dus omgaan met aankomsten die niet netjes wachten tot de vorige klaar is.

Dit lijkt meer op een kantoor. Niet perfect, wel beter dan iedereen tegelijk of juist volledig sequentieel. De metrics zijn ook anders. TPOT vertelt hoe snel tokens komen zodra je aan de beurt bent. TTFT P50 vertelt de normale ervaring. TTFT P99 vertelt wat de pechvogel merkt.

Hier wordt FP8 interessant. NVFP4 wint de mediaan en TPOT, maar FP8 wint de tail. Dat is precies waarom ik niet wil eindigen met "NVFP4 is altijd beter".

Metric	BF16	FP8	NVFP4
Achieved RPS	0.26	0.28	0.29
Peak concurrent	42	18	15
TTFT P50	1229 ms	732 ms	618 ms
TTFT P99	2996 ms	2008 ms	3235 ms
TPOT P50	203 ms	74 ms	39 ms
Aggregate tok/s	1203	1297	1329

Die peak concurrent van BF16 lijkt op papier goed, maar is het niet. De queue loopt op omdat BF16 hem minder snel leeg krijgt. NVFP4 verwerkt sneller, dus er staan minder requests tegelijk open. Dat is geen lagere capaciteit, dat is minder file.

De echte keuze zit tussen NVFP4 en FP8. Wil je de beste mediaan en snelste output, dan NVFP4. Wil je de netste P99 op deze workload, dan FP8.

</details>

<details> <summary>Run I: ShareGPT replay</summary>

ShareGPT replay is rommeliger en daardoor nuttig. Echte gesprekken hebben wisselende lengtes, vervolgvragen, korte antwoorden, lange antwoorden en prompts die niet door een benchmark-auteur netjes zijn gladgestreken.

Dit is de run die ik het meest vertrouw voor chatgevoel. Niet voor bedrijfsdocumenten, wel voor de vraag: hoe voelt dit als meerdere mensen door de dag heen gesprekken voeren?

Het patroon uit Run H blijft staan. NVFP4 is het snelst voor de doorsnee gebruiker. FP8 heeft de betere P99.

Metric	BF16	FP8	NVFP4
Peak concurrent	17	12	10
TTFT P50	433 ms	220 ms	157 ms
TTFT P99	713 ms	422 ms	1361 ms
TPOT P50	118 ms	38 ms	26 ms

NVFP4 voelt instant voor de meeste gebruikers: 157 ms TTFT P50 en 26 ms TPOT P50. Maar de P99 is 1361 ms, waar FP8 op 422 ms blijft. Dat is een fors verschil.

Voor een interne chat waar een enkele tragere request geen ramp is, kies ik NVFP4. Voor een product-UI met harde latency-belofte zou ik FP8 serieuzer nemen.

</details>

<details> <summary>Run J: maandagochtend-piek</summary>

Run J is oversubscribe. Het target is 1,5 requests per seconde met een concurrency-cap van 25. Dit is niet de normale werkdag. Dit is de test voor wat er gebeurt als de vraag groter is dan de server netjes kan bijhouden.

Bij oversubscribe kijk ik eerst naar achieved RPS. Niet naar configured RPS, want die is voor iedereen hetzelfde. De vraag is hoeveel requests de server daadwerkelijk verwerkt terwijl hij onder druk staat.

Daar wint NVFP4 duidelijk. FP8 houdt de tail netter, maar NVFP4 krijgt veel meer werk door de machine.

Metric	BF16	FP8	NVFP4
Configured RPS	1.50	1.50	1.50
Achieved RPS	0.25	0.43	0.58
Peak concurrent	28	28	28
TTFT P50	1130 ms	757 ms	687 ms
TTFT P99	5184 ms	3388 ms	4462 ms
TPOT P50	197 ms	112 ms	82 ms
Aggregate tok/s	1118	1951	2622

Concreet: NVFP4 verwerkt ongeveer 35 requests per minuut. BF16 ongeveer 15. Dat is het verschil tussen een queue die langzaam leegloopt en een queue die gebruikers aan het twijfelen brengt of ze nog een keer moeten klikken. Niet klikken. Nooit helpen die tweede klikken.

</details>

De drie precisies naast elkaar

Als ik één realistische chat-run moet kiezen, pak ik ShareGPT replay. Daar zie je het onderscheid het schoonst: NVFP4 wint de normale ervaring, FP8 wint de tail, BF16 doet mee maar nergens overtuigend.

Metric	BF16	FP8	NVFP4	Beste keuze
TPOT P50	118 ms	38 ms	26 ms	NVFP4
TTFT P50	433 ms	220 ms	157 ms	NVFP4
TTFT P99	713 ms	422 ms	1361 ms	FP8
Peak concurrent	17	12	10	NVFP4
Achieved RPS	0.30	0.30	0.30	gelijk

Bij oversubscribe wordt het verschil harder:

Metric	BF16	FP8	NVFP4	Beste keuze
Achieved RPS	0.25	0.43	0.58	NVFP4
TTFT P50	1130 ms	757 ms	687 ms	NVFP4
TTFT P99	5184 ms	3388 ms	4462 ms	FP8
TPOT P50	197 ms	112 ms	82 ms	NVFP4
Aggregate tok/s	1118	1951	2622	NVFP4

Dat maakt de keuze praktischer dan ik vooraf dacht. NVFP4 is de default als je throughput en normale gebruikerservaring wil. FP8 is de keuze als je P99 belangrijker vindt dan mediaan. BF16 is de baseline waarmee je checkt of quantization je accuracy sloopt.

Waarom FP8 de P99 wint

Mijn hypothese: NVFP4 geeft vLLM meer geheugenruimte en daarmee meer batchingruimte. Dat verhoogt throughput en verlaagt TPOT, maar individuele requests kunnen soms langer wachten voordat ze netjes in een batch vallen.

FP8 heeft minder headroom dan NVFP4, maar nog genoeg voor deze workload. Daardoor lijkt de scheduler voorspelbaarder. Minder agressief, minder snel in mediaan, beter in de tail.

BF16 heeft het slechtste van beide werelden: grote weights, minder KV-cache-headroom en lagere decode. De queue wordt voller, maar niet omdat de server zo veel tegelijk aankan. Hij komt er gewoon minder snel doorheen.

Dit wil ik nog verder uitzoeken met scheduler-instellingen en prefix caching. De ruwe cijfers en de testdefinities staan in de arena zodat ik toekomstige runs naast dezelfde lat kan leggen.

Vergelijking met Gemma-4-26B-A4B

Nemotron-NVFP4 is single-user bijna twee keer sneller dan Gemma-NVFP4. Bij multi-user wordt het verschil kleiner, maar blijft het meestal positief.

Workload	Gemma-NVFP4 d/u	Nemotron-NVFP4 d/u	Ratio
pp4096 c=1	30.01	60.30	2.0×
pp8192 c=1	29.35	55.72	1.9×
pp25000 c=1	28.00	54.98	2.0×
pp4096 c=10	17.05	19.69	1.2×
pp25000 c=10	7.61	12.99	1.7×

Dat patroon klopt bij wat het model is. Nemotron heeft 3B active params, Gemma 4B active params. Bij single-user helpt dat hard. Bij multi-user schuift de bottleneck richting geheugen-bandwidth en scheduling, en dan wordt het verschil kleiner.

Wat dit betekent voor on-prem AI

Mijn default keuze voor deze Spark is NVFP4. Niet omdat 4 bit principieel mooier is, maar omdat de cijfers bij deze workloads het dragen: hoogste throughput, snelste mediaan, laagste TPOT, kleinste footprint.

Ik kies FP8 wanneer tail-latency belangrijker is dan mediaan. Denk aan een UI waar je wil kunnen zeggen dat 99 procent van de requests binnen een bepaalde grens start. In Run H, I en J wint FP8 consequent op P99 TTFT.

Ik kies BF16 alleen nog als baseline of voor accuracy-kritische validatie. Niet als productie-default. Daarvoor is het op de Spark te duur: ongeveer drie keer zoveel geheugen als NVFP4 en grofweg de helft van de snelheid.

Voor een 25-persoons-kantoor met chat- en RAG-achtige workload zou ik NVFP4 draaien, met een eigen eval-suite ernaast. Voor een externe chatbot met strakke latency-belofte zou ik FP8 testen. Voor BF16 zou ik vooral een korte run bewaren om te zien wat quantization inhoudelijk verandert.

Wat deze runs niet zeggen

Geen accuracy-tests. FP8 en NVFP4 kunnen inhoudelijk afwijken van BF16. Voor productie moet je dat meten op je eigen documenten, je eigen prompts en je eigen fouttolerantie.

Geen multimodal-benchmarks. Nemotron-3-Nano-Omni is multimodal-aware, maar deze runs zijn text-only. Vision en audio blijven hier buiten beeld.

Geen vergelijking met dense modellen. Dit is een MoE-model. Dense modellen voelen anders, vooral bij output-snelheid en hoe vLLM ermee omgaat.

Geen definitieve scheduler-conclusie. De FP8-vs-NVFP4-tail is interessant genoeg om apart te testen met andere batching- en scheduling-instellingen.

Waar ik land

De precisie-keuze is geen detail. Op de Spark bepaalt hij of dezelfde machine voelt als een lokaal experiment of als iets dat je aan collega's kunt geven zonder elke vijf minuten uitleg te moeten geven.

NVFP4 verdubbelt in veel runs de bruikbare ervaring ten opzichte van BF16. FP8 is minder spectaculair, maar voorspelbaarder in de tail. BF16 blijft nuttig als referentiepunt, niet als eindstation.

De praktische les uit deze drie posts samen: volg de vendor recipes, draai de stable image en meet je eigen workload. Niet zelf knutselen tenzij je daar een goede reden voor hebt. Ik had bij Gemma een reden. Achteraf was hij middelmatig.

Gemma-4 op de DGX Spark: de prijs van context

2026-05-01T00:00:00.000Z

Ik wilde weten hoe goed een DGX Spark zich houdt als lokale AI-machine voor een kantooromgeving.

Niet theoretisch. Gewoon: Gemma-4-26B-A4B-it laden in vLLM, llama-benchy ertegenaan, context windows groter maken, output langer, concurrency omhoog, multi-turn erbij, en kijken waar het prettig blijft en waar de wachttijd pijn gaat doen. En toen dat verhaal zich begon af te tekenen kwam er een tweede vraag: wat als ik niet meer in lockstep test, maar verzoeken organisch laat aankomen zoals in een echt kantoor? Daarvoor pakte ik vLLM's eigen benchmark-suite erbij, die wel doet wat llama-benchy niet doet: Poisson-aankomsten, percentielen, echte conversation-data. Hoe ik dit allemaal meet staat in de methodologie.

De korte versie: voor normaal kantoorgebruik ziet dit er goed uit. Korte tot middelgrote prompts, langere outputs, en zelfs gesprekken over meerdere beurten blijven snel aanvoelen, ook met tien gebruikers tegelijk. Bij grote context windows wordt niet tokens per seconde het probleem, maar hoe lang iemand naar een leeg chatvenster kijkt voordat de eerste token komt. En als je de machine echt overbelast, schaalt 'ie niet, hij queue't.

Dat maakt dit geen "kan de DGX Spark het wel of niet"-verhaal. Het maakt het een workload-verhaal. Negen tests, twee methodes, één machine. Het is een van de build-logs onder de gids LLMs draaien op de DGX Spark.

Waarom deze test

Bij on-prem AI praat je al snel over privacy, data dichterbij houden en minder afhankelijk zijn van hosted modellen. Dat klopt allemaal, maar uiteindelijk komt er een plattere vraag achteraan.

Kan de machine het aan?

Een lokaal model dat één demo-prompt netjes beantwoordt is leuk. Maar productie lijkt daar zelden op. Daar heb je meerdere gebruikers, grotere context, agent-flows, tool-calls, retries en soms iemand die een halve roman in een ticket plakt.

Daarom wilde ik niet alleen tokens per seconde meten bij één prompt. Ik wilde zien wat er gebeurt als je de machine vanuit verschillende hoeken belast: van "tien gebruikers, korte prompts, lange antwoorden" tot "tien gebruikers, gesprekken van vijf beurten, groeiend geheugen" tot "verzoeken die organisch aankomen zoals in een echt kantoor, niet allemaal tegelijk en niet allemaal hetzelfde formaat".

Voor deze benchmarks testte ik één model:

google/gemma-4-26B-A4B-it
BF16
DGX Spark, NVIDIA GB10, 128 GB unified memory
vLLM als OpenAI-compatible endpoint

Dense komt later. MoE vs dense ook. Dit stuk gaat alleen over Gemma-4-26B-A4B-it op de DGX Spark. Deze run draait op BF16; wat er met dezelfde Gemma-4 gebeurt als je naar NVFP4 quantiseert is een apart verhaal.

De verwachting vooraf

Mijn verwachting was simpel: MoE zou redelijk goed blijven bij concurrent requests, maar ik dacht dat de DGX Spark sneller tegen zijn grenzen zou lopen zodra de context groot werd.

Vooral bij 25k context.

Context is duur. Je betaalt niet alleen voor de prompt die binnenkomt, maar ook voor de KV-cache die vLLM moet bijhouden. Als je dat vermenigvuldigt met meerdere gebruikers, wordt het ineens een geheugenvraagstuk én een wachtrijvraagstuk.

Ik was benieuwd naar vijf dingen:

blijft decode nog bruikbaar als context groeit?
hoeveel doet prefill met de tijd tot de eerste token?
wat gebeurt er als de prompt kort is, maar de output lang?
hoe gedraagt het zich bij multi-turn gesprekken, waar context per beurt aandikt?
en (pas later toegevoegd) hoe ziet dat er allemaal uit als verzoeken niet in lockstep komen, maar organisch?

Die laatste vraag bleek de helft van het verhaal.

De testopstelling

De server draaide in Docker met de officiële vLLM-image:

docker run -d --name vllm-bench \
  --gpus all --ipc=host \
  -v appliance_hf-cache:/root/.cache/huggingface \
  -p 8000:8000 \
  vllm/vllm-openai:v0.20.1 \
  --model google/gemma-4-26B-A4B-it \
  --served-model-name gemma-4-26b-a4b-bf16 \
  --max-model-len 131072 \
  --gpu-memory-utilization 0.95 \
  --kv-cache-dtype fp8 \
  --limit-mm-per-prompt '{"image":0,"audio":0}' \
  --async-scheduling \
  --no-enable-prefix-caching \
  --host 0.0.0.0 \
  --port 8000

Een paar details doen ertoe.

Prefix caching staat bewust uit. Ik wilde eerst de rauwe prefill-kosten zien, niet een benchmark die mooier wordt omdat prompts op elkaar lijken.

De KV-cache draait op fp8. Zonder dat wordt 128k context met meerdere requests tegelijk al snel een geheugenoefening waar je weinig aan hebt.

Alle negen tests hieronder gebruiken precies deze server-config. Geen herstart, geen tussentijdse aanpassing. Wat varieert is de workload: prompt-grootte, output-grootte, concurrency, depth, en bij de open-loop tests ook arrival rate en burstiness.

Wat de Spark hiervan maakt:

Onderdeel	Waarde
Model weights (BF16)	~48 GB
KV-cache headroom (fp8)	~65 GB
Theoretisch parallel @ 128k	~4 requests
Theoretisch parallel @ 8k	~50 requests

Bij volle context per request is het geheugen krap. In de praktijk gebruikt geen enkele test 128k tegelijk per gebruiker, dus de bottleneck verschuift naar prefill-compute en scheduler-batching. Dat zien we hieronder terug.

Run A: context groter maken

De eerste run liet de context groeien van 4k naar 25k. Concurrency ging mee van 1 naar 5 en 10. Closed-loop, dus N gebruikers in lockstep.

uvx llama-benchy \
  --base-url http://localhost:8000/v1 \
  --model gemma-4-26b-a4b-bf16 \
  --pp 4096 8192 16384 25000 \
  --tg 256 \
  --depth 0 \
  --concurrency 1 5 10 \
  --runs 3 \
  --latency-mode generation \
  --format md

pp is prefill, oftewel hoeveel prompttokens erin gaan. tg is decode, oftewel hoeveel tokens het model daarna genereert. llama-benchy rapporteert mean ± stddev. Geen p95. Dat is belangrijk om te onthouden, want bij latency wil je jezelf anders al snel rijk rekenen.

Dit is de samenvatting uit Run A:

Context	Users	Prefill total	Decode/user	Decode total	TTFT
4k	1	3677.85 ± 1259.27 tok/s	24.08 ± 0.02 tok/s	24.08 ± 0.02 tok/s	1.37 ± 0.52s
4k	5	5722.96 ± 94.70 tok/s	12.55 ± 0.49 tok/s	57.07 ± 2.64 tok/s	2.29 ± 0.82s
4k	10	5475.53 ± 888.14 tok/s	9.48 ± 0.73 tok/s	84.40 ± 3.08 tok/s	4.46 ± 2.38s
8k	1	6121.87 ± 62.31 tok/s	23.69 ± 0.02 tok/s	23.69 ± 0.02 tok/s	1.39 ± 0.01s
8k	5	5444.57 ± 12.82 tok/s	11.48 ± 0.92 tok/s	49.42 ± 1.60 tok/s	4.34 ± 1.91s
8k	10	5478.98 ± 11.48 tok/s	8.52 ± 1.10 tok/s	67.72 ± 0.91 tok/s	7.99 ± 4.03s
16k	1	4607.64 ± 23.05 tok/s	23.34 ± 0.05 tok/s	23.34 ± 0.05 tok/s	3.42 ± 0.00s
16k	5	4466.35 ± 27.19 tok/s	10.05 ± 1.75 tok/s	38.41 ± 0.12 tok/s	10.43 ± 4.69s
16k	10	4453.92 ± 18.19 tok/s	6.79 ± 1.62 tok/s	45.76 ± 0.43 tok/s	18.92 ± 9.43s
25k	1	3621.25 ± 18.50 tok/s	22.75 ± 0.08 tok/s	22.75 ± 0.08 tok/s	6.39 ± 0.05s
25k	5	3561.78 ± 9.23 tok/s	8.46 ± 2.36 tok/s	27.93 ± 0.08 tok/s	19.63 ± 8.87s
25k	10	3565.35 ± 8.21 tok/s	5.40 ± 2.00 tok/s	30.73 ± 0.12 tok/s	35.67 ± 18.00s

<figure class="breakout-wide"> <img src="/blog/gemma-4-dgx-spark/run-a-ttfr.webp" width="1425" height="878" loading="lazy" decoding="async" alt="Run A: TTFT vs context, lijn per gelijktijdige users (1, 5, 10). TTFT loopt op van ~1.4 seconden bij 4k tot 36 seconden bij 25k context met 10 users." /> <figcaption>Run A: Wachttijd voor de eerste token, per gelijktijdige users. Verdubbel de prompt en je verdubbelt de wachttijd.</figcaption> </figure>

<figure class="breakout-wide"> <img src="/blog/gemma-4-dgx-spark/run-a-decode.webp" width="1425" height="878" loading="lazy" decoding="async" alt="Run A: Decode-snelheid per gebruiker vs context. Bij c=1 blijft decode tussen 22.7 en 24.1 tokens per seconde, bij c=10 zakt het van 9.5 naar 5.4 tokens per seconde." /> <figcaption>Run A: Decode per gebruiker. Bij één gebruiker blijft het bijna vlak; pas met meerdere users en grote context valt het in.</figcaption> </figure>

Run B: 25k context vasthouden, concurrency omhoog

Daarna draaide ik dezelfde 25k-context zwaarder. Niet meer variëren in context, alleen gebruikers erbij.

uvx llama-benchy \
  --base-url http://localhost:8000/v1 \
  --model gemma-4-26b-a4b-bf16 \
  --pp 25000 \
  --tg 256 \
  --depth 0 \
  --concurrency 5 10 20 \
  --runs 3 \
  --latency-mode generation \
  --exit-on-first-fail \
  --format md

Geen OOM. Geen crash. De DGX Spark overleefde 20 gelijktijdige requests met 25k context.

Users	Prefill total	Decode/user	Decode total	TTFT
5	3559.17 ± 6.72 tok/s	8.51 ± 2.40 tok/s	27.88 ± 0.05 tok/s	19.86 ± 9.00s
10	3569.77 ± 2.99 tok/s	5.37 ± 1.99 tok/s	30.68 ± 0.09 tok/s	35.44 ± 17.95s
20	3563.64 ± 8.78 tok/s	3.16 ± 1.41 tok/s	32.26 ± 0.10 tok/s	67.37 ± 36.44s

<figure class="breakout-wide"> <img src="/blog/gemma-4-dgx-spark/run-b-prefill-wall.webp" width="1522" height="843" loading="lazy" decoding="async" alt="Run B: TTFT groeit lineair met concurrency: 19.9s bij 5 users, 35.4s bij 10, 67.4s bij 20. Aggregate decode plakt rond 30 tok/s." /> <figcaption>Run B: Aggregate decode plakt op ~30 tok/s; alle extra wachttijd gaat in TTFT zitten.</figcaption> </figure>

Dit is de stress-rand van de benchmark. Aggregate decode plakt rond 30 tok/s, ongeacht of je 5, 10 of 20 gebruikers neerzet. Per gebruiker zakt het van 8.51 naar 3.16 tok/s. Maar het echte probleem is TTFT: bij 20 gebruikers wacht de gemiddelde request 67 seconden voordat de eerste token komt. De server is dan niet stuk. De workload past alleen niet meer bij een realtime chatverwachting.

Run C: korte prompt, lange output

Run C draaide de vorm om. Niet 25k context met korte output, maar 1024 prompttokens en 1024 outputtokens.

Users	Prefill total	Decode/user	Decode total	TTFT
1	4627.12 ± 374.91 tok/s	23.86 ± 0.03 tok/s	23.86 ± 0.03 tok/s	0.31 ± 0.02s
5	5701.55 ± 561.36 tok/s	13.59 ± 1.05 tok/s	54.67 ± 4.90 tok/s	0.76 ± 0.11s
10	6346.87 ± 64.52 tok/s	10.92 ± 0.73 tok/s	86.46 ± 1.74 tok/s	1.26 ± 0.40s

<figure class="breakout-wide"> <img src="/blog/gemma-4-dgx-spark/run-c-grouped.webp" width="1227" height="777" loading="lazy" decoding="async" alt="Run C: per-user decode zakt van 23.9 (c=1) naar 10.9 (c=10), aggregate decode loopt op naar 86.5 tok/s." /> <figcaption>Run C: korte prompt, lange output. Aggregate decode schaalt netjes naar 86 tok/s, per-user blijft ruim leesbaar.</figcaption> </figure>

Bij tien gebruikers tegelijk blijft TTFT op 1.3 seconden. Dat voelt als chat.

Run G: nóg langere output

Run A, B en C lieten genoeg zien om het verhaal "decode is stabiel, prefill bepaalt de wachttijd" plausibel te maken. Maar er bleef één scenario open: wat als de output nog véél langer is? Een agent die code genereert. Een tool-call met gestructureerde output. Een lange samenvatting.

Users	Prefill total	Decode/user	Decode total	TTFT
1	1993.94 ± 262.05 tok/s	24.17 ± 0.02 tok/s	24.17 ± 0.02 tok/s	0.24 ± 0.01s
5	3048.28 ± 496.15 tok/s	14.32 ± 2.18 tok/s	46.11 ± 11.57 tok/s	0.38 ± 0.07s
10	4800.80 ± 50.75 tok/s	11.75 ± 0.68 tok/s	83.77 ± 4.04 tok/s	0.48 ± 0.01s

<figure class="breakout-wide"> <img src="/blog/gemma-4-dgx-spark/run-g-grouped.webp" width="1227" height="777" loading="lazy" decoding="async" alt="Run G: per-user decode 24.2 (c=1), 14.3 (c=5), 11.8 (c=10); aggregate 24.2, 46.1, 83.8 tok/s." /> <figcaption>Run G: 4k output: lange generaties zijn alleen langer, niet trager. Per-user staat dichtbij Run C.</figcaption> </figure>

Decode/user over 4096 tokens zakt nauwelijks weg vergeleken met C's 1024 tokens. Bij c=1 is het 24.17 (G) vs 23.86 (C). Bij c=10 is het 11.75 (G) vs 10.92 (C). Lange generaties compounderen niet, ze duren alleen proportioneel langer. En TTFT is hier het laagst: onder een halve seconde bij tien gebruikers tegelijk.

Run F: middelgrote context, meer gebruikers

Tussen Run C (1k context) en Run B (25k context) zat een gat dat dichter bij realiteit ligt. Een typische RAG-flow met vier chunks van ~2k tokens komt uit op zo'n 8k.

Users	Prefill total	Decode/user	Decode total	TTFT
5	5439.51 ± 32.60 tok/s	12.11 ± 0.51 tok/s	55.21 ± 1.49 tok/s	4.32 ± 1.90s
10	5466.71 ± 15.65 tok/s	9.31 ± 0.77 tok/s	78.36 ± 1.61 tok/s	7.99 ± 4.02s
20	5532.74 ± 5.39 tok/s	6.05 ± 0.62 tok/s	97.35 ± 3.50 tok/s	14.61 ± 7.72s

<figure class="breakout-wide"> <img src="/blog/gemma-4-dgx-spark/run-f-ttfr.webp" width="1522" height="843" loading="lazy" decoding="async" alt="Run F: 8k context. TTFT loopt van 4.3s (c=5) naar 8.0s (c=10) naar 14.6s (c=20); aggregate decode haalt 97.4 tok/s." /> <figcaption>Run F: 8k context. TTFT groeit lineair met concurrency, aggregate decode blijft schalen tot bijna 100 tok/s.</figcaption> </figure>

Drie observaties.

Prefill-throughput zit op een vlakke 5.5k tok/s, ongeacht of het 5, 10 of 20 gebruikers zijn. De machine is bij 8k context al gesatureerd op prefill-niveau. Aggregate decode blijft schalen: in Run B (25k) plateauerde dit op ~30 t/s, hier loopt het door tot 97.4 t/s. En het belangrijkste: TTFT bij 8k context is grofweg een kwart van wat het bij 25k is. Dezelfde concurrency, dezelfde machine, andere prompt-grootte.

Run E: multi-turn als realistisch kantoorwerk

--depth 4 betekent: per request vijf turns achter elkaar (initieel + vier vervolgvragen). Concurrency op 10 betekent: tien zulke gesprekken parallel.

Users	Prefill total	Decode/user	Decode total	TTFT
1	4716.21 ± 542.88 tok/s	23.97 ± 0.10 tok/s	23.97 ± 0.10 tok/s	0.53 ± 0.06s
5	5693.39 ± 128.08 tok/s	13.07 ± 0.16 tok/s	59.48 ± 2.26 tok/s	1.32 ± 0.39s
10	6096.81 ± 56.92 tok/s	10.43 ± 0.35 tok/s	92.42 ± 3.33 tok/s	2.13 ± 0.83s

<figure class="breakout-wide"> <img src="/blog/gemma-4-dgx-spark/run-e-multiturn.webp" width="1242" height="777" loading="lazy" decoding="async" alt="Run E: multi-turn. Per-user 24.0/13.1/10.4 tok/s, aggregate 24.0/59.5/92.4 tok/s, hoogste aggregate van alle closed-loop runs." /> <figcaption>Run E: multi-turn (depth = 4) bij 2k startcontext. Aggregate van 92 tok/s is het hoogste cijfer in alle zes closed-loop runs.</figcaption> </figure>

Drie dingen vielen op die ik vooraf niet had verwacht.

Per-user decode bij multi-turn is identiek aan single-turn. Multi-turn maakt de tokens niet langzamer, alleen het aantal prefills neemt toe. Aggregate decode op c=10 is 92.42 t/s, het hoogste van élke closed-loop run. vLLM krijgt bij multi-turn een dichtere stroom afhankelijke requests aangeleverd, en kan die efficiënter batchen dan tien losse single-shot prompts. En TTFT op c=10 is gemiddeld 2.13 seconden over alle vijf turns. Onder drie seconden voelt nog steeds als chat.

Wat de zes closed-loop runs samen laten zien

Eén tabel die alles bij c=10 naast elkaar zet:

Run	Prompt	Output	Depth	TTFT (c=10)	Decode/user (c=10)	Aggregate decode (c=10)
G	256	4096	0	0.48s	11.75 t/s	83.8 t/s
C	1024	1024	0	1.26s	10.92 t/s	86.5 t/s
E	2048	512	4	2.13s	10.43 t/s	92.4 t/s
F	8192	512	0	7.99s	9.31 t/s	78.4 t/s
A	16384	256	0	18.92s	6.79 t/s	45.8 t/s
A/B	25000	256	0	35.67s	5.40 t/s	30.7 t/s

<figure class="breakout-wide"> <img src="/blog/gemma-4-dgx-spark/summary-c10.webp" width="1569" height="944" loading="lazy" decoding="async" alt="Scatter van alle zes closed-loop runs bij c=10. Y-as decode/user (5 tot 12 tok/s), X-as TTFT logaritmisch (0.5s tot 49s). G en C linksboven, A-25k rechtsonder." /> <figcaption>Alle zes closed-loop runs bij 10 gelijktijdige users. Decode per user beweegt nauwelijks tot 8k context. TTFT beweegt overal.</figcaption> </figure>

Twee patronen springen eruit.

Decode/user beweegt nauwelijks tot 8k context. Tussen Run G en Run F zit een factor 32 in prompt-grootte en een factor 8 in output-grootte. Toch zit decode/user daar tussen 9.3 en 11.8 tok/s. Pas bij 16k+ valt die strook in elkaar.

TTFT beweegt overal en is bijna een functie van prompt-grootte alleen. Verdubbel de prompt en de TTFT verdubbelt grofweg mee. Output-grootte en depth doen er voor TTFT bijna niets toe.

Dat is de closed-loop conclusie. Hij klopt, en hij vertelt een echt deel van het verhaal. Maar er zit een gat in.

Maar dit zijn synthetische tests

De zes runs hierboven testen capaciteit. Plafonds. Allemaal in dezelfde vorm: N gebruikers in lockstep, allemaal hetzelfde prompt-formaat, allemaal tegelijk verzendknopjes indrukkend. Dat is een prima manier om te meten waar het breekt. Het is een slechte manier om te meten hoe een echt kantoor voelt.

Want een echt kantoor heeft 25 medewerkers waarvan er gemiddeld een paar tegelijk wat doen. De ene collega vraagt een korte vraag. De andere is mid-RAG met 8k context. De derde zit in turn 4 van een gesprek. En verzoeken arriveren niet in lockstep. Ze arriveren als een Poisson-proces met af en toe een burst, omdat iemand net een mail af heeft en drie collega's tegelijk aan koffie willen.

Dat is wat vLLM's eigen vllm bench serve wel kan en llama-benchy niet:

Open-loop met arrival rate. Verzoeken dispatchen volgens een Poisson- of Gamma-distributie, in plaats van lockstep.
Percentielen. P50, P90, P95, P99 op TTFT, TPOT (time per output token), ITL (inter-token latency) en E2E. Geen mean ± stddev meer.
Realistische datasets. ShareGPT replay van 94k+ echte gesprekken met natuurlijk variërende prompt-lengtes en multi-turn structuur.
Mixed workloads. Prompts uit een distributie sampelen in plaats van één vaste shape testen.

Drie tests hieronder, dezelfde server (geen herstart), maar met die andere bril op.

Test H: realistische kantoor-baseline

Het scenario: 25 mensen actief gemiddeld, elk stuurt zo'n keer per 1–2 minuten een prompt, prompts variëren sterk in lengte. Aankomsten zijn licht clumpy.

docker exec vllm-bench vllm bench serve \
  --backend openai-chat \
  --base-url http://localhost:8000 \
  --endpoint /v1/chat/completions \
  --model google/gemma-4-26B-A4B-it \
  --tokenizer google/gemma-4-26B-A4B-it \
  --served-model-name gemma-4-26b-a4b-bf16 \
  --dataset-name random \
  --random-input-len 4000 \
  --random-output-len 500 \
  --random-range-ratio 0.9 \
  --num-prompts 200 \
  --request-rate 0.3 \
  --burstiness 0.7 \
  --percentile-metrics ttft,tpot,itl,e2el \
  --metric-percentiles 50,90,95,99 \
  --seed 42

Met --random-range-ratio 0.9 variëren input-lengtes van 399 tot 7600 tokens, outputs van 49 tot 950. --burstiness 0.7 is iets clumpier dan pure Poisson. Mensen drukken vaak in burstjes op enter, niet als een metronoom. Target rate van 0.3 req/s = ~18 prompts/min over 25 gebruikers.

Metric	Value
Successful requests	200 / 200
Achieved RPS	0.27 (target 0.30)
Peak concurrent requests	36
Total token throughput	1215 tok/s

	Mean	P50	P90	P95	P99
TTFT (ms)	1395	1286	2284	2644	3316
TPOT (ms)	177	182	193	202	214
E2E (ms)	85921	85306	150192	162375	171351

Mediaan-gebruiker krijgt eerste token in 1.29s. Voelt nog als chat. De tail blijft binnen de perken: P99 wacht 3.3 seconden, ruim twee keer het gemiddelde.

En kijk naar peak concurrent: 36. Bij target rate van slechts 0.3 req/s. Geen enkele closed-loop run zat in die buurt. De Poisson-burstiness alleen al, gecombineerd met gemiddelde response-tijd van ~86 seconden, zorgt voor pieken die heftiger zijn dan welke Run B-stress-test ook had. Dat is het ding dat closed-loop letterlijk niet kan laten zien.

Test I: echte gesprekken (ShareGPT replay)

Identieke aankomst-pattern als Test H, maar nu met 250 echte multi-turn gesprekken uit ShareGPT V3 als prompts. Sommige zijn 1 turn van 200 tokens, andere zijn 15 turns met steeds groeiende context.

docker exec vllm-bench vllm bench serve \
  ... \
  --dataset-name sharegpt \
  --dataset-path /tmp/ShareGPT_V3.json \
  --num-prompts 250 \
  --request-rate 0.3 \
  --burstiness 0.7

Metric	Value
Successful requests	250 / 250
Achieved RPS	0.30 (target 0.30)
Peak concurrent requests	17
Total token throughput	133 tok/s

	Mean	P50	P90	P95	P99
TTFT (ms)	376	353	469	509	637
TPOT (ms)	93	95	117	123	135
E2E (ms)	19600	10923	49525	63036	82596

Dit is een ander universum dan Test H. TTFT P99 = 637 ms. 99% van de gebruikers ziet binnen 650 milliseconden de eerste token. Dat is écht chat-snelheid.

Identieke aankomst-pattern als Test H, totaal andere ervaring. Het verschil zit volledig in prompt-grootte: ShareGPT-gesprekken zijn gemiddeld 228 tokens, niet 4000. Korte prompt = goedkope prefill = geen queue-druk = sub-seconde TTFT.

Metric	Test H (random 4k)	Test I (ShareGPT)
Achieved RPS	0.27	0.30
Peak concurrent	36	17
TTFT P50	1286 ms	353 ms
TTFT P99	3316 ms	637 ms
TPOT P50	182 ms	95 ms

Dit is ook een waarschuwing: de synthetische workload van Test H overdrijft hoe zwaar een gemiddeld kantoor-prompt is. Real-world conversations zijn lichter dan onze 4k random baseline, dus de praktijk-cijfers zitten vermoedelijk dichter bij Test I dan bij Test H.

Test J: maandagochtend-piek

Wat als iedereen tegelijk binnenkomt en op verzendknopjes drukt? Vijfvoudige load, max 25 gelijktijdige requests om een echt kantoor te modelleren.

docker exec vllm-bench vllm bench serve \
  ... \
  --dataset-name random \
  --random-input-len 4000 \
  --random-output-len 500 \
  --random-range-ratio 0.9 \
  --num-prompts 300 \
  --request-rate 1.5 \
  --burstiness 1.0 \
  --max-concurrency 25

Metric	Value
Successful requests	300 / 300
Configured RPS	1.50
Achieved RPS	0.26
Peak concurrent requests	27
Total token throughput	1173 tok/s

	Mean	P50	P90	P95	P99
TTFT (ms)	1370	1132	1932	2961	6157
TPOT (ms)	185	187	195	199	221
E2E (ms)	92752	91099	165179	172073	179139

Dit is het sleutelcijfer: achieved rate 0.26 bij target 1.5. Het systeem is bijna 6× throttled. Niet omdat 'ie crasht (alle 300 requests slagen, geen failures), maar omdat de queue zich vult tot 25 en daar verzoeken vasthoudt totdat er ruimte is.

Vergelijk Test H (target 0.3) en Test J (target 1.5):

Metric	Test H (0.3 rps)	Test J (1.5 rps)
Achieved RPS	0.27	0.26
TTFT P50	1286 ms	1132 ms
TTFT P95	2644 ms	2961 ms
TTFT P99	3316 ms	6157 ms
TPOT P50	182 ms	187 ms

Mediaan-ervaring is bij Test J zelfs iets beter dan bij Test H (1.13s vs 1.29s). De cap zorgt voor een gelijkmatigere stroom. Maar de tail is dramatisch erger: P99 verdubbelt van 3.3s naar 6.2s.

<figure class="breakout-wide"> <img src="/blog/gemma-4-dgx-spark/open-loop-ttft.webp" width="1425" height="882" loading="lazy" decoding="async" alt="Open-loop TTFT-percentielen voor H (random 4k 0.3 rps), I (ShareGPT 0.3 rps) en J (random 4k 1.5 rps). I blijft sub-seconde overal; H loopt op tot 6.4s P99; J schiet door naar 14.8s P99." /> <figcaption>Open-loop TTFT-percentielen. Mediaan zegt weinig; de tail vertelt waar overload pijn doet.</figcaption> </figure>

De Spark schaalt niet onder oversubscribe, hij queue't. Dat is goed nieuws: graceful degradation in plaats van crashes. Voor on-prem AI is dat eigenlijk de beste failure-mode.

Wat closed-loop verbergt, wat open-loop overdrijft

De twee methodes vertellen elk een ander deel van het verhaal. Allebei waar, allebei onvolledig.

Closed-loop onderschat queue-diepte.

In Run F testte ik c=10 als "tien gebruikers tegelijk". Dat klinkt als een redelijk drukke kantoorsituatie. Maar Test H toont dat een organische 0.3 req/s arrival rate al genoeg is om pieken van 36 gelijktijdige requests te produceren. De closed-loop "10 gebruikers" claim is dus optimistischer dan de praktijk laat zien.

Open-loop met synthetisch overdrijft de werkelijke load.

Tegelijk: Test H gebruikt random 4k-prompts. Een echt kantoor stelt geen 25 gemiddelde 4k-prompts per minuut. ShareGPT (Test I) is een veel betere proxy voor "wat mensen typen", gemiddeld 228 tokens. Bij die workload-shape is peak concurrent 17 in plaats van 36, en P99 TTFT 637ms in plaats van 3.3s.

De praktijk zit dus tussen Run F en Test I in:

Bron	TTFT (P50 of mean)	Peak concurrent
Run F (closed-loop, 10 users, 8k)	7.99 s	10
Test H (open-loop, 0.3 rps, 4k random)	1.29 s P50 / 3.3s P99	36
Test I (open-loop, 0.3 rps, ShareGPT)	0.35 s P50 / 0.64s P99	17
Test J (open-loop, 1.5 rps, 4k random, cap 25)	1.13 s P50 / 6.2s P99	27

Voor een kantoor met realistische prompts en realistische arrival pattern is Test I het dichtst bij wat mensen voelen. Voor capaciteitsplanning ("wat als iedereen tegelijk een 8k RAG-vraag stelt?") is Run F het dichtst bij wat de machine kan verstouwen.

De tail vertelt wat het gemiddelde verbergt

llama-benchy gaf alleen mean ± stddev. Dat klinkt als veel informatie, maar het verbergt het deel dat er voor je gebruikers het meest toe doet: de tail.

Test I's mean TTFT is 376ms. Klinkt prima. Maar wat zegt dat over de 1% gebruikers waar de queue net pikte? Niets. Daarvoor heb je P99 nodig, en die zit op 637ms. In dit geval geen probleem (allebei sub-seconde), maar het principe dat je moet kennen.

Test H's mean TTFT is 1395ms. P99 is 3316ms. Ruim twee keer slechter dan het gemiddelde voor de unlucky 1%.

Test J's mean TTFT is 1370ms. P99 is 6157ms. Ruim vier keer het gemiddelde.

Voor SLA-beslissingen ("ons systeem geeft binnen 3 seconden antwoord aan 95% van requests") heb je deze percentielen nodig. Mean ± stddev kan een SLA suggereren die je niet haalt op de momenten dat het er het meest toe doet, namelijk wanneer er druk is.

Dat is waarom de blog niet alleen op llama-benchy kan landen. Capaciteit testen is één ding. Tail-latency rapporteren is een ander.

Decode is het probleem niet

Bij één gebruiker blijft decode bijna vlak.

4k context haalt 24.08 tok/s per gebruiker. 25k context haalt 22.75 tok/s. 4096 outputtokens (Run G, c=1) haalt 24.17 tok/s. Multi-turn met depth 4 (Run E, c=1) haalt 23.97 tok/s. Vier verschillende workloads, allemaal binnen 6 procent van elkaar.

Bij tien gebruikers tegelijk gebeurt iets vergelijkbaars, alleen op een lagere lijn. Run G: 11.75 tok/s/user. Run C: 10.92. Run E: 10.43. Run F: 9.31. En in de open-loop tests: Test I geeft TPOT P50 = 95ms = ~10.5 tok/s/user. Test H en J geven TPOT P50 = ~185ms = ~5.4 tok/s/user (omdat pieken daar 25+ concurrent halen).

Kortom: per-token decode-snelheid is een functie van gemiddelde concurrent load, niet van prompt-lengte, output-lengte, multi-turn, of arrival pattern. Pas bij 16k+ context gecombineerd met meerdere users (Run A) zakt het echt door 7 t/s/user.

Concurrency op zichzelf is niet het probleem. Lange output ook niet. Multi-turn ook niet. Pas grote context tegelijk met meerdere gebruikers eet decode op.

Prefill is de muur

Wat je als eerste voelt, is wachten.

Bij één gebruiker op 25k context duurt het ruim 6 seconden voordat de eerste response komt. Bij vijf gebruikers wordt dat 19.9 seconden. Bij tien wordt het 35.4 seconden. Bij twintig wordt het 67.4 seconden.

Run F laat zien dat dit lineair is in zowel concurrency als context. 8k context bij 20 gebruikers geeft 14.6 seconden, ongeveer een kwart van de 67.4 seconden bij 25k context, voor dezelfde concurrency. Halveer de prompt, halveer de wachttijd.

En Test J laat zien: zodra je het systeem voorbij zijn doorvoer-plafond pusht, gaat al die extra wachttijd in de tail zitten. Mediaan TTFT blijft stabiel rond 1.1-1.3s, maar P99 schiet naar 6 seconden. De pijn van overbelasting valt op een kleine groep, niet op iedereen.

Daar zit de echte grens.

Niet: kan de DGX Spark tokens genereren? Ja.

Niet: kan de KV-cache 20 × 25k aan? Ook ja.

Niet: stopt het bij overload? Nee, het queue't netjes door.

Maar: voelt dit nog als chat? Niet voor 25k. Voor 8k al wel grensgebied. Voor 2k met multi-turn gewoon prima. Voor ShareGPT-realistische prompts met 25 gebruikers organisch verspreid: glashelder ja.

Waar dit wel past

Deze benchmarks maken de on-prem keuze concreter.

Ja voor een kantooromgeving waar 10 tot 25 mensen verspreid over de dag lokale AI gebruiken. Test I is het bewijs: 250 echte ShareGPT-gesprekken, 0.3 req/s aankomst-rate, P99 TTFT van 637ms. Mediaan-gebruiker ziet de eerste token in 353 milliseconden. Dat is precies het kantoor-scenario, en dit is wat het voelt.

Ja voor RAG-flows met middelgrote context. Run F gaf de cijfers vooraf: 8k prompt, 10 users, 8s TTFT, 9.3 tok/s streamen. Test H bevestigt dat de open-loop variant nog steeds werkbaar is: P99 TTFT 3.3s. Niet realtime, wel binnen wachtbare grenzen.

Ja voor agents en code-generatie. Run G is de bevestiging: korte instructie, 4k+ tokens output, tien parallelle taken. TTFT onder een halve seconde, 11.75 tok/s/user.

Ja voor multi-turn gesprekken. Run E geeft 2.1s TTFT bij 10 parallelle 5-turn gesprekken. Decode hetzelfde als single-turn.

Voorzichtig bij 5+ gebruikers met 25k context tegelijk. 19.9 seconden TTFT is geen chat meer, wel werkbaar voor analyses.

Voorzichtig met SLA-claims op basis van gemiddeldes. Test H's mean TTFT van 1.4s zou als acceptabel kunnen klinken, maar P99 zit op 3.3s. Beslissingen op basis van percentielen, niet op mean.

Nee voor support-chat waarbij tien tot twintig gebruikers tegelijk 25k context per sessie sturen en allemaal realtime antwoord verwachten. Of: support-chat onder Test J-achtige load (1.5 rps van 4k-prompts). Dat kan technisch draaien (geen failures), maar P99 TTFT van 6 seconden is een grensgeval voor chat.

Wat deze tests niet zeggen

Dit is geen MoE-vs-dense vergelijking. Dat wil ik apart testen, en dan niet alleen met throughput. Als je MoE en dense vergelijkt, moet je ook prompts testen: samenvatten, codevragen, tool-keuze, ticket-classificatie, lang contextstuk met vervolgstappen. Anders meet je alleen hoe hard de motor draait, niet of hij de goede kant op rijdt.

Dit is ook geen test met prefix caching aan. Dat is bewust. Ik wilde de rauwe prefill-kosten zien, niet een benchmark die mooier wordt omdat prompts op elkaar lijken. In een volgend stuk gaat dat erbij: diezelfde 8k en 25k context-runs en de open-loop tests met --enable-prefix-caching. Mijn vermoeden: Test H en J profiteren matig (random data, weinig overlap), Test I profiteert behoorlijk (echte gesprekken hebben overlappende system prompts en context), en Run F gaat substantieel sneller. Maar dat moet gemeten worden.

Waar ik land

Mijn verwachting vooraf was dat de DGX Spark met dit MoE-model eerder zou vollopen bij grote context windows. Dat gebeurde, maar anders dan ik dacht.

Geheugen was niet de showstopper. Run B haalde 20 gebruikers met 25k context zonder OOM. Test J overleefde 1.5 req/s zonder een enkele failed request. De praktische grens zat altijd in prefill-latency, niet in capaciteit.

En na negen tests blijkt: dat is eigenlijk de enige grens die je voelt.

Decode/user is bijna een constante voor deze machine. Tussen 9 en 12 tokens per seconde bij tien gelijktijdige gebruikers, in zes verschillende closed-loop workloads. In open-loop met realistische ShareGPT-prompts: 10.5 t/s/user. Pas bij 16k context of bij synthetische pieken van 25+ concurrent valt dat onder de 7 t/s.

Wat varieert is hoe lang iemand wacht voordat de tekst begint. Op 256 prompttokens is dat een halve seconde, ook met tien gebruikers. Op 2048 prompttokens met vijf turns gemiddeld 2.1 seconden. Op 8192 prompttokens met tien gebruikers acht seconden. Op 25k met tien gebruikers 35 seconden. Op realistische 0.3 rps ShareGPT-belasting: 353 milliseconden voor de mediaan, 637 milliseconden voor de unlucky 1%.

En zodra je het systeem boven zijn capaciteit duwt, schaalt 'ie niet, hij queue't. Test J liet zien dat 1.5 req/s target wordt gethrottled tot 0.26 achieved, met de pijn volledig in de tail (P99 6.2s) terwijl de mediaan stabiel blijft. Voor on-prem AI is dat de beste failure-mode die je kunt hopen: niemand crasht, sommigen wachten langer.

Dat is geen "kan deze machine het wel of niet". Dat is "kies de workload die past bij wat de gebruiker verwacht, en accepteer dat 1% van de requests een onaangename wachttijd heeft op piekmomenten".

Voor één tot drie gebruikers met grote context is hij bruikbaar. Voor tien gebruikers met middelgrote context is hij prima. Voor tien gebruikers met multi-turn gesprekken is hij eigenlijk op zijn best. Voor een 25-persoons-kantoor met realistische prompts en organische arrival pattern is hij verbluffend goed: sub-seconde TTFT voor 99% van requests, gemeten op echte conversation-data.

Voor agent-flows met lange outputs is hij sterk. Voor twintig gelijktijdige 25k-prompts of voor 1.5 rps oversubscribe is het geen realtime chat meer. Daar moet je queue'en, prefix caching aanzetten, of dat type werk anders routeren.

Twee methodes meten twee dingen. Closed-loop benchmarks tonen wat de machine kán. Open-loop replay toont wat de gebruiker voelt. De DGX Spark is een sterke lokale AI-machine voor kantoorwerk, zolang je weet welke knop bepaalt wat je voelt.

Decode verkoopt de benchmark. Prefill bepaalt de ervaring. En zodra je de plank voorbij gaat, queue't de Spark in plaats van te breken, en dat is het derde cijfer dat een on-prem-keuze moet kunnen lezen.

Ik zette een 24/7 assistent op een Raspberry Pi

2026-05-01T00:00:00.000Z

Ik wilde geen betere chatbot. Ik wilde een agent die uit zichzelf werk kan oppakken: het internet op, tickets lezen, een repo induiken, een eerste voorstel voor code-wijzigingen maken en daarna terugrapporteren waar mijn team toch al werkt.

De ingang moest Slack zijn. Daar zitten de vragen, threads, bestanden en half afgemaakte ideeën. De agent moest tools kunnen gebruiken, bestanden kunnen lezen, branches kunnen klaarzetten en blijven draaien als mijn laptop dichtgaat.

Daarom draait er nu een Raspberry Pi 5 met 4 GB RAM in mijn netwerk. Daarop draait OpenClaw. Slack ervoor, GPT-5.5 erachter, Tailscale als toegangspoort wanneer ik niet thuis ben.

Dat klinkt groter dan het is. De Pi draait geen lokaal taalmodel. OpenClaw gebruikt de Pi als always-on Gateway: de laag die Slack-berichten ontvangt, sessies en workspace-context beheert, een agent-run start, tools beschikbaar maakt en het antwoord weer terugstuurt naar dezelfde thread. Het model draait in deze setup via OpenAI.

Dat onderscheid is belangrijk. Voor volledig lokale inference gebruik ik de DGX Spark, en daar schreef ik eerder over in de quantization-post. Deze Pi is de agent-laag ernaast: altijd aan, bereikbaar in Slack, dicht bij mijn bestanden en workflows.

Het ding dat ik miste

Ik gebruik al genoeg AI-tools. Claude Code voor bouwen. ChatGPT voor losse vragen. Voor klantprojecten werk ik met model-API’s of lokale modellen, afhankelijk van wat de data en infrastructuur toelaten.

De ontbrekende laag zat tussen die tools in: een agent die werk ziet binnenkomen en alvast begint. In Slack kan dat klein starten. Ik typ een rommelige opdracht, de agent leest de repo, pakt de juiste tone-of-voice-regels erbij en komt terug met iets dat ik kan beoordelen.

Publiceren blijft handwerk. Vertrouwen ook. Het eerste voorwerk mag wel automatisch gebeuren.

De richting is groter dan drafts schrijven. Ik wil uiteindelijk een ticket kunnen aanwijzen en zeggen: zoek uit wat hier nodig is. De agent leest de context, checkt documentatie, kijkt in de codebase, stelt een aanpak voor en zet eventueel alvast een branch klaar.

Dat werk blijft vaak liggen omdat het nergens netjes past. Te klein voor een sprint. Te groot om “even tussendoor” te doen. Voor je het weet staat zo’n ticket een week later nog open met dezelfde drie vage opmerkingen eronder.

Wat er op de Pi draait

De basis is klein:

Raspberry Pi 5, 4 GB RAM
OpenClaw Gateway lokaal op de Pi
OpenAI GPT-5.5 als model in deze setup
Slack als interface
Tailscale voor remote toegang

De Pi is hier vooral beschikbaar. Dat is zijn talent.

OpenClaw knoopt de lagen aan elkaar: channel, sessie, agent-runtime, model-provider en tools. Een Slack-bericht komt binnen via de channel-laag. OpenClaw zet daar een agent-turn van klaar, met de juiste context en tools. De runtime voert die turn uit met het gekozen model. Daarna bezorgt OpenClaw het antwoord weer terug via Slack.

Op die manier kan dezelfde agent files lezen, shell-commands draaien, webpagina’s ophalen, git-status bekijken of een PR voorbereiden, afhankelijk van welke tools je toestaat. De Pi is dus geen mini-GPU. Hij is de lokale controle-laag.

Tailscale houdt het praktisch. Ik kan bij de Pi als ik onderweg ben. Een publieke poort openzetten voor een build-log zou wat veel eer zijn.

Slack als werkvloer

Slack was de makkelijkste keuze omdat ik er al de hele dag in zit. Mijn bedrijven hebben workspaces, channels, threads, bestanden en notificaties. Een extra dashboard zou vooral extra tabblad-stof verzamelen.

Voor mij is dit de kern: de agent moet beschikbaar zijn waar het team werkt. Als hij iets uitzoekt op basis van een ticket, wil ik het antwoord terug in dezelfde flow. De analyse hoort naast de vraag, in dezelfde thread.

OpenClaw ondersteunt meer ingangen dan Slack. Het werkt ook via onder meer Telegram, Microsoft Teams, Google Chat, WhatsApp, Discord en iMessage. Slack is mijn ingang. Het bredere idee is agents op bestaande communicatiekanalen, met tools en geheugen erachter.

De installatie was minder spannend dan gehoopt

De installatie was minder dramatisch dan ik had verwacht. Dat is prettig voor mij en slecht voor het genre “build-log met vuur”.

De meeste tijd zat in lezen. OpenClaw heeft veel documentatie, en je moet even uitzoeken welk deel bij jouw setup hoort. Slack, Gateway, agents, runtimes, channels, tools: het zijn losse lagen die uiteindelijk samen één assistent vormen.

Slack instellen kostte ook aandacht. Je bepaalt welke gebruikers de bot mogen DM’en, in welke channels hij mag praten en of hij in groepschannels op elk bericht reageert of alleen bij een @mention. Dat zijn geen details voor later. Je moet die regels vooraf kiezen en met je team delen, anders snapt niemand wanneer de agent wel of niet mee gaat doen.

Na ongeveer twee uur werkte het. Ik typte in Slack, de Pi ving het bericht op, OpenClaw startte een run, GPT-5.5 dacht mee en het antwoord kwam terug in dezelfde thread.

Een hoop plumbing voor een tekstbericht. Alleen kan dat tekstbericht nu wel tools gebruiken.

Eerste test: deze site

De eerste plek waar ik dit voor gebruik is djangodevreng.nl.

De inhoud moet uit echt werk komen: wat we bouwden, wat brak, welke keuzes bleven staan, waar een tool mooi leek tot hij onder load begon te zweten. De agent mag helpen met vorm en uitvoering.

Zodra die ruwe input er is, kan hij veel doen. Een dump structureren. Een eerste outline maken. Een draft herschrijven in mijn toon. Marketing-taal eruit halen. Checken of een post klinkt alsof hij uit een generieke LinkedIn-carrousel is gevallen.

De workflow voor deze site begint meestal rommelig. Ik dump in Slack wat ik wil zeggen: een paar observaties, een half idee, soms alleen feedback op een bestaande post. De agent zoekt daarna de juiste repo erbij, leest de relevante files en pakt de schrijfgids uit de workspace.

Daarna vraag ik hem om een concrete wijziging: “herschrijf de intro”, “haal de marketing-taal eruit” of “maak deze technische uitleg preciezer”. Hoe scherper de opdracht, hoe bruikbaarder de diff. Hij past de markdown aan op een branch, draait de checks en pusht de wijziging naar een PR.

Daar begint mijn deel weer. Ik lees de diff, geef feedback in Slack en laat hem de volgende ronde verwerken. Pas als de post klopt, merge ik zelf. De agent doet het voorbereidende werk. Ik blijf verantwoordelijk voor wat er live gaat.

Een agent die publiceert zonder dat ik kijk, is geen workflow. Dat is een gokautomaat met commit-rechten.

Waarom dit anders voelt dan chat

Veel AI-tools voelen alsof je je werk naar een chatvenster moet brengen. Je kopieert context, plakt logs, legt voor de derde keer uit waar het repo-pad staat en hoopt dat het model doet alsof het erbij was.

Deze setup draait dichter op de context. De agent kan zelfstandig beginnen omdat hij de workspace ziet, de branch kent, de regels voor de site kan lezen en weet welke checks gedraaid moeten worden.

Dat maakt hem nog geen autonome developer. Hij schuift vooral het eerste saaie stuk naar voren.

Voor mij is dat de interessante agent-laag: alvast meelezen, een eerste versie maken, aanwijzen waar het wringt. Een junior collega met oneindig geduld, geen agenda en soms een verontrustend vertrouwen in zijn eigen zinnen.

Ik ga hier nog een losse post over schrijven, want OpenClaw verdient eigenlijk meer uitleg dan in deze build-log past. Welke kanalen het ondersteunt. Welke tools je eraan hangt. En vooral: waarom dit interessant wordt.

We schuiven langzaam van AI als sparringpartner naar AI als uitvoerende laag. De afgelopen jaren praatten we vooral met modellen: brainstormen, samenvatten, herschrijven, meedenken. Dat blijft nuttig, maar het echte verschil zit in agents die werk kunnen uitvoeren in bestaande systemen.

Agents nemen het werk van mensen niet één-op-één over. Zo simpel is het niet, gelukkig. De verschuiving zit in workflows: tickets uitzoeken, context verzamelen, drafts voorbereiden, code-wijzigingen voorstellen, checks draaien, terugrapporteren. Werk waar je normaal iemand voor vraagt omdat het tijd kost, terwijl het weinig diepe menselijke oordeelskracht nodig heeft.

Volgende stap: tickets en MCP

De volgende stap is MCP. Ik wil tools netjes aan deze workflow hangen, te beginnen met Linear.

Het scenario is simpel: er komt een ticket binnen, de agent leest de relevante repo-context, zoekt de waarschijnlijke files, schrijft een korte analyse en komt terug met een voorstel of een lijst vragen.

Autonoom mergen sla ik over. Eerst wil ik weten waar de grens ligt tussen nuttige voorbereiding en gevaarlijke dadendrang.

Daarna komen GitHub, repo-context en misschien een lokale knowledge base. Sommige context hoort gewoon beschikbaar te zijn, zonder dat ik hem steeds opnieuw in een prompt plak.

Workflow voor workflow

Deze Pi-setup is klein. Dat is precies waarom ik hem prettig vind.

Klein genoeg om te begrijpen. Echt genoeg om iets van te leren. Goedkoop genoeg om altijd aan te laten. Lokaal genoeg om dichtbij mijn werk te staan, zonder te doen alsof het model zelf lokaal draait.

Voor productie-AI bij klanten is dit hooguit één laag in de architectuur. Voor mijn eigen workflow werkt hij al prima: Slack als ingang, OpenClaw als Gateway, OpenAI als model-provider, GitHub als plek waar werk klaar komt te staan.

De komende tijd ga ik hier lekker mee rommelen. Eerst deze site. Daarna tickets. Daarna MCP-tools. Daarna waarschijnlijk iets waarvan ik nu nog denk dat het te specifiek is om te automatiseren.

Dat is de interessante route: workflow voor workflow vervangen door een agent die voorwerk doet, context verzamelt en voorstellen klaarzet. Stap voor stap bouw ik mijn OpenClaw-setup uit. Gewoon als praktische assistent die steeds iets meer werk uit mijn handen haalt.

En als het stukloopt, staat hij dichtbij genoeg om de stekker eruit te trekken.

Wat quantization werd na drie benchmarkrondes

2026-05-01T00:00:00.000Z

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.