Triton schedule policy 怎样给单个请求设置排队超时

Triton 里想给某一个推理请求设置排队超时，关键不是把 HTTP 客户端的等待时间调小，而是在请求的 parameters 中传入 timeout。这个值按微秒计算，并且主要由启用了 dynamic batching 的模型调度器处理；模型队列策略还要允许请求覆盖默认值。

官方文档：https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/protocol/extension_schedule_policy.html

最小可用组合是：模型的 ModelQueuePolicy.allow_timeout_override 打开，请求传 parameters.timeout，并用 timeout_action 决定超时后的处理方式。priority 只改变队列优先级，不表示等待多少微秒。

先确认模型真的允许单请求覆盖

如果请求带了 timeout 却没有按预期生效，先看模型的 config.pbtxt。Triton 的动态批处理默认是一个队列；只有配置了优先级层级时，priority 才能让高优先级请求绕过低优先级请求。排队超时则由队列策略中的几个字段共同决定。

dynamic_batching {
  # 允许请求加入动态批处理；这里只示意队列策略，不绑定具体后端
  preferred_batch_size: [ 4, 8 ]
  default_queue_policy {
    # 排队超过请求或默认超时后，直接拒绝该请求
    timeout_action: REJECT
    # 没有单请求覆盖时使用 2 秒，单位是微秒
    default_timeout_microseconds: 2000000
    # 允许请求 parameters.timeout 覆盖默认排队超时
    allow_timeout_override: true
    # 限制队列中的请求数量，避免只靠超时兜底
    max_queue_size: 128
  }
}

这里的 default_timeout_microseconds 是默认值，allow_timeout_override 才是“允许单请求自定义”的开关。timeout_action 决定超时后的策略，具体行为要以当前 Triton 版本和模型配置为准。先确认服务器元数据包含 schedule_policy 扩展，再检查模型确实使用 dynamic batching。

HTTP 请求里把 timeout 写成微秒整数

HTTP/REST 使用 KServe V2 的 parameters 字段传递请求级参数。比如想给当前请求设置 5 秒排队超时，就传 5000000，不要写成字符串，也不要把单位误当成毫秒。

{
  "parameters": {
    "timeout": 5000000,
    "priority": 1
  },
  "inputs": [
    {
      "name": "INPUT0",
      "shape": [1, 16],
      "datatype": "FP32",
      "data": [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
    }
  ],
  "outputs": [{"name": "OUTPUT0"}]
}

上面的 JSON 中，timeout 表示当前请求的服务端调度超时，priority: 1 表示使用更高优先级；优先级数字越小越高，0 则回到模型默认优先级。两者可以同时传，但职责不同：前者是时间边界，后者是队列选择。

# 用 curl 发送一个带请求级调度参数的 V2 推理请求
curl -sS -X POST "http://127.0.0.1:8000/v2/models/demo/infer" \
  -H "Content-Type: application/json" \
  --data-binary @request.json

# 查看服务器是否声明了 schedule_policy 扩展
curl -sS "http://127.0.0.1:8000/v2" | jq '.extensions'

检查时先确认响应不是参数类型错误，再观察请求是否在模型队列策略允许的范围内结束。这个设置不等于“强制中断已经开始执行的模型计算”；它解决的是请求级调度边界。

把客户端 timeout 和 client_timeout 分开看

Python gRPC 客户端的 infer 方法同时暴露了两个容易混淆的参数。timeout 是传给 Triton 的服务端请求超时，单位是微秒；client_timeout 是客户端等待 RPC 的上限，单位是秒。只想控制队列策略时，先设置前者，后者要给网络和响应传输留出余量。

import tritonclient.grpc as grpcclient

# inputs 应按当前模型的输入名称、形状和数据类型提前构造
client = grpcclient.InferenceServerClient(url="127.0.0.1:8001")
result = client.infer(
    model_name="demo",
    inputs=inputs,
    # 服务端排队策略：5 秒，单位是微秒
    timeout=5_000_000,
    # 客户端 RPC 等待上限：给响应传输留出 8 秒
    client_timeout=8.0,
    # 只有模型配置了优先级队列时，priority 才有队列区分效果
    priority=1,
)
print(result)

如果 client_timeout 先到，客户端会先放弃等待，即使服务端仍在按自己的请求策略处理；如果 timeout 先到，服务端会按模型配置的超时动作处理。排查时把这两个值分别记在日志里，避免看到 “Deadline Exceeded” 就误以为是服务端队列超时。

运行检查与常见误区

可以按“配置—请求—响应”三层检查，定位为什么单请求超时看起来没有生效：

还有一个边界：文档对 dynamic batching 提供正式的 schedule-policy 支持；sequence batching 配合 direct scheduling 的支持仍属于实验阶段。不要把动态批处理的请求参数行为直接套到所有调度器上。

总结：只记住三个值的职责

• parameters.timeout：当前请求的服务端超时，单位微秒。
• priority：当前请求的队列优先级，数值越小优先级越高。
• client_timeout：客户端等待 RPC 的上限，单位秒，不是 Triton 队列策略。

因此，正确的落地顺序是先在模型队列策略中打开请求覆盖，再在 HTTP 或 gRPC 请求中传入微秒值，最后独立记录客户端等待上限。这样遇到超时现象时，才能判断是请求尚未出队、服务端已按策略处理，还是客户端提前结束了等待。

相关问题

Triton 的 timeout 是毫秒还是微秒？

schedule policy 的请求参数和 Python gRPC infer(timeout=...) 使用微秒；例如 5 秒应写成 5000000。

priority: 1 会自动创建高优先级队列吗？

不会。模型需要配置动态批处理的优先级层级；否则请求仍受默认单队列行为约束。