◆ Q & A 요약
Q1. 모델 서빙이란 무엇이며, 왜 필요한가요? 실제 서비스 환경에서 서빙 프레임워크가 어떤 역할을 하나요?
A1. 모델 서빙은 학습이 완료된 AI 모델을 실제 사용자가 접근할 수 있도록 API 형태로 배포하는 과정이다. 이를 통해 모델의 예측 기능을 비즈니스 가치로 연결하고, 대규모 요청을 자동화하여 실시간으로 처리할 수 있다. 서빙 프레임워크는 고성능 추론을 위한 동적 배치, 여러 모델 버전 관리, 안정적인 자원 할당과 모니터링 등을 수행하며 확장성 높은 운영을 지원하는 핵심 역할을 담당한다.
Q2. Streamlit, FastAPI로 구성된 시스템에 Triton 기반 추론 서버를 통합하려면 어떤 구조로 설계하는 것이 바람직하다고 생각하나요?
A2. 3-Tier 아키텍처 설계가 가장 바람직하다. 이 구조에서 Streamlit은 사용자 인터페이스(Presentation), FastAPI는 API 게이트웨이 및 데이터 전후처리(Logic), Triton은 실제 모델 추론(Inference)만을 전담한다. 이 분리 구조는 추론 병목 현상 발생 시 Triton만 독립적으로 확장하는 등 유연성을 높이고, 시스템 전체의 안정성과 유지보수 효율을 극대화한다.
1. 모델 서빙이란 무엇이며, 왜 필요한가요? 실제 서비스 환경에서 서빙 프레임워크가 어떤 역할을 하나요?
(1) 모델 서빙의 정의
A. 모델 서빙이란?
- 학습이 완료된 머신러닝 모델을 프로덕션(실제 서비스) 환경에 배포하는 과정
- 최종 사용자, 애플리케이션, 다른 시스템이 모델의 예측 기능을 사용할 수 있도록 만드는 것
- 머신러닝 모델 개발 생명주기(MLOps)의 마지막 단계에 해당
B. 주요 목표
- 정적인 모델 파일(예:
.pt,.h5)을 동적인 예측 서비스로 전환 - 외부에서 요청하고 응답받을 수 있는 안정적인 API 엔드포인트를 제공
- 낮은 지연 시간(Low Latency)과 높은 처리량(High Throughput)을 보장
| 구분 | 개발 환경 | 서빙 환경 |
|---|---|---|
| 주요 목적 | 모델 학습 및 평가 | 모델 예측 기능 제공 |
| 사용자 | 데이터 과학자, ML 엔지니어 | 최종 사용자, 외부 시스템 |
| 데이터 | 정적인 학습/테스트 데이터셋 | 실시간으로 발생하는 불특정 데이터 |
| 핵심 요구사항 | 높은 정확도, 성능 | 안정성, 확장성, 빠른 응답 속도 |
(2) 모델 서빙의 필요성
A. 모델의 가치 실현
- 모델은 실제 서비스에 적용되어야 비로소 비즈니스 가치를 창출
- 개발자의 컴퓨터에만 존재하는 모델은 단순한 결과물에 불과
- 모델의 예측 능력을 실제 문제 해결에 연결하는 유일한 방법
B. 자동화 및 효율성 증대
- 인간의 판단이 필요했던 의사결정 과정을 자동화
- 다른 시스템이 프로그래밍 방식으로 모델 예측을 활용 가능하게 함
- 수작업 대비 대규모 요청을 빠르고 일관성 있게 처리하여 효율 극대화
C. 확장성과 안정성 확보
- 다수의 사용자가 동시에 서비스를 사용해도 끊김 없는 환경 제공
- 트래픽 양에 따라 유연하게 시스템 자원을 확장(Scale-out)
- 24시간 365일 무중단 서비스를 위한 고가용성(High Availability) 보장
(수동 예측과 모델 서빙 비교)
| 항목 | 수동 예측 | 모델 서빙 |
|---|---|---|
| 요청 처리 | 비동기적, 수작업 | 실시간, 자동화 |
| 처리 속도 | 느림, 비일관적 | 빠름, 일관적 |
| 동시성 | 불가능 | 대규모 동시 요청 처리 가능 |
| 확장성 | 없음 | 트래픽에 따라 유연하게 확장 |
| 가용성 | 사람이 일할 때만 가능 | 24/7 무중단 운영 |
(3) 서빙 프레임워크의 역할
A. 핵심 기능
- API 엔드포인트 생성: 외부 시스템과 통신할 수 있는 창구(REST, gRPC) 제공
- 요청/응답 처리: 들어온 요청을 모델이 이해하는 형식으로 변환하고, 모델 결과를 다시 사용자 친화적 형식으로 변환
- 모델 생명주기 관리: 메모리에 모델을 로드하고, 필요 시 언로드하는 등 생명주기를 관리
- 자원 관리: CPU, GPU, 메모리 등 하드웨어 자원을 효율적으로 할당하고 사용
B. 고급 기능
- 성능 최적화: 여러 요청을 묶어 한 번에 처리(배치)하여 GPU 효율을 극대화
- 동시성 및 확장성: 여러 모델을 동시에 실행하거나, 단일 모델의 여러 복사본을 실행하여 처리량 증대
- 모델 버전 관리: 여러 버전의 모델을 배포하여 A/B 테스트나 점진적 출시(Canary)를 지원하며, 문제 발생 시 즉시 롤백 가능
- 모니터링 및 로깅: 모델의 상태, 요청량, 응답 시간, 자원 사용량 등 지표를 수집하여 서비스 상태를 파악
| 역할 분류 | 주요 기능 | 설명 |
|---|---|---|
| 기본 인프라 | API 서버, 자원 관리 | 모델이 외부와 통신하고 하드웨어에서 동작할 기반 제공 |
| 성능 가속화 | 동적 배치, 동시 실행 | 모델 추론 속도를 높이고 처리량을 극대화 |
| 운영 효율화 | 버전 관리, 모니터링 | 안정적인 서비스 운영과 유지보수를 용이하게 함 |
2. Streamlit, FastAPI로 구성된 시스템에 Triton 기반 추론 서버를 통합하려면 어떤 구조로 설계하는 것이 바람직하다고 생각하나요?
(1) 3-Tier 아키텍처의 개념
A. 아키텍처 정의
- 전체 시스템을 기능적으로 독립적인 3개의 계층으로 분리하는 설계 방식
- 각 계층은 각자의 역할에만 집중하여 결합도(Coupling)를 낮추고 응집도(Cohesion)를 높임
- Presentation Tier: 사용자에게 보여지는 UI 영역
- Logic Tier: 비즈니스 로직, 데이터 가공을 처리하는 영역
- Inference Tier: 실제 모델 추론이 일어나는 고성능 계산 영역
B. 각 컴포넌트의 역할 매핑
- Streamlit (Presentation Tier): 사용자와의 직접적인 상호작용 담당, 사용자의 입력을 받아 Logic Tier로 전달하고 결과를 시각화
- FastAPI (Logic Tier): 프론트엔드와 추론 서버 사이의 게이트웨이, 데이터 유효성 검사, 모델 입력에 맞춘 전처리 및 후처리, 비즈니스 로직 수행
- Triton (Inference Tier): 모델 추론만을 전문적으로 담당, Logic Tier로부터 받은 데이터를 모델에 입력하고 결과를 반환하는 역할에 집중
(아키텍처 계층별 역할)
| 계층 (Tier) | 담당 컴포넌트 | 주요 역할 |
|---|---|---|
| Presentation | Streamlit | UI/UX, 사용자 입력 및 결과 표시 |
| Logic | FastAPI | API 게이트웨이, 비즈니스 로직, 데이터 전/후처리 |
| Inference | Triton | 고성능 모델 추론, GPU 자원 관리 |
(2) 데이터 흐름 및 상호작용
A. 요청(Request) 흐름
- ① 사용자 → Streamlit: 사용자가 웹 UI에서 텍스트 입력, 이미지 업로드 등 행동 수행
- ② Streamlit → FastAPI: Streamlit이 사용자 데이터를 HTTP 요청에 담아 FastAPI 서버로 전송
- ③ FastAPI (전처리): FastAPI가 요청을 받아 데이터 형식을 검증하고, Triton의 모델이 요구하는 텐서(Tensor) 형태로 데이터를 가공(전처리)
- ④ FastAPI → Triton: FastAPI가 Triton 클라이언트를 이용해 전처리된 데이터를 gRPC 또는 HTTP 요청으로 Triton 추론 서버에 전송
- ⑤ Triton (추론): Triton이 요청을 받아 지정된 모델과 버전으로 추론을 실행
B. 응답(Response) 흐름
- ⑥ Triton → FastAPI: Triton이 모델의 원시(Raw) 출력값(예: 로짓, 벡터)을 FastAPI로 반환
- ⑦ FastAPI (후처리): FastAPI가 원시 출력값을 해석하여 사용자에게 의미 있는 정보(예: 클래스 이름, 문장)로 가공(후처리)
- ⑧ FastAPI → Streamlit: FastAPI가 최종 결과를 HTTP 응답으로 Streamlit에 전달
- ⑨ Streamlit → 사용자: Streamlit이 받은 결과를 UI에 맞게 렌더링하여 사용자에게 보여줌
import requests
import torch
import json
import numpy as np
# 1. FastAPI가 사용자로부터 받은 데이터를 PyTorch 텐서로 변환 (전처리)
# 예시: (1, 3, 224, 224) 크기의 이미지 텐서
input_tensor = torch.randn(1, 3, 224, 224)
# 2. Triton의 HTTP/REST API 형식에 맞게 JSON 페이로드 생성
# Triton은 특정 JSON 구조를 요구함
payload = {
"inputs": [
{
"name": "IMAGE_INPUT", # Triton 모델 설정에 정의된 입력 이름
"shape": list(input_tensor.shape),
"datatype": "FP32",
"data": input_tensor.numpy().tolist()
}
]
}
# 3. FastAPI 서버에서 Triton 서버의 추론 엔드포인트로 POST 요청 전송
triton_url = "http://localhost:8000/v2/models/my_image_model/infer"
response = requests.post(triton_url, data=json.dumps(payload))
# 4. Triton으로부터 받은 응답 처리 (후처리)
if response.status_code == 200:
result = response.json()
# 'outputs' 필드에서 결과 데이터를 추출하여 후처리 로직 수행
output_data = result['outputs'][0]['data']
print("Inference successful:", output_data)
else:
print("Inference failed:", response.text)(3) 아키텍처 설계의 장점
A. 관심사의 분리 (Separation of Concerns)
- 각 컴포넌트가 UI, 로직, 추론이라는 명확하고 단일한 책임만 가짐
- 특정 계층의 코드를 수정해도 다른 계층에 미치는 영향이 최소화되어 유지보수가 용이
- 코드의 가독성과 재사용성이 향상됨
B. 독립적인 확장성 (Independent Scalability)
- 추론 부하가 높을 경우 Triton 서버와 GPU만 증설 가능
- API 요청이 많을 경우 FastAPI 서버의 인스턴스만 증설 가능
- 각 계층의 부하 특성에 맞게 자원을 할당하여 비용 효율적인 확장이 가능
C. 성능 및 안정성
- 모델 추론은 C++로 작성된 고성능 전용 서버 Triton이 담당하므로 Python 기반 서버보다 훨씬 빠름
- 특정 계층의 장애가 다른 계층으로 전파되는 것을 막아 전체 시스템의 안정성을 높임 (예: Triton 서버가 다운되어도 UI는 정상적으로 보일 수 있음)
- 각 계층에 특화된 최적화 전략(예: DB 캐싱, GPU 최적화)을 적용하기 용이
| 장점 | 설명 | 기대 효과 |
|---|---|---|
| 유연성/유지보수성 | 각 계층이 느슨하게 결합(Loosely Coupled) | 신규 기능 추가, 기술 스택 변경이 용이 |
| 확장성 | 부하가 발생하는 특정 계층만 독립적으로 확장 | 비용 효율적이고 신속한 스케일링 가능 |
| 성능 | 각 역할에 가장 최적화된 도구(Triton)를 사용 | 전체 시스템의 응답 속도 및 처리량 향상 |
| 안정성/팀워크 | 장애 격리 및 병렬 개발 용이 | 서비스 안정성 증대 및 팀 개발 효율 향상 |
◆ 해설
1. 모델 서빙이란 무엇이며, 왜 필요한가요? 실제 서비스 환경에서 서빙 프레임워크가 어떤 역할을 하나요?
Streamlit, FastAPI, 그리고 Nvidia Triton Inference Server를 통합하여 AI 모델 서빙 시스템을 구성할 때는 각 구성 요소의 역할을 명확히 분리하고, 통신 구조를 효율적으로 설계하는 것이 중요합니다. 바람직한 설계 방식은 다음과 같이 세 가지 계층으로 나누어 생각할 수 있습니다.
GURU
첫 번째 계층은 사용자 인터페이스 계층으로, Streamlit이 담당합니다. 이 계층에서는 사용자로부터 입력을 받고 결과를 시각적으로 제공하는 역할을 합니다. 예를 들어, 이미지를 업로드하거나 텍스트를 입력하고, 그 결과를 그래프나 표로 출력하는 작업이 이곳에서 수행됩니다. Streamlit은 인터랙티브한 프론트엔드 역할에 집중하며, 복잡한 비즈니스 로직은 다음 계층에 위임합니다.
두 번째 계층은 애플리케이션 로직 계층으로, FastAPI가 중심입니다. 이 계층에서는 사용자 입력을 받아 전처리하고, Triton 서버에 추론 요청을 보낸 뒤, 응답을 받아 후처리하는 과정을 담당합니다. 즉, FastAPI는 Streamlit과 Triton 사이의 중간 허브 역할을 하며, 다양한 모델 요청을 통합하고 API 구조를 체계화하여 확장성과 유지보수성을 높입니다.
세 번째 계층은 모델 추론 계층으로, Nvidia Triton Inference Server가 담당합니다. Triton은 사전 학습된 모델을 고속으로 추론하기 위한 최적화된 서버이며, TensorFlow, PyTorch, ONNX 등 다양한 프레임워크 기반 모델을 동시에 운영할 수 있습니다. FastAPI는 Triton의 REST API 또는 gRPC 인터페이스를 통해 모델에 요청을 전달하고 응답을 받습니다. 이 구조 덕분에 모델 서빙과 웹 서버는 서로 독립적으로 운영되며, 리소스 분리와 확장성이 용이합니다.
2. Streamlit, FastAPI로 구성된 시스템에 Triton 기반 추론 서버를 통합하려면 어떤 구조로 설계하는 것이 바람직하다고 생각하나요?
모델 서빙이란 학습된 인공지능 모델을 실제 서비스 환경에 배포하여, 외부에서 들어오는 입력 데이터에 대해 예측 결과를 실시간으로 제공하는 과정을 의미합니다. 단순히 모델을 학습시키는 것에 그치지 않고, 이를 사용자나 다른 시스템이 사용할 수 있는 형태로 안정적으로 제공해야 비로소 AI 기술이 제품화되고 서비스로 이어질 수 있습니다.
GURU
모델 서빙이 필요한 이유는 크게 세 가지입니다. 첫째, 학습된 모델은 일반적으로 Jupyter Notebook이나 로컬 환경에서 동작하기 때문에 실시간 요청을 처리할 수 없습니다. 둘째, 서비스 환경에서는 다수의 사용자 요청에 대해 높은 안정성과 일관된 응답 속도를 요구하기 때문에, 서빙 전용 시스템이 필요합니다. 셋째, 모델은 지속적으로 업데이트되거나 개선되어야 하며, 이 과정에서 새로운 버전의 모델을 무중단으로 교체하거나 관리할 수 있어야 합니다.
실제 서비스 환경에서 모델 서빙 프레임워크는 다음과 같은 역할을 수행합니다. 먼저, 모델을 메모리에 올려두고 REST API 혹은 gRPC와 같은 인터페이스를 통해 외부 요청을 받을 수 있게 합니다. 또한, 배치 처리나 비동기 요청 등 다양한 서빙 전략을 통해 처리 효율을 높이고, 동시에 로깅과 모니터링을 통해 모델의 상태와 응답 성능을 실시간으로 추적할 수 있도록 도와줍니다. 더 나아가, 멀티 모델 로딩이나 A/B 테스트, Canary 배포 등 복잡한 운영 전략도 서빙 프레임워크를 통해 수행할 수 있습니다.
결론적으로, 모델 서빙은 AI 모델을 제품 수준의 서비스로 전환하기 위한 핵심 요소이며, 서빙 프레임워크는 이를 실현하기 위한 필수적인 기반 인프라 역할을 합니다.
