连续批处理（Continuous Batching）是大模型服务端的一种动态调度方式：系统不必等同一批请求全部生成完才换下一批，而是在每个生成步结束后移出已完成请求、补入新请求。它主要提高 GPU 利用率和整体吞吐量，面向的是多人同时调用模型时的服务效率。
静态批处理为何容易空等
传统批处理会先凑齐一组请求，再让它们一起执行。但生成任务的输入长度、输出长度差异很大：有的回答几十个 Token 就结束，有的要继续几百步。短请求完成后，它占据的位置可能一直空着，后来到达的请求却只能在队列里等待整批结束。
连续批处理把调度粒度从“一个完整请求”缩小到“当前生成迭代”。每完成一轮 Token 生成，调度器就重新查看哪些序列结束、哪些序列可进入，并组成下一轮批次。批次成员会持续变化，所以它也常被称为迭代级调度或动态批处理。
一次调度要同时照顾三件事
- 吞吐量：尽量填满可用计算资源，让更多请求共同推进。
- 延迟：不能只为等更大的批次，让已经到达的用户长时间排队。
- 显存：每条活跃序列都要保存上下文状态，批次越大，KV Cache 的显存压力通常越高。
因此，批次上限不是越大越好。服务框架还要处理不同长度序列的填充浪费、抢占策略、优先级、公平性，以及输入预填充和逐 Token 解码对算力需求不同的问题。
用户会感受到什么
在并发稳定的在线服务里，连续批处理往往能减少排队空洞，用同一组 GPU 服务更多用户。但吞吐量提高不代表每个请求都更快：若调度器过度追求满载，低优先级请求可能等待更久，单请求延迟甚至会上升。
评估时应分开观察首 Token 延迟、后续 Token 间隔、每秒总 Token 数和高分位延迟。低并发的个人本地部署几乎凑不出动态批次，收益可能有限；面向 API、聊天平台或多租户推理集群时，它才是决定成本与体验的核心基础设施。
