Lokale LLM benchmark: 8 modellen getest op een Mac Mini M4 met 24GB RAM

Als je een AI-gedreven SaaS bouwt, wil je niet voor elke API-call betalen. Ik draai een multi-agent orchestratiesysteem op een Mac Mini M4 met 24GB RAM en wilde weten: welk lokaal LLM kan ik inzetten voor code generatie, data extractie en Nederlandse content?

Geen synthetische benchmarks. Geen MMLU-scores. Ik heb een benchmark framework gebouwd dat exact de taken test die mijn systeem dagelijks uitvoert: SEOcrawler code schrijven, bash scripts migreren naar Python, Nederlandse marketingteksten genereren.

Dit is het verhaal van drie rondes testen, 30+ benchmark runs, en waarom de "beste" modelpick niet zo simpel is als je denkt. (Zoek je de MKB-versie zonder technische diepgang? Lees AI-teksten schrijven zonder ChatGPT: 6 gratis modellen getest.)

De testopzet

Hardware

• Machine: Mac Mini M4, 24GB unified memory
• LLM runtime: Ollama (lokaal)
• Alle modellen draaien op dezelfde machine — geen cloud, geen API

Benchmark framework

Zelf gebouwd Python framework (llm_benchmark.py) met:

• Gestructureerde prompts met verwacht output-formaat (JSON of Python code)
• Automatische scoring: format compliance, field completeness, snelheid
• Nederlandse taaldetectie (stopword density)
• Character limit validatie (Google Ads headlines, meta descriptions)
• Progress checkpointing en resume na crashes
• Geheugenbeheer tussen runs: model unloaden, purge, swap monitoring

Geteste modellen

Taakcategorieën

Coding (8 taken): Session analyse (JSON), docstring generatie, test case generatie (pytest), error classificatie, print-to-logger conversie, Nederlandse bedrijfsdata extractie, digest narrative, bash-to-Python migratie.

Coding V2 (8 taken, moeilijker): Crawl4AI extraction pipeline, FastAPI SSE streaming, async batch upsert met retry, Nederlandse bedrijfsdata validator (KvK/BTW/IBAN), receipt processor, dispatcher routing, health monitor, state consolidator.

Marketing (10 taken): LinkedIn posts, Google Ads, SEO meta tags, review responses, productbeschrijvingen, re-engagement emails, FAQ's, lead kwalificatie, concurrentieanalyse, Instagram carousels — allemaal in het Nederlands.

Ronde 1: eerste vergelijking (num_predict=4096)

Resultaten

De 27B catastrofe

Het qwen3.5:27b model was een complete ramp op 24GB:

• 17GB model + 8GB context = meer dan beschikbaar geheugen
• Het systeem ging zwaar swappen
• Alle 8 taken timeden uit na 300 seconden
• Na het unloaden was er nog maar 4.6 GB vrij
• Rerun met langere timeout: 3/8 format OK, maar slechts 4.0 tok/s

Het 27B dense model past simpelweg niet in 24GB RAM met een werkbare context window. Het 35B MoE model (dat slechts ~3.5B parameters per token activeert) draait ironisch genoeg prima.

Verrassingen

1. qwen2.5-coder:14b was overduidelijk de beste — 94% completeness, 100% format compliance
2. Thinking mode maakte dingen erger bij qwen3.5 — de thinking tokens aten het output budget op
3. Het grotere model (27B) was het slechtste — tegenintuitief maar logisch gezien de geheugenbeperkingen
4. MoE architectuur was verrassend efficiënt — 35B heet "35B" maar activeert slechts 3.5B per token

Extra modellen: Mistral en phi4-mini

Halverwege de eerste ronde heb ik drie modellen bijgepakt:

phi4-mini was een verrassing: 28.4 tokens per seconde, 90% completeness, en het kleinste model van allemaal. Perfect voor snelle, gestructureerde taken waar je geen diep redeneren nodig hebt.

Ronde 2: het token-plafond doorbreken

De hypothese

Na analyse van de Ronde 1 resultaten zag ik een patroon: de qwen3.5 modellen genereerden consequent 4096 tokens (het maximum) maar de output was leeg of incompleet. Vooral bij thinking mode ging alles naar de "denkstappen" en bleef er niets over voor het antwoord.

Hypothese: De slechte scores zijn een token ceiling artefact, niet een kwaliteitsprobleem.

Nieuwe instellingen

Resultaten

qwen3.5:35b-a3b (MoE)

qwen3.5:9b

De doorbraak

De resultaten bevestigden de hypothese overtuigend:

• 9b ging van 0% naar 75-78% completeness — puur door token limits te verhogen
• Thinking mode werd plotseling beter dan no-think — precies het omgekeerde van Ronde 1
• Snelheid bleef nagenoeg gelijk (geen penalty voor grotere context)

De les: als je thinking-modellen test met te lage token limits, meet je het plafond, niet het model.

Dit is een van de meest onderschatte foutbronnen in lokale LLM benchmarks. De community deelt constant resultaten met default token limits, zonder te beseffen dat ze appels met peren vergelijken.

Ronde 2b: marketing taken (alle modellen)

Met de hogere token limits de volledige marketing benchmark gedraaid.

Kwaliteit

Snelheid: de echte eye-opener

Tokens per seconde zegt weinig voor eindgebruikers. De echte vraag: hoelang duurt het om een taak af te ronden?

Phi4-mini doet alle 10 taken in anderhalf minuut. Qwen 35B heeft daar meer dan een uur voor nodig.

De verklaring: Mistral-modellen en phi4-mini genereren compactere output. Qwen produceert uitgebreidere teksten — bij marketing is dat niet per se beter.

Thinking mode: wisselend effect bij marketing

Bij het 35B model maakt thinking mode geen verschil (of is het marginaal slechter). Bij het kleinere 9B model helpt thinking wél — het compenseert voor het gebrek aan parameters. De trade-off: thinking kost extra tijd en tokens.

Ronde 3: real-world coding V2

Na de eerste twee rondes heb ik een nieuwe benchmark gebouwd met hardere, realistischere taken. Token settings: num_predict=16384, num_ctx=32768.

Taken

SEOcrawler code (4 taken):

1. Crawl4AI extraction pipeline — CSS selectors, fallback, structured SEO data
2. FastAPI SSE streaming — event protocol, async generator, heartbeat
3. Async batch upsert — retry logic, deduplication, batch processing
4. Nederlandse bedrijfsdata validator — KvK, BTW, IBAN, postcode, telefoon

Bash-to-Python migratie (4 taken): 5. Receipt processor — NDJSON generatie, flood protection 6. Dispatcher routing — terminal claim, queue management 7. Health monitor — process checks, auto-restart, cooldown 8. State consolidator — merge terminal/queue/receipt state

Resultaten

qwen2.5-coder:14b blijft de beste voor code-taken. Dat is logisch: het is specifiek getraind op code, terwijl de andere modellen general-purpose zijn.

De qwen3.5:9b faalde op twee taken door timeouts (1800 seconden): de async batch upsert en de Nederlandse validator. Deze taken vereisen complex redeneren over retry-logica en validatiepatronen — te zwaar voor een 9B model.

Kwalitatieve observaties

Sterke punten over alle modellen:

• KvK/BTW extractie correct, juridische pagina's herkend
• Error classificatie: root cause correct geïdentificeerd (React SPA timeout)
• Print-to-logger: correcte log levels, systematische conversie
• Bash-to-Python: structureel correct, pathlib, signal handling

Structurele zwaktes:

• Test generatie: fixtures goed, maar specifieke gevraagde tests ontbreken (~20% completeness)
• Digest narrative (NL): lege output bij alle modellen — tokens gaan naar thinking, niets naar antwoord
• Nederlandse bedrijfsdata validator: alleen qwen2.5-coder:14b produceerde werkende regex voor alle patronen

Claude vergelijking: cloud als referentiepunt

Om de lokale resultaten in perspectief te plaatsen, heb ik dezelfde 10 marketing taken door Claude Haiku en Claude Sonnet gestuurd via de API.

Resultaten

Per taak vergelijking

Lokaal vs cloud: het complete plaatje

Claude levert de beste balans tussen snelheid en kwaliteit. Maar phi4-mini is sneller, en devstral matcht de kwaliteit — beide gratis. Qwen 35B levert de beste Nederlandse taalvaardigheid, maar betaalt dat met uur-lange runtimes.

📖 Lees ook: Qwen3.5 Lokaal Draaien: Waarom Dit AI-Model Alles Verandert voor het MKB — Diepere duik in het best scorende Nederlandse model

Tijdlijn van de benchmark

60 uur compute, 30+ runs, drie rondes:

1. 5 maart, 17:30 — Eerste run: qwen3.5:9b vs qwen2.5-coder:14b. Coder wint overduidelijk.
2. 5 maart, 18:14 — Heavy models: qwen3.5:27b crasht (swap), 35B-a3b scoort matig.
3. 6 maart, 07:03 — Ronde 2: token limits verdubbeld. Doorbraak — scores verdrievoudigen.
4. 6 maart, 10:36 — Extra modellen: devstral, codestral, phi4-mini getest.
5. 6 maart, 13:34 — Marketing benchmark gestart. Alle modellen, alle taken.
6. 7 maart, 00:00-06:00 — Marketing runs door de nacht (Qwen modellen duren uren per run).
7. 7 maart, 16:12 — Claude Haiku + Sonnet via API getest. Referentiepunt.
8. 7 maart, 16:19-20:21 — Alle lokale modellen opnieuw op marketing, individueel.
9. 7-8 maart — Coding V2 benchmark: hardere taken, maximale token settings.

Conclusies van deze lokale LLM benchmark

Modelkeuze hangt af van de taak

Vijf lessen

1. Token limits zijn cruciaal bij thinking-modellen — te laag en je meet het plafond, niet het model. Dit is de #1 fout in de meeste LLM benchmarks.

2. MoE architectuur maakt het verschil bij beperkt geheugen — 35B parameters in 23GB, activeert slechts 3.5B per token. Het 27B dense model faalde compleet waar het 35B MoE prima draaide.

3. Groter is niet altijd beter — phi4-mini (2 GB) scoort 90% completeness op coding taken en is het snelste model in elke categorie.

4. Marketing taken zijn fundamenteel anders dan coding taken — thinking mode helpt bij code, schaadt bij marketing. Test altijd op je eigen use case.

5. Nederlandse taalvaardigheid varieert sterk — Qwen 3.5 doet goed Nederlands. Mistral-modellen zijn wisselend ("Winter is op de deur" in plaats van "voor de deur"). phi4-mini is correct maar compact.

Het multi-model antwoord

In de praktijk gebruik ik nu een mix:

• phi4-mini voor snelle, gestructureerde analyses en intelligence queries
• qwen2.5-coder:14b voor code generatie en refactoring
• devstral voor snelle marketing drafts
• qwen3.5:35b-a3b voor complexe redeneer-taken en hoogwaardige Nederlandse content

Het is geen kwestie van "het beste model" kiezen. Het is een kwestie van het juiste model voor de juiste taak — dezelfde filosofie achter mijn AI-architectuur aanpak.

📖 Lees ook: Waarom een Mac de Beste Keuze Is voor AI Lokaal Draaien — Waarom unified memory het verschil maakt voor lokale LLMs

Technische details

Benchmark framework

Het framework is zelf gebouwd en bevat:

• Automatische Ollama model management (pull, unload, memory cleanup)
• Progress checkpointing met JSON (resume na crash)
• Markdown + JSON rapportage
• Memory monitoring (psutil) tussen runs
• macOS purge voor geheugenoptimalisatie

Reproduceren

Alle ruwe data

De benchmark resultaten (30+ JSON/Markdown rapportbestanden) staan in de .claude/vnx-system/reports/benchmarks/ directory van de SEOcrawler repo.

📖 Lees ook: Mijn AI Development Stack: Tools, Workflow en Wat het Kost — De volledige tool stack waarin deze modellen draaien