LLM 양자화 완전정리 — FP16·INT8·INT4, GGUF·AWQ·GPTQ 선택법

로컬 LLM을 실행하려고 모델을 내려받다 보면 같은 모델인데도 FP16, INT8, INT4, AWQ, GPTQ, GGUF처럼 이름이 여러 개 붙어 있는 것을 보게 됩니다. 파일 크기가 작으면 무조건 빠를 것 같지만 실제로는 실행 엔진, GPU 종류, CPU 오프로딩, 커널 지원에 따라 결과가 달라집니다.

결론부터 말하면 양자화는 모델의 숫자를 더 적은 비트로 표현해 메모리 사용량을 줄이는 기술입니다. 다만 압축률만 보고 고르면 안 됩니다. 모델 품질, 첫 토큰 지연시간, 생성 속도, 동시 처리량, 하드웨어 호환성을 함께 봐야 합니다.

핵심 요약

• FP16·BF16은 품질 검증의 기준점으로 쓰기 좋지만 메모리 사용량이 큽니다.
• INT8은 메모리와 품질 사이의 보수적인 선택입니다.
• INT4는 메모리를 크게 줄이지만 모델·작업별 품질 검증이 필수입니다.
• bitsandbytes는 간편한 로딩과 실험에, AWQ·GPTQ는 사전 양자화된 GPU 추론에 자주 사용됩니다.
• GGUF는 양자화 알고리즘 하나의 이름이 아니라 llama.cpp 계열에서 모델과 메타데이터를 저장하는 파일 형식입니다.
• 가장 좋은 방식은 “내 실행 엔진에서 잘 지원되는 형식”입니다.

양자화 모델로도 GPU 메모리가 부족하다면 vLLM CUDA OOM 해결 가이드를 먼저 확인하세요. 서버가 실행되지만 느리다면 vLLM 속도 튜닝 가이드에서 TTFT와 처리량을 기준으로 병목을 분리하는 편이 좋습니다.

1. 양자화가 필요한 이유

LLM의 가중치는 수십억 개의 숫자로 구성됩니다. 이 숫자를 어떤 정밀도로 저장하느냐에 따라 가중치가 차지하는 메모리가 달라집니다. 단순 계산으로 70억 개 파라미터를 FP16으로 저장하면 가중치만 약 14GB가 필요합니다.

이론적 가중치 크기 = 파라미터 수 × 비트 수 ÷ 8

7B 모델 FP16: 70억 × 16 ÷ 8 ≈ 14GB
7B 모델 INT8: 70억 × 8 ÷ 8 ≈ 7GB
7B 모델 INT4: 70억 × 4 ÷ 8 ≈ 3.5GB

실제 실행에는 스케일·제로포인트 같은 양자화 메타데이터, KV Cache, 임시 연산 버퍼, 프레임워크 오버헤드가 추가됩니다. 따라서 위 계산은 GPU 용량을 확정하는 값이 아니라 가중치 크기의 대략적인 출발점으로 사용해야 합니다.

2. FP16·BF16·INT8·INT4 차이

정밀도 가중치당 이론적 크기 장점 주의점

FP16·BF16	2바이트	원본에 가까운 품질, 넓은 호환성	VRAM 요구량이 큼
INT8	약 1바이트	비교적 보수적인 압축, 품질 유지에 유리	커널에 따라 속도 이득이 제한될 수 있음
INT4	약 0.5바이트	큰 메모리 절감, 더 큰 모델 적재 가능	품질 저하와 커널 호환성 검증 필요

중요한 점은 저장 비트와 실제 연산 정밀도가 항상 같지는 않다는 것입니다. 예를 들어 가중치는 4비트로 저장하더라도 연산 과정에서 일부 값을 FP16이나 BF16으로 복원해 계산할 수 있습니다. “4비트 모델”이라는 이름만으로 전체 연산이 모두 4비트라고 이해하면 안 됩니다.

3. 가중치 양자화와 활성값 양자화

표기에서 자주 보이는 W4A16은 가중치(weight)는 4비트, 활성값(activation)은 16비트를 사용한다는 뜻입니다. W8A8은 가중치와 활성값을 모두 8비트로 처리하는 구성을 의미합니다.

• Weight-only 양자화: 모델 가중치 메모리를 크게 줄이기 쉽고 적용 범위가 넓습니다.
• Weight + Activation 양자화: 지원 하드웨어와 커널에서 연산 효율을 더 높일 수 있지만 구현과 품질 보존이 어렵습니다.
• KV Cache 양자화: 긴 문맥과 높은 동시성에서 커지는 KV Cache 메모리를 줄이는 별도의 선택지입니다.

모델 가중치가 충분히 작아졌는데 동시 요청이 늘수록 메모리가 부족하다면 가중치보다 KV Cache가 병목일 수 있습니다. 이때 모델 비트 수만 계속 낮추는 것은 문제를 정확히 해결하지 못합니다.

4. bitsandbytes — 가장 간편한 시작점

bitsandbytes는 Transformers에서 8비트와 4비트 로딩을 간편하게 적용할 때 자주 사용됩니다. 원본 모델을 불러오는 과정에서 양자화를 적용할 수 있어 별도의 사전 양자화 파일을 찾지 않아도 된다는 장점이 있습니다.

from transformers import AutoModelForCausalLM, BitsAndBytesConfig

quant_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_compute_dtype="bfloat16"
)

model = AutoModelForCausalLM.from_pretrained(
    "YOUR_MODEL_ID",
    device_map="auto",
    quantization_config=quant_config
)

이 방식은 빠르게 모델을 시험하거나 QLoRA 계열 미세조정을 준비할 때 편리합니다. 반면 추론 전용 서버에서는 사전 양자화 형식과 최적화 커널을 사용하는 편이 더 빠를 수 있습니다. 공식 TGI 문서도 bitsandbytes의 온더플라이 양자화는 편리하지만 GPTQ나 FP16보다 추론이 느릴 수 있다고 설명합니다.

bitsandbytes가 잘 맞는 경우

• Transformers 코드에서 최소한의 변경으로 4비트·8비트를 시험할 때
• 여러 모델을 빠르게 비교하는 연구·개발 환경
• LoRA·QLoRA 미세조정을 준비할 때

5. GPTQ — 사전 양자화된 GPU 추론

GPTQ는 학습이 끝난 모델을 대상으로 하는 PTQ(Post-Training Quantization) 계열입니다. 작은 보정 데이터셋을 사용하고, 근사한 2차 정보를 바탕으로 양자화 오차를 줄이는 방식입니다. 원 논문은 거대 모델의 가중치를 3비트나 4비트까지 낮추면서 정확도 손실을 제한하는 것을 목표로 했습니다.

실무에서는 이미 GPTQ로 양자화된 모델을 받아 지원 엔진에서 실행하는 경우가 많습니다. 다만 파일에 GPTQ라고 적혀 있어도 group size, bit 수, 커널, 모델 구조에 따라 성능이 달라집니다.

GPTQ가 잘 맞는 경우

• GPU 추론을 목표로 하고 실행 엔진이 GPTQ 커널을 잘 지원할 때
• 사전 양자화된 모델을 그대로 배포하고 싶을 때
• 모델 품질과 메모리 사용량을 보정 데이터로 조절해야 할 때

6. AWQ — 중요한 가중치를 보호하는 4비트 양자화

AWQ는 활성값 분포를 관찰해 출력에 중요한 영향을 주는 가중치를 파악하고, 양자화 과정에서 중요한 채널을 더 잘 보존하는 접근입니다. 흔히 4비트 weight-only 양자화 모델로 배포되며 GPU 추론 엔진에서 폭넓게 사용됩니다.

AWQ와 GPTQ 중 어느 쪽이 항상 더 좋다고 말하기는 어렵습니다. 모델 구조, 보정 데이터, 실제 프롬프트, 배치 크기, 지원 커널이 결과를 바꿉니다. 같은 모델의 AWQ와 GPTQ를 비교할 때는 모델 파일 크기만 보지 말고 동일한 요청으로 품질과 속도를 측정해야 합니다.

AWQ가 잘 맞는 경우

• 지원되는 NVIDIA GPU 추론 엔진에서 4비트 모델을 운영할 때
• 이미 검증된 AWQ 체크포인트가 제공될 때
• 높은 동시 처리량과 낮은 가중치 메모리를 함께 노릴 때

7. GGUF — 알고리즘이 아니라 배포 파일 형식

GGUF는 GGML과 llama.cpp 기반 실행기에서 모델을 저장하고 로딩하기 위한 파일 형식입니다. 모델 구조, 토크나이저, 메타데이터와 양자화된 텐서를 한 파일에 담을 수 있습니다. Q4_K_M, Q5_K_M, Q8_0 같은 표기는 GGUF 안에서 사용되는 양자화 유형입니다.

따라서 “GGUF와 GPTQ 중 무엇이 더 정확한가?”라는 질문은 일부 조건이 빠져 있습니다. GGUF는 컨테이너 형식이고 GPTQ는 양자화 방법입니다. 실제 비교는 특정 GGUF 양자화 유형과 특정 GPTQ 설정, 그리고 실행 엔진까지 지정해야 의미가 있습니다.

GGUF가 잘 맞는 경우

• CPU 또는 CPU+GPU 혼합 추론을 사용할 때
• Apple Silicon, 일반 PC, 소형 서버 등 다양한 하드웨어에서 실행할 때
• llama.cpp, LM Studio 등 GGUF 중심 도구를 사용할 때

8. 형식별 선택 기준

상황 우선 검토 이유

품질 기준점 측정	FP16·BF16	양자화 손실을 비교할 기준이 필요함
Transformers에서 빠른 실험	bitsandbytes 8bit·4bit	로딩 설정이 간편하고 미세조정과 연결하기 쉬움
GPU 추론 서버	AWQ·GPTQ 또는 엔진 권장 형식	사전 양자화 가중치와 전용 커널 활용 가능
CPU·Apple Silicon·혼합 오프로딩	GGUF	llama.cpp 생태계와 다양한 하드웨어 백엔드 지원
최소 VRAM에 큰 모델 적재	검증된 INT4 계열	가중치 메모리를 크게 줄일 수 있음

9. 4비트가 항상 더 빠르지 않은 이유

모델 파일이 작아지면 메모리 대역폭 부담이 줄어 속도에 유리할 수 있습니다. 그러나 지원되지 않는 연산이 섞이거나, 매번 역양자화하는 비용이 크거나, 최적화 커널이 없으면 기대한 속도가 나오지 않습니다.

• GPU 아키텍처가 해당 저정밀 연산을 효율적으로 지원하는가
• 실행 엔진에 AWQ·GPTQ·INT4 전용 커널이 있는가
• 단일 요청 latency와 다중 요청 throughput 중 무엇을 측정하는가
• Prefill과 Decode 중 어느 구간이 병목인가
• CPU 오프로딩이나 PCIe 전송이 병목이 아닌가

따라서 “FP16보다 파일이 4분의 1이니 속도도 4배”라는 계산은 성립하지 않습니다. 메모리 절감은 비교적 예측하기 쉽지만 속도 향상은 실제 벤치마크가 필요합니다.

10. 품질 검증은 어떻게 해야 하나

일반 벤치마크 점수 하나만으로 운영 품질을 결정하면 위험합니다. 실제 서비스 프롬프트에서 양자화 전후를 비교해야 합니다.

1. FP16 또는 BF16 모델의 결과를 기준으로 저장합니다.
2. 동일한 모델·토크나이저·샘플링 설정을 사용합니다.
3. 실제 업무 프롬프트를 짧은 입력, 긴 입력, 구조화 출력으로 나눕니다.
4. 정답률뿐 아니라 형식 준수, 반복, 환각, 한국어 표현을 확인합니다.
5. TTFT, tokens/s, 최대 VRAM, 동시 처리량을 함께 기록합니다.

코딩 모델이라면 코드 실행 결과와 테스트 통과율을 보고, RAG 모델이라면 근거 문서 인용 정확도를 봐야 합니다. 대화형 모델은 문장 자연스러움뿐 아니라 긴 대화에서 지시를 유지하는지도 확인합니다.

11. 흔한 실수

실수 1. 이름이 같은 4비트 모델은 모두 같다고 생각한다

양자화 알고리즘, group size, 보정 데이터, 커널이 다르면 품질과 속도도 달라집니다.

실수 2. 이미 양자화된 모델을 다시 양자화한다

양자화는 손실 압축입니다. 저정밀 모델을 다시 변환하면 누적 오차가 커질 수 있으므로 가능하면 원본 FP16·BF16 가중치에서 목적 형식으로 한 번에 변환합니다.

실수 3. 가중치 크기만 보고 VRAM을 계산한다

KV Cache, CUDA 그래프, 활성값, 임시 버퍼가 추가됩니다. 긴 문맥이나 높은 동시성을 쓰면 이 영역이 더 커질 수 있습니다.

실수 4. 실행 엔진의 지원 표를 확인하지 않는다

같은 양자화 형식이라도 vLLM, TGI, Transformers, llama.cpp의 지원 범위와 최적화 정도가 다릅니다. 모델을 받기 전에 엔진 문서를 먼저 확인하는 편이 시간을 절약합니다.

12. 실전 선택 순서

1. 목표 하드웨어와 실행 엔진을 먼저 정합니다.
2. FP16·BF16 기준 품질과 메모리를 측정합니다.
3. VRAM이 부족하면 INT8, 그다음 검증된 INT4를 비교합니다.
4. GPU 서버는 엔진이 권장하는 AWQ·GPTQ 형식을 우선 검토합니다.
5. CPU·Apple Silicon은 GGUF 양자화 유형을 비교합니다.
6. 실제 프롬프트로 품질·지연시간·처리량을 동시에 측정합니다.

마치며

양자화의 목적은 가장 작은 파일을 만드는 것이 아니라 사용 가능한 품질을 유지하면서 목표 하드웨어 안에 모델을 넣고, 필요한 속도를 얻는 것입니다.

처음이라면 FP16·BF16 결과를 기준점으로 만든 뒤 INT8과 INT4를 차례로 비교하세요. GPU 서버에서는 AWQ·GPTQ 같은 사전 양자화 형식과 실행 엔진의 커널 지원을 확인하고, CPU나 Apple Silicon에서는 GGUF를 우선 검토하면 선택지가 빠르게 정리됩니다.

FAQ

Q1. 7B 모델을 4비트로 만들면 4GB VRAM에서 실행되나요?

가중치의 이론적 크기는 약 3.5GB지만 양자화 메타데이터, KV Cache, 실행 버퍼가 추가됩니다. 4GB에 안정적으로 들어간다고 단정할 수 없으며 문맥 길이와 실행 엔진까지 포함해 확인해야 합니다.

Q2. AWQ와 GPTQ 중 무엇이 더 좋은가요?

절대적인 승자는 없습니다. 사용하려는 모델의 검증된 체크포인트가 있는지, 실행 엔진이 어떤 커널을 잘 지원하는지, 실제 프롬프트 품질이 어떤지를 기준으로 선택합니다.

Q3. GGUF의 Q4_K_M은 INT4와 같은 뜻인가요?

대략 4비트 계열로 이해할 수 있지만 모든 텐서가 단순한 균일 INT4 한 종류로 저장된다는 의미는 아닙니다. GGUF의 구체적인 양자화 유형과 혼합 방식을 확인해야 합니다.

Q4. 양자화하면 정확도가 반드시 떨어지나요?

양자화는 정보 손실을 만들 수 있지만 손실의 크기는 모델, 비트 수, 방법, 작업에 따라 다릅니다. 일반 대화에서는 차이가 작아 보여도 수학, 코딩, 구조화 출력에서는 더 크게 나타날 수 있어 작업별 평가가 필요합니다.

참고 공식 문서·논문

• Hugging Face Transformers Quantization Concepts
• Hugging Face TGI Quantization
• GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers
• AWQ: Activation-aware Weight Quantization for LLM Compression
• GGUF Specification
• llama.cpp Quantization Guide

함께 읽으면 좋은 글

• vLLM 속도 튜닝 가이드
• vLLM CUDA OOM 해결 가이드
• vLLM vs Ollama 비교
• 로컬 LLM 서버 구축 비용과 GPU 사양 비교