Waarom deze blog en arena bestaan

Voor klanten van Kamoo zet ik AI-systemen op die soms dicht bij huis moeten blijven. Accountants, administraties, kantoren met persoonsgegevens en financiële stukken. Voor zulke gegevens moeten we vooraf vastleggen waar ze verwerkt mogen worden en wie erbij mag.

Daarom staat er bij ons een DGX Spark. 128 GB unified memory, klein genoeg voor een serverkast, groot genoeg om serieus lokale modellen te draaien via vLLM. Wat er praktisch op past, verzamel ik op de overzichtspagina over lokale modellen op de 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 metingen voor die combinatie van hardware, modellen en workloads.

Omdat ik onvoldoende passende metingen vond, ben ik ze zelf gaan verzamelen.

De arena is de meetbank

Op dit moment staan er tien benchmarkprofielen in de 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, wat NVFP4 wint van BF16 als de bugs eenmaal weg zijn, en hoe drie precisies van Nemotron-3 zich verhouden.

De ruwe output staat publiek op GitHub: 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.

Ik breid de Arena uit met nieuwe modellen en precisies. Ook scherp ik de workloads aan en herhaal ik runs waarvan de resultaten vragen oproepen.

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.

Die toelichting miste ik toen ik begon. Daarom beschrijf ik ook mislukte pogingen en aanpassingen, zodat je kunt volgen hoe een resultaat tot stand kwam.

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.

Juist kleine configuratiefouten kunnen veel invloed hebben op de uitkomst.

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 welke belasting de toepassing in dagelijks gebruik aankan.

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. Ik wil de configuratie en resultaten beschikbaar maken, zodat anderen mijn metingen kunnen controleren.

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, kan die mijn instellingen en beschreven problemen als uitgangspunt gebruiken. 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.

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. Ik blijf de inhoud beoordelen, maar de agent neemt een deel van het voorbereidende werk over.

Door het proces op te schrijven, leg ik de stappen en keuzes vast die anders alleen in mijn terminalgeschiedenis staan.

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. Daarmee wil ik het voor anderen met dezelfde hardware eenvoudiger maken om de tests te herhalen.

Ook wil ik een Nederlandse eval-suite voor lokale LLMs maken. Daarin wil ik Nederlands kantoorwerk testen: 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. Ik wil uitzoeken hoe een on-prem setup meer dan een miljoen documenten verwerkt en waar opslag, retrieval of OCR te veel tijd kosten.

Wat ik oversla

Ik richt me op eigen projecten en tests; een dagelijkse AI-nieuwsbrief staat niet op de planning.

De nadruk blijft op lokale modellen en de toepassingen waaraan ik zelf werk.

Ik schrijf vooral wanneer ik iets heb gebouwd of getest waarover ik concrete ervaringen kan delen.

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 publiceer wanneer ik nieuwe metingen of ervaringen te delen heb. Daarvoor houd ik geen vaste wekelijkse frequentie aan.