LLMs draaien op de DGX Spark
Ja, je kunt er serieus lokale LLMs op draaien. Een model dat in NVFP4 of FP8 past, draait met genoeg doorvoer voor een team of een productie-agent. De truc zit in de precisie-keuze en je engine-config, niet in brute kracht.
Wat de DGX Spark is
De DGX Spark is NVIDIA's kleine desktop-AI-machine. Eén GB10-superchip, geheugen dat CPU en GPU delen, en genoeg capaciteit om modellen lokaal te draaien die je anders naar de cloud zou sturen. Geen rack, geen datacenter, gewoon naast je bureau.
Het interessante detail zit in de FP4-compute. NVIDIA adverteert de Spark met een petaFLOP FP4, maar op sm_121 mist het instructie-pad dat NVFP4 nodig heeft. vLLM waarschuwt daar zelf voor en valt terug op Marlin, dat de 4-bit gewichten naar BF16 dequantiseert. Je slaat dus 4-bit op, en die geheugenwinst is echt, maar je rekent op een hoger niveau. Voor pure compute is dat een nadeel, voor geheugen en bandbreedte juist niet, en daar zit op deze hardware de winst.
- Chip
- GB10 superchip
- Geheugen
- 128 GB unified
- Compute
- SM12.1, geen native FP4
- Prijsklasse
- ~€3.700 ex btw
Wat erop past
De vuistregel: modelgrootte in miljarden parameters, keer de bytes per parameter, is wat je in geheugen kwijt bent. BF16 kost 2 bytes per parameter, FP8 één, NVFP4 een halve. Een 30B-model in BF16 is dus zo'n 60 GB aan gewichten, in NVFP4 nog maar 15. Daar komt de KV-cache nog bovenop, en die groeit met je context-lengte.
Met 128 GB unified memory heb je ruimte zat voor de meeste open-weight modellen, mits je niet alles in BF16 propt. De precisie-keuze is daarom geen detail, het bepaalt of een model past en hoeveel context je erbij krijgt.
- BF16
- 2 bytes / param
- FP8
- 1 byte / param
- NVFP4
- 0,5 byte / param
Beste kwaliteit, vreet geheugen. Voor codegen waar het moet kloppen.
De middenweg. Halveert geheugen, kwaliteit nauwelijks merkbaar lager.
Maximale ruimte en doorvoer. Voor RAG en agents prima, voor codegen opletten.
Hoe snel het is
Twee getallen tellen. Prefill is hoe snel het model je prompt inleest, decode is hoe snel het daarna tokens uitspuugt. Bij korte prompts merk je vooral decode, bij lange context wordt prefill de bottleneck. Op de Spark schaalt decode netjes, prefill loopt tegen een muur aan zodra je context flink groeit.
Onder druk gedraagt de machine zich verrassend volwassen. Stuur je meer requests dan hij aankan, dan queue't hij ze netjes op. Hij crasht niet, hij wordt traag. Dat is precies wat je wilt voor een systeem waar maandag een team op leunt.
De exacte cijfers per model en context-lengte staan in de benchmark-suite, gedraaid op één Spark met een vast meet-protocol. De redenering achter deze drie getallen staat in een apart essay.
- Decode @ klein
- 20,9 t/s/user
- Decode @ 25k
- 7,6 t/s/user
- Prefill-muur
- ~25k tokens
- Stabiele streams
- 25 parallel
Indicatie op Gemma-4-26B-A4B in NVFP4. Per model en precisie verschilt dit, de volledige cijfers staan in de arena.
→ Naar de volledige benchmark-suiteWelke engine
vLLM. Daar komt het kort gezegd op neer. Het is de engine met de beste support voor NVFP4 op de Spark, fatsoenlijke chunked prefill, en een serve-modus die zich gedraagt als een echte inference-server in plaats van een demo-scriptje.
Je hebt wel de juiste flags nodig. Chunked prefill aan, je max-num-batched-tokens goed gezet, en geheugen-utilisatie afgestemd op je context-budget. Zet je dat verkeerd, dan krijg je een instabiele server of throughput die nergens op lijkt. De werkende config staat in de build-log over Gemma-4.
Wat het kost
De aanschaf is eenmalig, de stroom loopt door. Een Spark trekt onder load zo'n 170 watt. Reken niet op 24/7 op volle toeren, dat haalt hij in de praktijk bijna nooit. Bij zo'n 8 uur echte load per dag kom je op ≈€130/jaar aan stroom. De marginale kost van één extra token is dan bijna niets, alleen stroom. Maar reken jezelf niet rijk: de échte kost per token hangt af van hoe vol je de machine houdt, en is lang niet altijd lager dan een hosted API.
Het omslagpunt hangt af van je volume. Draai je af en toe een prompt, dan is een cloud-API goedkoper. Draai je dag in dag uit met een team of een productie-workload, dan verdient de hardware zich terug. De volledige rekensom staat op de kostenpagina.
- Aanschaf
- ~€3.700 ex btw
- Stroom onder load
- ≈170 W
- Stroom per jaar
- ≈€130/jaar
- Per extra token
- ≈€0,00
Stroom op basis van ~8 uur load per dag bij €0,26/kWh. Een Spark staat zelden 24/7 onder volle load, dus continu-draaien overschat de rekening.
→ De volledige kostenvergelijking: lokaal vs cloudVoor wie
Niet voor iedereen. Als je data prima naar een hosted model mag, is een API simpeler en vaak goedkoper. De Spark wordt interessant zodra dat niet kan of niet mag.
Denk aan MKB-bedrijven en organisaties die met persoonsgegevens werken, interne documenten of klantdata die onder de AVG dichtbij moet blijven. Dan wordt de vraag niet "wat is het snelste model", maar "welk deel mag überhaupt naar buiten". Een Spark onder je eigen beheer beantwoordt die vraag een stuk makkelijker dan een contract met een cloud-leverancier.
Het is ook gewoon prettig om je inference in eigen huis te hebben. Geen rate-limits, geen prijswijziging per kwartaal, geen model dat zonder waarschuwing verandert onder je voeten.
Reproduceer het zelf
Alle cijfers op deze site komen van één Spark, met een vast meet-protocol: dezelfde prompts, dezelfde seeds, drie runs per meting. Geen cherry-picking, geen marketing-benchmark. De config, de prompts en de ruwe output staan open op GitHub.
Draai je 'm op een andere Spark of een andere vLLM-versie en krijg je andere getallen, laat het weten. Dat is precies het soort feedback waar deze hele suite beter van wordt.
Verder lezen
Gemma-4 op de DGX Spark: waar context pijn doet
Negen benchmarks, de prefill-muur in beeld, en de vLLM-config die uiteindelijk werkte.
Lees verder → BenchmarkGemma-4: NVFP4 vs BF16
Dezelfde negen tests, twee precisies. Waar NVFP4 de doorvoer bijna verdubbelt.
Lees verder → BenchmarkNemotron-3: BF16 vs FP8 vs NVFP4
Drie precisies naast elkaar op hetzelfde model en dezelfde Spark.
Lees verder → QuantizationWat quantization werd na drie benchmarkrondes
Het concept onder de cijfers: welke taak mag op welke precisie.
Lees verder → LensDe drie getallen achter een snelle DGX Spark
Decode, prefill en queueing: het ene perspectief dat elke benchmark-run verklaarde.
Lees verder →