Triton 아키텍처
Triton 아키텍처
Triton Inference Server가 어떻게 생겼는지, 한 장의 다이어그램으로 보여드릴게요. 추론 요청이 들어와서 스케줄러를 거쳐 백엔드가 실행하고 결과를 돌려주기까지, 각 구성 요소의 역할을 하나씩 짚어보겠습니다. '어떤 조각들이 어떤 순서로 맞물리는지'만 잡으면 이후 개념들을 이해하는 뼈대가 됩니다.
출처: 공식문서
본문
Triton Inference Server의 고수준 아키텍처를 보면, 모델 저장소(model repository) 는 Triton이 추론에 사용할 수 있도록 제공하는 파일 시스템 기반의 모델 저장소예요. 즉 서버가 '서빙할 모델이 여기 있다'고 알고 있는 디렉터리 구조입니다.
추론 요청은 HTTP/REST나 GRPC, 또는 C API를 통해 서버에 도착해요. 들어온 요청은 각 모델에 맞는 스케줄러(scheduler) 로 라우팅됩니다. Triton은 여러 가지 스케줄링·배칭 알고리즘을 구현하고 있고, 이건 모델별로 개별 설정할 수 있어요. 다시 말해 모델 A는 동적 배처를 쓰고, 모델 B는 기본 스케줄러를 쓰는 식으로 자유롭게 선택할 수 있다는 뜻입니다.
각 모델의 스케줄러는 선택적으로 요청 배칭(batching)을 수행한 뒤, 모델 타입에 해당하는 백엔드(backend) 로 요청을 넘겨요. 백엔드는 배칭된 요청의 입력을 받아 추론을 수행하고, 요청한 출력을 만들어 반환합니다.
Triton은 백엔드 C API를 지원해서, 커스텀 전·후처리(pre/post-processing) 연산이나 아예 새로운 딥러닝 프레임워크처럼 새 기능으로 확장할 수 있어요. 즉 서버를 열어서 원하는 백엔드를 붙이는 구조입니다.
서빙 중인 모델들은 전용 모델 관리 API(model management API) 로 조회·제어할 수 있고, 이 API도 HTTP/REST·GRPC 프로토콜 또는 C API로 사용 가능합니다. 마지막으로 readiness/liveness 헬스 엔드포인트와 utilization·throughput·latency 메트릭 덕분에 Kubernetes 같은 배포 프레임워크와의 통합이 수월해져요.