
모델 크기를 4분의 1로 압축해도 성능은 거의 떨어지지 않는다
요약
양자화(Quantization)를 통해 모델 가중치의 크기를 줄임으로써 메모리 대역폭 병목 현상을 해결하고 생성 속도와 처리량을 개선하는 방법을 설명합니다. 모델 크기를 4분의 1로 압축해도 품질 저하는 최소화하면서 비용과 지연 시간을 동시에 낮출 수 있습니다.
핵심 포인트
- LLM 생성 속도의 병목은 연산량이 아닌 메모리 대역폭임
- 양자화는 가중치를 적은 비트로 저장하여 메모리 읽기 속도를 향상함
- 모델 크기 4분의 1 압축 시 생성 시간 단축 및 처리 볼륨 4배 증가 가능
- 양자화 적용 시 품질 저하를 최소화하며 저렴한 GPU 활용 가능
양자화 (Quantization)가 비용과 지연 시간(Latency)을 동시에 낮추는 방법
AI 생성 속도가 느린 이유는 연산(Math)이 무겁기 때문이 아닙니다. **모델의 가중치 (Weights)를 읽어오는 메모리 대역폭 (Memory bandwidth)**이 속도 제한 요소이기 때문입니다.
따라서 가중치를 4분의 1의 공간으로 다시 패킹하면 (양자화하면), 지연 시간과 비용이 동시에 내려갑니다. 측정 결과: 생성 시간 168ms → 95ms, 처리 가능한 볼륨 4배 증가, 품질 -1pt. 속도를 결정하는 것은 파라미터 수(Parameter count)가 아니라 **바이트 수 (Byte count)**입니다.
하지만 주의할 점이 있습니다. 속도 향상은 실제 배포할 것과 동일한 경로로 측정했을 때만 나타나며, 양자화는 미세 조정 (Fine-tuning)을 통해 얻은 이점을 깎아먹습니다. 측정 방법을 일정하게 유지하지 않는다면, 이러한 이득은 환상에 불과하게 됩니다.
Part 5에서 저는 제 GPU에 "양자화 (Quantization)"를 적용했을 때 생성 속도가 168ms에서 95ms로 빨라졌고, 처리 가능한 볼륨이 4배 증가했다고 썼습니다. 저렴한 GPU가 값비싼 데이터 센터급 GPU와 대등한 성능을 내는 것입니다. 그리고 품질은 거의 떨어지지 않습니다.
왜 이렇게 편리한 일이 일어날까요? 여기서 자세히 설명해 보겠습니다.
진짜 병목 현상은 "연산 (Compute)"이 아니라 "메모리 (Memory)"입니다
먼저, LLM이 텍스트를 생성하는 방식입니다. LLM은 한 번에 답변을 내뱉지 않습니다. 단어 (토큰, Tokens)를 하나씩, 순서대로 생성합니다. 매번 확률적인 예측을 수행합니다. 즉, "지금까지의 문맥을 고려할 때, 다음에 올 가장 가능성 높은 단어는 무엇인가?"라고 묻고 단어 하나를 선택합니다. 이 과정을 수십 번 반복하면 문장이 됩니다.
그리고 AI 모델의 실체는 거대한 숫자의 산 (우리는 이를 "가중치 (Weights)"라고 부릅니다)입니다. 단어 하나를 생성할 때마다, GPU는 그 거대한 산 전체를 메모리에서 한 번 읽어와야 합니다. 100단어 문장을 만든다면, 그 산을 100번 다시 읽어야 한다는 뜻입니다.
놀라운 점은 바로 이것입니다. 속도를 제한하는 병목 지점(rate-limiting)은 곱셈 연산의 속도(연산량, compute)가 아닙니다. 바로 **그 산을 메모리에서 읽어오는 속도(메모리 대역폭, memory bandwidth)**입니다. 숫자로 이루어진 산이 커질수록 각 단어를 읽는 데 더 오랜 시간이 걸리고, 생성 속도는 더 느려집니다. GPU의 연산 유닛(compute units)은 대부분의 시간 동안 데이터가 도착하기만을 기다리며 대기하고 있습니다.
따라서 생성 속도를 높이고 싶다면 — 산을 더 작게 만드세요.
양자화 (Quantization) = 숫자를 거칠게 다시 채워 넣기
양자화 (Quantization)는 그 산에 있는 각각의 숫자를 **더 적은 비트 (fewer bits)**로 저장하는 기술입니다. 3.14159…를 3.14로 반올림하는 것과 매우 유사하게, 32비트나 16비트로 보유하던 숫자들을 대신 **4비트 (4 bits)**로 보유하는 것입니다.
그러면 숫자의 산은 원래 크기의 4분의 1 또는 8분의 1로 줄어듭니다.
그림 1: 양자화가 작동하는 이유. 가중치 (weights)의 산을 4분의 1로 줄이면 각 단어를 읽는 속도가 빨라지며, 동시에 처리할 수 있는 용량은 늘어납니다. 속도 제한 요소가 메모리 대역폭 (memory bandwidth)이기 때문에, 지연 시간 (latency)과 비용 (cost)이 함께 감소합니다.
이러한 효과들은 연쇄적으로 일어납니다.
| 양자화 전 | 양자화 후 (INT4) | |
|---|---|---|
| 생성 속도 (연산량, compute) | 168 ms | 95 ms |
| ... |
- 지연 시간 (Latency) 감소: 산이 더 작아졌으므로 각 단어를 읽는 속도가 빨라집니다.
- 비용 (Cost) 감소: 하나의 GPU가 4배 더 많은 용량을 처리할 수 있으므로, 요청당 고정 비용이 4분의 1로 떨어집니다.
- 정확도 (Accuracy) 거의 유지: 숫자를 거칠게 만드는 것이 모델의 답변을 거의 바꾸지 않습니다 (통과율(pass rate) -1 포인트).
사람들은 흔히 "지연 시간과 비용은 보통 트레이드오프 (trade-off) 관계"라고 가정하지만, 양자화는 이 둘을 동시에 낮춰줍니다. 산을 줄이는 것이 속도 향상과 비용 절감이라는 두 가지 결과의 공통된 원인입니다.
(정확히 말하자면: 생성 "속도 (speed)"가 4배가 아닌 1.8배에 그치는 이유는, 바이트 수 (byte count)에 따라 확장되는 것이 가중치 (weights)를 읽는 데 소비되는 시간뿐이기 때문입니다. 연산 자체와 고정된 오버헤드 (overhead)는 그대로 남아 있습니다. 반면, 한 대의 머신이 처리할 수 있는 전체 용량인 처리량 (throughput)은 산의 크기가 1/4로 줄어드는 것에 맞춰 거의 4배로 증가합니다. 따라서 이득은 서로 다른 곳에서 나타납니다: 속도는 1.8배, 용량과 비용은 4배입니다.)
(덧붙이자면: 이는 "지연 시간 (latency)은 가중치의 바이트 수에 의해 결정된다"는 원칙의 이면이기도 합니다. 그렇기 때문에 예를 들어, "강하게 양자화된 더 큰 모델"과 "약하게 양자화된 더 작은 모델"의 바이트 수가 같다면 거의 동일한 속도가 나옵니다. 파라미터 (parameters)가 아니라 바이트 (bytes) 단위로 생각하십시오.)
숫자를 거칠게 만들어도 지능을 잃지 않는 이유
직관에 어긋나 보일 수 있지만, 숫자를 거칠게 (coarsen) 만들어도 정답이 거의 바뀌지 않는 데에는 이유가 있습니다. 모델의 결정 대부분은 여유가 있는 상태에서 이루어지기 때문입니다 (모델이 단어를 선택할 때, 후보들 사이의 확신도 (confidence) 차이가 큽니다). 숫자를 조금 반올림한다고 해서 그 대다수의 결정이 바뀌지는 않습니다.
성능 저하는 애초에 아슬아슬했던 결정에서만 나타납니다. 즉, 10% 미만의 "경계선 (borderline)" 사례에 집중됩니다. 그리고 그 10% 미만은 영향을 받을 수도 있는 집합일 뿐이며, 실제로 정답이 바뀌는 것은 그중에서도 다시 하위 집합입니다. 이것이 평균 품질의 손실이 단지 -1점에 불과한 이유입니다. (그 "경계선" 부분 — 최악의 경우 — 에서 발생하는 성능 저하를 억제하기 위한 추가적인 기법들이 있지만, 그것은 다른 이야기입니다.)
어쨌든, 이 작은 모델이 특정 작업에서 보여주는 "지능 (smarts)"은 미세 조정 (fine-tuning; SFT, CPO)을 통해 구축하는 것이며, 이는 다음 시간에 다루겠습니다. 양자화 (Quantization)는 그렇게 구축된 지능을 거의 깎아내지 않으면서도 빠르고 저렴하게 만드는 기술입니다. 이것이 바로 이 두 가지가 하나의 세트로 작동하는 이유입니다.
잘못하면 이득이 사라집니다
그렇다고 해서 양자화 (Quantization)가 단순히 "적용하면 끝"인 것처럼 간단한 것은 아닙니다. 실제로 저는 두 가지 함정에 빠졌습니다.
- 항상 배포할 환경의 메커니즘을 통해 측정하세요. 양자화의 속도 이점은 전용 고속 실행 경로 (커널 (Kernel))를 통할 때만 나타납니다. 기본 환경에서 측정하면 "속도가 전혀 빨라지지 않는다"라는 잘못된 결론을 내리게 될 것입니다.
- 미세 조정 (Fine-tuning, 다음 편에서 다룸)과 양자화가 어떻게 맞물리는지 관찰하세요. 나중에 설명할 전문화 미세 조정은 모델 전체에 걸쳐 "얇고 넓게" 자리 잡고 있습니다. 공격적인 양자화는 이 부분을 가장 먼저 깎아낼 수 있습니다. 따라서 미세 조정과 양자화는 동일한 조건에서 유지되어야 합니다. 또한, 평가 역시 항상 실제 운영 환경의 양자화 상태에서 이루어져야 합니다.
요약
- 병목 지점은 연산량이 아니라 메모리 대역폭 (Memory Bandwidth)입니다. 생성 지연 시간 (Latency)을 결정하는 것은 거대한 가중치 (Weights) 더미를 얼마나 빨리 읽어낼 수 있느냐입니다. 따라서 속도는 "파라미터 수"가 아니라 **바이트 수 (Byte count)**에 의해 결정됩니다.
- 양자화는 지연 시간과 비용을 동시에 낮춥니다. 가중치 더미를 4분의 1로 줄여도 정확도는 거의 떨어지지 않습니다. 손실은 "경계선"에 있는 결정들에 국한되며, 번역의 근간은 유지됩니다.
- 측정 방법을 일정하게 유지하지 않으면, 이 이득은 환상에 불과합니다. 속도는 배포할 것과 동일한 경로에서만 실현되며, 양자화는 미세 조정으로 얻은 이득을 갉아먹을 수 있습니다. 훈련과 평가를 실제 운영 환경과 동일한 양자화 조건으로 유지하세요.
이제 저의 작은 모델은 빠르고 저렴해졌습니다. 하지만 이것은 작업의 절반일 뿐입니다. 이대로 두면 작은 모델은 상위 모델들에 비해 품질 면에서 뒤처지게 됩니다. 남은 절반인 모델을 똑똑하게 만드는 작업은 다음 편에서 다루겠습니다.
부록: raw data
| 항목 | 측정값 | 조건 및 주의사항 |
|---|---|---|
| INT4 (GPTQ-Marlin, RTX 4090) | 생성 연산 (generation compute) 168→95ms, 디코딩 (decode) 91→166 tok/s, 처리량 (volume handled) 2,200→9,600 req/min (4배) | 품질 (quality) −1pt (base-INT4 vs FP16, n=100) |
| ... | ||
| 원문은 LYR Performance Note #011에 게시되었습니다 — 이는 “Models — smaller, faster, sharper” 시리즈의 일부입니다. 전체 시리즈는 lyr.jp/en/research에서 확인할 수 있습니다. |
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기