Triton教程—模型设置

这是您第一次编写配置文件吗？查看本指南或本示例！
在这里插入图片描述

文章目录

Triton教程---模型设置
- 最小模型配置
- 名称、平台和后端
- 模型交互策略
- - 解耦
- 最大批量大小
- 输入和输出
- PyTorch 后端的特殊约定
- - 命名约定：
  - 张量字典作为输入：
- 自动生成的模型配置
- 默认最大批处理大小和动态批处理程序
- 数据类型
- Reshape
- 形状张量
- 版本策略
- 实例组
- 多个模型实例
- CPU型号实例
- 主机策略
- 速率限制器配置
- - 资源
  - 优先事项
  - 集成模型实例组
- CUDA计算能力
- 调度和批处理
- 默认调度程序
- 动态批处理器
- 推荐配置流程
- 首选批量大小
- 延迟批处理
- - 保留顺序
  - 优先级
  - 队列策略
  - 自定义批处理
- 序列批处理程序
- 集成调度器
- 优化策略
- 模型预热
- 响应缓存

模型存储库中的每个模型都必须包含一个模型配置，该配置提供有关模型的必需和可选信息。通常，此配置在指定为 ModelConfig protobuf 的 config.pbtxt 文件中提供。在某些情况下，如自动生成的模型配置中所述，模型配置可以由 Triton 自动生成，因此不需要明确提供。

本节介绍最重要的模型配置属性，但还应查阅 ModelConfig protobuf 中的文档。

最小模型配置

最小模型配置必须指定平台和/或后端属性、max_batch_size 属性以及模型的输入和输出张量。

例如，考虑一个 TensorRT 模型，它有两个输入 input0 和 input1 以及一个输出 output0，所有这些都是 16 dims float32 张量。最低配置是：

  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 ]
    }
  ]

名称、平台和后端

模型配置名称属性是可选的。如果模型的名称未在配置中指定，则假定它与包含模型的模型存储库目录相同。如果指定了名称，它必须与包含模型的模型存储库目录的名称相匹配。后端文档中描述了平台和后端所需的值。

模型交互策略

model_transaction_policy 属性描述了模型预期的交互性质。

解耦

此布尔值设置指示模型生成的响应是否与向其发出的请求分离。使用解耦意味着模型生成的响应数量可能与发出的请求数量不同，并且响应相对于请求的顺序可能是乱序的。默认值为 false，这意味着模型将为每个请求生成一个响应。

最大批量大小

max_batch_size 属性指示模型支持的批处理类型的最大批大小，Triton 可以利用这些类型。如果模型的批次维度是第一个维度，并且模型的所有输入和输出都有这个批次维度，那么 Triton 可以使用其动态批处理程序或序列批处理程序自动对模型使用批处理。在这种情况下，max_batch_size 应设置为大于或等于 1 的值，表示 Triton 应与模型一起使用的最大批量大小。

对于不支持批处理的模型，或者不支持上述特定方式的批处理，max_batch_size 必须设置为零。

输入和输出

每个模型输入和输出都必须指定名称、数据类型和形状。为输入或输出张量指定的名称必须与模型预期的名称相匹配。

PyTorch 后端的特殊约定

命名约定：

由于 TorchScript 模型文件中输入/输出的元数据不足，配置中输入/输出的“名称”属性必须遵循特定的命名约定。这些在下面详述。

[仅适用于输入] 当输入不是张量字典时，配置文件中的输入名称应反映模型定义中前向函数的输入参数名称。

例如，如果 Torchscript 模型的前向函数定义为 forward(self, input0, input1)，则第一个和第二个输入应分别命名为“input0”和“input1”。
<name>__<index>：其中<name>可以是任意字符串，<index>是一个整数索引，表示相应输入/输出的位置。

这意味着如果有两个输入和两个输出，则第一个和第二个输入可以命名为“INPUT__0”和“INPUT__1”，而第一个和第二个输出可以分别命名为“OUTPUT__0”和“OUTPUT__1”。
如果所有输入（或输出）不遵循相同的命名约定，那么我们从模型配置中强制执行严格排序，即我们假设配置中输入（或输出）的顺序是这些输入的真实顺序。

张量字典作为输入：

PyTorch 后端支持以张量字典的形式将输入传递给模型。仅当包含字符串到张量的映射的字典类型模型有单个输入时才支持此功能。例如，如果有一个模型需要表单的输入：

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

这种情况下配置中的输入名称不能遵循上述命名约定<name>__<index>。相反，在这种情况下，输入的名称必须映射到该特定张量的字符串值“key”。对于这种情况，输入将是“A”和“B”，其中输入“A”是指对应于 tensor1 的值，“B”是指对应于 tensor2 的值。

输入和输出张量允许的数据类型因模型类型而异。数据类型部分描述了允许的数据类型以及它们如何映射到每个模型类型的数据类型。

输入形状表示模型和 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。例如，如果模型需要一个二维输入张量，其中第一个维度的大小必须为 4，而第二个维度可以是任何大小，则该输入的模型配置将包括 dims: [ 4, -1 ]。然后，Triton 将接受推理请求，其中输入张量的第二维是大于或等于 0 的任何值。模型配置可能比底层模型所允许的更具限制性。例如，即使框架模型本身允许第二个维度为任意大小，模型配置也可以指定为 dims: [ 4, 4 ]。在这种情况下，Triton 只会接受输入张量的形状恰好为 [ 4, 4 ] 的推理请求。

如果 Triton 在推理请求中收到的输入形状与模型预期的输入形状不匹配，则必须使用 reshape 属性。同样，如果模型生成的输出形状与 Triton 在对推理请求的响应中返回的形状不匹配，则必须使用重塑属性。

模型输入可以指定 allow_ragged_batch 以指示输入是参差不齐的输入。该字段与动态批处理程序一起使用，以允许在不强制输入在所有请求中具有相同形状的情况下进行批处理。

自动生成的模型配置

包含所需设置的模型配置文件必须可用于要在 Triton 上部署的每个模型。在某些情况下，模型配置的所需部分可以由 Triton 自动生成。模型配置的必需部分是最小模型配置中显示的设置。默认情况下，Triton 将尝试完成这些部分。但是，通过使用 --disable-auto-complete-config 选项启动 Triton，可以将 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、输入和输出属性。这些属性将允许 Triton 在没有配置文件的情况下使用最小模型配置加载 Python 模型。所有其他模型类型必须提供模型配置文件。

开发自定义后端时，您可以在配置中填充所需的设置并调用 TRITONBAACKEND_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 表示。从这里您可以获取 JSON 的 max_batch_size、输入和输出部分并将其转换为 config.pbtxt 文件。 Triton 仅生成模型配置的最小部分。您仍然必须通过编辑 config.pbtxt 文件来提供模型配置的可选部分。

默认最大批处理大小和动态批处理程序

当模型使用自动完成功能时，可以使用 --backend-config=default-max-batch-size=<int> 命令行参数设置默认的最大批量大小。这允许所有能够进行批处理并使用自动生成的模型配置的模型都具有默认的最大批处理大小。默认情况下，此值设置为 4。后端开发人员可以通过从 TRITONBACKEND_BackendConfig api 获取它来使用这个 default-max-batch-size。目前，以下使用这些默认批处理值并在其生成的模型配置中打开动态批处理的后端是：

TensorFlow 后端
Onnxruntime后端
TensorRT 后端

TensorRT 模型显式存储最大批量大小并且不使用 default-max-batch-size 参数。但是，如果 max_batch_size > 1 且未提供调度程序，则将启用动态批处理调度程序。

如果为模型设置的最大批量大小的值大于 1，则在配置文件中未提供调度程序的情况下将设置 dynamic_batching 配置。

数据类型

下表显示了 Triton 支持的张量数据类型。第一列显示模型配置文件中出现的数据类型的名称。接下来的四列显示了支持的模型框架的相应数据类型。如果模型框架没有给定数据类型的条目，则 Triton 不支持该模型的该数据类型。第六列，标记为“API”，显示了 TRITONSERVER C API、TRITONBACKEND C API、HTTP/REST 协议和 GRPC 协议的相应数据类型。最后一列显示了 Python numpy 库的相应数据类型。

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

对于 TensorRT，每个值都在 nvinfer1::DataType 命名空间中。例如，nvinfer1::DataType::kFLOAT 是 32 位浮点数据类型。

对于 TensorFlow，每个值都在 tensorflow 命名空间中。例如，tensorflow::DT_FLOAT 是 32 位浮点值。

对于 ONNX 运行时，每个值都带有 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 接受的输入或输出形状与底层框架模型或自定义后端预期或生成的输入或输出形状不同。

对于输入，Reshape可用于将输入张量Reshape为框架或后端期望的不同形状。一个常见的用例是支持批处理的模型期望批处理输入具有形状 [ batch-size ]，这意味着批处理维度完全描述了形状。对于推理 API，必须指定等效形状 [ batch-size, 1 ]，因为每个输入都必须指定一个非空的 dims。对于这种情况，输入应指定为：

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

对于输出，Reshape可用于将框架或后端生成的输出张量Reshape为推理 API 返回的不同形状。一个常见的用例是支持批处理的模型期望批处理输出具有形状 [batch-size]，这意味着批处理维度完全描述了形状。对于推理 API，必须指定等效形状 [ batch-size, 1 ]，因为每个输出都必须指定一个非空的 dims。对于这种情况，输出应指定为：

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

形状张量

对于支持形状张量的模型，必须为充当形状张量的输入和输出适当设置 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”的形状为 [ 3 ] 而不是 [ 2 ]，这是模型配置中描述的方式。由于 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 支持形状张量。阅读形状张量 I/O 以了解有关形状张量的更多信息。

版本策略

每个模型可以有一个或多个版本。模型配置的 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 { }}

实例组

Triton 可以提供模型的多个实例，以便可以同时处理对该模型的多个推理请求。模型配置 ModelInstanceGroup 属性用于指定应该可用的执行实例的数量以及应该为这些实例使用什么计算资源。

多个模型实例

默认情况下，为系统中可用的每个 GPU 创建模型的单个执行实例。实例组设置可用于将模型的多个执行实例放置在每个 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型号实例

实例组设置还用于启用在 CPU 上执行模型。即使系统中有可用的 GPU，模型也可以在 CPU 上执行。下面将两个执行实例放在 CPU 上。

  instance_group [
    {
      count: 2
      kind: KIND_CPU
    }
  ]

如果没有为 KIND_CPU 实例组指定计数，则所选后端（Tensorflow 和 Onnxruntime）的默认实例计数将为 2。所有其他后端将默认为 1。

主机策略

实例组设置与主机策略相关联。以下配置会将实例组设置创建的所有实例与主机策略“policy_0”相关联。默认情况下，主机策略将根据实例的设备类型进行设置，例如，KIND_CPU 是“cpu”，KIND_MODEL 是“model”，KIND_GPU 是“gpu_<gpu_id>”。

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

速率限制器配置

实例组可以选择指定速率限制器配置，该配置控制速率限制器如何在组中的实例上运行。如果速率限制关闭，则忽略速率限制器配置。如果启用了速率限制并且 instance_group 不提供此配置，则属于该组的模型实例的执行将不会以任何方式受到速率限制器的限制。配置包括以下规格：

资源

执行模型实例所需的资源集。 “name”字段标识资源，“count”字段是指组中的模型实例需要运行的资源副本数。 “全局”字段指定资源是按设备还是在系统中全局共享。加载的模型不能指定与全局和非全局同名的资源。如果没有提供资源，那么 triton 会假设模型实例的执行不需要任何资源，并且会在模型实例可用时立即开始执行。

优先事项

优先级用作权重值，用于对所有模型的所有实例进行优先级排序。优先级为 2 的实例将获得优先级为 1 的实例的 1/2 调度机会。

以下示例指定组中的实例需要四个“R1”和两个“R2”资源才能执行。资源“R2”是全局资源。此外，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
      }
    }
  ]

上面的配置创建了 3 个模型实例，每个设备一个（0、1 和 2）。这三个实例之间不会争用“R1”，因为“R1”对于它们自己的设备是本地的，但是，它们将争用“R2”，因为它被指定为全局资源，这意味着“R2”在整个系统中共享 . 尽管这些实例不会在它们之间竞争“R1”，但它们会与其他模型实例竞争“R1”，这些模型实例在其资源需求中包含“R1”并与它们在同一设备上运行。

集成模型实例组

集成模型是 Triton 用于执行用户定义的模型管道的抽象。由于没有与集成模型关联的物理实例，因此无法为其指定 instance_group 字段。

但是，构成集成的每个组合模型都可以在其配置文件中指定 instance_group，并在集成接收到多个请求时单独支持并行执行，如上所述。

CUDA计算能力

与 default_model_filename 字段类似，您可以选择指定 cc_model_filenames 字段以在模型加载时将 GPU 的 CUDA 计算能力映射到相应的模型文件名。这对于 TensorRT 模型特别有用，因为它们通常与特定的计算能力相关联。

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

调度和批处理

Triton 通过允许单个推理请求指定一批输入来支持批量推理。对一批输入的推理是同时执行的，这对 GPU 尤为重要，因为它可以大大提高推理吞吐量。在许多用例中，单个推理请求未进行批处理，因此，它们无法从批处理的吞吐量优势中获益。

推理服务器包含多种调度和批处理算法，支持许多不同的模型类型和用例。有关模型类型和调度程序的更多信息，请参阅模型和调度程序。

默认调度程序

如果在模型配置中未指定任何 scheduling_choice 属性，则默认调度程序用于模型。默认调度程序只是将推理请求分发到为模型配置的所有模型实例。

动态批处理器

动态批处理是 Triton 的一项功能，它允许服务器组合推理请求，以便动态创建批处理。创建一批请求通常会导致吞吐量增加。动态批处理程序应用于无状态模型。动态创建的批次分发到为模型配置的所有模型实例。

使用模型配置中的 ModelDynamicBatching 属性为每个模型独立启用和配置动态批处理。这些设置控制动态创建批处理的首选大小、请求在调度程序中可以延迟以允许其他请求加入动态批处理的最长时间，以及队列属性（例如队列大小、优先级和超时） . 有关动态批处理的更详细示例，请参阅本指南。

首选批量大小

preferred_batch_size 属性指示动态批处理程序应尝试创建的批处理大小。对于大多数模型，不应指定 preferred_batch_size，如推荐配置过程中所述。一个例外是为不同批量大小指定多个优化配置文件的 TensorRT 模型。在这种情况下，由于某些优化配置文件可能会比其他优化配置文件提供显着的性能改进，因此使用 preferred_batch_size 来表示那些更高性能的优化配置文件支持的批处理大小可能是有意义的。

以下示例显示了启用首选批大小为 4 和 8 的动态批处理的配置。

  dynamic_batching {
    preferred_batch_size: [ 4, 8 ]
  }

当模型实例可用于推理时，动态批处理程序将尝试根据调度程序中可用的请求创建批处理。按照收到请求的顺序将请求添加到批处理中。如果动态批处理程序可以形成一个首选大小的批次，它将创建一个最大可能的首选大小的批次并将其发送以进行推理。如果动态批处理程序无法形成首选大小的批次（或者如果动态批处理程序未配置任何首选批处理大小），它将发送一个可能小于模型允许的最大批处理大小的最大大小的批处理（但请参阅下一节以了解更改此行为的延迟选项）。

生成的批次的大小可以使用计数指标进行聚合检查。

延迟批处理

动态批处理程序可以配置为允许请求在调度程序中延迟有限的时间，以允许其他请求加入动态批处理。例如，以下配置为请求设置了最大延迟时间 100 微秒。

  dynamic_batching {
    max_queue_delay_microseconds: 100
  }

当无法创建最大大小（或首选大小）批处理时，max_queue_delay_microseconds 属性设置会更改动态批处理程序行为。当无法从可用请求创建最大或首选大小的批处理时，只要没有请求延迟超过配置的 max_queue_delay_microseconds 值，动态批处理程序就会延迟发送批处理。如果新请求在此延迟期间到达并允许动态批处理程序形成最大或首选批处理大小的批处理，则立即发送该批处理以进行推理。如果延迟到期，动态批处理程序将按原样发送批处理，即使它不是最大或首选大小。

保留顺序

preserve_ordering 属性用于强制所有响应以与收到请求相同的顺序返回。有关详细信息，请参阅 protobuf 文档。

优先级

默认情况下，动态批处理程序维护一个队列，其中包含模型的所有推理请求。请求按顺序处理和批处理。 priority_levels 属性可用于在动态批处理程序中创建多个优先级，以便允许具有较高优先级的请求绕过具有较低优先级的请求。优先级相同的请求按顺序处理。未设置优先级的推理请求使用 default_priority_level 属性进行调度。

队列策略

动态批处理程序提供了几个设置来控制请求如何排队等待批处理。

当未定义 priority_levels 时，可以使用 default_queue_policy 设置单个队列的 ModelQueuePolicy。当定义了 priority_levels 时，每个优先级都可以有不同的 ModelQueuePolicy，由 default_queue_policy 和 priority_queue_policy 指定。

ModelQueuePolicy 属性允许使用 max_queue_size 设置最大队列大小。 timeout_action、default_timeout_microseconds 和 allow_timeout_override 设置允许配置队列，以便在队列中的时间超过指定超时时拒绝或推迟单个请求。

自定义批处理

除了动态批处理程序的指定行为之外，您还可以设置自定义批处理规则。为此，您将在 tritonbackend.h 中实现五个函数并创建一个共享库。这些功能如下所述。

Function	Description
TRITONBACKEND_ModelBatchIncludeRequest	Determines whether a request should be included in the current batch
TRITONBACKEND_ModelBatchInitialize	Initializes a record-keeping data structure for a new batch
TRITONBACKEND_ModelBatchFinalize	Deallocates the record-keeping data structure after a batch is formed
TRITONBACKEND_ModelBatcherInitialize	Initializes a read-only data structure for use with all batches
TRITONBACKEND_ModelBatcherFinalize	Deallocates the read-only data structure after the model is unloaded

共享库的路径可以通过参数 TRITON_BATCH_STRATEGY_PATH 传递到模型配置中。如果未提供，动态批处理程序将在模型版本、模型和后端目录中按顺序查找名为 batchstrategy.so 的自定义批处理策略。如果找到，它将加载它。这使您可以轻松地在使用相同后端的所有模型之间共享自定义批处理策略。

有关如何创建和使用自定义批处理库的教程，请参阅后端示例目录。

序列批处理程序

与动态批处理程序一样，序列批处理程序结合了非批处理推理请求，以便动态创建批处理。与动态批处理程序不同，序列批处理程序应用于有状态模型，其中一系列推理请求必须路由到同一模型实例。动态创建的批次分发到为模型配置的所有模型实例。

使用模型配置中的 ModelSequenceBatching 属性为每个模型独立启用和配置序列批处理。这些设置控制序列超时以及配置 Triton 将如何向模型发送控制信号以指示序列开始、结束、就绪和相关 ID。有关更多信息和示例，请参阅有状态模型。

集成调度器

集成调度程序必须用于集成模型，不能用于任何其他类型的模型。

使用模型配置中的 ModelEnsembleScheduling 属性为每个模型独立启用和配置集成调度程序。这些设置描述了集成中包含的模型以及模型之间张量值的流动。有关更多信息和示例，请参阅集成模型。

优化策略

模型配置 ModelOptimizationPolicy 属性用于指定模型的优化和优先级设置。这些设置控制后端是否/如何优化模型以及 Triton 如何调度和执行模型。有关当前可用的设置，请参阅 ModelConfig protobuf 和优化文档。

模型预热

当 Triton 加载模型时，相应的后端会为该模型初始化。对于某些后端，此初始化的部分或全部被推迟，直到模型收到其第一个推理请求（或前几个推理请求）。因此，由于延迟初始化，第一个（少数）推理请求可能会显着变慢。

为了避免这些初始的、缓慢的推理请求，Triton 提供了一个配置选项，使模型能够“预热”，以便在收到第一个推理请求之前完全初始化。当模型配置中定义了 ModelWarmup 属性时，Triton 将不会显示模型准备好进行推理，直到模型预热完成。

模型配置 ModelWarmup 用于指定模型的预热设置。这些设置定义了一系列推理请求，Triton 将创建这些请求来预热每个模型实例。模型实例只有在成功完成请求后才会被提供。请注意，预热模型的效果因框架后端而异，并且会导致 Triton 对模型更新的响应较慢，因此用户应该试验并选择适合自己需要的配置。有关当前可用设置的 ModelWarmup protobuf 文档，以及有关指定不同预热样本变体的示例，请参阅 L0_warmup。