模型服务批处理队列的延迟与吞吐配置

模型服务批处理的核心不是盲目增大 batch size，而是在用户可接受的排队时间内凑出稳定批次，再用显存预算和端到端延迟验证收益。低并发时，等待窗口过长会直接抬高首 token 或整体响应时间；高并发时，批量上限过小又会让 GPU 吃不满。可以把策略拆成三层：队列最多等多久、一个批次最多容纳多少请求或 token、以及用什么指标决定下一轮调整。

官方参考：https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/user_guide/model_configuration.html

生成式服务参考：https://huggingface.co/docs/text-generation-inference/basic_tutorials/launcher

先用排队延迟换取可控批量

以 Triton 为例，dynamic_batching 会把同时到达的推理请求合并。max_queue_delay_microseconds 允许调度器短暂等待后续请求；时间到了，即使没有形成最大或首选批次，也会把当前批次送入模型。因此它是“最多愿意等多久”，不是“保证得到多大批次”。建议先从业务 p95 预算中扣除网络、排队、推理和序列化时间，剩余部分才是队列等待预算。

max_batch_size: 8
dynamic_batching {
  // 只允许队列短暂等待，数值单位是微秒。
  max_queue_delay_microseconds: 200
  // 只有确认模型在该批量上有稳定收益时才填写首选批次。
  preferred_batch_size: [ 4, 8 ]
}

上面的数字只是配置形状，不是通用推荐值。若低负载时请求经常单独到达，继续增大等待时间只会增加延迟；若高负载时批次长期接近上限而显存仍有余量，再通过压测逐步增加 max_batch_size。preferred_batch_size 也不要凭感觉填写，除非模型或后端在某些批量上确实有明确的优化档位。

吞吐上限由请求预算决定

生成式模型不能只按请求数理解批量：一个短提示词和一个长提示词占用的显存完全不同。TGI 用 max_batch_total_tokens 表示当前批次可容纳的潜在 token 总量，用 max_batch_prefill_tokens 限制输入提示词的 prefill 预算。前者更像总容量，后者防止一批长输入瞬间挤压正在生成的请求。

# 令牌预算示例：先限制单批总量，再限制一次 prefill 的输入压力
docker run --gpus=all --rm \
  -e MAX_BATCH_TOTAL_TOKENS=4096 \
  -e MAX_BATCH_PREFILL_TOKENS=2048 \
  -e MAX_INPUT_TOKENS=1024 \
  text-generation-inference:latest
# 生产环境应固定镜像版本，并在启动日志中记录最终生效值。

如果 max_batch_total_tokens 太小，短请求会频繁排队；太大则可能触发显存压力或让单个长请求挤占其他请求。输入长度、最大输出长度、量化方式和 KV cache 都会改变可承受范围，所以应以压测和 OOM 前的安全余量共同确定，而不是直接照搬机器上的默认值。

用指标把参数调到目标区间

每次只改一个变量，至少比较低并发、目标并发和突发并发三组数据。Triton 侧关注队列等待、实际批大小、实例利用率和请求 p95；TGI 侧可读取 tgi_queue_size、tgi_batch_current_size、tgi_batch_current_max_tokens 以及 prefill、decode 和 inference duration。吞吐上升但 p95、超时率或拒绝率同步恶化时，说明调参已经越过服务目标。

一个实用的调整顺序是：先把等待窗口调到不会明显侵蚀 p95 的范围，再把批量或 token 预算调到显存安全线以内，最后用并发压测观察队列是否持续增长。队列持续增长通常意味着到达速率超过服务能力，此时应限流、扩实例或降低单请求预算，不能只继续增大等待时间。

# 以队列持续增长为扩容信号，避免只看 GPU 利用率。
deriv(tgi_queue_size[5m]) > 0
# 同时观察端到端 p95，防止吞吐上升却让用户超时。
histogram_quantile(0.95, sum(rate(request_latency_seconds_bucket[5m])) by (le))

常见问题

等待时间越长，吞吐一定越高吗？

不一定。只有在后续请求能及时到达、模型确实从更大批量中获益且显存仍有余量时，等待才可能换来吞吐；低流量场景通常只会增加排队延迟。

为什么批大小不大，显存仍然会爆？

生成式模型的占用还受输入和输出 token、KV cache、prefill 预算、量化和实现方式影响。应按 token 总量观察，而不是只看请求数量；保留安全余量，并为超时、拒绝和回滚设定明确边界。