Hoeveel VRAM heb je nodig voor een AI-model?

Bijna elk gesprek over AI-compute begint met dezelfde vraag: wat kost dit per maand? Dat is de verkeerde volgorde. Voordat een prijs betekenis heeft, moet eerst vaststaan of het model dat je wil draaien uberhaupt past in het geheugen van de GPU die je huurt. Bedrijven bekijken een prijstabel voordat ze weten welk VRAM-minimum ze nodig hebben, en komen er pas bij de eerste trage of vastlopende sessie achter dat de gekozen kaart te krap was. De GPU-keuzehulp draait die volgorde bewust om: eerst je workload, dan het VRAM-minimum, dan pas de aanbieder en de prijs.

Dit artikel legt de rekenkunde achter die volgorde uit, in gewone taal. Geen datacenter-jargon, wel de vuistregels die bepalen of een model op een zware laptop past of om een datacenter-GPU vraagt.

/ 01Vraag overslaan

De vraag die de meeste MKB'ers overslaan

Wie een AI-model wil draaien, googelt meestal eerst op een prijs: wat kost een GPU per uur, wat kost een A100, wat kost een H100. Dat is een begrijpelijke reflex, maar hij slaat een stap over. Een GPU heeft een vast geheugen aan boord, het VRAM, en een model dat groter is dan dat geheugen past er simpelweg niet in. Geen enkele prijsvergelijking vertelt je dat vooraf.

Het gevolg zien we terug bij bedrijven die al een GPU-abonnement hadden lopen voordat wij erbij kwamen kijken: een 13B-model dat traag reageert omdat de gehuurde kaart net te weinig geheugen had, of een 24 GB-kaart die was ingekocht voor een taak die eigenlijk 40 GB vraagt. Dat is geld weggegooid aan de verkeerde kant van de fout: te weinig ingekocht voor de taak.

De GPU-keuzehulp lost dat op door de volgorde om te draaien. Je beantwoordt drie vragen over je workload, je verwachte uren per maand en of je data gevoelig is, en krijgt daarna pas een VRAM-minimum, passende aanbieders en een kostenindicatie te zien. Dit artikel legt uit waar dat VRAM-minimum vandaan komt, zodat het geen zwarte doos blijft.

/ 02VRAM-bottleneck

VRAM in gewone taal: waarom geheugen de bottleneck is

Een AI-model bestaat uit miljarden getallen, de parameters, die tijdens elke berekening in het geheugen van de GPU moeten staan. Niet in het systeemgeheugen van de computer, maar in het geheugen dat direct naast de rekenkernen van de kaart zit: VRAM. Die nabijheid is precies waarom een GPU snel is. De rekenkernen hoeven niet te wachten tot data van elders wordt aangevoerd.

Past een model niet volledig in VRAM, dan moet een deel van het model uitwijken naar het langzamere systeemgeheugen. Dat heet offloading, en het werkt, maar tegen een prijs: de rekenkernen moeten dan telkens wachten op data die van verder weg komt. In de praktijk daalt de snelheid van inferentie dan ongeveer tien keer, soms meer. Een antwoord dat normaal binnen twee seconden verschijnt, kost dan ineens twintig seconden of langer.

Dit is waarom VRAM, niet CPU-rekenkracht, meestal de eerste bottleneck is bij een AI-model. Een snellere processor helpt niet als het model niet in het geheugen van de GPU past. De vraag "welke GPU heb ik nodig" is dus in de kern een geheugenvraag, geen snelheidsvraag.

/ 03Vuistregel

De vuistregel: van parameters naar gigabytes

De vuistregel die we hanteren, en die ook in meerdere technische bronnen terugkomt: reken op ongeveer 0,5 tot 1 GB VRAM per miljard modelparameters bij 4-bit quantisatie (Q4), de meest gebruikte precisie voor praktisch MKB-gebruik.¹ Dat is een richtwaarde, geen exacte specificatie: de precieze uitkomst hangt af van de contextlengte, de implementatie en het type model.

Het patroon is duidelijk: elke stap in modelgrootte vraagt niet evenredig, maar fors meer geheugen, en de stap van 13B naar 70B is de stap waarop een consumer-kaart het niet meer redt. Een 70B-model bij volledige FP16-precisie vraagt om twee GPU's van 80 GB naast elkaar, wat precies verklaart waarom die modellen vrijwel altijd op datacenter-kaarten draaien en zelden op eigen apparatuur.

/ 04Quantisatie

Quantisatie: hoe FP16, INT8 en INT4 de vraag halveren

Quantisatie is de belangrijkste hendel om VRAM-vraag te verlagen zonder een ander model te kiezen. In gewone taal: elke parameter wordt normaal opgeslagen als een getal met veel decimalen (FP16, 16-bit precisie). Quantisatie rondt die getallen af naar minder bits, INT8 of INT4, waardoor elke parameter minder geheugen inneemt. Elke stap halveert ongeveer het geheugengebruik, tegen een beetje verlies aan precisie.²

Dit is meteen waarom de vuistregel uit de vorige sectie uitgaat van Q4: het is de precisie die de meeste praktische MKB-toepassingen aankunnen, en die de VRAM-vraag het meest verlaagt zonder het model onbruikbaar te maken. Wil je toch FP16 draaien, reken dan op puur gewicht ongeveer het vierdubbele VRAM ten opzichte van Q4, simpelweg omdat elke parameter dan 16 in plaats van 4 bits inneemt. In de praktijk valt het verschil vaak dichter bij het drievoudige uit, zoals de tabel hierboven ook laat zien, omdat een deel van het geheugengebruik (context, overhead) niet meeschaalt met de quantisatie.

/ 05VRAM per taak

VRAM per taak: chatbot, transcriptie, beeldgeneratie, finetunen

Modelgrootte is niet de enige factor. Het type werk bepaalt ook hoe zwaar de VRAM-vraag uitpakt, en dat is precies de indeling die de GPU-keuzehulp gebruikt om je naar een aanbieder te leiden.

Finetunen springt eruit als de zwaarste categorie, en dat is geen toeval. Bij inferentie (een model gebruiken) staat alleen het model zelf in het geheugen. Bij finetunen (een model bijscholen) komen daar de gradients en de optimizer-status bovenop: extra kopieën van de gewichten die nodig zijn om het model tijdens het trainen bij te stellen. De cijfers hierboven gaan uit van parameter-efficiënte finetuning (LoRA of QLoRA), waarbij het gros van de oorspronkelijke gewichten bevroren blijft en alleen een kleine set extra parameters wordt bijgesteld. Dat verklaart waarom finetunen al bij een relatief klein model om een datacenter-GPU vraagt, terwijl hetzelfde model prima inferentie draait op een consumer-kaart. Volledige finetuning, waarbij alle gewichten van het model worden bijgesteld, vraagt aanzienlijk meer VRAM dan deze tabel laat zien en is voor de meeste MKB-toepassingen ook niet de aangewezen route: LoRA of QLoRA levert doorgaans een vergelijkbaar resultaat tegen een fractie van de rekenkosten. Of finetunen voor jouw situatie de juiste route is, of dat prompting of RAG goedkoper en sneller hetzelfde resultaat geeft, werken we uit in AI trainen op eigen bedrijfsdata: kan dat, wat kost het?.

Let op: de GPU-keuzehulp rekent voor finetunen bewust met een hogere ondergrens dan de bandbreedte hierboven (voor een model in de 13 miljard parameters klasse bijvoorbeeld 48 GB, waar de tabel 20 tot 40 GB laat zien): de tabel toont een illustratieve orde van grootte over meerdere modellen en datasets heen, terwijl de tool één harde, boekbare ondergrens moet geven die ook ruimte overlaat voor een langere contextlengte en marge op de optimizer-status. Beide cijfers kloppen, ze beantwoorden alleen een andere vraag.

/ 06Van VRAM naar aanbieder

Van VRAM-minimum naar aanbieder en maandprijs

Zodra het VRAM-minimum vaststaat, is de rest een kwestie van filteren en rekenen. Vier stappen die we zelf hanteren:

1. Bepaal je workload-categorie. Chatbot en RAG, batch-transcriptie, beeld- of videogeneratie, of finetunen: elke categorie heeft een eigen VRAM-orde, zoals hierboven.
2. Haal het VRAM-minimum op. De GPU-keuzehulp doet dit voor je concrete situatie, inclusief modelgrootte en gekozen quantisatie, in plaats van een vuistregel handmatig toe te passen.
3. Filter op datagevoeligheid. Moet je data binnen de EU of EER blijven, dan valt een deel van de internationale aanbieders af. De keuzehulp filtert hier automatisch op; zie ook de afweging tussen Europese en Amerikaanse GPU-aanbieders voor de achtergrond.
4. Vergelijk uurtarief tegen maandlast van eigen apparatuur. Boven een bepaald aantal draaiuren per maand loopt huren op tot voorbij de kosten van een eigen machine. De rekenregel daarvoor staat op GPU huren of kopen.

Het actuele prijsoverzicht van externe aanbieders staat op /gpu-huren, met tarieven die per uur kunnen wijzigen, dus die typen we hier bewust niet over. Past geen enkele externe aanbieder goed bij je situatie, dan leveren wij ook zelf GPU-capaciteit uit eigen beheer, op aanvraag en op maat samengesteld, en bouwen en beheren we on-premise AI-workstations en servers bij je op locatie. Speelt bij die keuze meer mee dan alleen VRAM en prijs, zoals datasoevereiniteit of latency, dan geeft on-premise AI versus cloud de bredere beslisboom.

/ 07Te veel VRAM

Wanneer je te veel VRAM inkoopt (vaker dan te weinig)

De fout die we vaker zien dan te weinig VRAM inkopen, is te veel inkopen. Een bedrijf huurt of koopt een zware datacenter-kaart met 80 GB VRAM voor een taak die comfortabel op 16 tot 24 GB past. Dat kost maandelijks geld zonder dat er ergens een voordeel tegenover staat: het model draait niet sneller of beter, alleen duurder.

Precies dit is waar de GPU-keuzehulp voor is gebouwd: niet automatisch de zwaarste kaart adviseren, maar het minimum dat past bij jouw workload. Dat is meestal minder GPU dan verwacht, niet meer.

/ 08Volgende stap

Drie volgende stappen

Je weet nu waar een VRAM-minimum vandaan komt en waarom zowel te weinig als te veel inkopen een dure keuze is. Drie concrete stappen:

1. Doe de GPU-keuzehulp voor jouw workload. De GPU-keuzehulp rekent op basis van je workload, uren per maand en datagevoeligheid direct een VRAM-minimum, passende aanbieders en een kostenindicatie per maand uit.
2. Lees het actuele prijsoverzicht. Op /gpu-huren staan de actuele GPU-huurtarieven van externe aanbieders naast ons eigen aanbod, en op huren of kopen staat de rekenregel voor wanneer een eigen machine goedkoper wordt.
3. Twijfel je tussen huren en eigen apparatuur, plan een gesprek. Voor de volledige kosten-kant, van GPU-uur tot maandbudget, lees eerst AI-capaciteit kosten 2026. Wil je liever meteen sparren, plan dan een gratis adviesgesprek.