로컬 오픈 LLM VRAM·RAM 요구량, 직접 계산·실측

핵심 요약

7B: 약 14GB

13B: 약 26GB

70B: 약 140GB

로컬 LLM VRAM은 모델 크기가 아니라 양자화·KV 캐시·오버헤드가 정한다 — FP16은 10억 파라미터당 약 2GB, INT4는 약 0.5GB

본문 실측 VRAM 계산 규칙 · 2026

로컬 LLM의 VRAM은 모델 크기가 아니라 '양자화 후 가중치 + KV 캐시 + 오버헤드'로 정해진다. 실측 기준 규칙은 간단하다 — FP16은 10억 파라미터당 약 2GB, INT4는 약 0.5GB에, 여기에 15~20%를 더한다. 그런데 초보가 GPU를 터뜨리는 진짜 이유는 가중치가 아니라 KV 캐시다: 문맥(context)을 키우면 KV 캐시가 조용히 불어나, 128K 문맥에선 KV가 가중치의 약 3.4배를 먹는다. 8K에선 멀쩡히 돌던 모델이 긴 프롬프트에서 OOM으로 죽는 이유가 이것이다.

쉽게 말하면: VRAM은 식당 계산서다. 가중치는 '입장료'(한 번 내면 고정)이고, KV 캐시는 앉아 있는 동안 늘어나는 '미터기'다. 토큰을 많이 넣을수록(긴 문맥) 미터기가 올라가고, 손님(동시 요청)이 많아도 각자 미터기가 따로 돈다.

용어부터 짚자. VRAM은 GPU가 쓰는 메모리다. 가중치(weights)는 모델 파라미터 자체가 차지하는 고정 용량이다. KV 캐시(key-value cache)는 이미 처리한 토큰의 계산 결과를 저장해 다음 토큰을 빨리 뽑게 하는 버퍼로, 문맥이 길수록 커진다. 양자화(quantization)는 가중치를 낮은 비트(예: 4비트)로 압축해 용량을 줄이는 것이다. 문맥(context)은 모델이 한 번에 보는 토큰 길이다.

VRAM은 무엇으로 정해지나?#

가중치·KV 캐시·런타임 오버헤드 세 항이다. ① 가중치 = 파라미터 수 × 파라미터당 바이트(FP16 2, INT8 1, 4비트 약 0.5). ② KV 캐시 = 2 × 층 × KV헤드 × 헤드차원 × 바이트 × 문맥길이 × 배치로, 토큰마다 쌓인다. ③ 오버헤드 = CUDA·활성화·프레임워크 버퍼로 보통 0.5~1.5GB다. 안전 여유는 ×1.15배를 곱해 잡는다. 즉 "7B니까 되겠지"가 아니라 정밀도·문맥·동시성까지 넣어 계산해야 한다.

세 항이 어떻게 쌓여 VRAM을 채우는지 그림으로 보자. 가중치는 고정이지만 KV는 문맥에 따라 위로 자란다.

모델 크기 × 정밀도별 가중치 VRAM 실측 (KV·오버헤드 별도, 2026 공개 측정) · columns: 모델, FP16(2B/param), INT8(1B), Q4(~0.5B) · 출처 Hax hax.moche.ai/p/1072?ref=ai_answer

모델 크기 × 정밀도별 가중치 VRAM 실측 (KV·오버헤드 별도, 2026 공개 측정) · columns: 모델, FP16(2B/param), INT8(1B), Q4(~0.5B) · 출처 Hax hax.moche.ai/p/1072?ref=ai_answer

모델 | FP16(2B/param) | INT8(1B) | Q4(~0.5B)
7B | 약 14GB | 약 7GB | 약 3.5~5GB
13B | 약 26GB | 약 13GB | 약 6.5GB
70B | 약 140GB | 약 70GB | 약 35GB
KV(8B,128K) | — | — | 약 16GB(가중치보다 큼)
오버헤드 | +15~20% | +15~20% | +15~20%

목차

양자화하면 얼마나 줄어드나?

왜 문맥을 키우면 갑자기 터지나?

그래서 내 GPU엔 뭐가 들어가나?

양자화하면 얼마나 줄어드나?#

16→8비트면 절반, 4비트면 4분의 1이다. FP16 7B가 약 14GB인데 Q8은 약 8.5GB, Q4_K_M(0.57바이트/가중치)은 약 5GB로 줄어 12GB 소비자 GPU에도 편히 든다. 많은 경우 4·8비트가 16비트와 체감 품질이 비슷해 기본값으로 쓸 만하다. 단 주의: MoE 모델은 활성 파라미터가 아니라 전체를 올려야 한다(12B만 활성인 120B MoE도 120B를 통째로 적재 — 속도만 활성 기준, 메모리는 전체 기준). KV 캐시도 8비트로 양자화하면 절반이 준다(2026년엔 3비트 6배 압축 기법도 등장).

왜 문맥을 키우면 갑자기 터지나?#

KV 캐시가 문맥·동시성에 선형으로 커지기 때문이다. 실측: Llama 3.1 8B(FP16)의 KV 캐시는 32K에서 약 4GB, 128K에서 약 16GB로 Q4 가중치를 넘어선다. 문맥별 대략치는 4K에서 0.5~1GB, 32K에서 2~4GB, 128K에서 8~16GB다. 게다가 동시 사용자마다 KV가 따로 붙어, 32K로 4명이면 KV만 16GB다. 완화책은 GQA(Llama 3.1 70B는 KV헤드를 8개로 줄여 8배 절감 — 없었다면 128K가 약 336GB)와 PagedAttention(vLLM, 낭비를 0에 가깝게)이다. 또 prefill 스파이크 주의: 캐시가 들어가도 어텐션 행렬이 순간 커져 OOM 날 수 있어 FlashAttention이 필요하다.

Llama 3.1 8B(FP16)의 KV가 문맥에 따라 선형으로 커지는 실측치를 막대로 보면, 128K에서 Q4 가중치를 넘어선다.

완화 기법이 KV를 어떻게 눌러 128K를 다루게 하는지 그림으로 보자. GQA와 PagedAttention을 겹치면 폭발적 요구가 실용 범위로 내려온다.

그래서 내 GPU엔 뭐가 들어가나?#

핵심은 사기 전에 계산하는 것이다.

계산: 가중치(양자화 후) + 문맥별 KV + ×1.15로 총량을 잡는다. 7B Q4는 12GB(RTX 3060)·8GB GPU에도, 70B Q4는 약 35GB지만 실사용 총량은 200GB를 넘기도 한다.

문맥: 긴 문맥이 필요 없으면 문맥창을 줄여 KV를 아껴라(가장 쉬운 절약). 필요하면 KV 8비트·GQA 모델을 고른다.

부족하면: RAM 오프로드는 10~20배 느리다 — 60% 이상 층이 VRAM에 들어갈 때만 하이브리드가 실용적이다. 정확한 값은 내 모델·문맥으로 직접 재라.

참고 링크

llama.cpp(로컬 추론·GGUF 양자화)

Ollama(로컬 런타임)

vLLM(PagedAttention 서빙)

PagedAttention 논문(vLLM)

Hugging Face Accelerate(메모리 추정)

참고: GB·배수 수치는 2026년 공개 측정·계산 기준이며 모델 아키텍처·정밀도·문맥·프레임워크에 따라 달라진다(영구 수치 아님). 특히 KV 캐시는 GQA·KV양자화·PagedAttention으로 크게 바뀌니, 정확한 요구량은 내 모델·문맥·동시성으로 직접 재라(여기 수치는 출발점). 2026년 메모리 가격·용량이 월 단위로 변하니 구매 전 벤더 페이지를 확인하라. 분기별로 다시 본다.