169. 모델 서빙 엔진 (Model Serving Engine) - TensorFlow Serving, NVIDIA Triton

핵심 인사이트 (3줄 요약)

본질: 모델 서빙 엔진 (Model Serving Engine)은 학습된 ML 모델을 REST/gRPC API로 실시간 제공하는 인프라로, TensorFlow Serving과 NVIDIA Triton Inference Server가 각각 단일 프레임워크와 멀티 프레임워크 서빙의 대표 솔루션이다.

가치: 동적 배치 (Dynamic Batching)로 GPU 활용률을 극대화하고, 모델 압축(Quantization)과 TensorRT 변환으로 지연시간을 수십 배 단축하여 대규모 서비스의 SLA를 충족한다.

판단 포인트: GPU 단일 모델에는 TF Serving, 멀티 프레임워크/고성능 GPU 추론에는 Triton, 쿠버네티스 환경의 멀티 프레임워크에는 KServe가 적합하며, 지연시간 vs 처리량 트레이드오프를 비즈니스 SLA에 맞게 튜닝해야 한다.

Ⅰ. 개요 및 필요성

1.1 모델 서빙이란?

**모델 서빙 (Model Serving)**은 학습된 ML 모델을 외부 클라이언트가 API를 통해 실시간으로 예측을 요청할 수 있도록 배포·제공하는 과정이다.

모델 학습 (오프라인)               모델 서빙 (온라인)
┌─────────────────────┐          ┌────────────────────────────┐
│  GPU 클러스터       │          │  서빙 서버                  │
│  데이터 → 학습 →   │ 배포 →   │                            │
│  model.pkl         │          │  클라이언트 요청             │
│  (정적 파일)        │          │  POST /predict             │
└─────────────────────┘          │  {"input": [1.2, 3.4, ...]}│
                                  │         ↓                  │
                                  │  모델 추론 (ms 단위)        │
                                  │         ↓                  │
                                  │  {"prediction": 0.95}      │
                                  └────────────────────────────┘

1.2 모델 서빙의 핵심 성능 지표

지표	설명	기준 값	영향 요소
지연시간 (Latency)	요청~응답 소요 시간	P99 < 100ms	배치 크기, 모델 크기
처리량 (Throughput)	초당 처리 가능 요청 수	QPS (Queries Per Second)	GPU 병렬성, 배치
가용성 (Availability)	서비스 정상 운영 비율	99.9% 이상	복제본, 헬스체크
GPU 활용률	GPU 연산 유닛 사용 비율	70~90% 목표	동적 배치, 최적화

📢 섹션 요약 비유: 모델 서빙은 패스트푸드 주방과 같다. 레시피(모델)를 미리 준비해두고, 주문이 들어오면 즉시 조리해서 내놓는다. 처리량은 분당 버거 생산량, 지연시간은 주문 후 수령까지 시간이다.

Ⅱ. 아키텍처 및 핵심 원리

2.1 TensorFlow Serving

┌──────────────────────────────────────────────────────────────┐
│                  TensorFlow Serving 아키텍처                  │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│  SavedModel 디렉토리 구조                                    │
│  models/                                                     │
│  └── fraud_detection/                                        │
│      ├── 1/  (버전 1)                                        │
│      │   ├── saved_model.pb                                  │
│      │   └── variables/                                      │
│      └── 2/  (버전 2 - 자동으로 최신 버전 서빙)              │
│          ├── saved_model.pb                                  │
│          └── variables/                                      │
│                                                              │
│  TF Serving 서버                                             │
│  ┌────────────────────────────────────────────────────┐     │
│  │  ModelServer                                        │     │
│  │  ├── HTTP/REST 서버 (포트 8501)                     │     │
│  │  ├── gRPC 서버 (포트 8500)                          │     │
│  │  ├── 모델 매니저 (버전 자동 감지)                   │     │
│  │  └── 동적 배치 (Dynamic Batching)                   │     │
│  └────────────────────────────────────────────────────┘     │
└──────────────────────────────────────────────────────────────┘

TF Serving 동적 배치 (Dynamic Batching) 원리

동적 배치 없음:
  요청 1 ──→ GPU 추론 ──→ 응답 1    (GPU 활용률: 낮음)
  요청 2 ──→ GPU 추론 ──→ 응답 2
  요청 3 ──→ GPU 추론 ──→ 응답 3

동적 배치 적용:
  요청 1 ──→ 대기 ─┐
  요청 2 ──→ 대기 ─┼──→ 배치 [1,2,3] ──→ GPU 추론 ──→ 응답 1,2,3
  요청 3 ──→ 대기 ─┘         (GPU 활용률: 높음, 단 지연시간 약간 증가)

설정:
  batch_timeout_micros: 5000  # 최대 5ms 대기
  max_batch_size: 128         # 최대 배치 크기

2.2 NVIDIA Triton Inference Server

┌──────────────────────────────────────────────────────────────┐
│              NVIDIA Triton Inference Server 아키텍처          │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│  클라이언트 요청 (HTTP/gRPC)                                 │
│         │                                                    │
│         ▼                                                    │
│  ┌──────────────────────────────────────────────────┐       │
│  │  Triton Server                                    │       │
│  │                                                   │       │
│  │  모델 저장소 (Model Repository)                   │       │
│  │  ├── TensorFlow SavedModel                       │       │
│  │  ├── PyTorch TorchScript                         │       │
│  │  ├── ONNX                                        │       │
│  │  ├── TensorRT Plan                               │       │
│  │  ├── OpenVINO                                    │       │
│  │  └── Python 커스텀 모델                          │       │
│  │                                                   │       │
│  │  인퍼런스 최적화                                  │       │
│  │  ├── 동적 배치 (Dynamic Batching)                │       │
│  │  ├── 동시 모델 실행 (Concurrent Model Execution) │       │
│  │  ├── 모델 앙상블 파이프라인                       │       │
│  │  └── 비동기 추론                                  │       │
│  └──────────────────────────────────────────────────┘       │
│         │                                                    │
│         ▼                                                    │
│  GPU (NVIDIA A100/H100) / CPU                               │
└──────────────────────────────────────────────────────────────┘

Triton 앙상블 파이프라인 예시

입력 (이미지)
     │
     ▼
┌───────────────┐     ┌───────────────┐     ┌───────────────┐
│  전처리 모델  │────→│  추론 모델    │────→│  후처리 모델  │
│  (Python)     │     │  (TensorRT)   │     │  (Python)     │
└───────────────┘     └───────────────┘     └───────────────┘
                                                    │
                                                    ▼
                                           예측 결과 반환

2.3 TF Serving vs Triton 비교

항목	TensorFlow Serving	NVIDIA Triton
지원 프레임워크	TensorFlow 전용	TF, PyTorch, ONNX, TensorRT, etc.
배포 복잡도	낮음	중간
GPU 최적화	기본	TensorRT 통합, 매우 강력
동적 배치	지원	지원 (더 유연)
앙상블	제한적	완전 지원 (파이프라인)
동시 모델 실행	제한적	완전 지원
메트릭	기본	Prometheus 통합, 상세
적합 상황	TF 단일 모델 서빙	멀티 프레임워크, 고성능

2.4 모델 최적화 기법

Quantization (양자화)

FP32 (32비트 부동소수점) 모델
  가중치: 4 bytes × N개
  정확도: 높음, 속도: 느림

INT8 (8비트 정수) 양자화 후
  가중치: 1 byte × N개
  정확도: 약간 저하 (<1%), 속도: 2~4배 향상
  메모리: 1/4

양자화 방법:
┌────────────────────────────────────────────────────┐
│  PTQ (Post-Training Quantization):                  │
│  학습 완료 후 양자화, 빠르고 간단                  │
│  → 정확도 손실 약간 있음                           │
│                                                    │
│  QAT (Quantization-Aware Training):                │
│  학습 중 양자화 시뮬레이션                         │
│  → 정확도 손실 최소화, 학습 비용 증가              │
└────────────────────────────────────────────────────┘

TensorRT 변환

원본 PyTorch/TF 모델
        │
        ▼
TensorRT 변환 과정:
  1. ONNX 내보내기 (PyTorch → ONNX)
  2. TensorRT 파서로 네트워크 빌드
  3. GPU별 최적화 (Layer Fusion, Kernel Selection)
  4. INT8/FP16 정밀도 최적화
        │
        ▼
TensorRT Plan (.plan)
  - GPU 특화 최적화 완료
  - 처음 빌드 시 수분 소요, 이후 ms 추론
  - 동일 GPU 아키텍처에서만 사용 가능

2.5 서빙 성능 지표 목표값

┌──────────────────────────────────────────────────────────────┐
│                  서빙 SLA 기준 예시                           │
├────────────────┬────────────────────────────────────────────┤
│  서비스 유형   │  목표 지연시간            │  목표 처리량    │
├────────────────┼───────────────────────────┼────────────────┤
│  실시간 추천   │  P99 < 50ms              │  > 10,000 QPS  │
│  사기 탐지     │  P99 < 100ms             │  > 5,000 QPS   │
│  이미지 분류   │  P99 < 200ms             │  > 1,000 QPS   │
│  LLM 생성      │  TTFT < 1s, TPS > 50    │  > 100 QPS     │
└────────────────┴───────────────────────────┴────────────────┘
  TTFT: Time to First Token  TPS: Tokens Per Second

📢 섹션 요약 비유: TF Serving vs Triton 비교는 단일 브랜드 전문점(TF Serving, TF 모델만)과 멀티 브랜드 쇼핑몰(Triton, 모든 프레임워크)의 차이다. 전문점은 해당 브랜드에 최적화됐고, 쇼핑몰은 어떤 브랜드든 모두 팔 수 있다. TensorRT는 GPU에 최적화된 터보 엔진이다.

Ⅲ. 비교 및 연결

3.1 서빙 솔루션 전체 비교

솔루션	특징	강점	적합 환경
TF Serving	TF 전용, 안정적	안정성, 간단한 설정	TF 단일 모델
Triton	멀티 프레임워크, GPU 최적화	고성능, 유연성	멀티 프레임워크, 고성능
KServe	K8s 기반, 멀티 프레임워크	클라우드 네이티브, 카나리	쿠버네티스 환경
TorchServe	PyTorch 전용	PyTorch 네이티브	PyTorch 모델
BentoML	코드 중심, 쉬운 배포	개발자 친화적	프로토타입, 소규모
Ray Serve	분산 Python	유연한 Python 로직	복잡한 서빙 로직

3.2 동적 배치 vs 정적 배치

항목	정적 배치 (Static Batching)	동적 배치 (Dynamic Batching)
배치 구성	고정 크기로 전처리	런타임에 요청 묶음
지연시간	낮음 (즉시 처리)	약간 높음 (대기 시간)
처리량	낮음	높음 (GPU 활용률↑)
복잡도	간단	복잡 (타임아웃 튜닝)
적합 상황	지연시간 SLA 엄격	처리량 중심 서비스

3.3 모델 압축 기법 비교

기법	원리	속도 향상	정확도 손실	구현 난이도
Quantization (INT8)	가중치 비트 수 축소	2~4배	<1%	낮음
Pruning (가지치기)	중요도 낮은 가중치 제거	1.5~3배	1~3%	중간
Knowledge Distillation	큰 모델 → 작은 모델 학습	2~10배	1~5%	높음
TensorRT	GPU 특화 그래프 최적화	3~10배	<0.5%	중간
ONNX 변환	중간 표현으로 최적화	1.5~3배	<0.1%	낮음

📢 섹션 요약 비유: 모델 압축은 짐 줄이기와 같다. Quantization은 짐을 작은 박스로 옮기는 것(용량 감소), Pruning은 불필요한 짐을 버리는 것(모델 경량화), Knowledge Distillation은 베테랑 직원의 노하우를 신입에게 빠르게 전수하는 것(소형 모델이 대형 모델 흉내)이다.

Ⅳ. 실무 적용 및 기술사 판단

4.1 모델 서빙 아키텍처 설계 패턴

┌──────────────────────────────────────────────────────────────┐
│              모델 서빙 아키텍처 패턴 선택                     │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│  단일 모델 서빙                                              │
│  클라이언트 → Load Balancer → TF Serving / TorchServe       │
│                                                              │
│  멀티 모델 서빙 (Triton)                                     │
│  클라이언트 → Triton Server                                  │
│               ├── 모델 A (TensorRT, GPU)                    │
│               ├── 모델 B (ONNX, CPU)                        │
│               └── 모델 C (Python, 후처리)                   │
│                                                              │
│  마이크로서비스 서빙                                         │
│  클라이언트 → API Gateway                                    │
│               ├── 서비스 A → 모델 서버 A                    │
│               ├── 서비스 B → 모델 서버 B                    │
│               └── 서비스 C → 모델 서버 C                    │
└──────────────────────────────────────────────────────────────┘

4.2 기술사 시험 핵심 포인트

Q. 동적 배치(Dynamic Batching)로 GPU 활용률을 향상시키는 원리와 트레이드오프를 설명하시오.

GPU는 병렬 연산에 최적화되어 있어 단일 요청 처리 시 대부분의 연산 유닛이 유휴 상태다. 동적 배치는 일정 시간(batch_timeout) 동안 들어오는 요청을 모아 배치로 처리하여 GPU 병렬성을 극대화한다.

트레이드오프: 배치 타임아웃(수 ms)만큼 지연시간이 증가하지만, GPU 처리량이 수배 향상된다. 지연시간 SLA가 엄격한 서비스(50ms 이하)에서는 타임아웃을 매우 짧게 설정하거나 비활성화해야 한다.

Q. TensorRT 변환의 원리와 GPU 아키텍처 의존성 문제를 설명하시오.

TensorRT는 GPU 특화 딥러닝 추론 최적화 라이브러리다. 변환 시 Layer Fusion(여러 레이어를 하나로 합병), Kernel Auto-Tuning(GPU 아키텍처별 최적 CUDA 커널 선택), 정밀도 최적화(FP16/INT8)를 수행한다. 단, 변환된 .plan 파일은 특정 GPU 아키텍처(SM 버전)에 종속되어, A100용 Plan을 V100에서 실행 불가능하다는 이식성 한계가 있다.

4.3 모델 서빙 최적화 튜닝 가이드

┌──────────────────────────────────────────────────────────────┐
│             모델 서빙 성능 최적화 순서                        │
├──────────────────────────────────────────────────────────────┤
│  Step 1: 베이스라인 측정                                     │
│  └── 현재 P50/P99 지연시간, QPS, GPU 활용률 측정            │
│                                                              │
│  Step 2: 동적 배치 튜닝                                      │
│  └── batch_timeout: 1ms~10ms 범위 실험                      │
│  └── max_batch_size: 16~256 범위 실험                       │
│                                                              │
│  Step 3: 모델 최적화                                         │
│  └── FP16 변환 (정확도 검증 필수)                           │
│  └── TensorRT 변환 (GPU 환경)                               │
│  └── INT8 양자화 (정확도 허용 범위 확인)                    │
│                                                              │
│  Step 4: 인프라 최적화                                       │
│  └── 복제본 수 조정 (HPA)                                   │
│  └── GPU 유형 업그레이드 (A10G → A100)                      │
└──────────────────────────────────────────────────────────────┘

📢 섹션 요약 비유: 모델 서빙 최적화는 요리 경연 속도 올리기와 같다. 동적 배치는 주문 여러 개를 한 번에 몰아서 요리하기, TensorRT는 최신 주방 도구로 업그레이드하기, Quantization은 레시피를 간소화하기(맛은 거의 동일)다. 각 방법을 조합해 최단 시간에 최다 요리를 만든다.

Ⅴ. 기대효과 및 결론

5.1 모델 서빙 최적화 효과

최적화 기법	지연시간 개선	처리량 개선	비용 절감
동적 배치	약간 증가 (타임아웃)	3~5배 향상	GPU 비용 40~60% 절감
TensorRT 변환	3~10배 감소	3~10배 향상	GPU 수 감소
INT8 양자화	2~4배 감소	2~4배 향상	메모리 75% 절감
모델 앙상블 (Triton)	-	전체 파이프라인 최적화	추가 서버 불필요

5.2 결론

모델 서빙 엔진은 ML 시스템의 프로덕션 성능을 결정하는 핵심 인프라다. TensorFlow Serving은 TF 단일 모델 안정 서빙에, NVIDIA Triton은 멀티 프레임워크 고성능 GPU 서빙에 적합하다. 동적 배치와 TensorRT/Quantization 최적화를 조합하면 GPU 비용을 수십~수백% 절감하면서 SLA를 충족할 수 있다.

📢 섹션 요약 비유: 모델 서빙 최적화는 피자 배달 최적화와 같다. 동적 배치는 배달 경로 묶음 배달(한 번에 여러 집), TensorRT는 더 빠른 차량 도입, Quantization은 피자 박스 경량화다. 세 가지를 모두 적용하면 같은 배달원이 더 많은 집에 더 빠르게 배달할 수 있다.

📌 관련 개념 맵

관계	개념	설명
핵심 도구	TensorFlow Serving	TF 단일 프레임워크 서빙
핵심 도구	NVIDIA Triton	멀티 프레임워크 GPU 서빙
최적화	TensorRT	NVIDIA GPU 추론 최적화
최적화	Quantization (양자화)	모델 비트 수 축소
최적화	Dynamic Batching	GPU 활용률 향상
K8s 서빙	KServe	쿠버네티스 기반 멀티 서빙
배포 전략	A/B 테스트	서빙 중 모델 성능 비교
배포 전략	카나리 롤아웃	점진적 트래픽 증가
상위 개념	MLOps	서빙은 MLOps 배포 단계
연관	모델 레지스트리	서빙할 모델 버전 선택

👶 어린이를 위한 3줄 비유 설명

모델 서빙은 배달 음식점 같아요. 주방(학습 서버)에서 만든 레시피(모델)로, 손님(클라이언트)의 주문(API 요청)을 받아 즉시 음식(예측 결과)을 내놓아요.
동적 배치는 버스 시스템과 같아요. 한 명씩 태우면(단건 처리) 비효율적이지만, 몇 분 기다려서 여러 명을 한 버스에 태우면(배치 처리) 연료(GPU)를 훨씬 아낄 수 있어요.
TensorRT는 자동차 엔진 튜닝과 같아요. 같은 자동차(모델)라도 특정 도로(GPU 아키텍처)에 맞게 엔진을 최적화하면 3~10배 빠르게 달릴(추론) 수 있어요.

📈 관련 키워드 및 발전 흐름도

학습된 모델 (.pt / .h5 / .onnx)
    │
    ▼
모델 서빙 엔진
    ├─► TF Serving: TensorFlow 네이티브
    ├─► NVIDIA Triton: 멀티 프레임워크 · 동적 배치
    ├─► TorchServe: PyTorch 네이티브
    └─► KServe: K8s 기반 통합 서빙
    │
    ▼
추론 최적화
    ├─► TensorRT: GPU 커널 융합 · FP16/INT8
    ├─► ONNX Runtime: 크로스 플랫폼
    └─► 동적 배치 (Dynamic Batching): GPU 활용 극대화
    │
    ▼
API 게이트웨이 → REST/gRPC → 클라이언트 응답 (ms 이내)