Triton Inference Server #4. Model Configuration

딥러닝 모델의 성능을 최적화하고 배포하는 것은 현대 AI 애플리케이션의 핵심 요소 중 하나입니다. 그 중에서도 모델을 효율적으로 관리하고 운영하는 것은 매우 중요합니다. Triton Inference Server는 이러한 요구에 부응하기 위해 설계된 강력한 도구입니다. 이번 시리즈에서는 Triton Inference Server에 대해 샅샅히 파헤처보는 글을 작성해보려고 합니다.

지난 포스트 다시보기

Triton Inference Server #1. Triton Inference Server란?

딥러닝 모델의 성능을 최적화하고 배포하는 것은 현대 AI 애플리케이션의 핵심 요소 중 하나입니다. 그 중에서도 모델을 효율적으로 관리하고 운영하는 것은 매우 중요합니다. Triton Inference Server

dytis.tistory.com

Triton Inference Server #2. 모델 스케쥴링

dytis.tistory.com

Triton Inference Server #3. Model Management & Repository

dytis.tistory.com

Model Configuration

모델 레포지토리에 포함된 각 모델은 모델 설정(Model Configuration)을 필수적으로 포함해야 합니다. 이 설정은 일반적으로 ModelConfig protobuf로 명시된 config.pbtxt 파일에 제공됩니다. 어떤 경우에는, 'Auto-Generated Model Configuration' 를 사용하여 모델 설정이 Triton에 의해 자동으로 생성될 수 있으므로 명시적으로 제공할 필요가 없습니다.

Minimal Model Configuration

모델의 최소 설정은 모델의 플랫폼과/또는 백엔드 속성, max_batch_size 속성, 그리고 모델의 입력 및 출력 텐서를 명시해야 합니다. 예를 들어, 두 개의 입력(input0과 input1)과 하나의 출력(output0)을 가지며, 모두 16개 항목의 float32 텐서인 TensorRT 모델을 고려해 볼 수 있습니다. 이러한 경우의 최소 설정은 다음과 같습니다.

  platform: "tensorrt_plan"
  max_batch_size: 8
  input [
    {
      name: "input0"
      data_type: TYPE_FP32
      dims: [ 16 ]
    },
    {
      name: "input1"
      data_type: TYPE_FP32
      dims: [ 16 ]
    }
  ]
  output [
    {
      name: "output0"
      data_type: TYPE_FP32
      dims: [ 16 ]
    }
  ]

Name, Platform and Backend

모델 설정의 이름 속성은 선택적입니다. 설정에서 모델의 이름이 명시되지 않은 경우, 그 이름은 모델을 포함하는 모델 레포지토리 디렉토리의 이름과 동일하다고 간주됩니다. 이름이 명시된 경우, 그 이름은 모델을 포함하는 모델 레포지토리 디렉토리의 이름과 일치해야 합니다.

Model Transaction Policy

model_transaction_policy 속성은 모델로부터 예상되는 트랜잭션의 성격을 설명합니다.

Decoupled

이 Boolean 설정은 모델에 의해 생성된 응답이 요청과 분리되어 있는지 여부를 나타냅니다. decoupled를 사용하면 모델에 의해 생성된 응답의 수가 요청된 수와 다를 수 있으며, 응답은 요청의 순서와 다를 수 있습니다. 기본값은 false로, 이는 모델이 각 요청에 대해 정확히 하나의 응답을 생성할 것임을 의미합니다.

Maximum Batch Size

max_batch_size 속성은 모델이 지원하는 최대 배치 크기를 나타냅니다. 이는 Triton이 모델과 함께 배치를 활용할 수 있는 방식으로 배치를 자동으로 사용할 수 있게 합니다. 만약 모델의 배치 차원이 첫 번째 차원이며 모든 입력과 출력이 이 배치 차원을 가지고 있다면, Triton은 동적 배처(dynamic batcher)나 시퀀스 배처(sequence batcher)를 사용하여 모델과 함께 배치를 자동으로 사용할 수 있습니다. 이 경우, max_batch_size는 Triton이 모델과 함께 사용해야 하는 최대 배치 크기를 나타내는 1 이상의 값을 설정해야 합니다.

배치를 지원하지 않는 모델이거나 위에서 설명한 특정 방식으로 배치를 지원하지 않는 경우, max_batch_size는 0으로 설정해야 합니다.

Inputs and Outputs

모델의 각 Input과 Output은 이름, 데이터 유형, 그리고 Shape를 명시해야 합니다. Input 또는 Output 텐서에 대해 지정된 이름은 모델이 기대하는 이름과 일치해야 합니다.

Input 및 Output 텐서의 허용되는 데이터 유형은 모델의 유형에 따라 다릅니다. Input Shape은 모델과 Triton이 추론 요청에서 기대하는 Input 텐서의 Shape를 나타냅니다. Output Shape은 모델이 생성하고 Triton이 추론 요청에 응답하여 반환하는 Output 텐서의 Shape를 나타냅니다. Input 및 Output Shape은 모두 1 이상의 Rank를 가져야 하며, 빈 Shape [ ]는 허용되지 않습니다.

Input 및 Output Shape은 max_batch_size와 Input 또는 Output dims 속성에 의해 지정된 차원의 조합으로 지정됩니다. max_batch_size가 0보다 큰 모델의 경우, 전체 Shape은 [ -1 ] + dims로 형성됩니다. max_batch_size가 0과 같은 경우, 전체 Shape은 dims로 형성됩니다.

아래 예시에서는 설정에 따라 "input0"의 Shape은 [ -1, 16 ] 이고, "output0"의 Shape은 [ -1, 4 ] 입니다.

  platform: "tensorrt_plan"
  max_batch_size: 8
  input [
    {
      name: "input0"
      data_type: TYPE_FP32
      dims: [ 16 ]
    }
  ]
  output [
    {
      name: "output0"
      data_type: TYPE_FP32
      dims: [ 4 ]
    }
  ]

max_batch_size가 0인 동일한 구성의 경우, "input0"의 Shape은 [ 16 ]이고 "output0"의 Shape은 [ 4 ]입니다.

  platform: "tensorrt_plan"
  max_batch_size: 0
  input [
    {
      name: "input0"
      data_type: TYPE_FP32
      dims: [ 16 ]
    }
  ]
  output [
    {
      name: "output0"
      data_type: TYPE_FP32
      dims: [ 4 ]
    }
  ]

Variable-size 차원을 지원하는 Input 및 Output 텐서를 가진 모델의 경우, 이러한 차원은 입력 및 출력 구성에서 -1로 나열될 수 있습니다. 예를 들어, 첫 번째 차원이 크기 4이고 두 번째 차원이 어떤 크기든 가능한 2차원 입력 텐서를 요구하는 모델의 경우, 해당 입력의 모델 구성에는 dims: [ 4, -1 ]이 포함됩니다. 이 경우 Triton은 입력 텐서의 두 번째 차원이 0 이상인 모든 값을 가진 추론 요청을 수락할 것입니다.

  input [
    {
      name: "input0"
      data_type: TYPE_FP32
      dims: [ 4, -1 ]
    }
  ]

모델 구성은 기본 모델이 허용하는 것보다 더 제한적일 수 있습니다. 예를 들어, 프레임워크 모델 자체가 두 번째 차원의 크기를 자유롭게 허용함에도 불구하고, 모델 구성은 dims: [ 4, 4 ]로 지정될 수 있습니다. 이 경우, Triton은 입력 텐서의 Shape이 정확히 [ 4, 4 ]인 추론 요청만을 수락합니다.

Triton이 추론 요청에서 받는 입력 Shape과 모델이 기대하는 입력 Shape 사이에 불일치가 있을 경우 reshape 속성을 사용해야 합니다. 마찬가지로, 모델이 생성한 출력 Shape과 Triton이 응답에서 반환하는 Shape 사이에 불일치가 있을 경우에도 reshape 속성을 사용해야 합니다.

  input [
    {
      name: "in"
      dims: [ 1 ]
      reshape: { shape: [ ] }
    }
  ]

모델 입력은 allow_ragged_batch를 지정하여 입력이 불규칙 입력임을 나타낼 수 있습니다. 이 필드는 Dynamic Batcher와 함께 사용되어 모든 요청에서 동일한 Shape을 갖도록 강제하지 않고 배치를 허용합니다.

Auto-Generated Model Configuration

Triton에서 배포될 각 모델에는 필요한 설정을 포함하는 모델 구성 파일이 있어야 합니다. 일부 경우에는 Triton에 의해 모델 구성의 필요한 부분이 자동으로 생성될 수 있습니다. 필요한 모델 구성 부분은 위의 'Minimal Model Configuration'에 나와 있는 설정들입니다. 기본적으로 Triton은 이러한 섹션을 완성하려고 시도합니다. 그러나 --disable-auto-complete-config 옵션으로 Triton을 시작하면, 백엔드 측에서 모델 구성을 자동 완성하지 않도록 설정할 수 있습니다. 그러나 이 옵션을 사용하더라도 Triton은 누락된 instance_group 설정을 기본값으로 채웁니다.

Triton은 대부분의 TensorRT, TensorFlow 저장된 모델, ONNX 모델 및 OpenVINO 모델에 대해 필요한 설정을 자동으로 생성할 수 있습니다. Python 모델의 경우, Python 백엔드에서 auto_complete_config 함수를 구현하여 set_max_batch_size, add_input, add_output 함수를 사용해 max_batch_size, 입력 및 출력 속성을 제공할 수 있습니다. 이 속성들은 구성 파일이 없는 경우 Python 모델을 Minimal Model Configuration으로 로드할 수 있게 합니다. 다른 모든 모델 유형은 모델 구성 파일을 제공해야 합니다.

사용자 지정 백엔드를 개발할 때는 구성에 필요한 설정을 채우고 TRITONBACKEND_ModelSetConfig API를 호출하여 Triton 코어와 함께 완성된 구성을 업데이트할 수 있습니다. 이를 달성하는 방법의 예로 TensorFlow 및 Onnxruntime 백엔드를 참조할 수 있습니다. 현재 백엔드에서 채울 수 있는 설정은 입력, 출력, max_batch_size 및 동적 배치 설정만 포함됩니다. 사용자 지정 백엔드의 경우, config.pbtxt 파일에는 백엔드 필드가 포함되어 있어야 하며, 모델 이름은 <model_name>.<backend_name> 형식이어야 합니다.

모델 구성을 Triton이 생성한 모델 구성 엔드포인트를 사용하여 확인할 수도 있습니다. 이를 수행하는 가장 쉬운 방법은 curl과 같은 유틸리티를 사용하는 것입니다:

$ curl localhost:8000/v2/models/<model name>/config

이는 생성된 모델 구성의 JSON 표현을 반환합니다. 여기서 max_batch_size, 입력 및 출력 섹션을 가져와 config.pbtxt 파일로 변환할 수 있습니다. Triton은 모델 구성의 최소 부분만 생성합니다. 여전히 선택적인 모델 구성 부분을 config.pbtxt 파일을 편집하여 제공해야 합니다.

Default Max Batch Size and Dynamic Batcher

모델이 자동 완성 기능을 사용하는 경우, --backend-config=default-max-batch-size=<int> 명령 줄 인수를 사용하여 기본 최대 배치 크기가 설정될 수 있습니다. 이를 통해 배치를 수행할 수 있는 모든 모델이 Auto Generated Model Configuration을 사용하여 기본 최대 배치 크기를 갖게 됩니다. 이 값은 기본적으로 4로 설정됩니다. 백엔드 개발자는 TRITONBACKEND_BackendConfig api에서 이 default-max-batch-size를 가져와 사용할 수 있습니다. 현재 이 기본 배치 값을 사용하고 생성된 모델 구성에서 동적 배치를 활성화하는 백엔드는 다음과 같습니다: TensorFlow, Onnxruntime, TensorRT

TensorRT 모델은 최대 배치 크기를 명시적으로 저장하며 default-max-batch-size 매개변수를 사용하지 않습니다. 그러나 max_batch_size가 1보다 크고 스케줄러가 제공되지 않는 경우, dynamic_batching 스케줄러가 활성화됩니다.

모델의 최대 배치 크기가 1보다 크게 설정된 경우, 구성 파일에 스케줄러가 제공되지 않으면 dynamic_batching 구성이 설정됩니다.

Datatypes

Triton이 지원하는 텐서 데이터 유형을 나타내는 다음 표는 모델 구성 파일에서 데이터 유형의 이름을 보여주는 첫 번째 열과 지원되는 모델 프레임워크에 대한 해당 데이터 유형을 보여주는 다음 네 열로 구성됩니다. 특정 데이터 유형에 대해 모델 프레임워크에 항목이 없는 경우, Triton은 해당 모델에 대해 그 데이터 유형을 지원하지 않습니다. 여섯 번째 열인 “API” 열은 TRITONSERVER C API, TRITONBACKEND C API, HTTP/REST 프로토콜 및 GRPC 프로토콜에 대한 해당 데이터 유형을 보여줍니다. 마지막 열은 Python numpy 라이브러리에 대한 해당 데이터 유형을 나타냅니다.

Reshape

ModelTensorReshape 속성은 모델 구성 입력 또는 출력에 사용되어 추론 API가 받아들이는 입력 또는 출력 Shape가 기본 프레임워크 모델이나 사용자 지정 백엔드가 예상하거나 생성하는 입력 또는 출력 Shape와 다를 때 이를 나타냅니다.

입력의 경우, reshape는 입력 텐서를 프레임워크 또는 백엔드가 예상하는 다른 Shape로 변형하는 데 사용될 수 있습니다. 일반적인 사용 사례는 배치를 지원하는 모델이 배치 입력의 Shape가 [batch-size]가 되기를 기대하는 경우입니다. 이는 배치 차원이 Shape를 완전히 설명한다는 것을 의미합니다. 추론 API의 경우, 각 입력이 비어 있지 않은 dims를 지정해야 하므로 동등한 Shape [batch-size, 1]이 지정되어야 합니다. 이 경우 입력은 다음과 같이 지정되어야 합니다:

  input [
    {
      name: "in"
      dims: [ 1 ]
      reshape: { shape: [ ] }
    }

출력의 경우, reshape는 프레임워크 또는 백엔드에 의해 생성된 출력 텐서를 추론 API가 반환하는 다른 Shape로 변형하는 데 사용될 수 있습니다. 일반적인 사용 사례는 배치를 지원하는 모델이 배치 출력의 Shape가 [batch-size]가 되기를 기대하는 경우입니다. 이는 배치 차원이 Shape를 완전히 설명한다는 것을 의미합니다. 추론 API의 경우, 각 출력이 비어 있지 않은 dims를 지정해야 하므로 동등한 Shape [batch-size, 1]이 지정되어야 합니다. 이 경우 출력은 다음과 같이 지정되어야 합니다:

  output [
    {
      name: "in"
      dims: [ 1 ]
      reshape: { shape: [ ] }
    }

Instance Groups

Triton은 하나의 모델에 대해 다수의 추론 요청을 동시에 처리할 수 있도록 모델의 여러 인스턴스를 제공할 수 있습니다. 모델 구성에서 ModelInstanceGroup 속성을 사용하여 제공해야 하는 실행 인스턴스의 수와 해당 인스턴스에 사용될 계산 리소스를 지정합니다.

Multiple Model Instances

기본적으로 시스템에 있는 각 GPU에 대해 모델의 단일 실행 인스턴스가 생성됩니다. instance-group 설정을 사용하면 모든 GPU 또는 특정 GPU에 모델의 여러 실행 인스턴스를 배치할 수 있습니다. 예를 들어, 다음 구성은 시스템의 각 GPU에 모델의 두 실행 인스턴스를 배치하도록 설정합니다.

  instance_group [
    {
      count: 2
      kind: KIND_GPU
    }
  ]

다음 구성은 GPU 0에 하나의 실행 인스턴스를, GPU 1과 2에는 두 개의 실행 인스턴스를 배치합니다.

  instance_group [
    {
      count: 1
      kind: KIND_GPU
      gpus: [ 0 ]
    },
    {
      count: 2
      kind: KIND_GPU
      gpus: [ 1, 2 ]
    }
  ]

CPU Model Instance

instance group 설정은 CPU에서 모델의 실행을 활성화하는 데도 사용됩니다. 시스템에 GPU가 있더라도 모델은 CPU에서 실행될 수 있습니다. 다음 설정은 CPU에 두 개의 실행 인스턴스를 배치합니다.

  instance_group [
    {
      count: 2
      kind: KIND_CPU
    }
  ]

KIND_CPU 인스턴스 그룹에 대해 인스턴스 수가 지정되지 않은 경우, 기본 인스턴스 수는 선택된 백엔드(Tensorflow 및 Onnxruntime)에 대해 2가 됩니다. 다른 모든 백엔드는 기본값으로 1을 사용합니다.

Host Policy

instance group 설정은 호스트 정책과 연관되어 있습니다. 다음 구성은 instance group 설정에 의해 생성된 모든 인스턴스를 호스트 정책 "policy_0"과 연관시킵니다. 기본적으로 호스트 정책은 인스턴스의 장치 유형에 따라 설정됩니다. 예를 들어, KIND_CPU는 "cpu", KIND_MODEL은 "model", KIND_GPU는 "gpu_<gpu_id>"입니다.

  instance_group [
    {
      count: 2
      kind: KIND_CPU
      host_policy: "policy_0"
    }
  ]

Rate Limiter Configuration

Instance group은 선택적으로 속도 제한기 구성을 명시할 수 있으며, 이 구성은 그룹 내 인스턴스에 대한 속도 제한기의 작동 방식을 제어합니다. 속도 제한이 꺼져 있으면 속도 제한기 구성은 무시됩니다. 속도 제한이 켜져 있고 instance_group이 이 구성을 제공하지 않는 경우, 이 그룹에 속한 모델 인스턴스의 실행은 속도 제한기에 의해 어떠한 방식으로도 제한되지 않습니다. 구성은 다음과 같은 사항을 포함합니다:

Resources

모델 인스턴스 실행에 필요한 리소스 집합입니다. “name” 필드는 리소스를 식별하고 “count” 필드는 그룹의 모델 인스턴스가 실행에 필요로 하는 리소스의 복사본 수를 나타냅니다. “global” 필드는 리소스가 장치별로 지정되는지 또는 시스템 전체에 걸쳐 공유되는지를 명시합니다. 로드된 모델은 같은 이름의 리소스를 글로벌과 비글로벌로 동시에 지정할 수 없습니다. 리소스를 제공하지 않는 경우 Triton은 모델 인스턴스의 실행이 어떠한 리소스도 필요로 하지 않는다고 가정하고, 모델 인스턴스가 사용 가능해지는 즉시 실행을 시작합니다.

Priority

Priority는 모든 모델의 모든 인스턴스를 통틀어 우선 순위를 정하는 데 사용되는 가중치 값입니다. Priority가 2인 인스턴스는 Priority가 1인 인스턴스의 절반 수준의 스케줄링 기회를 받게 됩니다.

다음 예시는 그룹의 인스턴스가 실행을 위해 네 개의 “R1” 리소스와 두 개의 “R2” 리소스를 필요로 함을 명시합니다. 리소스 “R2”는 글로벌 리소스입니다. 또한, instance_group의 rate-limit Priority는 2입니다.

  instance_group [
    {
      count: 1
      kind: KIND_GPU
      gpus: [ 0, 1, 2 ]
      rate_limiter {
        resources [
          {
            name: "R1"
            count: 4
          },
          {
            name: "R2"
            global: True
            count: 2
          }
        ]
        priority: 2
      }
    }
  ]

위 구성은 각기 다른 장치(0, 1, 2)에 하나씩 3개의 모델 인스턴스를 생성합니다. 이 세 인스턴스는 “R1”이 각자의 장치에 로컬이기 때문에 서로 “R1”에 대해 경쟁하지 않지만, “R2”가 시스템 전체에 걸쳐 공유된다고 명시되어 있기 때문에 “R2”에 대해서는 경쟁합니다. 이 인스턴스들은 서로 사이에 “R1”에 대해 경쟁하지는 않지만, 같은 장치에서 실행되고 “R1”을 리소스 요구 사항에 포함하는 다른 모델 인스턴스와 “R1”에 대해 경쟁합니다.

이 Rate Limiter에 대한 내용은 추후에 한번 다루도록 하겠습니다.

Ensemble Model Instance Groups

앙상블 모델은 사용자 정의 모델 파이프라인을 실행하기 위해 Triton이 사용하는 추상화입니다. 앙상블 모델에는 물리적 인스턴스가 연관되어 있지 않기 때문에 instance_group 필드를 지정할 수 없습니다.

그러나 앙상블을 구성하는 각 모델은 해당 구성 파일에서 instance_group을 지정하고 위에서 설명한 대로 앙상블이 여러 요청을 받을 때 개별적으로 병렬 실행을 지원할 수 있습니다.

CUDA Compute Capability

CUDA Compute Capability를 이용하여, 모델을 로드할 때 GPU의 CUDA Compute Capability를 해당 모델 파일명과 매핑할 수 있는 cc_model_filenames 필드를 선택적으로 지정할 수 있습니다. 이는 특히 TensorRT 모델에 유용한데, 이러한 모델들은 일반적으로 특정 Compute Capability에 종속되기 때문입니다.

cc_model_filenames [
  {
    key: "7.5"
    value: "resnet50_T4.plan"
  },
  {
    key: "8.0"
    value: "resnet50_A100.plan"
  }
]

Scheduling And Batching

Triton은 개별 추론 요청이 입력의 배치를 지정할 수 있도록 함으로써 배치 추론을 지원합니다. 입력 배치에 대한 추론은 동시에 수행되며, 이는 특히 GPU에 있어 중요한데, 추론 처리량을 크게 증가시킬 수 있기 때문입니다. 많은 사용 사례에서 개별 추론 요청은 배치 처리되지 않으므로, 배치의 처리량 이점을 누릴 수 없습니다.

추론 서버는 다양한 모델 유형과 사용 사례를 지원하는 여러 스케줄링 및 배치 알고리즘을 포함하고 있습니다. 모델 유형과 스케줄러에 대한 자세한 정보는 이전 저의 블로그 글에서 확인할 수 있습니다.

Triton Inference Server #2. 모델 스케쥴링

dytis.tistory.com

Default Scheduler

모델 구성에서 scheduling_choice 속성이 지정되지 않은 경우 모델에 대해 기본 스케줄러가 사용됩니다. 기본 스케줄러는 단순히 모델 인스턴스에 추론 요청을 분배합니다.

이러한 기능은 사용자가 다양한 컴퓨팅 환경에서 모델을 최적화하여 실행할 수 있게 해, 특히 복잡한 모델이나 대규모 데이터를 처리할 때 효율성을 크게 향상시킵니다. CUDA Compute Capability 매핑은 고성능 컴퓨팅을 필요로 하는 모델에 매우 중요하며, 스케줄링 및 배치 기능은 서버의 처리능력을 최대화하여 더 많은 요청을 빠르고 효율적으로 처리할 수 있도록 지원합니다.

Dynamic Batcher

Dynamic batching은 Triton의 기능으로, 서버가 추론 요청을 결합하여 동적으로 배치를 생성할 수 있도록 합니다. 요청의 배치를 생성하는 것은 일반적으로 처리량을 증가시킵니다. 동적 배처는 Stateless 모델에 사용되어야 하며, 동적으로 생성된 배치는 모델에 구성된 모든 모델 인스턴스에 분배됩니다.

동적 배치는 모델 구성에서 ModelDynamicBatching 속성을 사용하여 각 모델마다 독립적으로 활성화 및 구성됩니다. 이 설정은 동적으로 생성된 배치의 선호하는 크기, 다른 요청이 동적 배치에 참여할 수 있도록 스케줄러에서 요청을 지연시킬 수 있는 최대 시간, 그리고 큐 크기, 우선순위, 타임아웃과 같은 큐 속성을 제어합니다. 동적 배치의 자세한 예는 해당 가이드를 참조하세요.

Recommended Configuration Process

모델에 대한 최대 배치 크기를 결정합니다.
모델 구성에 다음을 추가하여 모든 기본 설정으로 동적 배처를 활성화합니다. 기본적으로 동적 배처는 최대 배치 크기까지 가능한 한 큰 배치를 생성하며, 배치 형성 시 지연을 하지 않습니다.

  dynamic_batching { }

Performance Analyzer를 사용하여 기본 동적 배처 구성이 제공하는 지연 시간 및 처리량을 결정합니다.
기본 구성이 delay time budget 내에 있는 경우, 처리량 증가를 위해 지연 시간을 늘리는 것을 고려해 보세요:
- 최대 배치 크기를 증가시킵니다.
- batch delay를 0이 아닌 값으로 설정합니다. delay time budget을 초과할 때까지 증가시켜 처리량에 미치는 영향을 확인합니다.
대부분의 모델에 대해 Preferred Batch Size를 사용해서는 안 됩니다. Preferred Batch Size는 해당 배치 크기가 다른 배치 크기보다 현저히 더 높은 성능을 제공하는 경우에만 구성해야 합니다.

Preferred Batch Sizes

preferred_batch_size 속성은 동적 배처가 시도해야 할 배치 크기를 나타냅니다. 대부분의 모델에 대해서는 Recommended Configuration Process에서 설명한 대로 preferred_batch_size를 지정해서는 안 됩니다. 예외는 다양한 배치 크기에 대한 여러 최적화 프로파일을 지정하는 TensorRT 모델입니다. 이 경우 일부 최적화 프로파일이 다른 프로파일에 비해 상당한 성능 개선을 제공할 수 있으므로, 더 높은 성능의 최적화 프로파일이 지원하는 배치 크기에 대해 preferred_batch_size를 사용하는 것이 타당할 수 있습니다.

다음 예시는 배치 크기 4와 8에 대한 선호도를 설정하여 동적 배치를 활성화하는 구성을 보여줍니다.

  dynamic_batching {
    preferred_batch_size: [ 4, 8 ]
  }

모델 인스턴스가 추론을 위해 사용 가능해지면, 동적 배처는 스케줄러에서 사용 가능한 요청으로부터 배치를 생성하려고 시도합니다. 요청은 수신된 순서대로 배치에 추가됩니다. 동적 배처가 선호하는 크기의 배치를 형성할 수 있는 경우, 가능한 가장 큰 선호하는 크기의 배치를 생성하여 추론을 위해 전송합니다. 동적 배처가 선호하는 크기의 배치를 형성할 수 없는 경우(또는 선호하는 배치 크기가 구성되지 않은 경우), 모델이 허용하는 최대 배치 크기보다 작은 가장 큰 크기의 배치를 전송합니다.

생성된 배치의 크기는 집계된 수치를 사용하여 검토할 수 있습니다.

Delayed Batching

동적 배처는 다른 요청이 동적 배치에 참여할 수 있도록 요청을 스케줄러에서 제한된 시간 동안 지연할 수 있도록 구성될 수 있습니다. 예를 들어, 다음 구성은 요청에 대해 최대 100 마이크로초의 지연 시간을 설정합니다.

  dynamic_batching {
    max_queue_delay_microseconds: 100
  }

max_queue_delay_microseconds 속성 설정은 최대 크기(또는 선호하는 크기) 배치를 생성할 수 없을 때 동적 배처의 동작을 변경합니다.

사용 가능한 요청으로 최대 또는 선호하는 크기의 배치를 생성할 수 없는 경우, 동적 배처는 구성된 max_queue_delay_microseconds 값보다 요청이 더 오래 지연되지 않는 한 배치 전송을 지연합니다. 지연 동안 새 요청이 도착하고 동적 배처가 최대 또는 선호하는 배치 크기의 배치를 형성할 수 있게 되면, 해당 배치는 즉시 추론을 위해 전송됩니다. 지연이 만료되면 동적 배처는 배치가 최대 또는 선호하는 크기가 아니더라도 배치를 그대로 전송합니다.

Preserve Ordering

preserve_ordering 속성은 모든 응답이 요청이 수신된 순서대로 반환되도록 강제하는 데 사용됩니다.

Priority Levels

기본적으로 동적 배처는 모델에 대한 모든 추론 요청을 보관하는 단일 큐를 유지합니다. 요청은 순서대로 처리 및 배치됩니다. priority_levels 속성을 사용하면 동적 배처 내에서 여러 우선순위 수준을 생성할 수 있으며, 더 높은 우선순위의 요청이 더 낮은 우선순위의 요청을 우회할 수 있습니다. 같은 우선순위 수준의 요청은 순서대로 처리됩니다. 우선순위가 설정되지 않은 추론 요청은 default_priority_level 속성을 사용하여 스케줄됩니다.

Queue Policy

동적 배처는 요청이 배치를 위해 큐에 배치되는 방식을 제어하는 여러 설정을 제공합니다.

priority_levels가 정의되지 않은 경우, 단일 큐의 ModelQueuePolicy는 default_queue_policy로 설정할 수 있습니다. priority_levels가 정의된 경우, 각 우선순위 수준은 default_queue_policy 및 priority_queue_policy에 의해 지정된 대로 다른 ModelQueuePolicy를 가질 수 있습니다.

ModelQueuePolicy 속성을 사용하면 max_queue_size를 사용하여 최대 큐 크기를 설정할 수 있습니다. timeout_action, default_timeout_microseconds 및 allow_timeout_override 설정을 사용하여 큐에서의 시간이 지정된 시간을 초과하는 경우 개별 요청이 거부되거나 연기되도록 큐를 구성할 수 있습니다.

Sequence Batcher

Sequence batcher는 동적 배처처럼 비배치 추론 요청을 결합하여 동적으로 배치를 생성합니다. 그러나 동적 배처와 달리, 시퀀스 배처는 추론 요청의 시퀀스가 동일한 모델 인스턴스로 라우팅되어야 하는 Stateful 모델에 사용되어야 합니다. 동적으로 생성된 배치는 모델에 구성된 모든 모델 인스턴스에 분배됩니다.

시퀀스 배치는 모델 구성에서 ModelSequenceBatching 속성을 사용하여 각 모델마다 독립적으로 활성화되고 구성됩니다. 이 설정들은 시퀀스 타임아웃을 제어하고, Triton이 시퀀스 시작, 종료, 준비 및 Correlation ID를 나타내는 제어 신호를 모델에 어떻게 보낼지 구성합니다.

Ensemble Scheduler

앙상블 스케줄러는 앙상블 모델에 대해 사용되어야 하며, 다른 유형의 모델에는 사용할 수 없습니다.

앙상블 스케줄러는 모델 구성에서 ModelEnsembleScheduling 속성을 사용하여 각 모델마다 독립적으로 활성화되고 구성됩니다. 설정은 앙상블에 포함된 모델들과 모델 간 텐서 값의 흐름을 설명합니다.

Optimization Policy

모델 구성의 ModelOptimizationPolicy 속성은 모델의 최적화 및 우선 순위 설정을 지정하는 데 사용됩니다. 이 설정들은 백엔드에 의해 모델이 어떻게 최적화되는지, 그리고 Triton에 의해 어떻게 스케줄링 및 실행되는지를 제어합니다.

Model Warmup

Triton에 의해 모델이 로드될 때 해당 백엔드는 그 모델을 위해 초기화됩니다. 일부 백엔드의 경우, 이 초기화의 일부 또는 전부가 모델이 첫 번째 추론 요청(또는 최초 몇 개의 추론 요청)을 받을 때까지 지연됩니다. 결과적으로, 최초의 추론 요청이 지연 초기화로 인해 상당히 느려질 수 있습니다.

이러한 초기의 느린 추론 요청을 피하기 위해, Triton은 모델이 첫 번째 추론 요청을 받기 전에 완전히 초기화될 수 있도록 "웜업"을 가능하게 하는 구성 옵션을 제공합니다. 모델 구성에서 ModelWarmup 속성이 정의되면, 모델 웜업이 완료될 때까지 Triton은 모델이 추론 준비가 되었다고 표시하지 않을 것입니다.

모델 구성의 ModelWarmup은 모델의 웜업 설정을 지정하는 데 사용됩니다. 이 설정들은 각 모델 인스턴스를 웜업하기 위해 Triton이 생성할 일련의 추론 요청을 정의합니다. 모델 인스턴스는 요청을 성공적으로 완료한 경우에만 서비스됩니다. 모델을 웜업하는 효과는 백엔드 프레임워크에 따라 다르며, 모델 업데이트에 대해 Triton이 덜 반응하게 만들 수 있으므로 사용자는 실험을 통해 자신의 필요에 맞는 구성을 선택해야 합니다.

model_warmup [
{
    name : "zero sample"
    batch_size: 1
    inputs {
        key: "INPUT"
        value: {
            data_type: TYPE_FP32
            dims: 4
            zero_data: true
        }
    }
}]

Response Cache

모델 구성의 response_cache 섹션에는 이 모델에 대한 응답 캐시를 활성화하는 데 사용되는 enable flag가 있습니다.

response_cache {
  enable: true
}

모델 구성에서 캐시를 활성화하는 것 외에도, 서버 측 캐싱을 활성화하기 위해 서버를 시작할 때 --cache-config를 지정해야 합니다.

저작자표시

'AI > MLOps' 카테고리의 다른 글

LitServe 리뷰 (1)	2024.08.31
Triton Inference Server #5. Python Backend (0)	2024.05.12
Triton Inference Server #3. Model Management & Repository (0)	2024.05.12
Triton Inference Server #2. 모델 스케쥴링 (0)	2024.04.23
Triton Inference Server #1. Triton Inference Server란? (0)	2024.04.22

지난 포스트 다시보기

Model Configuration

Minimal Model Configuration

Name, Platform and Backend

Model Transaction Policy

Decoupled

Maximum Batch Size

Inputs and Outputs

Auto-Generated Model Configuration

Default Max Batch Size and Dynamic Batcher

Datatypes

Reshape

Instance Groups

Multiple Model Instances

CPU Model Instance

Host Policy

Rate Limiter Configuration

Resources

Priority

Ensemble Model Instance Groups

CUDA Compute Capability

Scheduling And Batching

Default Scheduler

Dynamic Batcher

Recommended Configuration Process

Preferred Batch Sizes

Delayed Batching

Preserve Ordering

Priority Levels

Queue Policy

Sequence Batcher

Ensemble Scheduler

Optimization Policy

Model Warmup

Response Cache

'AI > MLOps' 카테고리의 다른 글

티스토리툴바