딥러닝 모델 서비스 A-Z 1편: 연산 최적화 및 모델 경량화

대형 딥러닝 모델을 비용과 응답 시간 제약 안에서 서비스하기 위한 선택지를 정리한다. CPU와 GPU 인스턴스의 비용·확장성 차이부터 MKL-DNN·TensorRT·TensorFlow Serving, Python 병목, OpenMP 설정, AWS Inferentia, pruning·quantization·distillation까지 이어진다. 단일 추론 속도만 보지 않고 클라우드 배포 가능성과 운영 비용을 함께 비교하는 것이 핵심이다.

핵심 포인트

CPU는 저렴하고 scale out과 배포가 쉽지만 단일 추론이 느리고, GPU는 빠르지만 비싸고 인스턴스 조합과 관리형 서비스 지원이 제한적이다.
CPU의 MKL-DNN과 GPU의 TensorRT는 행렬 연산과 layer fusion을 활용해 같은 모델의 inference를 최적화한다.
CPython의 GIL과 GC가 throughput과 tail latency 병목이 될 수 있어 TensorFlow Serving이나 TorchScript·libTorch 같은 비-Python 서빙 경로를 검토한다.
OpenMP와 TBB 관련 thread affinity·blocktime 환경 변수를 조정하는 것만으로 팀 환경에서 10~15% 성능 향상을 얻었다.
모델 경량화는 중요하지 않은 가중치를 제거하는 pruning, 정밀도를 낮추는 quantization, 작은 student를 학습하는 distillation로 구분한다.

상세 정리

서비스 문제: Transformer 이후 모델 파라미터는 빠르게 늘지만 컴퓨팅 자원은 같은 속도로 증가하지 않는다. 운영에서는 연산을 더 빠르게 하거나 실행할 연산 자체를 줄여야 한다.
CPU 선택: CPU 인스턴스는 가격이 낮고 vCPU와 메모리 조합이 다양해 scale up과 scale out이 쉽다. 컨테이너와 관리형 플랫폼에서도 제약이 적다.
GPU 선택: GPU는 단일 inference가 빨라 응답 시간이 중요한 서비스에 유리하다. 그러나 가장 작은 인스턴스도 비싸고 CPU·메모리·GPU 비율을 독립적으로 조정하기 어렵다.
당시 비용 비교: AWS g4dn.xlarge는 4vCPU, 16GiB, GPU 1개에 시간당 0.647달러였고 비슷한 CPU 구성의 t3a.xlarge는 0.1872달러였다.
배포 제약: 글 작성 당시 ECS Fargate는 GPU를 지원하지 않았다. 모델 성능뿐 아니라 선택한 런타임과 리전에서 GPU 워크로드를 배포할 수 있는지 확인해야 한다.
MKL-DNN: Intel의 딥러닝 연산 라이브러리로 TensorFlow와 PyTorch의 CPU inference를 가속한다. 프레임워크 패키지가 해당 라이브러리 지원으로 빌드됐는지 확인해야 한다.
TensorRT: NVIDIA GPU 추론 SDK는 convolution, bias, ReLU 같은 연속 layer를 하나의 연산으로 합쳐 중간 데이터 이동과 kernel 실행을 줄인다.
Python 병목: GIL은 multi-threading을 제한하고 GC는 간헐적으로 응답 시간을 튀게 한다. Flask 같은 Python 웹 서버가 모델 연산 외의 병목이 될 수 있다.
서빙 경로: TensorFlow는 TensorFlow Serving을, PyTorch는 TorchScript와 libTorch를 사용해 C++ 런타임에서 실행할 수 있다. 팀은 PyTorch로 학습한 모델을 TensorFlow 2.0으로 변환해 gRPC·Protocol Buffers 기반 Serving을 사용했다.
Thread 설정: 코어와 소켓 수로 `OMP_NUM_THREADS`를 정하고 `KMP_AFFINITY=granularity=fine,compact,1,0`, `KMP_BLOCKTIME=1`을 적용해 10~15% 개선을 얻었다. 최적값은 모델과 환경별로 재측정해야 한다.
전용 가속기: EC2 Inf1은 AWS Inferentia와 Neuron SDK로 TensorFlow·PyTorch 모델을 컴파일한다. 내부 실험에서 이득이 있었지만 당시 서울 리전 미지원과 최신 프레임워크 호환성 때문에 도입하지 못했다.
Pruning과 quantization: pruning은 영향이 작은 부분을 제거하고 quantization은 FP32보다 낮은 정밀도로 계산량과 메모리를 줄인다. TensorRT와 APEX 같은 도구를 사용할 수 있다.
도구 호환성: 당시 APEX는 PyTorch 1.3.1, CUDA 10.1 일치와 특정 pip 버전 회피가 필요했다. 경량화 기법보다 라이브러리·CUDA 버전 조합이 실제 도입을 막을 수 있음을 보여준다.
Distillation: 큰 teacher의 지식을 작은 student에 전달해 처음부터 더 작은 모델을 학습한다. pruning·quantization과 달리 별도 학습 과정이 필요하다.