请求量上涨时，先别急着把批次调大。AI应用高并发请求下的批处理与动态合批配置，关键是让足够多的兼容请求在可接受的等待时间内一起执行，而不是追求最大批量。批次变大可能提高设备利用率，也可能造成排队、显存压力和尾延迟上升。
先判断：这些请求能不能合在一起
合批适合模型、输入格式和推理设置相同或兼容的请求。若任务调用不同模型、要求不同输出格式，或拥有严格不同的截止时间，硬凑一批可能增加调度复杂度，甚至无法执行。文本生成还要关注输入长度和输出长度：长短差异明显时，短请求可能被长请求拖慢。
区分两种机制也很重要。Triton Inference Server 的动态批处理可在队列中短暂等待请求，再按配置组成批次，适合可合批的推理任务；vLLM 的连续批处理则会在生成过程中动态安排请求，更适合输出长度不一的生成负载。它们解决的问题相关，但配置方式和调度单位并不相同。
批次上限与等待窗口要一起调
最大批量限制一次执行最多接纳多少请求；等待窗口限制请求为凑批最多等多久。只增大前者、不给后者留出合理空间，批次未必变满；只拉长等待窗口，则可能让低流量时的请求白白变慢。
可以把最大批量 4、8、16 作为压测候选值，逐级比较，而不是直接选最大值。交互式服务可先测试约 2–10 毫秒的等待窗口；更偏吞吐、对响应时间不那么敏感的任务，可测试约 10–30 毫秒。它们只是起始范围，实际效果取决于硬件、模型、请求到达速率、输入长度和服务目标。
用指标找到拐点，而非凭感觉加码
AI应用高并发请求下的批处理与动态合批配置，应同时观察吞吐量、队列等待时间、端到端延迟的 p95/p99、显存占用和错误率。若批量继续增大，但吞吐提升很小、p99 明显恶化，通常已越过合适的拐点。若队列不断变长而设备仍未充分利用，则可能是调度、并发限制或前置处理环节在阻塞，不一定是批次太小。
可执行的调参步骤
先记录当前基线：并发请求数、每秒完成请求数、p95/p99 延迟、队列长度和资源占用。
按真实流量抽取短输入、长输入及不同输出长度的样本，分别压测，避免平均样本掩盖长请求问题。
固定模型与并发条件，逐档调整最大批量，再逐档调整等待窗口；每次只改一个参数，记录结果。
在预期峰值及更高一档负载下复测。若排队延迟超出服务目标，先缩短等待窗口或限制入口并发；若资源有余量且吞吐仍随批量提升，再考虑扩大上限。
三个常见避坑点
把请求数当成批次大小：并发请求可能到达时间分散，队列也可能被不同模型或不同任务隔开。
只看平均延迟：平均值看不出少数请求被长输入拖住的情况，应同时看 p95 或 p99 尾延迟。
忽略超时与过载保护：设置队列上限、请求超时和拒绝策略，避免过载时等待无限累积；具体阈值要依据服务承诺与实测设置。
归根结底，AI应用高并发请求下的批处理与动态合批配置不是“请求越多，批次越大”的简单对应关系。以真实请求分布压测，找到吞吐提升与尾延迟恶化之间的拐点，再将批量上限、等待窗口和队列保护一并固定，才是可持续的做法。
常见问题
低并发时也需要动态合批吗？
不一定。若请求稀疏，凑批带来的等待可能超过吞吐收益，可缩短等待窗口或关闭合批。
增大批次后显存占用会不会上升？
通常会增加，但增幅取决于模型、输入长度、缓存策略和推理框架。应在目标负载下观察资源峰值，预留余量。
应该优先提高批量还是增加服务实例？
若单实例仍有资源余量且合批能提升吞吐，可先测试批量；若单实例已接近资源或延迟上限，增加实例、分散请求通常更合适。
