GGUF 양자화 가이드 2026: Q4_K_M vs Q5_K_M vs Q8_0

이 기사는 원래 aifoss.dev에 게시되었습니다.

title: 'GGUF 양자화 가이드 2026: Q4_K_M vs Q5_K_M vs Q8_0'
description: 'Q4_K_M, Q5_K_M, Q8_0 GGUF 양자화(quantization) 사이의 정확한 트레이드오프(tradeoffs): 2026년 기준 7B에서 70B 모델에 대한 퍼플렉시티(perplexity) 비용, VRAM 요구 사항 및 추론(inference) 속도.'
pubDate: '2026년 5월 23일'

tags: ["quantization", "ai", "llm", "gpu", "opensource"]

Q4_K_M vs Q5_K_M vs Q8_0 결정은 새로운 모델을 가져올 때마다 내리는 첫 번째 결정입니다. 대부분의 가이드는 이를 "대부분의 사람들에게는 Q4가 적당하다"로 축약하곤 합니다. 그것은 사실입니다. 하지만 그것이 전부는 아닙니다.

다음은 실제 수치를 바탕으로 한 분석입니다: 파일 크기, VRAM 예산, FP16 대비 퍼플렉시티(perplexity) 차이, 그리고 생성 속도 — 이 모든 데이터는 llama.cpp 공식 문서와 검증된 벤치마크(benchmarks)를 바탕으로 합니다. 이 글을 다 읽을 때쯤이면, 여러분은 주의 사항이 가득한 표 대신 30초 안에 적용할 수 있는 하드웨어별 결정 규칙을 갖게 될 것입니다.

양자화(quantization)가 하는 일

전정밀도(full-precision) 언어 모델은 각 가중치(weight)를 16비트 부동 소수점(floating-point) 숫자로 저장합니다. FP16 상태의 8B 파라미터 모델은 14.96 GiB의 저장 공간을 차지하며 VRAM에서도 거의 동일한 용량이 필요합니다. 이는 대부분의 소비자용 GPU로는 감당하기 어려운 수준입니다. 양자화(quantization)는 이러한 가중치들을 표현 가능한 더 작은 값의 집합으로 매핑하여 압축합니다. 4비트로 양자화된 8B 모델은 4.58 GiB에 들어갑니다.

이 압축은 손실(lossy)이 발생합니다. 가중치를 더 적은 비트로 반올림하면 노이즈(noise)가 발생합니다. 문제는 그 노이즈가 얼마나 큰지, 그리고 여러분의 특정 워크로드(workload)에 영향을 미치는지 여부입니다. 짧게 답변하자면, Q4와 Q8 사이의 품질 격차는 대부분의 사용자가 채팅에서 인지하지 못할 정도로 작습니다. 문제가 눈에 띄게 발생하는 지점은 Q3와 Q4 사이입니다. 대부분의 양자화 가이드는 잘못된 임계점(cliff)을 걱정하고 있습니다.

GGUF와 세 가지 양자화 제품군

GGUF (GPT-Generated Unified Format)는 llama.cpp (MIT 라이선스, GitHub 별 112k 개, 2026년 5월 23일 기준 빌드 b9297), Ollama, LM Studio 및 거의 모든 다른 로컬 추론 도구에서 사용되는 파일 형식입니다. 이는 이전의 GGML 형식을 대체했으며, 현재 양자화된 오픈 소스 모델을 위한 범용 컨테이너로 자리 잡았습니다.

GGUF 내에는 세 가지 양자화 제품군이 존재합니다:

레거시 양자화 (Legacy quants: Q4_0, Q4_1, Q5_0, Q5_1, Q8_0) — 오리지널 방식입니다. 8비트에서는 레거시 Q8_0 형식이 여전히 우수하며 널리 사용됩니다. 하지만 더 낮은 비트 깊이에서는 레거시 형식이 동일한 비트 수의 K-quants에 비해 성능이 크게 뒤처집니다.

K-quants (Q2_K부터 Q6_K까지) — 4~6비트 압축의 현재 표준입니다. 이 방식은 슈퍼 블록 (super-block) 구조를 사용합니다. 256개의 가중치(weights)를 하나로 그룹화하고, 블록당 스케일(per-block scales) 자체를 다시 양자화하여 동일한 평균 비트 깊이에서 상당한 품질을 회복합니다. 접미사는 혼합 정밀도 (mixed-precision)의 공격성을 나타냅니다: _S (small/공격적), _M (medium/균형 잡힌), _L (large/보수적). 대부분의 사용 사례에서는 _M 변형이 권장되는 기본값입니다.

IQ quants (IQ1_S부터 IQ4_XS까지) — 중요도 행렬 (importance-matrix) 기반 양자화입니다. 이 방식은 모델의 동작에 어떤 가중치가 가장 중요한지를 기록한 보정 데이터(calibration data)에서 유도된 룩업 테이블 (lookup tables)을 사용합니다. 가장 낮은 비트 수준에서 K-quants보다 비트당 더 나은 품질을 제공하지만, 올바르게 작동하려면 imatrix 보정 파일이 필요합니다. imatrix가 없으면 IQ 양자화 출력은 동일한 K-quant보다 눈에 띄게 품질이 떨어집니다.

대부분의 결정 상황에서 핵심적인 질문은 다음과 같습니다: Q4_K_M, Q5_K_M, 아니면 Q8_0인가?

Q4_K_M: 이유 있는 기본값

Q4_K_M은 가중치당 평균 4.89비트입니다. Llama 3.1 8B 모델의 경우, 파일 크기는 4.58 GiB입니다. VRAM에서는 컨텍스트 버퍼 (context buffers)와 메타데이터 (metadata)를 위해 약 10~~20%의 오버헤드를 추가해야 합니다. 즉, 적당한 컨텍스트 창 (context window)을 사용하는 8B 모델의 경우 5.5~~6 GB의 예산을 잡아야 합니다.

내부 구조는 혼합 정밀도 (mixed-precision) 방식을 사용합니다. Q4_K_M은 어텐션 값 투영 (attention value-projection) 및 피드포워드 출력 텐서 (feed-forward output tensors)의 절반(양자화 노이즈에 가장 민감한 레이어들)에는 Q6_K를 사용하고, 그 외의 모든 부분에는 Q4_K를 사용합니다. 이러한 선택적 고정밀도 방식 덕분에 K-quants는 본질적으로 동일한 파일 크기에서 기존의 Q4_0보다 뛰어난 성능을 보여줍니다.

품질 (Quality): Llama 3.1 8B 모델 기준, FP16 대비 퍼플렉시티 (Perplexity) 증가량은 약 +0.18입니다. 절대적인 수치로 보면 이는 매우 작으며, 전체 정밀도 (full-precision) 기준선에서 약 3%의 성능 저하에 불과합니다. 일반적인 채팅, 요약, 문서 질의응답 (Q&A) 작업의 경우, 대부분의 사용자에게 Q4_K_M의 출력은 FP16과 구분이 불가능한 수준입니다.

속도 (Speed): Q4_K_M은 8B 모델에서 초당 약 71.9 토큰 (tokens/second)을 생성하며, 프롬프트 처리 (prefill) 속도는 초당 약 821 토큰입니다. 이 수치는 llama.cpp 양자화 README에서 가져온 것이며, 단일 GPU 소비자용 하드웨어의 성능을 반영합니다.

Ollama는 자체 레지스트리에 있는 대부분의 모델에 대해 Q4_K_M을 기본값으로 설정합니다. ollama pull llama3.2를 실행하면 별도로 지정하지 않는 한 Q4_K_M을 받게 됩니다. 이러한 기본 설정은 의도적인 것입니다. 6 GB의 VRAM에서 실행 가능하며, 거의 모든 일반적인 사용 워크로드를 만족하는 출력을 생성하고, 대화형 사용 시 반응 속도가 느껴질 만큼 충분히 빠르게 생성하기 때문입니다.

Q5_K_M: VRAM 값을 하는 업그레이드

Q5_K_M은 가중치당 5.70 비트 (bits per weight)를 사용합니다. 동일한 8B 모델은 5.33 GiB 파일이 되며, 이는 Q4_K_M보다 16% 더 큽니다. 8B 모델의 VRAM 요구 사항은 약 6.5 GB입니다.

품질 향상은 분명히 존재하지만, 퍼플렉시티 벤치마크상으로는 완만합니다. Q4_K_M의 +0.18 대비 FP16 대비 +0.06으로, 16%의 메모리를 더 사용하는 대신 양자화 노이즈를 66% 줄인 셈입니다. 이것이 중요한지 여부는 전적으로 작업의 성격에 달려 있습니다.

Q4→Q5 업그레이드가 비용을 정당화하는 경우: 코딩(coding) 및 구조적 추론(structured reasoning)입니다. 4비트(4 bits)에서는 누적된 가중치 노이즈(weight noise)가 변수 이름을 가끔 손상시키거나, 논리 체인에서 예외 조건(edge conditions)을 건너뛰거나, 미묘하게 잘못된 형식의 JSON 출력을 생성하기에 충분합니다. 이러한 성능 저하는 치명적이지는 않지만, 양자화(quantization) 때문이라기보다 모델 자체의 능력 부족으로 돌릴 법한 종류의 오류입니다. 5비트(5 bits)에서는 이러한 종류의 오류가 대부분 사라집니다. 코딩 어시스턴트를 실행하거나 파이프라인 내에서 구조화된 데이터 추출(structured data extraction)을 위해 모델을 사용하는 경우, Q5_K_M은 Q4_K_M에 비해 의미 있는 업그레이드입니다.

중요하지 않은 경우: 채팅(chat), 요약(summarization), 번역(translation), 창의적 글쓰기(creative writing)입니다. 이러한 워크로드(workloads)에서는 Q4→Q5의 차이가 출력 품질에서 체감되지 않습니다.

속도: Q5_K_M은 8B 모델에서 초당 약 67.2 토큰(tokens/second)으로 생성하며, 이는 생성 속도 면에서 Q4_K_M보다 약 7% 느립니다. 프롬프트 처리(Prompt processing) 속도는 초당 약 758 토큰으로 떨어집니다.

Q8_0: 이해할 가치가 있는 속도 트레이드오프를 동반한 무손실에 가까운 포맷

Q8_0는 기존의 8비트(8-bit) 포맷입니다. 가중치당 평균 8.50비트를 사용하며, 8B 모델의 경우 7.95 GiB 파일이 생성됩니다. 이는 Q4_K_M VRAM의 대략 2배에 달합니다. 일반적인 컨텍스트 길이(context lengths)에서 8B 모델을 구동하려면 9~10 GB의 VRAM을 확보하십시오.

FP16 대비 품질 차이는 퍼플렉시티(perplexity)가 약 +0.01 수준으로, 사실상 무손실(lossless)입니다. 어떤 작업 유형에서도 모델을 전체 정밀도(full precision)로 실행할 때와 비교하여 의미 있는 저하가 나타나지 않습니다. 레퍼런스 품질의 기준점(reference-quality baseline)이 필요할 때 사용하는 포맷입니다.

직관에 반하는 속도 프로필: Q8_0는 초당 약 50.9 토큰으로 생성하며, 이는 토큰 생성 시 Q4_K_M보다 29% 느립니다. 대화형 사용(interactive use) 측면에서는 상당한 페널티입니다. 하지만 프롬프트 처리 속도는 초당 약 865 토큰으로, Q4_K_M의 821 토큰보다 빠릅니다.

이것은 역설이 아닙니다. 프롬프트 처리 (prefill)는 연산 제한 (compute-bound) 방식입니다. 즉, 모든 입력 토큰은 GPU에서 대규모 병렬 행렬 연산을 통해 처리되며, 최신 텐서 코어 (tensor cores)는 8비트 정밀도에서 효율적으로 작동하는 고도로 최적화된 INT8 경로를 갖추고 있습니다. 반면 토큰 생성 (decode)은 메모리 대역폭 제한 (memory-bandwidth-bound) 방식입니다. 새로운 토큰을 생성할 때마다 VRAM에서 모델의 모든 가중치를 한 번씩 읽어와야 합니다. 매개변수당 8바이트를 메모리 버스를 통해 이동시키는 것은 4.9바이트를 이동시키는 것보다 비례적으로 더 오래 걸립니다. 생성되는 토큰당 GPU가 더 많은 데이터를 옮겨야 할수록, 연산 처리량 (computational throughput)과 관계없이 생성 속도는 느려집니다.

실질적인 시사점: 만약 당신의 작업 부하가 문서 수집 (document ingestion), RAG 검색 (RAG retrieval), 또는 긴 문맥 요약 (long-context summarization) (많은 프롬프트 토큰, 적은 생성 토큰)이라면, Q8_0은 속도 측면에서 거의 비용이 들지 않으면서 손실 없는 품질을 제공합니다. 만약 대화형 채팅 문맥에서 긴 응답을 생성하고 있다면, 29%의 생성 속도 저하를 체감하게 될 것입니다.

Q8_0의 또 다른 위험 요소: VRAM 포화 (VRAM crowding). 7B Q8_0 모델은 8GB 그래픽 카드에 들어갈 수 있지만, 문맥 (context)을 위한 여유 공간이 거의 남지 않습니다. 동일한 카드에서 Q4_K_M을 사용하면 13B 모델을 여유 공간을 남겨둔 채 실행할 수 있으며, 13B Q4_K_M은 출력 성능 면에서 거의 항상 7B Q8_0보다 뛰어난 성능을 보여줍니다.