[패스트캠퍼스 챌린지 18일차] Model Serving 개념

 

AI를 도입하는 회사는 문제 정의부터 모델 학습까지는 무탈하게 진행할 수 있지만, 돈을 벌기 위한 서비스화하는 부분에서 큰 장벽에 부딪히게 됩니다. 여기에 대해서 논의를 해보겠습니다.

 

1. ML Model 서비스화 = Model Serving

"서비스화"는 serving, deployment 등과 같은 의미로 생각하면 됩니다. 사용자가 코드를 직접 보거나 돌려보는 것이 아닌, 사용자가 특정 방식으로 인풋 데이터를 전달해주면 서버에서 Inference를 수행해 Input data의 결과를 "어떠한 방식"으로 전달해주는 것 입니다. 

 

2. 서비스 제공 방식

"어떠한 방식"으로 전달하느냐에 대한 것은 무궁무진한 형태를 뜻합니다. 예시를 적어보면 아래와 같습니다.

- 챗봇과의 대화

- HTTP API Request

- Netflex 영상 좋아요 Button

- Youtube Subscribe Button

- 등등

이와 같이 사용자가 Input data를 어떻게 주는지에 따라 형태도 다양합니다. 또한 전달해주는 주기와 방식도 다양합니다. 일정 크기 또는 일정 기간 동안 Input data를 모았다가 한 번에 보낼 수 있고(예를 들면 일배치성), realtime으로 계속 보낼 수도 있습니다. 

 

3. Serving 단계에서의 허들

- 모델 개발과 소프트웨어 개발의 방법 괴리 : 이 부분은 여기 에서 언급을 하였습니다. 

 

- 모델 개발 과정과 소프트웨어 개발 과정의 파편화 : 모델을 학습하는 사람, 모델을 서빙하는 사람 따로 존재하는 경우가 조직에 많기 때문에, 커뮤니케이션이 많이 발생합니다. 실제로도 겪었던 것은 모델 개발 당시에 일정한 형식으로 package화 되어있지 않아, 서빙하는 사람들 입장에서는 dependency 문제로 스트레스받는 것입니다. 

 

- 모델 평가 방식 및 모니터링 구축의 어려움: 서빙 환경에서 모델이 정상적으로 작동하고 있는지, eval metric 이나 모니터링 시스템이 구축이 안 되는 경우가 존재합니다. 서비스 개발자가 모델에 대한 이해도가 모델 개발자보다 상대적으로 떨어지기 때문에 서비스를 담당했더라도, 서비스가 되고 있는 모델이 테스트 데이터 분포에 변화가 생겨서 모델을 재학습을 해야 하는지 없는지 판단하지 못하는 경우도 생길 수 있습니다. 

 

 

 

 

 

 

 

 

 

 

4. 서빙을 편하게 해주는 Tools

위에 언급한 허들을 어느정도 낮추기 위해서 많은 Tool들이 많이 생겼습니다. 또한 여러 배포 전략(a/b 테스트, 블루 그린, 카나리, 쉐도우 등)을 수행하는 것도 지원해줍니다. 이러한 전략을 달리하면서 배포하는 것이 Framework내에서 수행이 충분히 가능합니다. Tool들을 소개하면 대략 이렇습니다.

- Seldon Core

- TFServing

- KFServing

- Torch Serve

- BentoML

BentoML은 키워드로 많이 들었지만 나머지 부분들은 처음 보는데요, 이러한 서비스 Framework들이 어느 정도 러닝 커브가 요구됩니다. 일단 블로그에 기록하는 것들은 Baseline 서비스 배포 정도 해볼 생각입니다.

 

다음 글에서는 Flask를 조금 찍어먹어 보고 그다음에는 Minikube내에서 Seldon core를 활용해 어떠한 방식으로 서빙하는지 실습을 해보겠습니다. 

 

 

 

 

 

 

 

---

https://bit.ly/37BpXiC

패스트캠퍼스 [직장인 실무교육]

 

* 본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성되었습니다.

 

 

 

 

---