로컬 LLM 메모리 계산법: RAM·VRAM 가이드

Q: Q4 모델이면 파라미터 수의 절반 GB만 있으면 되는가?

아니다. 실제 파일에는 양자화 보조 데이터가 있고 KV 캐시와 연산 버퍼가 추가된다.

Q: RAM 32GB와 VRAM 12GB로 32B Q4를 돌릴 수 있는가?

부분 offload는 가능할 수 있지만 둘을 44GB VRAM처럼 합산할 수 없고 속도가 낮아질 수 있다.

Q: 컨텍스트를 8K에서 32K로 늘리면 메모리도 정확히 4배가 되는가?

KV 캐시는 대체로 4배가 되지만 가중치는 그대로이므로 전체 메모리가 4배가 되는 것은 아니다.

Q: Apple 통합 메모리 64GB면 70B Q4에 충분한가?

대표 8K 계산에는 여지가 있지만 OS와 앱이 같은 풀을 쓰며 32K에서는 원시 합만 약 49.6GiB라 조건부다.

로컬 LLM용 RAM·VRAM은 모델 이름의 파라미터 수만 보고 고르면 부족하기 쉽다. 실제 GGUF 파일 크기 + 목표 컨텍스트의 KV 캐시 + 연산 버퍼 + 운영체제 여유를 합산해야 한다. 배치 1과 8K 컨텍스트를 기준으로 보면 Q4 8B는 8GB가 빠듯하고 12~16GB가 편하며, Q4 32B는 24GB가 경계선이고 32GB급이 안전하다.

핵심 요약

Q4는 정확히 4비트가 아니다. Q4_K_M에는 스케일과 보조 데이터가 들어가므로 실제 파일이 단순 계산보다 크다.
컨텍스트는 별도 비용이다. 가중치를 Q4로 줄여도 KV 캐시는 기본 F16일 수 있고 토큰 수에 따라 커진다.
RAM과 VRAM은 합산하지 않는다. 전용 GPU는 별도 풀이고 Apple Silicon은 OS와 GPU가 하나의 통합 메모리를 공유한다.
경계 용량은 피한다. 파일과 KV 합계에 15~30% 실행 여유를 더하고 OS용 메모리도 남긴다.

먼저 계산식부터 잡는다

가장 단순한 가중치 계산은 파라미터 수 × bits/weight ÷ 8이다. 그러나 이 값은 이론상 하한에 가깝다. GGUF 양자화는 블록별 스케일과 메타데이터를 포함하고 일부 텐서는 더 높은 정밀도를 쓸 수 있다. 구매나 배치 판단에는 모델 카드의 파라미터 수보다 내려받을 정확한 GGUF 파일 크기를 쓰는 편이 안전하다.

실행 장치 메모리 ≈ 가중치 W + KV 캐시 K + 연산·그래프 버퍼 C
보수적 모델 예산 ≈ (실제 GGUF + 목표 KV) × 1.15~1.30
시스템·통합 메모리에서는 OS와 다른 앱의 여유를 별도로 확보

여기서 15~30%는 포맷이 보장하는 상수가 아니라 OOM을 피하기 위한 계획 범위다. 백엔드, 배치 크기, GPU 커널, Flash Attention, 멀티모달 projector에 따라 실제 버퍼가 달라진다.

8B·14B·32B·70B 실제 GGUF 크기 비교

2026년 8월 3일 Hugging Face 파일 크기를 확인하고 8월 11일 원본 저장소 접근 상태를 다시 점검한 대표값이다. 8B와 70B는 Llama 3.1 Instruct, 14B와 32B는 Qwen2.5 Instruct 양자화 파일을 기준으로 했다. 같은 모델급이라도 구조와 양자화 도구에 따라 크기가 달라질 수 있다.

8B 14B 32B 70B 로컬 LLM Q4 Q8 GGUF 파일 크기 비교 — 모델급이 커질수록 Q4와 Q8의 저장·상주 메모리 차이가 확대된다
출처: Hugging Face GGUF 파일, llama.cpp 자료

모델급·대표 모델	Q4_K_M 실제 파일	Q8_0 실제 파일	8K F16 KV
8B · Llama 3.1	4.92GB (4.58GiB)	8.54GB (7.95GiB)	약 1.0GiB
14B · Qwen2.5	8.99GB (8.37GiB)	15.70GB (14.62GiB)	약 1.5GiB
32B · Qwen2.5	19.85GB (18.49GiB)	34.82GB (32.43GiB)	약 2.0GiB
70B · Llama 3.1	42.52GB (39.60GiB)	74.98GB (69.83GiB)	약 2.5GiB

GB는 10진 단위이고 GiB는 2진 단위다. 그래픽카드의 표기 용량과 도구의 출력 단위가 섞이면 경계에서 오판하기 쉬우므로 최종 판단은 byte 또는 GiB로 맞춰 다시 계산해야 한다.

컨텍스트가 길어지면 KV 캐시가 커진다

KV 캐시는 이미 처리한 토큰의 Key와 Value를 레이어별로 보관한다. 일반적인 decoder-only Transformer에서는 아래 식으로 근사할 수 있다.

KV bytes ≈ 2 × layers × tokens × KV_heads × head_dim × bytes_per_element × batch

GQA나 MQA 모델은 attention head보다 KV head 수가 적어 캐시가 줄어든다. 따라서 파라미터 수만으로 KV 메모리를 정확히 계산할 수 없고 모델의 config.json에서 레이어 수, KV head 수, head dimension을 확인해야 한다.

대표 모델급	8K F16 KV	32K F16 KV	128K F16 KV
8B	1.0GiB	4.0GiB	16.0GiB
14B	1.5GiB	6.0GiB	24.0GiB
32B	2.0GiB	8.0GiB	32.0GiB
70B	2.5GiB	10.0GiB	40.0GiB

표는 배치 1인 대표 GQA 구조의 설명용 계산값이다. sliding-window attention은 일부 레이어의 증가가 창 크기에서 멈출 수 있고, 동시 요청과 병렬 시퀀스는 사용량을 다시 늘린다.

Ollama 공식 문서는 2026년 8월 11일 기준 VRAM 24GiB 미만에서 4K, 24~48GiB에서 32K, 48GiB 이상에서 256K를 기본 컨텍스트로 안내한다. 또한 에이전트·코딩 도구처럼 긴 문맥이 필요한 작업은 64K 이상을 권하며, 컨텍스트를 늘리면 메모리 요구량도 증가한다고 명시한다. 설치 버전과 설정이 다를 수 있으므로 ollama ps의 실제 CONTEXT를 확인해야 한다.

용량별 현실적인 시작점

다음 표는 완전 GPU 가속 또는 Apple 통합 메모리에서 모델을 여유 있게 상주시키는 시작점이다. Q4_K_M, F16 KV, 8K 컨텍스트, 배치 1을 기준으로 하고 버퍼와 운영체제 여유를 반영했다.

목표 모델	가중치+KV 원시 합	빠듯한 경계	권장 시작점
8B Q4	약 5.58GiB	8GB	12~16GB
14B Q4	약 9.87GiB	12GB	16GB
32B Q4	약 20.49GiB	24GB	32GB
70B Q4	약 42.10GiB	48GB	64GB

이 표의 “권장”은 속도나 품질을 보장하는 제품 추천이 아니다. 32B Q4를 32K로 늘리면 F16 KV만 약 8GiB가 되어 원시 합이 약 26.5GiB로 커진다. 70B Q4를 32K로 쓰면 원시 합만 약 49.6GiB이므로 48GB 장치에는 맞지 않는다.

Q8 KV 캐시는 F16의 대략 절반, Q4 KV는 대략 4분의 1을 쓰도록 줄일 수 있지만 메타데이터 때문에 정확히 50%와 25%는 아니다. Ollama는 OLLAMA_KV_CACHE_TYPE, llama.cpp는 --cache-type-k와 --cache-type-v로 타입을 조정할 수 있다. 메모리 절약과 품질·지연시간의 trade-off를 실제 프롬프트로 확인해야 한다.

전용 GPU와 Apple 통합 메모리는 계산이 다르다

NVIDIA·AMD 전용 GPU

시스템 RAM 32GB와 VRAM 12GB를 더해 44GB GPU처럼 계산하면 안 된다. 완전 GPU offload에서는 가중치, KV, GPU 버퍼가 VRAM에 맞아야 한다. llama.cpp의 CPU·GPU hybrid inference로 일부 레이어를 시스템 RAM에 둘 수 있지만 PCIe 경계를 오가므로 완전 상주보다 느려질 수 있다.

Apple Silicon 통합 메모리

Apple Silicon은 CPU와 GPU가 하나의 통합 메모리 풀을 공유한다. 64GB Mac이 RAM 64GB와 VRAM 64GB를 따로 제공하는 구조가 아니다. macOS, 브라우저, 모델 가중치, KV 캐시, GPU 버퍼가 같은 64GB를 놓고 경쟁한다. 구매 후 증설도 불가능하므로 모델 예산을 꽉 채우지 말고 최소 15~25% 또는 4~8GiB 이상의 OS 여유를 남기는 편이 안전하다.

CPU-only와 부분 offload

CPU-only에서는 가중치와 KV가 시스템 RAM에 들어간다. llama.cpp의 기본 mmap은 모델 파일을 메모리 매핑해 불필요한 복사를 줄일 수 있지만 디스크가 물리 메모리를 대체하는 것은 아니다. working set이 RAM에 맞지 않아 swap과 page fault가 반복되면 생성 속도가 급격히 떨어질 수 있다.

구매·배치 전 7단계 체크리스트

모델 페이지에서 정확한 GGUF 변형과 파일 크기를 확인한다. Q4라는 이름만 보지 말고 Q4_K_M 같은 세부 타입까지 기록한다.
config.json에서 레이어 수, KV head 수, hidden size, attention head 또는 head dimension을 확인한다.
모델 최대 컨텍스트가 아니라 실제 프롬프트와 생성 토큰을 합친 목표 컨텍스트를 정한다.
서버라면 동시 시퀀스와 배치 수를 반영한다. 단일 사용자 계산을 그대로 복사하지 않는다.
실제 GGUF와 KV를 합친 뒤 런타임 버퍼 15~30%를 잡는다.
전용 VRAM은 10~20%, 시스템·통합 메모리는 OS와 앱을 위해 15~25% 여유를 둔다.
실행 뒤 ollama ps나 llama.cpp 시작 로그에서 실제 CONTEXT, CPU/GPU split, 메모리 사용량을 확인한다.

OOM이 나면 컨텍스트·batch·parallel 축소 → Flash Attention 확인 → KV Q8/Q4 검토 → 더 작은 양자화 → 일부 CPU offload 순서로 좁히는 편이 원인 확인에 유리하다. 여러 설정을 한 번에 바꾸면 어느 항목이 효과를 냈는지 알기 어렵다.

AI 개발용 RAM 용량 가이드 2026 — 개발 PC 전체 메모리를 32·64·96·128GB로 고르는 기준을 다룬다.
OpenClaw 설치 가이드: 맥미니로 개인 AI 에이전트 서버 구축하기 — 개인 서버 구성 흐름과 운영 항목을 이어서 볼 수 있다.
2026년 하반기 LLM 비교 — 로컬 실행과 API 사용을 비용·성능 관점에서 비교할 때 참고할 수 있다.

FAQ

Q4 모델이면 파라미터 수의 절반 GB만 있으면 되는가?

아니다. 그 값은 순수 4비트 가중치의 이론값일 뿐이다. 실제 Q4_K_M 파일에는 스케일과 보조 데이터가 있고 KV 캐시, 연산 버퍼, 런타임 여유가 추가된다.

RAM 32GB와 VRAM 12GB로 32B Q4를 돌릴 수 있는가?

부분 offload로 로드될 가능성은 있지만 44GB VRAM처럼 합산할 수는 없다. 모델 일부가 시스템 RAM에 남으면 CPU·GPU 전송과 CPU 계산 때문에 속도가 낮아질 수 있다. 완전 GPU 상주가 목표라면 VRAM만으로 가중치와 KV, 버퍼가 맞는지 따로 계산해야 한다.

컨텍스트를 8K에서 32K로 늘리면 메모리도 정확히 4배가 되는가?

KV 캐시 부분은 대체로 4배가 되지만 모델 가중치는 그대로다. 전체 프로세스 메모리가 4배가 되는 것은 아니다. sliding-window 구조, KV 양자화, 백엔드 버퍼에 따라 실제 증가폭도 달라진다.

Apple 통합 메모리 64GB면 70B Q4에 충분한가?

8K·배치 1의 대표 계산에서는 원시 합이 약 42.1GiB라 여지가 있지만 모델과 macOS, 다른 앱이 같은 풀을 쓴다. 32K에서는 원시 합이 약 49.6GiB로 커진다. 64GB를 권장 시작점으로 볼 수는 있어도 모든 70B 모델과 컨텍스트에서 충분하다고 보장할 수는 없다.

참고 자료

수치와 문서 접근 상태는 2026년 8월 11일에 다시 확인했다. 모델 파일과 런타임 기본값은 이후 갱신될 수 있다.