Triton Inference Server의 추론구조 분석

안녕하세요. yeTi입니다.
오늘은 Triton Inference Server에서 추론을 하기위한 구조를 분석해보려고 합니다.

분석 환경

• Triton Inference Server : Release 2.6.0 corresponding to NGC container 20.12

Concurrent Model Execution

Triton은 다양한 모델을 각각의 인스턴스로 수행하여 병렬로 처리할 수 있고, 하나의 모델에 대해서 다수의 인스턴스를 활용하여 병렬처리할 수 있도록 제공합니다.

각 경우를 그림과 함께 살표보겠습니다.

2개의 모델을 각각 요청한경우 병렬로 처리가 됩니다.
모델당 인스턴스의 기본 설정값이 1개인데, 이 때 model1에 2개의 요청이 들어오면 순차적으로 처리됩니다.

model1의 인스턴스 설정값을 3으로 변경하면 3개의 요청까지 병렬처리됩니다.
해당 기능을 제공하기 위해 triton inference server가 가지는 구조는 아래와 같습니다.

Inference Architecture

Triton inference server가 추론하는 과정에는 3개의 컴포넌트가 관여합니다.

3개의 컴포넌트는 외부에서 요청을 받고 응답을 반환하는 Request / Response Server, 외부의 요청을 스케쥴링하기 위한Scheduler Queue, 요청을 추론하고 결과를 반환하는 Instance 입니다.

Load model

Triton inference server가 모델을 로드하는 과정은 3가지로 요약할 수 있습니다.

1. 모델 정보를 기반으로 추론할 instance를 생성합니다.
2. Instance를 생성하는 과정에서 모델을 load합니다. (이 때, framework backend를 활용하여 다양한 형식의 모델을 지원하고, 필요한 모듈을 CPU나 GPU에 load합니다.)
3. Instance가 스케쥴링하도록 scheduler queue를 생성합니다.

참고적으로, 스케쥴링의 종류는 Default Scheduler, Dynamic Batcher, Sequence, Batcher, Ensemble Scheduler가 있고, 스케쥴링의 종류는 모델의 유형에 따라 다르게 설정될 수 있습니다.

Inference Flow

추론을 처리하는 과정에는 다양한 방식으로 병렬처리를 하여 리소스를 최대한 활용할 수 있도록 지원합니다.

Client의 요청은 Scheduler Queue에 전달하여 다수의 inastance가 처리할 수 있도록 합니다. 이 후 각 instance가 프로그래밍된 절차에 따라 OS, Cuda로 연산 요청을 하는데요. OS와 Cuda는 자체적으로 가지고 있는 스케쥴링이나 병렬처리기법을 활용하여 hardware 리소스를 최대한 활용할 수 있도록 해줍니다.

모든 연산이 끝나면 instance는 client에 response를 함으로써 추론 처리 과정이 끝나게 됩니다.

참고적으로 cuda는 CUDA Dynamic Parallelism에 의해 병렬처리를 수행합니다.

data-dependent parallel work can be generated inline within a kernel at run-time, taking advantage of the GPU's hardware schedulers and load balancers dynamically and adapting in response to data-driven decisions or workloads
데이터 처리를 위한 병렬 작업은 커널 내에서 인라인으로 런타임에 생성 될 수 있으며, GPU의 하드웨어 스케줄러 및 로드 밸런서를 동적으로 활용하고 데이터에 기반한 의사결정이나 워크로드를 제공합니다.

Instance 상세분석

Instance의 구현체는 triton_model_instance.cc입니다.
Instance는 모델정보를 가지고 있으며 각 instance는 thread로 생성되어 vector<>로 관리됩니다.

모델의 구현체는 TritonModel이며 backend(framework)에 대한 정보 및 AI모델, configuration 정보를 가지고 있습니다.

request가 들어오면 scheduler는 vector<>에 있는 instance중 하나를 호출하여 요청하고
instance는 가지고 있는 famework 및 모델 정보를 활용하여 요청을 처리하여 반환합니다.

참고적으로 요청을 처리하는 흐름은 다음과 같습니다.
enqueue request -> queue -> dequeue scheduler -> run model[runner_idx] -> excute instance