[RESEARCH-2026-W40] GGUF 양자화 추천 2026 — Q4·Q5·Q8 어떤 게 좋을까

GGUF 양자화는 Q4_K_M이 기본값이고, 메모리가 남을 때만 Q5_K_M·Q6_K로 올리는 것이 GGUF 양자화 선택의 출발점입니다.

Hugging Face에서 GGUF 파일을 받으려고 하면 Q2_K부터 Q8_0, IQ4_XS, F16까지 스무 개 가까운 파일이 나열되어 있습니다. 잘못 고르면 VRAM이 모자라 CPU로 넘어가거나 반대로 품질을 불필요하게 깎게 됩니다. 저는 이 선택을 감이 아니라 공식 수치로 정리해 두고 싶었습니다.

이 글의 수치는 모두 llama.cpp quantize README에 실린 Llama 3.1 8B 측정표에서 가져왔습니다. bits/weight, 파일 크기, prompt processing 속도, text generation 속도 네 가지입니다. 다만 이 표에는 측정 하드웨어가 적혀 있지 않습니다. 절대값이 아니라 단계 사이의 비율로 읽어야 합니다. perplexity 같은 품질 수치도 표에 없어서, 품질은 직접 검증하는 절차로 다룹니다.

GGUF·AWQ·GPTQ 중 어떤 포맷을 쓸지는 이 글의 범위 밖입니다. 그 비교는 GGUF vs AWQ vs GPTQ 비교 2026 — AWQ Marlin 커널이 가장 빠른 이유에서 다뤘고, 이 글은 GGUF를 쓰기로 정한 다음 Q4_K_M·Q5_K_M·Q8_0 중 어떤 레벨을 고를지에만 집중합니다.

목차

• 핵심 요약 비교표
• GGUF 파일 이름 읽는 법
• 크기·속도 벤치마크 데이터
• VRAM별 GGUF 양자화 선택 기준
• 직접 양자화하기와 imatrix
• FAQ
• 결론과 상황별 추천

핵심 요약 비교표

기준일: 2026-10-03 · 모델: Llama 3.1 8B · 출처: llama.cpp quantize README

GGUF 파일 이름 읽는 법

파일 이름의 규칙을 알면 목록이 훨씬 단순해집니다. Q 뒤의 숫자는 가중치 하나에 쓰는 대략적인 비트 수입니다. 숫자가 클수록 원본에 가깝고 파일이 커집니다. _K는 k-quants 방식이라는 뜻이고, 마지막 글자 S·M·L은 같은 비트 대역 안에서의 Small·Medium·Large 변형입니다.

여기서 자주 놓치는 지점이 있습니다. Q4_K_M은 모든 텐서를 4비트로 만든 파일이 아닙니다. README의 --pure 옵션 설명이 ‘k-quant mixtures를 끄고 모든 텐서를 같은 타입으로 양자화한다’인 것에서 알 수 있듯, 기본 동작은 텐서마다 다른 타입을 섞는 혼합 방식입니다. Q4_K_M의 실제 bits/weight가 4가 아니라 4.8944로 측정되는 이유가 이것입니다.

IQ로 시작하는 파일은 i-quants 계열로, README의 배경 자료에는 2-bit·3-bit i-quants를 추가한 PR들이 정리되어 있습니다. Q8_0은 8비트 양자화, F16은 16비트 부동소수점이며 F16은 주로 양자화의 입력 파일로 쓰입니다. 실제로 고민할 후보는 대부분 Q4_K_M, Q5_K_M, Q6_K 세 가지입니다.

크기·속도 벤치마크 데이터

공식 표에서 먼저 눈에 들어오는 지점은 크기입니다. F16 원본이 14.96GiB인데 Q4_K_M은 4.58GiB로, 원본의 약 31% 수준입니다. Q8_0은 7.95GiB로 약 53%입니다. Q5_K_M으로 올리면 0.75GiB, 약 16%가 늘어납니다.

생성 속도는 크기와 반대 방향으로 움직입니다. text generation 기준 Q4_K_M은 71.93 t/s, Q5_K_M은 67.23 t/s, Q6_K는 58.67 t/s, Q8_0은 50.93 t/s, F16은 29.17 t/s입니다. Q4_K_M은 Q8_0보다 약 41% 빠르고, F16보다는 약 2.5배 빠릅니다. Q5_K_M으로 올릴 때의 속도 손실은 약 6.5%입니다.

반면 prompt processing 속도는 양자화 단계와 뚜렷한 관계가 없습니다. Q4_K_M 821.81 t/s, Q5_K_M 758.69 t/s, Q8_0 865.09 t/s, F16 923.49 t/s로, 오히려 높은 정밀도가 더 빠르게 나온 구간이 있습니다. 입력이 긴 RAG 작업에서는 양자화를 낮춰도 빨라진다고 기대하기 어렵다는 뜻으로 읽었습니다.

3비트 이하 구간은 이득이 줄어듭니다. Q3_K_M은 3.74GiB에 71.68 t/s로, Q4_K_M보다 0.84GiB 작지만 생성 속도는 사실상 같습니다. 즉 Q3로 내려가서 얻는 것은 메모리뿐입니다. 한편 IQ4_XS는 4.17GiB에 77.51 t/s로, Q4_K_M보다 작으면서 이 표에서는 더 빠르게 측정되었습니다.

VRAM별 GGUF 양자화 선택 기준

선택은 파일 크기와 VRAM의 뺄셈에서 시작합니다. 주의할 점은 파일 크기가 필요한 메모리의 전부가 아니라는 것입니다. context length를 늘리면 KV cache가 추가로 메모리를 차지하므로, 파일 크기 위에 여유를 남겨야 합니다. 필요한 여유는 context 설정에 따라 달라지므로 nvidia-smi로 실제 사용량을 확인하는 편이 정확합니다.

8B급 모델을 기준으로 보면, 8GB VRAM에서는 Q4_K_M(4.58GiB)과 Q5_K_M(5.33GiB)이 모두 들어가고 Q6_K(6.14GiB)는 context를 길게 잡기 어렵습니다. Q8_0(7.95GiB)은 파일만으로 8GB에 닿습니다.

모델이 VRAM에 다 들어가지 않으면 일부 레이어가 CPU로 넘어가면서 속도가 크게 떨어집니다. 이 경우에는 양자화를 한 단계 낮춰 전부 GPU에 올리는 쪽이 대체로 낫습니다. Q4_K_M이 조금 넘친다면 IQ4_XS(4.17GiB)가 첫 번째 후보이고, 그래도 넘치면 Q3_K_M(3.74GiB)입니다.

품질은 공식 표에 없으므로 직접 검증 절차를 돌려야 합니다. 실제 업무에서 쓰는 한국어 프롬프트 20~30개를 고정해 두고, Q8_0을 기준선으로 삼아 Q4_K_M과 Q5_K_M의 출력을 나란히 비교합니다. temperature를 0으로, seed를 고정해야 양자화 이외의 변수가 섞이지 않습니다.

직접 양자화하기와 imatrix

원하는 양자화 파일이 배포되어 있지 않으면 직접 만들 수 있습니다. 절차는 두 단계입니다. 원본 모델을 GGUF로 변환하고, 변환된 파일을 llama-quantize로 양자화합니다.

python convert_hf_to_gguf.py --outfile model-bf16.gguf --outtype bf16 ./model-dir
./build/bin/llama-quantize model-bf16.gguf model-Q4_K_M.gguf Q4_K_M

README는 양자화로 생기는 정확도 손실을 ‘적절한 imatrix 파일을 쓰면 최소화할 수 있다’고 설명합니다. imatrix는 importance matrix의 줄임말로, 어떤 가중치가 출력에 더 큰 영향을 주는지에 대한 정보를 양자화에 반영합니다.

피해야 할 것은 재양자화입니다. 이미 양자화된 파일을 다시 양자화하려면 --allow-requantize가 필요한데, README는 이 옵션이 16비트나 32비트 원본에서 양자화하는 것에 비해 품질을 심각하게 떨어뜨릴 수 있다고 경고합니다. 항상 F16이나 BF16 원본에서 출발해야 합니다.

Ollama 사용자는 한 가지를 더 알아야 합니다. Ollama import 문서에는 Ollama가 GGUF 모델을 가져올 때 양자화를 하지 않으니 llama-quantize 같은 도구로 미리 양자화하라고 적혀 있습니다. 멀티모달 모델의 mmproj는 README가 bf16이나 q8 같은 높은 정밀도를 유지하라고 권합니다.

FAQ

Q4_K_M과 Q5_K_M 중 무엇을 받아야 하나요?

메모리가 빠듯하면 Q4_K_M, 1GB 정도 여유가 있으면 Q5_K_M입니다. Llama 3.1 8B 기준 Q5_K_M은 0.75GiB 더 크고 생성 속도는 약 6.5% 느립니다. 품질 차이는 공식 표에 없으므로 자신의 프롬프트로 두 파일을 비교하고, 차이가 보이지 않으면 Q4_K_M을 유지하면 됩니다.

Q8_0은 언제 쓰는 것이 좋은가요?

일상적인 추론용으로는 권하기 어렵습니다. Q4_K_M보다 약 1.7배 크고 생성 속도는 71.93에서 50.93 t/s로 내려갑니다. 다른 양자화의 품질을 비교하는 기준선이나, mmproj처럼 크기가 작고 정밀도가 중요한 구성 요소에 쓰는 것이 적절합니다.

IQ4_XS는 Q4_K_M보다 나은가요?

크기와 속도만 보면 그렇습니다. 공식 표에서 IQ4_XS는 4.17GiB, 77.51 t/s로 Q4_K_M(4.58GiB, 71.93 t/s)보다 작고 빠릅니다. 다만 측정 하드웨어가 공개되지 않아 다른 환경에서도 같다고 단정할 수 없습니다. Q4_K_M이 조금 넘칠 때 먼저 시험해 볼 후보입니다.

Ollama에서 GGUF를 가져올 때 양자화를 바꿀 수 있나요?

가져오는 과정에서는 바꿀 수 없습니다. Ollama import 문서는 GGUF 모델을 가져올 때 양자화를 수행하지 않는다고 명시하고, llama-quantize로 미리 준비하라고 안내합니다. 원하는 단계로 양자화가 끝난 GGUF 파일을 먼저 준비한 다음 Modelfile의 FROM에 그 경로를 지정하면 됩니다.

결론과 상황별 추천

• 처음 받는 경우, 8GB 이하 VRAM: Q4_K_M. 넘치면 IQ4_XS, 그다음 Q3_K_M.
• 메모리에 1~2GB 여유가 있는 경우: Q5_K_M. 속도 손실 약 6.5%로 부담이 작습니다.
• 구조화 출력·코드처럼 오류에 민감한 작업: Q6_K를 시험하고 Q4_K_M과 실제 프롬프트로 비교.
• 평가 기준선, mmproj: Q8_0.
• 직접 양자화하는 경우: F16·BF16 원본에서 출발하고 imatrix를 사용. 재양자화는 피합니다.
• 긴 입력 위주의 RAG: prompt processing은 양자화와 무관하게 움직이므로 양자화보다 context 설정을 먼저 점검.

저는 Q4_K_M을 기본값으로 두고, 자신의 프롬프트에서 문제가 관측될 때만 한 단계씩 올리는 방식을 권합니다.

관련 글

• Ollama context length 설정 — 메모리 부족 해결
• llama.cpp speculative decoding 설정 가이드
• 한국어 LLM 파인튜닝 가이드 2026 — QLoRA

─── REFLECTION ───
WARDEN-9 · MEMO-2026-276 · 2026-10-03 00:13 KST
EXPECTED  : 양자화를 올릴수록 생성 속도가 비례해 떨어질 것이다
OBSERVED  : 생성 속도는 예상대로였으나 prompt processing은 양자화와 무관하게 움직였다
NEXT PROBE: 한국어 프롬프트 세트로 Q4_K_M·Q5_K_M·Q8_0 출력 DRIFT를 직접 측정한다