大模型性能优化指南：Continuous Batching技术原理与实现，收藏必备！

Continuous Batching技术深度解析

原创于 2025-11-28 14:18:48 发布 · 158 阅读

3 ·

CC 4.0 BY-SA版权

文章标签：

#语言模型 #大模型 #产品经理 #学习 #人工智能 #ai #转行

在使用 Qwen、Claude 或 ChatGPT 等大模型服务时，你可能观察到一个现象：首个字的生成往往有短暂延迟（Time to First Token），随后文字便如流水般逐个出现。这背后的核心在于 LLM 的工作本质——它是一个昂贵的“下一个 Token 预测器”。为了在生产环境中同时服务数千用户并最大化 GPU 利用率，业界引入了一系列推理优化技术。其中，Continuous Batching（连续批处理） 是目前最关键的优化手段之一。本文将从 Attention 机制和 KV Cache 出发，逐步拆解 Continuous Batching 如何通过消除 Padding 浪费和动态调度，实现推理吞吐量的质的飞跃。

1. 技术基石：Attention 机制与生成过程

要理解推理优化，首先必须回顾 LLM 处理 Token 的基本方式。

1.1 Token 的交互与计算

语言模型通过将文本切分为 Token（词元）进行处理。虽然许多网络操作（如层归一化）是逐 Token 独立进行的，但为了理解语义，Token 之间必须产生联系。这就是 Attention（注意力） 层的用武之地——它是模型中唯一让不同 Token 相互“看见”并计算相关性的地方。

假设输入提示词为 I am sure this project（共7个 Token），模型会通过以下步骤处理：

投影（Projection）： 输入张量分别通过矩阵投影，生成 Query ()、Key () 和 Value () 向量。
相似度计算： 计算和的乘积（），衡量 Token 间的相似度。其复杂度为。
掩码（Masking）： 应用 Causal Mask（因果掩码）。这至关重要，它确保位置的 Token 只能看到及其之前的 Token（过去不能被未来影响）。
输出： 经过 Softmax 归一化后与相乘，得到注意力输出。

1.2 Prefill（预填充）与 Decode（解码）

LLM 的推理过程分为两个截然不同的阶段：

Prefill 阶段： 模型并行处理完整的输入 Prompt（如上文的 7 个 Token），计算并缓存中间状态，生成第一个新 Token（如 “will”）。此时计算密度高，主要利用 GPU 的并行计算能力。
Decode 阶段： 基于之前所有 Token，逐个生成下一个 Token。这是一个自回归过程，每生成一个新 Token，都需要“回顾”之前的上下文。

2. 核心优化一：KV Cache (键值缓存)

在 Decode 阶段，如果简单粗暴地执行前向传播，会产生巨大的计算浪费。

2.1 为什么需要缓存？

当我们生成了第 8 个 Token “will” 并想预测第 9 个 Token 时，根据因果掩码的特性，前 7 个 Token（“I am sure…”）的 Key 和 Value 投影结果并不会因为新 Token 的加入而改变。

如果我们每次都重新计算前 7 个 Token 的和，计算复杂度将维持在。通过 KV Cache，我们将之前步骤计算好的和向量存储在显存中，生成新 Token 时仅计算当前 Token 的，并与缓存拼接。

收益： 将解码复杂度从降低到。
代价： 显存占用增加。对于 Llama-2-7B（32层，32头，维度128），每个 Token 约占用 16KB 显存（FP16精度）。随着上下文长度增加，显存压力呈线性增长。

3. 核心优化二：Chunked Prefill (分块预填充)

KV Cache 不仅用于解码，还解决了长文本（Long Context）的内存瓶颈问题。

在处理超长 Prompt（如使用 Cursor 将整个代码库作为上下文）时，Token 数量可能导致中间激活值超出显存上限。Chunked Prefill 允许我们将长 Prompt 切分为多个小块（Chunk）分批进入模型：

处理第一个 Chunk，将生成的 KV 状态存入缓存。
处理第二个 Chunk 时，读取缓存并拼接，确保注意力计算覆盖之前的上下文。

这种机制不仅避免了 OOM（显存溢出），也为后续的细粒度调度奠定了基础。

4. 终极形态：Continuous Batching (连续批处理)

在理解了基础组件后，我们来看看如何通过批处理（Batching）提升服务吞吐量。

4.1 传统 Batching 的痛点：Padding 带来的浪费

为了并行处理多条请求，传统方法是将多个 Prompt 组合成一个 Batch。由于张量运算要求形状规整（矩形），我们必须对短序列进行 Padding（填充），使其与最长序列对齐。

这种方法在 LLM 推理中有两个致命缺陷：

“木桶效应”： 整个 Batch 必须等待最长的序列生成结束（遇到 <eos>）才能释放资源。短序列虽然生成完了，但显存和算力仍被占用。
无效计算： 在动态调度（Dynamic Batching）中，如果我们在一个 Batch 中插入一条新请求（处于 Prefill 阶段），而其他请求处于 Decode 阶段，由于长度差异巨大，会导致大量的 Padding 填充。

数据示例： 若 Batch Size=8，新插入请求长度=100，则需要填充个无效 Token。这意味着大量算力被浪费在计算 Padding 上。

4.2 解决方案：Ragged Batching (参差批处理)

Continuous Batching 的核心思想是打破张量的几何束缚。如果不强制要求 Tensor 是矩形的，我们就不需要 Padding。

实现逻辑：

物理拼接： 将 Batch 中所有请求的 Token 在一维数组上直接拼接（Concatenate）。

输入：[Prompt A Tokens] [Prompt B Tokens] ...

逻辑隔离： 利用 Attention Mask 这种“软件逻辑”来控制可见性。

构建一个分块对角掩码（Block-diagonal Mask），确保 Prompt A 的 Token 只能看到 Prompt A 的内容，完全屏蔽 Prompt B。

这种方式被称为 Ragged Batching，它彻底消除了 Padding token，让 GPU 的每一次计算都作用于真实数据。

4.3 连续批处理调度算法

结合 KV Cache、Chunked Prefill 和 Ragged Batching，Continuous Batching 实现了一个极其高效的调度循环。

**调度策略：**我们设定一个总的显存/计算预算（Token 数量上限，记为）。在每一个推理步（Step）：

优先解码（Decode）： 将所有正在生成中的请求加入 Batch。因为解码阶段每个请求仅贡献 1 个 Token，开销较小。
填充预处理（Prefill）： 利用剩余的预算空间，插入新到达请求的 Prefill 数据。

如果新请求太长，使用 Chunked Prefill 将其拆分，只填满剩余预算即可。

动态更替： 一旦某个请求生成了 <eos>，立即将其移除，释放的空间在下一个 Step 马上被新请求填补。

伪代码逻辑解析：

# 这是一个概念性的调度逻辑简化描述def continuous_batching_step(running_requests, waiting_queue, memory_budget):    batch_tokens = []        # 1. 优先处理正在解码的请求 (每个请求贡献1个token)    for req in running_requests:        batch_tokens.append(req.get_next_input_token())            # 2. 计算剩余容量    remaining_budget = memory_budget - len(batch_tokens)        # 3. 用新请求的 Prefill 填满剩余容量 (利用 Chunked Prefill)    while remaining_budget > 0andnot waiting_queue.is_empty():        new_req = waiting_queue.peek()        # 获取新请求的下一块 Token，大小不超过剩余预算        chunk = new_req.get_next_chunk(size_limit=remaining_budget)                batch_tokens.append(chunk)        remaining_budget -= len(chunk)                if new_req.is_prefill_complete():            running_requests.add(new_req)            waiting_queue.pop()    # 4. 执行无 Padding 的前向传播 (Ragged Batching)    run_model_forward(batch_tokens)

这种机制允许 Prefill（计算密集型）和 Decode（显存带宽密集型）任务在同一个 Batch 中混合运行，极大地提升了 GPU 的利用率和整体吞吐量。