LLM VRAM 요구량 계산기

이 계산기에 모델, 가중치 양자화(quantization), KV cache(KV 캐시) 정밀도, 컨텍스트 길이, 동시 시퀀스 수와 GPU를 넣으면 LLM VRAM 요구량을 가중치와 KV cache로 나눠 계산하고, 그 GPU에서 여유 있음·빠듯함·부족 중 어디에 해당하는지 판정합니다. 핵심 공식은 두 개입니다. 가중치는 파라미터 수 × bpw(bits per weight, 가중치당 평균 비트 수) ÷ 8 바이트이고, KV cache는 컨텍스트 길이와 동시 시퀀스 수에 비례해 늘어납니다. 그래서 전체 컨텍스트를 저장하는 층만 있는 모델이라면 컨텍스트를 4배로 늘릴 때 KV cache도 4배가 됩니다. 최근 토큰만 저장하는 층이나 선형 어텐션 층을 섞은 모델은 그보다 덜 늘어납니다. 결과는 모델 config와 공개 실측 bpw로 계산한 추정치이며, 엔진·버전·설정에 따라 실제 사용량은 달라질 수 있습니다.

LLM VRAM 계산기 사용법

처음 화면은 Llama 3.1 8B Instruct, GGUF Q4_K_M, BF16 KV cache, 8,192토큰, 시퀀스 1개, GeForce RTX 4060(8 GB) 조합입니다. 이 조건의 결과는 가중치 4.58 GiB, KV cache 1.00 GiB, 최소 요구량 5.58 GiB, 권장 요구량 6.63 GiB이고, 8 GB는 7.45 GiB로 환산되므로 여유 있음(권장 기준 0.82 GiB 남음)입니다.

입력은 위에서 아래로 바꿔 보면 됩니다. 각 칸의 의미는 계산기 안의 도움말에 있으므로, 여기서는 어떤 순서로 무엇을 바꾸면 좋은지만 정리합니다.

주요 GPU별 판정 표는 같은 모델·설정을 GPU 1장, 표기 용량 100% 기준으로 한꺼번에 판정합니다. 한 번 설정해 두면 8 GB부터 512 GB까지 어느 용량부터 여유가 생기는지 바로 보입니다.

목록에 없는 모델은 Hugging Face 저장소의 config.json에서 num_hidden_layers, num_key_value_heads, head_dim, sliding_window 같은 값을 읽어 구조값 칸에 넣으면 됩니다. 이때 총 파라미터 수는 양자화 저장소가 아니라 원본(BF16) 저장소나 모델 카드의 값을 쓰는 것이 안전합니다. 양자화 저장소는 패킹된 정수 원소 수를 파라미터 수처럼 집계하는 경우가 있어 실제보다 작게 나올 수 있습니다.

LLM VRAM은 무엇으로 정해지는가

추론에 필요한 메모리는 세 부분으로 나눌 수 있습니다. 앞의 두 부분은 모델 구조로 계산할 수 있고, 마지막 부분은 공개된 공식 고정값이 없습니다.

flowchart LR
    A["가중치<br/>파라미터 수 × bpw ÷ 8"] --> D["최소 요구량<br/>(여유 제외)"]
    B["KV cache<br/>토큰 수 × 시퀀스 수에 비례"] --> D
    C["선형 어텐션 상태<br/>시퀀스당 고정 크기"] --> D
    D --> E["권장 요구량<br/>최소 × (1 + 여유율) + 고정 여유"]
    F["런타임 여유<br/>활성화·CUDA graph 등"] --> E

계산기는 앞의 두 항(일부 모델은 선형 어텐션 상태까지)을 더해 최소 요구량을 만들고, 여기에 여유율 10%와 고정 여유 0.5 GiB를 더해 권장 요구량을 만듭니다. 두 값 모두 입력으로 조정할 수 있습니다.

가중치: 파라미터 수 × bpw ÷ 8

가중치 메모리는 파라미터 수에 파라미터 하나가 차지하는 평균 비트 수를 곱하고 8로 나눈 바이트입니다.

BF16이면 16 bpw라 파라미터당 2바이트, FP8·INT8이면 1바이트입니다. 기본값인 Llama 3.1 8B(8,030,261,248개)를 Q4_K_M(4.8944 bpw)으로 계산하면 4.91 GB, 즉 4.58 GiB입니다. llama.cpp가 공개한 같은 모델의 Q4_K_M 실측 크기도 4.58 GiB입니다.

MoE(Mixture of Experts, 전문가 혼합) 모델은 활성 파라미터가 아니라 총 파라미터로 계산합니다. 토큰마다 일부 전문가만 계산에 쓰이지만, 어느 전문가가 선택될지 모르므로 모든 전문가 가중치를 메모리에 올려 두어야 하기 때문입니다. Qwen3-30B-A3B는 활성 파라미터가 3.3B이지만 총 30.5B를 적재하므로 Q4_K_M 가중치가 17.40 GiB입니다.

4bit 양자화가 4.0 bpw가 아닌 이유

4bit 양자화라고 해서 파라미터당 정확히 0.5바이트가 되지는 않습니다. 실제 포맷은 일정 개수의 가중치마다 스케일 값을 따로 저장하고, 임베딩·출력층 같은 일부 텐서는 더 높은 정밀도로 남겨 두기 때문입니다.

이 차이는 큰 모델에서 크게 벌어집니다. Llama 3.3 70B 가중치는 이론 INT4로 32.85 GiB지만 Q4_K_M으로는 40.20 GiB입니다. 약 7 GiB 차이라 GPU 한 장 판정이 바뀔 수 있습니다. AWQ·GPTQ도 양자화한 선형층만 4.156 bpw이고 임베딩과 출력층은 FP16·BF16으로 남으므로, 어휘가 큰 모델에서는 전체 평균이 더 올라갑니다. Qwen3-14B-AWQ의 전체 평균은 5.40 bpw입니다.

GGUF 값은 llama.cpp가 Llama 3.1 8B에서 측정한 평균입니다. 모델마다 0.1-0.2 bpw 정도 차이가 날 수 있으며, Qwen3-8B 공식 GGUF의 Q4_K_M은 4.911 bpw였습니다.

KV cache: 컨텍스트 길이에 비례

KV cache는 앞서 처리한 토큰의 key와 value를 층마다 저장해 두는 공간입니다. 새 토큰을 만들 때마다 이전 토큰을 다시 계산하지 않으려고 쓰는 것이므로, 저장할 토큰이 많을수록 커집니다.

Llama 3.1 8B는 32층, KV head 8개, head_dim 128이므로 BF16에서 토큰 하나당 128 KiB입니다. 8,192토큰이면 1.00 GiB, 32,768토큰이면 4.00 GiB, 131,072토큰이면 16.00 GiB입니다. 128K 컨텍스트에서는 KV cache가 Q4_K_M 가중치(4.58 GiB)의 3배를 넘습니다. 동시 시퀀스 수를 2로 올려도 같은 비율로 두 배가 됩니다.

KV cache 정밀도를 낮추면 이 값이 줄어듭니다. FP8은 원소당 1바이트, llama.cpp의 q8_0은 1.0625바이트, q4_0은 0.5625바이트입니다. 다만 품질에 주는 영향은 모델과 작업에 따라 다르고 이 계산기는 판단하지 않습니다.

어텐션 구조가 결과를 바꾸는 이유

위 공식을 모든 층에 똑같이 적용하면 2025-2026년에 나온 상당수 모델에서 KV cache를 몇 배에서 수십 배까지 과대 추정합니다. 모델마다 무엇을 얼마나 저장하는지가 다르기 때문입니다.

그래서 계산기의 프리셋은 config에서 전체 어텐션 층 수와 sliding window 층 수, window 크기, MLA 차원, 선형 층 수를 따로 읽어 둡니다. 직접 입력할 때도 모델 구조값의 어텐션 유형을 맞게 골라야 결과가 의미를 가집니다.

Gemma 4의 global 층은 K와 V가 같은 값을 쓰는 구조입니다. 엔진이 이를 한 번만 저장하는지는 확인하지 못해 기본값은 K·V를 각각 계산하는 보수적인 값이고, “K=V 공유 층을 한 번만 저장”을 켜면 그 층의 KV cache가 절반이 됩니다. Qwen3.5 이후 모델의 선형 층 상태도 FP32로 가정한 값이며 엔진별 실측은 확인하지 못했습니다.

GiB와 GB를 섞지 않는 이유

계산기는 모든 비교를 GiB(2^30바이트)로 합니다. GPU 제조사의 표기 용량은 10진 GB(10^9바이트)로 보고 GiB로 바꿔 비교합니다. 제조사 페이지가 표기 단위를 명시하지 않아, 더 작게 나오는 쪽으로 잡은 것입니다.

80 GB GPU에 “70 GB짜리 모델”이 들어간다고 볼 때 70 GB가 10진 단위라면 65.19 GiB이고, 2진 단위라면 70 GiB입니다. 단위를 섞으면 이 정도 차이가 판정을 바꿉니다.

판정 3단계가 뜻하는 것

판정은 최소 요구량과 권장 요구량을 가용 메모리와 비교해 정합니다.

기본 여유율 10%와 고정 여유 0.5 GiB는 gpt-oss 모델 카드의 두 진술(“single 80GB GPU”, “within 16GB”)과 모순되지 않는 값으로 정했습니다. 더 보수적으로 잡고 싶다면 여유율을 20%, 고정 여유를 1 GiB까지 올릴 수 있습니다. 20%는 Hugging Face Accelerate 문서가 추론 시 “up to an additional 20%”를 예상하라고 한 값이고, 1 GiB는 llama.cpp --fit-target의 기본값(1024 MiB)입니다.

“빠듯함”이나 “부족”이 나왔을 때 VRAM 요구량을 줄이는 방법은 대체로 다음 순서로 검토합니다.

1. 컨텍스트 길이와 동시 시퀀스 수를 실제로 필요한 만큼으로 줄인다.
2. KV cache를 FP8이나 q8_0으로 양자화한다.
3. 가중치를 더 낮은 bpw 포맷으로 바꾼다.
4. MoE라면 전문가 가중치 일부를 CPU 메모리로 오프로딩(offloading)한다(계산기에는 반영되지 않음).
5. GPU를 늘리거나 더 큰 GPU로 바꾼다.

실제 사례로 보는 LLM VRAM 판정

아래 수치는 모두 계산기에 같은 조건을 넣었을 때의 결과입니다. 여유율 10%, 고정 여유 0.5 GiB, BF16 KV cache, 시퀀스 1개 기준입니다.

Llama 3.1 8B Q4_K_M: 8GB GPU에서는 컨텍스트가 관건

단위는 GiB입니다. 가중치는 그대로인데 컨텍스트만 늘려도 8 GB GPU에서 판정이 “여유 있음”에서 “부족”으로 바뀝니다. 128K를 쓰려면 24 GB GPU에서도 여유가 부족합니다. 8 GB GPU에 8B 모델이 “들어간다”는 말은 컨텍스트 조건을 함께 말해야 맞는 문장입니다.

gpt-oss-20b·120b: 모델 카드의 문장과 대조

gpt-oss 두 모델은 MoE 가중치를 MXFP4로, 나머지를 BF16으로 배포합니다. 계산기는 이 혼합 형식을 bpw로 근사하지 않고 배포 파일의 실측 크기(20b 13.76 GB, 120b 65.25 GB)를 그대로 씁니다.

OpenAI 모델 카드는 gpt-oss-120b가 “single 80GB GPU”에서, gpt-oss-20b가 “within 16GB of memory”에서 실행된다고 설명합니다. 120b는 최대 컨텍스트 128K에서도 80 GB GPU에 여유 있게 들어가므로 카드와 맞습니다. 20b는 8K에서는 맞지만, 128K까지 늘리면 가중치와 KV cache만으로 16 GB를 넘습니다. 카드가 컨텍스트 조건을 밝히지 않았으므로 모순은 아닙니다. 다만 이 계산기의 가정, 즉 BF16 KV cache로 모두 GPU에 올리는 조건에서는 16 GB로 128K를 쓰기 어렵다는 뜻입니다. 실제로 쓸 수 있는 컨텍스트는 KV cache 정밀도와 엔진의 메모리 할당 방식에 따라 달라집니다. KV cache를 q8_0으로 낮추면 128K에서도 “부족”이 “빠듯함”으로 올라오고, 최소 요구량(14.41 GiB)은 가용 메모리 안에 들어옵니다.

gpt-oss는 층의 절반이 window 128토큰의 sliding window 층이라, 128K에서도 sliding 층 KV cache는 20b 3 MiB, 120b 4.5 MiB에 그칩니다.

Llama 3.3 70B: 4bit라는 말만으로는 판정할 수 없다

같은 “4bit”라도 이론 INT4로 계산하면 24 GB GPU 두 장에 여유 있게 들어가는 것처럼 보이지만, 실제로 많이 쓰는 Q4_K_M은 8K에서도 빠듯합니다. Q4_K_M 가중치 40.20 GiB(43.16 GB)는 llama.cpp가 Llama 3.1 70B Q4_K_M에 대해 공개한 43.1 GB와 맞습니다. GPU 두 장은 메모리를 합쳐 비교한 값이며, 실제로 두 장에 나눠 싣는 효율은 아래 한계 절의 조건을 따릅니다.

이 계산기가 보여 주지 않는 것

계산기의 최소 요구량은 가중치와 KV cache(와 선형 상태)만 합한 값입니다. 실제 실행에서는 아래 요인이 더해지거나 계산 방식이 달라집니다.

멀티 GPU 합산은 한 장비 안에서 tensor parallel로 모델을 나눠 싣는 경우를 가정합니다. 여러 PC를 네트워크로 연결한다고 메모리가 자동으로 합쳐지지는 않습니다. 이 차이는 NVIDIA PAIR가 여러 PC를 묶는 방식을 다룬 글에서 자세히 설명합니다.

실제 사용량은 vLLM 기동 로그에 찍히는 KV cache 용량, llama.cpp 기동 로그의 KV 버퍼 크기, nvidia-smi로 확인할 수 있습니다. 계산기 결과와 다르면 위 표에서 어느 항목이 차이를 만들었는지부터 보면 됩니다.

함께 읽으면 좋은 글

• MoE가 왜 전체 전문가 가중치를 메모리에 올려야 하는지, 작은 모델과 큰 모델의 차이는 sLLM과 LLM의 차이를 정리한 글에 있습니다. 그 글의 메모리 표는 INT4를 파라미터당 0.5바이트로 본 이론값이라, 이 계산기의 “이론 INT4″와 같은 기준입니다. Q4_K_M처럼 실제 포맷으로 계산하면 그보다 커집니다.
• KV cache가 추론 속도 최적화에서 어떤 역할을 하는지는 Speculative Decoding의 원리와 조건에서 다룹니다. 초안 모델을 따로 띄우면 그 가중치와 KV cache도 VRAM에 더해집니다.

확인일과 출처

모델 구조값, 양자화 bpw, GPU 메모리, 엔진 옵션은 모두 2026년 10월 20일에 확인했습니다. 모델 카드와 config는 저장소에서 갱신될 수 있습니다.

• 양자화 bpw 실측표, 블록 구조, KV cache 양자화·sliding window·오프로딩 옵션: llama.cpp quantize README, ggml-common.h, llama.cpp server README, llama-kv-cache-iswa.cpp
• vLLM 메모리 사전 할당·KV cache dtype·hybrid KV cache: Engine Arguments, Quantized KV Cache, Hybrid KV Cache Manager, Conserving Memory
• 추론 여유 20%: Hugging Face Accelerate model size estimator
• MLA 캐시 대상: DeepSeek-V3 Technical Report
• 모델 구조값과 카드: Meta llama-models, Qwen3-8B, Qwen3-30B-A3B, Qwen3.8-27B, Gemma 3 27B, Gemma 4 31B, gpt-oss-20b, gpt-oss-120b, DeepSeek-V3, Mistral Small 3.2, Qwen3-14B-AWQ
• GPU 메모리: NVIDIA GeForce 비교, A100, H100, H200, DGX B200, RTX PRO 6000, DGX Spark, Apple Mac Studio