Gemma-4 v23 op de DGX Spark
Gemma-4 op de DGX Spark met vLLM v0.23.0. Ik vergelijk BF16, NVFP4 en MTP op uitvoersnelheid en wachttijd, ook bij grote context en piekbelasting.
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-it-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. Hiermee vergelijk ik de doorvoer bij een korte prompt en een antwoord van dezelfde tokenlengte.
| 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 |
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. De prompt moet nog steeds worden verwerkt voordat het eerste token verschijnt.
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 |
NVFP4 haalt hier 182.90 tok/s totaal voor tien gelijktijdige multi-turngesprekken.
MTP is een optie als je het Google BF16-model wilt blijven serveren en meer decode-doorvoer zoekt. Het haalt hier 16.57 tok/s per gebruiker, tegenover 10.69 zonder MTP.
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: een prompt van 25k tokens kost veel verwerkingstijd. Dat zie je terug in de 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 |
De output-throughput is 139.05 versus 129.92 tok/s. Het grotere verschil zit in de p95 TPOT: 77.98 ms bij NVFP4 tegenover 197.57 ms bij BF16. Zodra het antwoord begint, volgen tokens dus sneller op elkaar.
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 geeft in deze test een korte wachttijd voor het eerste token en weinig tijd tussen de volgende tokens.
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 een deel wacht langer in de wachtrij. BF16 en MTP hebben hier hogere wachttijden in de staart van de verdeling. 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. Alleen het serve-profiel wisselen neemt die wachttijd niet weg.