제5부 추론 최적화와 서빙

5.11 Triton I — 모델 리포지토리·백엔드

5.11.1 이 장에서 배우는 것 / 선수 지식

5.2~5.10에서 모델을 최적화된 엔진(TensorRT·TensorRT-LLM)으로 컴파일했다. 그런데 5.1에서 말했듯 추론 시스템의 절반은 모델이 아니라 "요청을 받고·줄 세우고·배치로 묶고·여러 모델을 동시에 운용하고·지표를 내는" 서빙 인프라다. 매번 이것을 직접 작성할 순 없다. Triton Inference Server가 그 서빙 계층을 표준으로 제공한다 — 여러 프레임워크의 모델을 하나의 서버·하나의 API로 운영하고, 배칭·동시성·다중 모델·메트릭·모델 수명주기를 다룬다.

이 장은 제5부 서빙 묶음(5.11~5.14)의 출발점이다. Triton의 모델 리포지토리 구조와 config.pbtxt, 그리고 백엔드 추상화(TensorRT·ONNX·PyTorch·Python·TRT-LLM·vLLM 등 무엇이든 같은 서버로)를 실습으로 익힌다. 배칭·동시성의 세부 튜닝은 5.12~5.13, 앙상블·BLS는 5.14.

배우는 것:

• 왜 서빙 계층인가 — 직접 서버를 구현하는 것 대비 Triton이 주는 것(다중 프레임워크·배칭·동시성·메트릭·수명주기).
• 모델 리포지토리 — model/<버전>/<파일> + config.pbtxt 디렉터리 규약과 버전 정책.
• config.pbtxt — backend/platform·max_batch_size·input/output(이름·dtype·dims)·instance_group·version_policy의 의미.
• 백엔드 — TensorRT·ONNX Runtime·PyTorch(LibTorch)·Python·TRT-LLM·vLLM·FIL·DALI·ensemble·BLS의 역할 분담.
• 모델 로딩 제어(none/explicit/poll)와 클라이언트(HTTP·gRPC·perf_analyzer)·헬스·메트릭.
• TensorRT 엔진(5.2)과 Python 백엔드를 한 서버로 기동하고 질의·측정하기(실습), TRT-LLM 백엔드 연결.

선수 지식: 5.1(서빙·스케줄러가 추론 시스템의 절반·지표), 5.2(TensorRT 엔진 — 서빙 대상), 5.7~5.10(TRT-LLM — 백엔드로 연결), 0.3/A.1(컨테이너). 배칭·동시성은 5.12~5.13에서 깊게. 환경은 NGC Triton 컨테이너 권장.

정직: Triton의 백엔드 가용성·기능·컨테이너 태그·일부 필드는 버전마다 다르다(예: TRT-LLM·vLLM 백엔드 통합 방식 변화). config.pbtxt의 핵심 스키마는 비교적 안정적이나, 정확한 필드·기본값·백엔드 지원은 그 버전 문서로 확인("시점 의존, 확인 필요"). 모든 성능 수치는 환경 의존 개략값, 실측.

5.11.2 왜 서빙 계층 — Triton이 하는 일

직접 Flask/FastAPI로 모델 서버를 구현하면 금세 한계에 부딪힌다 — 배칭·동시성·다중 모델·다중 프레임워크·메트릭·모델 교체를 전부 직접 작성해야 한다. Triton은 이를 프로덕션 검증된 단일 시스템으로 준다.

Triton이 주는 것:

핵심: Triton은 "모델을 어떻게 빨리 실행하나"(그것은 TensorRT/TRT-LLM의 일)가 아니라 "여러 모델·여러 요청을 어떻게 운영하나" 를 푼다. 사면체(5.1)에서 처리량·활용률·비용 축을 미는 서빙 계층.

5.11.3 모델 리포지토리 — 디렉터리 규약

Triton은 모델 리포지토리(디렉터리)를 가리켜 실행한다. 규약된 레이아웃:

규칙:

• 모델 이름 = 디렉터리 이름 = API에서 부르는 이름.
• 버전 = 정수 하위 디렉터리(1, 2, …). 여러 버전 공존, version_policy로 어느 것을 서빙할지 결정.
• 모델 파일명은 백엔드 규약을 따른다(TensorRT=model.plan, ONNX=model.onnx, LibTorch=model.pt, Python=model.py 등 — 버전 확인).
• config.pbtxt 가 그 모델의 백엔드·입출력·배치·인스턴스를 선언(일부는 자동 추론 가능).

5.11.4 config.pbtxt — 모델 설정의 핵심

config.pbtxt는 모델을 어떻게 서빙할지 선언한다. TensorRT 분류 모델 예:

# model_repository/densenet_trt/config.pbtxt
name: "densenet_trt"
platform: "tensorrt_plan"          # 백엔드/플랫폼(tensorrt_plan, onnxruntime_onnx, pytorch_libtorch, python ...)
max_batch_size: 32                 # 0이면 배칭 안 함. >0이면 첫 차원이 '배치'(아래 dims엔 생략)

input [
  {
    name: "input"                  # 엔진의 입력 텐서명과 일치
    data_type: TYPE_FP32           # dtype(TYPE_FP16/TYPE_INT8/TYPE_INT32 ...)
    dims: [ 3, 224, 224 ]          # 배치 차원 제외(max_batch_size>0이면 앞에 N 자동)
  }
]
output [
  {
    name: "logits"
    data_type: TYPE_FP32
    dims: [ 1000 ]
  }
]

instance_group [                   # 동시 인스턴스(5.12에서 깊게)
  { count: 2, kind: KIND_GPU, gpus: [ 0 ] }   # GPU0에 2개 인스턴스
]

version_policy: { latest: { num_versions: 1 } }  # 최신 1개 버전 서빙(all/specific도 가능)

# dynamic_batching { } 등 배칭 설정은 5.13에서. 여기선 구조에 집중.

핵심 필드:

함정 미리: dims·dtype·텐서 이름 불일치가 가장 흔한 로드 실패다. TensorRT 엔진의 입출력 이름·형상(5.2의 set_input_shape 이름)과 config.pbtxt가 정확히 맞아야 한다. max_batch_size>0이면 dims에서 배치 차원을 빼는 규약을 헷갈리기 쉽다.

5.11.5 백엔드 — 무엇이든 한 서버로

Triton의 힘은 백엔드 추상화다. 같은 서버·같은 API 뒤에서 백엔드가 실제 실행을 담당한다.

Python 백엔드가 특히 유용하다 — 전처리·후처리·여러 모델 조합·커스텀 로직을 파이썬으로 작성해 같은 서버에 둔다:

# model_repository/my_python/1/model.py — Python 백엔드 골격(API는 버전 확인)
import triton_python_backend_utils as pb_utils
import numpy as np

class TritonPythonModel:
    def initialize(self, args):
        self.model_config = args["model_config"]   # 로드 시 1회(자원 준비)

    def execute(self, requests):                   # 요청 배치 처리
        responses = []
        for request in requests:
            x = pb_utils.get_input_tensor_by_name(request, "input").as_numpy()
            y = (x * 2.0).astype(np.float32)        # 예: 임의 로직(실전은 전처리/후처리)
            out = pb_utils.Tensor("output", y)
            responses.append(pb_utils.InferenceResponse(output_tensors=[out]))
        return responses

핵심: 모델마다 최적의 백엔드를 고르고 한 서버로 운영한다. 예: 전처리(DALI/Python) → TensorRT 추론 → 후처리(Python)를 ensemble로 묶어(5.14) 클라이언트는 한 번만 호출. LLM이면 tensorrtllm 백엔드가 인플라이트 배칭(5.8)을 수행한다.

5.11.6 워크스루 (1) — 서버 기동하고 질의

5.2에서 만든 TensorRT 엔진을 Triton으로 서빙한다.

5.11.6.1 리포지토리 구성·서버 실행

# 1) 리포지토리 배치
mkdir -p model_repository/densenet_trt/1
cp resnet50_dyn.plan model_repository/densenet_trt/1/model.plan   # 5.2의 엔진
#   config.pbtxt는 5.11.4 내용으로 작성(입출력 이름·dims를 엔진에 맞춤)

# 2) Triton 서버 실행(NGC 컨테이너; 태그·플래그 버전 확인)
docker run --gpus all --rm -p 8000:8000 -p 8001:8001 -p 8002:8002 \
  -v "$PWD/model_repository":/models \
  nvcr.io/nvidia/tritonserver:<YY.MM>-py3 \
  tritonserver --model-repository=/models
#   8000=HTTP, 8001=gRPC, 8002=메트릭(Prometheus)

# 3) 준비 확인(readiness/liveness)
curl -s localhost:8000/v2/health/ready && echo " READY"
curl -s localhost:8000/v2/models/densenet_trt/config | head     # 적재된 설정 확인

서버 로그에서 모델이 READY인지 확인 — UNAVAILABLE이면 config 불일치·파일명·백엔드를 점검(5.11.8).

5.11.6.2 클라이언트로 추론

# client.py — HTTP 클라이언트로 추론(tritonclient; API 버전 확인)
import numpy as np, tritonclient.http as httpclient

client = httpclient.InferenceServerClient(url="localhost:8000")
x = np.random.randn(8, 3, 224, 224).astype(np.float32)          # 배치 8

inp = httpclient.InferInput("input", x.shape, "FP32"); inp.set_data_from_numpy(x)
out = httpclient.InferRequestedOutput("logits")
res = client.infer("densenet_trt", inputs=[inp], outputs=[out])

logits = res.as_numpy("logits")
print(logits.shape, logits.argmax(1))      # (8, 1000), 배치별 top-1

python client.py    # (8,1000) + 클래스 인덱스

5.11.6.3 성능 측정 — perf_analyzer

Triton은 perf_analyzer 로 처리량·지연을 부하 조건별로 잰다(서버 외부에서 부하 생성).

# 동시성을 높이며 처리량·지연(p50/p90/p99) 곡선 — 5.1 지표
perf_analyzer -m densenet_trt -b 8 \
  --concurrency-range 1:8 \
  -u localhost:8000
# 출력: concurrency별 Throughput(infer/s)·Latency(평균·p90·p99)
# → SLA를 깨기 직전의 동시성이 운영점(5.1). instance/batch 튜닝 효과를 여기서 검증(5.12~5.13).

5.11.7 워크스루 (2) — TRT-LLM 백엔드 연결

LLM은 tensorrtllm 백엔드로 서빙한다 — 5.7~5.10의 인플라이트 배칭·페이지드 KV가 서버 안에서 실행된다. 보통 전처리(토크나이즈)·tensorrt_llm(생성)·후처리(디토크나이즈) 를 ensemble(5.14)로 묶는다(절차·템플릿은 버전 의존):

# 스트리밍 생성은 gRPC(decoupled) 또는 OpenAI 호환 프런트엔드(버전 의존)로
# 클라이언트는 'ensemble'에 프롬프트를 보내고 토큰 스트림을 받음

왜 "decoupled"인가: 기본(non-decoupled) 요청 모델은 요청 1개 → 응답 1개를 가정한다. LLM 생성처럼 토큰이 하나씩 여러 번 나오는 응답은 이 가정에 안 맞는다. Triton의 decoupled 트랜잭션 정책은 이 1:1 짝을 풀어, 백엔드가 한 요청에 대해 응답을 0개·1개·여러 개(스트림)를 원하는 시점에 보낼 수 있게 한다 — 요청과 응답의 개수·타이밍이 분리(decoupled)된다는 뜻이다. tensorrtllm 백엔드는 새 토큰이 나올 때마다 부분 응답을 내보내는 식으로 이를 활용해 클라이언트가 토큰을 실시간으로 받는다. ensemble로 여러 모델을 묶을 때도 스트림이 파이프라인을 통과하도록 구성해야 한다(구체 설정은 버전 의존, 확인 필요).

요지: Triton은 LLM도 비-LLM도 같은 서버로 운영한다. LLM의 자기회귀·KV·인플라이트 배칭은 tensorrtllm 백엔드가, 요청 큐·스트리밍·메트릭·다른 모델과의 공존은 Triton이 맡는다. 6.7~6.8의 NIM은 이 조합을 표준 API·컨테이너로 더 감싼 것.

5.11.8 중간 점검 (체크포인트)

• [ ] Triton이 직접 서버 대비 무엇을 주는지(다중 프레임워크·배칭·다중 모델·메트릭·수명주기)를 제시한다.
• [ ] 모델 리포지토리 레이아웃(model/<버전>/<파일> + config.pbtxt)과 버전 정책을 설명한다.
• [ ] config.pbtxt의 핵심 필드(platform·max_batch_size·input/output·instance_group)와, max_batch_size>0이면 dims에서 배치 차원 생략 규약을 안다.
• [ ] 백엔드 추상화(TensorRT·ONNX·PyTorch·Python·TRT-LLM·vLLM·ensemble)와 각 용도를 구분한다.
• [ ] 서버를 기동해 헬스·config을 확인하고, 클라이언트로 질의하며, perf_analyzer로 처리량·지연을 측정한다.
• [ ] LLM은 tensorrtllm 백엔드 + ensemble(전/후처리) 로 서빙됨을 안다.

증상→의심: 모델이 UNAVAILABLE/로드 실패 → config의 dtype·dims·텐서 이름 불일치, 파일명·백엔드 불일치 → 로그·/v2/models/.../config로 점검. 추론은 되는데 배치가 안 묶임 → dynamic_batching 미설정(5.13) 또는 max_batch_size=0. GPU 활용률 낮음 → 인스턴스 1개·배칭 없음(5.12~5.13). LLM 처리량 낮음 → tensorrtllm 백엔드의 인플라이트 배칭·KV 설정(5.8). dims 에러 → max_batch_size>0인데 dims에 배치 차원 포함(또는 반대).

5.11.9 트레이드오프·대안

서빙을 무엇으로?

견해: 다중 모델·다중 프레임워크·비-LLM 포함 production이면 Triton이 자연스럽다 — 비전·임베딩·LLM을 한 서버로 운영하고 메트릭·배칭·수명주기를 얻는다. LLM 단일에 빠르게면 vLLM 자체 서버나 NIM이 간편할 수 있다. 프로토타입은 프레임워크 직접도 충분. Triton의 진입 비용은 config.pbtxt·리포지토리 규약 학습인데, 그 대가로 운영을 크게 단순화한다.

비엔비디아 정직: Triton은 여러 프레임워크·여러 런타임을 품는 개방적 서버다(vLLM·ONNX RT·PyTorch도 백엔드). 대안으로 KServe·TorchServe·Ray Serve·각 클라우드 서빙이 있고, LLM 전용은 vLLM/SGLang 자체 서버가 간편하다. Triton의 강점은 다중 프레임워크·다중 모델·동적 배칭·메트릭의 통합과 TRT-LLM·DALI 연계다. 워크로드(LLM 전용? 다중 모델?)로 고르고 실측.

5.11.10 흔한 함정

• config 입출력 불일치. 텐서 이름·dtype·dims가 모델과 안 맞으면 로드 실패·오류. 엔진의 실제 입출력에 정확히 맞춘다(5.2).
• max_batch_size 차원 규약 혼동. max_batch_size>0이면 dims에서 배치 차원을 뺀다(첫 차원이 배치로 자동). 포함하면 형상 에러.
• 파일명·백엔드 규약 위반. TensorRT=model.plan, ONNX=model.onnx 등. 백엔드가 기대하는 이름이어야 적재.
• 엔진의 GPU/버전 종속 무시. Triton이 적재하는 TensorRT/TRT-LLM 엔진은 그 GPU·그 버전용(5.2·5.9). 서버 GPU와 엔진이 맞아야.
• 배칭·인스턴스 미설정으로 저활용. 기본은 인스턴스 1·동적 배칭 off일 수 있다 → GPU 유휴. 5.12~5.13에서 켠다.
• 모델 제어 모드 오해. --model-control-mode(none/explicit/poll)에 따라 핫 로드·언로드 동작이 다르다. 운영 시 확인.
• LLM을 tensorrt 백엔드로. LLM은 tensorrtllm 백엔드(인플라이트 배칭). 일반 tensorrt로는 자기회귀·KV를 처리하지 못한다(5.7).
• 메트릭·헬스 미사용. /v2/health/ready·8002 메트릭을 안 보면 운영 가시성 0 → k8s readiness·Prometheus 연동(7.3).

5.11.11 연습문제

연습 1 (왜 Triton). 팀이 비전 분류·임베딩·LLM 세 모델을 production에서 서빙한다. FastAPI로 각각 구현하는 것 대비 Triton을 한 서버로 쓰는 이점을 넷 이상 제시하라.

연습 2 (config 차원). max_batch_size: 16인 모델의 입력이 실제로 (N, 3, 224, 224)이다. (a) config의 dims에 무엇을 써야 하나? (b) max_batch_size: 0이면? (c) 흔한 실수와 증상은?

연습 3 (백엔드 선택). 다음 각각에 적합한 Triton 백엔드와 이유: (a) 5.2에서 빌드한 ResNet TensorRT 엔진, (b) 70B 오픈웨이트 LLM, (c) 이미지 디코딩·리사이즈 전처리, (d) 입력에 따라 두 모델 중 하나를 선택 호출하는 조건 로직.

연습 4 (로드 실패 디버깅). TensorRT 엔진을 올렸는데 모델이 UNAVAILABLE이다. 점검 순서를 단계로 제시하라.

연습 5 (서빙 선택). 회사가 "LLM 하나만 OpenAI 호환 API로 빠르게"를 원한다. Triton(+TRT-LLM), vLLM 자체 서버, NIM 중 어떻게 권하고, 나중에 비전·임베딩 모델이 추가되면 결정이 어떻게 바뀌나?

5.11.12 요약 · 다음 장

• Triton Inference Server는 추론의 서빙 계층이다 — 여러 프레임워크(TensorRT·TRT-LLM·vLLM·ONNX·PyTorch·Python·DALI·FIL)의 모델을 한 서버·한 API로 운영하고, 배칭·동시성·다중 모델·메트릭·수명주기를 제공한다. 사면체의 처리량·활용률·비용 축.
• 모델 리포지토리 = 모델/<버전>/<파일> + config.pbtxt. config는 platform·max_batch_size·input/output(이름·dtype·dims)·instance_group·version_policy를 선언 — 텐서 일치와 배치 차원 규약(max_batch_size>0이면 dims에서 배치 생략)이 핵심.
• 백엔드 추상화로 모델마다 최적 런타임을 고른다. LLM은 tensorrtllm 백엔드 + 전/후처리 ensemble(5.14), 전처리는 DALI/Python.
• 실습: 리포지토리 구성 → 컨테이너로 서버 실행 → 헬스·config 확인 → 클라이언트 질의 → perf_analyzer로 처리량·지연 측정(5.1 지표).
• 정직: 백엔드 가용성·컨테이너 태그·일부 필드는 버전 의존(확인 필요), 엔진은 GPU·버전 종속, 모든 수치 실측.

다음 장: 5.12 Triton II — config·동시성·인스턴스. 이 장에서 구조를 잡았으니, 이제 활용률·처리량을 끌어올리는 튜닝으로 들어간다 — instance_group으로 한 GPU에 여러 인스턴스를 기동해 동시성을 높이는 법, 동시 실행과 GPU 자원의 관계, MPS/MIG(7.5)와의 연계를 perf_analyzer로 측정하며 실습한다.