Ile RAM-u potrzebuje podstawowy VPS?

Dla jednego bota, małego API albo strony statycznej wystarczy 1 GB, często z zapasem. 2 GB to wygodny standard, gdy dochodzi baza danych albo uruchamiasz rzeczy w Dockerze. Poniżej 1 GB nowoczesne menedżery pakietów i środowiska uruchomieniowe języków zaczynają cierpieć.

Ile RAM-u potrzeba do uruchomienia LLM na VPS-ie?

Mniej więcej tyle, ile waży model przy danej kwantyzacji, plus gigabajt lub dwa na kontekst. Model 7–8B w 4 bitach potrzebuje około 5–6 GB, 14B około 10 GB, 32B około 20 GB, a 70B około 40–45 GB. Dlatego istnieją serwery 64 GB: mieści się na nich model 70B z miejscem na resztę stosu.

Czy swap zastępuje RAM?

Nie. Swap to siatka bezpieczeństwa na krótkie skoki: chroni build albo kopię zapasową przed ubiciem. Jeśli obciążenie siedzi w swapie cały dzień, wszystko zwalnia; to sygnał, żeby przejść na wyższy plan.

Jak sprawdzić, ile RAM-u naprawdę zużywa mój serwer?

Uruchom 'free -h' i patrz na kolumnę 'available', nie 'free': Linux używa wolnej pamięci jako pamięci podręcznej dysku i oddaje ją na żądanie. 'ps aux --sort=-rss | head' pokazuje największe procesy, a 'docker stats --no-stream' zużycie per kontener.

Kiedy VPS z 64 GB ma sens?

Gdy jedna rzecz musi siedzieć w pamięci: lokalny model 32–70B, duży indeks wektorowy do RAG albo flota agentów z własnymi środowiskami. Dla stron, botów i większości API to wyrzucone pieniądze.

Ile RAM-u potrzebuje VPS? Prawdziwe liczby dla obciążeń

Większość ludzi zgaduje, ile RAM-u potrzebuje. Albo kupuje zdecydowanie za dużo „na wszelki wypadek”, albo poznaje OOM killera o 3 w nocy. Pamięć to w rzeczywistości jedna z najłatwiejszych rzeczy do dobrania, bo obciążenia są przewidywalne, gdy znasz przybliżone liczby. Oto one, od maszyny 1 GB dla bota po serwery 64 GB, których szuka się, gdy chce się uruchomić duży model lokalnie.

Przybliżone liczby według obciążenia

To rzeczywiste wartości w stanie ustalonym dla typowej konfiguracji, a nie minima producentów.

Obciążenie	Faktyczne zużycie RAM	Pasujący plan
Bot Telegram/Discord (Python, Node.js)	100–300 MB	Nano 1 GB
Strona statyczna + Caddy/Nginx	50–150 MB	Nano 1 GB
WordPress + MariaDB, normalny ruch	0,8–1,5 GB	Micro-IP 2 GB
PostgreSQL dla małej aplikacji	0,5–2 GB (decydujesz przez `shared_buffers`)	Micro / Small
n8n z kilkoma workflow	0,5–1,5 GB	Micro 2 GB
Host Dockera z 5–10 małymi usługami	2–4 GB	Small 4 GB
Coolify + buildy + baza danych	3–4 GB	Small-IP 4 GB
LLM 7–8B, 4 bity, inferencja na CPU	5–6 GB	Medium 6 GB
LLM 14B, 4 bity	~10 GB	Pro-32
LLM 32B, 4 bity	~20 GB	Pro-32
LLM 70B, 4 bity	~40–45 GB	Pro-48 / Pro-64

Warto zauważyć dwie rzeczy. Po pierwsze, przeskok między „zwykłymi” obciążeniami a LLM jest ogromny: bot i model 70B różnią się dwustukrotnie. Po drugie, większości usług wystarcza 1–4 GB; ludzie przepłacają, bo dobierają rozmiar pod przyszłość, która rzadko nadchodzi.

Wzór dla LLM

Dla modeli językowych istnieje proste oszacowanie: parametry × bity na wagę ÷ 8, plus narzut. Model 8B przy około 4,5 bitu (typowa kwantyzacja Q4) to 8 × 4,5 ÷ 8 ≈ 4,5 GB wag. Dodaj 1–2 GB na okno kontekstu (KV cache rośnie z długością kontekstu) i środowisko uruchomieniowe, a wychodzi 5–6 GB.

Uczciwa część: na serwerach bez GPU pamięć to tylko połowa historii. Spodziewaj się kilku tokenów na sekundę dla modeli 7–8B na paru vCPU i mniej więcej jednego tokena na sekundę dla 70B. To wystarczy do zadań wsadowych, agentów w tle i prywatnych eksperymentów; to nie jest czat dla wielu jednoczesnych użytkowników. Jeśli głównie wywołujesz hostowane API modeli, twój agent potrzebuje znacznie mniej: zobacz dobór VPS-a dla agentów AI.

Mierz zamiast zgadywać

Jeśli masz już serwer, liczby są na wyciągnięcie ręki:

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 używa bezczynnego RAM-u jako pamięci podręcznej dysku, więc „free” jest zawsze małe i to zdrowe. Liczy się available: pamięć, którą jądro może dać programom w tej chwili. Jeśli w najbardziej obciążonej godzinie available zostaje powyżej ~25%, rozmiar jest dobry. Jeśli regularnie spada do zera, a swap rośnie, przejdź wyżej.

Sprawdź też, czy w przeszłości były ubicia przez OOM:

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

Swap: pas bezpieczeństwa, nie silnik

Plik swap 1–2 GB na małym serwerze to tanie ubezpieczenie: aktualizacja pakietów albo build Dockera, które na chwilę potrzebują więcej pamięci, przetrwają zamiast zostać ubite. Ale jeśli usługa żyje w swapie, każde żądanie czeka na dysk. Swap jest na skoki. Ciągłe swapowanie oznacza, że potrzebujesz następnego planu.

Ile więc kupić?

1 GB: jeden bot, jedno małe API, strona statyczna.
2 GB: rozsądny standard dla wszystkiego z bazą danych albo Dockerem.
4–6 GB: kilka usług na jednej maszynie, buildy na serwerze, mały lokalny model.
32–64 GB: tylko wtedy, gdy jedna duża rzecz musi żyć w pamięci: lokalny model powyżej 14B, duży indeks RAG, flota agentów. Do tego służą plany z dużą ilością pamięci.

Zacznij od rozmiaru o jeden mniejszego, niż podpowiada intuicja, obserwuj free -h przez tydzień i przejdź wyżej, jeśli liczby tak mówią. W EQVPS zmiana planu na wyższy zachowuje twoje dane i pobiera tylko proporcjonalną różnicę (jak działają zmiany planu).