모델 구성

모델 구성 (Model Configuration)

config 파일을 처음 작성하는 건가요? 이 가이드나 이 예제를 확인해 보세요!

모델 저장소(model repository)의 각 모델은 모델에 대한 필수·선택 정보를 담은 **모델 구성(model configuration)**을 포함해야 해요. 보통 이 구성은 ModelConfig protobuf로 명시된 config.pbtxt 파일로 제공돼요. Auto-Generated Model Configuration에서 다루는 몇몇 경우에는 모델 구성을 Triton이 자동으로 생성해 명시적으로 제공할 필요가 없을 수도 있어요.

이 섹션은 가장 중요한 모델 구성 속성들을 설명하지만, ModelConfig protobuf의 문서도 함께 참고해야 해요.

최소 모델 구성 (Minimal Model Configuration)

최소 모델 구성은 반드시 platform 및/또는 backend 속성, 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 ]
    }
  ]

이름, Platform, Backend

모델 구성의 name 속성은 선택적이에요. 구성에서 모델 이름을 지정하지 않으면 모델 저장소에서 그 모델을 담은 디렉토리와 같은 이름으로 간주돼요. name을 지정하면 모델 저장소에서 모델을 담은 디렉토리 이름과 일치해야 해요. platform과 backend의 필수 값은 backend 문서에서 설명해요.

모델 트랜잭션 정책 (Model Transaction Policy)

model_transaction_policy 속성은 모델에서 기대하는 트랜잭션의 성격을 설명해요.

Decoupled

이 불리언 설정은 모델이 생성하는 응답이 모델에 발행한 요청과 분리(decoupled)되는지 여부를 나타내요. decoupled를 쓰면 모델이 생성하는 응답 수가 발행한 요청 수와 달라질 수 있고, 응답이 요청 순서와 다르게 나올 수도 있어요. 기본값은 false이며, 모델이 각 요청에 대해 정확히 하나의 응답을 생성한다는 뜻이에요.

최대 배치 크기 (Maximum Batch Size)

max_batch_size 속성은 Triton이 활용할 수 있는 배치 유형들에 대해 모델이 지원하는 최대 배치 크기를 나타내요. 모델의 배치 차원이 첫 번째 차원이고 모든 입력·출력이 이 배치 차원을 가지면, Triton은 동적 배처나 시퀀스 배처로 해당 모델에서 자동으로 배치를 쓸 수 있어요. 이 경우 max_batch_size는 Triton이 모델과 함께 사용할 최대 배치 크기를 나타내는 1 이상의 값으로 설정해야 해요.

배치를 지원하지 않거나 위에서 설명한 특정 방식으로 배치를 지원하지 않는 모델은 max_batch_size를 반드시 0으로 설정해야 해요.

입력과 출력 (Inputs and Outputs)

각 모델 입력·출력은 이름(name), 데이터 타입(datatype), 모양(shape)을 명시해야 해요. 입력·출력 텐서에 지정한 이름은 모델이 기대하는 이름과 일치해야 해요.

PyTorch Backend 특별 규칙

명명 규칙 (Naming Convention):

TorchScript 모델 파일의 입력/출력에 대한 충분한 메타데이터가 없기 때문에, 구성의 입력/출력 "name" 속성은 특정 명명 규칙을 따라야 해요. 아래에 자세히 나와 있어요.

1. [입력 전용] 입력이 텐서 딕셔너리(Dictionary of Tensors)가 아닐 때, 구성 파일의 입력 이름은 모델 정의에서 forward 함수의 입력 인자 이름과 동일해야 해요.

   예를 들어 Torchscript 모델의 forward 함수가 forward(self, input0, input1)로 정의됐다면, 첫 번째와 두 번째 입력은 각각 "input0"과 "input1"로 이름지어야 해요.

2. <name>__<index>: \<name\>은 어떤 문자열이어도 되고 \<index\>는 해당 입력/출력의 위치를 가리키는 정수 인덱스예요.

   즉 입력이 두 개이고 출력이 두 개라면, 첫 번째·두 번째 입력을 "INPUT__0", "INPUT__1"로, 첫 번째·두 번째 출력을 "OUTPUT__0", "OUTPUT__1"로 각각 이름지을 수 있어요.

3. 모든 입력(또는 출력)이 같은 명명 규칙을 따르지 않으면, 모델 구성에서 엄격한 순서를 강제해요. 즉 구성의 입력(또는 출력) 순서가 이 입력들의 실제 순서라고 가정해요.

텐서 딕셔너리(Dictionary of Tensors) 입력:

PyTorch backend는 모델에 입력을 텐서 딕셔너리 형태로 전달하는 것을 지원해요. 이는 모델에 문자열→텐서 매핑을 담은 단일 Dictionary 유형 입력이 있을 때만 지원돼요. 예를 들어 다음과 같은 형태의 입력을 기대하는 모델이 있다고 할게요:

{'A': tensor1, 'B': tensor2}

이 경우 구성의 입력 이름은 위의 <name>__<index> 명명 규칙을 따르면 안 돼요. 대신 이 경우 입력 이름은 해당 텐서의 문자열 'key' 값에 매핑해야 해요. 이 경우 입력은 "A"와 "B"가 되며, 입력 "A"는 tensor1에 해당하는 값을, "B"는 tensor2에 해당하는 값을 가리켜요.

입력·출력 텐서에 허용되는 데이터 타입은 모델 유형에 따라 달라져요. Datatypes 섹션은 허용되는 데이터 타입과 각 모델 유형의 데이터 타입으로 어떻게 매핑되는지 설명해요.

입력 모양은 모델이 그리고 추론 요청에서 Triton이 기대하는 입력 텐서의 모양을 나타내요. 출력 모양은 모델이 생성하고 추론 요청에 대한 응답으로 Triton이 반환하는 출력 텐서의 모양을 나타내요. 입력·출력 모양은 모두 랭크가 1 이상이어야 해요. 즉 빈 모양 **[ ]**은 허용되지 않아요.

입력·출력 모양은 max_batch_size와 입력·출력 dims 속성이 지정하는 차원의 조합으로 명시돼요. max_batch_size가 0보다 큰 모델의 경우 전체 모양은 [ -1 ] + dims로 구성돼요. max_batch_size가 0인 모델의 경우 전체 모양은 dims로 구성돼요. 예를 들어 아래 구성에서 "input0"의 모양은 [-1, 16], "output0"의 모양은 [ -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"의 모양이 [ 16 ], "output0"의 모양이 [ 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 ]
    }
  ]

가변 크기 차원을 가진 입력·출력 텐서를 지원하는 모델의 경우, 그 차원을 입력·출력 구성에 -1로 나열할 수 있어요. 예를 들어 모델이 2차원 입력 텐서를 요구하는데 첫 번째 차원은 크기 4여야 하고 두 번째 차원은 아무 크기나 될 수 있다면, 그 입력의 모델 구성은 *dims: [ 4, -1 ]*을 포함해요. 그러면 Triton은 그 입력 텐서의 두 번째 차원이 0 이상의 어떤 값이든 가진 추론 요청을 받아들여요. 모델 구성은 밑바탕 모델이 허용하는 것보다 더 제한적일 수 있어요. 예를 들어 프레임워크 모델 자체가 두 번째 차원을 아무 크기나 허용하더라도, 모델 구성은 *dims: [ 4, 4 ]*로 지정할 수 있어요. 이 경우 Triton은 입력 텐서 모양이 정확히 *[ 4, 4 ]*인 추론 요청만 받아들여요.

Triton이 추론 요청에서 받는 입력 모양과 모델이 기대하는 입력 모양이 불일치하면 반드시 reshape 속성을 사용해야 해요. 마찬가지로 모델이 생성하는 출력 모양과 Triton이 추론 요청에 대한 응답으로 반환하는 모양이 불일치하면 reshape 속성을 사용해야 해요.

모델 입력은 allow_ragged_batch를 지정해 해당 입력이 ragged 입력임을 나타낼 수 있어요. 이 필드는 동적 배처와 함께 쓰여 모든 요청에서 입력이 같은 모양일 것을 강제하지 않고 배치를 가능하게 해요.

자동 생성 모델 구성 (Auto-Generated Model Configuration)

Triton에 배포할 각 모델에는 필수 설정을 담은 모델 구성 파일이 있어야 해요. 어떤 경우에는 모델 구성의 필수 부분을 Triton이 자동으로 생성할 수 있어요. 모델 구성의 필수 부분은 최소 모델 구성에 표시된 설정들이에요. 기본적으로 Triton은 이 섹션들을 완성하려고 시도해요. 그러나 --disable-auto-complete-config 옵션으로 Triton을 시작하면 백엔드 쪽에서 모델 구성을 자동 완성하지 않도록 구성할 수 있어요. 다만 이 옵션을 써도 Triton은 빠진 instance_group 설정은 기본값으로 채워요.

Triton은 대부분의 TensorRT saved-model, ONNX 모델, OpenVINO 모델에서 필요한 설정을 모두 자동으로 유도할 수 있어요. Python 모델의 경우 Python backend에서 auto_complete_config 함수를 구현해 set_max_batch_size, add_input, add_output 함수로 max_batch_size, input, output 속성을 제공할 수 있어요. 이 속성들 덕분에 Triton은 구성 파일이 없어도 최소 모델 구성으로 Python 모델을 로드할 수 있어요. 다른 모든 모델 유형은 모델 구성 파일을 반드시 제공해야 해요.

커스텀 backend를 개발할 때 구성의 필수 설정을 채우고 TRITONBACKEND_ModelSetConfig API를 호출해 완성된 구성을 Triton core와 갱신할 수 있어요. Onnxruntime backend를 어떻게 달성하는지의 예로 볼 수 있어요. 현재 backend가 채울 수 있는 설정은 inputs, outputs, max_batch_size, dynamic batching뿐이에요. 커스텀 backend의 경우 config.pbtxt 파일은 backend 필드를 포함하거나 모델 이름이 <model_name>.<backend_name> 형태여야 해요.

Triton이 모델에 대해 생성한 모델 구성은 model configuration endpoint로도 볼 수 있어요. 가장 쉬운 방법은 curl 같은 유틸리티를 쓰는 거예요:

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

이렇게 하면 생성된 모델 구성의 JSON 표현이 반환돼요. 이 JSON의 max_batch_size, inputs, outputs 섹션을 가져가 config.pbtxt 파일로 변환할 수 있어요. Triton은 모델 구성의 최소 부분만 생성해요. 모델 구성의 선택 부분은 여전히 config.pbtxt 파일을 편집해 직접 제공해야 해요.

커스텀 모델 구성 (Custom Model Configuration)

때로는 하나의 모델 저장소를 공유하는 여러 Triton 인스턴스가 각 플랫폼에서 최상의 성능을 내려면 모델을 다르게 구성해야 할 때가 있어요. Triton은 --model-config-name 옵션을 설정해 커스텀 모델 구성 이름을 고를 수 있게 해줘요.

예를 들어 ./tritonserver --model-repository=</path/to/model/repository> --model-config-name=h100으로 실행하면, 서버는 로드되는 각 모델에 대해 /path/to/model/repository/<model-name>/configs 디렉토리 아래에서 커스텀 구성 파일 h100.pbtxt를 찾아요. h100.pbtxt가 존재하면 그 파일이 이 모델의 구성으로 사용돼요. 그렇지 않으면 설정에 따라 기본 구성 /path/to/model/repository/<model-name>/config.pbtxt 또는 자동 생성 모델 구성이 선택돼요.

커스텀 모델 구성은 Explicit와 Poll 모델 제어 모드에서도 동작해요. 사용자가 커스텀 구성을 삭제하거나 추가할 수 있고, 서버는 로드된 각 모델에 대해 구성 파일을 동적으로 선택해요.

참고: 커스텀 모델 구성 이름에는 공백 문자를 포함하면 안 돼요.

예제 1: --model-config-name=h100

.
└── model_repository/
    ├── model_a/
    │   ├── configs/
    │   │   ├── v100.pbtxt
    │   │   └── **h100.pbtxt**
    │   └── config.pbtxt
    ├── model_b/
    │   ├── configs/
    │   │   └── v100.pbtxt
    │   └── **config.pbtxt**
    └── model_c/
        ├── configs/
        │   └── config.pbtxt
        └── **config.pbtxt**

예제 2: --model-config-name=config

.
└── model_repository/
    ├── model_a/
    │   ├── configs/
    │   │   ├── v100.pbtxt
    │   │   └── h100.pbtxt
    │   └── **config.pbtxt**
    ├── model_b/
    │   ├── configs/
    │   │   └── v100.pbtxt
    │   └── **config.pbtxt**
    └── model_c/
        ├── configs/
        │   └── **config.pbtxt**
        └── config.pbtxt

예제 3: --model-config-name 미설정

.
└── model_repository/
    ├── model_a/
    │   ├── configs/
    │   │   ├── v100.pbtxt
    │   │   └── h100.pbtxt
    │   └── **config.pbtxt**
    ├── model_b/
    │   ├── configs/
    │   │   └── v100.pbtxt
    │   └── **config.pbtxt**
    └── model_c/
        ├── configs/
        │   └── config.pbtxt
        └── **config.pbtxt**

기본 최대 배치 크기와 동적 배처 (Default Max Batch Size and Dynamic Batcher)

모델이 auto-complete 기능을 사용할 때 --backend-config=default-max-batch-size=<int> 커맨드라인 인자로 기본 최대 배치 크기를 설정할 수 있어요. 이렇게 하면 배치가 가능하고 자동 생성 모델 구성을 사용하는 모든 모델이 기본 최대 배치 크기를 가질 수 있어요. 이 값은 기본적으로 4로 설정돼요. backend 개발자는 TRITONBACKEND_BackendConfig API에서 이 default-max-batch-size를 얻어 사용할 수 있어요. 현재 생성된 모델 구성에서 이 기본 배치 값을 활용하고 동적 배치를 켜는 backend는 다음과 같아요:

1. Onnxruntime backend

2. TensorRT backend

   1. TensorRT 모델은 최대 배치 크기를 명시적으로 저장하며 default-max-batch-size 파라미터를 사용하지 않아요. 그러나 max_batch_size > 1이고 스케줄러가 제공되지 않으면 동적 배치 스케줄러가 켜져요.

모델의 최대 배치 크기가 1보다 큰 값으로 설정되고 구성 파일에 스케줄러가 제공되지 않으면 dynamic_batching 구성이 설정돼요.

데이터 타입 (Datatypes)

아래 표는 Triton이 지원하는 텐서 데이터 타입을 보여줘요. 첫 번째 열은 모델 구성 파일에 나타나는 데이터 타입 이름이에요. 다음 네 열은 지원되는 모델 프레임워크의 해당 데이터 타입이에요. 모델 프레임워크가 특정 데이터 타입에 대한 항목이 없으면 Triton은 그 모델에 대해 그 데이터 타입을 지원하지 않아요. "API"로 표시된 여섯 번째 열은 TRITONSERVER C API, TRITONBACKEND C API, HTTP/REST 프로토콜, GRPC 프로토콜의 해당 데이터 타입이에요. 마지막 열은 Python numpy 라이브러리의 해당 데이터 타입이에요.

Model Config	TensorRT	ONNX Runtime	PyTorch	API	NumPy
TYPE_BOOL	kBOOL	BOOL	kBool	BOOL	bool
TYPE_UINT8	kUINT8	UINT8	kByte	UINT8	uint8
TYPE_UINT16		UINT16		UINT16	uint16
TYPE_UINT32		UINT32		UINT32	uint32
TYPE_UINT64		UINT64		UINT64	uint64
TYPE_INT8	kINT8	INT8	kChar	INT8	int8
TYPE_INT16		INT16	kShort	INT16	int16
TYPE_INT32	kINT32	INT32	kInt	INT32	int32
TYPE_INT64	kINT64	INT64	kLong	INT64	int64
TYPE_FP16	kHALF	FLOAT16		FP16	float16
TYPE_FP32	kFLOAT	FLOAT	kFloat	FP32	float32
TYPE_FP64		DOUBLE	kDouble	FP64	float64
TYPE_STRING		STRING		BYTES	dtype(object)
TYPE_BF16	kBF16			BF16

TensorRT에서 각 값은 nvinfer1::DataType 네임스페이스에 있어요. 예를 들어 nvinfer1::DataType::kFLOAT는 32비트 부동소수점 데이터 타입이에요.

ONNX Runtime에서 각 값에는 ONNX_TENSOR_ELEMENT_DATA_TYPE_가 붙어요. 예를 들어 ONNX_TENSOR_ELEMENT_DATA_TYPE_FLOAT는 32비트 부동소수점 데이터 타입이에요.

PyTorch에서 각 값은 torch 네임스페이스에 있어요. 예를 들어 torch::kFloat는 32비트 부동소수점 데이터 타입이에요.

Numpy에서 각 값은 numpy 모듈에 있어요. 예를 들어 numpy.float32는 32비트 부동소수점 데이터 타입이에요.

리셰이프 (Reshape)

모델 구성 입력·출력의 ModelTensorReshape 속성은 추론 API가 받아들이는 입력·출력 모양이 밑바탕 프레임워크 모델 또는 커스텀 backend가 기대하거나 생성하는 입력·출력 모양과 다르다는 것을 나타내는 데 사용돼요.

입력의 경우 reshape를 써서 입력 텐서를 프레임워크·backend가 기대하는 다른 모양으로 리셰이프할 수 있어요. 흔한 사용 사례는 배치를 지원하는 모델이 배치된 입력이 [ batch-size ] 모양을 기대하는 경우예요. 이는 배치 차원이 모양을 완전히 설명한다는 뜻이에요. 추론 API에서는 각 입력이 비어 있지 않은 dims를 지정해야 하므로 동등한 모양 *[ batch-size, 1 ]*을 지정해야 해요. 이 경우 입력은 다음과 같이 지정해야 해요:

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

출력의 경우 reshape를 써서 프레임워크·backend가 생성하는 출력 텐서를 추론 API가 반환하는 다른 모양으로 리셰이프할 수 있어요. 흔한 사용 사례는 배치를 지원하는 모델이 배치된 출력이 [ batch-size ] 모양을 기대하는 경우예요. 이는 배치 차원이 모양을 완전히 설명한다는 뜻이에요. 추론 API에서는 각 출력이 비어 있지 않은 dims를 지정해야 하므로 동등한 모양 *[ batch-size, 1 ]*을 지정해야 해요. 이 경우 출력은 다음과 같이 지정해야 해요:

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

셰이프 텐서 (Shape Tensors)

셰이프 텐서를 지원하는 모델의 경우, 셰이프 텐서로 동작하는 입력·출력에 대해 is_shape_tensor 속성을 적절히 설정해야 해요. 아래는 셰이프 텐서를 지정하는 예제 구성이에요.

  name: "myshapetensormodel"
  platform: "tensorrt_plan"
  max_batch_size: 8
  input [
    {
      name: "input0"
      data_type: TYPE_FP32
      dims: [ 1 , 3]
    },
    {
      name: "input1"
      data_type: TYPE_INT32
      dims: [ 2 ]
      is_shape_tensor: true
    }
  ]
  output [
    {
      name: "output0"
      data_type: TYPE_FP32
      dims: [ 1 , 3]
    }
  ]

위에서 논의했듯, Triton은 배치가 입력·출력 텐서 dims에 나열되지 않은 첫 번째 차원을 따라 일어난다고 가정해요. 그러나 셰이프 텐서의 경우 배치는 첫 번째 셰이프 값에서 일어나요. 위 예의 경우 추론 요청은 다음 모양의 입력을 제공해야 해요.

  "input0": [ x, 1, 3]
  "input1": [ 3 ]
  "output0": [ x, 1, 3]

여기서 x는 요청의 배치 크기예요. Triton은 배치를 사용할 때 셰이프 텐서가 모델에서 셰이프 텐서로 표시되도록 요구해요. "input1"은 모델 구성에 설명된 *[ 2 ]*가 아니라 [ 3 ] 모양이라는 점에 주의하세요. myshapetensormodel 모델은 배칭 모델이므로 배치 크기가 추가 값으로 제공되어야 해요. Triton은 모델에 요청을 발행하기 전에 배치 차원에서 "input1"의 모든 셰이프 값을 함께 누적해요.

예를 들어 클라이언트가 다음 입력으로 Triton에 세 요청을 보낸다고 가정할게요:

Request1:
input0: [[[1,2,3]]] <== shape of this tensor [1,1,3]
input1: [1,4,6] <== shape of this tensor [3]

Request2:
input0: [[[4,5,6]], [[7,8,9]]] <== shape of this tensor [2,1,3]
input1: [2,4,6] <== shape of this tensor [3]

Request3:
input0: [[[10,11,12]]] <== shape of this tensor [1,1,3]
input1: [1,4,6] <== shape of this tensor [3]

이 요청들이 함께 배치되면 모델에 다음과 같이 전달돼요:

Batched Requests to model:
input0: [[[1,2,3]], [[4,5,6]], [[7,8,9]], [[10,11,12]]] <== shape of this tensor [4,1,3]
input1: [4, 4, 6] <== shape of this tensor [3]

현재 셰이프 텐서는 TensorRT만 지원해요. 셰이프 텐서에 대해 더 배우려면 Shape Tensor I/O를 읽어 보세요.

비선형 I/O 포맷 (Non-Linear I/O Formats)

비선형 포맷으로 입력·출력 데이터를 처리하는 모델의 경우 is_non_linear_format_io 속성을 설정해야 해요. 아래 예제 모델 구성은 INPUT0과 INPUT1이 비선형 I/O 데이터 포맷을 사용한다는 것을 지정하는 방법을 보여줘요.

  name: "mytensorrtmodel"
  platform: "tensorrt_plan"
  max_batch_size: 8
  input [
    {
      name: "INPUT0"
      data_type: TYPE_FP16
      dims: [ 3,224,224 ]
      is_non_linear_format_io: true
    },
    {
      name: "INPUT1"
      data_type: TYPE_FP16
      dims: [ 3,224,224 ]
      is_non_linear_format_io: true
    }
  ]
  output [
    {
      name: "OUTPUT0"
      data_type: TYPE_FP16
      dims: [ 1,3 ]
     }
  ]

현재 이 속성은 TensorRT만 지원해요. I/O 포맷에 대해 더 배우려면 I/O Formats 문서를 참고하세요.

버전 정책 (Version Policy)

각 모델은 하나 이상의 버전을 가질 수 있어요. 모델 구성의 ModelVersionPolicy 속성은 다음 정책 중 하나를 설정하는 데 사용돼요.

• All: 모델 저장소에 가용한 모델의 모든 버전이 추론에 사용 가능해요. version_policy: { all: {}}

• Latest: 저장소에 있는 모델 중 가장 최근 'n'개의 버전만 추론에 사용 가능해요. 모델의 최신 버전은 숫자로 가장 큰 버전 번호예요. version_policy: { latest: { num_versions: 2}}

• Specific: 명시적으로 나열된 모델 버전만 추론에 사용 가능해요. version_policy: { specific: { versions: [1,3]}}

버전 정책이 지정되지 않으면 Latest(n=1)가 기본으로 사용돼, 모델의 가장 최근 버전만 Triton이 제공한다는 뜻이에요. 어떤 경우든 모델 저장소에서 버전 하위 디렉토리의 추가·제거는 이후 추론 요청에 어떤 모델 버전이 사용되는지 바꿀 수 있어요.

다음 구성은 서버에서 모델의 모든 버전을 제공한다는 것을 지정해요.

  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 ]
    }
  ]
  version_policy: { all { }}

인스턴스 그룹 (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 모델 인스턴스

instance group 설정은 모델을 CPU에서 실행하도록 하는 데도 사용돼요. 시스템에 GPU가 있어도 모델을 CPU에서 실행할 수 있어요. 다음은 CPU에 실행 인스턴스 두 개를 배치해요.

  instance_group [
    {
      count: 2
      kind: KIND_CPU
    }
  ]

KIND_CPU 인스턴스 그룹에 count를 지정하지 않으면 선택된 백엔드(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은 선택적으로 그 그룹의 인스턴스에 레이트 리미터가 어떻게 동작하는지 제어하는 rate limiter 구성을 지정해요. 레이트 제한이 꺼져 있으면 레이트 리미터 구성은 무시돼요. 레이트 제한이 켜져 있고 instance_group이 이 구성을 제공하지 않으면, 이 그룹에 속한 모델 인스턴스의 실행은 레이트 리미터가 어떤 방식으로도 제한하지 않아요. 구성은 다음 사양을 포함해요:

리소스 (Resources)

모델 인스턴스를 실행하는 데 필요한 리소스 집합이에요. "name" 필드는 리소스를 식별하고 "count" 필드는 그룹의 모델 인스턴스가 실행하는 데 필요한 리소스 복사본 수를 가리켜요. "global" 필드는 리소스가 디바이스별인지 시스템 전체에 걸쳐 전역으로 공유되는지 지정해요. 로드된 모델은 같은 이름의 리소스를 global과 non-global 둘 다로 지정할 수 없어요. 리소스가 제공되지 않으면 triton은 모델 인스턴스의 실행에 리소스가 필요하지 않다고 가정하고 모델 인스턴스가 가용해지는 즉시 실행을 시작해요.

우선순위 (Priority)

우선순위는 모든 모델의 모든 인스턴스에 걸쳐 우선순위를 정하는 데 쓰이는 가중치 값 역할을 해요. 우선순위 2인 인스턴스는 우선순위 1인 인스턴스보다 스케줄링 기회를 절반 받아요.

다음 예제는 그룹의 인스턴스가 실행에 "R1" 네 개와 "R2" 두 개 리소스를 요구한다는 것을 지정해요. 리소스 "R2"는 global 리소스예요. 추가로 instance_group의 레이트 리미터 우선순위는 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"을 두고 경쟁해요.

앙상블 모델 인스턴스 그룹 (Ensemble Model Instance Groups)

앙상블 모델은 Triton이 사용자 정의 모델 파이프라인을 실행하는 데 쓰는 추상화예요. 앙상블 모델과 연결된 물리적 인스턴스가 없기 때문에 그에 대해 instance_group 필드를 지정할 수 없어요.

그러나 앙상블을 구성하는 각 모델은 자기 구성 파일에서 instance_group을 지정할 수 있고, 앙상블이 여러 요청을 받을 때 위에서 설명한 것처럼 개별적으로 병렬 실행을 지원할 수 있어요.

CUDA Compute Capability

default_model_filename 필드와 비슷하게, cc_model_filenames 필드를 선택적으로 지정해 GPU의 CUDA Compute Capability를 모델 로드 시 해당 모델 파일 이름에 매핑할 수 있어요. TensorRT 모델은 일반적으로 특정 compute capability에 묶여 있으므로 특히 유용해요.

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

최적화 정책 (Optimization Policy)

모델 구성 ModelOptimizationPolicy 속성은 모델에 대한 최적화·우선순위 설정을 지정하는 데 쓰여요. 이 설정들은 백엔드가 모델을 최적화하는지/어떻게 최적화하는지, 그리고 Triton이 모델을 어떻게 스케줄링하고 실행하는지 제어해요. 현재 사용 가능한 설정은 ModelConfig protobuf와 optimization 문서를 참고하세요.

모델 워밍업 (Model Warmup)

모델이 Triton에 로드되면 해당 backend가 그 모델을 위해 초기화돼요. 일부 backend에서는 이 초기화의 일부 또는 전부가 모델이 첫 추론 요청(또는 처음 몇 개의 추론 요청)을 받을 때까지 지연돼요. 결과적으로 첫 번째(몇 개) 추론 요청이 지연 초기화 때문에 현저히 느려질 수 있어요.

이런 초기 느린 추론 요청을 피하기 위해 Triton은 모델을 "워밍업"해서 첫 추론 요청을 받기 전에 완전히 초기화되도록 하는 구성 옵션을 제공해요. 모델 구성에 ModelWarmup 속성이 정의되면 Triton은 모델 워밍업이 완료될 때까지 그 모델을 추론 준비 완료 상태로 표시하지 않아요.

모델 구성 ModelWarmup은 모델의 워밍업 설정을 지정하는 데 쓰여요. 설정은 각 모델 인스턴스를 워밍업하기 위해 Triton이 만들어낼 일련의 추론 요청을 정의해요. 모델 인스턴스는 요청을 성공적으로 완료해야만 서빙돼요. 워밍업 모델의 효과는 프레임워크 backend에 따라 다르고, 모델 업데이트에 대해 Triton의 반응성을 떨어뜨리므로, 사용자는 실험해 자기 요구에 맞는 구성을 선택해야 한다는 점을 주의하세요. 현재 사용 가능한 설정은 ModelWarmup protobuf 문서를, 다양한 워밍업 샘플 변형 지정 예제는 L0_warmup을 참고하세요.

응답 캐시 (Response Cache)

모델 구성의 response_cache 섹션에는 이 모델에 대한 Response Cache를 켜는 데 쓰이는 enable 불리언이 있어요.

response_cache {
  enable: true
}

모델 구성에서 캐시를 켜는 것에 더해, 서버 쪽에서 캐싱을 켜려면 서버를 시작할 때 --cache-config를 지정해야 해요. 서버 측 캐싱 켜기에 대한 자세한 내용은 Response Cache 문서를 참고하세요.

더 알아보기 (Learn more)

• 모델 저장소 (Model Repository) — 구성 파일·버전·파일 배치
• 동시 모델 실행 (Concurrent Model Execution) — stateless·stateful 모델
• 동적 배치 (Batchers) — 동적 배처 구성

출처: 공식문서 (Model Configuration)