Triton dynamic batcher 怎么让高优先级请求先处理

在模型的 dynamic_batching 中启用 priority_levels，并让客户端请求携带 priority=1，即可让高优先级请求在动态批处理队列中越过较低优先级请求。数字越小优先级越高，1最高；0表示使用模型默认等级，不能拿0表示最高级。

官方地址：https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/user_guide/batcher.html

先确定要改善哪一类请求的等待

如果要给在线交互和后台任务共用一个模型，我会先分开看两类请求的尾延迟。只有整体平均值，很容易漏掉在线请求被后台积压拖慢的问题。本文提供配置与对照测量设计，没有运行服务或压测，也没有可声称的性能提升数字。

优先级解决的是已进入该模型调度队列的请求之间如何竞争机会。它不增加模型实例的计算能力，也不构成对正在执行推理的抢占承诺。如果主要时间耗在模型计算或客户端等待发送，单改队列等级未必有明显收益。

给动态批处理设置两个优先级

下面将在线请求约定为等级1，普通请求约定为等级2。默认等级也设成2，避免未改造的调用方自动进入最高级。将片段合并到真实模型的 config.pbtxt 中，不能用它替代完整模型配置；模型本身必须支持动态批处理。

# 合并到已有且支持批处理的模型配置；保留原有输入输出定义。
dynamic_batching {
  priority_levels: 2
  default_priority_level: 2  # 未指定优先级的请求归入普通级。

  default_queue_policy {
    max_queue_size: 128
    default_timeout_microseconds: 200000
    timeout_action: REJECT
    allow_timeout_override: false
  }
  priority_queue_policy {
    key: 1  # 数字1是最高级，不是最低级。
    value {
      max_queue_size: 32
      default_timeout_microseconds: 50000
      timeout_action: REJECT
      allow_timeout_override: true
    }
  }
}

这里的32、128、50000与200000均为教学参数。50000微秒是50毫秒，200000微秒是200毫秒，不代表推荐的服务目标。等级2没有单独条目，因此使用 default_queue_policy；等级1采用自己的队列策略。等级配置和队列策略是两个维度：前者规定相对优先关系，后者规定允许积压和等待多久。

让客户端明确携带请求等级

只修改服务端配置，不让调用方区分请求，通常不会得到预期分流。Python HTTP客户端可以通过 infer 的 priority 参数携带等级：

def infer_by_class(client, model_name, inputs, urgent=False):
    # inputs 由调用方按真实模型定义构造；优先级属于请求元数据。
    level = 1 if urgent else 2
    return client.infer(
        model_name=model_name,
        inputs=inputs,
        priority=level,
        request_id="interactive" if urgent else "background",
    )

这是集成函数，调用方提供真实客户端、模型名与输入对象，不包含可直接运行的示例模型。request_id 便于关联记录，不决定优先级；实际并发测量时应给每个请求使用独立ID。没有指定等级或传0的请求使用默认等级，本例是2。不要发送超出已配置范围的等级并期望它自动映射。

还要让两类负载确实同时到达服务端。若客户端严格串行发送，上一条结束后才发下一条，几乎没有排队竞争，无法用完成顺序判断优先级是否发挥作用。同一等级内部仍按到达顺序处理。

分别约束各级队列的容量和超时

max_queue_size 表示队列能容纳多少请求，队满时新请求会被拒绝。它不是批大小，也不是为高优先级预留的GPU执行槽位。把队列扩大，只是允许更多请求等待，不会让它们更快完成。

default_timeout_microseconds 控制队列等待的超时策略。示例选择 REJECT，让失去等待价值的请求返回错误；若使用 DELAY，超时请求会被延后，持续新流量可能使其长时间得不到处理，不能把它理解为超时后立即执行。

等级1的 allow_timeout_override: true 允许单个请求采用比默认值更短的超时，不允许借此延长默认上限。不要把队列超时解释成完整HTTP调用的硬性截止时间，也不要与为了凑批而等待的 max_queue_delay_microseconds 混为一谈。计算和传输时间还需要单独考虑。

用分组指标判断是否值得保留

我的取舍标准是：在线请求更符合目标，同时普通请求的等待和失败仍能接受。只看到高优先级变快，不能说明整体服务已经更好。

可先保持模型、输入形状、实例数量、批处理参数和总到达负载一致，做一个所有请求均使用等级2的基线；随后只把在线类改成等级1。预热条件、在线与后台的负载比例、到达节奏也要相同，分别记录成功、超时和队满拒绝，避免只统计成功请求造成偏差。

这些是测量记录位置，不是结果。端到端延迟可由客户端按请求类别记录；需要解释服务端队列耗时时，应关联对应请求的服务端跟踪数据，不要从一个模型级聚合值推断每个等级的等待。

为什么高优先级不一定最先返回？排队优先关系不等于响应完成顺序。已开始执行的工作、请求计算差异和响应保序设置都可能影响观察。

能否保证普通请求永远不会饿死？这组配置没有给出这样的公平性保证。高等级长期占满负载时，应持续观察低等级等待与拒绝。

没有积压时还需要分级吗？优先级主要在竞争时体现价值。没有等待的低负载测试，通常不足以说明拥塞时的表现。

参考：动态批处理文档；模型队列策略字段；Python HTTP客户端参数。