Continuous Batching 深度解析：为什么 LLM 推理不能用传统 Request Batching

如果你做过 Web 后端，对"请求合并批量处理再返回"应该不陌生。但在 LLM 推理领域，这个模式完全行不通——传统静态 batching 的吞吐只有 Continuous Batching 的 十分之一不到。本文从后端工程师的视角，拆解这两种 batching 的根本差异。

一、传统 Request Batching 为什么在 LLM 上翻车？

后端常见的 batch 模式：攒一批请求，一起发给数据库或下游服务，全处理完再逐个返回。伪代码大概长这样：

def traditional_batch(requests: list[Request]) -> list[Response]:
    batch = []
    for req in requests:
        if len(batch) >= MAX_BATCH_SIZE:
            results = process_batch(batch)  # 等全处理完
            batch = []
        batch.append(req)
    return send_responses(results)

在 LLM 场景里，这个模式有致命的"木桶效应"：一个 batch 的完成时间取决于输出最长的那个请求。

时间轴 →

请求 A (10 tokens):  ████████████████████████████████⏳⏳⏳⏳⏳⏳⏳⏳⏳⏳⏳⏳⏳⏳⏳
请求 B (60 tokens):  ████████████████████████████████████████████████████████████████
请求 C (6 tokens):   ██████████⏳⏳⏳⏳⏳⏳⏳⏳⏳⏳⏳⏳⏳⏳⏳⏳⏳⏳⏳⏳⏳⏳⏳⏳⏳⏳⏳⏳⏳⏳

图例：█ = GPU 在工作，⏳ = GPU 空闲

请求 C 只生成 6 个 token，但它必须等着 B 生成 60 个 token。这 54 个 token 的等待时间里，C 占着一个显存槽位却不能释放，GPU 也在浪费时间——这种「完成即释放」的朴素模型，显存利用率不到 15%，吞吐不到 3 req/s（以 LLaMA-7B、A10 GPU、平均输出 128 tokens 实测）。

核心矛盾：自回归解码的每一步都是串行的，但不同请求的步数完全不同。

二、Continuous Batching：把 Server 从请求级变成迭代级

Continuous Batching 最早由 vLLM（Kwon et al., SOSP 2023）在工业界引起广泛关注，TGI、TensorRT-LLM 随后都实现了自己的版本。核心思路只有一条：

不要让请求等请求——让请求在任意一次迭代中自由进出 batch。

# 传统 batching：请求级
batch = [req_a, req_b, req_c]
for token in generate_tokens(batch):  # 等最慢的那个
    pass

# Continuous Batching：迭代级
scheduler = Scheduler()
while scheduler.has_pending():
    running_batch = scheduler.schedule()  # ← 每步重新决定 batch 里有哪些请求
    next_tokens = model.forward(running_batch)
    for req, token in zip(running_batch, next_tokens):
        req.append(token)
        if token == EOS:
            scheduler.remove(req)     # 完成就立即移出
    scheduler.maybe_add_waiting()     # 有槽位就加入新请求

时间轴变成这样：

时间轴 →

请求 A (10 tokens): ████████████
请求 B (60 tokens): ████████████████████████████████████████████████████████████████
请求 C (6 tokens):  ██████
请求 D (等待):       ⏳⏳⏳⏳⏳████████████████

图例：█ = GPU 在工作，⏳ = 排队等槽位

请求 C 一完成就释放 GPU 显存，请求 D 立即补上。A 完成后，D 接着用 A 的槽位。GPU 利用率从不到 15% 拉到接近 90%，吞吐飙到 30+ req/s（同样配置）。这不是渐进优化，是质的飞跃。

三、Prefill 与 Decode 的调度分离

LLM 一次推理其实分两个阶段：

阶段	输入	计算特征	瓶颈
Prefill	全部 prompt tokens	计算密集（compute-bound），大矩阵乘法	GPU 算力
Decode	单个 token	显存带宽密集（memory-bound），搬权重比算乘法慢	HBM 带宽

这个差异对 Continuous Batching 至关重要。如果每次迭代既有 prefill 又有 decode，就会出现：

1. Prefill 的 compute-bound 特性会拖慢 decode 响应——decode 本来 15ms 一步，prefill 插入后可能变成 50ms，所有正在 decode 的请求都感受到延迟抖动。
2. 大 prompt 的 prefill 可能耗尽显存，导致 decode 中的请求被 OOM 踢出。

解决方案有三种：

方案一：Chunked Prefill（vLLM / TGI 的默认策略）

把长 prompt 的 prefill 切成固定大小的 chunk，和 decode batch 混排调度：

# 每个 chunk 只算 MAX_PREFILL_TOKENS 个 token
def prefill_chunked(prompt_tokens, max_chunk=2048):
    for i in range(0, len(prompt_tokens), max_chunk):
        chunk = prompt_tokens[i:i + max_chunk]
        kv_cache = model.forward_prefill(chunk)
        # 每算完一个 chunk 就把控制权交还给调度器
        yield kv_cache
    return kv_cache

每个 chunk 之间，调度器有机会处理 decode 请求，避免长时间阻塞。实测数据显示（vLLM 团队，2024），chunked prefill 把 TTFT（Time to First Token）的 P99 从 2.3s 降到 0.4s（500 token prompt，A100）。

方案二：Prefill / Decode Disaggregation（Splitwise 等）

这是更激进的做法——直接把 prefill 和 decode 放到不同 GPU 上：

          prefill 节点 (H800 × 2)
         /           \
请求 → [Prefill]    [Prefill]
         \           /
          \         /
           [KV Cache 传输层] (NCCL / InfiniBand)
           /         \
          /           \
         [Decode]    [Decode]    ←  decode 节点 (H800 × 4)

DeepSpeed-FastGen（2024）的做法类似。优势：

• Prefill 节点用大 batch 跑 compute-bound 任务，充分吃满 GPU 算力
• Decode 节点用较小 batch 跑 memory-bound 任务，控制延迟
• 两个集群可以独立扩缩容

代价是多了一跳 KV Cache 传输延迟，外加多了一倍的 GPU 节点。

方案三：KV Cache Offload（FlexGen / Infinite-LLM）

把暂时不用的 KV Cache 页从 GPU 显存搬到 CPU 内存。当请求长时间未被调度时（比如用户暂停输入），它的 KV Cache 可以被 offload 出 GPU，释放显存给活跃请求。下次调度时再 load 回来。

这是空间换时间，传输开销和调度复杂度都会增加。实践中更多作为超长上下文场景的补充手段。

四、PagedAttention：让 Continuous Batching 的显存管理真正可用

Continuous Batching 解决了调度问题，但引入了新的显存管理问题。每个请求的 KV Cache 需要预留显存——如果按 max_length 预留，一个 4096 token 上限的请求需要占用几十 GB；如果动态分配，频繁的 alloc/free 会导致严重的显存碎片。

vLLM 的 PagedAttention（受操作系统虚拟内存启发）用页表管理 KV Cache：

class PageTable:
    """每个请求维护一个页表，指向物理 KV Cache 页"""
    def __init__(self, num_layers, page_size=16):
        self.entries: dict[int, list[int]] = {}  # layer_id → [page_ids]

    def append(self, layer_id, page_id):
        if layer_id not in self.entries:
            self.entries[layer_id] = []
        self.entries[layer_id].append(page_id)

class BlockManager:
    """物理页分配器，类似操作系统的物理内存管理"""
    def __init__(self, num_blocks, block_size):
        self.free_blocks = list(range(num_blocks))
        self.block_size = block_size  # 每页 16 个 token 位置

    def allocate(self, num_blocks) -> list[int]:
        if len(self.free_blocks) < num_blocks:
            raise OutOfMemory("No free blocks")
        allocated = self.free_blocks[:num_blocks]
        self.free_blocks = self.free_blocks[num_blocks:]
        return allocated

    def free(self, block_ids: list[int]):
        self.free_blocks.extend(block_ids)

这带来了三个关键能力：

1. 显存零浪费：请求只占用实际生成 token 数对应的页数，不预留任何 padding
2. 无碎片：页大小固定（16 tokens），不存在外部碎片；内部碎片上限为 15 个 token
3. 高效共享：beam search 或 parallel sampling 中，相同 prompt prefix 的 KV Cache 可以跨请求共享（写时复制）

没有 PagedAttention，Continuous Batching 的显存利用率会被碎片拖累到 20-40%。有了它，vLLM 实测能跑到 96% 的显存利用率（SOSP 2023 论文数据）。

五、简化版调度器实现

下面是一个精简的 Continuous Batching 调度器，核心逻辑不到 200 行。它展示了迭代级调度、prefill chunking、请求进出 batch 的完整流程：

from dataclasses import dataclass, field
from collections import deque
from enum import Enum

class Phase(Enum):
    WAITING = 0      # 等待被调度
    PREFILLING = 1   # 正在处理 prompt
    DECODING = 2     # 正在逐 token 生成
    DONE = 3

@dataclass
class Request:
    req_id: str
    prompt_tokens: list[int]
    max_tokens: int
    phase: Phase = Phase.WAITING
    generated_tokens: list[int] = field(default_factory=list)
    prefill_progress: int = 0  # 已处理的 prompt token 数

    @property
    def is_finished(self) -> bool:
        return (self.phase == Phase.DONE or
                len(self.generated_tokens) >= self.max_tokens or
                (self.generated_tokens and self.generated_tokens[-1] == EOS_TOKEN_ID))

    def remaining_tokens(self) -> int:
        return self.max_tokens - len(self.generated_tokens)

class ContinuousBatchingScheduler:
    def __init__(
        self,
        max_batch_tokens: int = 4096,      # batch 内最大 token 总数
        max_prefill_chunk: int = 512,       # 每次 prefill 最多处理的 token 数
        max_running_requests: int = 64,
    ):
        self.max_batch_tokens = max_batch_tokens
        self.max_prefill_chunk = max_prefill_chunk
        self.max_running_requests = max_running_requests
        self.waiting_queue: deque[Request] = deque()
        self.running: list[Request] = []

    def add_request(self, req: Request):
        self.waiting_queue.append(req)

    def schedule(self) -> list[Request]:
        """核心调度逻辑：决定本轮 forward 的 batch 组成"""
        batch = []

        # === 第一步：decode 请求优先 ===
        # decode 是一次 forward 一个 token，延迟敏感
        for req in self.running:
            if req.phase == Phase.DECODING:
                batch.append(req)
                req.generated_tokens.append(None)  # placeholder，由 model.forward 填充

        # === 第二步：prefill 从等待队列中调度 ===
        # 按 token 数限制，避免阻塞 decode
        tokens_remaining = self.max_batch_tokens - len(batch)

        # 先处理 running 中还在 prefill 的请求（chunked prefill 的下一个 chunk）
        for req in self.running:
            if req.phase != Phase.PREFILLING or tokens_remaining <= 0:
                continue
            unprocessed = len(req.prompt_tokens) - req.prefill_progress
            if unprocessed == 0:
                req.phase = Phase.DECODING
                continue
            chunk_size = min(unprocessed, self.max_prefill_chunk, tokens_remaining)
            req.prefill_progress += chunk_size
            tokens_remaining -= chunk_size
            if req not in batch:
                batch.append(req)

        # 再从 waiting 队列中取新请求做 prefill
        while tokens_remaining > 0 and self.waiting_queue:
            slots_left = self.max_running_requests - len(self.running)
            if slots_left <= 0:
                break

            req = self.waiting_queue[0]
            token_budget = min(
                len(req.prompt_tokens),
                self.max_prefill_chunk,
                tokens_remaining
            )
            if token_budget == 0:
                break

            req.phase = Phase.PREFILLING
            req.prefill_progress = min(token_budget, len(req.prompt_tokens))
            tokens_remaining -= token_budget
            self.waiting_queue.popleft()
            self.running.append(req)
            batch.append(req)

        return batch

    def post_forward(self, batch: list[Request], output_tokens: list[int]):
        """model.forward 完成后更新请求状态"""
        finished = []
        for req, token in zip(batch, output_tokens):
            if req.phase == Phase.DECODING:
                req.generated_tokens[-1] = token  # 回填 placeholder
            if req.is_finished:
                req.phase = Phase.DONE
                finished.append(req)

        for req in finished:
            self.running.remove(req)

    def stats(self) -> dict:
        return {
            "waiting": len(self.waiting_queue),
            "running": len(self.running),
            "running_phases": {req.req_id: req.phase.name for req in self.running},
        }

关键设计点：

1. Decode 优先：decode 请求一次只处理一个 token，延迟敏感，必须优先入 batch（否则已开始吐字的用户会卡住）。
2. Token 预算制：max_batch_tokens 不是请求数上限而是 token 数上限。batch 里是 4 个长响应还是 40 个短响应，取决于 token 预算而不是固定槽位数。
3. Prefill chunking：max_prefill_chunk 把大 prompt 切成小块，和 decode 交替处理，这是 P99 TTFT 从秒级降到毫秒级的关键。

六、性能数据

vLLM 论文（SOSP 2023）的 benchmark，以 LLaMA-13B 在 A100-40G 上跑 ShareGPT 数据集（平均 prompt 150 tokens，平均输出 350 tokens）：

方案	吞吐 (req/s)	GPU 显存利用率	TTFT P50	T POT P99
无 batching	1.2	12%	800ms	25ms
静态 batching (batch=8)	3.5	18%	2200ms	120ms
Continuous Batching	14.3	72%	650ms	30ms
+ PagedAttention	24.5	96%	380ms	28ms

三点值得注意：

• 静态 batching 的 TTFT 反而更差（2.2s），因为请求必须等前一批全部完成才能开始 prefill。
• Continuous Batching 的 TPOT（Time Per Output Token）和单请求几乎持平，因为 decode 阶段的每个请求只算一个 token，不存在互相阻塞。
• PagedAttention 的增益（14 → 24 req/s）来自更高的显存利用率——能同时跑更多请求。

另外，Anyscale 团队 2024 年用 Llama-2-70B 在 8×A100 上的测试显示：Continuous Batching + chunked prefill 的组合，比 naive batching 的吞吐提升最高达到 8-12 倍，在输出长度方差较大的真实生产流量中尤其明显。

七、生产实践中的坑

1. Prefill 风暴

当大量请求同时到达（比如服务重启后 backlog 恢复），调度器会面临"prefill 风暴"：数十个等待请求都想抢 prefill 槽位。如果 max_prefill_chunk 没设好，decode 中的用户会遭遇明显延迟抖动。

解决：限制每轮 prefill 的总 token 预算，并且对 prefill 和 decode 做独立限制：

# 典型生产配置
scheduler = ContinuousBatchingScheduler(
    max_batch_tokens=8192,      # 总预算
    max_prefill_tokens=2048,    # prefill 子预算
    max_decode_tokens=6144,     # decode 子预算
    max_prefill_chunk=512,      # 单个请求的 chunk 上限
)

2. 长输出饥饿

一个生成 4096 token 回复的请求，从开始到结束占了 4096 次 decode iteration。如果队列里有大量短回复请求，它们会在长请求结束后一拥而入，造成 prefill 风暴。反过来，如果短回复请求持续涌入，长请求的 decode 永远抢不到 prefill slot 去"完成"。

解决：给连续 decode 次数加上限，超限后强制把该请求标记为低优先级，让别的请求有机会 prefill。或者使用 priority-aware 调度（vLLM 1.5+ 支持）。

3. 序列长度预测不准

调度器决策依赖对输出长度的预测（比如用 max_tokens 做预算规划）。但用户设的 max_tokens=4096 实际只生成 50 个 token 的情况非常普遍。这导致显存预留过大，实际利用率低。

解决：用轻量分类模型预测输出长度（Response Length Prediction），动态调整显存预算。vLLM 的 prefix caching 和 swap 机制也能缓解这个问题。

4. Speculative Decoding 与 Continuous Batching 的交互

投机解码会一次生成 K 个候选 token（而不是 1 个），这会改变 decode 阶段的 token 预算计算。如果连续多轮投机都成功（accept K tokens），该请求实际占用的预算会短暂膨胀。

vLLM 的处理方式是把投机解码的 K 个候选 token 作为一次"超级 decode"处理，占用 K 个 token 预算。如果 draft 模型命中率高，这个请求几乎相当于并行生成；如果命中率低，预算被浪费。实践中要监控 acceptance rate，低于 50% 时考虑关闭该请求的投机解码。

八、总结

Continuous Batching 是 LLM 推理从"能跑起来"到"能上线服务"的关键工程突破。它的核心洞察——"不要让请求等请求"——说起来简单，但背后是一整套调度器设计、显存管理和延迟控制策略。

几个关键数字记一下：

• 无 batching → Continuous Batching：吞吐提升 10-20 倍
• PagedAttention：在 Continuous Batching 基础上再提升 50-70%
• Chunked Prefill：P99 TTFT 降幅 80%+
• Prefill/Decode 分离：进一步解耦 latency/cost trade-off，适合大规模部署

如果你是后端工程师转 AI Infra，Continuous Batching 的调度器设计（迭代级调度、token 预算、优先级队列）会让你感觉很亲切——它本质上就是一个 GPU 资源调度的操作系统，只是调度单位从进程变成了 token 序列。

参考文献

• Kwon et al., "Efficient Memory Management for Large Language Model Serving with PagedAttention", SOSP 2023
• Yu et al., "Orca: A Distributed Serving System for Transformer-Based Generative Models", OSDI 2022
• Agrawal et al., "Splitwise: Efficient Generative LLM Inference Using Phase Splitting", ISCA 2024
• vLLM 源码: https://github.com/vllm-project/vllm
• DeepSpeed-FastGen: https://github.com/microsoft/DeepSpeed