De drie getallen achter een snelle DGX Spark

Kun je serieus large language models lokaal draaien op een DGX Spark? Ja. Dat is het saaie antwoord, en het is ook het antwoord dat elke review je geeft: een modelnaam, een getal, tokens per seconde, klaar.

Het bruikbare antwoord is lastiger. Een model dat één demo-prompt netjes afhandelt zegt niks over een maandagochtend met tien mensen, grote context, agent-flows en iemand die een halve roman in een ticket plakt. Daar gaat het schuren, of niet. En dat hangt niet af van de Spark, het hangt af van je workload.

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. Wat na al dat meten overbleef is geen scorebord. Het is één manier van kijken die elke keer klopte, en die staat hieronder. De harde cijfers per model staan in de losse posts, en de complete gids met de setup, de kosten en voor wie het werkt staat op LLMs draaien op de DGX Spark. Dit stuk gaat over die ene lens.

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

Hier gaan de meeste DGX Spark-reviews de fout in. Ze pakken één prompt, meten tokens per seconde, en noemen dat “de snelheid”. Maar snelheid is op deze machine geen getal. Het zijn drie dingen, ze voelen anders en ze gedragen zich anders. Haal ze uit elkaar en de hele Spark valt op zijn plek.

Decode is bijna gratis

Decode is de tekst die binnenkomt zodra het model eenmaal genereert. Op de Spark is dat saai stabiel, en saai is hier een compliment. 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. Decode is, kortom, het probleem niet.

Prefill is de rekening

Prefill wel. Prefill is de stilte vóór het eerste token, en dat is wat een gebruiker als “traag” ervaart, niet de tokens daarna.

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.

En quantization? Helpt 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

Blijft de vraag: wat doet hij als je er gewoon te veel op gooit? Het antwoord is geruststellend saai. Hij valt niet om. Hij gaat in de rij staan.

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.

Voor on-prem is dat de beste uitkomst die je kunt hopen. Een crash is een telefoontje. Een rij is even geduld. Een kantoor leeft met het tweede, niet met het eerste.

Dat is het hele model. Decode is bijna gratis, prefill is de rekening, queueing is je vangnet. 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, niet in dit ene lens-verhaal. 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.

Lokaal draaien is geen principe. Het is een verdeling: wat moet binnen blijven, en wat mag naar buiten.

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.