성능 보존이 잘된다면 int8, onnx화는 반드시 필요한가?

**"성능(정확도)만 유지된다면, 가볍고 빠른 것(INT8)이 무조건 이득"**인 것이 상용화(Production) 단계의 정석입니다.

 

그렇다면 int8 화를 먼저 진행하고 onnx를 진행하는 경우 모델이 달라지는가에 대한 궁금증이 생겼습니다.

 

1. PTQ: Post-Training Quantization (방금 한 방식)

순서: 학습 완료(FP32) → ONNX 변환(FP32) → 양자화(INT8)

• 방식: "훈련이 다 끝난 뒤(Post)"에 살을 빼는 방식입니다.
• 장점: 가장 쉽고 빠릅니다. 별도의 재학습이 필요 없습니다.
• 단점: 모델이 예민할 경우 정확도가 뚝 떨어질 수 있습니다.
• 현업: 90% 이상의 프로젝트가 이 방식을 먼저 시도합니다. (가성비 최고)

2. QAT: Quantization Aware Training

순서: 학습 도중(INT8인 척 연기) → INT8로 변환 → ONNX 배포

• 방식: 학습할 때부터 "너 나중에 멍청해질(INT8) 거야, 미리 적응해!"라고 가혹하게 훈련시키는 것입니다.
• 장점: PTQ로 했을 때 정확도가 많이 떨어지는 모델도, 이 방식으로 하면 정확도를 거의 완벽하게 보존할 수 있습니다.
• 단점: 코드가 훨씬 복잡하고, 학습 시간이 오래 걸립니다. (PyTorch에서 QuantStub 등을 써서 코드를 뜯어고쳐야 함)

비교: 어느 순서가 좋을까?

"INT8화를 먼저 하고 ONNX로 만드는 것"이 바로 QAT(Quantization Aware Training) 방식에 해당하거나, PyTorch 내부 기능을 이용한 방식입니다.

구분	1. ONNX 가서 줄이기 (PTQ)	2. 줄여서 가져가기 (QAT / PyTorch Native)
난이도	⭐ (아주 쉬움, 코드 몇 줄)	⭐⭐⭐⭐⭐ (어려움, 모델 구조 변경 필요)
정확도	약간 떨어질 수 있음	거의 원본과 동일하게 유지됨
순서	PyTorch -> ONNX -> INT8	PyTorch -> INT8 -> ONNX
추천	대부분의 경우 (1순위)	PTQ로 정확도가 너무 안 나올 때 (2순위)

 

왜 "ONNX 가서 줄이기"를 더 많이 쓸까?

"호환성(Compatibility)" 때문입니다.

1. PyTorch의 INT8: PyTorch 안에서 INT8로 만든 모델은, ONNX로 변환할 때 가끔 **"이 연산은 ONNX가 못 알아듣는데요?"**라며 에러가 날 확률이 높습니다. (Operator Support 문제)
2. ONNX의 INT8: 반면, 일단 FP32로 안전하게 ONNX로 넘겨놓고, **ONNX Runtime(실행기)**이 "내가 제일 잘 아는 방식"으로 깎는 것이 에러도 적고 속도 최적화도 더 잘 되어 있는 경우가 많습니다.