심화: 프로덕션 Model Serving 운영
이 섹션에서는 프로덕션 환경에서 Model Serving을 운영할 때 알아야 할 지연시간 특성, 비용 최적화, 배포 전략, 캐싱, 멀티 리전 패턴을 다룹니다.지연시간 특성 (Latency Profile)
Foundation Model API
| 메트릭 | Pay-per-token | Provisioned Throughput |
|---|---|---|
| p50 지연시간 | 200~500ms (짧은 응답) | 100~300ms |
| p99 지연시간 | 1~5초 | 500ms~2초 |
| TTFT (Time to First Token) | 100~300ms | 50~150ms |
| 처리량 | 공유 풀, 변동 가능 | 예약 처리량 보장 |
| 콜드스타트 | 없음 (항상 가동) | 없음 (항상 가동) |
💡 TTFT(Time to First Token) 란 요청 후 첫 번째 토큰이 생성되기까지의 시간입니다. Streaming 응답에서 사용자 체감 속도에 직접 영향을 줍니다.
Custom Model Endpoint
| 상태 | 지연시간 | 설명 |
|---|---|---|
| Warm (Scale > 0) | p50: 10 | 인스턴스가 가동 중 |
| Cold Start (Scale-to-Zero) | 30초~3분 | 컨테이너 시작 + 모델 로딩 + 헬스체크 |
| GPU Cold Start | 1~5분 | GPU 할당 + CUDA 초기화 + 대형 모델 로딩 |
⚠️ Gotcha — Scale-to-Zero 콜드스타트: Scale-to-Zero를 활성화하면 유휴 시 비용을 절약할 수 있지만, 첫 요청 시 30초~수 분의 콜드스타트가 발생합니다. 프로덕션 실시간 서빙에서는 Scale-to-Zero를 비활성화 하는 것이 일반적입니다. 개발/스테이징 환경에서만 활성화하세요.
⚠️ Gotcha — 모델 크기와 콜드스타트: 모델 아티팩트가 클수록(예: PyTorch 모델 5GB+) 콜드스타트 시간이 길어집니다. MLflow 로깅 시 모델을 최적화(ONNX 변환, 양자화)하면 로딩 시간을 단축할 수 있습니다.
비용 최적화 전략
Pay-per-token vs Provisioned Throughput 손익분기점
| 사용 패턴 | 권장 과금 모델 | 이유 |
|---|---|---|
| 프로토타이핑, 불규칙 사용 | Pay-per-token | 사용한 만큼만 과금 |
| 일 1,000건 이하 요청 | Pay-per-token | 고정 비용 대비 사용량 적음 |
| 일 10,000건+ 안정적 트래픽 | Provisioned Throughput | 예측 가능한 비용, 안정적 지연시간 |
| 배치 추론 (대량 처리) | Pay-per-token + Batch Inference | 서빙 엔드포인트 대신 배치 추론 사용 |
Custom Model 비용 최적화
| 최적화 전략 | 절감 효과 | 트레이드오프 |
|---|---|---|
| Scale-to-Zero(dev/staging) | 유휴 시 100% 절감 | 콜드스타트 30초~3분 |
| CPU 사용(전통 ML) | GPU 대비 70~90% 절감 | 딥러닝 모델은 추론 속도 저하 |
| Small 사이즈 | Large 대비 ~75% 절감 | 동시 요청 처리량 감소 |
| 배치 추론 활용 | 서빙 대비 50~80% 절감 | 실시간 응답 불가 |
⚠️ Gotcha — GPU 선택: Custom Model에 GPU를 선택하면 비용이 10배 이상 증가합니다. scikit-learn, XGBoost, LightGBM 등 전통 ML 모델은 CPU로 충분합니다. GPU는 PyTorch/TensorFlow 딥러닝 모델이나 Fine-tuned LLM에만 사용하세요.
프로덕션 배포 패턴
Canary 배포 단계별 가이드
Canary 배포는 새 모델 버전을 소량의 트래픽으로 먼저 검증 한 후, 점진적으로 트래픽을 늘리는 전략입니다.모니터링 기준 (Canary 판단)
| 메트릭 | 정상 범위 | 롤백 기준 |
|---|---|---|
| p99 지연시간 | 기존 버전 대비 ±20% | 50% 이상 증가 |
| 에러율 | < 0.1% | 0.5% 초과 |
| 모델 정확도 | 기존 버전 대비 ±2% | 5% 이상 하락 |
| 메모리 사용량 | 안정적 (증가 추세 없음) | 지속적 증가 (메모리 누수) |
롤백 전략
⚠️ Gotcha — 블루/그린 배포: 블루/그린 방식으로 완전히 새로운 엔드포인트를 생성하여 전환하는 것도 가능하지만, 엔드포인트 URL이 변경 되므로 클라이언트 측 수정이 필요합니다. Traffic Split 방식의 Canary 배포가 더 실용적입니다.
추론 캐싱과 Prompt Caching
AI Gateway Prompt Caching
Foundation Model API와 External Model Endpoint에서 동일한 프롬프트에 대한 응답을 캐싱 하여 비용과 지연시간을 줄일 수 있습니다.| 캐싱 유형 | 설명 | 효과 |
|---|---|---|
| Exact Match Cache | 완전히 동일한 요청에 대해 캐시된 응답 반환 | 지연시간 ~10ms, 토큰 비용 0 |
| KV Cache (Provisioned) | 긴 시스템 프롬프트의 KV Cache를 재사용 | TTFT 50~80% 감소 |
⚠️ Gotcha:temperature > 0이면 동일 입력에도 다른 출력이 나오므로 Exact Match Cache의 효과가 제한적입니다. 캐싱을 적극 활용하려면temperature=0을 사용하세요.
멀티 리전 서빙
대규모 글로벌 서비스에서는 지연시간 최적화와 장애 대응을 위해 멀티 리전 아키텍처를 고려해야 합니다.패턴 1: DNS 기반 지역 라우팅
- 각 리전에 동일한 모델을 배포한 엔드포인트를 운영합니다
- DNS 또는 API Gateway(예: AWS API Gateway, Azure Front Door)로 가까운 리전으로 라우팅합니다
- MLflow Model Registry에서 동일 모델 버전을 관리하여 일관성을 보장합니다
패턴 2: Failover 구성
| 고려 사항 | 설명 |
|---|---|
| 모델 동기화 | 양쪽 리전에 동일 버전의 모델이 배포되어야 합니다 |
| 데이터 일관성 | Feature Store 데이터가 리전 간 동기화되어야 합니다 |
| 비용 | 두 리전 모두 엔드포인트를 유지하므로 비용이 2배 |
| Inference Table | 각 리전별로 별도 Inference Table이 생성됩니다 |
⚠️ Gotcha: Databricks의 Model Serving은 단일 워크스페이스 내에서만 서빙됩니다. 멀티 리전 구성을 위해서는 각 리전에 별도 워크스페이스와 엔드포인트를 구성해야 하며, 모델 배포 파이프라인도 멀티 리전을 지원하도록 설계해야 합니다.
정리
| 엔드포인트 유형 | 용도 | 과금 |
|---|---|---|
| Foundation Model API | Databricks 호스팅 LLM 사용 | Pay-per-token 또는 Provisioned |
| External Model | 외부 LLM (OpenAI 등) 프록시 | 외부 API 비용 + DBU |
| Custom Model | 자체 ML 모델/에이전트 배포 | 엔드포인트 실행 시간 기준 |