Advanced Quantization

강의의 첫 솔직한 한 마디. “GPU quantization 이 이때까지 없었던 이유는 — quantized GPU 커널이 없었기 때문이다.” CPU 진영에서는 quantization 이 흔했다 (oneDNN, FBGEMM). GPU 에서는 “fp16 이 충분히 빠르니까” 의 분위기. 그 가정이 깨진 게 LLM 시대 — 모델이 GPU 메모리에 안 들어가고, 추론의 bottleneck 이 바뀌었다.

강의가 답하는 세 질문.

1. quantization 이 GPU 위에서 무엇을 푸는가 — bandwidth? compute? 둘 중 어느 쪽이 표적인가.
2. algorithm 과 kernel 의 분업이 어떻게 진화했는가 — 이전엔 “양쪽 다 직접” 이 표준, 이제는 “algorithm Python + kernel torch.compile” 의 분리.
3. CUDA 와 Triton 사이의 결정 — Charles 가 직접 헤맨 자리들에서의 교훈.

quantization 의 motivation 은 두 갈래다 — ① memory 줄이기 (모델이 GPU 에 안 들어가니), ② compute 빠르게 (lower precision = 더 많은 FLOPs/sec, Tensor Core 활용). LLM 추론에서는 거의 항상 ① 이 dominant.

강의에서 Charles 가 짚는 사실 — 대부분의 LLM 추론은 memory-bound. 그래서 이 강의의 본론은 weight-only quant 와 GPTQ. activation quant 는 prefill 가속이나 batch 가 큰 경우에만.

강의의 가장 인상적인 한 줄. “dynamic quantization 의 모든 quant 부분을 그냥 Python 으로 짜고, torch.compile 이 알아서 다 한다.” 결과 — Triton 도 안 써도 되고, CUDA 도 안 써도 된다. 한 PyTorch 함수가 통째로 inductor 의 표적.

# dynamic quant 의 핵심 — Python 그대로
def dynamic_quantize_linear(x, weight_int8, weight_scale):
    # activation 의 동적 범위로 scale 계산 (Python pointwise)
    x_max = x.abs().amax(dim=-1, keepdim=True)
    x_scale = x_max / 127.0
    x_int8 = (x / x_scale).round().to(torch.int8)

    # int8 matmul (Tensor Core int8 로 lower 됨)
    out_int32 = torch._int_mm(x_int8, weight_int8)

    # dequantize
    return out_int32.to(torch.float16) * x_scale * weight_scale

# 한 줄 추가로 fast
fast = torch.compile(dynamic_quantize_linear)

강의에서 Charles 가 직접 제시한 시간 — fast 한 GPU 위에서 ~150 token/s (정확한 숫자는 변동, 본문에서 “limited GPU” 라 명시). 같은 알고리즘을 fp16 baseline 과 비교해 약 2–3× 가속.

메모리 줄이기가 표적인 케이스. weight 만 int8 (또는 int4) 로 저장, activation 은 fp16 그대로. matmul 시점에 weight 를 dequantize 해서 fp16 matmul. 가속의 비결은 — HBM 에서 weight 를 절반/1/4 만 읽기.

이 패턴의 핵심 디테일 — per-channel quantization. 한 weight matrix 를 한 scale 로 quantize 하면 어떤 channel 의 큰 값이 작은 channel 의 정밀도를 망친다. 그래서 each output channel 에 한 scale (즉 한 column 의 fp16 vector) 를 저장.

메모리를 더 줄이는 다음 단계가 int4. byte 안에 두 element 를 packing. 이 packing 의 layout 과 dequantize 가 까다로워 — int8 의 “Python 으로 그대로” 패턴이 그대로는 안 된다. tinygemm 같은 전용 CUDA 커널이 필요.

int4 quant 의 핵심 디테일 — group quantization. 한 row 또는 column 안에서도 element 들을 group 으로 묶고 group 마다 별도 scale. group_size = 32, 64, 128 가 흔함. 작을수록 정확하지만 scale buffer 가 커진다.

# int4 의 packing layout (단순화)
# 한 byte 가 두 int4 를 들고 있음
packed_byte = (high_4bit << 4) | (low_4bit & 0x0F)

# tinygemm 의 dequant — bit 연산 + scale
high = (packed_byte >> 4) - 8           # signed [-8, 7]
low  = (packed_byte & 0x0F) - 8
val_high = high.to(fp16) * scales[group_h]
val_low  = low.to(fp16)  * scales[group_l]

GPTQ 는 “weight 를 한 row 씩 양자화하면서 다음 row 가 quantization error 를 보정” 하는 알고리즘. 이미 auto-gptq 같은 library 가 있다. 그런데 Charles 와 팀이 직접 다시 구현한 이유 — auto-gptq 의 weight layout 이 자기 quant kernel (tinygemm 등) 과 맞지 않았다.

이 일화의 메시지는 미묘하다.

• algorithm 과 kernel 사이의 layout 계약 — quantization 알고리즘이 weight 를 어떤 모양으로 저장하는가가 그 다음 kernel 의 가능성을 정한다.
• “model agnostic” — auto-gptq 는 특정 모델 (GPT-2/GPT-J 등) 에 맞춰져 있어, 임의의 PyTorch model 에 일반적으로 적용하기 어려웠다.
• algorithm 자체는 Python 으로 다시 짤 수 있다 — quant 의 정확도 부분은 결국 작은 행렬 산술. CUDA 가 필요한 건 그 결과로 얻은 weight 의 fast matmul.

강의의 가장 실전적인 부분. Charles 가 quant 일을 하면서 어디에서 어떤 도구를 썼는지의 직접적인 회고.

강의에서 Charles 가 직접 디버깅 한 일화. quant Triton 커널이 어떤 사이즈에서 너무 빠르게 도는데, 다른 사이즈에서 갑자기 느려졌다. 원인 추적 — block_size 가 모델의 hidden dimension 을 limit 하고 있었다.

이 사실을 풀어 보면.

• Triton 의 BLOCK_SIZE 가 작으면 — SM 당 block 수가 많아 occupancy 가 좋다, 하지만 register 사용이 작아 ILP (instruction-level parallelism) 가 부족.
• BLOCK_SIZE 가 크면 — register reuse 가 좋아 빠르지만, 어떤 hidden dim 에서는 마지막 block 이 비거나 한 SM 에 한 block 만 실행 가능 (occupancy ↓).
• 최적 BLOCK_SIZE 가 모델 사이즈에 의존 — 한 set 의 BLOCK_SIZE 로 모든 모델을 cover 할 수 없다. autotune 이 답.

강의 후반의 sober 한 메시지. weight-only int8 quant 만 하면 거의 정확도 손실 없음 — 그런데 conv, layernorm, embedding 등을 모두 quantize 하면 정확도가 떨어지는 일이 흔하다. production 까지 가려면 per-layer sensitivity 와 경우에 따라 QAT (quantization-aware training) 가 필요.

• per-layer sensitivity — 어떤 layer 가 quantization 에 민감한가의 측정. 한 layer 만 quantize 한 채 모델을 돌리고 정확도 측정 → 가장 둔감한 layer 부터.
• QAT — 학습 중에 fake quantize → dequantize 의 round 를 끼워넣어 모델이 quant 를 알고 학습. 학습 비용이 추가.
• SmoothQuant / AWQ — activation outlier 를 weight 로 옮기는 reparametrization. 정확도와 가속을 모두 잡는 알고리즘.

이 강의의 마지막 톤은 — “quantization 은 algorithm 과 systems 의 양쪽 영역. algorithm 이 정확도를 결정하고, systems 가 속도를 결정한다. 둘 다 손에 잡고 있어야 한다.” 이게 GPU Mode 에서 다음 quant 강의들 (L034 Low-bit Triton, AWQ 강의 등) 의 reading frame.

quant 의 dtype 사다리, algorithm/kernel 분리, CUDA/Triton 갈림길의 핵심.

손에 새기기 — 실습 시퀀스

1. fp16 baseline — 작은 LLM (GPT-2 small 또는 LLaMA-1B) 의 한 forward 시간 측정. tokens/sec 기록.
2. dynamic quant 적용 — 강의의 Python 코드 그대로. torch.compile wrap. 시간 비교 — baseline 대비 가속률.
3. weight-only int8 — torchao 의 quantize_(model, int8_weight_only) 또는 직접 구현. 정확도 (perplexity 또는 다른 metric) 가 baseline 과 거의 같은지 검증.
4. int4 group quant — torchao 의 int4_weight_only. group_size sweep (32, 64, 128) 으로 정확도 vs 가속의 trade-off 측정.
5. BLOCK_SIZE sweep — Triton quant 커널의 BLOCK_SIZE 를 변화시키면서 시간. 최적값이 모델 hidden dim 에 어떻게 의존하는가.
6. per-layer sensitivity — 한 layer 만 fp16 으로 두고 나머지 quantize. 어느 layer 가 가장 민감한가 (보통 첫 layer 와 마지막 layer).
7. chrome trace 비교 — fp16, int8 weight-only, int4 의 각 forward 의 trace 를 비교. matmul 막대의 두께와 메모리 트래픽 차이.
8. 한 페이지 plan — 자기가 다루는 모델의 추론 latency 를 줄이려면 어떤 quant 가 답인지 — bound, 정확도 요구, 모델 사이즈를 기반으로 한 페이지로.

algorithm/kernel 분리, CUDA/Triton/compile 갈림길의 단어들이 이후 GPU Mode quant 강의들의 기본 어휘.

강의에서 흐릿하게 지나간 자리들과, 자기 환경에서 직접 봐야 할 사실들.

• 정확한 가속 수치 — 강의에서 “limited GPU 에서 ~150 token/s” 같은 정성적 표현. 자기 GPU 에서 fp16 vs int8 vs int4 의 token/sec 를 직접 측정. (확인 필요)
• tinygemm 의 내부 — 강의에서 “전용 CUDA kernel” 이라고만. 정확한 layout (group_size, packing 순서) 와 PTX 수준의 instruction 사용은 별도 추적.
• Triton vs CUDA 의 정확한 격차 — Charles 가 “거의 같다” 고 했지만 정확한 비율은 강의에서 안 다룸. matmul / quant / attention 별로 다를 가능성.
• per-layer sensitivity 의 자동화 — 강의에서 일부 언급. 실제 sensitivity scan 의 표준 도구가 무엇인가? L034 또는 별도 quant 강의.
• SmoothQuant / AWQ / GPTQ 의 정확도 vs 가속 비교 — 강의에서 GPTQ 만 본격 다룸. 다른 algorithm 들의 trade-off 는 후속 강의의 영역.
• activation quantization 의 fp8 옵션 — Hopper (H100) 의 fp8 Tensor Core. int8 대신 fp8 의 production 사용은 강의 시점 (2024-02) 이후 본격화.
• QLoRA 와의 관계 — fine-tuning 시점의 quant 가 강의의 표적이 아님. PEFT 영역에서 별도.