Hvor meget RAM kræver en simpel VPS?

Til en enkelt bot, et lille API eller et statisk site er 1 GB nok, ofte med luft. 2 GB er den behagelige standard, når du tilføjer en database eller kører ting i Docker. Under 1 GB begynder moderne pakkehåndteringer og sprogmiljøer at lide.

Hvor meget RAM skal jeg bruge for at køre en LLM på en VPS?

Nogenlunde modellens størrelse ved dens kvantisering plus en gigabyte eller to til konteksten. En model på 7–8B i 4 bit kræver omkring 5–6 GB, en 14B-model omkring 10 GB, 32B omkring 20 GB og 70B omkring 40–45 GB. Derfor findes der servere på 64 GB: der er plads til en 70B-model med rum til resten af din stak.

Nej. Swap er et sikkerhedsnet til korte toppe: det forhindrer et build eller en backup i at blive dræbt. Lever en opgave i swap hele dagen, bliver alt langsomt; det er signalet om at gå en plan op.

Hvordan ser jeg, hvor meget RAM min server faktisk bruger?

Kør 'free -h' og kig på kolonnen 'available', ikke 'free': Linux bruger ledig hukommelse som diskcache og giver den tilbage efter behov. 'ps aux --sort=-rss | head' viser de største processer, og 'docker stats --no-stream' forbruget pr. container.

Hvornår giver en VPS med 64 GB mening?

Når én ting skal ligge i hukommelsen: en lokal model på 32–70B, et stort vektorindeks til RAG eller en flåde af agenter med egne afviklingsmiljøer. Til hjemmesider, bots og de fleste API'er er det spildte penge.

Hvor meget RAM kræver en VPS? Reelle tal pr. opgave

De fleste gætter på deres RAM. Enten køber de alt for meget »for en sikkerheds skyld«, eller også møder de OOM killeren klokken tre om natten. Hukommelse er faktisk noget af det nemmeste at dimensionere, fordi opgaver er forudsigelige, når du kender de omtrentlige tal. Her er de, fra en maskine på 1 GB til en bot op til de servere på 64 GB, folk søger efter, når de vil køre en stor model lokalt.

Omtrentlige tal pr. opgave

Det er reelle værdier i stabil drift for en typisk opsætning, ikke leverandørernes minimumskrav.

Opgave	RAM den faktisk bruger	Plan der passer
Telegram-/Discord-bot (Python, Node.js)	100–300 MB	Nano 1 GB
Statisk site + Caddy/Nginx	50–150 MB	Nano 1 GB
WordPress + MariaDB, normal trafik	0,8–1,5 GB	Micro-IP 2 GB
PostgreSQL til en lille app	0,5–2 GB (du bestemmer via `shared_buffers`)	Micro / Small
n8n med nogle få workflows	0,5–1,5 GB	Micro 2 GB
Docker-vært med 5–10 små tjenester	2–4 GB	Small 4 GB
Coolify + builds + en database	3–4 GB	Small-IP 4 GB
LLM på 7–8B, 4 bit, inferens på CPU	5–6 GB	Medium 6 GB
LLM på 14B, 4 bit	~10 GB	Pro-32
LLM på 32B, 4 bit	~20 GB	Pro-32
LLM på 70B, 4 bit	~40–45 GB	Pro-48 / Pro-64

To ting er værd at bemærke. For det første er springet mellem »almindelige« opgaver og LLM'er enormt: en bot og en 70B-model adskiller sig med en faktor to hundrede. For det andet klarer de fleste tjenester sig fint på 1–4 GB; folk køber for meget, fordi de dimensionerer til en fremtid, der sjældent kommer.

LLM-formlen

Til sprogmodeller findes der et simpelt overslag: parametre × bit pr. vægt ÷ 8, plus overhead. En 8B-model på omkring 4,5 bit (en typisk Q4-kvantisering) giver 8 × 4,5 ÷ 8 ≈ 4,5 GB vægte. Læg 1–2 GB til for kontekstvinduet (KV-cachen vokser med kontekstlængden) og afviklingsmiljøet, så lander du på 5–6 GB.

Den ærlige del: på servere med kun CPU er hukommelsen kun halvdelen af historien. Regn med få tokens i sekundet for modeller på 7–8B på nogle få vCPU'er og cirka ét token i sekundet for 70B. Det er fint til batchjob, baggrundsagenter og private eksperimenter; det er ikke en chatoplevelse for mange samtidige brugere. Kalder du mest hostede model-API'er, har din agent brug for langt mindre: se dimensionering af en VPS til AI-agenter.

Mål i stedet for at gætte

Har du allerede en server, ligger tallene lige foran dig:

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 bruger ubrugt RAM som diskcache, så »free« er altid lille, og det er sundt. Available er det tal, der tæller: hukommelse, kernen kan give programmer lige nu. Holder available sig over ~25 % i din travleste time, er du dimensioneret rigtigt. Rammer den jævnligt nul, og swap vokser, så gå op.

Tjek også, om der tidligere har været OOM-drab:

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

Swap: en sikkerhedssele, ikke en motor

En swapfil på 1–2 GB på en lille server er en billig forsikring: en pakkeopdatering eller et Docker-build, der kortvarigt har brug for mere hukommelse, overlever i stedet for at blive dræbt. Men lever en tjeneste i swap, venter hver forespørgsel på disken. Swap er til toppe. Konstant swapping betyder, at du har brug for den næste plan.

Hvor meget skal du så købe?

1 GB: én bot, ét lille API, et statisk site.
2 GB: den fornuftige standard til alt med en database eller Docker.
4–6 GB: flere tjenester på samme maskine, builds på serveren, en lille lokal model.
32–64 GB: kun når én stor ting skal leve i hukommelsen: en lokal model over 14B, et stort RAG-indeks, en agentflåde. Det er, hvad planerne med meget hukommelse er til.

Start én størrelse mindre, end mavefornemmelsen siger, hold øje med free -h i en uge, og opgradér, hvis tallene siger det. Hos EQVPS beholder en opgradering dine data og opkræver kun den forholdsmæssige forskel (sådan fungerer planskift).