모델 배포 고려사항 (Model Deployment Considerations)¶

개요¶

모델 배포(Model Deployment)는 학습된 모델을 실제 서비스 환경에서 동작하게 만드는 과정이다. 개발 환경에서 뛰어난 성능을 보이는 모델이 프로덕션에서 실패하는 경우가 많으며, 이는 지연시간(latency), 처리량(throughput), 모델 크기, 서빙 인프라, 모니터링 등을 충분히 고려하지 않기 때문이다.

핵심 개념¶

1. 지연시간과 처리량¶

지표	정의	중요한 서비스
Latency	단일 요청 처리 시간	실시간 서비스 (검색, 추천)
Throughput	단위 시간당 처리 요청 수	배치 처리, 대량 분석

Batching: 여러 요청을 묶어 GPU 활용도를 극대화한다. 지연시간과 처리량 간 trade-off가 존재한다.

처리량(Throughput)과 지연시간(Latency)의 정량적 정의는 다음과 같다:

\[\text{Throughput} = \frac{N_{\text{requests}}}{T_{\text{window}}} \quad (\text{requests/sec})\]

\[\text{Latency}_{P99} \leq T_{\text{SLA}}\]

\(N_{\text{requests}}\): 시간 윈도우 내 처리된 요청 수
\(T_{\text{window}}\): 관측 시간 (초)
\(P99\): 99번째 백분위수 지연시간
\(T_{\text{SLA}}\): SLA에서 정의한 최대 허용 지연시간

배치 크기 \(B\)에 따른 trade-off를 정량적으로 표현하면:

\[\text{Latency}(B) \approx t_{\text{wait}}(B) + t_{\text{compute}}(B)\]

\[\text{Throughput}(B) = \frac{B}{t_{\text{compute}}(B)}\]

\(t_{\text{wait}}(B)\)는 배치를 채우기 위한 대기 시간으로 \(B\)가 커질수록 증가하고, \(t_{\text{compute}}(B)\)는 GPU 병렬 처리로 인해 \(B\)에 대해 sub-linear하게 증가한다. 따라서 배치 크기가 커지면 처리량은 증가하지만 지연시간도 증가한다.

2. 모델 압축 (Model Compression)¶

Pruning (가지치기)¶

유형	방법	실질적 속도 향상
Unstructured	개별 가중치(값이 작은 것) 제거	어려움 (sparse 연산 필요)
Structured	전체 필터/채널/층 제거	가능 (표준 연산 유지)

Quantization (양자화)¶

\[W_{int8} = \text{round}\left(\frac{W_{fp32}}{s}\right) + z\]

방법	시점	정밀도	속도 향상
Post-Training (PTQ)	학습 후	약간 감소	2~4배
Quantization-Aware (QAT)	학습 중 시뮬레이션	거의 유지	2~4배

LLM 양자화: GPTQ, AWQ, GGUF 포맷 등이 LLM에 특화된 양자화를 제공한다.

Knowledge Distillation (지식 증류)¶

큰 모델(teacher)의 지식을 작은 모델(student)로 전달한다.

\[L = \alpha L_{hard} + (1-\alpha) T^2 L_{soft}\]

\(L_{hard}\): 정답 라벨과의 손실
\(L_{soft}\): teacher의 soft label과의 손실
\(T\): temperature (높을수록 부드러운 분포)

직관: Teacher의 "어두운 지식(dark knowledge)" — 예를 들어 "이 이미지는 고양이지만, 약간 개와 비슷하다"는 정보가 student에게 전달된다.

3. 서빙 프레임워크¶

프레임워크	특징	사용처
TorchServe	PyTorch 네이티브	일반 모델 서빙
TF Serving	TensorFlow 네이티브, gRPC	대규모 서비스
ONNX Runtime	프레임워크 호환	프레임워크 전환
TensorRT	NVIDIA GPU 최적화	최대 성능 추론
vLLM	PagedAttention, continuous batching	LLM 서빙
Triton Inference Server	멀티 모델, 멀티 프레임워크	복잡한 파이프라인

4. Edge Deployment (엣지 배포)¶

모바일, 임베디드 기기에서의 추론이다.

런타임	플랫폼
TFLite	Android, 임베디드
Core ML	iOS, macOS
ONNX Runtime Mobile	크로스 플랫폼

경량 모델: MobileNet, EfficientNet-Lite, SqueezeNet

엣지 배포 시 모델 크기(Model Size)와 추론 비용(FLOPs) 제약을 정량적으로 고려해야 한다:

\[\text{Model Size (bytes)} = N_{\text{params}} \times B_{\text{precision}}\]

\(N_{\text{params}}\): 전체 파라미터 수
\(B_{\text{precision}}\): 파라미터당 바이트 수 (FP32 = 4, FP16 = 2, INT8 = 1)

예를 들어 MobileNetV2(\(N_{\text{params}} \approx 3.4 \times 10^6\))의 INT8 양자화 모델 크기는 약 \(3.4 \times 10^6 \times 1 = 3.4\text{MB}\)이다.

5. 배포 전략¶

flowchart TD
    A["배포 전략"] --> B["A/B Testing"]
    A --> C["Canary Deployment"]
    A --> D["Shadow Deployment"]
    A --> E["Blue-Green Deployment"]

    B --> B1["기존(A) vs 새 모델(B)<br>동시 서빙, 성능 비교"]
    C --> C1["소수 트래픽에 새 모델<br>문제 없으면 점진적 확대"]
    D --> D1["새 모델 예측을 기록만<br>실제 서비스에는 반영 안 함"]
    E --> E1["두 환경을 전환<br>문제 시 즉시 롤백"]

상세 내용¶

배포 아키텍처¶

graph LR
    Client["클라이언트"] --> LB["로드 밸런서"]
    LB --> API["API 서버"]
    API --> Pre["전처리"]
    Pre --> Model["모델 추론"]
    Model --> Post["후처리"]
    Post --> API

    Model --- Cache["모델 캐시<br>(KV-Cache 등)"]
    Model --- GPU["GPU/CPU"]

    subgraph 모니터링
        Mon["메트릭 수집"]
        Alert["알림 시스템"]
    end

    API --> Mon
    Mon --> Alert

Training-Serving Skew¶

학습 시와 배포 시의 데이터 전처리가 불일치하는 문제이다.

원인: - 학습: Python/pandas 전처리 → 서빙: Java/C++ 전처리 - 학습/서빙에서 다른 라이브러리 버전 - 특성 변환 로직의 미묘한 차이

해결: 전처리 파이프라인을 모델과 함께 직렬화하거나, Feature Store를 사용하여 online/offline 일관성을 보장한다.

언제 사용하는가¶

상황	핵심 고려사항
실시간 서비스	지연시간 최소화, 양자화/pruning
배치 처리	처리량 최대화, batching
모바일/엣지	모델 크기, 경량화
LLM 서빙	KV-Cache, continuous batching, 양자화
A/B Testing 필요	인프라 구축, 통계적 유의성

흔한 오해와 함정¶

"학습 정확도가 높으면 배포해도 된다": 프로덕션에서는 지연시간, 처리량, 메모리, 데이터 drift 등을 모두 고려해야 한다.
Training-Serving Skew 무시: 학습과 서빙의 전처리 차이로 모델 성능이 현저히 다를 수 있다.
모니터링 없이 배포: 모델 성능은 시간이 지남에 따라 저하된다 (data/concept drift). 모니터링이 필수적이다.
롤백 계획 없음: 새 모델이 문제를 일으킬 때 즉시 이전 버전으로 돌아갈 수 있어야 한다.
양자화 후 성능 검증 생략: 양자화가 특정 입력 분포에서 성능을 크게 저하시킬 수 있다. 배포 전 충분한 테스트가 필요하다.

다른 주제와의 연결¶

ML 파이프라인 설계: 배포는 파이프라인의 마지막 단계
실험 추적: Model Registry로 배포 관리
ML 시스템 설계 패턴: A/B Testing, Feature Store
MLOps 기초: CI/CD, 모니터링
전이 학습: PEFT 모델의 효율적 배포
LLM: LLM 추론 최적화