기본적인 VPS에는 RAM이 얼마나 필요한가요?

봇 하나, 작은 API, 정적 사이트라면 1 GB로 충분하고 대개 여유도 있습니다. 데이터베이스를 추가하거나 Docker로 무언가를 돌린다면 2 GB가 편안한 기본값입니다. 1 GB 미만에서는 최신 패키지 관리자와 언어 런타임이 힘들어하기 시작합니다.

VPS에서 LLM을 돌리려면 RAM이 얼마나 필요한가요?

대략 양자화된 모델 크기에 컨텍스트용 1~2 GB를 더한 만큼입니다. 4비트 7~8B 모델은 약 5~6 GB, 14B는 약 10 GB, 32B는 약 20 GB, 70B는 약 40~45 GB가 필요합니다. 64 GB 서버가 있는 이유가 이것입니다. 70B 모델을 올리고도 나머지 스택을 위한 공간이 남습니다.

스왑이 RAM을 대신할 수 있나요?

아니요. 스왑은 짧은 급증을 위한 안전망으로, 빌드나 백업이 강제 종료되는 것을 막아 줍니다. 어떤 작업이 하루 종일 스왑에서 돌고 있다면 모든 것이 느려지며, 그것이 요금제를 올리라는 신호입니다.

서버가 실제로 쓰는 RAM은 어떻게 확인하나요?

'free -h'를 실행하고 'free'가 아니라 'available' 열을 보세요. Linux는 남는 메모리를 디스크 캐시로 쓰고 필요할 때 돌려줍니다. 'ps aux --sort=-rss | head'는 큰 프로세스를, 'docker stats --no-stream'은 컨테이너별 사용량을 보여 줍니다.

64 GB VPS는 언제 의미가 있나요?

하나의 대상이 메모리에 올라가 있어야 할 때입니다. 32~70B 로컬 모델, RAG용 대형 벡터 인덱스, 자체 런타임을 가진 에이전트 무리 같은 경우입니다. 웹사이트, 봇, 대부분의 API에는 돈 낭비입니다.

VPS에는 RAM이 얼마나 필요할까요? 작업별 실제 수치

대부분의 사람은 RAM을 감으로 고릅니다. “혹시 몰라서” 너무 많이 사거나, 새벽 3시에 OOM killer를 처음 만납니다. 사실 메모리는 사양을 정하기 가장 쉬운 것 중 하나입니다. 대략적인 수치만 알면 작업량을 예측할 수 있기 때문입니다. 봇용 1 GB 서버부터 큰 모델을 직접 돌리려는 사람들이 찾는 64 GB 서버까지, 그 수치를 소개합니다.

작업별 대략적인 수치

전형적인 구성에서 안정 상태의 실제 값이며, 공급사가 밝힌 최소 사양이 아닙니다.

작업	실제로 쓰는 RAM	알맞은 요금제
Telegram/Discord 봇(Python, Node.js)	100~300 MB	Nano 1 GB
정적 사이트 + Caddy/Nginx	50~150 MB	Nano 1 GB
WordPress + MariaDB, 일반 트래픽	0.8~1.5 GB	Micro-IP 2 GB
작은 앱용 PostgreSQL	0.5~2 GB(`shared_buffers`로 직접 결정)	Micro / Small
워크플로 몇 개를 가진 n8n	0.5~1.5 GB	Micro 2 GB
작은 서비스 5~10개를 돌리는 Docker 호스트	2~4 GB	Small 4 GB
Coolify + 빌드 + 데이터베이스	3~4 GB	Small-IP 4 GB
7~8B LLM, 4비트, CPU 추론	5~6 GB	Medium 6 GB
14B LLM, 4비트	약 10 GB	Pro-32
32B LLM, 4비트	약 20 GB	Pro-32
70B LLM, 4비트	약 40~45 GB	Pro-48 / Pro-64

주목할 점이 두 가지 있습니다. 첫째, “일반적인” 작업과 LLM 사이의 격차가 엄청납니다. 봇과 70B 모델은 200배나 차이가 납니다. 둘째, 대부분의 서비스는 1~4 GB로 충분합니다. 사람들이 과하게 사는 이유는 좀처럼 오지 않는 미래에 맞춰 사양을 잡기 때문입니다.

LLM 계산식

언어 모델에는 간단한 추정법이 있습니다. 파라미터 수 × 가중치당 비트 수 ÷ 8, 여기에 오버헤드를 더합니다. 약 4.5비트(일반적인 Q4 양자화)의 8B 모델은 8 × 4.5 ÷ 8 ≈ 4.5 GB의 가중치입니다. 컨텍스트 창(KV 캐시는 컨텍스트 길이에 따라 커집니다)과 런타임을 위해 1~~2 GB를 더하면 5~~6 GB가 됩니다.

솔직히 말하면, CPU만 있는 서버에서 메모리는 이야기의 절반일 뿐입니다. vCPU 몇 개로 7~8B 모델은 초당 몇 토큰, 70B는 초당 약 1토큰을 예상하세요. 배치 작업, 백그라운드 에이전트, 개인 실험에는 충분하지만, 많은 사용자가 동시에 쓰는 채팅 경험은 아닙니다. 주로 호스팅된 모델 API를 호출한다면 에이전트에 필요한 자원은 훨씬 적습니다. AI 에이전트를 위한 VPS 사양 정하기를 참고하세요.

추측하지 말고 측정하세요

이미 서버가 있다면 수치는 바로 볼 수 있습니다.

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는 놀고 있는 RAM을 디스크 캐시로 쓰기 때문에 “free”는 늘 작고, 그것이 정상입니다. 중요한 것은 available, 즉 커널이 지금 당장 프로그램에 내줄 수 있는 메모리입니다. 가장 바쁜 시간대에 available이 약 25% 이상 유지되면 사양이 적절합니다. 자주 0에 닿고 스왑이 늘어난다면 요금제를 올리세요.

과거에 OOM으로 강제 종료된 적이 있는지도 확인하세요.

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

스왑은 엔진이 아니라 안전벨트입니다

작은 서버에 1~2 GB 스왑 파일을 두는 것은 저렴한 보험입니다. 잠깐 더 많은 메모리가 필요한 패키지 업데이트나 Docker 빌드가 강제 종료되지 않고 살아남습니다. 하지만 서비스가 스왑에서 돌고 있으면 모든 요청이 디스크를 기다립니다. 스왑은 급증을 위한 것입니다. 계속 스왑을 쓴다면 다음 요금제가 필요하다는 뜻입니다.

그래서 얼마나 사야 할까요?

1 GB: 봇 하나, 작은 API 하나, 정적 사이트.
2 GB: 데이터베이스나 Docker를 쓰는 모든 것에 합리적인 기본값.
4~6 GB: 한 서버에 여러 서비스, 서버에서의 빌드, 작은 로컬 모델.
32~64 GB: 큰 것 하나가 메모리에 상주해야 할 때만. 14B를 넘는 로컬 모델, 대형 RAG 인덱스, 에이전트 무리 같은 경우입니다. 이를 위해 대용량 메모리 요금제가 있습니다.

직감보다 한 단계 작은 사양으로 시작해 일주일 동안 free -h를 지켜보고, 수치가 말해 주면 업그레이드하세요. EQVPS에서는 요금제를 올려도 데이터가 그대로 유지되고, 일할 계산된 차액만 청구됩니다(요금제 변경 방식).