GGUF VRAM 계산기: 다운로드 전에 확인하세요

원래 mrsaynothing.dev에 게시되었습니다. GGUF VRAM 계산기 자체는 오픈 소스이며, 빌드 과정 없이 HTML 파일 하나로 구성되어 있습니다.

ggml_backend_cuda_buffer_type_alloc_buffer: failed to allocate 3412 MiB. 파일을 다운로드하는 데는 문제가 없었습니다. 하지만 해당 카드는 이 모델을 감당할 수 없었고, 이를 예측한 계산은 영수증 여백에 들어갈 정도였습니다. 일반적인 작업 흐름은 역순입니다. 즉, 다운로드를 실행하고 진행 표시줄을 지켜보며, 메모리 부족 오류가 계산하게 두는 방식이죠. 오늘날의 이 도구는 그러한 순서를 거부합니다. GGUF VRAM 계산기가 공개되었습니다: 모델 크기, 양자화(quantization), 컨텍스트를 입력하면 가중치(weights), KV 캐시(KV cache)와 모든 일반 카드에 대한 판정 결과를 얻을 수 있습니다. 또는 사용자의 VRAM 예산부터 가장 적합한 양자화까지 역으로 실행할 수도 있습니다. 이 도구는 브라우저 내에서 완전히 작동하며, 어떠한 데이터도 업로드하지 않으며, 로컬 LLM 실행 클러스드에 참여합니다.

이 도구는 질문의 형태가 두 가지이기 때문에 두 가지 모드를 가지고 있습니다:

• "이 모델은 얼마나 많은 VRAM이 필요할까요?" — 파라미터, 양자화, 컨텍스트, 아키텍처를 입력하면 분석 결과와 카드별 판정표(6GB부터 96GB까지)가 출력됩니다.
• "내 VRAM에 무엇이 들어갈 수 있을까요?" — 예산(VRAM), 모델 크기, 컨텍스트를 입력하면 Q2_K부터 F16까지 모든 양자화별 판정 결과가 출력됩니다.

GGUF 모델은 얼마나 많은 VRAM이 필요할까요?

항상 같은 세 가지 부분이 있습니다:

VRAM ≈ weights + KV cache + overhead
weights  = params × bits-per-weight / 8
KV cache = 2 × layers × kv_dim × context × 2 bytes   (f16)
...

가장 흔한 작업 예시: 32k 컨텍스트를 가진 Q4_K_M으로 양자화된 8B 모델을 사용한다고 가정해 봅시다. 가중치(Weights): 8 × 4.85 / 8 = 4.85 GB. KV 캐시(KV cache): 2 × 32 레이어 × 1024 kv-dim × 2 바이트 = 토큰당 128 KB × 32,768 = 4.0 GB. 오버헤드까지 포함하면: 총 약 9.8 GB가 필요합니다. 이 때문에 "Q4 8B"라는 모델은 모두가 8GB 카드에 맞는다고 생각하지만, 긴 컨텍스트를 제공하는 순간 8GB 카드의 용량을 23% 초과하게 됩니다. 문제는 양자화(quant) 자체가 아니었고, 컨텍스트 길이였습니다. 이러한 실패 모드는 자체 필드 노트를 가지고 있는데, 이는 오프로드(offload)할 때 시스템 RAM도 소모하기 때문입니다.

어떤 GGUF 양자화가 내 카드에 적합한가?

'Mode 2'는 사람들이 실제로 가진 역방향 질문, 즉 고정된 메모리 용량과 염두에 둔 모델을 가지고 있을 때 존재합니다. 8GB 예산으로 4096 컨텍스트를 가진 7B 모델을 돌릴 경우 정확히 다음과 같은 결과를 얻게 됩니다:

단 하나의 화면만으로, 오랫동안 논의되던 "Q4 대 Q8"이라는 포럼 토론은 다른 사람의 의견이 아닌 사용자의 하드웨어 사양에 맞춰 무너집니다.

수치가 나오는 출처

Bits-per-weight(bpw) 표는 llama.cpp의 ggml 양자화 형식에서 가져온 것입니다. 이는 Hugging Face의 파일들이 구축되는 것과 동일한 수치입니다:

KV 캐시 절반은 각 계열의 공개된 기하학(geometry)을 사용합니다. 여기서 핵심은 그룹화된-쿼리 어텐션(Grouped-query attention, GQA)입니다. Llama-3급 8B 모델은 8개의 KV 헤드 × 128 차원 × 32 레이어를 유지하며 토큰당 128 KB를 사용합니다. 반면, GQA가 없는 구형의 명목상 작은 시대의 모델인 Llama 2 13B는 토큰당 640 KB를 소모하여 다섯 배나 더 많은 메모리를 사용합니다. 아키텍처 드롭다운 메뉴에는 네 가지 일반적인 형태와 config.json에서 읽을 수 있는 모든 것을 위한 사용자 정의 모드가 포함되어 있습니다.

파일 크기는 다운로드할 용량을 알려줄 뿐입니다. 실제로 구동할 수 있는 용량은 절대 알려주지 않습니다.

세 가지 이유가 있습니다. 의도적으로요. Mixture-of-experts 라우팅(MoE)의 경우 추론 시 활성화된 전문가들만 사용되지만, 이 도구는 전체 가중치 세트를 가격 책정하므로 MoE 총합이 높게 나옵니다. 혼합 양자화(Mixed quantization)의 경우 Q4_K_M 자체가 텐서에 대한 평균값이기 때문에 실제 파일 크기는 표에 나와 있는 값보다 몇 퍼센트 낮을 수 있습니다. 그리고 CUDA 측 패딩은 백엔드 버전에 따라 다르므로, 제시된 0.7 GB라는 값은 중간 정도의 수치일 뿐 자연의 상수(constant of nature)가 아닙니다. 만약 결정해야 할 크기가 수백 메가바이트 이상이라면, 추정치는 건너뛰고 llama.cpp의 gguf_dump.py를 사용하여 파일 헤더를 읽으세요. 헤더 리딩 계산기는 정확히 이 역할을 합니다. 이 도구는 의도적으로 산술적인 방식을 유지합니다. 손으로 다시 유추할 수 있는 세 가지 입력값과, 논쟁할 여지가 있는 하나의 결론이 있기 때문입니다.

이 도구는 github.com/mrsaynothing/gguf-vram-calculator에 있습니다. 의존성이나 빌드 단계가 필요 없는 단일 HTML 파일입니다. 이 도구는 로컬 GGUF 가이드, llama.cpp 대 Ollama, 최고의 로컬 LLM 추천 목록와 함께 제공되며, 서빙 측면의 대응물은 can vLLM run GGUF에서 확인할 수 있습니다.

만약 이 결론이 실제 로드 시간과 다르다면, 모델, 양자화(quant), 컨텍스트를 명시하여 저장소 이슈를 열어주세요. 이 표는 실제 하드웨어와 접촉하는 과정에서도 살아남아야 하며, 그렇지 않은 부분은 수정해야 할 항목입니다.