LLM을 로컬에서 실행하려면 실제로 RAM이 얼마나 필요할까? 2026년 벤치마크

"내 컴퓨터에서 돌아갈까?"는 모두가 Ollama로 모델을 가져오기 전에 던지는 첫 번째 질문입니다. 솔직한 답변은 '예/아니오'가 아니라 하나의 공식입니다. 용량이 부족해 다운로드조차 못 할 9GB짜리 파일을 받기 전에 메모리를 추정하는 방법과, 이미 보유하고 있는 하드웨어에서 실제로 기대할 수 있는 속도에 대해 알아보겠습니다.

경험 법칙 (The Rule of Thumb)

모델의 메모리 점유율(memory footprint)은 대략 다음과 같습니다:

RAM = (매개변수 수(billions)) * (매개변수당 바이트) + 오버헤드 (overhead)

매개변수당 바이트는 양자화 (Quantization)에 따라 달라집니다 (자세한 내용은 아래 참조). 일반적인 Q4 양자화의 경우, KV 캐시 (KV cache)와 런타임 오버헤드 (runtime overhead)를 포함하면 10억 개의 매개변수당 약 0.55~0.65GB가 필요합니다. Ollama의 기본 양자화 값들이 이 범위에 해당합니다.

따라서 Q4 방식의 7B 모델은 대략 7 * 0.6 ≈ 4.2GB가 필요하며, 실제로 Ollama에서 qwen2.5-coder:7b를 확인하면 디스크 용량이 4.7GB로 보고되는데, 이는 메모리 점유량과 유사합니다. 오버헤드는 컨텍스트 윈도우 (context window)가 커질수록 증가합니다. 긴 프롬프트는 KV 캐시를 채우며 수백 MB에서 수 GB까지 추가 용량을 차지합니다. 딱 맞게 계획하지 말고 여유 공간을 고려하세요.

양자화 (Quantization)가 실제로 하는 일

모델은 16비트 부동 소수점 (16-bit floats)으로 학습됩니다. 양자화 (Quantization)는 각 가중치 (weight)를 더 적은 비트로 줄여 모델이 더 적은 메모리에 들어갈 수 있게 합니다. 약간의 품질을 희생하는 대신 많은 RAM을 확보하는 것입니다.

_K_M 접미사는 "K-quant, medium"을 의미합니다. 이는 중요한 가중치는 높은 정밀도로 유지하고 나머지는 압축하는 더 스마트한 방식입니다. Q4_K_M은 대부분의 Ollama 모델에서 기본값으로 사용되는데, 그 이유는 균형이 가장 좋기 때문입니다. FP16 크기의 약 4분의 1 수준이면서, 일반적인 사용 시 대부분의 사람이 품질 차이를 느끼지 못할 정도입니다.

제 의견은 이렇습니다: 공간이 정말 절박한 상황이 아니라면 Q4 미만으로는 내려가지 마세요. Q4에서 Q3로 넘어가는 것은 RAM을 조금 더 확보해주지만, 특히 코드 생성 시 실제 일관성 (coherence)을 잃게 됩니다.

Ollama에서 특정 양자화 모델을 가져오려면:

ollama pull qwen2.5-coder:7b-instruct-q4_K_M
ollama pull qwen2.5-coder:7b-instruct-q8_0

RAM vs VRAM: CPU vs GPU 추론 (Inference)

이 부분은 초보자들이 놓치는 지점입니다. 중요한 메모리는 두 종류가 있으며, 어떤 메모리를 보유하고 있느냐에 따라 속도에 관한 모든 것이 달라집니다.

• RAM은 시스템 메모리입니다. 모델이 여기에 위치하면 CPU가 연산을 수행합니다. 작동은 하지만, 범용적이며 느립니다.
• VRAM은 GPU의 메모리입니다. 모델 전체가 여기에 들어간다면 GPU가 연산을 수행하며, 이는 10배에서 30배 더 빠릅니다.

Ollama는 VRAM에 들어갈 수 있는 만큼의 모델을 로드하고 나머지는 CPU에서 실행합니다. 모델의 절반은 VRAM에, 절반은 RAM에 있는 경우 대략 느린 쪽의 속도로 실행되므로, 부분적인 오프로드 (offload)는 기대만큼 큰 도움이 되지 않습니다. 목표는 모델 전체를 VRAM에 넣는 것입니다.

이것이 바로 300달러짜리 중고 12GB GPU가 추론 (inference) 시 64GB RAM을 탑재한 2000달러짜리 노트북을 종종 이기는 이유입니다. RAM은 충분하지만, VRAM이 없으면 CPU가 병목 현상 (bottleneck)이 되기 때문입니다.

Apple Silicon은 예외입니다. 통합 메모리 (Unified memory)는 GPU와 CPU가 하나의 빠른 풀 (pool)을 공유함을 의미하므로, 16GB 이상의 M-시리즈 Mac은 일반적인 RAM 전용 PC보다 훨씬 뛰어난 성능을 보여줍니다.

벤치마크 표 (The Benchmark Table)

이 수치들은 실험실 결과가 아니라, 제 개인 기기에서 얻은 대표적인 수치와 지속적으로 보고되는 내용들입니다. 사용자의 정확한 CPU, RAM 속도, GPU에 따라 어느 정도 차이가 있을 수 있으므로 "예상치"로 간주하십시오. CPU 수치는 최신 멀티코어 데스크톱/노트북 칩을 가정하며, GPU 수치는 모델이 완전히 오프로드된 상태의 미드레인지 카드(대략 RTX 3060/4060 급, 8~12GB VRAM)를 가정합니다.

중요한 몇 가지 참고 사항:

1. Tokens/sec(초당 토큰 수)는 사용자가 느끼는 "체감 속도"입니다. 초당 약 5토큰(5 tok/s) 미만이면 채팅 시 고통스럽게 느껴집니다. 초당 약 20토큰(20 tok/s) 이상이면 빠릿빠릿하게 느껴집니다. GPU를 사용하면 "커피를 만들어 올 정도의 시간"이 "즉각적인 반응"으로 바뀝니다.
2. deepseek-coder-v2는 Mixture-of-Experts (MoE) 모델입니다. 총 파라미터는 16B이지만 토큰당 약 2.4B만 활성화되므로, 실제 크기보다 빠르지만 전체 8.9GB의 상주 메모리(resident memory)는 여전히 필요합니다.
3. CPU에서의 1.5B 모델은 진정으로 사용 가능합니다. 그것이 이 모델의 핵심 목적입니다. 자동 완성(autocomplete), 빠른 요약, 구조화된 추출(structured extraction) 작업에는 GPU 없이도 충분히 빠릅니다.
4. 첫 번째 호출은 항상 느립니다. 모델이 디스크에서 메모리로 로드되기 때문입니다. 두 번째 호출을 기준으로 벤치마크를 측정하세요.

기기 사양별 권장 사항

8GB 노트북 (전용 GPU 없음)

7B 모델을 실행할 수는 있지만, 간신히 가능할 뿐입니다. OS와 브라우저가 이미 3~4GB를 점유하므로, 4.7GB 크기의 모델을 사용하면 여유 공간이 거의 없습니다. 현실적인 선택지는 다음과 같습니다:

• 일상적인 용도: qwen2.5-coder:1.5b (~1.0GB). CPU에서도 빠르며 다른 작업을 위한 여유 공간을 확보할 수 있습니다.
• 가끔 필요한 고품질 작업: mistral:7b 또는 qwen2.5-coder:7b. 하지만 먼저 브라우저 탭을 닫아야 하며, 초당 5~9토큰(5 to 9 tok/s) 정도를 예상해야 합니다.
• 8B 이상의 모델은 피하세요. 디스크 스와핑(swap to disk)이 발생하여 속도가 매우 느려질 것입니다.

컨텍스트 윈도우(context window)를 적절하게 유지하세요. 16K 컨텍스트는 KV 캐시(KV cache)를 가득 채워 8GB 환경에서 한계치를 넘길 수 있습니다.

16GB 개발용 PC (GPU 없음 또는 성능이 낮은 iGPU)

이 단계는 RAM만으로도 쾌적하게 사용할 수 있는 구간이며, 대부분의 개발자가 위치하는 지점입니다.

• 기본 설정: qwen2.5-coder:7b (~4.7GB). 여유 공간이 충분하며 코드 품질도 좋습니다.
• 성능 확장: deepseek-coder-v2 (~8.9GB)는 여유 있게 들어가며, MoE 덕분에 준수한 속도로 실행됩니다.
• 7B 모델을 실행하면서도 IDE, Docker, 브라우저를 동시에 띄워둘 수 있습니다. 이것이 진정한 이점입니다.

이 환경에서도 속도는 여전히 CPU에 종속되어 있습니다 (초당 한 자릿수에서 10대 초반 토큰). 따라서 "사고(thinking)\

• Workhorse (주력 모델): qwen2.5-coder:7b를 완전히 오프로딩(offloaded)하면 45~70 tok/s의 속도가 나옵니다. 마치 호스팅된 API를 사용하는 느낌입니다.
• Quality (품질): 더 어려운 코딩 작업에는 deepseek-coder-v2를 사용하며, 여전히 빠릅니다.
• 24GB의 VRAM (3090/4090급 그래픽 카드)이 있다면 32B급 모델을 Q4 양자화로 GPU에서 완전히 실행할 수 있습니다. 이 단계부터는 로컬의 품질이 코딩 분야에서 클라우드와 경쟁하기 시작합니다.

Ollama가 실제로 무엇을 하고 있는지 확인해 보세요:

ollama ps

PROCESSOR 열이 분할 상태를 알려줍니다. 여러분이 원하는 상태는 100% GPU입니다. 만약 50%/50% CPU/GPU라고 표시된다면, 모델이 VRAM에 비해 너무 커서 속도를 손해 보고 있는 것입니다. 모델이 완전히 GPU에 올라갈 때까지 더 작은 양자화(quant) 모델이나 더 작은 모델로 낮추세요.

빠른 사이즈 결정 체크리스트

무언가를 다운로드하기 전에:

1. 전체 RAM에서 4GB를 뺀 값이 RAM 전용 머신에서 사용할 수 있는 대략적인 모델 예산입니다.
2. GPU가 있다면 중요한 숫자는 VRAM입니다. 모델 전체를 VRAM에 맞추세요.
3. 특별한 이유가 없다면 Q4_K_M 방식을 고수하세요.
4. 컨텍스트(context)를 위한 여유 공간을 확보하세요. 긴 프롬프트는 실제 메모리를 소모합니다.
5. 두 번째 호출을 벤치마크하세요. 첫 번째 호출은 절대 기준이 될 수 없습니다.

요약 (The Takeaway)

여러분은 생각보다 적은 RAM이 필요하고, 가진 것보다 더 많은 VRAM이 필요합니다. GPU가 없는 16GB 머신에서도 7B 코딩 모델을 쾌적하게 실행할 수 있으며, 이는 대부분의 실제 개발 작업을 커버할 수 있습니다. 8~12GB VRAM을 가진 저렴한 GPU를 사용하는 것이 시스템 RAM을 두 배로 늘리는 것보다 더 중요합니다. 왜냐하면 GPU는 참을 만한 도구를 즉각적인 도구로 바꿔주기 때문입니다.

워크플로우를 익히기 위해 qwen2.5-coder:1.5b로 시작하고, 품질을 원할 때 7b로 넘어가며, 모델을 담을 수 있는 VRAM을 확보한 후에야 더 큰 모델을 쫓으세요. spectr-ai를 포함하여 제가 만드는 모든 것은 16GB 사양의 PC에서 7B 모델로 잘 작동합니다. 로컬 환경은 하드웨어에 대한 두려움이 시사하는 것보다 훨씬 더 유능합니다.