양자화 (Quantization)
오픈웨이트 모델을 직접 GPU 에 올려 돌릴 때만 여는 문서. GGUF·AWQ·GPTQ·FP8 중 뭘 고르고, 이 모델이 내 VRAM 에 들어가는지 계산할 때.
먼저: 이건 셀프호스트 전용 주제다
Claude·GPT 같은 API 모델은 프로바이더가 서버에서 서빙한다. 내가 양자화할 일도, 양자화 포맷을 고를 일도 없다. API 를 쓰는 한 이 문서는 통째로 무관하다. 양자화가 의미 있는 경우는 오직 open-weight-models 를 내 GPU(또는 로컬 맥)에 직접 얹을 때다.
양자화 = 모델 가중치를 FP16(16bit) 에서 8bit·4bit 등 저정밀도로 압축해 VRAM 과 대역폭을 줄이는 것. 대가는 약간의 품질 저하다.
포맷별 차이와 용도
| 포맷 | 정체 | 특징 | 주 용도 |
|---|---|---|---|
| GGUF | 파일 포맷(양자화 알고리즘 아님) | Q2_K~Q8_0 레벨, CPU+GPU 하이브리드 추론 | llama.cpp / Ollama / LM Studio — 로컬 실험 기본 |
| AWQ | Activation-aware Weight Quant | 큰 activation("salient") 가중치 보호, 캘리브레이션셋 128~512 샘플 필요 | vLLM 프로덕션 배포 |
| GPTQ | 2차 정보(Hessian)로 오차 보상 | column 단위, group size 보통 128. AWQ 보다 품질 약간 높으나 양자화 자체가 느림 | vLLM 배포 (AWQ 대안) |
| FP8 | 8bit 부동소수 | H100 이상 지원, FP16 대비 거의 동품질 + 메모리 50%↓ | 신형 GPU 서빙 |
| BitsandBytes | 로딩 시 on-the-fly 양자화(사전 양자화 불필요) | NF4/FP4, perplexity 보존 최고. 8bit 는 vLLM 지원 제한적 | 빠른 프로토타이핑 |
| Marlin | 양자화 아님, CUDA 커널 | 기존 GPTQ/AWQ 모델에 얹어 속도만 올림 | vLLM 추론 가속 |
핵심 함정: GGUF 와 Marlin 은 "포맷"이 아니다. GGUF 는 파일 컨테이너고, Marlin 은 커널이다. AWQ/GPTQ/FP8/BitsandBytes 가 실제 양자화 알고리즘이다.
비트수 vs 품질 트레이드오프 감각
jarvislabs 의 Qwen2.5-32B 실측 기준(구체 점수는 관례상 생략)으로, 4bit 기법 대부분이 baseline 대비 품질 저하 한 자릿수 % 이내였다 — 4bit 은 실용적이다 (verified 2026-07). 대략적 서열:
- 품질 보존순 (perplexity): BitsandBytes 4bit ≳ GGUF Q4_K_M ≳ AWQ 4bit ≳ GPTQ 4bit.
- 코딩 태스크에서는 GPTQ 계열 저하가 유독 두드러진다. 코드 생성이 중요하면 GPTQ 를 피하고 AWQ/GGUF 쪽으로.
- GGUF 레벨 감각: Q5_K_M·Q6_K 는 near-BF16(체감 무손실), Q4_K_M 이 로컬 기본 추천, Q2_K 는 눈에 띄는 저하.
"커널이 알고리즘보다 중요" — Marlin 커널을 얹으면 같은 GPTQ/AWQ 모델이 몇 배 빨라진다(GPTQ 약 2.6배·AWQ 약 10.9배). 반대로 Marlin 없는 AWQ 나 vLLM 위의 GGUF 는 매우 느리다. GGUF 는 애초에 llama.cpp 용으로 설계된 포맷이라 vLLM 에선 제 성능이 안 난다 (verified 2026-07).
VRAM 계산법
가중치 VRAM 의 뼈대 공식:
weight VRAM(GB) ≈ 파라미터수(B) × 비트수 / 8
비트수만 넣으면 된다. 예: 8B 모델이면 FP16 은 8 × 16 / 8 = 16GB, 4bit 은 8 × 4 / 8 = 4GB.
bytes/param 로 외워도 된다: FP16 = 2, FP8/INT8 = 1, 4bit ≈ 0.5.
| 8.2B 모델 예시 | 대략 가중치 VRAM |
|---|---|
| FP16 | ≈16GB |
| FP8 | ≈8GB |
| AWQ·GPTQ Int4 | ≈6GB |
| GGUF Q4_K_M | ≈5GB |
여기에 KV 캐시 + activation 오버헤드가 별도로 붙는다. KV 캐시는 컨텍스트 길이·배치·레이어 수에 비례해 커지므로, 긴 컨텍스트로 돌릴 계획이면 가중치 VRAM 위에 넉넉한 여유를 둬야 한다(tokens-and-context-windows 참고). 32B 모델은 FP16 이면 60GB 를 넘겨 단일 소비자 GPU 로는 불가능하고, 4bit 으로 내려야 겨우 손에 잡힌다.
언제 양자화 대신 다른 선택을 하나
| 상황 | 나은 선택 |
|---|---|
| 그냥 품질 좋은 답이 필요, 인프라 관리 하기 싫음 | API 모델 — 양자화 고민 자체가 사라진다 |
| 4bit 로도 VRAM 이 빠듯 / 품질 저하가 거슬림 | 애초에 더 작은 파라미터의 모델(예: 32B→14B)을 FP16 로. 큰 모델을 저비트로 뭉개는 것보다 나은 경우가 많다 |
| 데이터가 밖으로 나가면 안 됨(온프렘 강제) | 셀프호스트 + 양자화 — 이때가 양자화의 진짜 존재 이유 |
| 로컬에서 가볍게 실험만 | Ollama/LM Studio + GGUF Q4_K_M |
| NVIDIA GPU 로 프로덕션 서빙 | vLLM + AWQ(Marlin) — 속도·품질 균형 최선 (verified 2026-07) |
판단 순서: (1) 정말 셀프호스트가 필요한가(비용·프라이버시·레이턴시 때문에)? 아니면 API 가 거의 항상 싸고 편하다. (2) 필요하다면, 큰 모델 4bit vs 작은 모델 FP16 을 비교하라. (3) 그다음에야 포맷을 고른다. model-choice-decision-guide 도 함께 보라.
함정 (gotcha)
- 포맷 ≠ 알고리즘: GGUF·Marlin 을 AWQ·GPTQ 와 같은 층위로 비교하다 혼란에 빠진다. 위 표대로 정체를 구분하라.
- vLLM 에서 GGUF 를 기대하지 마라: llama.cpp 용 포맷이라 vLLM 위에선 throughput 이 무너지고 TTFT(첫 토큰까지 지연)가 매우 높다. vLLM 이면 AWQ/GPTQ.
- VRAM 계산에 KV 캐시를 빼먹는다: 가중치만 계산해 "들어간다" 판단했다가 긴 컨텍스트에서 OOM. 가중치 위에 KV·activation 여유를 반드시 더하라.
- Q2 로 너무 내린다: 저비트일수록 품질이 급락한다. Q2_K 는 체감 저하가 크다 — 무손실 착각 금지.
- 큰 모델을 무리하게 저비트로: 32B 를 2bit 로 욱여넣느니 14B 를 FP16/Q6 로 돌리는 게 품질이 나을 수 있다.
정밀 벤치마크 점수(perplexity·코드 통과율 절대값)는 위키 관례상 인용하지 않는다. 위 서열·감각은 raw 캡처의 실측을 정성 요약한 것이며 원본은 아래 출처에 있다.
참고
- open-weight-models — 양자화 대상이 되는 오픈웨이트 모델 목록과 선택. 이 문서의 전제.
- model-choice-decision-guide — 셀프호스트 vs API, 큰 모델 vs 작은 모델을 먼저 가르는 판단.
- tokens-and-context-windows — KV 캐시가 컨텍스트 길이에 따라 VRAM 을 얼마나 더 먹는지.
- glossary — VRAM·perplexity·양자화 용어 정의.
출처: 포맷·서열·VRAM 규칙은 aggregator([MED], jarvislabs.ai 실측 + 검색 요약). 세부 수치는 재확인 요망. 원본 → 2026-07-25-concepts-retrieval-quality