LLM에 필요한 VRAM을 추정하고 GPU에 들어가는지 확인하세요.
| 양자화 | bpw | 가중치 | 합계 | 들어가나요? |
|---|---|---|---|---|
| FP32 | 32 | 29.92 GiB | 34.91 GiB | 아니요 |
| FP16 | 16 | 14.96 GiB | 18.45 GiB | 예 |
| Q8_0 | 8.5008 | 7.95 GiB | 10.74 GiB | 예 |
| FP8 | 8 | 7.48 GiB | 10.23 GiB | 예 |
| Q6_K | 6.5633 | 6.14 GiB | 8.75 GiB | 예 |
| Q5_K_M | 5.7036 | 5.33 GiB | 7.87 GiB | 예 |
| Q5_K_S | 5.5704 | 5.21 GiB | 7.73 GiB | 예 |
| Q4_K_M | 4.8944 | 4.58 GiB | 7.03 GiB | 예 |
| Q4_K_S | 4.6672 | 4.36 GiB | 6.80 GiB | 예 |
| Q3_K_L | 4.2979 | 4.02 GiB | 6.42 GiB | 예 |
| Q3_K_M | 3.996 | 3.74 GiB | 6.11 GiB | 예 |
| Q3_K_S | 3.6429 | 3.41 GiB | 5.75 GiB | 예 |
| Q2_K | 3.1593 | 2.95 GiB | 5.25 GiB | 예 |
모델 사양은 Hugging Face의 config.json과 safetensors 메타데이터에서 가져왔습니다(2026-10-20 확인). 양자화 bpw 값은 Llama-3.1-8B에서 측정한 llama.cpp 값이며 다른 모델에서는 약간 다릅니다.
모델을 학습하거나 파인튜닝하는 데 필요한 메모리가 아니라 모델을 실행(추론)하는 데 필요한 메모리의 계획용 추정치입니다. 실제 사용량은 엔진(vLLM, llama.cpp, TensorRT-LLM 등), 배칭, CUDA 버전에 따라 다르므로 여유를 두세요.
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요!
LLM VRAM 계산기는 대규모 언어 모델을 로컬 또는 자체 호스팅으로 실행(RUN)하는 데 필요한 메모리를 추정합니다. 합계 ≈ 가중치 + KV 캐시 + 런타임 오버헤드이며, 가중치 = 파라미터 × 가중치당 비트 ÷ 8, KV 캐시 = 2 × 레이어 × KV 헤드 × 헤드 차원 × 요소당 바이트 × 컨텍스트 × 동시 시퀀스입니다. 모델, 양자화, 기기를 고르면 들어가는지, 여유, 들어가는 최대 컨텍스트, 생성 속도 상한을 알려 줍니다.
합계 ≈ 가중치 + KV 캐시 + 런타임 오버헤드. 가중치 = 매개변수 × 가중치당 비트 수 ÷ 8입니다. 예를 들어 80억 매개변수 모델은 FP16(16비트)에서 약 15GiB, Q4_K_M(약 4.9비트)에서 약 4.6GiB가 필요합니다. KV 캐시는 컨텍스트 길이와 동시 시퀀스 수에 따라 커지므로 둘 다 설정하세요.
처리한 토큰마다 모델은 생성하는 동안 다시 계산하지 않도록 각 레이어의 Key와 Value를 저장합니다. 크기 = 2 × 레이어 수 × KV 헤드 수 × 헤드 차원 × 요소당 바이트 × 컨텍스트 길이 × 시퀀스 수이므로 컨텍스트 길이에 비례합니다. 그룹 쿼리 어텐션(KV 헤드 수가 적음)이나 슬라이딩 윈도를 쓰는 모델은 훨씬 적게 필요합니다.
비트 수가 적을수록 가중치가 작아지고 보통 더 빨라지지만 품질을 희생합니다. Q8_0은 원본에 가깝고, Q5_K_M과 Q6_K는 흔한 절충안이며, 메모리가 빠듯할 때는 보통 Q4_K_M에서 시작하고, Q3 아래에서는 품질 저하가 눈에 띕니다. 표에서 각 수준이 현재 설정에 들어가는지 확인할 수 있습니다.
모든 전문가를 불러와야 하므로 가중치는 토큰마다 활성화되는 매개변수가 아니라 전체 매개변수를 씁니다. 반면 생성 속도는 활성 매개변수에 좌우되므로 MoE 모델은 메모리를 많이 쓰면서도 특별히 느리지는 않은 경우가 많습니다.
보통은 아닙니다. 기본적으로 시스템은 GPU가 통합 메모리의 일부(대략 3분의 2에서 4분의 3)만 쓰게 하므로 “Apple 통합 메모리”를 고르면 75%를 사용 가능으로 봅니다. 실제 설정에 맞추려면 “사용 가능 비율 직접 지정”을 고르세요.
가중치와 KV 캐시는 카드 사이에 균등하게 나뉘고 각 카드가 고정 런타임 오버헤드를 따로 부담한다고 가정하므로 합계가 카드 한 장일 때보다 조금 높습니다. 실제 분할(텐서 또는 파이프라인 병렬)과 통신 오버헤드는 엔진에 따라 달라지므로 여유를 두세요.
추론(INFERENCE) 전용 계획용 추정치입니다: 가중치, KV 캐시, 조정 가능한 오버헤드. 실제 사용량은 엔진(vLLM, llama.cpp 등), 배칭, CUDA 버전, 페이지드 KV 설정에 따라 달라집니다. 학습과 파인튜닝은 훨씬 많은 메모리(그래디언트, 옵티마이저 상태, 활성값)가 필요하며 이 도구의 범위 밖입니다.
토큰 하나를 생성할 때마다 활성 가중치를 한 번 읽으므로 배치 크기 1에서의 상한은 대략 “메모리 대역폭 ÷ 토큰당 읽는 가중치 바이트”입니다. 연산 한계, KV 캐시 읽기, 소프트웨어 오버헤드를 무시한 이론상 한계이므로 실제 속도는 보통 더 낮습니다. 기기의 대역폭을 입력한 뒤에만 표시됩니다.
