View

출처: convexapp.com
허깅페이스에 들어가면 Q4_K_M이니 GPTQ니 AWQ니 하는 태그가 덕지덕지 붙어 있는 광경을 본 적이 있을 것이다. 이게 대체 무슨 소린지 알기 어려운데 제대로 설명해 주는 글도 별로 없다. 흔히 "4bit 양자화"라고 하지만 그래서 어쩌라는 것인지 감이 잡히지 않는다.
LLM을 돌려 보려고 모델을 다운로드받으려는데 VRAM이 부족하다는 알림이 뜨고, 결국 양자화 버전을 찾아가면 또 무엇이 GPTQ이고 무엇이 GGUF인지 골라야 한다. 이 글을 다 읽고 나면 LLM 양자화 원리부터 방식별 차이, 실제 성능 손실 수준, 상황별 선택 기준까지 한 번에 정리된다. 수식 없이 비유부터 시작한다.
양자화란 무엇인가? 쌀을 좁쌀로 바꾸는 작업이다
2L 생수통을 500mL 병 4개로 쪼개는 비유
LLM 양자화를 한 줄로 요약하면 "뚱뚱한 숫자를 날씬한 숫자로 바꾸는 작업"이다. 원래 모델 가중치 하나가 FP16(16비트 부동소수점, 2바이트)으로 저장돼 있다고 가정하면, 이를 INT8(1바이트)이나 INT4(0.5바이트)로 눌러 담는 작업이다.
쉽게 말하면 2L 생수통이 들어가지 않는 냉장고에 500mL 병 4개로 나누어 넣는 것과 같다. 안에 들어 있는 물의 "대략적인 양"은 비슷하게 유지되지만 용기 크기는 훨씬 작아진다. 또는 고해상도 사진을 압축하는 것과도 비슷하다. 1600만 색에서 256색으로 줄여도 사람이 보면 "어, 비슷한데?" 싶은 것과 동일한 원리다.
양자화 없이는 왜 구동이 어려운가
숫자로 감을 잡아 본다. LLaMA 3 70B 모델은 파라미터가 700억 개다. 각 파라미터가 FP16(2바이트)이면 필요한 메모리는 다음과 같이 계산된다.
- 70,000,000,000개 × 2바이트 = 140GB
140GB짜리 VRAM을 가진 개인용 GPU는 지구상에 존재하지 않는다. RTX 4090이 겨우 24GB이고, H100 80GB도 개인이 살 만한 물건은 아니다. 그러나 4bit 양자화를 적용하면 이렇게 바뀐다.
- 70,000,000,000개 × 0.5바이트 = 35GB
이 정도면 RTX 4090 두 장이나 A100 40GB 한 장으로도 어떻게든 돌아간다. 양자화 덕분에 개인이 70B를 돌리는 시대가 열린 것이다. 모델 경량화의 핵심 기술이 바로 이것이다.
그렇다면 왜 처음부터 4bit로 만들지 않는가?
이 질문이 자주 등장한다. 답은 학습 시점에는 정밀도가 필요하기 때문이다.
학습(training)은 gradient descent로 미세하게 파라미터를 업데이트하는 과정인데, 이때 소수점 뒷자리 차이가 누적돼 최종 성능을 결정한다. 0.001 단위의 변화까지 반영해야 수렴이 이루어진다. INT4는 표현 가능한 값이 16가지뿐이라 이런 미세 조정이 불가능하다.
따라서 학습은 FP32 또는 FP16으로 진행하고, 학습이 끝난 뒤 "이제 그만 뚱뚱해도 된다"라고 눌러 버리는 것이 양자화다. 추론(inference) 시점에는 파라미터가 고정돼 있어 정밀도가 다소 떨어져도 결과가 거의 비슷하게 나온다.
LLM 양자화 원리 (수식 없이 이해 가능하다)
가중치(weight)란 무엇이며 왜 양자화 대상인가
뉴럴넷에서 가중치는 뉴런 사이의 연결 강도다. 그저 소수점 숫자 하나에 불과하다. 예를 들면 -1.2345671이나 0.0081923 같은 값이 700억 개 들어 있다. 이 숫자들이 모델의 "지능"을 담고 있다.
문제는 이 숫자 하나하나가 FP16이면 2바이트씩 차지한다는 점이다. 70B 모델은 이 숫자가 700억 개이므로 140GB가 된다. 모델 양자화는 이 숫자들의 정밀도를 희생해 저장 공간을 확보하는 작업이다.
FP16 → INT4, 어떻게 압축하는가
핵심 아이디어는 "가중치 분포는 대부분 비슷한 범위에 몰려 있다"는 사실이다. 실제로 LLM 가중치는 대부분 -1 ~ 1 사이에 분포한다. 그래서 다음과 같은 절차를 거친다.
- 가중치 배열의 min/max 값을 찾는다 (예: -0.8 ~ 0.8)
- 이 범위를 16단계(INT4) 또는 256단계(INT8)로 쪼갠다
- 원래 숫자를 가장 가까운 단계로 반올림한다
- 스케일 팩터(scale factor)를 별도로 저장한다
아날로그 신호를 디지털로 바꾸는 ADC(Analog-to-Digital Converter)와 완전히 동일한 원리다. 8bit DAC가 0~255로 소리를 샘플링하는 것과 INT8 양자화가 본질적으로 같다.

출처: AI分享圈 (43KB)
정보 손실은 어떻게 처리하는가
당연히 손실이 발생한다. 원래 0.7234였던 값이 INT4에서는 0.75로 뭉개질 수 있다. 이 차이가 누적되면 perplexity(언어모델 품질 지표)가 다소 상승한다. 다만 "다소"라는 점이 중요하다. 대부분의 사람이 대화하면서 "어 얘가 멍청해졌네?" 하고 느낄 수준은 아니다. 구체적인 숫자는 뒤에서 보여 준다.
양자화 방식 총정리 — GPTQ, AWQ, GGUF, bitsandbytes
요즘 LLM 양자화 방식이 너무 많아 헷갈린다. 네 가지만 알면 거의 다 커버된다.
비교표로 한눈에
| 방식 | 타겟 환경 | 추론 속도 | 정확도 | 양자화 소요 시간 | 대표 툴 |
| GPTQ | GPU | 빠름 | 중상 | 길음 (수십분~수시간) | auto-gptq, vLLM |
| AWQ | GPU | 매우 빠름 | 상 | 중간 (수십분) | AutoAWQ, vLLM |
| GGUF | CPU/GPU/Mac | 중상 | 중~상 | 짧음 | llama.cpp, Ollama |
| bitsandbytes | GPU | 중간 | 중 | 즉시 (로드 시점) | transformers |
GPTQ — 학술적으로 검증된 정석파
GPTQ는 2022년 논문으로 등장한 방식이다. Frantar 등이 쓴 "GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers" 논문이 원본이다.
특징은 다음과 같다.
- Calibration 데이터셋이 필요하다. 양자화 시 샘플 문장 몇 개(대개 128개)를 돌려보면서 가중치 분포를 확인한다
- 양자화 시간이 오래 걸린다. 70B 모델 GPTQ를 돌리는 데 수 시간이 소요된다
- vLLM 같은 프로덕션 서빙 엔진에서 지원이 잘 된다
- 학술 벤치마크에서 기준점으로 자주 사용된다
허깅페이스 저장소에서 TheBloke/Llama-2-70B-GPTQ 같은 형식으로 올라온다. 지금은 TheBloke가 업로드를 하지 않지만, 그 전까지 커뮤니티 표준 제공자였다.
AWQ — 중요한 가중치는 살려두기
AWQ는 "모든 가중치가 똑같이 중요하지는 않다"라는 간단한 아이디어에 기반한다. 2023년 MIT가 낸 AWQ 논문이 원본이다.
핵심은 다음과 같다.
- activation 값이 큰(=중요한) 가중치는 FP16 그대로 유지한다
- 나머지 대다수는 INT4로 눌러 버린다
- 결과적으로 정확도 손실이 GPTQ보다 적다
- 4bit 양자화 중에서는 현재 가장 인기가 많다
요즘 실무에서 "양자화 무엇을 쓰지?" 하고 물으면 AWQ + vLLM 조합이 대세로 굳어지는 중이다. 추론 속도도 빠르고 품질도 괜찮다.
GGUF — 노트북에서도 구동되는 만능 포맷
GGUF는 llama.cpp 진영에서 만든 파일 포맷이다. llama.cpp GitHub를 가 보면 자세히 나온다.
강점은 다음과 같다.
- CPU 추론을 지원한다. 그래픽카드 없이도 돌아간다
- 맥북 M1/M2/M3 Metal 가속을 지원한다
- Vulkan, OpenCL 같은 다양한 백엔드를 지원한다
- 파일 하나로 깔끔하게 관리된다 (llama-3-8b.Q4_K_M.gguf 같은 형식)
- Ollama, LM Studio, text-generation-webui에서 모두 사용된다
허깅페이스에서 Q4_K_M, Q5_K_S, Q8_0 같은 태그가 붙어 있는 것은 모두 GGUF 양자화 방식이다. 개인이 로컬에서 돌릴 때 가장 편하다.
bitsandbytes — 한 줄로 끝나는 편의성
bitsandbytes는 Tim Dettmers가 만든 라이브러리다. bitsandbytes GitHub에서 확인 가능하다.
특징은 다음과 같다.
from transformers import AutoModelForCausalLM, BitsAndBytesConfig
bnb_config = BitsAndBytesConfig(load_in_4bit=True)
model = AutoModelForCausalLM.from_pretrained(
"meta-llama/Llama-3-8B",
quantization_config=bnb_config
)
이게 전부다. load_in_4bit=True 한 줄이면 양자화되면서 로딩된다. 별도로 양자화 파일을 다운로드받을 필요가 없다. 다만 GPTQ/AWQ보다는 추론 속도가 느린 편이다. 프로토타이핑이나 QLoRA 파인튜닝 시에 많이 쓰인다.

출처: mobisoftinfotech.com
그렇다면 성능은 얼마나 저하되는가?
이 부분이 가장 궁금할 것이다. "양자화하면 멍청해진다"라는 말이 많은데 실제로 얼마나 떨어지는지는 숫자로 확인해야 감이 잡힌다.
실제 벤치마크 — LLaMA 2 7B 기준
| 양자화 방식 | Perplexity (낮을수록 좋음) | 메모리 사용 | 변화율 |
| FP16 (원본) | 5.47 | 14GB | 기준 |
| INT8 | 5.48 | 7GB | +0.2% |
| INT4 (GPTQ) | 5.63 | 3.5GB | +2.9% |
| INT4 (AWQ) | 5.56 | 3.5GB | +1.6% |
| INT4 (GGUF Q4_K_M) | 5.60 | 4.1GB | +2.4% |
체감상은 다음과 같다.
- 일상 대화, 요약, 번역, Q&A 수준: 거의 구분되지 않는다
- 코드 생성: 다소 티가 난다. 복잡한 로직에서 실수 확률이 증가한다
- 복잡한 수학 추론: 명확하게 떨어진다. 특히 multi-step reasoning에서 두드러진다
- 긴 문서 생성: 뒷부분으로 갈수록 일관성이 다소 흔들린다
언제 양자화를 피해야 하는가
모든 경우에 양자화가 답은 아니다. 다음과 같은 경우에는 원본을 쓰거나 INT8까지만 적용한다.
- 의료 진단, 법률 자문처럼 정확도가 치명적인 도메인
- 장문 추론이 필요한 복잡한 코드 생성
- 여러 단계 논리가 꼬이면 안 되는 reasoning 작업
- 정밀한 수치 계산이 포함된 프롬프트
이런 경우에는 그냥 FP16을 유지하거나 INT8까지만 양자화하는 것이 안전하다.
VRAM 절약 실제 수치
모델별로 얼마나 메모리를 아낄 수 있는지 정리한다. 가중치만 계산한 수치이고 실제로는 KV 캐시 같은 추가 메모리가 더 필요하다.
| 모델 | FP16 | INT8 | INT4 |
| LLaMA 3 8B | 16GB | 8GB | 4GB |
| LLaMA 3 70B | 140GB | 70GB | 35GB |
| Mistral 7B | 14GB | 7GB | 3.5GB |
| Qwen 2.5 72B | 144GB | 72GB | 36GB |
| Gemma 2 27B | 54GB | 27GB | 13.5GB |
이 표를 보면 왜 4bit 양자화가 중요한지 바로 드러난다. 70B 모델을 35GB로 줄이면 A100 40GB 한 장이나 RTX 4090 두 장으로 돌아간다. 4bit가 없으면 개인은 아예 건드릴 수 없는 영역이다.
상황별로 무엇을 써야 하는가? 실무 가이드
환경별 추천
- 맥북/윈도우 노트북: GGUF로 가면 된다. Ollama를 깔고 ollama run llama3을 입력하면 끝이다. LM Studio도 UI가 깔끔하다
- RTX 3090 / 4090 한 대: GPTQ 또는 AWQ 4bit를 추천한다. vLLM으로 서빙하면 처리량이 매우 우수하다
- 다중 GPU 서버 서빙: AWQ + vLLM이 대세다. 여러 요청을 동시 처리할 때 가장 효율적이다
- 파인튜닝까지 할 경우: QLoRA를 권장한다. bitsandbytes 4bit 로드 + LoRA 어댑터 학습 조합이다
- 빠른 프로토타입 / 실험: bitsandbytes load_in_4bit=True로 편하게 처리한다. 성능은 약간 포기한다
- 정확도 극대화 필요: INT8까지만 양자화하거나 그냥 FP16을 유지한다
허깅페이스 파일명 해석법
허깅페이스에서 양자화 모델을 찾을 때 파일명이 암호처럼 보인다. 해독법을 정리한다.
GGUF 파일명 패턴:
llama-3-8b.Q4_K_M.gguf
llama-3-8b.Q5_K_S.gguf
llama-3-8b.Q8_0.gguf
- Q 뒤 숫자 = 비트 수. Q4는 4bit, Q5는 5bit, Q8은 8bit이다
- K = K-quant 방식 (일반 양자화보다 개선된 형태다)
- M, S, L = Medium, Small, Large 사이즈. 같은 비트 내에서 품질/용량 trade-off가 발생한다
- 대부분 Q4_K_M을 고르면 된다. 품질과 용량의 밸런스가 가장 좋다
- VRAM 여유가 있으면 Q5_K_M이나 Q6_K, 정말 빡빡하면 Q3_K_M을 선택한다
GPTQ/AWQ 저장소 패턴:
TheBloke/Llama-2-70B-GPTQ
hugging-quants/Meta-Llama-3-70B-Instruct-AWQ-INT4
저장소 이름에 GPTQ, AWQ가 명시돼 있다. 저장소 안에는 여러 bit 버전이 폴더로 나뉘어 있는 경우도 있다.
QLoRA란 무엇인가? 양자화와 파인튜닝의 결합
QLoRA는 양자화 + LoRA 파인튜닝을 합친 기법이다. 2023년 Tim Dettmers 논문으로 나왔다.
핵심은 다음과 같다.
- 베이스 모델을 4bit로 양자화해 VRAM을 아낀다
- 그 위에 작은 LoRA 어댑터(보통 수억 파라미터)만 학습한다
- 학습 중에는 양자화된 가중치를 frozen 상태로 유지한다
- 결과적으로 24GB GPU 한 대로 70B 모델 파인튜닝이 가능하다
QLoRA는 "양자화냐 파인튜닝이냐"라는 이분법이 아니라 양자화 상태에서 파인튜닝하는 방법이다. 개인 개발자가 LLaMA 70B 같은 모델을 커스터마이징할 수 있게 해 준 게임 체인저다.
LLM 양자화, 정리하면 이렇다
핵심 요약 5줄
- LLM 양자화 = 모델 가중치를 FP16에서 INT8/INT4로 눌러 메모리를 줄이는 기술이다
- 메모리는 1/4로 줄고, 정확도는 보통 2~3% 손실에 그친다 (대부분 체감하지 못한다)
- GPTQ/AWQ는 GPU 서빙용, GGUF는 노트북/맥 포함 범용, bitsandbytes는 간편함이 강점이다
- 실무 추론 서빙은 AWQ + vLLM 조합이 현재 대세다
- 개인 로컬 실행은 GGUF + Ollama만 알아도 95%가 커버된다
최소한 이것만 기억하면 된다
허깅페이스에서 Q4_K_M을 보면 GGUF 4bit 양자화이고, 대부분의 경우 이것을 받으면 된다. GPTQ가 붙은 것은 GPU에서 vLLM 같은 도구로 돌릴 때 사용한다. AWQ는 GPTQ의 업그레이드 버전인데 정확도가 더 좋다. load_in_4bit=True는 빠르게 테스트할 때 사용한다.
양자화는 이제 LLM 생태계에서 선택이 아니라 필수가 되었다. 70B급 모델을 돌리는 데 4bit를 쓰지 않으면 답이 없다. 다만 너무 겁먹을 필요는 없다. 품질 손실이 별로 없고, 툴체인도 다 갖춰져 있다. 그저 Ollama를 깔고 ollama pull llama3:70b을 입력하면 알아서 양자화 모델을 내려받아 준다.
다음에 해 볼 만한 것들
이 글을 읽고 나서 더 파보고 싶다면 다음을 시도해 본다.
- Ollama를 설치해 llama3:8b-instruct-q4_K_M을 직접 돌려 본다
- vLLM으로 AWQ 모델을 서빙해 tokens/sec을 측정한다
- QLoRA로 자기 데이터를 파인튜닝하는 실험을 진행한다
- Hugging Face Quantization 공식 문서를 정독한다
- GPTQ vs AWQ 벤치마크를 직접 비교한다
양자화 개념이 잡혔다면 이제 모델을 고르는 것도 덜 막막할 것이다. Q4_K_M을 보고 "아 그것이구나" 하는 수준이 되었다면 이 글의 목적은 달성된 것이다.
'AI LLM' 카테고리의 다른 글
| 개발은 Claude Code, 테스트는 Codex? 한 달 사용 후기를 정리한다 (0) | 2026.04.19 |
|---|---|
| Claude Code 유출 정리 - 여기서 인사이트를 뽑아간 개발자들이 왜 더 빨리 달리는가 (0) | 2026.04.19 |
| Claude Skills로 API를 구축할 때의 디렉토리 구조 - references/scripts/envs가 정석인 이유 (1) | 2026.04.19 |
| 투박한 AI 디자인 이제 끝인가? 클로드 디자인(Claude Design) 사용 방법 (1) | 2026.04.18 |
| Harness Engineering이란 무엇인가: AI Agent를 장시간 구동하는 개발자들이 DB와 YAML에 집착하는 이유 (0) | 2026.04.18 |
