Modellen eerlijk vergelijken op je eigen hardware

Door Ivo Donker - 3 augustus 2026

Het vergelijken van grote taalmodellen (LLM's) gebeurt online vaak op basis van algemene benchmarks, tabellen en ervaringen van anderen. Wie een model zelf lokaal wil draaien, merkt echter al snel dat gepubliceerde cijfers zelden overeenkomen met de werkelijkheid op de eigen computer. Een model dat volgens een online tabel soepel draait, kan op jouw specifieke configuratie traag reageren of onnodig veel geheugen opslokken. Om te bepalen welk model het beste presteert voor jouw toepassingen, is een gestructureerde en objectieve meetmethode noodzakelijk.

In deze gids behandelen we hoe je op een wetenschappelijke en herhaalbare manier verschillende modellen onderling vergelijkt op je eigen hardware. We kijken naar de variabelen die de uitkomst beïnvloeden, de meeteenheden die er daadwerkelijk toe doen, en de stappen die je moet zetten om vertekening door externe factoren te voorkomen.

Waarom externe cijfers zelden kloppen

De prestatiegegevens die op fora en in benchmarkoverzichten verschijnen, zijn verzameld onder specifieke testomstandigheden. Wanneer je deze cijfers probeert te reproduceren, stuit je op inherente verschillen in zowel de onderliggende apparatuur als de software-instellingen. Wie algemene adviezen volgt bij een lokaal model kiezen, merkt dat lokale factoren de uiteindelijke prestaties sterk dicteren.

Er zijn vier primaire redenen waarom gepubliceerde cijfers afwijken van jouw eigen ervaring:

• Hardware-architectuur: De verhouding tussen geheugenbandbreedte, videogeheugen (VRAM), werkgeheugen (RAM) en rekenkernfrequenties verschilt per systeem. Een videokaart met een brede geheugenbus verwerkt tokens anders dan een processor die afhankelijk is van het algemene systeemgeheugen.
• Kwantisatievormen: Niet elke kwantisatie is identiek geïmplementeerd. Een 4-bit kwantisatie via een bepaald schema kan een andere geheugenafdruk en verwerkingssnelheid opleveren dan een 4-bit versie op een ander schema of ander type engine.
• Contextlengte: Het vergroten van het contextvenster vereist een exponentieel of lineair toenemende hoeveelheid geheugen voor het beheer van de sleutel-waarde-cache (KV-cache). Een benchmark die is uitgevoerd op een context van 512 tokens geeft geen representatief beeld van de prestaties bij 8192 tokens.
• Runtime-instellingen: De gekozen inference-engine, het aantal toegewezen CPU-threads en de verdeling van de model-lagen over verschillende systemen beïnvloeden de snelheid direct.

Variabelen vastzetten voor een eerlijke vergelijking

Een betrouwbare meting vereist dat alle randvoorwaarden constant blijven, behalve het model dat je direct wilt testen. Wanneer je twee modellen vergelijkt met verschillende instellingen, meet je de invloed van de instellingen en niet de kwaliteit of efficiëntie van het model zelf.

Zorg er bij elke testreeks voor dat de volgende variabelen expliciet vaststaan:

• Kwantisatieniveau: Vergelijk modellen van hetzelfde precisieniveau, bijvoorbeeld beide op Q4_K_M of Q8_0. Het vergelijken van een ongekwantiseerd model met een sterk gecomprimeerd model geeft een vertekend beeld.
• Contextlengte: Stel de maximale contextgrootte in op een vaste waarde (bijvoorbeeld 4096 tokens) in de configuratie van de runtime.
• Batchgrootte: Houd de parallelle verwerkingsparameters (zoals logical_batch_size of physical_batch_size) identiek.
• Hardware-offloading: Fixeer het aantal lagen dat naar de GPU wordt gestuurd. Zorg ervoor dat het volledige model in het VRAM past, of houd de verhouding tussen VRAM en RAM exact gelijk bij vergelijkbare modelgroottes.
• Sampling-parameters: Schakel willekeur uit bij prestatietesten of zet deze vast. Gebruik een vaste willekeurige kiem (seed), een vaste temperatuur (bijvoorbeeld temperature = 0.0 voor deterministische resultaten), en consistente waarden voor top-p en top-k.
• Exacte modelversie: Documenteer het precieze revisienummer of de exacte bestandsnaam (SHA256-hash) van het modelbestand.

Prefill versus decode: twee gescheiden fasen

Bij de verwerking van een verzoek door een taalmodel vinden twee technisch verschillende fasen plaats: prompt-verwerking (prefill) en tokengeneratie (decode). Het combineren van deze twee fasen in één gemiddelde snelheid verbergt cruciale prestatie-informatie.

Tijdens de prefill-fase leest het model de ingevoerde tekst (de prompt) in en bouwt het de interne representatie op. Dit proces is voornamelijk gebonden aan de rekenkracht van de processor of GPU (compute-bound). Zeker bij het insturen van lange documenten of grote lappen code is de snelheid van de prefill-fase doorslaggevend voor de responsiviteit van het systeem. Meer details over hoe je deze snelheden specifiek isoleert vind je via snelheid meten op de benchmark-hub.

De decode-fase betreft het genereren van nieuwe tokens, één voor één. Omdat bij elk nieuw token de gehele gewichtenmatrix van het model opnieuw door het geheugen moet worden gehaald, is deze fase voornamelijk gebonden aan de geheugenbandbreedte (memory-bound). Een model kan een trage prefill hebben maar een snelle decode, of andersom. Om die reden moeten beide waarden afzonderlijk worden geregistreerd in het meetprotocol.

Relevante prestatie-indicatoren

Om een model op je eigen hardware te beoordelen, volstaat een enkele waarde niet. Een volledige analyse rust op vier pijlers:

Meet deze indicatoren nooit over één enkele uitvoer. Voer elke testreeks minimaal vijf keer uit onder identieke omstandigheden. Bereken vervolgens het gemiddelde en de standaarddeviatie. Een model dat gemiddeld 25 t/s haalt met grote schommelingen is in de praktijk minder voorspelbaar dan een model dat constant op 22 t/s opereert.

Vertekening voorkomen: temperatuur en achtergrondprocessen

Hardware gedraagt zich niet statisch. Twee veelvoorkomende bronnen van ruis tijdens lokale metingen zijn thermische begrenzing (thermal throttling) en onvoorziene achtergrondactiviteit van het besturingssysteem.

Wanneer een grafische kaart of processor gedurende langere tijd zwaar wordt belast, stijgt de temperatuur van de chip. Zodra de maximale bedrijfstemperatuur wordt bereikt, verlaagt de hardware automatisch de kloksnelheid om schade te voorkomen. Als je model A test op een koude grafische kaart en direct daarna model B op een opgewarmde kaart, zal model B consistent slechter scoren puur vanwege de hogere temperatuur.

Neem daarom de volgende voorzorgsmaatregelen op jouw machine:

1. Voer een opwarmrun uit: Laat de hardware voorafgaand aan de officiële meting één korte generatie uitvoeren om het geheugen te vullen en de koeling op te starten. Gooi de resultaten van deze eerste run weg.
2. Houd rustpauzes: Bouw een vaste rustperiode in (bijvoorbeeld 10 tot 15 seconden) tussen opeenvolgende tests om het koelsysteem de gelegenheid te geven de temperatuur te laten dalen.
3. Sluit achtergrondprocessen: Schakel browsers, communicatie-apps, automatische back-ups en andere zware software uit. Zorg dat de belasting van het systeem in rust minimaal is.
4. Controleer de koeling: Monitor de temperatuur en kloksnelheid van de hardware tijdens de tests om vast te stellen of er sprake is van throttling.

Kwaliteit meten met een vaste Nederlandse testset

Snelheid is slechts de helft van de vergelijking. Een model dat extreem snel teksten genereert maar inhoudelijk foutieve of onsamenhangende antwoorden levert, is ongeschikt. Het beoordelen van kwaliteit vereist net zo veel structuur als het meten van de snelheid.

Bouw voor de kwalitatieve evaluatie een kleine, eigen testset op van 10 tot 20 vaste prompts. Zorg ervoor dat deze opdrachten representatief zijn voor het werk dat je het model daadwerkelijk wilt laten uitvoeren. Als de beoogde toepassing Nederlandstalig is, moet de testset volledig uit Nederlandstalige opdrachten bestaan. Kwaliteitstesten in het Engels zeggen weinig over het taalbegrip en de syntaxis van een model in het Nederlands. Zie voor specifieke richtlijnen het artikel over het Nederlands testen van taalmodellen.

Stel voor de beoordeling een vast evaluatieformulier op met specifieke criteria, zoals:

• Inhoudelijke nauwkeurigheid: Bevat het antwoord feitelijke onjuistheden of hallucinaties?
• Instructievolging: Is het gevraagde formaat (bijvoorbeeld een JSON-structuur, een opsomming of een vaste lengte) exact overgenomen?
• Taalgebruik en grammatica: Loopt de Nederlandse zinsbouw natuurlijk, of vertoont het antwoord duidelijke sporen van letterlijke Engelse vertalingen?
• Redeneervermogen: Is een logische stappenredenering bij een complex probleem correct opgebouwd?

Bij het uitvoeren van kwalitatieve benchmarks is het van belang om de testopdrachten te standaardiseren op een manier die de reproduceerbaarheid van resultaten waarborgt.

Praktisch meetprotocol in stappen

Om direct aan de slag te gaan, kun je onderstaand stappenplan hanteren voor elke vergelijkingssessie op je eigen machine:

Stap 1: Voorbereiding van de omgeving

Sluit alle niet-essentiële toepassingen. Controleer via het taakbeheer of de monitor van je besturingssysteem of de CPU- en GPU-belasting nabij de nul procent ligt. Zorg dat je nieuwste drivers en de gewenste runtime (zoals llama.cpp of Ollama) bijgewerkt zijn. Bekijk eventueel de instructies over LLM's lokaal draaien voor een stabiele basisopzet.

Stap 2: Bepalen van de testopdrachten

Kies drie vaste prompts voor de snelheidsmetingen:

1. Korte prompt / Korte responstijd: Een eenvoudige vraag (bijvoorbeeld 20 tokens in, 50 tokens uit) om de initiële latency te testen.
2. Lange prompt / Korte responstijd: Een grote brontekst van 2000 tokens met de vraag om een korte samenvatting, om de prefill-snelheid te meten.
3. Korte prompt / Lange responstijd: Een korte instructie die vraagt om een uitgebreid artikel van 1000 tokens, om de decode-snelheid te isoleren.

Stap 3: Het uitvoeren van de testreeks

Voer per model de onderstaande stappen uit:

• Laad het model in met de vastgestelde parameters (bijvoorbeeld Q4_K_M, 4096 context).
• Voer één opwarmrun uit en negeer de tijdsmeting.
• Voer test 1, 2 en 3 achter elkaar uit. Herhaal deze reeks 5 keer. Tussen elke run wacht je 10 seconden.
• Aantekening maken van de ruwe meetwaarden uit het logbestand of de terminaluitvoer van de runtime.

Stap 4: Vastleggen in het resultaatlogboek

Houd de gegevens bij in een eenvoudig logboek of rekenblad. Gebruik een consistente structuur zodat je later oude metingen kunt vergelijken wanneer je nieuwe onderdelen aanschaft of instellingen aanpast.

Veelgemaakte fouten bij de meting

Tijdens het testen van lokale modellen worden regelmatig methodologische fouten gemaakt die de uitkomst onbetrouwbaar maken. De meest voorkomende valkuilen zijn:

Appels met peren vergelijken: Een model van 7 miljard parameters op Q8_0 vergelijken met een model van 14 miljard parameters op Q2_K. Hoewel ze evenveel geheugen kunnen innemen, verschillen de kwalitatieve eigenschappen en verwerkingskarakteristieken fundamenteel. Meer achtergrond over de impact van compressie op de nauwkeurigheid vind je in het overzicht van kwantisatie uitgelegd.

Meten met een koude cache: Sommige runtimes slaan eerdere contexten op in het RAM-geheugen. Als je exact dezelfde prompt twee keer achter elkaar verstuurt, kan de tweede run een extreem hoge prefill-snelheid laten zien omdat de context al verwerkt is. Wis de cache of herstart de runtime tussen de tests om schijnresultaten te voorkomen.

Conclusies trekken uit een enkele prompt: Eén specifieke prompt kan toevallig erg gunstig uitvallen voor een bepaald model vanwege het specifieke trainingsmateriaal. Pas wanneer een model over meerdere uiteenlopende opdrachten consistent goed scoort, kun je een gegronde conclusie trekken over de geschiktheid voor jouw workflow.

Lees ook

• Lokaal model kiezen
• Kwantisatie uitgelegd
• LLM lokaal draaien
• Snelheid meten op de benchmark-hub
• Reproduceerbaarheid van resultaten
• Nederlands testen van taalmodellen