Model Serving - 인공지능 > 생성형 AI | AI Insight Note

모델 서빙(Model Serving)은 학습이 완료된 ML/AI 모델을 프로덕션 환경에 배포하여 실시간 또는 배치 추론 요청에 응답하도록 만드는 전 과정이다. 디스크에 저장된 정적 모델 파일과 실제 운영 환경 사이의 다리 역할을 하며, 아무리 정확한 모델이라도 효율적인 서빙 인프라 없이는 실용적 가치를 가질 수 없다.

모델 배포 vs 모델 서빙

개념	범위	설명
모델 배포	상위 개념	모델을 프로덕션에 출시하는 전체 라이프사이클
모델 서빙	배포의 핵심	배포된 모델을 실행하는 구체적 메커니즘
추론(Inference)	수학적 행위	입력값으로부터 예측값을 계산하는 연산 자체

모델 서빙은 추론 인프라(네트워크 인터페이스, 스케일링, 모니터링)를 포함하는 더 넓은 개념이다.

필수 요구사항

•사용자 요청에 대한 즉각적 응답 (낮은 지연 시간)
•다수 사용자 요청의 효율적 동시 처리
•학습 환경과 추론 환경의 명확한 분리
•모델 버전 관리 및 장애 대응 체계

서빙 방식

방식	특징	사용 사례
온라인 서빙	REST API/gRPC 즉각 응답	사용자 대면 웹/앱 서비스
배치 서빙	대량 데이터 오프라인 처리	야간 보고서, 대용량 분석
스트리밍 서빙	점진적 출력 (토큰 단위)	LLM 텍스트 생성
엣지 서빙	기기 내 로컬 추론	모바일, IoT, 프라이버시 중시 앱

핵심 성능 지표

지표	설명	최적화 방향
지연 시간(Latency)	요청 → 응답까지 걸리는 시간	캐싱, 양자화, 배치 최소화
처리량(Throughput)	초당 처리 가능한 요청 수	배치 처리, GPU 병렬화
p99 지연	99번째 백분위 응답 시간	꼬리 지연 분석 및 최적화

통합 아키텍처 설계

실제 프로덕션 환경에서는 여러 계층을 조합한 통합 아키텍처를 구성한다.

UI (Streamlit / React)
    ↓ HTTP 요청
FastAPI  ← 요청 검증, JWT 인증, Rate Limiting, 캐싱
    ↓
Celery + Redis  ← 비동기 큐 처리 (장시간 작업 분리)
    ↓
Triton Inference Server  ← GPU 추론 최적화, 멀티모델 서빙
    ↓
Model Repository  ← 버전 관리, 자동 리로드

계층별 역할

계층	기술	역할
UI	Streamlit, React	사용자 입력 및 결과 표시
API 게이트웨이	FastAPI, Flask	요청 수신·검증·인증·라우팅
비동기 큐	Celery + Redis	장시간 작업 비동기 처리
추론 엔진	Triton, TorchServe, vLLM	모델 로드 및 최적화 추론
리소스 관리	Kubernetes, Ray Serve	GPU/CPU 자원 할당·스케일링
모니터링	Prometheus, Grafana	성능 추적 및 알림
로깅	Loki, OpenTelemetry	요청 트레이싱·에러 모니터링

서빙 아키텍처 패턴

1. 단일 모델 서버

클라이언트 → [로드 밸런서] → [모델 서버 ×N] → 응답

가장 단순한 형태. Kubernetes로 수평 확장.

2. 마이크로서비스 패턴

클라이언트
    ↓
[API Gateway]
    ├── 전처리 서비스
    ├── 모델 추론 서비스  ← 모델 서빙의 핵심
    └── 후처리 서비스

각 서비스를 독립 배포·확장 가능. JSON으로 데이터 교환.

3. 멀티 모델 서버 (Triton)

하나의 서버 인스턴스가 여러 모델을 동시에 호스팅.

[Triton Inference Server]
 ├── model_a (PyTorch)
 ├── model_b (TensorFlow)
 ├── model_c (ONNX)
 └── model_d (TensorRT)

FastAPI로 온라인 서빙 구현

python

from fastapi import FastAPI
from pydantic import BaseModel
import torch

app = FastAPI()

# 서버 시작 시 모델 1회 로드 (요청마다 로드 금지)
model = torch.load("model.pt")
model.eval()

class PredictRequest(BaseModel):
    features: list[float]

class PredictResponse(BaseModel):
    prediction: float
    confidence: float

@app.post("/predict", response_model=PredictResponse)
async def predict(req: PredictRequest):
    with torch.no_grad():
        x = torch.tensor(req.features).unsqueeze(0)
        logits = model(x)
        prob = torch.sigmoid(logits).item()
    return {"prediction": float(prob > 0.5), "confidence": prob}

NVIDIA Triton Inference Server

고성능 멀티 프레임워크 추론 서버. PyTorch, TensorFlow, ONNX, TensorRT, XGBoost를 단일 서버에서 지원한다.

모델 저장소 구조

triton_server/model_repository/
├── summarizer/
│   ├── 1/                ← 버전 번호 디렉토리
│   │   └── model.plan    ← TensorRT 모델
│   └── config.pbtxt      ← 모델 설정
└── classifier/
    ├── 1/
    │   └── model.onnx    ← ONNX 모델
    └── config.pbtxt

버전 번호(1, 2, 3...)로 디렉토리를 구성하면 Triton이 자동으로 인식·로드한다.

config.pbtxt 설정

protobuf

name: "summarizer"
platform: "tensorrt_plan"
max_batch_size: 8

input [
  {
    name: "input_ids"
    data_type: TYPE_INT32
    dims: [ -1 ]        # -1: 동적 크기
  }
]

output [
  {
    name: "output_ids"
    data_type: TYPE_INT32
    dims: [ -1 ]
  }
]

instance_group [
  { kind: KIND_GPU }    # GPU 추론
]

dynamic_batching {
  max_queue_delay_microseconds: 1000  # 1ms 대기 후 배치 처리
}

Triton Python 클라이언트

python

import tritonclient.http as httpclient
import numpy as np

client = httpclient.InferenceServerClient(url="localhost:8000")

# 입력 텐서 준비
input_ids = np.array([[1, 2, 3, 4, 5]], dtype=np.int32)
inputs = [httpclient.InferInput("input_ids", input_ids.shape, "INT32")]
inputs[0].set_data_from_numpy(input_ids)

outputs = [httpclient.InferRequestedOutput("output_ids")]

# 추론 요청
result = client.infer("summarizer", inputs, outputs=outputs)
output = result.as_numpy("output_ids")
print(output)

주요 서빙 프레임워크

프레임워크	특징	적합한 경우
NVIDIA Triton	GPU 최적화, 다중 프레임워크, 동적 배치	고성능 멀티모델 서빙
TorchServe	PyTorch 공식, 멀티 모델	PyTorch 단일 프레임워크
TF Serving	TensorFlow 공식	TensorFlow/Keras 모델
BentoML	Python 친화적, 배포 자동화	빠른 프로토타이핑
vLLM	LLM 전용, PagedAttention	GPT/Llama 계열 서빙
Ray Serve	분산 서빙, 확장성	대규모 클러스터
FastAPI	범용 API 서버	커스텀 서빙 로직

bash

# TorchServe 사용 예
torch-model-archiver --model-name mymodel --version 1.0 \
  --model-file model.py --serialized-file model.pt
torchserve --start --model-store ./model_store --models mymodel=mymodel.mar

# vLLM으로 LLM 서빙
from vllm import LLM, SamplingParams
llm = LLM(model="meta-llama/Llama-3-8B")
outputs = llm.generate(["안녕하세요!"], SamplingParams(max_tokens=200))

모델 최적화 기법

서빙 전 모델을 최적화하면 지연 시간·메모리 사용량을 크게 줄일 수 있다.

기법	설명	효과
모델 양자화	FP32 → INT8/INT4 변환	메모리 50~75% 절감, 속도 향상
ONNX 변환	프레임워크 독립 포맷	크로스 플랫폼 배포, 추론 가속
TensorRT	NVIDIA GPU 최적화 컴파일	GPU 추론 2~5배 가속
지식 증류	큰 모델 → 작은 모델 압축	모델 크기 감소
가지치기(Pruning)	불필요한 가중치 제거	연산량 감소

python

# PyTorch → ONNX 변환
import torch

dummy_input = torch.randn(1, 3, 224, 224)
torch.onnx.export(model, dummy_input, "model.onnx",
                  opset_version=17,
                  input_names=["input"],
                  output_names=["output"],
                  dynamic_axes={"input": {0: "batch_size"}})

동적 배치 처리 (Dynamic Batching)

개별 요청을 즉시 처리하지 않고, 짧은 시간 동안 묶어서 GPU에 한 번에 전달.

t=0ms: 요청A 도착 → 대기
t=5ms: 요청B 도착 → 대기
t=10ms: 배치 타임아웃 → [A, B] 묶어서 GPU 전송
t=12ms: [A, B] 결과 동시 반환

단일 요청 처리 대비 GPU 활용률 수배 향상, 처리량 증가. 지연시간과 처리량 간 트레이드오프 발생.

컨테이너 기반 배포

Docker로 모델과 의존성을 패키징하여 어느 환경에서나 동일하게 실행. FastAPI, Streamlit, Triton을 각각 별도 컨테이너로 구성한다.

dockerfile

FROM pytorch/pytorch:2.3.0-cuda12.1-cudnn8-runtime
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY model.pt .
COPY app.py .
EXPOSE 8000
CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8000"]

Kubernetes + HPA(Horizontal Pod Autoscaler)로 트래픽에 따라 자동 스케일링.

모니터링 및 관측 가능성

도구	역할
Prometheus	응답 지연, GPU 메모리, 요청 수 메트릭 수집
Grafana	실시간 대시보드 시각화
Loki	로그 수집 및 검색
OpenTelemetry	분산 트레이싱, 요청 추적

python

from prometheus_client import Counter, Histogram

REQUEST_COUNT = Counter("model_requests_total", "총 요청 수")
LATENCY = Histogram("model_latency_seconds", "추론 지연 시간")

@app.post("/predict")
async def predict(req: PredictRequest):
    REQUEST_COUNT.inc()
    with LATENCY.time():
        result = model.infer(req.features)
    return result

보안 고려사항

항목	기술	목적
인증	JWT, OAuth 2.0	API 접근 제어
인가	RBAC	권한 수준별 접근
전송 암호화	HTTPS/TLS	데이터 도청 방지
도메인 보호	CORS 설정	허가된 출처만 접근 허용
Rate Limiting	API 게이트웨이	DDoS 및 남용 방지

모델 버전 관리 및 A/B 테스트

트래픽 분할:
  90% → 모델 v1 (현재 운영)
  10% → 모델 v2 (새 버전 테스트)

성능 지표 비교 후 v2가 더 나으면 100% 전환

블루-그린 배포 또는 카나리 배포 전략 활용.

실제 적용 사례

분야	서빙 모델	요구사항
스마트 제조	결함 탐지 비전 모델	실시간 고속 처리, 엣지 서빙
소매 자동화	물체 감지 모델	계산대 상품 자동 인식
의료 진단	의료 영상 분류	높은 정확도, 규정 준수
추천 시스템	랭킹 모델	초저지연 (< 10ms)
챗봇/AI 어시스턴트	LLM	스트리밍, 높은 동시 접속

참고문헌

•Ultralytics. What is Model Serving? (ultralytics.com/glossary)
•Velog @aeeanakb. 모델 서빙과 Triton 기반 추론 서버 통합 설계
•NVIDIA. Triton Inference Server Documentation (docs.nvidia.com/deeplearning/triton-inference-server)
•vLLM. High-throughput and memory-efficient inference engine
•Rao, A. et al. Introducing MLOps (O'Reilly, 2021)

Model Serving모델 서빙