大模型Batch与并发数是一回事吗：请求队列、连续批处理和显存边界

图解产业阿军编辑 · AI 辅助整理与编辑核查

不是。并发数通常描述某个统计边界内同时尚未完成的请求数；Batch描述一次计算或调度组织起来的工作。客户端同时发出100条请求，不代表GPU正在把100条请求放进同一批执行，其中一些可能还在排队。

比较服务参数时，必须先问清“在哪里数”“数的是什么”“按哪段时间统计”。离开这三个条件，一个更大的数字未必代表更高性能。

从请求入口走到计算批次

可以把简化流程写成：客户端提交→服务接收与排队→调度器选取工作→执行→返回结果。真实服务还可能有网关、分词和多个队列，这张图只用于分清层次。

“一次提交1000条”还可能只是离线任务列表的长度。它既不是同一时刻的并发，也不规定引擎必须一次处理完。

三个长短不同的请求怎样排队

以下为原创假设模型，不对应某台GPU或某次压测。假设A、B同时到达，分别需要2轮和4轮生成；C在第1轮结束后到达，需要1轮。每轮最多容纳2条序列，每条每轮生成1个token。为突出调度差异，暂不计预填充、传输和调度开销，各轮也不换算成毫秒。

在C刚到达、A尚未完成时，未完成请求是3条，但执行批里只有2条。这直接说明并发数与Batch可以不同。连续批处理让已完成请求退出、等待请求有机会进入后续迭代，不要求每个请求从头到尾绑定同一组伙伴。

这个例子只证明“补位规则改变了C等待的轮数”。不能据此宣称实际服务加速20%，因为真实批次的耗时会随工作量变化，C还需要处理输入。输入处理与逐步生成的区别，可结合Prefill与Decode指南阅读。

传统动态批处理还可能短暂等待，以便把更多到达请求组成一批；这与逐轮调整生成请求成员不是同一个概念。Triton的动态批处理说明提供了队列等待配置，但不能把它的参数直接套到另一套LLM引擎。

序列上限、token预算和显存分别管什么

以vLLM为例，max_num_seqs约束单次迭代处理的序列数量，max_num_batched_tokens约束单次迭代处理的token数量。后者不是“所有会话允许保存的历史token总数”。开启分块预填充时，长输入可分块与解码工作共同调度，预算分配会影响首token等待和后续输出间隔。具体行为应核对安装版本的vLLM优化文档。

作一个独立的算术假设：某轮token预算为12，3条解码序列各占1个token，剩余预算便是9。即使序列数量还没到上限，一段长输入也不能因此无限塞进这一轮。这个简化账本不包括推测解码等额外机制。

显存又是另一层限制。vLLM文档说明，KV Cache空间不足时可能发生抢占与重新计算，影响端到端延迟。提高调度上限不会创造缓存空间。理解这一点，可先区分KV Cache与模型权重：模型能装下，不等于更多长会话也能一起装下。

吞吐上去了，为什么用户仍觉得慢

吞吐衡量单位时间完成多少工作；延迟衡量一项工作经历多久。生成服务还应拆开看：首token时间、相邻输出token间隔，以及整条回答完成时间。输入与输出token吞吐也要注明口径，不能混成一个“速度”。可用带宽、延迟与吞吐指南补齐这些指标的关系。

增加并发可能提供更多可合批工作，也可能主要增加排队。只看平均吞吐，容易漏掉少数请求等待很久的问题。建议用同一组请求长度分布，逐档调整一个参数，并保留以下核对表：

• 负载一致吗： 模型、输入长度、输出限制、到达方式及缓存条件是否相同？
• 等待在哪里： 分别记录客户端、网关和引擎队列中能观察到的等待。
• 体验达标吗： 同时看首token、输出间隔和完整响应的中位数及高分位值。
• 资源受限吗： 查看缓存使用、抢占或重算记录，不能只看GPU利用率。
• 结果完整吗： 报告吞吐时同时列出失败、超时和完成数量。

先确定交互服务能接受的等待，再寻找该约束内的吞吐；离线任务则可以采用不同目标。记录框架版本和具体工作负载，才能判断某个配置适合哪里，而不是寻找脱离条件的“最佳Batch”。