AI 推理服务延迟抖动时怎么区分排队和模型计算

AI 推理服务的 p95、p99 延迟突然升高时，先别急着换模型或提高 GPU 配额。最可靠的判断是把一次请求拆成服务端的排队、输入处理、模型计算、输出处理和端点开销，再观察它们是否与并发、吞吐一起变化。排队时通常是 queue_duration_us 和 pending_request_count 先涨，模型变慢时则是 compute_infer_duration_us 自身变长。

判断口诀是：并发升高后队列指标明显放大、吞吐接近平台上限，多半是排队；队列稳定而 compute_infer 变长，才优先怀疑模型计算。只看总延迟或 GPU 利用率，无法完成这两类归因。

先把一次请求拆成排队、计算与端点开销

以 Triton 这类推理服务为例，服务端请求延迟不是一个不可解释的黑盒。nv_inference_request_duration_us 表示请求处理总时间，nv_inference_queue_duration_us 表示在调度队列中等待的时间，nv_inference_compute_input_duration_us、nv_inference_compute_infer_duration_us 和 nv_inference_compute_output_duration_us 分别对应输入准备、模型执行和输出处理。端点协议、序列化和网络等待还可能形成额外的 overhead。

这里有一个容易忽略的边界：请求在前置网关、协议适配层中花费的时间，未必会被 Triton 的 pending request count 记录。也就是说，客户端总延迟变高而服务端 queue 不变时，应把 HTTP/gRPC 端点和前置层作为独立观察对象。

用指标和压测结果判断抖动来自哪里

先固定同一个模型、输入形状和请求速率，再比较低并发与高并发两个窗口。若并发从 1 提高到 4 后，pending_request_count、queue 时长和 p99 同步上升，而 compute_infer_duration_us 基本稳定，瓶颈更像调度容量不足。若 queue 仍接近原水平，但 compute_infer 的 p95/p99 变长，才应检查模型执行、输入尺寸、动态批处理等待或 GPU 资源竞争。

Perf Analyzer 的输出可以作为对照实验：它会报告吞吐、客户端延迟以及服务端的 queue、compute 和 overhead。不要只比较平均值，至少同时记录 p50、p95、p99；平均值不变而 p99 抖动，常见于少量请求进入长队列或遇到批次边界。

把排查判断写成最小监控配方

Triton 默认指标端点通常是 http://localhost:8002/metrics。先确认目标模型的指标确实存在，再在 Prometheus 中对同一组 model、version 标签求增量速率。计数器不能直接当作单请求时长；用 rate(nv_inference_queue_duration_us[5m]) 与 rate(nv_inference_request_duration_us[5m]) 做窗口比较，才不会把服务启动以来的累计值误读成当前延迟。

# 中文注释：确认服务端已暴露请求、排队和模型计算指标
curl -s http://localhost:8002/metrics | grep -E 'nv_inference_(request|queue|compute_infer)_duration_us'

# 中文注释：只保留目标模型，避免多模型累计值混在一起
curl -s http://localhost:8002/metrics | grep 'model="text_encoder"'

实际看板可以增加一个“排队占比”表达式：以 queue 的窗口增量除以 request 的窗口增量，作为趋势指标而不是绝对真值。占比上升且 pending 同步增加，处理方向偏向实例数、最大并发、请求速率和批等待；占比平稳而 compute_infer 上升，则应回到模型执行和输入输出阶段。

两类抖动分别怎么处理

排队抖动先做容量实验：逐步提高模型实例并发或调整动态批策略，观察吞吐是否继续增长、p99 是否出现拐点。如果吞吐已基本不变而 queue 继续增加，继续堆请求只会扩大尾延迟，可以在网关做限流、背压或按优先级分流。改变配置后要重新记录同一组分位数，避免用不同输入形状的结果比较。

计算抖动则从输入大小、compute_input、compute_infer 和 compute_output 分开查。输入张量变大、输出 token 变多或 GPU 与其他任务争用，都可能让模型执行时间上升；这时单纯增加服务实例还可能带来显存压力。先用固定输入做基线，再逐项放开长度和并发，才能知道是模型本身、数据搬运还是资源竞争。

AI 推理延迟排查常见问题

GPU 利用率不高，能否直接判断不是模型计算？

不能。短请求、动态批处理、内存搬运和采样阶段都可能让 GPU 利用率不高，但 compute_infer 仍然变长。GPU 指标只能作为关联证据，要和分段延迟一起看。

pending request count 很高就一定是队列故障吗？

它说明有请求等待后端执行，但不等于服务异常。高并发或刻意的批处理等待也会产生 pending。需要同时观察 queue 时长、吞吐和错误率，确认是否已经影响服务目标。

为什么客户端延迟比服务端 request duration 高很多？

客户端还包含请求发送、响应读取、序列化和网络等待；前置网关也可能在 Triton 收到请求前消耗时间。此时应把端点 overhead 与服务外链路单独打点。

应该优先看平均延迟还是 p99？

定位抖动优先看 p95 和 p99，平均值用来做总量趋势。若只有少量请求变慢，平均值可能几乎不动，但 p99 已经暴露队列或计算的尾部问题。