De auteur heeft verschillende kleine taalmodellen (LLM's), waaronder Qwen en Gemma via Ollama, getest op een M1 Pro laptop met 16GB RAM. De testen bestonden uit 21 praktische data-engineering taken, zoals het schrijven van SQL, Python bugfixes en JSON-extractie.
De belangrijkste conclusies zijn:
- Prestaties: Er is een significante verbetering zichtbaar in kleine modellen over het afgelopen jaar. Gemma 4 scoorde het hoogst met een slaagpercentage van 90%.
- De 'Reasoning Tax': Moderne redeneermodellen vertragen de doorlooptijd enorm op lokale hardware vanwege de grote hoeveelheid gegenereerde reasoning tokens.
- Betrouwbaarheid: Hoewel lokale modellen snel kunnen reageren, zijn ze minder betrouwbaar dan zoekmachines en geven ze zelfverzekerd onjuiste antwoorden.
- Kosten: Door de extreem lage prijzen van API's (zoals DeepSeek) is lokaal draaien financieel niet interessant als men de eigen wachttijd meerekent.
De auteur concludeert dat lokale modellen vooral waardevol zijn voor privacy, offline gebruik of specifieke taken zoals JSON-extractie. Het model gemma4:e4b-it-qat wordt aanbevolen als de beste keuze voor deze hardware.
Ik heb lokale LLM's gebenchmarkt op de laptop die ik al heb
De benchmarks die dit advies ondersteunen, hebben echter een hardwareprobleem. De verslagen waarin daadwerkelijk iets wordt gemeten, maken gebruik van Mac Studio's of 128GB M5 Max laptops, en de koppen in het nieuws zijn nog erger. DeepSeek V4 Flash "draait op een MacBook" als die MacBook een build van 128GB is die ongeveer $ 5.000 kost. Kimi K3 heeft open gewichten die acht H100's nodig hebben om alleen al geladen te worden. Eén gids van deze zomer was letterlijk getiteld "Open Weights You Can’t Run".
Mijn laptop is een M1 Pro uit 2021 met 16GB RAM. Hij is bijna vijf jaar oud en ik vermoed dat hij veel dichter bij de gemiddelde machine van een ontwikkelaar ligt dan alles in die benchmarks. Daarom heb ik gebenchmarkt wat hij daadwerkelijk kan.
De Setup
Ik heb vijf modellen getest, allemaal via Ollama binnengehaald en gekozen omdat ze in 16GB passen:
qwen3.5:4b en qwen3.5:9b: de huidige kleine modellen van Alibaba, die standaard nadenken voordat ze antwoorden.gemma4:e4b-it-qat en gemma4:12b-it-qat: de huidige kleine familie van Google, in de quantization-aware builds.qwen2.5:7b: een model uit eind 2024, als baseline om te zien of een jaar vooruitgang zichtbaar is bij deze grootte.
De huidige modellen waar iedereen het over heeft, maakten geen deel uit van de lijst, en dat is op zichzelf al een bevinding. glm-4.7-flash en qwen3-coder klinken beide klein, maar zijn downloads van 19GB. Qwen3.8-27B, aangekondigd in de week dat ik dit uitvoerde, heeft ongeveer 17GB nodig en de gewichten waren toen nog niet eens downloadbaar (ze werden beloofd voor de week dat dit bericht verschijnt). Op 16GB RAM is de lijst met modellen die je daadwerkelijk kunt draaien veel korter dan online discussies suggereren.
De taken bestaan uit 21 problemen van het type dat in een week van een data-engineer voorkomt, verdeeld over zes categorieën:
- Het schrijven van DuckDB SQL tegen een gevulde database.
- Het repareren van foutieve Python-bestanden met een falende testsuite.
- Het extraheren van JSON uit rommelige tekst, zoals Airflow-logs en facturatie-e-mails.
- Voorspellen wat lastige Python-snippets printen.
- Het beantwoorden van korte vragen die ik normaal gesproken zou googelen.
- Het vinden van feiten die zijn geplaatst in een runbook van 7.400 tokens.
Alles wordt beoordeeld door code, niet door mij de antwoorden te laten lezen: gegenereerde SQL wordt uitgevoerd en rij voor rij vergeleken met een referentiequery, bugfixes moeten slagen via pytest, extracties worden veld voor veld gecontroleerd. Elk model heeft ook een temperature-instelling die bepaalt hoeveel willekeur er in de antwoorden gaat; ik heb deze op nul gezet en alles twee keer gedraaid, zodat elk model 42 runs krijgt.
Wat is er geslaagd?
| Model | Grootte | Slaagpercentage | Totale doorlooptijd (wall time) |
|---|
gemma4:12b-it-qat | 7.2GB | 38/42 (90%) | 123 min |
gemma4:e4b-it-qat | 6.1GB | 36/42 (86%) | 18 min |
qwen3.5:9b | 6.6GB | 34/42 (81%) | 114 min |
qwen3.5:4b | 3.4GB | 26/42 (62%) | 125 min |
qwen2.5:7b | 4.7GB | 22/42 (52%) | 3 min |
Twee dingen verrasten me hier. Ten eerste hoe veel deze modellen correct beantwoorden. Gemma 4's 12B beantwoordde 90% van de suite correct, inclusief 6/6 bugfixes die een daadwerkelijke testsuite moesten passeren en 8/10 SQL-vragen beoordeeld op uitvoering. De baseline uit 2024 haalde 52% op dezelfde taken en scoorde 0 van de 6 op het voorspellen wat Python-code print, dus de modellen zijn over het jaar heen verbeterd, althans tussen deze twee.
De tweede verrassing is de kolom met doorlooptijd. De oude qwen2.5 knalde door de hele suite in 3 minuten. De modellen die hem versloegen, hadden één tot twee uur nodig voor dezelfde 42 runs, en bijna dat hele gat wordt veroorzaakt door reasoning tokens (redeneertokens).
De "Reasoning Tax"
De huidige generatie denkt na voordat hij antwoordt, en op een laptop gaat daar de meeste tijd in zitten.
Bij mijn eerste run beperkte ik de generatie tot 3.072 tokens per taak, wat niet veel is gezien hoeveel tokens iets als Claude gebruikt voor één verzoek. De qwen3.5-modellen bereikten die limiet in 48 van de 84 runs; ze besteedden het volledige budget aan redeneren en produceerden nooit een antwoord. Beiden scoorden rond de 40-57%. Ik verdubbelde het budget naar 8.192 en draaide alles opnieuw: beiden behaalden precies tien succesvolle runs extra. De capaciteit was er, de modellen hadden alleen duizenden extra tokens nodig om bij het antwoord te komen. Sommige runs schoten ook door het verdubbelde budget heen. qwen3.5:9b besteedde acht minuten en 34.000 tekens aan nadenken over één SQL-vraag en kwam alsnog tekort.
De Gemma-modellen denken ook na, meestal minder, maar niet altijd. In één run besteedde gemma4:12b 14 minuten aan redeneren over welke numerieke chmod-modus overeenkomt met rwxr-xr–, produceerde 19.000 tekens aan nadenken, en antwoordde "750". Het juiste antwoord is "754".
Bij een API verschijnt dit gedrag als een kostenpost; de redeneertokens worden gefactureerd zoals alle andere tokens. Lokaal vertaalt dit zich in tijd die je moet wachten.
Zou je stoppen met Googelen?
De vraag over snelheid waar ik echt om gaf: verslaat het vragen aan een lokaal model een zoekmachine voor een snelle feitelijke opzoeking?
Voor de modellen zonder "denkproces" is het antwoord ja, althans qua latentie. Met het model reeds geladen kwam het antwoord op "welke poort gebruikt Postgres" in 0,6 tot 1,1 seconde terug van gemma4:e4b en qwen2.5. Dat is sneller dan ik de query in een browser kan typen. De redeneermodellen kunnen hier niet meedingen: qwen3.5:9b deed er gemiddeld 17 seconden over per korte vraag en de 4B-versie gemiddeld 38, wat langzamer is dan elke zoekmachine.
Het probleem is wat er met die snelheid terugkomt. Drie modellen gaven drie verschillende foute antwoorden op de chmod-vraag: 752, 744, 750. Twee modellen suggereerden git reset HEAD~ of HEAD^ voor "maak de laatste commit ongedaan maar houd wijzigingen staged", wat precies het tegenovergestelde doet; een gewone git reset maakt de wijzigingen juist unstaged. De foute antwoorden kwamen net zo snel en net zo zelfverzekerd terug als de juiste. Een zoekresultatenpagina geeft je Stack Overflow-stemmen en drie concurrerende antwoorden om te kruiscontoleren. Een lokaal model geeft je één antwoord en geen manier om te weten of het klopt.
De test met lange documenten
Het plakken van een runbook van 7.400 tokens en het stellen van een vraag is waar de laptop-hardware zijn werkelijke limiet bereikt. Alle vijf de modellen vonden de geplaatste feiten, zelfs die aan het einde, dus de capaciteit is niet het probleem. Het probleem is het wachten: 32 seconden voor de eerste vraag op gemma4:e4b, 84 op qwen3.5:4b en 148 op gemma4:12b. Mijn M1 Pro verwerkt een inkomende prompt met 130 tot 330 tokens per seconde, en dat is waarom niemand coding agents draait op laptopmodellen. Een harness in de stijl van Claude Code stuurt tienduizenden tokens aan systeemprompts en context mee bij elk verzoek. Bij laptopsnelheden betekent dit dat je minuten moet wachten voordat het antwoord überhaupt begint, bij elk verzoek dat de agent maakt.
Een prettige verrassing: vervolgvragen over hetzelfde document kwamen snel terug (17 tot 40 seconden), omdat Ollama het reeds verwerkte document in het geheugen houdt. Chatten met één lang document werkt lokaal prima, maar alles wat bij elk verzoek een verse context verzendt, doet dat niet.
De financiën
Dit is de tabel waarvoor ik deze benchmark eigenlijk heb gebouwd. De hele suite van 210 runs gebruikte 162.000 inputtokens en 412.000 outputtokens. Berekend tegen de huidige API-tarieven kost dit alles samen:
| Provider | Gehele benchmark |
|---|
| Claude Opus 5 ($5/$25 per 1M) | $ 11,11 |
| GPT-5.6 Terra ($2/$12) | $ 5,27 |
| DeepSeek V4 Flash ($0,14/$0,28) | $ 0,14 |
| Muse contributor tier ($0,10/$0,20) | $ 0,10 |
De volledige benchmark, elk model en elke herhaling, kost veertien cent tegen de prijzen van DeepSeek, en Meta zal waarschijnlijk nog lager gaan als je ze toestaat om op jouw prompts te trainen. Daartegenover staat dat mijn laptop 6,4 uur besteedde aan het produceren van de lokale antwoorden. De elektriciteit komt neer op een paar cent, dus lokaal is technisch gezien goedkoper dan Opus. Dat houdt echter op waar te zijn zodra mijn tijd iets waard is, en bij de prijzen van DeepSeek is er simpelweg niets te besparen. Wanneer Uber ingenieurs beperkt tot $ 1.500 per maand, kun je geen betekenisvol deel daarvan verplaatsen naar een machine die twee uur nodig heeft om werk van veertien cent te doen.
De echte reden om lokale modellen op een normale laptop te draaien is dus niet het geld. Het zijn de situaties waarin de API geen optie is: data die de machine niet mag verlaten, offline werken, of wanneer de API plat ligt. En ik vond nog één reden die ik niet verwachtte: gemma4:e4b deed elke extractietaak in de suite correct, en het draaien ervan kost niets, ongeacht hoe vaak ik het doe. Dat voelt anders dan het gebruik van een API waar elk verzoek bijdraagt aan de rekening.
Wat ik daadwerkelijk zou behouden
Als één model een plek op deze machine verdient, dan is dat gemma4:e4b-it-qat. Het haalde 86% van de suite met 30 tokens per seconde, beantwoordt korte vragen in minder dan een seconde en voltooide de hele benchmark in 18 minuten, terwijl de 12B-versie twee uur nodig had voor vier procentpunten meer. Dat is genoeg om het te behouden als offline fallback en als gratis JSON-extractietool.
De rest kan weg. De 12B is te traag op deze hardware, de redeneermodellen doen er langer over dan de antwoorden waard zijn, en de baseline uit 2024 was een mooie herinnering aan hoeveel deze kleine modellen in een jaar tijd zijn verbeterd (van 52% naar 90% bij ongeveer dezelfde grootte).
Dus, terug naar het advies aan het begin van dit bericht: het lokaal draaien van modellen werkt beter dan ik had verwacht op de laptop die ik al heb. Maar het zal je AI-rekening niet verlagen, en die rekening was precies de reden om dit in de eerste plaats te proberen.
Ik heb lokale LLM's gebenchmarkt op de laptop die ik al heb
De benchmarks die dit advies ondersteunen, hebben echter een hardwareprobleem. De verslagen waarin daadwerkelijk iets wordt gemeten, maken gebruik van Mac Studio's of 128GB M5 Max laptops, en de koppen in het nieuws zijn nog erger. DeepSeek V4 Flash "draait op een MacBook" als die MacBook een build van 128GB is die ongeveer $ 5.000 kost. Kimi K3 heeft open gewichten die acht H100's nodig hebben om alleen al geladen te worden. Eén gids van deze zomer was letterlijk getiteld "Open Weights You Can’t Run".
Mijn laptop is een M1 Pro uit 2021 met 16GB RAM. Hij is bijna vijf jaar oud en ik vermoed dat hij veel dichter bij de gemiddelde machine van een ontwikkelaar ligt dan alles in die benchmarks. Daarom heb ik gebenchmarkt wat hij daadwerkelijk kan.
De Setup
Ik heb vijf modellen getest, allemaal via Ollama binnengehaald en gekozen omdat ze in 16GB passen:
qwen3.5:4b en qwen3.5:9b: de huidige kleine modellen van Alibaba, die standaard nadenken voordat ze antwoorden.gemma4:e4b-it-qat en gemma4:12b-it-qat: de huidige kleine familie van Google, in de quantization-aware builds.qwen2.5:7b: een model uit eind 2024, als baseline om te zien of een jaar vooruitgang zichtbaar is bij deze grootte.
De huidige modellen waar iedereen het over heeft, maakten geen deel uit van de lijst, en dat is op zichzelf al een bevinding. glm-4.7-flash en qwen3-coder klinken beide klein, maar zijn downloads van 19GB. Qwen3.8-27B, aangekondigd in de week dat ik dit uitvoerde, heeft ongeveer 17GB nodig en de gewichten waren toen nog niet eens downloadbaar (ze werden beloofd voor de week dat dit bericht verschijnt). Op 16GB RAM is de lijst met modellen die je daadwerkelijk kunt draaien veel korter dan online discussies suggereren.
De taken bestaan uit 21 problemen van het type dat in een week van een data-engineer voorkomt, verdeeld over zes categorieën:
- Het schrijven van DuckDB SQL tegen een gevulde database.
- Het repareren van foutieve Python-bestanden met een falende testsuite.
- Het extraheren van JSON uit rommelige tekst, zoals Airflow-logs en facturatie-e-mails.
- Voorspellen wat lastige Python-snippets printen.
- Het beantwoorden van korte vragen die ik normaal gesproken zou googelen.
- Het vinden van feiten die zijn geplaatst in een runbook van 7.400 tokens.
Alles wordt beoordeeld door code, niet door mij de antwoorden te laten lezen: gegenereerde SQL wordt uitgevoerd en rij voor rij vergeleken met een referentiequery, bugfixes moeten slagen via pytest, extracties worden veld voor veld gecontroleerd. Elk model heeft ook een temperature-instelling die bepaalt hoeveel willekeur er in de antwoorden gaat; ik heb deze op nul gezet en alles twee keer gedraaid, zodat elk model 42 runs krijgt.
Wat is er geslaagd?
| Model | Grootte | Slaagpercentage | Totale doorlooptijd (wall time) |
|---|
gemma4:12b-it-qat | 7.2GB | 38/42 (90%) | 123 min |
gemma4:e4b-it-qat | 6.1GB | 36/42 (86%) | 18 min |
qwen3.5:9b | 6.6GB | 34/42 (81%) | 114 min |
qwen3.5:4b | 3.4GB | 26/42 (62%) | 125 min |
qwen2.5:7b | 4.7GB | 22/42 (52%) | 3 min |
Twee dingen verrasten me hier. Ten eerste hoe veel deze modellen correct beantwoorden. Gemma 4's 12B beantwoordde 90% van de suite correct, inclusief 6/6 bugfixes die een daadwerkelijke testsuite moesten passeren en 8/10 SQL-vragen beoordeeld op uitvoering. De baseline uit 2024 haalde 52% op dezelfde taken en scoorde 0 van de 6 op het voorspellen wat Python-code print, dus de modellen zijn over het jaar heen verbeterd, althans tussen deze twee.
De tweede verrassing is de kolom met doorlooptijd. De oude qwen2.5 knalde door de hele suite in 3 minuten. De modellen die hem versloegen, hadden één tot twee uur nodig voor dezelfde 42 runs, en bijna dat hele gat wordt veroorzaakt door reasoning tokens (redeneertokens).
De "Reasoning Tax"
De huidige generatie denkt na voordat hij antwoordt, en op een laptop gaat daar de meeste tijd in zitten.
Bij mijn eerste run beperkte ik de generatie tot 3.072 tokens per taak, wat niet veel is gezien hoeveel tokens iets als Claude gebruikt voor één verzoek. De qwen3.5-modellen bereikten die limiet in 48 van de 84 runs; ze besteedden het volledige budget aan redeneren en produceerden nooit een antwoord. Beiden scoorden rond de 40-57%. Ik verdubbelde het budget naar 8.192 en draaide alles opnieuw: beiden behaalden precies tien succesvolle runs extra. De capaciteit was er, de modellen hadden alleen duizenden extra tokens nodig om bij het antwoord te komen. Sommige runs schoten ook door het verdubbelde budget heen. qwen3.5:9b besteedde acht minuten en 34.000 tekens aan nadenken over één SQL-vraag en kwam alsnog tekort.
De Gemma-modellen denken ook na, meestal minder, maar niet altijd. In één run besteedde gemma4:12b 14 minuten aan redeneren over welke numerieke chmod-modus overeenkomt met rwxr-xr–, produceerde 19.000 tekens aan nadenken, en antwoordde "750". Het juiste antwoord is "754".
Bij een API verschijnt dit gedrag als een kostenpost; de redeneertokens worden gefactureerd zoals alle andere tokens. Lokaal vertaalt dit zich in tijd die je moet wachten.
Zou je stoppen met Googelen?
De vraag over snelheid waar ik echt om gaf: verslaat het vragen aan een lokaal model een zoekmachine voor een snelle feitelijke opzoeking?
Voor de modellen zonder "denkproces" is het antwoord ja, althans qua latentie. Met het model reeds geladen kwam het antwoord op "welke poort gebruikt Postgres" in 0,6 tot 1,1 seconde terug van gemma4:e4b en qwen2.5. Dat is sneller dan ik de query in een browser kan typen. De redeneermodellen kunnen hier niet meedingen: qwen3.5:9b deed er gemiddeld 17 seconden over per korte vraag en de 4B-versie gemiddeld 38, wat langzamer is dan elke zoekmachine.
Het probleem is wat er met die snelheid terugkomt. Drie modellen gaven drie verschillende foute antwoorden op de chmod-vraag: 752, 744, 750. Twee modellen suggereerden git reset HEAD~ of HEAD^ voor "maak de laatste commit ongedaan maar houd wijzigingen staged", wat precies het tegenovergestelde doet; een gewone git reset maakt de wijzigingen juist unstaged. De foute antwoorden kwamen net zo snel en net zo zelfverzekerd terug als de juiste. Een zoekresultatenpagina geeft je Stack Overflow-stemmen en drie concurrerende antwoorden om te kruiscontoleren. Een lokaal model geeft je één antwoord en geen manier om te weten of het klopt.
De test met lange documenten
Het plakken van een runbook van 7.400 tokens en het stellen van een vraag is waar de laptop-hardware zijn werkelijke limiet bereikt. Alle vijf de modellen vonden de geplaatste feiten, zelfs die aan het einde, dus de capaciteit is niet het probleem. Het probleem is het wachten: 32 seconden voor de eerste vraag op gemma4:e4b, 84 op qwen3.5:4b en 148 op gemma4:12b. Mijn M1 Pro verwerkt een inkomende prompt met 130 tot 330 tokens per seconde, en dat is waarom niemand coding agents draait op laptopmodellen. Een harness in de stijl van Claude Code stuurt tienduizenden tokens aan systeemprompts en context mee bij elk verzoek. Bij laptopsnelheden betekent dit dat je minuten moet wachten voordat het antwoord überhaupt begint, bij elk verzoek dat de agent maakt.
Een prettige verrassing: vervolgvragen over hetzelfde document kwamen snel terug (17 tot 40 seconden), omdat Ollama het reeds verwerkte document in het geheugen houdt. Chatten met één lang document werkt lokaal prima, maar alles wat bij elk verzoek een verse context verzendt, doet dat niet.
De financiën
Dit is de tabel waarvoor ik deze benchmark eigenlijk heb gebouwd. De hele suite van 210 runs gebruikte 162.000 inputtokens en 412.000 outputtokens. Berekend tegen de huidige API-tarieven kost dit alles samen:
| Provider | Gehele benchmark |
|---|
| Claude Opus 5 ($5/$25 per 1M) | $ 11,11 |
| GPT-5.6 Terra ($2/$12) | $ 5,27 |
| DeepSeek V4 Flash ($0,14/$0,28) | $ 0,14 |
| Muse contributor tier ($0,10/$0,20) | $ 0,10 |
De volledige benchmark, elk model en elke herhaling, kost veertien cent tegen de prijzen van DeepSeek, en Meta zal waarschijnlijk nog lager gaan als je ze toestaat om op jouw prompts te trainen. Daartegenover staat dat mijn laptop 6,4 uur besteedde aan het produceren van de lokale antwoorden. De elektriciteit komt neer op een paar cent, dus lokaal is technisch gezien goedkoper dan Opus. Dat houdt echter op waar te zijn zodra mijn tijd iets waard is, en bij de prijzen van DeepSeek is er simpelweg niets te besparen. Wanneer Uber ingenieurs beperkt tot $ 1.500 per maand, kun je geen betekenisvol deel daarvan verplaatsen naar een machine die twee uur nodig heeft om werk van veertien cent te doen.
De echte reden om lokale modellen op een normale laptop te draaien is dus niet het geld. Het zijn de situaties waarin de API geen optie is: data die de machine niet mag verlaten, offline werken, of wanneer de API plat ligt. En ik vond nog één reden die ik niet verwachtte: gemma4:e4b deed elke extractietaak in de suite correct, en het draaien ervan kost niets, ongeacht hoe vaak ik het doe. Dat voelt anders dan het gebruik van een API waar elk verzoek bijdraagt aan de rekening.
Wat ik daadwerkelijk zou behouden
Als één model een plek op deze machine verdient, dan is dat gemma4:e4b-it-qat. Het haalde 86% van de suite met 30 tokens per seconde, beantwoordt korte vragen in minder dan een seconde en voltooide de hele benchmark in 18 minuten, terwijl de 12B-versie twee uur nodig had voor vier procentpunten meer. Dat is genoeg om het te behouden als offline fallback en als gratis JSON-extractietool.
De rest kan weg. De 12B is te traag op deze hardware, de redeneermodellen doen er langer over dan de antwoorden waard zijn, en de baseline uit 2024 was een mooie herinnering aan hoeveel deze kleine modellen in een jaar tijd zijn verbeterd (van 52% naar 90% bij ongeveer dezelfde grootte).
Dus, terug naar het advies aan het begin van dit bericht: het lokaal draaien van modellen werkt beter dan ik had verwacht op de laptop die ik al heb. Maar het zal je AI-rekening niet verlagen, en die rekening was precies de reden om dit in de eerste plaats te proberen.
Groetjes,