학습이 끝난 모델을 실제 서비스에 붙이는 순간, 완전히 새로운 문제가 펼쳐집니다. 밀리초 단위 지연, 트래픽 폭증, GPU 비용. 모델 서빙 인프라는 이 세 압력을 어떻게 균형 있게 떠받칠 것인가의 문제이며, 정답은 워크로드 특성에 따라 달라집니다.
운영 문제: 추론은 학습과 다른 짐승이다
학습은 처리량(throughput) 싸움이지만 온라인 추론은 지연(latency) 싸움입니다. 사용자는 200ms 안에 응답을 기대하는데, 모델은 무겁고 GPU는 비쌉니다. 게다가 트래픽은 시간대마다 출렁여, 고정 GPU 풀은 피크엔 부족하고 평상시엔 낭비됩니다.
서빙 아키텍처 비교
| 방식 | 지연 | 비용 효율 | 적합 상황 |
|---|---|---|---|
| 실시간 온라인 | 매우 낮음 | 낮음 | 대화형·추천 |
| 동적 배치 | 중간 | 높음 | 고처리량 추론 |
| 오프라인 배치 | 해당 없음 | 매우 높음 | 주기적 대량 예측 |
핵심 기법은 동적 배치(dynamic batching)입니다. 짧은 시간 창(예: 10ms) 동안 들어온 요청을 묶어 한 번에 GPU로 처리하면, 약간의 지연을 감수하는 대신 처리량을 몇 배로 끌어올려 GPU 효율을 극적으로 높일 수 있습니다.
구현: 확장과 콜드 스타트
GPU 파드는 모델 로딩에 수십 초가 걸려 콜드 스타트가 길고, 그래서 0으로 줄였다 다시 띄우는 전략은 지연 민감 서비스에 위험합니다. 최소 레플리카를 유지하되 트래픽 기반으로 확장하는 절충이 필요합니다.
autoscaling:
minReplicas: 2 # 콜드 스타트 회피용 상시 풀
maxReplicas: 20
targetConcurrency: 8 # 레플리카당 동시 요청 목표
scaleDownDelay: 600s # 트래픽 출렁임에도 안정 유지모니터링과 비용
서빙 인프라의 건강은 p95/p99 지연, GPU 활용률, 배치 점유율로 봅니다. GPU 활용률이 30% 아래로 머문다면 동적 배치나 모델 경량화(양자화)로 더 적은 GPU에 더 많은 트래픽을 태울 여지가 큽니다. 양자화만으로도 지연을 유지하며 GPU 수를 절반으로 줄인 사례가 많습니다.
정리
모델 서빙에 만능 아키텍처는 없습니다. 지연이 생명인 대화형 서비스, 처리량이 중요한 대량 추론, 비용이 최우선인 배치 작업은 각기 다른 답을 요구합니다. 워크로드의 지연·비용·확장성 요구를 먼저 정의하고, 그에 맞는 서빙 전략과 오토스케일링을 짝지으십시오.
