쉽게 이해하기

모델 서빙은 모델을 실제 제품에서 쓸 수 있게 API나 endpoint(호출 주소)로 운영하는 것이다. 노트북에서 모델이 한 번 잘 도는 것과, 수천 명의 사용자가 동시에 요청해도 안정적으로 답하는 것은 다른 문제다. 모델 서빙은 추론, 요청 처리, scaling(확장), monitoring(관측), versioning(버전 관리)을 묶어 서비스로 만든다.

비유와 예시

• 식당 운영: 레시피가 모델이라면, 주문 접수·주방 동선·배달·품질 관리가 model serving이다.
• 챗봇 API: 사용자의 메시지를 받아 LLM inference를 실행하고 streaming으로 답변을 보낸다.
• 이미지 분류 서비스: 업로드된 이미지를 queue에 넣고 batch inference로 처리한다.

한눈에 비교

개념	범위	주요 관심사
Inference	한 요청의 모델 실행	latency, output quality
Model Serving	inference를 서비스로 운영	API, scaling, monitoring
Batch Inference	여러 입력을 묶어 처리	throughput, cost
MLOps	모델 생애주기 전체	data, training, deploy, governance

어디서 왜 중요한가

AI 기능이 제품에 들어가는 순간 model serving 품질이 사용자 경험을 좌우한다. 모델 자체가 좋아도 cold start가 길거나, GPU memory가 부족하거나, version rollback이 안 되면 서비스 장애가 된다. LLM serving에서는 TTFT(첫 token까지 걸리는 시간), streaming, continuous batching, KV cache, rate limit, prompt/token accounting이 특히 중요하다.

자주 하는 오해

• “모델을 Docker로 띄우면 서빙은 끝이다” → autoscaling, health check, observability, rollback이 필요하다.
• “빠른 모델이면 서비스도 빠르다” → queue wait, batching, network, tokenizer, postprocess가 latency를 만든다.
• “GPU 사용률이 높으면 효율적이다” → tail latency와 error rate가 나쁘면 좋은 serving이 아니다.
• “새 모델을 바로 교체하면 된다” → versioning, canary, rollback plan이 필요하다.

대화에서는 이렇게

• “모델 성능은 괜찮은데 serving P99 latency가 SLO를 넘습니다.”
• “batching 정책을 바꾸면 GPU utilization은 오르지만 TTFT가 나빠질 수 있습니다.”
• “새 모델은 canary traffic으로 먼저 serving해보고 rollback 조건을 정합시다.”
• “token usage와 GPU memory를 같이 봐야 cost per request를 알 수 있습니다.”

함께 읽으면 좋은 용어

• Inference: 서빙 시스템 안에서 실제 모델 실행이 일어난다.
• GPU: 대규모 serving의 주요 계산 자원이다.
• KV Cache: LLM serving concurrency와 memory를 좌우한다.
• Quantization: serving 비용과 memory를 줄인다.
• Autoscaling: 요청량에 맞춰 replica와 자원을 조절한다.