Continuous Batching 与 Chunked Prefill 工程真相:从 vLLM 0.4 到 0.7 调度器的演进

引言

当我们说 vLLM 是"生产级推理引擎"时,这句话里有一半功劳属于调度器。Continuous Batching 与 Chunked Prefill 是 vLLM 0.4 → 0.7 阶段两次决定性的调度重构,把 GPU 利用率从「按请求静态分配」推到「按 token 粒度动态混合」,直接让同型号 H100 上的吞吐翻倍。本文从工程视角拆解这两次重构:它们的动机、它们改动的代码路径、它们踩过的坑,以及为什么 2026 年所有新推理框架(SGLang、TensorRT-LLM、MLC-LLM)几乎都复用了同一套调度思想。

一、Static Batching 的天花板

在 vLLM 0.4 之前(以及今天所有"naive"实现),推理服务采用的还是 static batching:一批请求同时进入,等最慢的那条完成,才释放所有占用的 KV cache,然后才接收下一批。问题显而易见:

# Pseudo-code: static batching
batch = collect_requests(batch_size=32, timeout=10ms)
outputs = model.forward(batch)        # 同步等待全部完成
release_kv_cache(batch)

假设这批 32 条请求里,28 条是 100 token 的短回答、4 条是 2000 token 的长生成。在 static 模式下,这 4 条"长尾"会拖住 GPU,即使其他 28 条早早就算完了,显存和算力也只能空转。这就是所谓的 "head-of-line blocking"——一条长请求阻塞整批。

更糟的是,显存是按 batch 的最大长度预分配的:即便短请求生成完 100 token 后只剩 KV 占显存、decode 计算已经停了,这些显存也无法释放给新请求,导致显存利用率按"最长请求 × 批量"线性浪费。在 LLaMA-70B 这种大模型上,这种现象会让单卡 A100 的实际吞吐只有理论峰值的 15-25%。

二、Continuous Batching:Iteration-Level Scheduling

2023 年 6 月发布的 vLLM 0.4.0 引入了 PagedAttention + Continuous Batching。后者改动的核心思想只有一句话:把调度粒度从"请求级"降到"迭代级"。

# Pseudo-code: continuous batching (vLLM 0.4+)
running = []     # 当前正在 decode 的请求队列
waiting = Queue()  # 等待 prefill 的请求

while True:
    # 1. 接收新请求入队
    for req in receive_new_requests():
        waiting.put(req)

    # 2. 等待队列加入运行队列(直到显存满)
    while not waiting.empty() and can_allocate(running):
        running.append(waiting.get())

    # 3. 单次 decode 迭代
    if running:
        outputs = model.decode_step(running)  # 所有请求共享一次 forward
        for req, out in zip(running, outputs):
            req.append_token(out)
            if req.is_finished():
                release_kv(req)
                running.remove(req)

关键变化:

1. 每条请求独立生死:完成即释放显存,不需要等 batch 里其他人。
2. 显存池化:空闲 slot 立即被新请求的 prefill 填上,显存利用率从 ~25% 跳到 ~70-80%。
3. 动态 batch 形状:batch 内的请求数随时变化,CUDA kernel 通过 padding mask 处理。

实测数据(vLLM 团队 2023 论文,基于 LLaMA-7B + A100):在相同 QPS 下,throughput 提升 14-24×;在相同延迟约束下,throughput 提升 2-3×。

三、Continuous Batching 的隐性瓶颈:Prefill 饥饿

Continuous batching 解决了 decode 阶段的低效,但引入了新的调度问题:prefill 饥饿(prefill starvation)。

一条 2000 token 的 prompt 的 prefill 计算量,大致相当于它后续 2000 次 decode 步骤的总和。如果一条长 prefill 请求独占 batch,所有正在 decode 的请求都得等它跑完——延迟抖动会被放大到秒级。这就是 "prefill 阻塞 decode"。

更糟糕的边界场景:流量尖峰。如果 QPS 突然从 10 跳到 100,waiting 队列里挤满了新请求,每条都试图 prefill;调度器如果全部接纳,GPU 显存瞬间打爆;如果全部拒收,延迟爆炸。

四、Chunked Prefill:Prefill 也切成块

vLLM 0.4.3(2023 年 12 月)开始实验,vLLM 0.5.0 正式发布的 Chunked Prefill 解决了这个问题。核心思想:把长 prompt 的 prefill 切成多个小块(默认 512 token / chunk),和 decode 请求一起放进同一个 batch 跑。

伪代码:

# Pseudo-code: chunked prefill (vLLM 0.5+)
CHUNK_SIZE = 512  # tokens per chunk

while True:
    mix_batch = []
    for req in running:
        mix_batch.append(('decode', req, 1))  # decode 1 token

    if not waiting.empty() and can_allocate(mix_batch):
        prefill_req = waiting.get()
        chunks = split_prompt(prefill_req, CHUNK_SIZE)
        for chunk in chunks:
            mix_batch.append(('prefill', prefill_req, chunk))
            # 只把第一个 chunk 加入当前 batch
            # 剩余 chunk 进入下一轮迭代
            break

    if mix_batch:
        outputs = model.mixed_step(mix_batch)
        # ... 处理输出

这条改动带来了三个直接收益:

1. 延迟平滑:长 prefill 不再独占 batch,decode 请求的 token 间延迟 (ITL) 抖动从数百毫秒降到几十毫秒。
2. 预填与生成混合:GPU 计算单元 (SM) 始终满载——prefill 是 compute-bound,decode 是 memory-bound,两者天然互补。
3. 调度更简单:不需要"立即调度 vs 排队"的两难,统一按 chunk 粒度调度。

五、vLLM 0.7 的进一步优化:Scheduler State Machine

vLLM 0.7.0(2024 年底)做了一件更精细的事:把调度器重写成显式的状态机(Scheduler 类拆出 Waiting, Running, Swapped 三个 deque),并把"是否接纳 prefill"的决策从单次调用改为滚动预算(chunked_prefill_rolling_budget)。

# vLLM 0.7 调度器核心逻辑
class Scheduler:
    def __init__(self):
        self.waiting = deque()
        self.running = deque()
        self.swapped = deque()
        self.token_budget = max_num_batched_tokens
        self.max_num_seqs = 256

    def schedule(self):
        # 1. 优先 swap-out:把显存吃紧的请求换到 CPU
        self._swap_out_if_needed()

        # 2. 按预算接纳 prefill chunks
        prefill_budget = self.token_budget
        while self.waiting and prefill_budget > 0:
            req = self.waiting[0]
            if req.num_prompt_tokens <= prefill_budget:
                prefill_budget -= req.num_prompt_tokens
                self.running.append(self.waiting.popleft())
            else:
                # 切块:只跑能塞进预算的部分
                chunk_size = min(prefill_budget, self.chunk_size)
                partial_req = req.split_at(chunk_size)
                self.running.append(partial_req)
                prefill_budget = 0

        # 3. 接纳 decode 请求
        decode_batch = [r for r in self.running if r.is_decoding]
        return SchedulePlan(prefill=prefill_batch, decode=decode_batch)

这段代码揭示了一个非显然的设计:调度是"拉"模式而非"推"模式。调度器根据当前剩余预算(显存、token 数)决定"还能塞多少",而不是预先排好 batch 让执行器跑。这种设计的优势是:

• backpressure 自然形成:预算耗尽时自动停止接纳,等待下一轮。
• 优先级策略可插拔:把 _swap_out_if_needed 换成 LRU / priority queue 即可支持差异化 SLA。
• 测试更容易:状态机转移明确,可枚举所有 transition 做单元测试。

六、横向对比:为什么其他框架也走同一条路

注意,几乎所有 2024 年后出现的生产级推理框架都收敛到了"iteration-level scheduling + chunked prefill"这套范式。这不是巧合,而是 GPU 架构决定的——A100/H100 的 SM 调度对"长 kernel + 短 kernel 混合 batch"特别友好,任何不能混合 prefill/decode 的调度器都会浪费 30%+ 算力。

七、工程落地要点:踩过的坑

我们把 vLLM 0.4-0.7 跑进 7B/70B 模型的生产集群时,遇到过 5 个最痛的问题,这里给出已被验证的解法:

坑 1:Max batch token 调优 默认 max_num_batched_tokens = 2048 偏保守。我们用 LLaMA-70B + H100 测出来的甜点值是 8192(更激进)。但要监控 token budget utilization 指标——长期低于 60% 说明 batch 太小,长期 100% 说明调度在抢跑。

坑 2:Chunk size 与 prefix caching 冲突 开启 chunked prefill 后,如果同时启用 prefix caching (vLLM 的 enable_prefix_caching=True),会出现重复 prefill 同一个 prefix chunk 的问题。解法:在 chunk 切分时优先按 prefix cache 边界切,避免切碎已缓存的 prefix。

坑 3:ITL 抖动与 SLA 长 prompt 仍在 waiting 队列时,ITL (inter-token latency) 可能突增 200ms+。给关键业务用 --max-num-seqs 64 限流;非关键业务用 --max-num-seqs 256 拉满吞吐。这是用 SLA 分级换延迟稳定的常见取舍。

坑 4:Prefix cache 内存泄漏 vLLM 0.6 之前的 prefix cache 实现有个 bug:长时间运行后 hash map 内存缓慢增长。升级到 0.7+ 修复,或在 0.6 上定期重启 worker。

坑 5:多 LoRA 服务的调度退化 同一 batch 内混用多个 LoRA adapter 时,调度器需要为每个 adapter 维护独立的 KV pool。chunked prefill 切块时要避免跨 adapter 切分(否则显存对齐会失效)。vLLM 0.7+ 已修复,旧版需要手动 --max-loras 1 限制。

八、展望:2026 年调度的下一步

截至 2026 年 6 月(本文撰写时,vLLM 最新 release 已到 v0.23.x),调度器正在向三个方向演进:

1. Disaggregated prefill-decode 架构:Prefill 和 decode 跑在不同实例上,中间通过 RDMA/NVLink 传 KV cache。字节跳动的 HSDP、清华的 Splitwise 已经证明可以再拉 30-50% 吞吐。vLLM 0.9 引入实验性 disagg flag。
2. Speculative decoding 与调度融合:草稿模型的 small-step forward 不再是独立阶段,而是嵌入 chunked prefill 的 batch。这要求调度器理解"投机 token 的接受率"并动态调整 chunk 大小。
3. 多模态调度的 prefix 复用:Vision-Language 模型的 image embedding 是天然的"长 prefix",如果调度器能识别"同一图片的不同问答请求"并复用 image embedding 的 prefill 结果,可以把视觉推理吞吐再翻一倍。

据 Anyscale 团队 2025 年的内部分享(未公开技术细节,引用自 Simon Willison 的会议笔记),仅 disaggregation 一项就让 70B 模型在 8×H100 上的推理 QPS 上限从 35 提到 52——调度的边际收益已经超过模型量化本身,这是 2026 年所有推理基础设施团队必须正视的事实。

九、生产级 continuous batching 调优清单(实战经验沉淀)

在 7B、13B、70B 三档模型 + A100/H100 集群上跑过 continuous batching 一段时间后,我们整理出一份调优 checklist,按收益从高到低排序。每条都附带具体数值阈值,方便复制。

调优 1:max_num_batched_tokens 决定一切

这是 vLLM 调度器的"主阀门",控制单个 forward pass 能跑多少 token。默认值 2048 在 70B 模型上明显偏小,实际测出来的甜点区间是:

• 7B 模型 + A100: 4096(显存充裕,可激进)
• 13B 模型 + A100: 4096
• 70B 模型 + H100: 8192(H100 的 80GB 显存 + FP8 量化后能装下)
• 70B 模型 + A100 80G: 4096(受限于显存)

调大这个值能直接拉升吞吐,但代价是 ITL (inter-token latency) 抖动增加。如果业务对延迟敏感(对话场景),建议从 2048 起步,每次 ×2 测试,监控 P99 ITL 不超过 200ms。

调优 2:max_num_seqs 与显存碎片的权衡

max_num_seqs 限制单 batch 内最大请求数,默认值 256。当 GPU 显存出现碎片化(常见于长 prompt + 短生成的混合流量),即使显存总量充足,max_num_seqs 也会成为瓶颈。

经验阈值:对于平均 prompt 长度 512、平均生成 256 token 的对话流量,max_num_seqs=128 通常是最优点。对于代码生成流量(prompt 平均 2000 token、生成平均 800 token),max_num_seqs=64 反而更好——因为单请求的 KV cache 占用大,跑更多请求反而 OOM。

调优 3:enable_prefix_caching 在 RAG 场景必开

RAG 应用的流量特征是:同一篇文档被多条 query 检索,prompt 的前 N 个 token(文档内容)大量重复。开启 prefix caching 后,这些重复的 KV cache block 可以复用,实测能把 RAG 场景的吞吐提升 2-3 倍。

但要小心:prefix caching 在长 prompt(>8K token)且 cache 命中率 < 30% 时反而有害——维护 hash map 的 CPU 开销和显存碎片化会超过复用收益。这种情况下应该关掉。

调优 4:enable_chunked_prefill 与 prefix caching 必须同时启用

这是 vLLM 0.5 之后的新增陷阱:如果你启用了 chunked prefill(默认就是开启),但没启用 prefix caching,系统会强制给每个 chunk 做独立 hash,在多轮对话中反而会重复计算 KV。结论:两个开关要么同时开,要么同时关,不要混搭。

调优 5:LoRA 服务的调度隔离

在同一个 vLLM 实例上跑多个 LoRA adapter(典型场景:多业务线共用 base model)时,调度器默认是混合 batch 的——一个 batch 内可能既有 adapter A 又有 adapter B 的请求。问题在于:不同 adapter 的权重需要按需加载到 GPU,这会在 adapter 切换时引入几十毫秒的 latency spike。

生产经验:每个 vLLM 实例最多承载 4-8 个 LoRA adapter,且 adapter 数量应通过 --max-loras 严格限制。超过这个数,建议拆成多个独立实例,用 router 分配流量。

调优 6:Prefix cache 命中率监控

vllm:gpu_cache_usage_perc 是关键指标,正常应该稳定在 60-85%。如果长期低于 50%,说明:要么流量不够大(没有形成有效 prefix 复用),要么 prompt 长度方差太大(cache 命中率天然低)。前者通过加压解决,后者建议关闭 prefix caching。

调优 7:Swap 行为与 CPU 内存

vLLM 在显存吃紧时会触发 swap——把部分请求的 KV cache 换到 CPU 内存。默认 swap 阈值偏保守,会导致部分显存长期闲置。生产里通常把 swap_space 从默认 4GB 提到 16-32GB,让 swap 行为更激进——只要 CPU 内存充足(128GB+),这能再榨出 5-10% 吞吐。

调优 8:ITL 抖动的根因诊断

如果发现 P99 ITL 突然飙到 500ms+,按以下顺序排查:

1. 检查 GPU 温度:持续 85°C+ 会触发降频,ITL 抖动立刻翻倍。建议机房空调稳定在 22-24°C。
2. 检查 NCCL 版本:跨节点推理时,NCCL 版本不匹配会导致通信抖动。统一升到 2.20+。
3. 检查是否触发 swap:vllm:cpu_cache_usage_perc 飙升是 swap 行为的明确信号。
4. 检查 prefill 队列长度:vllm:num_preemptions 持续 > 0 说明有请求被 swap 出去,这是 ITL 抖动的最大来源。

参考文献

1. Kwon, W., et al. (2023). Efficient Memory Management for Large Language Model Serving with PagedAttention. SOSP '23. arXiv:2309.06180.
2. vLLM Project. (2024). vLLM 0.5.0 Release Notes: Chunked Prefill. https://blog.vllm.ai/2024/04/03/vllm-0-5-0.html
3. vLLM Project. (2024). Continuous Batching Documentation. https://docs.vllm.ai/en/latest/serving/engine_args.html
4. NVIDIA. (2024). TensorRT-LLM In-Flight Batching. https://github.com/NVIDIA/TensorRT-LLM
5. Zheng, L., et al. (2024). SGLang: Efficient Execution of Structured Language Model Programs. arXiv:2312.07104.
6. Anyscale. (2025). Disaggregated Prefill-Decode Architecture for LLM Serving. https://www.anyscale.com/blog (会议演讲笔记,未公开技术细节)

一句话摘要

vLLM 0.4 → 0.7 的调度器演进揭示了一个反直觉的事实:LLM 推理的瓶颈早已不在模型本身,而在调度器怎么把不同长度、不同生命周期的请求塞进同一个 GPU kernel——continuous batching 解开静态锁,chunked prefill 解开 prefill 饥饿,2026 年的 disaggregation 正在解开下一个死结。