De drie getallen achter een snelle DGX Spark

Op een DGX Spark kun je lokaal taalmodellen draaien. Om te bepalen of dat voor je toepassing snel genoeg is, heb je meer nodig dan één meting in tokens per seconde.

Een korte prompt van één gebruiker belast de machine anders dan lange documenten en tien gelijktijdige gesprekken. Daarom test ik meerdere workloads. Zo zie ik wat promptlengte en gelijktijdigheid doen met de snelheid en wachttijd.

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. Bij het vergelijken van de runs keek ik naar decode, prefill en wachtrijen. De harde cijfers per model staan in de losse posts en op de benchmarkkaarten voor Gemma-4 BF16, Gemma-4 NVFP4 en Nemotron-3 in BF16, FP8 en NVFP4. De complete gids met de setup, de kosten en voor wie het werkt staat op LLMs draaien op de DGX Spark. Hier leg ik uit hoe ik die drie metingen lees.

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

Tokens per seconde vertelt hoe snel een antwoord verschijnt zodra de generatie begint. De wachttijd daarvoor en de wachtrij bij drukte moet je apart bekijken.

Decode is bijna gratis

Decode is de tekst die binnenkomt zodra het model eenmaal genereert. In deze tests bleef dat bij één gebruiker vrij stabiel. 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. In die runs bood decode voldoende snelheid voor mijn toepassing.

Prefill is de rekening

Prefill vindt plaats voordat het eerste token verschijnt. Tijdens die verwerking ziet de gebruiker nog geen antwoord.

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.

Quantization hielp 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

In de overbelastingstest crashte de server niet. Verzoeken bleven in de wachtrij staan totdat er capaciteit vrijkwam.

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.

Dat de verzoeken slagen is nuttig, maar de extra wachttijd moet wel acceptabel zijn voor de toepassing.

Ik beoordeel deze metingen dus op uitvoersnelheid, promptverwerking en wachttijd onder belasting. 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, buiten de bespreking van deze metingen. 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.

Ik bepaal per taak welke gegevens binnen de eigen omgeving moeten blijven en welke naar een externe dienst mogen.

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.