AI请求延迟忽高忽低，不一定是模型突然变慢。高并发时，请求到达不均匀：有时很快凑满一批，有时请求要在队列里等；输入长度、输出长度和设备负载也会改变单次推理时间。调试AI应用高并发请求下的批处理与动态合批配置，关键是同时观察“等了多久”和“算了多久”，不要只把批次调大。
先分清延迟波动来自哪里
一次请求的总耗时，可以拆成排队、等待合批、模型计算和结果返回。若队列等待上升而设备仍有空闲，可能是调度或合批等待造成；若排队和计算时间都增加，则可能是算力已接近负载上限。可按请求记录到达时间、开始推理时间、批次大小、输入长度与总耗时，再比较低负载和高负载时的变化。
还要区分模型类型。图像分类、文本向量化等输入输出形状相对固定的任务，通常较适合固定尺寸批次或动态批处理。自回归大语言模型的生成长度差异大，提示词处理与逐 token 生成的计算特征也不同；单纯增大固定批次，可能占用更多 KV cache，并拖慢长请求。
批量上限与等待窗口怎么设
最大批量决定一次推理最多合并多少请求；合批等待窗口决定请求最多等多久来凑批。上限过低，设备可能没有充分利用；上限过高，显存占用、排队时间和长请求对短请求的影响都可能变大。窗口太短，常凑不满批；太长，则直接增加在线请求延迟。
TensorFlow Serving 提供 batching 配置，可调整最大批量、批处理超时、批处理线程数及排队批次数等参数。参数名称和具体可用设置应以所用版本文档为准。它们分别影响合批规模、等待时长、调度并行度和过载时的积压空间，不宜只改一个参数后就判断效果。
| 调整项 | 适合关注的现象 | 可能的代价 |
|---|---|---|
| 最大批量 | 批次常未满，且设备仍有余量 | 增大后可能提高显存占用与单批耗时 |
| 等待窗口 | 请求稀疏、批次大小波动明显 | 增大后会增加等待延迟 |
| 队列深度 | 短时突发请求造成拒绝或积压 | 队列过深只会延后失败或超时 |
用小步压测找到可用配置
- 先设延迟目标。明确业务可接受的端到端延迟及超时策略，并记录平均值之外的高分位延迟、错误率和吞吐量。对实时交互服务，尾部延迟通常比单纯提升吞吐更重要。
- 建立基线。从单请求或当前配置开始，在代表性的请求并发、输入长度和输出长度下测试。负载应逐步增加，避免只测稳定、均匀的流量而漏掉突发情况。
- 分档调整批量。可把 1、2、4、8 等作为初始测试档位；这只是便于逐步比较的起点，不是通用最优值。每档都检查显存、设备利用率、吞吐、排队时间和超时情况。
- 再调等待窗口。若设备有余量、批次偏小，可从较短窗口逐档增加；对严格在线延迟的服务，可先测试约 1–5 毫秒，对延迟容忍度较高的任务再评估约 5–20 毫秒。实际可用范围受请求到达率、模型、硬件和服务端调度影响，应以压测结果为准。
- 设置积压保护。为队列设定上限，并明确超限时是快速拒绝、降级还是返回可重试错误。无限排队通常不能解决过载，反而会让请求在最终超时前持续占用资源。
长短请求混在一起时，别只看批次大小
例如图像分类服务收到分辨率不同的图片，或生成服务同时处理短提示词和长文本，仅看“平均批次”可能掩盖尾部延迟。可按输入尺寸或任务类型分队列，减少形状差异和长任务对短任务的干扰；但队列切得过细，又可能让每个队列都凑不满批次。应比较分队列前后的等待时间、批次填充情况与资源使用，再决定是否保留。
生成式模型还要单独关注首 token 延迟、每 token 生成速度和 KV cache 使用量。提高并发序列上限可能增加吞吐，却不代表首 token 一定更快；如果显存紧张或请求输出很长，反而可能出现延迟突升。因此，AI应用高并发请求下的批处理与动态合批配置需要按模型服务方式分别验证，不能照搬图像或向量任务的批量值。
常见问题
批次越大，吞吐一定越高吗？
不一定。达到设备的高效区间后，继续增大可能只增加显存占用和单批等待，甚至降低整体吞吐。
等待窗口设为零可以避免延迟吗？
可以减少为凑批而等待的时间，但批次可能变小，设备利用率和吞吐可能下降。是否合适取决于流量密度与延迟目标。
高分位延迟升高，应该先调哪个参数？
先看请求的排队时间、合批等待和模型计算时间分别如何变化。队列积压时优先处理过载或并发能力；设备有余量且批次偏小时，再测试增大批量或等待窗口。
归根结底，稳定配置不是把批次调到最大，而是在延迟预算内平衡等待与计算。按负载分档压测、观察队列深度和高分位延迟，再逐项调整，才能让AI应用高并发请求下的批处理与动态合批配置既提高资源利用率，也不把请求卡在队列里。
