模型配置#

这是您第一次编写配置文件吗？ 请查看本指南或此示例！

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

本节介绍最重要的模型配置属性，但也应参考ModelConfig protobuf中的文档。

最小模型配置#

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

作为一个示例，考虑一个 TensorRT 模型，它有两个输入 input0 和 input1，以及一个输出 output0，所有这些都是 16 项 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 ]
    }
  ]

名称、平台和后端#

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

模型事务策略#

model_transaction_policy 属性描述了模型预期的事务性质。

解耦#

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

最大批大小#

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

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

输入和输出#

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

PyTorch 后端的特殊约定#

命名约定

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

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

例如，如果 Torchscript 模型的 forward 函数定义为 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 在对推理请求的响应中返回的形状不匹配，则必须使用 reshape 属性。

模型输入可以指定 allow_ragged_batch 以指示输入是不规则输入。该字段与动态批处理器一起使用，以允许批处理，而无需强制输入在所有请求中具有相同的形状。

自动生成的模型配置#

包含所需设置的模型配置文件必须与要在 Triton 上部署的每个模型一起提供。在某些情况下，模型配置的必需部分可以由 Triton 自动生成。模型配置的必需部分是最小模型配置中显示的设置。默认情况下，Triton 将尝试完成这些部分。但是，通过使用 --disable-auto-complete-config 选项启动 Triton，可以将 Triton 配置为不在后端自动完成模型配置。但是，即使使用此选项，Triton 仍将使用默认值填充缺少的 instance_group 设置。

对于大多数 TensorRT、TensorFlow saved-model、ONNX 模型和 OpenVINO 模型，Triton 可以自动派生所有必需的设置。对于 Python 模型，可以在 Python 后端中实现 auto_complete_config 函数，以使用 set_max_batch_size、add_input 和 add_output 函数提供 max_batch_size、input 和 output 属性。这些属性将允许 Triton 在没有配置文件的情况下使用最小模型配置加载 Python 模型。所有其他模型类型必须提供模型配置文件。

在开发自定义后端时，您可以在配置中填充必需的设置，并调用 TRITONBACKEND_ModelSetConfig API 以使用 Triton 核心更新已完成的配置。您可以查看 TensorFlow 和 Onnxruntime 后端，以了解如何实现此目的的示例。目前，只有输入、输出、max_batch_size 和动态批处理设置可以由后端填充。对于自定义后端，您的 config.pbtxt 文件必须包含一个 backend 字段，或者您的模型名称必须采用 <model_name>.<backend_name> 的形式。

您还可以使用模型配置端点查看 Triton 为模型生成的模型配置。最简单的方法是使用像 curl 这样的实用程序

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

这将返回生成的模型配置的 JSON 表示形式。您可以从中获取 JSON 的 max_batch_size、inputs 和 outputs 部分，并将其转换为 config.pbtxt 文件。Triton 仅生成模型配置的最小部分。您仍然必须通过编辑 config.pbtxt 文件来提供模型配置的可选部分。

自定义模型配置#

有时，当多个设备运行共享一个模型仓库的 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**

默认最大批大小和动态批处理器#

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

TensorFlow 后端
Onnxruntime 后端
TensorRT 后端
1. 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 库的相应数据类型。

模型配置	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	kINT64	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	kBF16				BF16

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

对于 TensorFlow，每个值都在 tensorflow 命名空间中。例如，tensorflow::DT_FLOAT 是 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 位浮点数据类型。

重塑#

模型配置输入或输出上的 ModelTensorReshape 属性用于指示推理 API 接受的输入或输出形状与底层框架模型或自定义后端期望或产生的输入或输出形状不同。

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

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

对于输出，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以了解有关形状张量的更多信息。

非线性 I/O 格式#

对于以非线性格式处理输入或输出数据的模型，必须设置 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 格式文档。

版本策略#

每个模型可以有一个或多个版本。模型配置的 ModelVersionPolicy 属性用于设置以下策略之一。

全部：模型仓库中可用的所有模型版本都可用于推理。version_policy: { all: {}}
最新：只有仓库中最新的 ‘n’ 个模型版本可用于推理。模型的最新版本是数值上最大的版本号。version_policy: { latest: { num_versions: 2}}
特定：只有明确列出的模型版本可用于推理。version_policy: { specific: { versions: [1,3]}}

如果未指定版本策略，则默认使用最新 (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 创建模型的单个执行实例。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 模型实例#

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

  instance_group [
    {
      count: 2
      kind: KIND_CPU
    }
  ]

如果未为 KIND_CPU 实例组指定 count，则对于选定的后端（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” 字段指的是组中模型实例运行所需的资源副本数。“global” 字段指定资源是按设备还是在整个系统中全局共享。加载的模型不能指定名称相同的资源，既作为全局资源又作为非全局资源。如果未提供资源，则 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"
  }
]

优化策略#

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

模型预热#

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

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

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

响应缓存#

模型配置 response_cache 部分具有一个 enable 布尔值，用于为此模型启用响应缓存。

response_cache {
  enable: true
}

除了在模型配置中启用缓存外，启动服务器时还必须指定 --cache-config，以在服务器端启用缓存。有关启用服务器端缓存的更多详细信息，请参阅响应缓存文档。