Als het niet werkt: out-of-memory, trage tokens en een GPU die niet meedoet

Door Ivo Donker — samengesteld met AI-ondersteuning · 7 augustus 2026

Elke installatiegids eindigt bij "het werkt", maar daarna begint het echte werk: modellen die niet laden, output die tergend langzaam is, of een videokaart die stil blijft staan. Deze gids is het foutzoek-artikel voor lokale LLM-opstellingen: symptoom, diagnose, oplossing; gecontroleerd op 2026-08-07. Binnen de canon van de gids bevindt deze pagina zich in pijler 2 ("Hardware, prestaties & energie"). Binnen de algemene route van de gids — kiezen, installeren, gebruiken, koppelen, en beheren of serveren — sluit deze pagina direct aan op de hardwarefase. Mocht je machine structureel tekortschieten, dan helpt de pagina hardware voor lokale llm om de basiseisen te bepalen, terwijl de gids llm op oude hardware optimaliseren je opties biedt voor oudere systemen.

Commando's, configuratiebestanden en instellingen in tools als Ollama, LM Studio en llama.cpp kunnen per softwareversie wijzigen. Het is daarom belangrijk om de documentatie van je specifieke client te raadplegen als de grafische schil of de commandoregelinterface afwijkt van de voorbeelden in dit artikel. Let er tevens op dat de controledatum van 2026-08-07 geldt als referentiepunt voor de huidige generatie open-weights modellen en runtime-engines.

Hardware-ondergrens als uitgangspunt

De voorbeelden in dit artikel gaan uit van een aantal realistische hardware-configuraties die als referentie dienen voor je eigen installatie. Een gangbaar uitgangspunt is een systeem met 16 GB werkgeheugen in combinatie met een model van 7 tot 8 miljard parameters (7-8B) in een 4-bits kwantisatie (Q4), wat neerkomt op ongeveer 5 GB geheugenbelasting. Dit draait op Windows of Linux met een dedicated videokaart met voldoende VRAM, of op een Apple Silicon Mac met unified memory. Voor wie snel wil experimenteren of beschikt over beperktere middelen, is 8 GB werkgeheugen met een compacter model van 3 tot 4 miljard parameters de ondergrens.

Wanneer je merkt dat jouw hardware ver onder deze specificaties zit en het model simpelweg weigert te functioneren, is het verstandig om je verwachtingen bij te stellen of over te stappen op een alternatieve configuratie. Een grondige analyse van wat je machine minimaal nodig heeft, vind je op de pagina over hardware voor lokale llm. Het doel van deze gids is niet om onmogelijke hardwaredromen waar te maken, maar om de knelpunten in je huidige lokale workflow systematisch op te lossen.

Stap 0: Diagnose — meet voordat je verandert

Voordat je willekeurig instellingen aanpast, configuratiebestanden herschrijft of modellen verwijdert, moet je exact vaststellen wat er onder de motorkap gebeurt. Veel gebruikers raken gefrustreerd doordat ze symptomen bestrijden in plaats van de werkelijke oorzaak. Een systematische diagnose begint met het beantwoorden van drie kernvragen: laadt het model überhaupt in het geheugen, hoeveel geheugen (RAM en VRAM) is er op dat moment in gebruik, en welke hardwarecomponent (CPU, GPU of geheugenbus) voert de berekeningen uit?

Om een objectief beeld te krijgen van de prestaties kun je gebruikmaken van een gestructureerd meetprotocol. Hiermee voorkom je dat je afgaat op subjectieve indrukken zoals "het voelt traag". Vergelijk je opstelling op een eerlijke manier met de handvatten op modellen vergelijken op eigen hardware. Bovendien is het nuttig om te kijken naar de verdeling van de latentie in plaats van te leunen op een enkel gemiddelde; hiervoor kun je terecht bij het meetprotocol voor latency percentielen meten op het netwerkende benchmark-subdomein.

Tijdens de diagnose controleer je de actieve processen via taakbeheer op Windows, activity monitor op macOS of commando's zoals top en nvidia-smi op Linux. Kijk specifiek naar de temperatuur van je processor en videokaart. Als de temperaturen oplopen tot het maximum, treedt er thermische throttling op en schakelt de hardware uit zelfbescherming terug in kloksnelheid, wat resulteert in extreme traagheid.

Symptoom 1: Out-of-memory (OOM)

Out-of-memory situaties behoren tot de meest voorkomende frustraties bij het lokaal draaien van taalmodellen. Het komt erop neer dat de gevraagde hoeveelheid data groter is dan de fysieke capaciteit van je RAM of VRAM, waardoor het besturingssysteem of de runtime-engine abrupt ingrijpt.

Herkenning van OOM

Je herkent dit symptoom aan harde foutmeldingen in je console of logbestanden. Veelvoorkomende meldingen zijn "CUDA out of memory", "cannot allocate memory", of een plotselinge segmentatie-fout (segmentation fault) op Linux. Soms crasht de applicatie direct bij het laden van het modelbestand, of zie je dat het systeem extreem langzaam wordt omdat het werkgeheugen volloopt en de computer massaal data begint weg te schrijven naar de trage harde schijf of SSD (paging of swapping).

Diagnose van OOM

Open tijdens het opstarten van het model je taakbeheer of activity monitor. Zie je het geheugenpercentage in een fractie van een seconde naar 99 procent schieten, gevolgd door een crash? Of draai je een commando zoals ollama ps om te zien welke processen actief zijn en hoeveel geheugen ze claimen? Vaak zie je dat het model wel probeert te laden, maar halverwege de lagen strandt omdat er simpelweg geen vrije gigabytes meer over zijn.

Oplossingen voor OOM in volgorde van impact

1. Kies een kleiner model of een kleinere kwantisatie: Als je huidige modelbestand te groot is voor je hardware, stap dan over naar een variant met minder parameters of een zwaardere compressie. Hoe kwantisatie werkt en welke kwaliteitsafwegingen hierbij horen, lees je op kwantisatie uitgelegd. Als je echt niet weet welk formaat past, raadpleeg dan lokaal model kiezen.
2. Verlaag de contextlengte: Een groter geheugenvenster vreet gigabytes aan werkgeheugen tijdens de inferentie. Door het venster te verkleinen, bespaar je direct geheugen. Dit wordt uitgebreid behandeld op context window optimaliseren lokaal.
3. Verplaats lagen naar de CPU: Als je videokaart te weinig VRAM heeft, kun je instellen dat een deel van de modelmatige lagen door de reguliere processor en het werkgeheugen wordt afgehandeld. Dit vertraagt de output wel, maar voorkomt een totale crash.
4. Accepteer de hardwaregrens: Soms past een model simpelweg niet. Als geen enkele instelling helpt, is het model te groot voor je machine. In dat geval kun je je heil zoeken bij hardware voor lokale llm om te zien wat je werkelijk nodig hebt.

Symptoom 2: Trage tokens

Trage tokens betekenen dat het model wel antwoord geeft, maar dat de snelheid per seconde ver achter blijft bij wat acceptabel is voor interactief gebruik. Waar een vlotte lokale setup al snel tientallen tokens per seconde genereert, kan een miseconfigureerd systeem terugvallen tot minder dan één woord per seconde.

Herkenning van trage tokens

Je merkt dit doordat woorden tergend langzaam op het scherm verschijnen, alsof iemand ze stuk voor stuk intypt. Dit is subjectief zolang je niet meet, maar zodra je merkt dat een simpele zin meer dan een minuut nodig heeft om te voltooien, is er sprake van een prestatieprobleem. Om dit objectief vast te leggen en te controleren of je optimalisaties effect hebben, kun je gebruikmaken van de richtlijnen op snelheid meten.

Oorzaken van trage tokens

De meest voorkomende oorzaak is CPU-fallback: de software is vergeten om de grafische kaart in te schakelen, waardoor de trage CPU alle berekeningen alleen moet uitvoeren. Andere oorzaken zijn een gigantische contextlengte die het werkgeheugen overbelast, thermische throttling door een loeiende ventilator, of het bereiken van de geheugenbandbreedte-limiet op geïntegreerde grafische chips, zoals beschreven in hardware voor lokale llm en llm op oude hardware optimaliseren.

Oplossingen voor trage tokens

1. Meet voor en na: Voer een vaste benchmark uit zodat je weet of een aanpassing effect heeft. Raadpleeg hiervoor snelheid meten.
2. Verklein de context: Lange documenten in de prompt zorgen voor zware berekeningen per gegenereerd token. Optimaliseer dit via context window optimaliseren lokaal.
3. Activeer speculatieve decoding: Indien je runtime-engine dit ondersteunt, kun je een klein hulpmodel inzetten om tokens voor te stellen die het grote model vervolgens in één klap goedkeurt.
4. Stel realistische verwachtingen in: Oudere hardware heeft fysieke beperkingen. Als je werkt met legacy-apparatuur, bekijk dan de optimalisatiestrategieën op llm op oude hardware optimaliseren.

Wanneer je te maken hebt met API-integraties waarin trage lokale responses optreden, moet je ook aan de applicatiekant maatregelen treffen. Hiervoor kun je de richtlijnen raadplegen over timeouts en cancellation om te zorgen dat je software niet vastloopt op trage antwoorden.

Symptoom 3: De GPU die niet meedoet

Een hardnekkig probleem is dat je weliswaar een krachtige videokaart in je computer hebt zitten, maar dat de LLM-software daar totaal geen gebruik van maakt. Het model draait volledig op de processor, waardoor de prestaties tegenvallen.

Herkenning van een slapende GPU

Je ziet dit doordat de generatiesnelheid erg laag is, terwijl je taakbeheer aangeeft dat de CPU op 100 procent draait en de grafische kaart werkeloos toekijkt. Commando's zoals ollama ps tonen aan dat het model volledig op de CPU is geladen, en hulpprogramma's zoals nvidia-smi op Windows of Linux tonen geen actieve LLM-processen in het VRAM.

Oorzaken van een ontbrekende GPU-acceleratie

Oorzaken variëren van ontbrekende of verouderde stuurprogramma's en een niet-ingeschakelde Metal-interface op macOS tot een miscommunicatie over CUDA-versies op Windows of Linux. Ook komt het voor dat de gebruiker de instellingen van de client (zoals LM Studio of Ollama) niet expliciet heeft verteld hoeveel lagen naar de grafische kaart moeten worden gestuurd.

Platform-specifiek controleoverzicht

Gebruik de onderstaande tabel om per besturingssysteem te controleren waar je moet kijken en welke actie je kunt ondernemen:

Veelgemaakte fouten bij het foutzoeken

Bij het oplossen van problemen trappen gebruikers vaak in dezelfde vallen. Het vermijden van deze fouten bespaart je uren aan frustratie:

• Te veel variabelen tegelijk wijzigen: Pas nooit tegelijk de kwantisatie, het model, de contextlengte en de hardware-instellingen aan. Als het dan ineens werkt, weet je niet welke wijziging het probleem heeft opgelost. Verander telkens één parameter en test opnieuw.
• Vergeten dat de theoretische achtergrond vaststaat: Probeer niet opnieuw uit te vinden waarom context geheugen kost of hoe kwantisatie werkt; raadpleeg in plaats daarvan de feitelijke documentatie zoals kv caching opbouw.
• Staren naar gemiddelden in plaats van uitschieters: Een gemiddelde snelheid zegt weinig als je model af en toe volledig stokt. Kijk altijd naar de verdeling van de prestaties.
• Het negeren van stroomverbruik en warmte: Lokale AI trekt veel energie. Een continu draaiende server slurpt al snel tientallen watts, wat leidt tot hitteproblemen. Controleer daarom je energiehuishouding via stroomverbruik lokale ai.
• Blindstaren op Engelse benchmarks bij Nederlandse invoer: Modellen reageren anders op Nederlandse teksten. Test altijd met realistische lokale input. Een voorbeeld hiervan is een trage Nederlandse samenvatting die na het verkleinen van de context of het inschakelen van de GPU plotseling op acceptabele snelheid binnenkomt. Wil je de kwaliteit van de Nederlandse output optimaliseren, bekijk dan beter nederlands.

Wanneer je moet stoppen met foutzoeken

Er komt een moment waarop verdere troubleshooting geen zin meer heeft. Als je hardware structureel te klein is voor de taken die je wilt uitvoeren — iets wat je kunt verifiëren via hardware voor lokale llm of llm op oude hardware optimaliseren — dan blijft elke poging dweilen met de kraan open. Een model dat door fysieke beperkingen niet past, zal nooit stabiel draaien.

In dergelijke situaties is het verstandig om de knoop door te hakken en te kiezen voor een alternatieve route. Je kunt overstappen op een extern aangeboden API-dienst. Om ervoor te zorgen dat je applicatie robuust blijft functioneren wanneer je lokale setup onverhoopt uitvalt of tekortschiet, kun je fallbacks inbouwen aan de hand van de handleiding op robuuste integraties.

Privacy en energie bij lokaal draaien

Een van de voornaamste drijfveren om LLM's lokaal te draaien is het waarborgen van je privacy. Bij een correct geconfigureerde lokale opstelling verlaat geen enkele prompt, document of gegenereerd antwoord je eigen machine; alle berekeningen vinden lokaal plaats binnen je eigen netwerkdomein. Meer hierover lees je op privacyvriendelijk ai.

Daarnaast speelt energie een cruciale rol bij langdurig gebruik. Het continu belasten van een videokaart of processor zorgt voor een aanzienlijk stroomverbruik dat kan oplopen tot enkele tientallen of zelfs honderden watts per uur, afhankelijk van je hardware. Wie grip wil houden op de energiekosten van doorlopende lokale servers, doet er goed aan om de inzichten op stroomverbruik lokale ai door te nemen.

Gecontroleerd op 2026-08-07.