批处理器#

动态批处理器#

动态批处理是 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 中实现五个函数并创建一个共享库。这些函数在下面描述。

函数

描述

TRITONBACKEND_ModelBatchIncludeRequest

确定是否应将请求包含在当前批次中

TRITONBACKEND_ModelBatchInitialize

初始化新批次的记录保存数据结构

TRITONBACKEND_ModelBatchFinalize

在形成批次后释放记录保存数据结构的内存

TRITONBACKEND_ModelBatcherInitialize

初始化一个只读数据结构，用于所有批次

TRITONBACKEND_ModelBatcherFinalize

在模型卸载后释放只读数据结构的内存

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

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

序列批处理器#

与动态批处理器类似，序列批处理器组合了非批处理的推理请求，从而动态创建批次。与动态批处理器不同，序列批处理器应用于有状态模型，其中一系列推理请求必须路由到同一模型实例。动态创建的批次将分发到为模型配置的所有模型实例。

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

迭代序列#

[!NOTE] 迭代序列是临时的，并且可能会在未来版本中更改。序列批处理器支持“迭代序列”的有状态执行，其中单个请求在多个调度迭代中处理。“迭代序列”使调度器能够在每个步骤中批处理多个正在进行的请求，并允许模型或后端在任何迭代中完成请求。

对于支持“迭代序列”的模型和后端，用户可以通过指定以下内容在序列批处理器中启用支持

  sequence_batching {
    iterative_sequence: true
  }

“迭代序列”指的是有状态模型，它迭代处理单个请求，直到生成完整响应。启用迭代序列后，序列调度器将期望单个传入请求来启动序列。支持迭代序列的后端随后可以返回序列批处理器，以在未来的批次中重新调度请求以进行进一步执行。

由于仅使用一个请求来表示“迭代序列”，因此用户无需设置上一节中提到的控制输入。它们将由调度器在内部填充。

“迭代序列”可以是解耦的，其中在执行期间可以生成多个响应，也可以是非解耦的，其中在完整响应完成时生成单个响应。

“迭代序列”的主要优点是能够使用 Triton 的原生批处理功能在不同迭代阶段形成请求批次，而无需在后端维护额外的状态。通常，后端执行的批次在同一次执行中完成，如果批次中某个请求的执行时间比其余请求长得多，则可能会浪费资源。使用“迭代序列”，批次中每个请求的处理可以分解为多个迭代，并且后端可以在任何请求完成后立即开始处理新请求。

使用迭代序列的连续/飞行中批处理#

连续批处理、迭代级别批处理和飞行中批处理是大型语言模型 (LLM) 推理中使用的术语，用于描述在每个迭代步骤形成请求批次的批处理策略。通过“连续”形成批次，推理服务器可以通过在批次插槽空闲后立即重复使用它们来提高吞吐量，而无需等待批次中的所有请求完成。

由于处理请求所需的步骤数可能会有很大差异，因此连续批处理现有请求和新请求可以显着提高吞吐量和延迟。

为了使用迭代序列实现飞行中批处理，后端应将请求处理分解为多个步骤，其中每个步骤对应于一个 Triton 模型实例执行。在每个步骤结束时，模型实例将释放已完成的请求并重新调度仍在飞行中的请求。然后，Triton 将形成并调度下一个混合新请求和重新调度请求的批次。

本页内容