Hoeveel RAM heeft een basis-VPS nodig?

Voor één bot, een kleine API of een statische site is 1 GB genoeg, vaak met ruimte over. 2 GB is de comfortabele standaard zodra je een database toevoegt of dingen in Docker draait. Onder 1 GB beginnen moderne pakketbeheerders en runtimes van programmeertalen pijn te doen.

Hoeveel RAM heb ik nodig om een LLM op een VPS te draaien?

Ongeveer de grootte van het model bij zijn kwantisatie, plus een of twee gigabyte voor de context. Een 7–8B-model in 4 bit heeft zo'n 5–6 GB nodig, een 14B-model ongeveer 10 GB, 32B rond de 20 GB en 70B rond de 40–45 GB. Daarom bestaan er servers van 64 GB: daar past een 70B-model op met ruimte voor de rest van je stack.

Is swap een vervanging voor RAM?

Nee. Swap is een vangnet voor korte pieken: het voorkomt dat een build of back-up wordt afgeschoten. Als een taak de hele dag in swap leeft, wordt alles traag; dat is het signaal om een plan hoger te gaan.

Hoe zie ik hoeveel RAM mijn server echt gebruikt?

Draai 'free -h' en kijk naar de kolom 'available', niet 'free': Linux gebruikt vrij geheugen als schijfcache en geeft het terug wanneer nodig. 'ps aux --sort=-rss | head' toont de grootste processen, en 'docker stats --no-stream' het gebruik per container.

Wanneer is een VPS met 64 GB zinvol?

Als één ding in het geheugen moet staan: een lokaal model van 32–70B, een grote vectorindex voor RAG of een vloot agents met hun eigen runtimes. Voor websites, bots en de meeste API's is het weggegooid geld.

Hoeveel RAM heeft een VPS nodig? Echte cijfers per taak

De meeste mensen gokken hun RAM. Ze kopen óf veel te veel „voor de zekerheid”, óf leren de OOM killer om 3 uur 's nachts kennen. Geheugen is eigenlijk een van de makkelijkste dingen om te dimensioneren, omdat taken voorspelbaar zijn zodra je de ruwe cijfers kent. Hier zijn ze, van een 1 GB-machine voor een bot tot de 64 GB-servers waar mensen naar zoeken als ze een groot model lokaal willen draaien.

Ruwe cijfers per taak

Dit zijn praktijkwaarden in stabiele toestand voor een typische opzet, geen minimumeisen van leveranciers.

Taak	RAM die het echt gebruikt	Passend plan
Telegram/Discord-bot (Python, Node.js)	100–300 MB	Nano 1 GB
Statische site + Caddy/Nginx	50–150 MB	Nano 1 GB
WordPress + MariaDB, normaal verkeer	0,8–1,5 GB	Micro-IP 2 GB
PostgreSQL voor een kleine app	0,5–2 GB (jij bepaalt via `shared_buffers`)	Micro / Small
n8n met een paar workflows	0,5–1,5 GB	Micro 2 GB
Docker-host met 5–10 kleine diensten	2–4 GB	Small 4 GB
Coolify + builds + een database	3–4 GB	Small-IP 4 GB
7–8B-LLM, 4 bit, inferentie op CPU	5–6 GB	Medium 6 GB
14B-LLM, 4 bit	~10 GB	Pro-32
32B-LLM, 4 bit	~20 GB	Pro-32
70B-LLM, 4 bit	~40–45 GB	Pro-48 / Pro-64

Twee dingen vallen op. Ten eerste is de sprong tussen „normale” taken en LLM's enorm: een bot en een 70B-model verschillen een factor tweehonderd. Ten tweede zijn de meeste diensten prima af met 1–4 GB; mensen kopen te veel omdat ze dimensioneren voor een toekomst die zelden komt.

De LLM-formule

Voor taalmodellen is er een eenvoudige schatting: parameters × bits per gewicht ÷ 8, plus overhead. Een 8B-model op ongeveer 4,5 bit (een typische Q4-kwantisatie) is 8 × 4,5 ÷ 8 ≈ 4,5 GB aan gewichten. Tel daar 1–2 GB bij op voor het contextvenster (de KV-cache groeit met de contextlengte) en de runtime, en je komt uit op 5–6 GB.

Het eerlijke deel: op servers met alleen CPU is geheugen maar de helft van het verhaal. Reken op enkele tokens per seconde voor 7–8B-modellen op een paar vCPU's en ongeveer één token per seconde voor 70B. Prima voor batchtaken, achtergrondagents en privé-experimenten; geen chatervaring voor veel gelijktijdige gebruikers. Roep je vooral gehoste model-API's aan, dan heeft je agent veel minder nodig: zie een VPS dimensioneren voor AI-agents.

Meten in plaats van gokken

Heb je al een server, dan liggen de cijfers voor het oprapen:

free -h                              # look at "available", not "free"
ps aux --sort=-rss | head -n 8       # the biggest processes, by resident memory
docker stats --no-stream             # per-container usage

Linux gebruikt ongebruikt RAM als schijfcache, dus „free” is altijd klein, en dat is gezond. Available is het getal dat telt: geheugen dat de kernel nu direct aan programma's kan geven. Blijft available tijdens je drukste uur boven de ~25%, dan zit je goed. Zakt het regelmatig naar nul en groeit swap, ga dan omhoog.

Controleer ook of er in het verleden OOM-kills waren:

journalctl -k | grep -i "out of memory"

Swap: een veiligheidsgordel, geen motor

Een swapbestand van 1–2 GB op een kleine server is een goedkope verzekering: een pakketupdate of Docker-build die even meer geheugen nodig heeft, overleeft in plaats van afgeschoten te worden. Maar als een dienst in swap leeft, wacht elk verzoek op de schijf. Swap is voor pieken. Voortdurend swappen betekent dat je het volgende plan nodig hebt.

Hoeveel moet je dan kopen?

1 GB: één bot, één kleine API, een statische site.
2 GB: de verstandige standaard voor alles met een database of Docker.
4–6 GB: meerdere diensten op één machine, builds op de server, een klein lokaal model.
32–64 GB: alleen als één groot ding in het geheugen moet leven: een lokaal model boven 14B, een grote RAG-index, een vloot agents. Daar zijn de plannen met veel geheugen voor.

Begin één maat kleiner dan je gevoel zegt, houd free -h een week in de gaten en ga omhoog als de cijfers dat aangeven. Bij EQVPS behoudt een upgrade je data en betaal je alleen het naar rato berekende verschil (hoe planwijzigingen werken).