← terug

10 juni 2026

GPU-infra zonder mist: VRAM, batching, latency en wat AI echt kost

Er landt een offerte op je bureau. Een server met vier GPU's, prijskaartje ergens tussen een goede leaseauto en een klein huis. Of een cloudvoorstel: zoveel euro per GPU per uur, maal 24, maal 365. Iemand moet ja of nee zeggen, en die iemand ben jij. Niet omdat je hardware-expert bent, maar omdat het over budget en risico gaat.

Dit is het moment waarop veel organisaties vastlopen. Niet op de vraag of ze AI willen, maar op de vraag wat dat ding daaronder eigenlijk doet en waarom het zo duur is. Deze blog is voor dat moment. Geen koopadvies, wel het denkmodel waarmee je zo'n offerte kunt lezen zonder dat iemand je iets kan wijsmaken.

Waarom AI op GPU's draait

Een taalmodel is, ontdaan van alle magie, een gigantische berg vermenigvuldigingen. Elke keer dat het model een woord genereert, worden miljarden getallen met elkaar vermenigvuldigd en opgeteld. Stuk voor stuk simpele sommen. Het probleem is het aantal.

Een CPU, de processor in je laptop, is gebouwd om ingewikkelde taken na elkaar te doen. Een handvol slimme kernen die alles kunnen. Een GPU is het omgekeerde: duizenden domme rekenkernen die allemaal tegelijk dezelfde simpele som doen. Voor de meeste software is dat nutteloos. Voor een berg vermenigvuldigingen die parallel kunnen, is het precies wat je nodig hebt. Dat is de hele reden. Geen marketing, gewoon wiskunde die toevallig de vorm heeft waar grafische kaarten ooit voor zijn ontworpen.

De praktische consequentie: je kunt een taalmodel technisch op een CPU draaien, maar dan wacht je seconden tot minuten per antwoord. Voor alles wat op productiesnelheid moet reageren, ben je op GPU's aangewezen.

VRAM: de eerste vraag is niet hoe snel, maar of het past

VRAM is het werkgeheugen op de GPU zelf. En hier zit de eerste harde grens: het model moet er in zijn geheel in passen, anders draait het niet of wordt het dramatisch traag. VRAM bepaalt dus niet hoe snel je bent, maar wat er überhaupt mogelijk is.

De rekensom is verrassend simpel. Een model bestaat uit parameters, de getallen die het tijdens training heeft geleerd. In het standaardformaat kost elke parameter twee bytes. Een model van 8 miljard parameters heeft dan zo'n 16 gigabyte nodig, alleen al voor zichzelf. Een model van 70 miljard parameters komt op zo'n 140 gigabyte. Ter vergelijking: een stevige consumentenkaart heeft 24 gigabyte VRAM, de zwaarste datacenterkaarten zitten rond de 80 tot bijna 200 gigabyte. Dat grote model past dus niet op één gewone kaart. Dan moet je het verdelen over meerdere GPU's, en dat maakt alles duurder en complexer.

Er is een ontsnappingsroute: quantization. Daarbij sla je de parameters grover op, met één byte of zelfs een half byte per parameter in plaats van twee. Het model wordt dan twee tot vier keer kleiner in geheugen, tegen een meestal beperkt verlies aan kwaliteit. Zo past een 70B-model ineens wel op één grote kaart. Hoeveel kwaliteit je inlevert verschilt per model en per taak, dus dat wil je testen op je eigen gebruik, niet aannemen op basis van een benchmark.

En dan is er nog een post die in offertes zelden wordt benoemd: het model is niet het enige dat in VRAM moet. Elke lopende conversatie houdt tussenresultaten bij in het geheugen, de zogenaamde KV-cache. Hoe langer de documenten en gesprekken, en hoe meer gebruikers tegelijk, hoe meer extra geheugen dat vreet. Een kaart waar het model net op past, heeft dus geen ruimte voor echte gebruikers. Dit klinkt als een detail. In productie is het de reden dat systemen die in de demo prima werkten, bij twintig gelijktijdige gebruikers omvallen.

Een GPU die op je wacht, verbrandt geld

Hier komt het deel dat financieel het meest uitmaakt, en dat bijna niemand intuïtief aanvoelt.

Stel, een advocatenkantoor host een eigen model voor het samenvatten van dossiers. De GPU kost gehuurd een paar euro per uur, dag en nacht. Overdag stellen medewerkers er vragen aan. Maar zelfs op een druk moment is die GPU het grootste deel van de tijd aan het wachten: op de volgende vraag, op een gebruiker die zit te lezen, op de nacht. Een bezetting van tien procent is in de praktijk geen uitzondering. Je betaalt dan negen van de tien euro's voor stilte.

Dat komt door een technische eigenschap van taalmodellen: bij het genereren van tekst is niet de rekenkracht de bottleneck, maar de snelheid waarmee het geheugen kan worden gelezen. Voor elk gegenereerd woord moet het hele model door het geheugen worden gehaald. De rekenkernen zelf zitten ondertussen te niksen.

En precies daar zit de oplossing: batching. Als de GPU toch het hele model door het geheugen sleept, kan hij in diezelfde beweging net zo goed voor tien of vijftig gesprekken tegelijk rekenen. Tien vragen tegelijk verwerken kost daardoor niet tien keer zoveel tijd, maar slechts een fractie meer dan één vraag. Moderne inference-software zoals vLLM doet dit continu en automatisch: nieuwe verzoeken schuiven in de lopende batch zodra er ruimte is, in plaats van netjes in de rij te wachten.

Het effect op de kosten is groot. Dezelfde GPU die zonder batching één gebruiker bedient, bedient met goede batching tientallen gebruikers. De prijs per vraag daalt dan niet met procenten, maar met een veelvoud. Dit is ook waarom grote AI-aanbieders zo goedkoop per miljoen tokens kunnen zijn: hun GPU's staan nooit te wachten, want er is altijd iemand anders met een vraag om de batch mee te vullen.

De afweging: latency tegen throughput

Batching is geen gratis lunch. Er zit een fundamentele afweging onder die je als beslisser wilt snappen, want hij bepaalt hoe je systeem voelt.

Twee begrippen. Latency is hoe lang één gebruiker wacht op antwoord, met als belangrijkste maat de tijd tot het eerste woord verschijnt. Throughput is hoeveel werk het systeem in totaal per seconde verzet. Batching verhoogt de throughput enorm, maar elke individuele gebruiker deelt de machine nu met anderen en wordt daar iets trager van.

Welke kant je op stuurt, hangt af van wat het systeem doet. Een chatassistent voor medewerkers moet snel beginnen met antwoorden, anders voelt hij kapot; daar accepteer je een lagere bezetting en dus hogere kosten per vraag. Maar het 's nachts samenvatten van tienduizend documenten heeft geen ongeduldige gebruiker. Daar wil je de batch zo vol mogelijk en maakt het niemand uit of één samenvatting twee seconden langer duurt. Zelfde hardware, zelfde model, totaal andere instellingen en totaal andere kosten per taak.

De vraag aan je leverancier is dus niet "hoe snel is het", maar: hoe snel bij hoeveel gelijktijdige gebruikers, en wat gebeurt er met de wachttijd als het druk wordt.

Nuchter rekenen aan kosten

Met dit beeld kun je de geldvraag scherper stellen. Een paar denklijnen die ik in de praktijk steeds gebruik.

Huren versus kopen draait om bezetting. Eigen hardware is per uur goedkoper dan huren, maar alleen als die uren ook gevuld zijn. Een gekochte GPU die op tien procent bezetting draait is bijna altijd duurder dan huren of per token betalen, nog los van stroom, koeling, onderhoud en het feit dat hardware in dit tempo van ontwikkeling snel afschrijft. Kopen wordt pas interessant bij hoge, voorspelbare belasting, of wanneer data-soevereiniteit en controle de doorslag geven en je die prijs bewust accepteert. Dat is een legitieme keuze, maar maak hem dan expliciet, niet verstopt in een spreadsheet.

Spot instances zijn de tweedehandsmarkt van de cloud: restcapaciteit die je fors goedkoper huurt, vaak voor minder dan de helft van de normale prijs, met als voorwaarde dat de aanbieder hem op korte termijn kan terugvorderen. Voor een chatdienst die altijd bereikbaar moet zijn is dat onbruikbaar. Voor batchwerk dat herstartbaar is, zoals het doorrekenen van een documentenarchief of het hergenereren van embeddings, is het juist een van de grootste besparingen die er te halen valt.

En de simpelste besparing van allemaal: gebruik geen groot model voor klein werk. Een mail classificeren, een veld extraheren, een tekst herschrijven naar een vast format: daar is een klein model van een paar miljard parameters vaak ruim goed genoeg voor, op een fractie van de hardware. In de praktijk, ook in wat ik bij HostYourAI aan verkeer voorbij zie komen, is een groot deel van de verzoeken aan AI-systemen dit soort simpel werk. Een router die simpele taken naar een klein model stuurt en alleen het moeilijke werk naar het grote model, scheelt vaak meer dan welke hardwareonderhandeling dan ook.

Het denkmodel in zes vragen

Krijg je een voorstel voor AI-infrastructuur, loop dan deze vragen langs:

Wie deze zes vragen kan stellen, is geen hardware-expert geworden. Maar wel iemand die een offerte kan lezen.

Conclusie

GPU-infrastructuur is geen mysterie. Het is geheugen dat bepaalt wat past, bezetting die bepaalt wat het kost, en batching die bepaalt of je betaalt voor werk of voor wachten. De demo is makkelijk: één gebruiker, één GPU, alles voelt snel. Productie is waar het serieus wordt, want daar betaal je voor elk stil uur en merkt elke gebruiker elke ontwerpkeuze.

De belangrijkste misvatting die ik wil corrigeren: dat AI-kosten vooral over de prijs van de hardware gaan. Dat doen ze niet. Ze gaan over hoeveel van die hardware je daadwerkelijk gebruikt. Twee organisaties met exact dezelfde server kunnen per vraag een factor tien in kosten verschillen, puur door bezetting, batching en modelkeuze. Wie morgen één ding anders wil doen: vraag niet wat de GPU kost, vraag wat een verwerkte taak kost. Dat is het getal waar je op stuurt. 

↘︎ ALLE ARTIKELEN