LLM GPU- & VRAM-calculator
Bereken hoeveel GPU-geheugen nodig is om een open-source LLM te serveren, welke GPU past, en wat self-hosting per maand kost. Kies modelgrootte, quantisatie, contextlengte en gelijktijdigheid, en zie de VRAM uitgesplitst in modelgewichten en KV-cache. Gratis, zonder aanmelden, draait in je browser.
Uitsplitsing
- Modelgewichten
- KV-cache
- Overhead & activaties
3 manieren om op een kleinere GPU te passen
4-bit-quantisatie kan tot 0 GiB aan VRAM vrijmaken.
Je gebruikt al 4-bit-gewichten — het kleinste gangbare formaat. De punten hieronder gelden nog wel voor de KV-cache.
- Quantiseer de gewichten INT4 (GPTQ/AWQ) verkleint het gewichtsgeheugen ~4× ten opzichte van FP16 met weinig kwaliteitsverlies — vaak het verschil tussen twee GPU’s en één.
- Beperk context & KV-cache De KV-cache groeit met contextlengte × gelijktijdigheid. Kortere contextvensters en FP8-KV-cache verkleinen die direct.
- Gebruik een serving-stack vLLM of TGI met paged attention pakken de KV-cache veel compacter en verhogen de doorvoer, zodat je voor hetzelfde verkeer minder GPU’s nodig hebt.
Twijfel je tussen self-host en API, of size je een cluster?
Stuur me je model, verkeer en latentiedoel en je krijgt een goed gedimensioneerd GPU-plan, een realistische maandprijs, en een eerlijk oordeel of self-hosting een API verslaat. Het eerste gesprek van 30 minuten is gratis.
Mail me →Aannames. VRAM = modelgewichten + KV-cache + ~15% overhead voor activaties en de CUDA-context. Architecturen (lagen, hidden size) zijn typisch voor elke groottecategorie; echte modellen verschillen, en technieken als grouped-query attention verkleinen de KV-cache. GPU-prijzen zijn representatieve cloud-lijsttarieven per uur. Zie dit als een serving-side indicatie. Tarieven voor het laatst bijgewerkt op 2026-06-26.
Vergelijk je met API-prijzen? Probeer de LLM-kostencalculatorVeelgestelde vragen
Hoeveel VRAM heb ik nodig om een LLM te draaien?
Drie dingen tellen op: de modelgewichten (parameters × bytes per parameter, bijv. 2 bytes bij FP16), de KV-cache (die groeit met contextlengte en het aantal gelijktijdige requests), en ~15% overhead voor activaties en de CUDA-context. Een 7-8B-model bij FP16 heeft alleen al ~16-20 GiB nodig voor de gewichten; quantiseren naar 4-bit kwart dat ongeveer. Gebruik de calculator hierboven voor je eigen setup.
Wat is de KV-cache en waarom groeit die?
De KV-cache bewaart de attention-keys en -values voor elk token dat al in de context zit, voor elke laag, zodat het model die niet bij elke stap opnieuw berekent. De omvang schaalt met contextlengte × batch (gelijktijdige requests) × lagen × hidden size. Bij lange context of hoge gelijktijdigheid kan die de gewichten evenaren of overtreffen, en daarom kan een model dat bij korte context "past" bij lange context het geheugen overschrijden.
Verlaagt quantisatie de GPU-eisen?
Ja, fors. FP16 gebruikt 2 bytes per gewicht; INT8 gebruikt 1; INT4 (GPTQ/AWQ) ongeveer 0,5. Van FP16 naar INT4 verkleint het gewichtsgeheugen ruwweg 4×, vaak het verschil tussen twee GPU’s en één, met beperkt kwaliteitsverlies voor de meeste workloads. Het verkleint de KV-cache niet; die stuur je met contextlengte en KV-precisie.
Moet ik self-hosten of een API gebruiken?
Self-hosting wint bij stabiel, hoog volume, strikte data-residency, of een fijngetuned open model; een API wint bij grillig of laag verkeer, waar je voor idle GPU’s zou betalen. Vergelijk de maandelijkse GPU-kosten hier met dezelfde workload in de LLM-kostencalculator. Het break-evenpunt is meestal een kwestie van bezetting, niet van lijstprijs.
Is deze calculator nauwkeurig?
Het is een degelijke serving-side schatting, geen garantie. Hij gaat uit van typische architecturen per groottecategorie en representatieve GPU-prijzen; echte cijfers verschuiven met grouped-query attention, de serving-stack en je exacte GPU en regio. Voor een nauwkeurig plan op basis van jouw model en verkeer is een kort gesprek de snelste weg.