심화: 프로덕션 Model Serving 운영
이 섹션에서는 프로덕션 환경에서 Model Serving을 운영할 때 알아야 할 지연시간 특성, 비용 최적화, 배포 전략, 캐싱, 멀티 리전 패턴을 다룹니다.지연시간 특성 (Latency Profile)
Foundation Model API
💡 TTFT(Time to First Token) 란 요청 후 첫 번째 토큰이 생성되기까지의 시간입니다. Streaming 응답에서 사용자 체감 속도에 직접 영향을 줍니다.
Custom Model Endpoint
⚠️ Gotcha — Scale-to-Zero 콜드스타트: Scale-to-Zero를 활성화하면 유휴 시 비용을 절약할 수 있지만, 첫 요청 시 30초~수 분의 콜드스타트가 발생합니다. 프로덕션 실시간 서빙에서는 Scale-to-Zero를 비활성화 하는 것이 일반적입니다. 개발/스테이징 환경에서만 활성화하세요.
⚠️ Gotcha — 모델 크기와 콜드스타트: 모델 아티팩트가 클수록(예: PyTorch 모델 5GB+) 콜드스타트 시간이 길어집니다. MLflow 로깅 시 모델을 최적화(ONNX 변환, 양자화)하면 로딩 시간을 단축할 수 있습니다.
비용 최적화 전략
Pay-per-token vs Provisioned Throughput 손익분기점
Custom Model 비용 최적화
⚠️ Gotcha — GPU 선택: Custom Model에 GPU를 선택하면 비용이 10배 이상 증가합니다. scikit-learn, XGBoost, LightGBM 등 전통 ML 모델은 CPU로 충분합니다. GPU는 PyTorch/TensorFlow 딥러닝 모델이나 Fine-tuned LLM에만 사용하세요.
프로덕션 배포 패턴
Canary 배포 단계별 가이드
Canary 배포는 새 모델 버전을 소량의 트래픽으로 먼저 검증 한 후, 점진적으로 트래픽을 늘리는 전략입니다.모니터링 기준 (Canary 판단)
롤백 전략
⚠️ Gotcha — 블루/그린 배포: 블루/그린 방식으로 완전히 새로운 엔드포인트를 생성하여 전환하는 것도 가능하지만, 엔드포인트 URL이 변경 되므로 클라이언트 측 수정이 필요합니다. Traffic Split 방식의 Canary 배포가 더 실용적입니다.
추론 캐싱과 Prompt Caching
AI Gateway Prompt Caching
Foundation Model API와 External Model Endpoint에서 동일한 프롬프트에 대한 응답을 캐싱 하여 비용과 지연시간을 줄일 수 있습니다.⚠️ Gotcha:temperature > 0이면 동일 입력에도 다른 출력이 나오므로 Exact Match Cache의 효과가 제한적입니다. 캐싱을 적극 활용하려면temperature=0을 사용하세요.
멀티 리전 서빙
대규모 글로벌 서비스에서는 지연시간 최적화와 장애 대응을 위해 멀티 리전 아키텍처를 고려해야 합니다.패턴 1: DNS 기반 지역 라우팅
- 각 리전에 동일한 모델을 배포한 엔드포인트를 운영합니다
- DNS 또는 API Gateway(예: AWS API Gateway, Azure Front Door)로 가까운 리전으로 라우팅합니다
- MLflow Model Registry에서 동일 모델 버전을 관리하여 일관성을 보장합니다
패턴 2: Failover 구성
⚠️ Gotcha: Databricks의 Model Serving은 단일 워크스페이스 내에서만 서빙됩니다. 멀티 리전 구성을 위해서는 각 리전에 별도 워크스페이스와 엔드포인트를 구성해야 하며, 모델 배포 파이프라인도 멀티 리전을 지원하도록 설계해야 합니다.