LLMs draaien op de DGX Spark

De DGX Spark is een compacte AI-computer van NVIDIA met een GB10-superchip. CPU en GPU delen het geheugen. Je kunt er lokaal taalmodellen op draaien en de machine naast je bureau zetten.

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.

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.

Hoeveel er in 128 GB past, hangt af van de modelgrootte en precisie. Na het laden van de gewichten moet er ook ruimte overblijven voor de KV-cache. De gekozen precisie bepaalt dus mede hoeveel context je kunt gebruiken.

Prefill is het verwerken van je prompt; decode is het genereren van de antwoordtokens. Bij korte prompts valt vooral de uitvoersnelheid op. Bij lange prompts kan de verwerking vooraf veel tijd kosten. In mijn tests op de Spark nam die wachttijd sterk toe bij grote context.

In mijn overbelastingstest bleven verzoeken in de wachtrij staan en crashte de server niet. De wachttijd liep wel op. Bekijk daarom naast de doorvoer ook hoe lang gebruikers bij drukte op hun antwoord wachten.

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.

Ik gebruik vLLM om de modellen als API aan te bieden. Het ondersteunt de NVFP4-configuratie die ik test en kan lange prompts in delen verwerken met chunked prefill.

In mijn configuratie staat chunked prefill aan. Ik stem max-num-batched-tokens en de geheugenbenutting af op de gewenste contextlengte. Die instellingen beïnvloeden de stabiliteit en doorvoer. De configuratie staat in de build-log over Gemma-4.

Een cloud-API kan praktischer zijn wanneer je de gegevens daar mag verwerken en zelf geen modelserver wilt beheren. Een Spark is een optie wanneer je de verwerking in eigen beheer wilt houden.

De hardware is maar één deel van de keuze. De Local AI-beslisgids vergelijkt ook kwaliteit, datagrenzen, beheer, kosten en veranderbaarheid.

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.

Met eigen hardware bepaal je zelf welke modelversie draait en wanneer je die bijwerkt. Je capaciteit wordt begrensd door je machine. Onderhoud en updates regel je ook zelf.

Alle cijfers op deze site komen van één Spark, met een vast meet-protocol: dezelfde prompts, dezelfde seeds, drie runs per meting. De config, de prompts en de ruwe output staan open op GitHub.

Krijg je andere resultaten op een andere Spark of vLLM-versie? Stuur je instellingen en meetresultaten mee, dan kunnen we de verschillen onderzoeken.