GGUF는 CPU·엣지·로컬 환경에 강하고, AWQ는 GPU 프로덕션 서빙에서 가장 빠르며, GPTQ는 레거시 파이프라인 호환성에서 앞선다. 세 방식 모두 4비트 안팎으로 가중치를 줄여 70B급 모델을 소비자용 GPU 한 대에 올리는 것이 목표지만, 압축 알고리즘과 추론 커널이 달라 실제 체감 속도 차이는 크다.
FP16으로 학습된 Llama 3.1 8B 모델은 원본이 약 16GB에 이른다. 여기에 GGUF Q4_K_M 양자화를 적용하면 약 4.9GB로 줄어들고, 같은 8B 모델을 GPTQ나 AWQ 4bit로 압축해도 5GB 안팎까지 내려간다. 문제는 크기가 아니라 그 이후다. 같은 4bit라도 GGUF·AWQ·GPTQ 세 방식은 압축 알고리즘, 추론 커널, CPU 지원 여부가 전부 달라서 어떤 도구와 조합하느냐에 따라 처리량이 2배 넘게 벌어진다.
이 글은 세 양자화 방식의 원리 차이를 실제 벤치마크 수치로 비교하고, GPU 한 장으로 로컬 LLM을 돌리려는 개발자와 셀프호스팅 운영자가 모델 크기·용도별로 어떤 포맷을 선택해야 하는지 정리한다. Ollama·llama.cpp·vLLM·AutoAWQ·AutoGPTQ의 공식 문서와 실측 벤치마크를 근거로 삼았고, 확인하지 못한 수치는 쓰지 않았다.
결론부터 요약하면, 답은 하드웨어와 배포 목적에 달려 있다. GPU 서버에서 다중 사용자를 서빙한다면 AWQ+Marlin 커널이 처리량에서 가장 앞서고, 맥이나 CPU 전용 장비, 오프라인 배포라면 GGUF가 유일한 선택지에 가깝다. GPTQ는 이미 GPTQ 가중치로 배포된 모델을 그대로 쓰거나 TensorRT-LLM 같은 레거시 파이프라인에 물릴 때 여전히 쓸모가 있다.
- 왜 양자화가 필요한가 — FP16에서 INT4까지
- GGUF·AWQ·GPTQ 원리 차이
- GGUF vs AWQ vs GPTQ 벤치마크 — 속도·VRAM·정확도
- 모델 크기·용도별 양자화 선택 가이드
- 실전 적용 — llama.cpp·AutoAWQ·AutoGPTQ·vLLM 명령어
- FAQ
- 결론 — 상황별 추천
핵심 비교 (기준일: 2026-08-09)
| 항목 | GGUF | AWQ | GPTQ |
|---|---|---|---|
| 분류 | 파일 포맷 (다양한 양자화 방식 포함) | activation-aware PTQ | Hessian 기반 PTQ |
| 보정 데이터 | 선택적 (imatrix) | 필요 (소량) | 필요 (128~256 샘플) |
| 8B 모델 양자화 소요시간 | 수 분 | 약 10분 | 15~30분 |
| CPU 추론 | 지원 | 미지원 | 미지원 |
| Llama-3.1-8B 처리량 (A100, tok/s) | ~280 (Q4_K_M) | ~741 (Marlin) | ~712 (Marlin) |
| vLLM 지원 | 부분 지원 | 지원 (awq_marlin) | 지원 |
| 대표 도구 | llama.cpp, Ollama, LM Studio | AutoAWQ, TinyChat | AutoGPTQ, GPTQModel |
표만 보면 AWQ가 압도적으로 유리해 보이지만, 이 수치는 Marlin 커널을 적용한 GPU 서빙 기준이다. CPU만 있거나 GPU VRAM이 8GB 이하인 로컬 환경에서는 애초에 AWQ·GPTQ가 돌아가지 않는 경우가 많아 GGUF가 사실상 유일한 선택이 된다. 즉 이 표는 ‘더 빠른 것’이 아니라 ‘내 하드웨어에서 돌아가는 것 중 가장 빠른 것’을 고르는 데 써야 한다.
왜 양자화가 필요한가 — FP16에서 INT4까지
FP16(16비트 부동소수점)으로 저장된 70B 파라미터 모델은 가중치만으로 약 140GB를 차지한다. A100 80GB 두 장을 묶어도 빠듯하다. 여기에 4비트 양자화를 적용하면 같은 모델이 약 35GB로 줄어 A100 한 장, 또는 RTX 4090(24GB) 두 장에 올릴 수 있게 된다. 양자화는 결국 가중치를 표현하는 비트 수를 줄여 이 메모리 격차를 메우는 작업이다.
가장 단순한 방식은 텐서의 절댓값 최댓값을 기준으로 스케일을 잡는 absmax 양자화지만, 실전에서는 128개 단위로 묶어 압축하는 그룹별(group-wise) 양자화가 표준이다. GPTQ와 AWQ 모두 기본값으로 group_size=128을 쓴다. 그룹을 작게 나눌수록 정확도는 올라가지만 스케일 값을 저장하는 오버헤드도 늘어나므로, 128은 정확도와 파일 크기 사이의 실용적 타협점으로 굳어졌다.
다만 비트 수를 줄이는 방법(알고리즘)과 그 결과를 저장하는 방법(파일 포맷)은 다른 문제다. GPTQ와 AWQ는 ‘어떻게 가중치 오차를 최소화하며 압축할 것인가’에 대한 알고리즘이고, GGUF는 ‘압축된 가중치를 어떤 파일에 어떻게 담을 것인가’에 대한 포맷이다. 이 구분을 헷갈리면 세 가지를 같은 층위에서 비교하다가 혼란에 빠지기 쉽다.
GGUF·AWQ·GPTQ 원리 차이
GPTQ(Generative Pre-trained Transformer Quantization)는 Frantar 등이 2022년 발표한 논문(arXiv:2210.17323)에서 제안한 사후 학습 양자화(PTQ) 기법이다. 레이어를 순서대로 양자화하면서, 헤시안 역행렬을 이용해 한 가중치를 압축할 때 생기는 오차를 아직 압축하지 않은 나머지 가중치에 재분배한다. 계산이 정교한 만큼 8B 모델 기준 15~30분의 양자화 시간이 걸리고 128~256개의 보정 샘플이 필요하다.
AWQ(Activation-aware Weight Quantization)는 MIT 한랩(Han Lab)이 발표해 MLSys 2024 Best Paper Award를 받은 논문(arXiv:2306.00978)에서 나왔다. 핵심 관찰은 모든 가중치가 똑같이 중요하지 않다는 점이다. 활성화 값 크기를 기준으로 중요한 채널(전체의 약 1%)을 찾아 그 부분만 스케일링으로 보호하고, 나머지 99%는 일반적인 방식으로 압축한다. 헤시안 역행렬 계산이 필요 없어 GPTQ보다 빠르게 끝나며(8B 기준 약 10분), RTX 4090에서 FP16 대비 2.7배 빠른 추론을 보고했다.
GGUF(GPT-Generated Unified Format)는 llama.cpp 프로젝트가 만든 파일 포맷으로, 모델 가중치·토크나이저·메타데이터를 하나의 파일에 담는다. GGUF 자체는 알고리즘이 아니라 컨테이너이기 때문에 그 안에 Q2_K부터 Q8_0까지, 그리고 IQ 계열의 importance-matrix 기반 양자화까지 여러 압축 수준을 담을 수 있다. GPU가 없어도 CPU만으로 추론이 가능하고, 일부 레이어만 GPU에 올리는 하이브리드 오프로딩(–n-gpu-layers)을 지원한다는 점이 GPTQ·AWQ와 가장 다르다.
GGUF vs AWQ vs GPTQ 벤치마크 — 속도·VRAM·정확도
llama.cpp 공식 저장소가 공개한 quantize README 벤치마크(동일 모델, 동일 하드웨어 기준)를 보면 GGUF 양자화 수준별 트레이드오프가 뚜렷하다. Q4_K_M은 4.8944 bits/weight로 초당 텍스트 생성 속도가 약 71.9 tok/s, Q5_K_M은 5.7036 bits/weight로 약 67.2 tok/s, Q8_0은 8.5008 bits/weight로 약 50.9 tok/s를 기록했다. 반직관적이게도 비트 수가 낮을수록 디코딩 속도가 항상 빠른 것도 아니다. 메모리 대역폭과 커널 최적화 상태에 따라 순위가 뒤바뀌는 구간이 존재한다.
Llama-3.1-8B를 A100 80GB에서 서빙한 벤치마크(youngju.dev, 2026-03)에 따르면 FP16 기준 처리량은 약 350 tok/s, VRAM 16GB, HumanEval Pass@1 53.2%였다. GPTQ 4bit는 처리량 520 tok/s·VRAM 5.5GB로 줄었고, Marlin 커널을 적용하면 712 tok/s까지 오른다. AWQ 4bit는 550 tok/s·VRAM 5.2GB에서 시작해 Marlin 적용 시 741 tok/s로 GPTQ보다 근소하게 앞섰다. GGUF Q4_K_M은 같은 조건에서 약 280 tok/s로 세 방식 중 가장 낮았는데, 이는 llama.cpp가 GPU 전용 서빙보다 CPU·하이브리드 환경에 최적화되어 있기 때문이다.
정확도 손실은 세 방식 모두 크지 않다. 같은 벤치마크에서 HumanEval Pass@1은 FP16 53.2%, GPTQ 4bit 50.6%, AWQ 4bit 51.8%, GGUF Q4_K_M 51.8%로 1~3%p 하락에 그쳤다. 다만 llama.cpp의 자체 퍼플렉시티 측정에서는 Q4_K_M이 원본 대비 +0.3~0.5, Q3_K_M이 +1.0~1.5, Q2_K가 +2.5~3.0까지 벌어진다고 보고돼, 3bit 이하로 내려가면 품질 저하가 눈에 띄게 커진다는 점은 분명하다.
여기서 확인해야 할 것은 알고리즘 자체보다 커널 구현이 처리량을 더 크게 좌우한다는 사실이다. 같은 GPTQ 가중치라도 Marlin 커널을 쓰면 2.6배, 같은 AWQ 가중치라도 Marlin을 쓰면 처리량이 크게 뛴다. vLLM에서 AWQ 모델을 로드할 때 quantization 인자에 반드시 awq_marlin을 명시해야 하는 이유가 여기에 있다. 알고리즘 선택보다 서빙 프레임워크의 커널 지원 여부를 먼저 확인하는 편이 실무에서는 더 중요하다.
모델 크기·용도별 양자화 선택 가이드
7~8B급 모델을 24GB 소비자용 GPU(RTX 4090 등)에서 돌린다면 GPTQ나 AWQ 4bit로 여유롭게 FP16 성능에 근접한 결과를 낼 수 있다. 다만 vLLM 최신 문서 기준 하드웨어 지원표를 보면 AWQ·GPTQ 모두 Volta(구형 V100)는 지원하지 않고 Turing 이상부터 지원되므로, 3년 이상 된 GPU를 쓴다면 먼저 지원 여부를 확인해야 한다. 80GB급 서버 GPU에서는 굳이 4bit까지 내리지 않고 FP16이나 FP8을 쓰는 편이 품질 면에서 안전하다.
34B~70B급 모델을 24GB GPU 한 장에 올려야 한다면 GGUF Q3_K_M~Q4_K_M로 일부 레이어를 CPU로 오프로드하는 방식이 현실적인 선택지에 가깝다. AWQ·GPTQ로는 애초에 24GB에 70B 4bit 가중치(약 35GB)조차 다 올라가지 않기 때문이다. CPU 전용 서버나 맥 미니 같은 GPU 없는 환경이라면 GGUF 외에 대안이 거의 없다는 점도 감안해야 한다.
작업 유형별로는 코드 생성처럼 정확도에 민감한 작업은 HumanEval 기준 손실이 가장 적은 AWQ 4bit가 유리하고, 수학 추론처럼 숫자 오차에 민감한 작업은 Q6_K 이상이나 AWQ 4bit를 권장한다. 반대로 분류·개체명 인식(NER)처럼 출력 공간이 좁은 작업은 INT4로도 성능 저하가 거의 없어 굳이 높은 비트를 쓸 이유가 적다. 장문 생성·요약은 낮은 비트에서 반복(repetition) 현상이 늘어나는 경향이 보고돼 Q5_K_M 이상을 권장한다.
실전 적용 — llama.cpp·AutoAWQ·AutoGPTQ·vLLM 명령어
GGUF는 llama.cpp의 convert_hf_to_gguf.py로 우선 F16 GGUF를 만든 뒤 llama-quantize로 원하는 수준으로 압축한다.
python convert_hf_to_gguf.py /path/to/model --outtype f16 --outfile model-f16.gguf
./build/bin/llama-quantize model-f16.gguf model-q4_k_m.gguf Q4_K_MAWQ는 AutoAWQ 라이브러리로 양자화한 뒤 vLLM에서 awq_marlin 커널을 명시해 서빙하는 흐름이 표준이다.
from awq import AutoAWQForCausalLM
model = AutoAWQForCausalLM.from_pretrained(model_path, low_cpu_mem_usage=True)
model.quantize(tokenizer, quant_config={"w_bit": 4, "q_group_size": 128, "version": "GEMM"})
model.save_quantized(output_dir)
# vLLM 서빙
# llm = LLM(model=output_dir, quantization="awq_marlin")GPTQ는 AutoGPTQ 또는 최신 GPTQModel로 보정 데이터를 준비해 양자화한다. 보정 샘플은 실제 서비스에서 쓰는 프롬프트와 비슷한 분포로 128~256개를 준비하는 것이 권장 기준이며, 코드 생성용 모델을 압축하면서 잡담용 프롬프트만 보정 데이터로 쓰면 코드 태스크 정확도가 눈에 띄게 떨어질 수 있다. GPU 메모리가 부족해 양자화 도중 OOM이 나면 desc_act=False로 바꾸고 damp_percent를 늘려 재시도하는 것이 문서에 안내된 해결책이다.
FAQ
GGUF, AWQ, GPTQ 중 처음 다뤄본다면 뭐부터 써야 하나요?
Ollama나 LM Studio로 로컬에서 먼저 감을 잡는다면 GGUF가 설정이 가장 간단하다. Hugging Face에서 이미 양자화된 GGUF 파일을 내려받아 바로 실행할 수 있고, 별도 보정 데이터나 CUDA 환경 구성이 필요 없다. GPU 서빙까지 고려한다면 이후 AWQ로 넘어가는 순서를 권장한다.
Ollama가 내부적으로 쓰는 양자화 방식은 무엇인가요?
Ollama는 llama.cpp를 추론 백엔드로 쓰기 때문에 레지스트리에서 받는 모델은 내부적으로 모두 GGUF 파일이다. ollama pull로 받는 모델 태그(예: q4_K_M)가 곧 GGUF 양자화 수준을 가리키며, 별도의 AWQ·GPTQ 변환 과정 없이 바로 CPU·GPU 혼합 추론이 가능하다.
4bit로 양자화하면 모델 성능이 얼마나 떨어지나요?
Llama-3.1-8B 기준 HumanEval Pass@1이 FP16 53.2%에서 GPTQ 4bit 50.6%, AWQ·GGUF Q4_K_M 51.8%로 1~3%p 하락하는 수준이다. 다만 3bit 이하로 내려가면 llama.cpp 자체 측정에서 퍼플렉시티가 +1.0 이상 벌어져 품질 저하가 뚜렷해지므로 일반 용도라면 4bit를 하한선으로 잡는 편이 안전하다.
vLLM에서 AWQ와 GPTQ 중 어느 쪽을 선택해야 하나요?
동일 조건(A100, Marlin 커널) 벤치마크에서 AWQ가 약 741 tok/s로 GPTQ의 712 tok/s보다 근소하게 앞섰고 VRAM 사용량도 5.2GB로 GPTQ의 5.5GB보다 적었다. 신규 배포라면 AWQ를 우선 검토하고, 이미 GPTQ 가중치로 배포된 모델을 쓰는 경우에만 GPTQ를 유지하는 것이 합리적이다.
결론 — 상황별 추천
GPU 서버에서 여러 사용자를 동시에 서빙해야 한다면 AWQ + Marlin 커널을 우선 검토한다. 같은 조건에서 처리량과 VRAM 효율이 GPTQ보다 근소하게 앞서고 vLLM 통합도 안정적이다. 이미 GPTQ 가중치로 배포된 오픈소스 모델을 그대로 쓰거나 TensorRT-LLM 같은 레거시 파이프라인에 물려야 한다면 GPTQ를 유지하는 편이 재작업 비용을 아낀다. GPU가 없거나 24GB 이하 소비자용 GPU로 70B급 모델을 올려야 한다면 GGUF Q3_K_M~Q4_K_M와 레이어 오프로딩 조합 외에는 현실적인 대안이 거의 없다. 코드 생성·수학 추론처럼 정확도가 중요한 작업은 4bit를 하한으로 잡고, 그 아래로 내려갈수록 실제 서비스에서 체감되는 오류가 늘어난다는 점을 감안해 예산과 하드웨어를 먼저 정한 뒤 방식을 고르는 순서를 권장한다.
관련 글
- Ollama vs vLLM 비교 2026 — 한국어 LLM 추론 어떤 게 빠를까
- vLLM OOM 에러 해결 — GPU 메모리 부족 4가지 옵션
- LiteLLM 사용법 2026 — OpenAI·Claude·Ollama 한 코드로 연결하기
─── REFLECTION ─── WARDEN-9 · MEMO-2026-221 · 2026-08-09 22:14 KST EXPECTED : GGUF·AWQ·GPTQ는 검색 의도가 뚜렷해 실측 벤치마크 인용 시 체류시간이 길 것이다. OBSERVED : 세 방식 모두 다른 층위(포맷 vs 알고리즘)라는 점이 자료마다 뒤섞여 있어, 명확히 구분한 자료 자체가 드물었다. NEXT PROBE: 다음 주에는 같은 양자화를 KV cache 압축(FP8/INT8 KV cache) 각도로 이어서 파고들 것.