--- title: "Waarom deze blog en arena bestaan" description: "Ik zocht concrete cijfers voor lokale AI op de DGX Spark en vond ze niet. Dus meet ik ze zelf, en bouw ik de blog en de arena op als open werkbank." canonical: "https://djangodevreng.nl/blog/waarom-deze-blog-en-arena/" pubDate: "2026-05-05T00:00:00.000Z" updatedDate: "2026-05-05T00:00:00.000Z" category: "reflecties" --- Voor klanten van [Kamoo](https://kamoo.ai) zet ik AI-systemen op die soms dicht bij huis moeten blijven. Accountants, administraties, kantoren met persoonsgegevens en financiële stukken. Precies het soort data waar je auditor niet rustiger van wordt als je zegt: “we sturen het even naar Amerika”. Daarom staat er bij ons een [DGX Spark](https://www.nvidia.com/en-us/products/workstations/dgx-spark/). 128 GB unified memory, klein genoeg voor een serverkast, groot genoeg om serieus lokale modellen te draaien via [vLLM](https://docs.vllm.ai/). Wat er praktisch op past, verzamel ik op [de overzichtspagina over lokale modellen op de DGX Spark](/dgx-spark/). Toen begon de praktische vraag. Welk model gebruik je waarvoor op deze machine? Welke precisie kies je? Hoeveel context past nog? Waar valt concurrency om? Wat gebeurt er op een gewone maandag met tien mensen die niet tegelijk een benchmark draaien, maar gewoon hun werk doen? Ik zocht cijfers voor precies die vragen. Geen algemene leaderboard met een score die vooral goed staat in een screenshot. Gewoon: deze chip, deze modellen, deze engines, deze workloads, deze grenzen. Die vond ik niet. Dus bouw ik ze zelf op. ## De arena is de meetbank Op dit moment staan er tien benchmarkprofielen in de [arena](/arena/), met runs voor onder meer context-scaling, concurrency, output-throughput, RAG-achtige workloads en Maandagochtend-piek. Die arena moet één ding goed doen: laten zien wat je op een DGX Spark praktisch kunt verwachten. Niet welk model “het beste” is in abstracte zin, maar welk model op deze hardware bruikbaar blijft onder de workloads die ik in klantwerk tegenkom. Bij een paar runs schreef ik al op wat er misging en wat ik eruit haalde. Bijvoorbeeld [waar Gemma-4 op de Spark begint te schuren](/blog/gemma-4-dgx-spark-benchmarks/), [wat NVFP4 wint van BF16 als de bugs eenmaal weg zijn](/blog/gemma-4-nvfp4-vs-bf16-dgx-spark/), en [hoe drie precisies van Nemotron-3 zich verhouden](/blog/nemotron-3-dgx-spark-precisies/). De ruwe output staat publiek op GitHub: [djangodevreng/dgx-spark-benchmarks](https://github.com/djangodevreng/dgx-spark-benchmarks). Dat is bewust. Als je zelf een Spark hebt, moet je dezelfde route kunnen lopen en ongeveer dezelfde cijfers kunnen krijgen. Als dat niet lukt, is dat ook interessante data. De arena is dus geen statisch lijstje. Het is een werkbank. Nieuwe modellen erin, andere precisies ernaast, workloads aanscherpen, rare resultaten opnieuw draaien. Precies saai genoeg om nuttig te worden. ## De blog is de context eromheen Cijfers zijn handig, maar ze vertellen niet het hele verhaal. Een benchmark kan zeggen dat NVFP4 sneller is dan BF16. De blog kan vertellen dat de eerste runs stukliepen op vLLM-bugs, dat een parameter verkeerd stond, dat een model pas bruikbaar werd nadat de contextlengte omlaag ging, of dat de tail-latency erger voelde dan het gemiddelde deed vermoeden. Dat is de laag die ik zelf miste toen ik begon. Niet alleen “hier is een score”, maar: dit probeerde ik, dit brak, dit heb ik aangepast, en dit zou ik de volgende keer anders doen. Daarom staan de blog en arena naast elkaar. De arena geeft de meetpunten. De blog geeft de redenering, de fouten en de praktische keuzes erachter. ## Waarom lokaal Privacy is meestal de nette uitleg. Die klopt ook. De praktischere reden: sommige klanten hebben geen keuze. Een accountantskantoor kan klantdata niet behandelen alsof het voorbeeldtekst in een demo is. Gemeentes hebben regels. Financiële documenten hebben regels. Persoonsgegevens hebben regels. In de praktijk komt dat allemaal neer op dezelfde vraag: kun je dit opzetten zonder dat legal, compliance en audit meteen de deur dichttrekken? Dan heb je twee opties. AI past daar niet, of je maakt het lokaal. Wij kiezen voor lokaal waar dat nodig is. De Spark maakt dat ineens minder exotisch. Hij is niet goedkoop, maar wel behapbaar voor een MKB-kantoor dat iets serieus wil doen zonder meteen een eigen datacenter te bouwen. Daar zit voor mij het interessante werk: modellen draaien, latency meten, prompts testen, documenten door een pipeline trekken, en kijken waar het breekt. Meestal breekt het ergens saais. Dat zijn de beste plekken. ## Wat ik wil kunnen beantwoorden De arena moet uiteindelijk antwoord geven op vragen die in projecten steeds terugkomen. Welk model is snel genoeg voor interne documentvragen? Welke precisie geeft genoeg ruimte voor meerdere gebruikers tegelijk? Wanneer is NVFP4 prima, wanneer wil je FP8, en wanneer is BF16 vooral een dure default? Hoeveel context kun je geven voordat latency vervelend wordt? Welke engine past beter bij welke workload: vLLM, TensorRT-LLM of SGLang? Dat zijn geen academische vragen. Ze bepalen hoe je een on-prem setup ontwerpt. Hoeveel hardware je nodig hebt. Welke data lokaal blijft. Welke stappen je eventueel naar een hosted model stuurt. En waar je de grens trekt tussen “werkt in een demo” en “houdt stand op maandagochtend”. Die laatste grens is de hele reden dat deze site bestaat. ## Waarom ik dit publiek opschrijf Alles wat ik hiervoor gebruik is open of publiek: vLLM, modellen op Hugging Face, benchmark-scripts, losse JSON, de site zelf. Het geheim zit niet in toegang tot een magisch dashboard. Het zit in uren proberen, meten, opnieuw draaien, bugs zoeken en daarna nog eens meten omdat je eerste run verdacht goed was. Dat kostte mij inmiddels tientallen uren. Modellen laten draaien, runs herhalen, rare resultaten uitvogelen, en daarna nog een keer meten omdat de eerste run verdacht goed was. Als iemand anders dezelfde route loopt, hoeft die niet opnieuw door alle stoeptegels heen. En als iemand mijn cijfers tegenspreekt met betere runs: mooi. Dan wordt de arena beter. Er zit ook een tweede reden onder. Deze site is zelf onderdeel van het experiment. De blog, de arena, de flow van benchmark-output naar gestructureerde JSON naar pagina’s: dat is grotendeels in een paar weken gebouwd met agents die meeschrijven en meebouwen. De kleine versie daarvan beschreef ik eerder in [de OpenClaw-setup op een Raspberry Pi](/blog/openclaw-op-raspberry-pi/). Die workflow is inmiddels onderdeel van het werk. Ik dump ruwe bevindingen in Slack, laat een agent de repo en schrijfgids lezen, krijg een branch met voorstel terug, draai checks en review zelf de diff. Dat scheelt geen denken. Het verplaatst wel veel voorbereiding naar een laag die gewoon doorwerkt. Schrijven over dat proces dwingt me om het minder rommelig te maken dan mijn terminal history. Dat helpt. Niet altijd leuk, wel nodig. ## Wat ik hierna wil bouwen Eerst meer benchmarks. vLLM was het startpunt, omdat het snel werkt en breed gebruikt wordt. TensorRT-LLM ligt al op de werkbank voor Nemotron-3. SGLang wil ik daarna naast dezelfde workloads leggen. Pas met meerdere engines zie je of je model traag is, je engine dwarsligt, of jij gewoon iets doms hebt gedaan. Daarna wil ik `bench-spark` publiek maken: de benchmark-runner zoals ik hem nu gebruik. Geen perfect framework. Wel iets waarmee iemand met dezelfde hardware dezelfde vragen kan stellen zonder eerst mijn fouten na te bouwen. Ook wil ik een Nederlandse eval-suite voor lokale LLMs maken. Geen Engelse reasoning-benchmark erbij, maar kantoorwerk: accountancy-jargon, juridische teksten, financiële stukken, documenten met rare opmaak. Precies de dingen waar lokale AI in Nederland op afgerekend wordt. En er komt meer werk rond lokaal RAG op grote documentsets. Geen platform-pitch. Gewoon uitzoeken hoe je meer dan een miljoen documenten door een on-prem setup krijgt zonder dat opslag, retrieval of OCR je langzaam gaat haten. ## Wat ik oversla Geen dagelijkse AI-nieuwsbrief. Daar zijn al genoeg plekken voor, sommige zelfs expres. Geen general-purpose “wij doen alles met AI”-verhaal. Te breed, en meestal betekent het niets. Geen thought-leader-act. Ik bouw liever iets dat kraakt dan een mening die soepel klinkt. Ook geen platform bouwen zoals OpenClaw. Ik gebruik het, ik schrijf erover, ik bouw er flows mee. Maar die laag zelf laat ik aan de mensen die daar elke dag in zitten. ## Wat dit moet worden Voor klanten moet dit laten zien wat lokale AI praktisch kost: hardware, latency, precisie, onderhoud, rare randgevallen. Voor mij is het de plek waar ik mijn eigen aannames vastzet voordat de volgende benchmark ze onderuit haalt. Ik probeer het ritme vast te houden. Geen belofte per week. Als er niets te melden is, staat hier niets. Als er bugs, runs en rare grafieken zijn, staat hier waarschijnlijk te veel.