프로덕션 양자화 — AWQ, GPTQ, GGUF, FP8, NVFP4

양자화 형식(quantization format)은 누구에게나 통하는 보편적인 선택이 아닙니다. 어떤 하드웨어를 쓰는지, 어떤 서빙 엔진(serving engine) 위에서 돌리는지, 어떤 워크로드(workload)를 받는지에 따라 결정되는 함수에 가깝습니다. CPU와 엣지(edge) 환경에서는 GGUF Q4_K_M 또는 Q5_K_M이 사실상 표준이며, llama.cpp와 Ollama를 통해 배포됩니다. 같은 베이스 모델 위에 여러 LoRA를 동시에 올려야 하는 멀티 LoRA(multi-LoRA) 상황에서는 vLLM 안에서 GPTQ가 가장 강력합니다. Marlin-AWQ 커널을 쓰는 AWQ는 7B급 모델에서 약 741 tok/s를 내고, INT4 계열 형식 중 Pass@1이 가장 높습니다. 이 조합이 2026년 데이터센터 프로덕션의 기본값입니다. FP8은 Hopper, Ada, Blackwell에서 안전한 중간지대로, 거의 무손실에 가깝고 지원 범위도 넓습니다. NVFP4와 MXFP4(Blackwell의 마이크로스케일링(microscaling) FP4)는 더 공격적인 선택지이지만, 블록(block) 단위로 품질 검증을 반드시 거쳐야 합니다. 현장 팀이 자주 빠지는 함정은 두 가지입니다. 첫째, 보정 데이터셋(calibration dataset)은 실제 배포 도메인(deployment domain)과 일치해야 합니다. 둘째, KV 캐시(KV cache)는 가중치 양자화(weight quantization)와 완전히 별개의 비용입니다. AWQ를 쓰면서 "내 모델이 이제 4GB가 됐다"고 말하는 순간, 프로덕션 배치 크기에서 10-30GB로 부풀어 오르는 KV 캐시를 잊어버리는 셈입니다.

유형: Learn 언어: Python(표준 라이브러리, 형식별 메모리와 처리량(throughput)을 비교하는 장난감 계산기) 선수 지식: Phase 10 · 13(양자화 기초, Quantization foundations), Phase 17 · 04(vLLM Serving Internals) 예상 시간: 약 75분

학습 목표

• 2026년 기준 프로덕션 양자화 형식 여섯 가지와 각각의 강점 영역(sweet spot)을 말할 수 있습니다.
• 하드웨어(CPU 대 GPU, Hopper 대 Blackwell), 엔진(vLLM, TRT-LLM, llama.cpp), 워크로드(일반 대화, 추론(reasoning), 멀티 LoRA)가 주어졌을 때 적절한 형식을 고를 수 있습니다.
• 선택한 형식에 대해 줄어드는 가중치 메모리와, 그대로 남는 KV 캐시를 직접 계산할 수 있습니다.
• 도메인 트래픽에서 양자화 모델의 품질을 떨어뜨리는 보정 데이터셋 함정(calibration-dataset pitfall)을 설명할 수 있습니다.

문제

양자화는 메모리와 HBM 대역폭(bandwidth)을 줄여 줍니다. 디코드(decode)가 필요로 하는 것이 바로 그것입니다. FP16 70B 모델은 가중치만으로 140GB를 차지합니다. 가중치를 INT4(AWQ 또는 GPTQ)로 양자화하면 모델 크기는 35GB까지 떨어지고, KV 캐시를 둘 공간까지 확보한 채로 H100 하나에 올릴 수 있습니다. 동시 시퀀스 128개와 2k 컨텍스트(context) 조건에서는 KV 캐시만 20-30GB에 달하기 때문에, 이렇게 확보된 여유 공간이 결정적으로 중요합니다.

다만 양자화는 공짜가 아닙니다. 공격적인 양자화는 특히 추론 비중이 큰(reasoning-heavy) 작업에서 품질을 떨어뜨립니다. 형식마다 동작하는 엔진이 다르고, 하드웨어마다 네이티브(native)로 지원하는 정밀도(precision)도 다릅니다. 2026년의 양자화 형식 동물원(format zoo)은 실제로 그만큼 다양하기 때문에, 다른 팀의 선택을 그대로 복사할 수는 없습니다. 결국 자기 스택을 기준으로 직접 고를 줄 알아야 합니다.

개념

여섯 가지 형식

GGUF — CPU/엣지 기본값

GGUF는 엄밀히 말해 양자화 기법이 아니라 파일 형식(file format)입니다. 하나의 컨테이너 안에 K-quant 계열 변종, 즉 Q2_K, Q3_K_M, Q4_K_M, Q5_K_M, Q6_K, Q8_0을 함께 담아 두는 구조입니다. 그중 Q4_K_M과 Q5_K_M이 프로덕션 기본값으로, 4-5비트 수준에서 BF16에 가까운 품질을 제공합니다. CPU나 엣지에서 서빙해야 한다면 사실상 최선의 선택입니다. llama.cpp가 CPU 추론 엔진 중에서는 압도적으로 빠르기 때문입니다.

대신 vLLM 위에서 GGUF를 돌리면 7B 기준 약 93 tok/s 수준으로 처리량이 크게 떨어집니다. GGUF는 애초에 GPU 커널(kernel)에 맞춰 최적화된 형식이 아니기 때문입니다. 배포 대상이 CPU나 엣지일 때만 GGUF를 선택하시고, 그 외 환경에서는 다른 형식을 쓰시기 바랍니다.

GPTQ — vLLM 안의 멀티 LoRA

GPTQ는 보정(calibration) 단계를 거치는 학습 후 양자화(post-training quantization) 알고리즘입니다. Marlin 커널 덕분에 GPU에서 매우 빠르게 동작하며, Marlin을 쓰지 않은 GPTQ 대비 약 2.6배 처리량 향상을 보입니다. 7B 모델에서 약 712 tok/s 정도가 나옵니다.

GPTQ만의 강점은 GPTQ-Int4가 vLLM에서 LoRA 어댑터(adapter)를 지원한다는 점입니다. 베이스 모델 하나에 10-50개 정도의 파인튜닝(fine-tuning) 변종을 각각 LoRA로 붙여 서빙해야 한다면, GPTQ가 가장 자연스러운 경로입니다. 2026년 초 기준으로 NVFP4는 아직 LoRA를 지원하지 않습니다.

AWQ — 데이터센터 GPU 기본값

AWQ는 활성값을 고려한 가중치 양자화(Activation-aware Weight Quantization)입니다. 양자화 과정에서 전체 가중치 중 약 1%에 해당하는 가장 중요한(salient) 가중치를 따로 보호합니다. Marlin-AWQ 커널은 단순 구현 대비 약 10.9배의 처리량 향상을 보이며, 7B에서 약 741 tok/s, INT4 계열 형식 중 가장 높은 Pass@1을 기록합니다.

새로 시작하는 GPU 서빙이라면, 멀티 LoRA(GPTQ)나 공격적인 Blackwell FP4(NVFP4)가 꼭 필요하지 않은 한 AWQ를 고르시는 것이 좋습니다.

FP8 — 신뢰할 수 있는 중간지대

FP8은 8비트 부동소수점(floating point)입니다. 거의 무손실에 가깝고, 지원 범위가 넓으며, Hopper 텐서 코어(Tensor Core)에서 네이티브로 가속됩니다. Blackwell도 이 가속을 그대로 이어받습니다. 품질을 절대로 양보할 수 없는 워크로드, 예를 들어 추론, 의료, 코드 생성(code generation) 같은 영역에서는 FP8이 2026년의 안전한 기본값입니다. 메모리 절감 폭은 INT4의 절반 수준이지만, 품질을 잃을 위험은 훨씬 낮습니다.

MXFP4 / NVFP4 — Blackwell의 공격적 선택지

마이크로스케일링 FP4입니다. 가중치를 작은 블록으로 나누고 블록마다 자체 스케일 팩터(scale factor)를 갖도록 합니다. 매우 공격적인 양자화이지만, Blackwell 텐서 코어에서 하드웨어 가속(hardware-accelerated)을 받기 때문에 실용적입니다. 토큰당 바이트(byte) 수를 FP8 대비 절반으로 줄여 줍니다. Phase 17 · 07에서 다뤘던 경제성 이득이 바로 여기서 나옵니다.

주의할 점:

• 2026년 초 기준으로 아직 LoRA를 지원하지 않습니다.
• 추론 비중이 큰 워크로드에서는 품질 저하가 눈에 띄게 나타납니다.
• 모델별로 평가 세트(eval set)에서 직접 검증해야 합니다.

보정 함정(calibration trap)

AWQ와 GPTQ는 보정 데이터셋이 반드시 필요하며, 보통 C4나 WikiText를 사용합니다. 그런데 코드, 의료, 법률처럼 특정 도메인에 특화된 모델을 일반 웹 텍스트로 보정하면, 알고리즘이 "어떤 가중치를 보호해야 하는가"에 대해 잘못된 결정을 내립니다. 이렇게 되면 HumanEval의 Pass@1이 몇 점 단위로 떨어질 수 있습니다.

해결책은 도메인 내(in-domain) 데이터로 보정하는 것입니다. 보통은 도메인 샘플 수백 개 정도면 충분합니다. 배포 전에는 반드시 평가 세트에서 검증한 다음 출시하세요.

KV 캐시 함정(KV cache trap)

AWQ는 가중치를 4비트로 줄이지만, KV 캐시는 별도 자원이며 여전히 FP16/FP8에 머물러 있습니다. 70B 모델에 AWQ를 적용한 예를 들면 다음과 같습니다.

• 가중치(Weights): 약 35GB(원래 140GB에서 INT4로 줄어든 값).
• 동시 시퀀스 128개 × 2k 컨텍스트의 KV 캐시: 약 20GB.
• 활성값(Activations): 약 5GB.
• 합계: 약 60GB로, H100 80GB 한 장에 들어갑니다.

"모델을 4GB로 양자화했다"는 식의 단순한 표현은 나머지 30-50GB를 잊은 말입니다. HBM은 항상 전체적으로 묶어서 예산을 잡아야 합니다.

이와 별도로 KV 캐시 자체를 양자화하는 선택, 예를 들어 FP8 KV나 INT8 KV는 가중치 양자화와는 완전히 다른 의사결정입니다. 어텐션 정확도(attention accuracy)에 직접적으로 영향을 주며, 결코 공짜로 얻는 이득이 아닙니다.

AWQ INT4는 추론 작업에 위험합니다

생각의 사슬(chain-of-thought), 수학, 긴 컨텍스트 위에서 동작하는 코드 생성 같은 작업은 공격적인 양자화의 영향을 눈에 띄게 받습니다. AWQ INT4는 MATH 벤치마크에서 약 3-5점의 손실을 보입니다. 추론 비중이 큰 워크로드라면 FP8 또는 BF16으로 배포하고, 그만큼의 메모리 비용을 받아들이시는 편이 안전합니다.

2026년 선택 가이드

• CPU/엣지 서빙: GGUF Q4_K_M. 더 고민할 필요 없습니다.
• GPU 서빙, 일반 대화, LoRA 불필요: AWQ.
• GPU 서빙, 멀티 LoRA: GPTQ + Marlin.
• 추론 워크로드: FP8.
• Blackwell 데이터센터, 품질이 이미 검증된 경우: NVFP4 + FP8 KV.
• 판단이 애매하면: 후보 형식마다 1,000개 샘플 규모의 평가를 돌려 보십시오.

사용해보기

code/main.py는 여러 모델 크기에 대해 여섯 가지 형식의 메모리 구성(가중치 + KV + 활성값)과 상대 처리량을 함께 계산해 줍니다. 어느 지점에서 KV 캐시가 지배적인 비용이 되는지, 가중치 압축이 어디서 이득을 만들어 내는지, 그리고 FP8이 어디서 안전한 선택지가 되는지를 한눈에 보여 줍니다.

산출물 만들기

이 강의는 outputs/skill-quantization-picker.md를 만들어 냅니다. 하드웨어, 모델 크기, 워크로드 유형, 품질 허용 범위(quality tolerance)가 주어지면, 적절한 양자화 형식을 고르고 그에 맞는 보정/검증 계획(calibration/validation plan)을 함께 산출합니다.

연습문제

1. 쉬움: code/main.py를 실행해 보세요. 70B 모델, 동시 시퀀스 128, 2k 컨텍스트 조건에서 각 형식의 총 HBM 사용량을 계산해 보세요. 어떤 형식이 H100 80GB 한 장에 들어가나요?
2. 중간: 7B 코딩 모델이 하나 있다고 가정해 보세요. 형식을 하나 고르고 근거를 설명해 보세요. 품질 허용 범위 판단이 틀린 것으로 드러났다면, 복구 경로(recovery path)는 무엇인가요?
3. 중간: 의료 도메인 모델에 AWQ를 적용하려면 보정 데이터셋의 규모를 어떻게 잡아야 할까요? 데이터가 많다고 항상 좋은 것은 아닌 이유는 무엇인가요?
4. 어려움: Marlin-AWQ 커널 논문 또는 릴리스 노트(release notes)를 읽어 보세요. 일반 GPTQ가 약 712 tok/s에 머무르는 반면 AWQ는 7B에서 741 tok/s를 내는 이유를 세 문장으로 설명해 보세요.
5. 어려움: AWQ 가중치와 FP8 KV 캐시를 함께 쓰는 구성이 합리적인 상황은 언제이며, 반대로 KV를 BF16에 그대로 두어야 하는 상황은 언제인가요?

핵심 용어

더 읽을거리

• VRLA Tech — LLM Quantization 2026 — 형식별 벤치마크 비교입니다.
• Jarvis Labs — vLLM Quantization Complete Guide — 형식별 처리량 수치를 정리해 둔 글입니다.
• PremAI — GGUF vs AWQ vs GPTQ vs bitsandbytes 2026 — 형식별 선택 기준을 안내합니다.
• vLLM docs — Quantization — vLLM이 지원하는 형식과 플래그(flag)를 확인할 수 있습니다.
• AWQ paper (arXiv:2306.00978) — 최초의 AWQ 정식화 논문입니다.
• GPTQ paper (arXiv:2210.17323) — 최초의 GPTQ 정식화 논문입니다.