推理服务连续批处理怎样减少 GPU 空转

连续批处理减少 GPU 空转的关键，不是把批次一次性做得更大，而是把“谁能进入下一轮计算”的决定放到每个推理迭代上：请求生成完就立即移出，释放出的槽位马上从等待队列补入新请求。这样，短请求先结束时不会让剩余长请求拖着一个越来越窄的固定批次继续跑。

但连续批处理也不是吞吐开关。单轮 Token 预算、并发序列数、长提示词的 prefill、KV Cache 容量和实际到达率都会决定它能否真正填满 GPU。下面我用一次很典型的压测复盘，把“看起来 GPU 在工作，为什么吞吐仍然掉”的原因拆开。

影响面：GPU 没报错，吞吐却掉了

我第一次碰到这类现象时，服务没有 OOM，也没有明显报错：请求能返回，显存也没有耗尽，可并发一上来，等待队列开始增长，吞吐却没有按预期提高。更容易误导人的地方是，GPU 监控并非一直显示空闲，于是大家会把问题归到网络、序列化或客户端限流。

真正受影响的是批次的“有效宽度”。同一批请求的输出长度不会一致：有的很快遇到停止条件，有的还要继续生成。固定批次如果不能在中途补入新请求，已经完成的槽位就失去作用；模型仍在为剩余请求执行前向计算，但每轮可并行处理的序列越来越少。这里所谓“空转”，更准确地说是批处理容量没有被充分利用，而不是 GPU 完全没有执行计算。

时间线：空转是怎样被制造出来的

问题通常从一组看似合理的固定批次开始。批次刚进入模型时，请求数足够多，GPU 的并行度也不错。随后短输出请求先完成，长输出请求仍占着批次；如果系统要等整批结束才能组建下一批，空出来的位置就不能接纳队列里的新请求。

当流量持续到达时，服务会同时出现两种状态：GPU 正在处理少量尚未结束的长请求，入口处却堆着很多等待请求。这正是我后来判断调度问题的关键证据——不是没有工作可做，而是等待中的工作进不了当前计算轮次。

触发条件：哪些流量最容易暴露问题

连续批处理的收益在请求差异较大时最明显。下面三个条件经常一起出现：

• 输出长度分散：问答、摘要和长文生成共享同一实例，结束时间天然不齐。
• 提示词长短混合：长 prefill 会消耗大量单轮 Token 预算，短请求容易在等待队列里被拖延。
• 到达时间不整齐：在线流量是持续到达的，不会像离线任务那样先凑齐一整批再开始。

反过来，如果到达率很低，队列里本来就没有可补入的请求，连续批处理也无法凭空创造并行度。因此，判断它是否有效，必须把调度方式和实际负载放在一起看。

根因：固定批次按整批结束，连续批处理按迭代重排

vLLM 对引擎循环的说明很清楚：每个 step 都包含调度、模型前向与后处理；异步引擎在每个 step 后会同时考虑新请求和已有请求。完成的请求释放 KV Cache 块并离开运行集合，新请求则可以从 waiting 进入 running。连续批处理因此不是“更大的静态 batch”，而是“每轮都可以改变成员的 batch”。

这里还要区分 prefill 和 decode。prefill 处理提示词，通常更偏计算密集；decode 每次主要推进新 Token，并重复读取模型权重和 KV Cache，更偏内存带宽受限。vLLM V1 调度器可以在同一步混合这两类请求，但它仍受单轮 Token 预算和 KV Cache 可用空间约束。只开连续批处理、不管资源边界，队列仍可能堵住。

修复动作：先控制 Token 预算，再处理长提示词

我的调优顺序会先分清两个上限。max_num_seqs 控制单轮最多处理多少条序列；max_num_batched_tokens 控制单轮最多处理多少个 Token。前者限制请求数量，后者限制实际计算预算，两者不能互相替代。

如果长提示词频繁挤占预算，可以启用或确认 chunked prefill，让 prefill 根据剩余的 max_num_batched_tokens 分段进入计算，而不是一次吞掉整轮预算。这样做的目的不是缩短提示词，而是给 decode 和其他短请求留下可调度空间。对于请求差异很大的服务，还要关注长 prefill 阈值和并发 partial prefill 数量，避免多个长提示词同时占满预算。

接着检查 KV Cache。连续补位会让更多请求处于运行态，如果显存余量不足，调度器可能跳过新请求，甚至发生抢占与重算。官方配置中的 scheduler_reserve_full_isl 用于在接纳请求时检查完整输入长度是否能放入 KV Cache，watermark 则可以保留一部分空闲块作为余量。它们解决的是过度接纳和反复抢占，不是单纯追求更高并发。

参数不要一起拉满。更稳妥的做法是固定模型、硬件、请求分布和流量曲线，每次只调整一个预算：先观察等待队列是否下降，再看首 Token 延迟和抢占是否恶化。只要延迟明显变差或 KV Cache 长期逼近上限，就说明新增并发已经超过当前实例的舒适区。

防复发：用指标确认不是把空转换成排队

连续批处理生效后，最怕把“GPU 批次偏窄”换成“队列更长、首 Token 更慢”。vLLM 的 /metrics 已经暴露了足够的联合信号：

• vllm:num_requests_running 与 vllm:num_requests_waiting：看运行集合是否稳定、等待是否持续积压。
• vllm:iteration_tokens_total：看每个 engine step 实际承载的 Token 数是否经常过低。
• vllm:request_queue_time_seconds 与 vllm:time_to_first_token_seconds：确认吞吐提升没有牺牲排队和首 Token 延迟。
• vllm:inter_token_latency_seconds：观察生成阶段是否因为调度竞争而变得不平稳。
• vllm:kv_cache_usage_perc 与 vllm:num_preemptions：判断是不是用过高并发换来了缓存压力和重算。

最终验收不应该只看一条 GPU 利用率曲线。我的判断标准是：在相同请求分布下，等待队列不再单边增长，单轮 Token 数更稳定，吞吐提高，同时 TTFT、每 Token 延迟和抢占次数仍落在服务目标内。满足这组条件，才说明连续批处理真正减少了资源浪费。

常见问题

连续批处理会不会让单个请求更慢？

有可能。更大的并发集合会提高总体吞吐，但也可能增加排队、调度竞争或单请求延迟，所以必须同时观察 TTFT 和 inter-token latency。

把 max_num_seqs 调大就能提高 GPU 利用率吗？

不一定。它只是提高序列数量上限；如果单轮 Token 预算、KV Cache 或到达率才是瓶颈，继续增大序列数只会增加排队或缓存压力。

为什么启用连续批处理后等待队列还在增长？

常见原因包括流量超过实例容量、长 prefill 占满 Token 预算、KV Cache 余量不足，或者输出长度过长。需要把 waiting、iteration tokens、TTFT、KV Cache 和 preemption 放在一起判断。

chunked prefill 和连续批处理是什么关系？

连续批处理负责按迭代动态重组请求；chunked prefill 负责把长提示词拆成受预算约束的片段。两者结合时，长 prefill 更不容易独占整轮计算。

本文技术事实参考 vLLM 的 引擎结构说明、调度配置文档与生产指标文档。