숫자를 줄이기: FP16·BF16·INT8 양자화, 사후 양자화와 양자화 인식 학습, 보정 데이터

상태: 초안 (2026-10-16), 일부 실측. GPU 측정은 집 랩의 8GB급 노트북용 GPU 한 장에서 1회용 파드로 했습니다(예열 뒤 반복 중앙값). 정확도 비교는 공개 데이터셋 OpenTTGames 시험 경기 하나(표식 있는 60fps 프레임 388장)입니다. INT8 은 같은 파드의 CPU(4코어 한도)에서 PyTorch 의 사후 양자화로 했습니다. 형식과 보정의 원리는 노트북 CPU 예제(code/02_quant_error.py, 1초 안팎)로 확인했습니다. 시리즈 「비전 모델 읽기 3」 2편. 지연 예산은 1편에 있습니다.

목차

• 1. 왜 비트를 줄이면 빨라지나
• 2. 16비트 두 가지: FP16 과 BF16
• 3. INT8: 실수를 눈금에 맞추기
  • 눈금을 몇 개 둘까: 텐서 하나 대 채널마다
• 4. 사후 양자화(PTQ)와 보정 데이터
• 5. 양자화 인식 학습(QAT)
• 6. 우리 실측: 공 모델의 FP16
  • 속도
  • 정확도: 공 위치가 바뀌나
• 7. 우리 실측: 공 모델의 INT8 사후 양자화(CPU)
• 8. 한계
• 9. 우리 프로젝트와의 연결
• 참고 문헌

1. 왜 비트를 줄이면 빨라지나

신경망 추론의 시간은 대부분 두 가지입니다. 메모리에서 숫자를 가져오는 시간, 그리고 곱하고 더하는 시간. 숫자 하나를 32비트에서 16비트로 줄이면 가져올 바이트가 절반이 됩니다. 게다가 요즘 GPU 와 휴대폰 칩에는 16비트·8비트 곱셈을 한꺼번에 많이 하는 전용 장치가 있습니다. NVIDIA 의 2018년 세대 GPU 사양으로는 INT8 계산 처리량이 FP32 의 16배, FP16 이 8배입니다(Wu 외 2020, 표 1 — 사양 비율이지 실측이 아닙니다).

대가는 정확도입니다. 숫자를 덜 촘촘하게 적으면 반올림 오차가 생기고, 범위가 좁으면 큰 수가 넘칩니다.

2. 16비트 두 가지: FP16 과 BF16

부동소수는 부호·지수·가수로 나뉩니다. 지수는 「얼마나 크거나 작은 수까지」, 가수는 「얼마나 촘촘하게」 를 정합니다.

(code/02_quant_error.out.txt 의 PyTorch 값.) FP16 은 촘촘하지만 범위가 좁고, BF16 은 FP32 와 범위가 같은 대신 성깁니다. 직접 넣어 보면 70,000 은 FP16 에서 inf, BF16 에서 70,144 가 되고, 1e-8 은 FP16 에서 0, BF16 에서 1.00117e-8 이 됩니다. 256×256 행렬곱의 상대 오차는 FP16 3.6×10⁻⁴, BF16 2.9×10⁻³ 이었습니다.

학습에서는 이 범위 문제가 큽니다. Micikevicius 외의 「Mixed Precision Training」(2018)은 FP16 에서 2⁻²⁴ 보다 작은 기울기가 0 이 되는 문제를 손실에 큰 수를 곱해 두었다 나누는 손실 스케일링으로 풀고, 가중치의 FP32 사본을 따로 두었습니다. 그렇게 하면 ResNet-50 의 ImageNet top-1 이 FP32 75.92 와 혼합 정밀도 76.04 로 같았습니다(표 1). BF16 은 범위가 FP32 와 같아 손실 스케일링 없이 쓸 수 있고, Kalamkar 외(2019)는 ResNet-50 을 BF16 으로 학습해 FP32 와 같은 74.7 을 냈습니다(같은 평가 방식끼리 비교, 4.1.2절).

추론에서는 이미 학습된 가중치를 쓰므로 범위 문제가 덜합니다. 활성값이 65,504 를 넘지 않는 한 FP16 으로 충분한 경우가 많습니다.

3. INT8: 실수를 눈금에 맞추기

8비트 정수는 256개의 칸뿐입니다. Jacob 외(2018)의 아핀 양자화는 실수 r 을 이렇게 적습니다.

r = S · (q − Z)
S: 눈금 한 칸의 크기(실수),  Z: 실수 0 에 해당하는 정수(영점),  q: 0–255 의 정수
범위 [최솟값, 상한] 을 정하면  S = (상한 − 최솟값) / 255,  Z = round(−최솟값 / S)

실수 0 이 정확히 정수 하나로 적히도록 Z 를 두는 것이 요점입니다. 0 으로 채우는 패딩과 ReLU 뒤의 0 이 오차 없이 표현됩니다. 곱셈은 uint8 × uint8 을 int32 로 더한 뒤 마지막에 한 번만 배율을 곱해 다시 8비트로 줄이므로, 추론 전체를 정수로만 할 수 있습니다. 같은 논문은 배치 정규화를 합성곱에 미리 접은(3편) 그래프로 양자화합니다.

같은 33ms 예산 안에서는 INT8 모델이 실수 모델보다 약 10% 더 정확했다는 것이 이 논문의 요지입니다(4.2.1절, 휴대폰의 작은 코어). 정밀도를 낮춰 아낀 시간으로 더 큰 모델을 돌릴 수 있기 때문입니다.

눈금을 몇 개 둘까: 텐서 하나 대 채널마다

가중치 텐서 전체에 S 하나를 쓰면, 한 채널만 값이 커도 눈금이 그 채널에 맞춰 넓어져 나머지가 뭉개집니다. 출력 채널마다 S 를 따로 두면(per-channel) 이 문제가 사라집니다. 직접 해 보니(256×256 행렬곱, 가중치만 INT8)

입니다. 실제 모델에서도 같은 일이 일어납니다. Krishnamoorthi(2018)의 백서에서 MobileNet-v1 을 학습 없이 8비트로 바꾸면 텐서 하나 눈금은 top-1 0.001(완전히 무너짐), 채널마다 눈금은 0.703(실수 0.709)이었습니다(표 3). 깊이별 합성곱(4편)은 채널마다 값의 크기가 크게 달라 이 문제에 특히 약합니다.

4. 사후 양자화(PTQ)와 보정 데이터

사후 양자화는 학습이 끝난 모델에 대표 입력 몇백 장을 흘려 층마다 활성값의 범위를 재고(보정, calibration), 그 범위로 S·Z 를 정합니다. 학습이 필요 없습니다. Nagel 외(2021)의 백서는 라벨 없는 이미지 500–1,000장이면 대개 충분하다고 적었고, 표준 절차를 따르면 W8A8(가중치·활성값 8비트)에서 다룬 모델 모두 FP32 의 0.7% 안이었다고 보고했습니다.

어려운 것은 범위를 어디까지 잡느냐입니다. 최솟값–최댓값을 그대로 쓰면 드문 큰 값 하나 때문에 눈금이 성겨집니다. 위쪽을 조금 잘라(예: 99.99 백분위) 범위를 좁히면 눈금은 촘촘해지지만 잘린 값이 틀립니다. 두 종류의 활성값으로 직접 해 봤습니다(보정 표본과 시험 표본은 따로 뽑음).

• (가) 에서 최솟값–최댓값은 보정 데이터를 늘릴수록 나빠졌습니다. 표본이 많을수록 더 큰 극단값을 만나 범위가 23 → 215 로 커졌기 때문입니다. 99.99 백분위는 표본 수와 상관없이 안정적이었습니다.
• (나) 에서는 반대입니다. 드문 큰 값이 결과를 만드는 경우 그것을 자르면 크게 틀립니다. 언어 모델의 「이상값 특징」 이 그런 경우로, Dettmers 외(2022)는 그 0.1% 의 값을 지우면 모델이 무너지는 것을 보였습니다.

그래서 보정 방법은 모델마다 재 봐야 합니다. Wu 외(2020)의 표에서 EfficientNet-B0 를 PTQ 하면 최솟값–최댓값 22.3%, 엔트로피 72.1%, 99.9 백분위 70.9% 였고(FP32 76.9%), Inception v4 는 최솟값–최댓값 0.1%, 99.99 백분위 79.6%(FP32 79.7%)였습니다(ImageNet top-1, 보정 1,024장, 표 5).

5. 양자화 인식 학습(QAT)

PTQ 로 모자라면 학습할 때부터 양자화를 흉내 냅니다. 순전파에서 가중치와 활성값을 「양자화했다 되돌린」 값(가짜 양자화)으로 계산하고, 역전파는 반올림이 없는 것처럼 기울기를 그대로 흘립니다. 모델이 눈금에 맞춰 가중치를 옮겨 놓도록 배우는 셈입니다. Krishnamoorthi 백서에서 텐서 하나 눈금으로 무너졌던 MobileNet-v1(0.001)이 QAT 로 0.70 까지 돌아왔고(표 4), Wu 외에서 EfficientNet-B0 는 QAT 로 76.95% 가 되어 PTQ 최선(72.1%)을 넘었습니다(원래 학습 일정의 약 10% 만큼 미세 조정, 표 7). 대가는 학습 파이프라인과 데이터가 필요하다는 것입니다.

6. 우리 실측: 공 모델의 FP16

속도

TT Score 의 공 모델(BlurBall, 3프레임 창, 512×288)을 실험용 GPU 에서 쟀습니다(배치 1, 예열 20회 뒤 250회의 중앙값).

같은 GPU 에서 트랜스포머 인코더(EfficientTAM-S, 4편)는 3.1배였습니다. 공 모델은 해상도를 끝까지 유지하는 합성곱 망이라 16비트 전용 장치의 몫이 상대적으로 작고, 배치 정규화·ReLU 같은 원소별 연산이 남아 있어서입니다. 3편에서 이것을 컴파일러로 묶으면 4.3ms 까지 내려갔습니다.

정확도: 공 위치가 바뀌나

OpenTTGames 시험 경기 하나에서 공 위치 표식이 있는 60fps 프레임 388장(모두 공 있음)에 대해, 운영과 같은 방식(마지막 프레임의 히트맵, 문턱 0.5 의 덩어리 찾기)으로 FP32·FP16 을 같은 입력에 돌렸습니다. 정답과 5px(512×288 기준) 안이면 맞힌 것으로 셉니다. 같은 프레임을 JPEG 품질 70 으로 압축했다 푼 입력(브라우저가 보내는 것과 같은 조건)도 FP32 로 돌렸습니다.

FP16 은 이 388장에서 판정을 하나도 바꾸지 않았습니다. 히트맵 값의 차이는 중앙 0.0001 수준이었습니다. 반면 JPEG 압축은 놓친 공을 4개에서 11개로 늘리고, 최댓값 위치를 프레임의 3분의 1 에서 움직였습니다. 정밀도를 반으로 줄이는 것보다 입력을 압축하는 것이 훨씬 큰 오차였습니다. 운영에서는 이미 JPEG 를 받고 있으므로, FP16 을 켜도 지금보다 크게 달라지지 않을 것으로 봅니다. 다만 경기 한 편·조건 하나의 결과이고, 열화 조건(어두움·흐림)과 운영 GPU 에서는 재지 않았습니다(미실측).

7. 우리 실측: 공 모델의 INT8 사후 양자화(CPU)

GPU 의 INT8 은 TensorRT 같은 런타임이 필요해 이번에 재지 못했습니다(3편). 대신 PyTorch 의 사후 양자화(FX 그래프 방식, x86 정수 엔진)로 같은 모델을 CPU 에서 INT8 로 바꿨습니다. 보정 프레임은 경기 앞부분, 평가 프레임은 뒷부분에서 겹치지 않게 골랐습니다.

평가 프레임 220장(공 있음 215), 보정 후보 146장, CPU 4코어 한도, 4장씩 묶어 돌린 창당 시간의 중앙값입니다.

• 보정 프레임이 64장이면 INT8 이 FP32 와 같은 판정 수(맞힘 208)를 냈고, 1장이면 둘을 더 놓쳤습니다. 이 모델은 보정 한 장으로도 무너지지 않을 만큼 순했습니다.
• 히트맵 값의 차이는 FP16(0.001 수준)보다 50배쯤 컸지만, 문턱 0.5 의 판정은 거의 바뀌지 않았습니다. 히트맵의 공 자리 값이 대개 문턱에서 멀기 때문입니다.
• CPU 시간은 FP32 의 약 7분의 1 이었습니다. 다만 이 배수가 모두 8비트 덕이라고 말하기는 어렵습니다. 같은 CPU 에서 FP32 경로가 이 모델(해상도를 끝까지 유지하는 합성곱)에서 유난히 느렸을 수 있고, 그 원인은 따로 확인하지 않았습니다(미실측). 이 차이를 빼더라도 같은 모델이 GPU FP16 에서 10ms 라, CPU INT8 72ms 는 실시간 서버 경로의 대안이 되지 않습니다. 폰 CPU 에서의 값은 재지 않았습니다.

8. 한계

• 정확도 비교는 공개 경기 하나, 옆면 카메라, 깨끗한 조건입니다. 공이 흐리거나 어두운 프레임에서 16비트·8비트 오차가 더 커지는지는 재지 않았습니다.
• 「판정이 같다」 는 문턱 0.5 의 덩어리 찾기 기준입니다. 문턱 근처의 공(신뢰도 0.5 언저리)은 작은 오차에도 판정이 뒤집힐 수 있습니다.
• 논문 수치는 각자의 데이터·하드웨어 결과이고, 그 배수를 우리 모델로 옮길 수 없습니다.

9. 우리 프로젝트와의 연결

• 운영 작업자는 지금 FP32 입니다. 6절의 결과로는 FP16 이 판정을 바꾸지 않으면서 창 하나를 약 35% 줄입니다. 켜기 전에 여러 경기·열화 조건과 운영 GPU 에서 같은 비교를 한 번 더 할 생각입니다.
• 폰으로 옮기는 모델(7편)은 8비트가 기본 선택지가 됩니다. 이때 보정 데이터는 실제 폰 화면(JPEG, 다양한 조명)으로 골라야 합니다. 4절처럼 보정 데이터의 성질이 범위를 정하기 때문입니다.

다음 글은 정밀도는 그대로 두고 실행 방식을 바꾸는 컴파일러와 런타임입니다.

티티 한마디. 숫자를 반으로 줄였는데 공 위치는 그대로였어요. 오히려 사진을 압축할 때 더 흔들렸죠. 어디서 오차가 생기는지 재 보기 전엔 몰라요!

참고 문헌

• Micikevicius, P. et al. (2018). Mixed Precision Training. ICLR 2018. https://arxiv.org/abs/1710.03740
• Kalamkar, D. et al. (2019). A Study of BFLOAT16 for Deep Learning Training. arXiv. https://arxiv.org/abs/1905.12322
• Jacob, B. et al. (2018). Quantization and Training of Neural Networks for Efficient Integer-Arithmetic-Only Inference. CVPR 2018. https://arxiv.org/abs/1712.05877
• Krishnamoorthi, R. (2018). Quantizing deep convolutional networks for efficient inference: A whitepaper. arXiv. https://arxiv.org/abs/1806.08342
• Nagel, M. et al. (2021). A White Paper on Neural Network Quantization. arXiv. https://arxiv.org/abs/2106.08295
• Wu, H. et al. (2020). Integer Quantization for Deep Learning Inference: Principles and Empirical Evaluation. arXiv. https://arxiv.org/abs/2004.09602
• Dettmers, T. et al. (2022). LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale. arXiv. https://arxiv.org/abs/2208.07339
• 공개 데이터: OpenTTGames(CC BY-NC-SA 4.0)
• 예제 코드와 출력: 이 폴더의 code/02_quant_error.py, code/02_quant_error.out.txt