Gemma-4 v23 op de DGX Spark
Nieuwe vLLM v0.23.0-runs voor Gemma-4 op de DGX Spark: BF16, NVFP4 en MTP naast elkaar, met decode, TTFT, tails en praktische grenzen voor lokale agents.
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.