LLM 양자화 가이드: 7가지 방법 비교 (벤치마크 숫자 포함)

LLM 양자화 가이드: 7가지 방법 비교 (벤치마크 숫자 포함)

FP16 상태의 Llama 3.3 70B는 가중치만으로 140 GB가 필요합니다. H100 두 장이죠. Q4_K_M으로 양자화하면 같은 모델이 약 42 GB에 들어가며, 이는 중고 RTX A6000 한 장이면 충분한 용량입니다. 이 격차야말로 LLM 양자화가 존재하는 이유 그 자체이며, 잘못된 방법을 고르면 눈으로 보이는 품질 손실이든 보유하지 않은 VRAM이든 대가를 치르게 됩니다.

이 LLM 양자화 가이드는 2026년에 의미 있는 7가지 방법을 비교하며, 모든 숫자는 공개된 출처로 거슬러 올라갈 수 있습니다.

핵심 요약

• 양자화는 측정 가능하고 대개 작은 품질 손실과 메모리 및 대역폭을 맞바꾸는 것입니다.
• GPTQ와 AWQ는 GPU 우선이며, GGUF는 CPU에서도 실행되는 포맷입니다.
• Q4_K_M은 4가 아니라 가중치당 약 4.8비트에 자리합니다. 이름이 오버헤드를 숨기고 있습니다.
• llama.cpp k-quants PR에 따르면 6비트 양자화는 FP16 펄플렉시티의 약 0.1% 이내입니다.

LLM 양자화는 실제로 모델에 무엇을 하나요?

LLM 양자화는 모델 가중치를 더 낮은 수치 정밀도로 저장해, 반올림 오차를 대가로 메모리와 대역폭을 줄입니다. 700억 파라미터 모델은 FP16의 140 GB에서 4비트의 약 42 GB로 줄어듭니다. 지능은 남고, 소수점 자릿수만 사라집니다. 이 가이드의 모든 방법은 바로 그 트레이드오프의 변형입니다.

정밀도 사다리는 FP32(32비트)에서 FP16과 BF16(각각 16비트)을 거쳐 INT8, 그리고 INT4로 내려갑니다. 한 단계 내려갈 때마다 파라미터당 바이트가 절반이 됩니다. IEEE 754 표준이 부동소수점 포맷을 정의하며, Mark Horowitz의 2014년 논문 "Computing's Energy Problem"은 그 바이트에 대한 연산이 아니라 바이트를 이동시키는 작업이 에너지 비용을 지배하는 이유를 보여줬습니다. 이것이 양자화가 추론 속도를 높이는 물리적 이유입니다.

양자화를 작동시키는 두 가지 매개변수가 있습니다. 정수 범위를 실제 값으로 다시 매핑하는 승수인 **스케일 팩터(scale factor)**와, 0.0을 나타내는 정수인 **제로포인트(zero-point)**입니다. 대칭 양자화는 범위의 중심을 0에 두고 제로포인트를 생략하며, 비대칭 양자화는 가중치가 0에서 벗어나 몰려 있을 때 정수 범위 전체를 활용하기 위해 범위를 오프셋합니다.

가중치는 정적이고 정규 분포를 따르기 때문에 깔끔하게 양자화됩니다. 활성화 값은 그렇지 않습니다. 때로 중앙값의 100배에 달하는 이상치(아웃라이어) 활성화는 단순하게 양자화하면 반올림 오차를 폭발시킵니다. 이런 비대칭 때문에 여기 있는 대부분의 방법은 가중치만 양자화(W4A16)하고 활성화는 FP16으로 유지합니다.

**사후 학습 양자화(PTQ)**는 학습이 끝난 완성된 모델을 변환합니다. **양자화 인식 학습(QAT)**은 학습 중에 반올림을 시뮬레이션해 모델이 적응하도록 합니다. 이 글의 모든 내용은 PTQ입니다. QAT는 더 많은 연산과 학습 실행이 필요하며, 별개의 의사결정입니다.

INT4와 NF4 행은 이론상의 순수 4비트입니다. 가중치당 4비트 외에는 아무것도 없습니다. 실제 4비트 포맷은 그 위에 블록 스케일과 최솟값(min)을 얹기 때문에 더 높아집니다. Q4_K_M의 70B 모델은 35 GB가 아니라 약 42 GB입니다. 아래쪽의 VRAM 표는 대신 실효 비율을 사용합니다.

양자화는 모델의 지능을 줄이지 않습니다. 그 지능을 담아두는 소수점 자릿수를 줄일 뿐입니다. 그리고 API 추론에 토큰당 비용을 내고 있다면, LLM API 비용 줄이기는 대개 양자화된 모델을 직접 실행하는 것에서 시작됩니다.

7가지 양자화 방법, 한눈에 비교

아래 일곱 가지 방법은 2026년에 LLM을 양자화하는 모든 프로덕션 경로를 다룹니다. 두 가지는 GPU 전용(GPTQ, AWQ)이고, 하나는 어디서나 실행되며(GGUF), 하나는 로드 시점에 양자화하고(BitsandBytes), 두 가지는 고처리량 서빙을 겨냥하며(SmoothQuant, FP8), 하나는 PyTorch 네이티브(TorchAO)입니다. 올바른 선택은 리더보드에서 가장 높은 점수를 받은 방법이 아니라 여러분의 하드웨어에 달려 있습니다.

GPTQ는 역 헤세 행렬(inverse Hessian)을 사용해 레이어별로 양자화하며, 반올림 오차를 남은 가중치에 재분배합니다. 캘리브레이션 세트와 GPU가 필요합니다. GPTQ 논문은 175B 모델을 약 4 GPU-시간 만에 3-4비트로 양자화했다고 보고합니다.

AWQ는 가장 중요한 약 1%의 가중치(활성화 크기로 찾아낸 salient 가중치)를 식별하고, 반올림으로부터 보호하기 위해 스케일을 조정합니다. AWQ 논문(MLSys 2024 최우수 논문)은 데스크톱과 모바일 GPU 양쪽에서 HuggingFace FP16 구현 대비 3배 이상의 속도 향상을 보고합니다.

GGUF는 알고리즘이 아니라 파일 포맷입니다. 내부의 알고리즘은 llama.cpp PR #1684의 k-quant 블록 방식입니다. 여기에서 CPU에서 실행되는 유일한 방법이며, 그래서 로컬 추론의 기본 선택지입니다. 어떤 모델을 올릴지는 양자화할 가치가 있는 오픈 웨이트 모델을 참고하세요.

BitsandBytes는 미리 양자화하지 않고 로드 시점에 양자화합니다. NF4(4비트 NormalFloat)가 이 방식의 대표 포맷이며, QLoRA 파인튜닝의 뼈대입니다. 캘리브레이션 세트가 필요 없습니다.

SmoothQuant는 활성화 이상치를 가중치 쪽으로 이동시켜 양쪽 모두 INT8로 실행할 수 있게 합니다. 논문은 최대 1.56배의 속도 향상과 2배의 메모리 감소를 보고하며, W4A16 방식이 성능을 놓치는 대용량 배치 서빙의 처리량을 겨냥합니다.

**FP8(W8A8)**은 H100과 B200 GPU의 네이티브 경로입니다. 8비트에서 무손실에 가깝고, 캘리브레이션 골칫거리가 없으며, vLLM이 직접 지원합니다.

TorchAO는 PyTorch 고유의 양자화 라이브러리로, torch.compile과 함께 작동하도록 만들어졌습니다. 파이프라인이 이미 PyTorch라면 가장 저항이 적은 경로입니다.

실제 질문은 단 두 가지입니다. 여러분의 하드웨어가 그것을 실행할 수 있는가, 그리고 그 품질 비용을 감수할 수 있는가입니다.

공개된 벤치마크는 실제로 무엇을 보여주나요?

공개된 벤치마크는 7B 모델에서 4비트 양자화가 1-2%의 펄플렉시티 비용을 치르고, 6비트는 0.1% 미만이라고 말합니다. 이 숫자는 llama.cpp PR #1684(2023)에서 나온 것으로, llama.cpp 메인테이너가 RTX 4080 위의 단일 7B 모델로 측정한 값입니다. 양자화 분야에서 가장 많이 인용되는 수치이며, 실제 값입니다. 동시에 n = 1이기도 합니다.

출처: llama.cpp PR #1684(2023). 7B 모델, RTX 4080, llama.cpp 메인테이너 측정. n = 1 모델.

비트/가중치 열에 대한 참고: 이 값들은 기본 k-quant 타입의 명목상 비율이며, _K 혼합은 실효 비율을 높입니다. Q2_K가 딱 그런 사례입니다. 이 글의 공식을 명목값 2.5625와 6.74B 파라미터 모델에 적용하면 약 2.0 GB가 나오지만, 해당 행은 2.67 GB 파일을 보고하며, 이를 역산하면 가중치당 약 3.4비트입니다. 이 글의 나머지는 이 파일 크기에서 도출한 실효 비율을 사용합니다.

GPU 방법의 숫자는 논문에서 직접 가져왔습니다. GPTQ는 FP16 대비 엔드투엔드 추론 속도 향상을 A100에서 약 3.25배, A6000에서 약 4.5배로 보고하며, 175B 모델을 약 4 GPU-시간 만에 3-4비트로 양자화했습니다. AWQ는 "데스크톱과 모바일 GPU 양쪽에서 Huggingface FP16 구현 대비 3배 이상의 속도 향상"을 보고하며, TinyChat을 통한 모바일 GPU 최초의 70B Llama-2 배포도 포함합니다. 숫자를 거짓 정밀도로 바꿔 쓰기보다 논문의 표현을 그대로 인용합니다.

여기서 독창적인 기여는 산수입니다. 가중치 메모리는 다음을 따릅니다. weights (GB) ≈ params (B) × bits per weight ÷ 8. 함정은 어떤 가중치당 비트 수를 넣느냐입니다. PR #1684는 기본 k-quant 타입의 비율(Q4_K = 4.5)을 공개하며, _S/_M/_L 혼합은 어텐션 텐서와 피드포워드 텐서에 추가 비트를 할당하기 때문에 그 기본 비율 위에 자리합니다. 그래서 PR 자체가 공개한 파일 크기에서 실효 비율을 도출했습니다. 실제로는 6.74B 파라미터인 7B 모델에서, 2.67 GB의 Q2_K는 약 3.4 bpw로 역산되고, 3.56 GB의 Q4_K_S는 약 4.5, 5.15 GB의 Q6_K는 약 6.6입니다. Q4_K_M은 약 4.8에 자리합니다.

이것이 헤드라인 숫자를 바꿉니다. Q4_K_M의 70B 모델은 70 × 4.8 ÷ 8 = 42 GB입니다. 대부분의 글은 35 GB라고 말합니다. 4.0 bpw를 사용하고 블록 스케일 오버헤드를 통째로 건너뛰기 때문입니다. 교차 검증은 클릭 한 번이면 됩니다. Llama-3.3-70B-Instruct-Q4_K_M.gguf는 HuggingFace에서 42.5 GB로 배포되며, bartowski, lmstudio-community, second-state 리포지토리 모두 마찬가지입니다. 아래 VRAM 표의 모든 셀을 그 기준으로 다시 계산했습니다.

이 숫자에 대한 저희의 해석은 이렇습니다. Q6_K(5.9110)와 F16(5.9066) 사이의 펄플렉시티 격차는 0.0044로, 같은 기반 모델의 서로 다른 두 파인튜닝 사이의 격차보다 작습니다. 그래서 "그냥 Q4_K_M이나 Q5_K_M을 쓰라"는 조언이 실제 하드웨어와 맞닿아도 살아남습니다. ms/토큰 열은 또한 Q2_K가 Q4_K_S 대비 속도 이득이 전혀 없으면서(둘 다 15.5 ms/토큰) 펄플렉시티는 0.75나 비싸다는 점을 보여줍니다. Q2_K는 표 안에서 최악의 거래입니다.

숫자가 말해주지 않는 것: wikitext 펄플렉시티는 여러분의 프롬프트에서의 품질과 같지 않습니다. 하나의 GPU 위 하나의 모델은 n = 1입니다. 속도 수치는 배치 크기에 따라 달라집니다. 방향성으로 받아들이되, 보편적 진실로 여기지는 마세요.

6비트 양자화는 전체 정밀도 모델 펄플렉시티의 약 0.1% 이내에 자리합니다. 그 수준에서는 압축이 거의 공짜입니다.

GPTQ vs AWQ: 두 GPU 방법 사이에서 선택하기

GPTQ와 AWQ는 둘 다 캘리브레이션 세트에서 4비트 GPU 체크포인트를 만들어내며, 둘 다 vLLM에서 잘 지원됩니다. 차이는 반올림 오차를 다루는 방식입니다. GPTQ는 역 헤세 행렬을 사용해 남은 가중치에 오차를 재분배합니다. AWQ는 활성화가 중요하다고 표시하는 1%의 가중치를 보호합니다. 둘 다 작동합니다. 선택은 여러분의 서빙 패턴에 달렸습니다.

GPTQ는 레이어별로 작동합니다. 각 레이어에서 한 번에 하나의 가중치를 양자화한 뒤, 방금 한 반올림을 보정하도록 해당 레이어의 남은 가중치를 조정합니다. 이 조정은 헤세 행렬의 2차 정보를 사용하며, 그래서 계산에 캘리브레이션 세트가 필요합니다. 결과는 토큰당 지연 시간보다 처리량이 중요한 배치 추론에서 강력합니다.

AWQ는 다른 각도를 취합니다. 캘리브레이션 세트 전반의 활성화 크기를 살펴 salient 가중치를 식별하며, 대략 상위 1% 채널입니다. 이 가중치들은 반올림 중 더 높은 정밀도 범위에 머물도록 채널별 스케일 팩터를 받습니다. 캘리브레이션 세트는 GPTQ보다 작아도 되며, 특정 입력에 맞추는 대신 구조적 특징을 보호하기 때문에 과적합도 적습니다. 논문은 지연 시간 민감 서빙에서 강력한 결과를 보고합니다.

GPTQ를 고를 경우: GPU에서 배치 추론을 하고, 도메인에 맞는 좋은 캘리브레이션 세트가 있으며, 지표가 처리량일 때.

AWQ를 고를 경우: 저지연으로 단일 사용자 요청을 서빙하고, 더 작은 캘리브레이션 세트를 원하거나, 에지/모바일 GPU에 배포할 때.

# Serve a published AWQ checkpoint with vLLM
vllm serve TheBloke/Llama-2-7B-Chat-AWQ \
  --quantization awq \
  --max-model-len 4096

# Serve a published GPTQ checkpoint with vLLM
vllm serve TheBloke/Llama-2-7B-Chat-GPTQ \
  --quantization gptq \
  --max-model-len 4096

서빙 엔진 사이에서도 고민 중이라면, vLLM과 SGLang 비교가 그 결정을 별도로 다룹니다.

GGUF와 K-Quants: Q4_K_M의 실제 의미

GGUF는 양자화 알고리즘이 아니라 파일 포맷입니다. GGUF 사양은 모델 가중치, 메타데이터, 토크나이저 데이터를 담는 컨테이너를 정의합니다. GGUF 파일 내부의 양자화 알고리즘은 llama.cpp PR #1684의 k-quant(또는 i-quant) 블록 방식입니다. 컨테이너와 알고리즘을 혼동하는 것이 이 분야에서 가장 흔한 실수이며, "GGUF와 GPTQ 중 뭐가 더 좋은가요?"처럼 성립하지 않는 질문으로 이어집니다.

명명 체계는 다음과 같이 풀립니다. Q는 k-quant 블록 방식을 뜻하고, IQ는 중요도 행렬 i-quant(같은 비트 깊이에서 더 나은 품질을 위해 중요도 행렬을 사용하는 최신 변형)를 뜻합니다. 숫자는 명목상 비트 깊이입니다. _K는 Q4_0 같은 레거시 포맷과 구별되는 k-quant 계열을 표시합니다. _S, _M, _L은 어떤 텐서 그룹이 추가 비트를 받을지 제어합니다. small, medium, large입니다. 접미사가 높을수록 가장 중요한 어텐션 텐서와 피드포워드 텐서에 더 많은 비트가 할당됩니다.

실효 비율은 기본 타입 수치가 아니라 PR #1684에 공개된 7B(6.74B 파라미터) 파일 크기에서 역산한 값입니다. 레거시 행은 구조상 정확합니다. Q4_0 블록은 4비트 가중치 32개에 FP16 스케일 하나를 더한 것으로 가중치당 4.5비트이며, Q8_0은 8비트 가중치 32개에 FP16 스케일 하나로 8.5입니다. PR도 이를 뒷받침하는데, 7B Q4_0과 Q4_K_S 파일을 같은 3.56 GB로 나열합니다.

Q4_K_M은 가중치당 4비트가 아닙니다. 약 4.8입니다. 블록 스케일과 최솟값은 어딘가에 있어야 하고, _M 혼합은 어텐션 텐서와 피드포워드 텐서에 추가 비트를 씁니다. 그래서 Q4_K_M이 Q4_K_S 위에, Q3_K_M이 Q3_K_S와 같지 않고 그 위에 자리하는 것입니다.

GGUF가 GPTQ가 못 가는 곳에서 실행되는 이유: CPU 추론과 GPU VRAM-시스템 RAM 간 레이어 오프로딩을 지원하기 때문입니다. GPU에 통째로 들어가지 않는 32B 모델도 레이어 절반을 오프로드해 실행할 수 있으며, 느리지만 작동은 합니다. GPTQ에는 CPU 경로가 없습니다.

# Pull a specific quant tag with Ollama
ollama run llama3.1:8b-instruct-q4_K_M

# Convert an F16 GGUF to Q4_K_M with llama.cpp
llama-quantize model-f16.gguf model-q4_k_m.gguf Q4_K_M

로컬 모델이 처음인가요? 무엇인가를 양자화하기 전에 첫 로컬 모델 실행하기부터 시작하세요. 브라우저 UI를 원한다면 Ollama 위에 Open WebUI는 약 10분이면 됩니다. HuggingFace GGUF 문서는 Hub가 quant 타입 명명을 어떻게 노출하는지 설명합니다.

BitsandBytes, Marlin, SmoothQuant, TorchAO

이 네 가지는 남은 프로덕션 경로를 다룹니다. 어느 것도 "더 나은 GPTQ"가 아닙니다. 서로 다른 문제를 풉니다.

BitsandBytes는 미리 양자화하지 않고 로드 시점에 양자화합니다. FP16 체크포인트를 지정하면 즉석에서 NF4나 FP4로 변환합니다. 캘리브레이션 세트도, 오프라인 단계도 없습니다. 이 방식의 가장 큰 명성은 QLoRA입니다. 4비트로 고정된 기반 모델 위에 LoRA 어댑터를 학습하는 방식으로, 65B 모델의 단일 GPU 파인튜닝을 48 GB VRAM에서 가능하게 합니다. QLoRA는 추론 기법이 아니라 학습 기법이지만, 대부분의 사람이 BitsandBytes를 처음 접하는 이유이기도 합니다.

Marlin은 양자화 방법이 아닙니다. 적당한 배치 크기에서 기존 4비트 체크포인트를 빠르게 만드는 INT4xFP16 혼합 정밀도 GEMM 커널입니다. Marlin 논문은 A100과 H100에서의 속도 향상을 보고합니다. 서빙 스택이 지원한다면, 이미 양자화된 모델에서 활성화하면 됩니다. "Marlin으로 양자화"하는 것이 아닙니다.

SmoothQuant는 채널별 스케일링 팩터를 통해 활성화 이상치를 가중치 쪽으로 옮겨, W8A8(가중치와 활성화 모두 INT8)을 실현 가능하게 만듭니다. 논문은 W4A16 방식이 처리량을 놓치는 대용량 배치 서빙을 겨냥합니다. 수백 개의 동시 요청을 서빙한다면, 이것이 정답입니다.

TorchAO는 torch.compile과 함께 작동하는 PyTorch 네이티브 양자화입니다. 외부 의존성도, 포맷 변환도 없습니다. 추론 파이프라인이 이미 PyTorch라면 마찰이 가장 적은 선택지입니다. 임베딩 모델을 로컬로 실행하는 경우 대개 Ollama 경로가 더 단순하지만, TorchAO는 커스텀 PyTorch 스택에 맞습니다.

양자화된 모델에는 VRAM이 얼마나 필요한가요?

공식은 weights (GB) ≈ params (B) × bits per weight ÷ 8입니다. Q4_K_M의 70B 모델은 70 × 4.8 ÷ 8 = 42.0 GB입니다. 아래 비율은 실효값으로, 기본 타입 수치가 아니라 llama.cpp PR #1684가 공개한 파일 크기에서 역산했습니다. _M 혼합은 항상 기본 k-quant 비율 위에서 작동하기 때문입니다. 흔한 4.0-bpw 지름길을 베끼는 대신 다시 계산했습니다.

실효 가중치당 비트 수로 계산: Q8_0 = 8.5, Q6_K = 6.56, Q5_K_M = 5.7, Q4_K_M = 4.8, Q3_K_M = 3.9. PR #1684의 7B(6.74B 파라미터) 파일 크기에서 도출한 뒤 공개된 70B 빌드와 교차 검증했습니다. Llama-3.3-70B-Instruct-Q4_K_M.gguf는 HuggingFace에서 42.5 GB로, 여기서 예측한 42.0 GB와 대조됩니다.

정직한 주의사항: 이것은 가중치만 해당합니다. KV 캐시, 컨텍스트 길이, 프레임워크 오버헤드가 그 위에 더해집니다. KV 캐시는 컨텍스트 길이와 배치 크기에 따라 커집니다. 70B 모델의 32k 컨텍스트 세션은 몇 GB를 더할 수 있습니다. 가중치 표는 하한선이지 예산이 아닙니다. 컨텍스트 윈도우도 VRAM을 빌려 씁니다. 전체 그림은 모델별 VRAM 요구사항 상세를 참고하세요.

어떤 양자화 방법을 써야 하나요?

선호보다 하드웨어가 먼저 결정합니다. 여러분의 GPU에서 실행되지 않는 방법은 선택지가 아니라 소망입니다. 아래 표는 위에서 다룬 하드웨어 제약과 품질 트레이드오프를 바탕으로, 흔한 구성을 실제로 작동하는 방법에 대응시킵니다.

소비자용 하드웨어를 쓰는 대부분의 독자에게는 사전 양자화된 Q4_K_M 또는 Q5_K_M GGUF가 정답입니다. HuggingFace에서 받아 Ollama나 llama.cpp로 실행하고, 최적화를 멈추세요. Q4_K_M과 Q5_K_M의 품질 차이는 충분히 작아서, 펄플렉시티 표가 아니라 파일이 들어맞는지 여부로 골라야 합니다. 그 너머의 모든 것은 최적화를 위한 최적화이며, Q4에서 모델이 실제로 여러분의 문제를 푸는지 확인한 뒤에야 할 가치가 있습니다.

이 모델들을 실제로 로컬에서 돌리는 도구 가이드는 quant 단계를 고른 뒤의 서빙 쪽을 다룹니다.

양자화가 잘못되는 다섯 가지 경우

양자화 실패는 거의 항상 방법의 문제가 아니라 설정의 문제입니다. 이 다섯 가지는 끊임없이 등장합니다.

1. 캘리브레이션 세트가 도메인과 맞지 않는다. GPTQ와 AWQ는 둘 다 캘리브레이션 데이터에 맞춰집니다. Wikipedia로 캘리브레이션하고 의료 전사 기록에 배포하면, 양자화된 모델은 한 번도 보지 못한 토큰에서 성능이 떨어집니다. 해결책: 실제 입력 분포에서 뽑은 캘리브레이션 세트를 사용하세요. 128개 샘플만으로도 도움이 됩니다.

2. 그룹 크기를 너무 크게 설정한다. GPTQ의 그룹 크기는 몇 개의 가중치가 하나의 스케일 팩터를 공유할지 제어합니다. 표준은 128입니다. 256이나 512는 양자화 중 연산을 아끼지만, 작은 모델에서는 품질 절벽에 부딪힙니다. 해결책: 여러분의 프롬프트에서 품질이 유지된다고 확인하지 않는 한 128을 유지하세요.

3. Q2_K가 쓸만하리라 기대한다. PR #1684 데이터에 따르면, Q2_K는 F16 대비 약 0.87의 펄플렉시티 비용을 치르면서도 Q4_K_S 대비 속도 이득이 없습니다(7B 벤치마크에서 둘 다 15.5 ms/토큰). 더 작은 파일과 더 나쁜 출력을 얻되 지연 시간 이득은 없습니다. 해결책: 파일 크기가 절대 제약이 아닌 한 Q4_K_S가 하한선입니다.

4. 자기 프롬프트 대신 wikitext 펄플렉시티로 벤치마크한다. 펄플렉시티는 언어 모델링 지표입니다. 모델이 시스템 프롬프트를 따르는지, JSON을 올바르게 형식화하는지, 도메인 어휘를 다루는지는 측정하지 않습니다. 해결책: 실제 프롬프트 20-30개를 양자화된 모델과 양자화되지 않은 모델 양쪽으로 실행하고 출력을 비교하세요.

5. 컨테이너인 GGUF를 그 안의 양자화 알고리즘과 혼동한다. 이는 "GGUF vs GPTQ"를 같은 범주인 것처럼 비교하는 결과로 이어집니다. 둘은 같은 범주가 아닙니다. GGUF는 파일 포맷입니다. 그 안의 k-quant 방식이 알고리즘입니다. 해결책: 파일 포맷이 아니라 k-quant 단계(Q4_K_M vs Q5_K_M)를 비교하세요.

자주 묻는 질문

LLM 양자화란 무엇인가요?

LLM 양자화는 모델 가중치의 수치 정밀도를 낮추는 것으로, 대개 16비트 부동소수점에서 4비트 또는 8비트 정수로 낮춥니다. 이로써 메모리 사용량이 줄고 대역폭이 감소해 추론이 빨라집니다. 70B 모델은 140 GB에서 4비트 시 약 42 GB로 줄어듭니다. 품질 비용은 대개 4비트에서 1-2% 펄플렉시티이며, 6비트에서는 더 적습니다.

양자화가 모델 정확도를 떨어뜨리나요?

그렇지만, 대부분의 기대보다는 적습니다. llama.cpp PR #1684 벤치마크에 따르면, 7B 모델의 Q4_K_S는 F16 대비 약 2%의 펄플렉시티 비용을 치르고, Q6_K는 0.1% 미만입니다. 실제 프롬프트에서의 실질적 영향은 대개 펄플렉시티 숫자가 시사하는 것보다 작으며, 특히 Q4_K_M 이상에서 그렇습니다.

GPTQ와 AWQ 중 뭐가 더 나은가요?

어느 쪽이 보편적으로 더 낫지는 않습니다. GPTQ는 역 헤세 행렬 오차 재분배를 사용하며 배치 GPU 추론에 맞습니다. AWQ는 활성화 인식 스케일링으로 salient 가중치를 보호하며 지연 시간 민감 서빙에 맞습니다. AWQ는 더 작은 캘리브레이션 세트가 필요하고 과적합도 적습니다. 저지연으로 단일 사용자 요청을 서빙한다면 AWQ로 시작하세요.

Q4_K_M은 무엇을 뜻하나요?

Q4_K_M은 k-quant GGUF 양자화 단계입니다. "Q4"는 명목상 4비트 깊이를 뜻하고, "K"는 k-quant 블록 방식(레거시 Q4_0과 구별)을 표시하며, "M"은 medium을 뜻합니다. 어텐션 텐서와 피드포워드 텐서가 추가 비트를 받습니다. 실효 가중치당 비트 수는 4.0이 아니라 약 4.8인데, 블록 스케일과 최솟값이 오버헤드를 더하고 medium 혼합이 그 위에 더 쓰기 때문입니다.

양자화된 모델을 CPU에서 실행할 수 있나요?

가능합니다. 하지만 GGUF를 통해서만 됩니다. GPTQ와 AWQ는 GPU 전용 포맷입니다. GGUF의 k-quant 모델은 llama.cpp나 Ollama를 통해 CPU에서 실행되며, GPU VRAM과 시스템 RAM 간 레이어 오프로딩을 지원합니다. Q4_K_M이 표준 CPU quant입니다. GPU보다 토큰 생성은 느리지만, 작동하는 추론을 기대할 수 있습니다.

GGUF와 GGML의 차이는 무엇인가요?

GGML은 llama.cpp가 원래 사용하던 구형 텐서 라이브러리이자 파일 포맷입니다. GGUF는 2023년 8월에 더 나은 메타데이터 지원을 갖춘 더 유연한 컨테이너 포맷으로 이를 대체했습니다. 오늘날 HuggingFace에서 다운로드하는 파일은 GGUF입니다. GGML 파일은 레거시이며 이제 거의 배포되지 않습니다.

모델을 직접 양자화해야 하나요, 사전 양자화된 것을 다운로드해야 하나요?

먼저 사전 양자화된 것을 다운로드하세요. llama.cpp와 HuggingFace 커뮤니티는 이미 대부분의 인기 모델을 모든 단계에서 양자화해 두었습니다. 직접 양자화하는 것이 의미가 있는 경우는 도메인용 특정 캘리브레이션 세트가 필요하거나, 모델에 대한 사전 양자화 버전이 없을 때뿐입니다.

더 작은 모델 대신 양자화를 언제 써야 하나요?

더 큰 모델의 역량이 필요하지만 메모리에 들어가지 않을 때 양자화를 사용하세요. 양자화된 70B 모델은 대개 복잡한 추론 작업에서 양자화되지 않은 13B 모델을 능가합니다. 지연 시간이 제약이라면 더 작은 모델을 대신 사용하세요. 작은 모델은 양자화와 무관하게 토큰을 더 빠르게 생성합니다.

양자화와 증류의 차이는 무엇인가요?

양자화는 기존 모델 가중치의 수치 정밀도를 낮춥니다. 증류(디스틸레이션)는 더 작은 모델이 더 큰 모델을 모방하도록 학습시켜, 본질적으로 다른(더 작은) 아키텍처를 만들어냅니다. 양자화는 원래 모델의 아키텍처를 보존하며 원칙적으로 되돌릴 수 있습니다. 증류는 새 모델을 만들며 학습 실행이 필요합니다.

짧은 버전: 양자화는 원하는 모델을 가진 하드웨어에 맞추는 방법입니다. 소비자용 GPU나 Apple Silicon을 쓰는 대부분의 사람에게, HuggingFace에서 받아온 사전 양자화 Q4_K_M GGUF가 해결책의 전부입니다. GPTQ와 AWQ는 GPU 서빙의 답입니다. FP8과 SmoothQuant은 프로덕션 처리량의 답입니다. 그 밖의 모든 것은 모델이 작동한다고 확인한 뒤의 최적화입니다.

무엇을 셀프 호스팅할지 결정 중이고 하드웨어-방법 조합에 대한 제3의 의견을 원하신다면, 상담을 환영합니다.