LLM 서빙하기 (1) - Triton Inference Server란?

 

 

 

LLM 서빙하기 (1) - Triton Inference Server란?

 

 

 

• 실제 서비스를 만들려면,
  • 사용자 요청을 받고
  • 모델에 입력을 넣고
  • 추론 결과를 받아서 응답해야 함 

 

 

 

일반적인 PyTorch 혹은 Transformers 모델 배포 성능을 극대화하기 위해 모델 포맷을 

 

1) ONNX 또는 SavedModel 형태로 저장한 뒤,

2) Conversion을 통해 TensorRT/vLLM 등의 Engine로 변환하고

3) Triton Inference Server로 배포하는 과정을 거침

 

 

 

 

 

 

Triton Inference Server 란? 

 

 

• Triton이란 AI 모델을 여러 환경에서 빠르고 유연하게 서비스할 수 있게 해주는 서버 플랫폼 
  • 모델 최적화 이후 “실제 서비스화”를 위한 단계에서 모델을 HTTP/gRPC API로 서비스하게 해주는 추론 서버
• 요점 
  
  • 입력: TensorRT, ONNX, PyTorch, vLLM 등 다양한 모델 포맷
  • 처리:
    • 서버에 모델 등록 후
    • HTTP/gRPC로 요청 받음
    • GPU 자원 자동 배분, 멀티 모델 배포, 배치 처리 등 자동 배치 + 멀티 모델 + 멀티 프레임워크 실행 지원
  • 특징:
    • 서비스 운영에 적합 (API 기반 서빙)
    • 모델 추론 자체를 가속하지는 않지만, 서비스 성능을 극대화 (= 위의 GPU 자원 자동 배분, 멀티 모델 배포, 배치 처리 등)
      • 최적화, 즉 효율적으로 모델 추론할 수 있도록 하는 건 TensorRT, vLLM과 같은 프레임워크를 이용해서 변환될 때!
• Github Repo. https://github.com/orgs/triton-inference-server/repositories

 

 

 

• Triton의 구성 요소 

Triton Server (repo)	모델을 로드하고 서버로서 추론 요청을 처리하는 엔진
Triton Backend (repo)	Triton이 어떤 형식의 모델을 어떻게 실행할지를 정의하는 모듈 (e.g., TensorRT, Python, ONNX 등)
Triton Client (repo)	Triton 서버에 요청을 보내는 라이브러리/도구 (HTTP/gRPC로 통신)

 

 

 

 

 

• 1. Triton Server
  • 모델 repo 디렉토리를 읽고 모델을 로딩함
  • API 요청(HTTP 또는 gRPC) 들어오면 내부적으로 backend에 전달해서 추론함
  • REST (HTTP) 또는 gRPC API를 열어둠 
    • 이때  API 연결 방식, gRPC과 HTTP 중 어떤 것을 선택할지 정할 수 있음 

	gRPC	HTTP (REST)
통신 방식	바이너리 기반 프로토콜	텍스트 기반 JSON
속도	빠름	느림 (오버헤드 큼)
데이터 크기	작음	큼
사용 편의성	약간 복잡함	쉬움 (curl, Postman 등)
실전 사용	고성능 서버 간 통신	사용자 테스트, 프론트 연동

 

 

• 2. Triton Backend
  • Triton이 어떤 형식의 모델을 어떻게 실행할지를 정의하는 모듈 (e.g., TensorRT, Python, ONNX 등)
  • models/<모델명>/config.pbtxt 에 지정된 backend가 이걸 결정
  • 지원 Backend : Python Backend, TensorRT-LLM Backend, vLLM Backend, onnx Backend, .... 
  • Backend별 특징 

python	Python 코드 직접 실행시에 사용 (tokenizer와 같은 preprocessing이나 후처리 코드 실행 시에! )
onnxruntime	ONNX 모델 실행
TensorRT	.engine 으로 변환 (FP16, INT8 최적화 포함)
vLLM	HuggingFace 모델 구조 그대로 but 내부 최적화 (paginated KV cache, continuous batching)
OpenVINO / TensorFlow-TRT	CPU inference / Edge optimized
Tensorrt-LLM	LLM에 특화된 TensorRT 엔진 (LLaMA, GPT 등)

 

 

✔️ Triton은 아래와 같이 다양한 backend 지원하고, 사용자가 커스텀 backend도 만들 수 있다 

 

https://github.com/triton-inference-server/tutorials?tab=readme-ov-file#quick-deploy

 

 

• 3. Triton Client
  • Triton 서버에 요청을 보내는 라이브러리/도구 (HTTP/gRPC로 통신)
  • Python, C++, CLI 등 다양한 버전 존재
  • tritonclient 패키지 (Python용):

import tritonclient.http as httpclient
client = httpclient.InferenceServerClient("localhost:8000")

• 요청 준비 → infer() → 결과 받기

 

---

 

 

위에서 모델 추론 자체를 가속하지는 않지만, 서비스 성능을 극대화 (= 위의 GPU 자원 자동 배분, 멀티 모델 배포, 배치 처리 등)

한다고 설명했다. 

 

그렇다면 어떻게 서비스를 극대화하는가? 

 

• 고성능 추론
  • GPU와 CPU 기반 추론을 모두 지원
  • 다이나믹 배칭, 동시 실행, 모델 앙상블 등을 통해 처리량과 활용도를 극대화
    • 다이나믹 배칭? 큐에 쌓인 만큼 배치 인퍼런스하는 방법
• 확장성
  • Docker 컨테이너 형태로 제공되어 Kubernetes와 통합 가능
  • 손쉽게 서버를 확장하여 증가하는 추론 부하 처리 가능
• 모델 관리
  • 모델 저장소(Model Repository)를 통해 모델 파일 관리
  • 모델 제어 API를 통해 동적으로 모델 로드/언로드 가능

 

 

 

Batching (자동 배치 처리)

여러 개의 추론 요청을 모아서 한꺼번에 처리해 GPU 효율을 높이는 기술

 

왜 필요해?

• 한 번에 하나씩 처리하면 GPU 활용률 낮음
• 여러 요청을 모아 GPU에 한꺼번에 넘기면 속도와 처리량 둘 다 향상됨

 

Triton의 배치 처리 방식:

• 내부 큐를 사용해 요청을 모음
• preferred_batch_size로 설정하면 그 크기로 자동 배치함
• max_batch_size는 절대 초과하지 않음

 

주의할 점

• 입력 텐서 shape가 [batch_size, ...] 형태여야 함 (예: [16, 3, 224, 224])
• max_batch_size 이상으로 요청하면 오류 발생
• 너무 큰 배치는 추론 지연(latency)이 커질 수 있음 → 실시간 서비스에선 주의

필수 항목 2가지:

1. max_batch_size: 최대 몇 개까지 묶을 수 있는지
2. dynamic_batching: 어떤 크기로, 얼마나 기다렸다가 묶을지

config 예시:

dynamic_batching {
  preferred_batch_size: [4, 8, 16]
  max_queue_delay_microseconds: 100
}

→ 위 설정이면 요청을 모아서 4, 8, 16 개씩 배치 실행

→ 요청이 오래 대기하지 않도록 최대 100us만 기다림

 

 

 

 

---

 

 

 

다음 포스트에선 실제 프로젝트에서 어떻게 구성하는지 등을 정리한다.