모델 서빙
모델 서빙이란?
- 학습이 끝난 모델을 실제 서비스가 요청해서 쓸 수 있게 API로 오픈한 것
- 서버 프로세스로 띄워두고, REST/gRPC 같은 인터페이스로 요청하면 응답해주는 상태로 만드는 것
왜 필요한가?
- 애플리케이션에서 직접 호출할 수 있어야 함
- 문제 배경
- 앱/웹/백엔드가 “이 입력에 대한 예측 좀 줘” 하고 실시간으로 부를 수 있어야 합니다.
- 학습이 끝난 모델이 .pth, .pb, .onnx 같은 파일 상태로만 존재하면, 실제 웹/모바일 서비스는 이를 직접 사용할 수 없습니다.
- 애플리케이션은 보통 HTTP/REST/gRPC 같은 표준 프로토콜로만 외부 연산을 호출할 수 있습니다.
- 필요성
- 모델을 API 엔드포인트로 노출하면, 여러 서비스(웹 서버, 배치 서버, 사내 업무 시스템, 외부 파트너 시스템)가 공유 자원처럼 같은 모델을 사용할 수 있습니다.
- 기대 효과
- 서비스별 중복 구현 제거
- 모델 변경 시 서비스 코드 변경 최소화
- 모델 호출에 대한 공통 인증/로깅 적용 가능
- 서비스별 중복 구현 제거
- 일관성 있는 배포와 업데이트를 위한 중앙화
- 문제 배경
- 모델을 여러 서버나 애플리케이션에 직접 복사해서 넣는 구조는, 모델이 새로 나올 때마다 모든 배포 대상을 다시 교체해야 합니다.
- 이때 버전 혼재, 롤백 실패, 테스트 누락 같은 문제가 쉽게 발생합니다.
- 필요성
- TensorFlow Serving처럼 버전 기반 로딩(versioned model loading) 을 지원하는 프레임워크는 새로운 모델 디렉터리를 감지해 자동으로 올리고, 이전 버전을 유지하는 식으로 운영 리스크를 줄여줍니다.
- 기대 효과
- 모델 교체 시 서비스 중단 최소화(HOT/WARM swap)
- 테스트 버전과 운영 버전의 명확한 분리
- 운영자가 모델 버전을 서비스 코드와 분리해서 독립적으로 관리
- 성능·확장성(Scalability) 확보
- 문제 배경
- 실제 서비스 트래픽은 시간대/이벤트에 따라 급증할 수 있고, 초당 수십~수천 요청 수준의 동시 추론이 요구될 수 있습니다.
- 모델이 GPU를 사용한다면, GPU 메모리/세션을 어떻게 공유할지에 대한 전략이 필요합니다.
- 필요성
- 서빙 프레임워크는 다음과 같은 성능 기법을 내장하거나 연계합니다.
• 배치 인퍼런스(Batch Inference): 짧은 시간 동안 들어온 여러 요청을 한 번에 묶어 추론 → GPU 활용률 개선
• 멀티 워커/스레드 풀: 동시에 여러 요청 처리
• GPU 핀 고정 / 모델 선로딩: 추론 지연시간(latency) 안정화
• 오토스케일링 연계(Kubernetes/HPA 등): 트래픽에 따라 서빙 인스턴스 수 자동 조절
- 서빙 프레임워크는 다음과 같은 성능 기법을 내장하거나 연계합니다.
- 기대 효과
- 고트래픽 시에도 예측 지연시간을 SLA 안으로 유지
- 동일 하드웨어에서 처리량(QPS) 극대화
- 서비스 피크 시간대 대응 용이
- 고트래픽 시에도 예측 지연시간을 SLA 안으로 유지
- 운영·관측(MLOps) 체계와의 연계
- 문제 배경
- 모델이 프로덕션에 올라가면, 단순히 “추론이 된다”는 것만으로는 충분하지 않습니다.
- 요청 수, 예측 지연시간, 에러율, 어떤 모델 버전이 사용 중인지, 입력 데이터 분포가 학습 때와 달라졌는지(데이터 드리프트) 등을 지속적으로 관측해야 합니다.
- 필요성
- 서빙 레이어는 보통 다음을 제공합니다.
• 메트릭 노출: Prometheus, OpenTelemetry 등으로 수집
• 로그/트레이싱: 어느 요청이 어느 모델 버전을 호출했는지 기록
• 모델 상태 점검 헬스체크: liveness/readiness probe - 이렇게 하면 MLOps 파이프라인(모델 재학습, 성능 저하 감지, 자동 롤백)과 프로그램적으로 연결할 수 있습니다.
- 서빙 레이어는 보통 다음을 제공합니다.
- 기대 효과
- 모델 품질 저하 조기 감지
- 장애 시 원인(특정 모델 버전, 특정 입력 유형) 추적 용이
- 운영팀/데이터팀이 같은 관측 지표를 공유
- 모델 품질 저하 조기 감지
- 다양한 배포 패턴 지원
- 문제 배경
- 실제 서비스에서는 “새 모델을 바로 100% 트래픽으로 교체”하는 것은 위험합니다.
- 모델별로 성능이 입력 도메인에 따라 달라질 수 있어, 점진적·부분적 배포가 필요합니다.
- 실제 서비스에서는 “새 모델을 바로 100% 트래픽으로 교체”하는 것은 위험합니다.
- 필요성
- 서빙 프레임워크는 다음과 같은 배포 전략을 지원하거나, 상위 레이어와 쉽게 연동되도록 설계됩니다.
• A/B Test: 50%는 기존 모델, 50%는 신규 모델
• Canary Release: 1~5%의 소량 트래픽만 신규 모델로 보내서 이상 여부 확인
• Shadow Testing: 실제 응답은 기존 모델로 주되, 동일 요청을 신규 모델에도 보내서 품질을 백그라운드에서 비교
• 롤백: 신규 모델 이상 시, 미리 올라가 있던 이전 버전으로 즉시 복귀 - TensorFlow Serving처럼 모델 버전을 동시에 올려두는 구조는 이런 패턴을 구현하기에 매우 적합합니다.
- 서빙 프레임워크는 다음과 같은 배포 전략을 지원하거나, 상위 레이어와 쉽게 연동되도록 설계됩니다.
- 기대 효과
- 신규 모델 배포 리스크 최소화
- 모델 간 성능 비교의 체계화
- ML 실험 문화와 운영 환경의 간극 축소
개발자