8B 모델 4비트 파일은 4.58GiB인데 왜 카드가 터질까요. vLLM 기본값 0.92, KV 캐시 GQA 공식, llama.cpp 양자화 실측 표까지 VRAM 실사용량 계산법을 2026년 8월 기준 공식 문서 수치로 정리했습니다.
VRAM 계산 개요
VRAM을 계산할 때 가장 먼저 버려야 할 공식은 “파라미터 수 ÷ 2 = 필요 VRAM” 입니다. 가중치만 보고 대화 기록을 담는 KV 캐시와 런타임 오버헤드를 통째로 빠뜨리는 계산이라, 실제로는 카드가 꽉 차서 모델이 뜨지 않거나 컨텍스트가 조용히 잘려 나갑니다. 이 글은 vLLM·llama.cpp·Ollama·NVIDIA·Hugging Face 공식 문서에 명시된 수치(2026년 8월 30일 확인 기준)로 VRAM 실사용량이 어떻게 구성되는지, 널리 퍼진 계산법이 어디서 얼마나 어긋나는지 정리했습니다.
간극의 규모부터 말씀드리겠습니다. llama.cpp 공식 양자화 표에서 Llama-3.1-8B의 Q4_K_M은 실제 4.8944 bpw·4.58GiB 입니다. “4비트는 F16의 1/4″이라는 통념으로 계산하면 3.74GiB니까 단순 계산 대비 1.225배 가 이미 어긋납니다. KV 캐시 쪽은 더 심각합니다. vLLM 공식 문서의 hidden_size 기반 공식과 NVIDIA의 GQA 기반 공식은 Qwen3-8B에서 정확히 4배 차이가 나고, 40,960 토큰 기준으로 22.5GiB와 5.62GiB로 갈립니다. 24GB 카드에 들어가느냐 마느냐가 공식 선택 하나로 뒤집히는 셈입니다.
이 글은 개발자 트랙입니다. 직접 모델을 띄우거나 서버 스펙을 결정해야 하는 분을 대상으로, 가중치·KV 캐시·활성화·오버헤드 네 항목을 각각 어떤 근거로 계산하는지, 계산기 대신 무엇을 봐야 하는지 다룹니다. 학습(파인튜닝) 세부 최적화와 분산 학습 구성은 다루지 않습니다.
1. VRAM은 네 덩어리로 나뉜다 — vLLM 기동 로그가 정답지다
VRAM 실사용량을 추정하는 가장 정확한 방법은 계산기가 아니라 프레임워크 기동 로그 입니다. vLLM은 기동할 때 더미 forward pass로 피크 메모리를 실측하는 프로파일링을 돌리고, 그 결과를 네 갈래로 분해해 로그에 남깁니다. vLLM PR #10511에 실린 실제 로그 예시입니다.
| 항목 | 실측값 | 의미 |
|---|---|---|
| total_gpu_memory | 79.22 GiB | 카드 총량 |
| × gpu_memory_utilization | 0.90 | 점유 비율 |
| = 사용 가능 예산 | 71.29 GiB | vLLM이 쓸 수 있는 전부 |
| model weights | 14.96 GiB | 가중치 |
| non_torch_memory | 0.18 GiB | PyTorch 추적 밖 할당 |
| PyTorch activation peak | 1.26 GiB | 활성화 피크 |
| KV Cache 잔여 | 54.90 GiB | 나머지 전부 |
핵심은 KV 캐시가 “계산되는 값”이 아니라 “남는 값” 이라는 데 있습니다. vLLM은 예산에서 가중치·non_torch·활성화 피크를 뺀 나머지를 전부 KV 캐시로 선점 할당합니다. 그래서 로 보면 카드가 거의 꽉 차 보이지만, 그게 실제 필요량은 아닙니다. 실사용량은 가 아니라 기동 로그로 읽으십시오.
한 번 측정한 값은 재사용됩니다. vLLM은 프로파일링 결과를 재현하는 값을 로그에 남기고, 이 값을 고정하면 재기동 때 프로파일링을 건너뜁니다. 다만 공식 문서는 이 값이 “only valid on the same GPU with the same initial free memory”라고 못 박습니다 — 같은 GPU, 같은 초기 여유 메모리 조건에서만 유효합니다. kv_cache_memory_bytes의 기본값은 None이라, 지정하지 않으면 gpu_memory_utilization으로부터 자동 추론됩니다.
활성화 메모리의 크기 감각도 잡아둘 만합니다. vLLM-Omni 문서는 추론 시 활성화 메모리를 가중치 대비 10-30% 수준으로 서술하는데, 위 로그에서는 14.96GiB 가중치에 1.26GiB로 8.4%였습니다. 문서 범위보다 낮게 나온 사례이니, 문서 값은 상한 감각으로만 쓰는 편이 안전합니다.
용어 풀이
1. KV 캐시 — 이미 처리한 토큰의 키·값 벡터를 저장해 재계산을 피하는 메모리로, 대화가 길어질수록 선형으로 커진다.
2. 활성화 메모리 — 순전파 도중 계층 사이를 흐르는 중간 텐서가 차지하는 일시적 메모리다.
3. 양자화(Quantization) — 가중치를 16비트 대신 8·4비트 등 낮은 정밀도로 저장해 용량을 줄이는 기법이다.
2. gpu_memory_utilization 기본값은 0.9가 아니라 0.92다
VRAM 예산을 계산할 때 가장 흔하게 어긋나는 지점이 vLLM의 점유율 기본값입니다. 2026년 8월 30일 확인 기준 vLLM stable 문서와 vllm serve CLI 문서는 모두 Default: 0.92 로 표기합니다. 반면 널리 인용되는 튜닝 가이드들은 0.9로 서술합니다. 2026년 3월 3일자 Red Hat Developer 문서는 vLLM이 “약 90%를 모델과 KV 캐시에 할당하고 나머지 10%를 CUDA 그래프와 런타임 오버헤드로 남긴다”는 취지로 설명합니다.
0.02 차이는 작아 보이지만 카드 용량에 곱해지면 실체가 생깁니다.
| 카드 용량 | 0.90 적용 | 0.92 적용 | 차이 |
|---|---|---|---|
| 24 GiB | 21.6 GiB | 22.08 GiB | 0.48 GiB |
| 32 GiB | 28.8 GiB | 29.44 GiB | 0.64 GiB |
| 79.22 GiB (H100급) | 71.29 GiB | 72.88 GiB | 1.59 GiB |
0.5GiB는 Qwen3-8B 기준 약 3,600토큰 분량의 KV 캐시입니다. 계산기나 사내 문서가 0.9로 굳어 있다면 KV 예산이 그만큼 어긋난 채로 굴러가고 있다는 뜻입니다. 0.9에서 0.92로 바뀐 시점·PR·릴리스 번호는 공식 자료에서 확인하지 못했습니다(확인 필요). 2026년 3월 시점 자료가 0.9, 2026년 8월 30일 시점 문서가 0.92이니 그 사이에 바뀐 듯하지만 단정할 근거는 없습니다.
반대 방향으로 조정할 여지도 있습니다. Red Hat Developer는 예비로 남는 10%가 “H100에서는 최대 8GB에 이를 수 있다”고 지적하며 --gpu-memory-utilization=0.95 상향과 --kv-cache-dtype=fp8을 권합니다. 다만 프레임워크 기본값이 아닌 제3자 권고이므로, 상향한 뒤에는 반드시 실제 워크로드에서 OOM 여부를 확인하십시오.
함께 알아둘 기본값들도 정리해 둡니다. vLLM의 block_size는 16토큰, 멀티모달 프로세서 캐시 mm_processor_cache_gb는 4GiB, CPU KV 캐시 VLLM_CPU_KVCACHE_SPACE도 4GiB가 기본입니다. 멀티모달 모델을 안 쓰는데 프로세서 캐시가 4GiB를 잡고 있다면 그것부터 회수 대상입니다.
3. KV 캐시 공식 — hidden_size를 쓰면 4배가 부풀려진다
이 글에서 가장 실질적인 손해가 나는 지점입니다. KV 캐시 공식은 두 가지가 유통되고 있고, 둘은 GQA 모델에서 결과가 크게 다릅니다.
vLLM-Omni 공식 문서의 서술은 kv_cache_memory ≈ batch_size × seq_len × hidden_size × num_layers × 2 × dtype_size입니다. 반면 NVIDIA Technical Blog의 공식은 토큰당 2 × num_layers × (num_heads × dim_head) × precision_in_bytes이고, 여기서 헤드는 KV 헤드 를 뜻합니다. GQA(Grouped Query Attention)를 쓰는 최신 모델은 어텐션 헤드보다 KV 헤드가 훨씬 적어서 차이가 벌어집니다.
Qwen3-8B의 공식 config.json 값으로 계산해 보겠습니다. num_hidden_layers 36, num_attention_heads 32, num_key_value_heads 8, head_dim 128, hidden_size 4096, max_position_embeddings 40960, dtype는 bfloat16입니다.
GQA 공식으로 토큰당 KV 캐시는 147,456바이트(144KiB) 입니다. 컨텍스트 길이별로 환산하면 이렇습니다.
| 컨텍스트 | GQA 공식 KV | hidden_size 공식 KV | 비율 |
|---|---|---|---|
| 4,096 토큰 | 0.56 GiB | 2.25 GiB | 4.0배 |
| 32,768 토큰 | 4.5 GiB | 18.0 GiB | 4.0배 |
| 40,960 토큰 (모델 최대) | 5.62 GiB | 22.5 GiB | 4.0배 |
| 131,072 토큰 | 18.0 GiB | 72.0 GiB | 4.0배 |
Qwen3-8B는 KV 헤드가 8개, 어텐션 헤드가 32개라 정확히 4.0배 차이가 납니다. 40,960 토큰 기준으로 5.62GiB는 24GB 카드에 여유 있게 들어가지만, 22.5GiB는 가중치를 얹기도 전에 카드를 다 먹습니다. 배포 가능/불가능 판정이 공식 선택 하나로 뒤집힙니다. GQA 모델을 다룬다면 hidden_size 기반 공식은 쓰지 마십시오.
오버헤드를 상수로 잡는 관행도 여기서 깨집니다. Hugging Face Accelerate 문서는 추론 시 EleutherAI 기준으로 최대 20%를 추가하라고 안내하고, Modal의 공식 M = (P × Q/8) × 1.2 역시 1.2배를 KV 캐시 등의 오버헤드로 잡습니다. 그런데 Qwen3-8B(8.2B 파라미터) bf16 가중치는 15.27GiB고 그 20%는 3.05GiB인데, 40,960 토큰 KV만으로 5.62GiB로 이미 20%를 넘습니다. KV는 시퀀스 길이에 선형으로 늘어나므로 컨텍스트를 무시한 상수 배율은 긴 컨텍스트에서 반드시 과소 추정합니다.
NVIDIA가 든 예시는 Llama 2 7B·FP16·4096 컨텍스트·배치 1에서 KV 캐시 약 2GB, 가중치 약 14GB입니다. 짧은 컨텍스트에서는 20% 규칙이 그럭저럭 맞아떨어지는 구간이라는 점도 함께 보시면 좋습니다.
용어 풀이
1. GQA(Grouped Query Attention) — 여러 쿼리 헤드가 키·값 헤드를 공유해 KV 캐시 용량을 줄이는 어텐션 구조다.
2. 컨텍스트 윈도우 — 모델이 한 번에 참조할 수 있는 최대 토큰 수로, KV 캐시 크기를 직접 결정한다.
3. bpw(bits per weight) — 파라미터 하나당 실제로 쓰인 평균 비트 수로, 양자화 이름이 아닌 이 값이 파일 크기를 정한다.
4. 양자화 실측표 — “4비트 = 1/4″이 아니다
가중치 쪽은 다행히 추정할 필요가 없습니다. llama.cpp 공식 문서(tools/quantize/README.md)가 meta-llama/Llama-3.1-8B를 측정한 실제 bpw와 파일 크기를 표로 공개합니다.
| 양자화 | 실제 bpw | 파일 크기 |
|---|---|---|
| F16 | 16.0005 | 14.96 GiB |
| Q8_0 | 8.5008 | 7.95 GiB |
| Q6_K | 6.5633 | 6.14 GiB |
| Q5_K_M | 5.7036 | 5.33 GiB |
| Q4_K_M | 4.8944 | 4.58 GiB |
| Q4_K_S | 4.6672 | 4.36 GiB |
| Q3_K_M | 3.9960 | 3.74 GiB |
| Q2_K | 3.1593 | 2.95 GiB |
| IQ2_XXS | 2.3824 | 2.23 GiB |
| IQ1_S | 2.0042 | 1.87 GiB |
이름과 실제 비트가 어긋난다는 게 핵심입니다. Q4_K_M의 실제 bpw는 4.8944로 “4비트”보다 22% 높습니다. F16의 1/4로 단순 계산하면 3.74GiB인데 실제는 4.58GiB, 1.225배 초과입니다. 흥미롭게도 3.74GiB는 Q3_K_M의 실제 크기와 같습니다. “4비트 = 1/4″로 계산한 사람은 결국 Q3_K_M의 예산을 잡아놓고 Q4_K_M을 다운로드하는 셈입니다.
품질까지 함께 보려면 제3자 측정이 유용합니다. arXiv 프리프린트 2601.14277(2026년 1월 11일)은 Llama-3.1-8B-Instruct를 대상으로 파일 크기와 WikiText-2 perplexity를 함께 보고합니다.
| 양자화 | 크기(MiB) | ppl | 압축률 |
|---|---|---|---|
| Q3_K_M | 3,825.27 | 7.96 | 75.03% |
| Q4_K_M | 4,685.30 | 7.56 | 69.41% |
| Q5_K_M | 5,459.93 | 7.40 | 64.35% |
| Q6_K | 6,282.97 | 7.35 | 58.98% |
| Q8_0 | 8,137.64 | 7.33 | 46.87% |
| FP16 | 15,317.02 | 7.32 | — |
Q4_K_M에서 Q5_K_M으로 올리면 ppl이 7.56 → 7.40으로 0.16 좋아지는 대신 용량은 약 775MiB 늘어납니다. Q6_K에서 Q8_0으로 갈 때는 ppl 개선이 0.02인데 용량은 1.85GiB가 늘어납니다. Q6_K 위쪽은 용량 대비 품질 이득이 사실상 사라지는 구간 입니다. 다만 이 측정의 조건은 Xeon Platinum 8488C 듀얼소켓 CPU 환경에 pp=512 / tg=128이라, 파일 크기와 품질 비교로만 유효하고 GPU VRAM 실사용량으로 그대로 옮길 수 없습니다.
5. 기본값이 조용히 깎는 것들 — 그리고 줄이는 순서
계산을 다 맞춰도 런타임 기본값이 결과를 바꿔놓기도 합니다. 가장 흔한 게 Ollama의 자동 컨텍스트입니다. Ollama 공식 문서는 감지된 VRAM 용량으로 기본 컨텍스트를 결정한다고 명시합니다 — 24GiB 미만이면 4k, 24~48GiB면 32k, 48GiB 이상이면 256k 입니다. 같은 문서는 웹 검색·에이전트·코딩 도구처럼 긴 컨텍스트가 필요한 작업이라면 최소 64,000토큰 으로 설정하라고 권합니다. 24GB 미만 카드로 긴 문서를 넣었는데 앞부분을 잊는다면, 모델 성능 문제가 아니라 4k 기본값에 잘린 것일 수 있습니다. Ollama 문서에는 컨텍스트 길이별 메모리 사용량 표가 없습니다(확인 필요 — 근거 수치 비공개).
llama-server 쪽 기본값도 정리해 둡니다. -c/--ctx-size는 (0이면 모델 설정에서 로드), /는 ****, 은 8192MiB, 은 , 은 (auto)입니다. KV 캐시 타입이 f16 기본이라는 점이 중요합니다. 여기가 가장 먼저 손댈 자리이기 때문입니다.
줄이는 순서는 정해져 있습니다.
| 순서 | 조치 | 효과 |
|---|---|---|
| 1 | KV dtype을 fp8 / q8_0으로 | Qwen3-8B 40,960토큰 기준 5.62 → 2.81 GiB |
| 2 | max_model_len·max_num_seqs 축소 |
KV가 길이에 선형이므로 즉효 |
| 3 | gpu_memory_utilization 0.92 → 0.95 |
H100 기준 최대 8GB 회수 여지 |
| 4 | 가중치 양자화 하향 | 품질 손실 동반, 최후 수단 |
가중치부터 깎으면 품질만 떨어지고 병목은 그대로 남습니다. 긴 컨텍스트 워크로드에서 진짜 병목은 KV 캐시이기 때문입니다. 그 밖의 노브로는 enforce_eager(그래프 캡처 완전 비활성화), 멀티모달을 안 쓸 때의 mm_processor_cache_gb 회수가 있습니다.
하드웨어로 해결하려는 경우, 지금은 시점이 좋지 않습니다. TrendForce가 2026년 8월 4일 보도한 바에 따르면 한국에서 RTX 5090 32GB는 7월 중순 이후 최대 150만원 올라 약 730만원 수준이며, RTX 5060 Ti 8GB는 약 10만원(US$70), RTX 5070은 약 20만원(US$140) 올랐습니다. RTX 5090의 공식 사양은 32GB GDDR7·512-bit 로 대역폭은 강하지만 용량이 벽입니다. 반면 DGX Spark는 128GB LPDDR5x·273GB/s 통합 메모리로 공식적으로 70B 파인튜닝, 200B 추론, 4대 연결 시 700B를 표방합니다. 용량이 병목이면 통합 메모리, 토큰 생성 속도가 병목이면 전용 VRAM 이라는 갈림이 두 공식 사양만으로 이미 드러납니다.
용량 자체를 우회하는 방향도 나오고 있습니다. 2026년 8월 17일 vLLM 공식 블로그는 124GB 규모 Cosmos3-Super를 계층별 오프로드로 서빙해 B300에서 피크 HBM 12.62GB(HSDP 42.00GB 대비 30%)를 기록했다고 밝혔습니다. 대신 단일 요청 지연은 스텝당 870ms → 1,020ms로 늘었습니다. 메모리를 3분의 1로 줄이는 대신 지연을 약 17% 감수하는 거래입니다.
마지막으로 웹 계산기 이야기입니다. apxml VRAM 계산기(v3.0, 2026년 8월 3일 / 최초 v1.0.0은 2025년 5월 6일)는 가중치 정밀도·KV 캐시·활성화·시스템 예비분을 모델링하지만, 실측 대비 정확도 진술이 페이지에 없고 내부 공식과 시스템 예비분 값도 비공개입니다(확인 필요). 반대로 Hugging Face Accelerate는 가 CUDA full precision에서 실제 413.68MB를 쓰고 계산기는 413.18MB로 추정했다고 실측 대조를 명시하지만, 이쪽은 가중치만 다루고 KV 캐시를 계산하지 않습니다. 구매 전 후보를 좁힐 때는 계산기, 배포 직전에는 기동 로그 로 나눠 쓰는 편이 현실적입니다.
정리
VRAM 실사용량은 가중치·KV 캐시·활성화·런타임 오버헤드 네 덩어리고, 이 중 배포 성패를 가르는 것은 컨텍스트 길이에 선형으로 늘어나는 KV 캐시입니다. GQA 모델에서 hidden_size 기반 공식을 쓰면 Qwen3-8B 기준 정확히 4배가 부풀려져 5.62GiB짜리 워크로드가 22.5GiB로 계산되고, 가중치 쪽에서도 “4비트 = 1/4” 통념은 Q4_K_M 실측 4.58GiB 대비 1.225배 어긋납니다. 숫자는 llama.cpp bpw 표와 모델 config.json에서 가져오고, 최종 확인은 vLLM 기동 로그의 4분할로 하는 것이 가장 확실합니다. 줄여야 한다면 KV dtype → 컨텍스트 길이 → 점유율 → 가중치 순서를 지키십시오. 가중치부터 깎는 것은 품질만 잃고 병목은 남기는 선택입니다.
참고 자료
조사 기준일: 2026년 08월 30일
본문의 수치는 아래 자료에서 확인한 것입니다. 제조사 공식 자료(T1)와 전문 매체 실측(T2)을 구분해 표기했습니다. 가격·공급 상황은 변동이 크므로 기준일 이후의 값은 다시 확인해야 합니다.
Tier 1
– vLLM — CacheConfig API 문서: https://docs.vllm.ai/en/stable/api/vllm/config/cache/ (확인 2026-08-30)
– vLLM — vllm serve CLI 문서: https://docs.vllm.ai/en/stable/cli/serve.html (확인 2026-08-30)
– vLLM — Optimization and Tuning: https://docs.vllm.ai/en/stable/configuration/optimization/ (확인 2026-08-30)
– vLLM — Conserving Memory: https://docs.vllm.ai/en/latest/configuration/conserving_memory/ (확인 2026-08-30)
– vLLM-Omni — GPU Memory Calculation and Configuration: https://docs.vllm.ai/projects/vllm-omni/en/latest/configuration/gpu_memory_utilization/ (확인 2026-08-30)
– vLLM PR #10511 — overhaul memory profiling: https://github.com/vllm-project/vllm/pull/10511 (확인 2026-08-30)
– vLLM Blog — Distributed Layerwise Offload, 2026-08-17: https://vllm.ai/blog/2026-08-17-distributed-layerwise-offload (확인 2026-08-30)
– NVIDIA Technical Blog — Mastering LLM Techniques: Inference Optimization: https://developer.nvidia.com/blog/mastering-llm-techniques-inference-optimization/ (확인 2026-08-30)
– NVIDIA — GeForce RTX 5090 제품 페이지: https://www.nvidia.com/en-us/geforce/graphics-cards/50-series/rtx-5090/ (확인 2026-08-30)
– NVIDIA — DGX Spark 제품 페이지: https://www.nvidia.com/en-us/products/workstations/dgx-spark/ (확인 2026-08-30)
– Hugging Face Transformers — GPU memory usage(model_memory_anatomy): https://huggingface.co/docs/transformers/main/model_memory_anatomy (확인 2026-08-30)
– Hugging Face Accelerate — model_size_estimator.md: https://raw.githubusercontent.com/huggingface/accelerate/main/docs/source/usage_guides/model_size_estimator.md (확인 2026-08-30)
– llama.cpp — tools/quantize/README.md: https://raw.githubusercontent.com/ggml-org/llama.cpp/master/tools/quantize/README.md (확인 2026-08-30)
– llama.cpp — tools/server/README.md: https://raw.githubusercontent.com/ggml-org/llama.cpp/master/tools/server/README.md (확인 2026-08-30)
– Ollama — Context length: https://docs.ollama.com/context-length (확인 2026-08-30)
– Qwen — Qwen3-8B config.json: https://huggingface.co/Qwen/Qwen3-8B/raw/main/config.json (확인 2026-08-30)
– arXiv 2309.06180 — Efficient Memory Management for LLM Serving with PagedAttention (SOSP 2023): https://arxiv.org/abs/2309.06180 (확인 2026-08-30, 초록에서 2-4× 처리량만 확인)
Tier 2
– arXiv 2601.14277 — Which Quantization Should I Use? (Uygar Kurt, 2026-01-11): https://arxiv.org/html/2601.14277v1 (확인 2026-08-30)
– Red Hat Developer — Practical strategies for vLLM performance tuning (2026-03-03): https://developers.redhat.com/articles/2026/03/03/practical-strategies-vllm-performance-tuning (확인 2026-08-30)
– Modal Blog — How much VRAM do I need for LLM inference? (2024-09-01): https://modal.com/blog/how-much-vram-need-inference (확인 2026-08-30)
답글 남기기