Continuous Batching：动态批处理推理

可视化演示

动态演示Continuous Bat的核心机制，通过开始/执行/监控/完成四种模式展示关键概念与交互流程。

静态批处理：定时班车的空驶之痛

调度员老张管理的线路曾经是定时班车制：每隔 30 分钟发一班，凑够一车人才走。乘客少时车辆空驶，乘客多时后面的人只能眼巴巴等下一班。更麻烦的是，只要有一位乘客动作慢，整车人都得陪着他等。

大模型推理最早采用的就是这种“定时班车”——静态批处理（Static Batching）。多个请求凑成一个 batch 后统一进入 GPU，整个批次同步推进。它的三个先天缺陷和定时班车一模一样：一是请求要排队等批；二是同一批里每个请求生成的 token 数量差异巨大，最长的请求拖住所有人；三是 GPU 在等待和收尾阶段大量空转。

假设一个 batch 里有 B 个请求，第 i 个请求需要生成 L_i 个 token，GPU 的峰值算力为 C，总耗时 T。静态批处理的 GPU 利用率可以写成：

这就是定时班车的空驶之痛：车在跑，座位却空着；人在等，车却发不了。要解决它，必须让“发车”不再受固定批次约束。

动态插队：实时拼车的补位智慧

老张引入实时拼车小巴后，规则彻底变了：车辆在环路上循环行驶，每到一站只要有空座就立刻让候车乘客上车，人满也不等，直接出发。每个乘客的目标站数各不相同，到站就下车，空位马上被下一位乘客补上。

Continuous Batching 正是这种“迭代级调度”。它不再把一个批次当作铁板一块，而是让调度器在每个解码步骤（decode step）结束后检查一次：哪些请求已经生成完毕？完成的立即移出批次，并立刻从等待队列插入新请求。插入操作发生在每一个迭代步之后，而不是等整批结束。

为了衡量这种调度的“满载程度”，定义占用率：设批次最大容量为 B_max，第 t 个迭代步的实际请求数为 B_t，共运行 N 步，则平均占用率为：

拼车小巴永远在补位，连续批处理也永远在补位。被取消的“整批等待”，正是吞吐量飞跃的起点。

GPU 利用率：让每块算力都坐满

公交公司算了一笔账：满载的小巴每公里的收益是空载车的五倍。调度中心的核心目标因此变成——让车辆在任何时刻都有尽可能多的乘客。

对 GPU 来说，让算力“坐满”同样关键。连续批处理通过两件事提升利用率：一是消除了批次之间的等待空档，GPU 不再发呆；二是长短请求互补，短请求快速下车、长请求继续占座，队列里始终有新请求补入，batch 保持高位。

推理服务的核心指标是吞吐量（Throughput）。设一次运行中 B 个请求各自生成了 output_len_i 个 token，引擎总耗时为 t_engine，则：

满载的车辆带来翻倍的营收。同样，当 GPU 的每条计算单元都在产出 token 时，成本被摊薄，用户等待也显著缩短——这就是连续批处理的商业魔力。

KV 缓存：乘客的行李牌与共享路段

拼车小巴上每位乘客都有一块行李牌，记录自己已经走过的站点。如果两位乘客要去同一片区，他们可以共享前一程的记录，不必重新认路。

大模型的自回归解码有个特点：生成下一个 token 时，需要重新计算前面所有 token 的注意力分数。为了避免重复劳动，推理引擎把每个已生成 token 的 Key（K）和 Value（V）向量缓存下来，这就是 KV Cache。它相当于每个请求的“行李牌”——生成得越长，行李越多，占用的显存也越大。

以一个 L 层、H 个注意力头、每个头维度为 D 的模型为例，序列长度为 S 的请求，它的 KV Cache 显存占用为：

行李牌多了，车厢就挤了。连续批处理下不同请求的行李牌交错摆放，如何高效安放，成了下一节的核心问题。

vLLM 框架：分页停车坪与调度器实战

拼车公司的停车场曾因碎片化浪费大量空间：每位乘客固定占一块区域，下车后区域零散无法合并使用。后来停车场改成“分块停车坪”，车辆按标准车位灵活停放，碎片空间瞬间被激活。

vLLM 正是把这个思路带进大模型推理的开源框架。它的核心是 PagedAttention：把 KV Cache 切分成固定大小的块（block），按需分配、不连续存放，像操作系统分页一样管理显存。配合迭代级调度器，vLLM 实现了真正的 Continuous Batching，并支持抢占（preemption）：当显存不足时，先把低优先级请求的 KV Cache 换出到 CPU，腾出空间后再换回。

碎片率是衡量管理效果的关键指标。设已分配显存可容纳的 token 数为 Capacity，其中真正有数据的有效 token 数为 V_valid，则碎片率为：

分块停车坪让每一寸空间都用起来。vLLM 因此能把更多请求塞进同一块 GPU，这也是它成为当下部署大模型首选框架的原因。

性能指标：调度中心的 KPI 报表

调度中心每月出一份 KPI 报表：总运客量（吞吐）、最久乘客等待时间（长尾延迟）、每公里成本（成本效率）。三张表放在一起，才能评判拼车改革值不值得。

衡量连续批处理也一样，不能只看单一指标。吞吐量（tokens/s 或 requests/s）反映整体产能；TTFT（首 token 延迟）和 p99 解码延迟反映用户体验；显存占用与 GPU 利用率反映成本。连续批处理追求的是在满足延迟约束（SLA/SLO）的前提下最大化吞吐。

假设同一份请求流分别在静态和连续批处理下运行，得到吞吐量 TPT_static 与 TPT_continuous，加速比为：

KPI 报表最终告诉老张：满载的智慧不只在运量，更在让每一个等待都有价值。对推理工程师来说，理解这些指标，才能在成本和体验之间找到最优解。

AI 应用场景

Python 演示

import random  class FakeRequest:    """模拟一个 LLM 推理请求, 需要生成 output_len 个 token"""     def __init__(self, req_id, output_len):        self.req_id = req_id        self.output_len = output_len        self.generated = 0     def is_done(self):        return self.generated >= self.output_len     def decode_one_step(self):        self.generated += 1        return self.is_done()  def simulate(mode, requests, max_batch):    pending = list(requests)    running = []    total_tokens = 0    steps = 0     if mode == "static":        while pending:            batch = pending[:max_batch]            pending = pending[max_batch:]            while batch:                for req in batch:                    req.decode_one_step()                total_tokens += len(batch)                batch = [req for req in batch if not req.is_done()]                steps += 1    else:        while pending or running:            while len(running) < max_batch and pending:                running.append(pending.pop(0))            if not running:                break            for req in running:                req.decode_one_step()            total_tokens += len(running)            running = [req for req in running if not req.is_done()]            steps += 1     return total_tokens / max(steps, 1)  def main():    random.seed(2024)    reqs = [FakeRequest(i, random.randint(4, 12)) for i in range(60)]    static_tpt = simulate("static", reqs, max_batch=8)     random.seed(2024)    reqs = [FakeRequest(i, random.randint(4, 12)) for i in range(60)]    continuous_tpt = simulate("continuous", reqs, max_batch=8)     print("静态批处理平均每步吞吐: %.2f tokens" % static_tpt)    print("连续批处理平均每步吞吐: %.2f tokens" % continuous_tpt)    print("连续批处理加速比: %.2fx" % (continuous_tpt / max(static_tpt, 1e-9)))  if __name__ == "__main__":    main()

1. def decode_one_step(self):每调用一次代表 GPU 解码一步，生成 1 个 token。
2. batch = [req for req in batch if not req.is_done()]静态模式必须整批一起等，直到所有请求完成才换下一批。
3. total_tokens += len(batch)这一步产出的 token 数等于当前活跃请求数。
4. while len(running) < max_batch and pending:连续模式一有空位就立刻从等待队列补入新请求。
5. running = [req for req in running if not req.is_done()]连续模式只移除本步完成的请求，不影响其他请求继续生成。
6. return total_tokens / max(steps, 1)平均每步吞吐量，用于公平对比两种调度模式。

常见误区

面试题