개발자

로컬 LLM VRAM 계산기

이 모델, 내 GPU에 돌아갈까? — 양자화별 가중치 + KV 캐시 + 오버헤드를 llama.cpp 실측 기준으로.

최종 업데이트 2026년 7월· llama.cpp quantize README 실측 bpw · HuggingFace 공식 config.json (Llama·Qwen·Gemma·EXAONE 등 13종)· 출처: llama.cpp · HuggingFace

모델

양자화 (GGUF)

용량·품질 균형 — 기본 추천 · 약 4.89 bit/가중치 (llama.cpp 실측)

컨텍스트 길이

KV 캐시 정밀도

Llama 3.1 8B · Q4_K_M · 8K 컨텍스트

8.0GB

가중치 4.9 + KV 캐시 1.1 + 오버헤드 약 2.0GB

가중치KV 캐시오버헤드(관행)

내 GPU에 들어갈까?

필요 8.0GB / 가용 12GB → ✅ 여유 있게 구동 가능

양자화가중치총 필요판정
Q2_K3.2GB6.2GB여유
Q3_K_M4.0GB7.1GB여유
Q4_K_M4.9GB8.0GB여유
Q5_K_M5.7GB8.8GB여유
Q6_K6.6GB9.7GB여유
Q8_08.5GB11.6GB빠듯
F1616.1GB19.1GB불가

총 필요 = 가중치 + KV 캐시(8K·F16) + 오버헤드 2GB. 실효 bpw는 모델별 ±1~2% 편차가 있어(대형 모델은 소폭 과대) ‘약’으로 보세요.

본 도구는 참고용입니다
  • 입력값·환경에 따라 결과가 달라질 수 있으며 정확성을 보장하지 않습니다.
  • 중요한 의사결정에는 전문가 조언을 받으세요.
  • 가중치·KV 캐시는 llama.cpp 실측 기반 산술값, 오버헤드는 커뮤니티 관행 추정치입니다. 실제 사용량은 런타임(llama.cpp·ollama·vLLM)·드라이버·배치 설정에 따라 달라지므로 1~2GB 여유를 두고 판단하세요.
알아두면 좋아요

필요 VRAM은 이렇게 계산해요

가중치 = 파라미터 수 × 실효 bit ÷ 8
KV 캐시 = 2 × 레이어 × KV헤드 × head_dim × 컨텍스트 × 2B
총 필요 = 가중치 + KV 캐시 + 오버헤드(1~2GB 관행)
📌 검산 앵커: Llama 3.1 8B Q4_K_M = 8.03B × 4.8944 ÷ 8 = 4.91GB (실제 파일 4.92GB, 오차 0.2%) · KV는 토큰당 128KiB → 32K 컨텍스트에서 4.3GB. 최신 모델은 GQA 덕분에 KV헤드가 8개 수준이라 KV 캐시가 구세대(MHA)보다 4배 이상 작아요.

양자화별 크기 — Llama 3.1 8B 기준 실측

양자화bit/가중치8B 파일70B 파일용도
Q2_K3.163.18GB26.4GB최후 수단
Q3_K_M4.004.02GB34.3GBVRAM 부족 시
Q4_K_M4.894.92GB42.5GB기본 추천
Q5_K_M5.705.73GB50.0GB여유 있으면
Q6_K6.566.60GB57.9GB고품질
Q8_08.508.54GB75.0GB사실상 무손실
F1616.014.96GB141GB+원본

※ bit/가중치는 llama.cpp quantize README의 Llama-3.1-8B 실측값, 파일 크기는 bartowski GGUF 저장소 공표값. 모델·아키텍처에 따라 실효 bit은 ±1~2% 달라집니다.

VRAM이 모자랄 때 — 우선순위 3가지

1️⃣ KV 캐시 양자화

Q8_0 KV는 품질 영향이 거의 없이 캐시를 절반으로. 긴 컨텍스트를 쓴다면 가장 먼저 시도할 옵션이에요.

2️⃣ 컨텍스트 줄이기

KV 캐시는 컨텍스트에 정비례합니다. 128K를 다 쓸 일이 없다면 8~16K로 제한하는 것만으로 수 GB가 절약돼요.

3️⃣ 양자화 한 단계 아래로

Q4_K_M→Q3_K_M은 8B 기준 약 0.9GB 절약. 품질 타협이 시작되는 지점이라 마지막 카드로 쓰세요.

자주 묻는 질문 (FAQ)

Q1. 왜 모델 파일 크기보다 VRAM이 더 필요한가요?

VRAM에는 가중치(=파일 크기) 외에 두 가지가 더 올라갑니다. ① KV 캐시 — 대화 컨텍스트를 기억하는 메모리로, 컨텍스트 길이에 정비례해 커집니다(Llama 3.1 8B는 토큰당 128KiB → 32K 컨텍스트에서 약 4.3GB). ② 런타임 오버헤드 — CUDA 컨텍스트와 연산 버퍼로 1~2GB. 그래서 4.9GB짜리 Q4_K_M 8B 모델도 8GB GPU에서 긴 컨텍스트를 쓰면 빠듯해집니다.

Q2. 양자화는 어떤 걸 골라야 하나요?

커뮤니티 기본 추천은 Q4_K_M(약 4.89bit/가중치)입니다 — 원본 대비 품질 저하가 작으면서 용량이 F16의 약 30%예요. VRAM에 여유가 있으면 Q5_K_M·Q6_K로 올리고, 부족하면 Q3_K_M까지 내려볼 수 있습니다. Q2_K는 품질 손실이 눈에 띄게 커서 큰 모델을 억지로 구겨 넣을 때의 최후 수단으로 보세요. 같은 양자화라도 모델에 따라 실효 bit이 ±1~2% 다릅니다.

Q3. 8GB GPU로는 어떤 모델까지 가능한가요?

7~8B급 Q4_K_M(가중치 약 4.7~4.9GB)이 현실적인 상한입니다. 짧은 컨텍스트(4~8K)라면 여유 있게 돌고, 32K 이상 긴 컨텍스트는 KV 캐시를 Q8_0으로 양자화하면 가능해요. 12~14B는 Q3 계열로 내려야 해서 품질 타협이 필요합니다. 위 계산기에서 GPU를 선택하면 양자화별 판정을 한눈에 볼 수 있어요.

Q4. 70B 모델을 로컬에서 돌릴 수 있나요?

Q4_K_M 기준 가중치만 약 42.5GB라 단일 소비자 GPU(최대 32GB)로는 불가능합니다. 현실적인 방법은 ① 24GB×2 등 멀티 GPU, ② Mac 통합메모리 64GB 이상(GPU 가용 약 48GB), ③ Q2_K(약 26GB)로 낮춰 32GB급에서 구동 — 단 품질 저하 감수. CPU 오프로딩도 가능하지만 속도가 크게 떨어집니다.

Q5. Mac 통합메모리는 왜 75%만 계산하나요?

macOS의 Metal은 기본적으로 통합메모리의 약 75%까지만 GPU 작업 영역으로 허용합니다(recommendedMaxWorkingSetSize, 소용량 기기는 65~70% 수준). 예를 들어 32GB Mac이면 GPU 가용은 약 24GB예요. sysctl iogpu.wired_limit_mb로 상한을 올릴 수 있지만 시스템용 메모리를 침범하므로 OS·앱용 여유를 남겨두는 게 안전합니다.

Q6. KV 캐시 양자화(Q8_0·Q4_0)는 써도 되나요?

llama.cpp의 --cache-type-k/v 옵션으로 KV 캐시를 F16의 절반(Q8_0)이나 1/4(Q4_0)로 줄일 수 있습니다. Q8_0은 품질 영향이 거의 없어 긴 컨텍스트의 표준 선택이고, Q4_0은 장문에서 품질·속도 저하 보고가 있어 신중하게 쓰세요. V 캐시 양자화는 플래시 어텐션 활성화가 필요합니다. 예: 8B 모델 32K 컨텍스트의 KV가 4.3GB→2.1GB로 줄어 16GB GPU 여유가 생깁니다.

Q7. Gemma 3는 왜 KV 캐시가 유난히 작게 나오나요?

Gemma 3는 슬라이딩 윈도 어텐션(SWA) 구조로, 6개 레이어 중 5개는 최근 1,024토큰만 보고 1개만 전체 컨텍스트를 봅니다. 그래서 일반 공식으로 계산하면 5~6배 과대 추정돼요(27B 128K 기준 나이브 66GB vs 실제 약 12GB). 이 계산기는 llama.cpp의 iSWA 구현 기준으로 글로벌/로컬 레이어를 분리 계산합니다.

함께 쓰면 좋은 도구

🪙

AI 토큰 카운터

GPT·Claude 토큰·비용

🛠️

기술 스택 추천기

프로젝트 풀스택 추천

📋

JSON 포맷터

정렬·검증·타입 생성

🔐

Base64 인코더

텍스트↔Base64 변환

🔢

진법 변환기

2·8·10·16진수 변환

📏

단위 변환기

GB·GiB 등 14종 환산