Choosing an LLM Quantization Method

LLM quantization 방법을 외울 때 가장 흔한 실수는 기술 이름을 같은 줄에 놓고 비교하는 것이다.

LLM.int8 vs GPTQ vs AWQ vs SmoothQuant vs TurboQuant

이렇게 보면 헷갈린다. 이 방법들은 같은 tensor를 줄이는 기술이 아니기 때문이다.

더 좋은 첫 질문은 이것이다.

무엇을 quantize하려는가?

Target tensor가 먼저다

LLM inference에서 줄일 수 있는 큰 대상은 보통 세 가지다.

weights:
model parameter memory와 weight bandwidth

activations:
low-precision compute path와 activation outlier

KV cache:
long context와 concurrency를 제한하는 serving state

Target이 다르면 좋은 방법도 달라진다.

weights

GPTQ / AWQ

Model weights dominate GPU memory

Can W4A16 quality hold?

activation outliers

LLM.int8 / SmoothQuant

INT8 activation path loses quality

Split outliers or move scale burden?

KV cache

KV INT4 / TurboQuant

Long context limits concurrency

Is cache capacity the bottleneck?

weights + activations

W8A8 / FP8

High batch prefill is compute-bound

Does the runtime have fast kernels?

tensor bottleneck runtime kernel quality metric

7장의 방법들은 같은 일을 하는 경쟁 기술이 아니다. 먼저 어떤 tensor가 병목인지 고르고, 그 다음 품질 손실과 runtime 지원을 같이 확인해야 한다.

Weight가 문제면 GPTQ/AWQ를 본다

GPU memory에서 model weight가 크고 decode가 weight bandwidth에 막힌다면 weight-only quantization이 먼저다.

W4A16:
weight -> 4-bit
activation -> FP16/BF16

이때 GPTQ와 AWQ는 같은 목표를 가진다. 둘 다 INT4 weight를 만들되, 단순 RTN보다 품질을 덜 잃는 방법이다.

GPTQ:
calibration activation으로 Hessian sensitivity를 보고 rounding error를 보정

AWQ:
activation이 큰 salient channel을 quantization 전에 보호

Activation outlier가 문제면 LLM.int8 또는 SmoothQuant를 본다

Activation까지 INT8로 내리면 compute path 이득을 기대할 수 있다. 하지만 LLM은 activation outlier 때문에 일반적인 INT8 activation quantization이 쉽게 망가진다.

이때 선택지는 크게 두 방향이다.

LLM.int8:
outlier dimension을 FP16 path로 분리

SmoothQuant:
activation의 큰 range 부담을 weight 쪽으로 이동

두 방법 모두 핵심은 같다.

activation outlier를 그냥 clip하지 않는다

다만 LLM.int8은 outlier를 별도 path로 보내는 쪽이고, SmoothQuant는 equivalent transformation으로 activation을 quantize하기 쉬운 형태로 바꾸는 쪽이다.

Long context가 문제면 KV cache를 본다

Weight를 줄였는데도 긴 context나 많은 동시 요청에서 GPU memory가 부족하면 KV cache가 병목일 수 있다.

context length 증가
concurrent requests 증가
prefix cache 증가
-> KV cache memory 증가

이때는 INT4/FP8 KV cache quantization이나 TurboQuant 같은 vector quantization을 본다.

TurboQuant는 특히 더 aggressive한 KV cache compression을 다룬다. Weight checkpoint를 작게 만드는 기술이 아니라, decode 중 만들어지는 KV vector를 online으로 압축하는 기술이다.

마지막 결정은 runtime이 한다

Algorithm만 보고 끝내면 안 된다.

Quantized artifact가 있어도 runtime이 그것을 빠른 kernel로 실행하지 못하면 기대한 성능이 안 나온다.

확인 순서:
1. target tensor가 맞는가?
2. FP baseline 대비 quality가 유지되는가?
3. runtime이 quantized operator를 실제로 쓰는가?
4. profiler에서 memory 또는 compute 병목이 줄었는가?

그래서 method selection은 model accuracy 표 하나로 끝나지 않는다. Serving workload, context length, batch/concurrency, execution provider, kernel coverage를 함께 봐야 한다.

확인

GPTQ/AWQ, LLM.int8, TurboQuant는 각각 어떤 tensor를 주로 다루는가?
Activation outlier 문제를 weight-only quantization으로 해결할 수 없는 이유는 무엇인가?
Quantized model 파일이 생겼는데도 실제 속도가 안 나올 수 있는 이유는 무엇인가?