Continuous Batching

3 秒看懂

Continuous Batching（连续批处理）将大语言模型推理从“等所有人准备好再一起出发”变为“流水线上一人接着一人不停工”。它在每一次 GPU 计算步（生成一个 token）动态插入新请求、即时移除已完成请求，使硬盘利用率与吞吐量达到静态批处理的数倍，成为当前所有主流 LLM 推理引擎的标配调度策略。

3 分钟产业解释

大模型推理是一类“生成式”负载：每个请求的输入长度不同，输出长度也动态变化。传统静态批处理（Static Batching）要求一个批次内所有请求必须同时开始、全部完成输出之后才整体返回结果，导致大量 GPU 计算单元在“短板请求”上被迫空等，长尾延迟极高。动态批处理（Dynamic Batching）虽然可以在一个时间窗口内收集请求成批，但批次一旦形成就无法中途增减成员，仍存在队头阻塞。

Continuous Batching 则彻底拆掉批次边界：调度器维护一个活跃请求池，每做一次矩阵乘法（一次 forward）都只生成每个请求的下一个 token。新到达的请求可以在下一轮计算即刻加入；只要某个请求生成结束符（EOS）或被终止，其所占用的显存 slot 立刻被释放。整块 GPU 几乎不间断地执行密集矩阵运算，空闲时间被压缩至极致，从而使同等硬件下可并发的用户数、每秒生成的总 token 数实现质的飞跃。该技术是大模型 API 成本急剧下降的核心引擎，广泛存在于 vLLM、NVIDIA TensorRT-LLM、HuggingFace TGI、LMDeploy 等框架中。

技术原理

核心矛盾：Transformer 自回归推理时，每生成一个 token 都需执行完整模型前向传播。增大批处理规模可以摊薄计算单位开销（更高的 GPU 计算效率），但若按照“请求”为边界收集固定大小的批次，必然会引入等待延迟和碎片化闲置。

iteration‑level 调度：Continuous Batching 将“批次”重新定义为一个 iteration（一次生成步）的快照，而非请求的整个生命周期。其工作流程可以概括为以下循环：

1. 调度器从活跃请求池中挑选请求拼成当前 batch，送入模型执行一次 forward，获得每个请求的新一个 token。
2. 返回后立即检查：哪些请求已生成结束符、达到最大输出长度或被用户取消？这些请求被移出活跃池，其占据的 KV cache 空间被标记为可回收。
3. 等待队列中的新请求在本次 iteration 结束后可以“即插即用”地加入活跃池，参与下一次 forward。
4. 反复执行上述过程，无需等待任何一个“批次完成”，GPU 始终处于工作状态。

内存管理关键：PagedAttention：动态插拔请求意味着 KV cache 必须能够快速分配与回收，否则显存碎片化将严重限制并发上限。vLLM 提出的 PagedAttention 将 KV cache 切分为固定大小的 block，采用类似操作系统分页的机制进行非连续映射，当一个请求被移除时，整块 block 被直接回收，避免了静态预留和碎片。这使得 Continuous Batching 的高频调度在工程上真正可行。

与 prefix caching 协同：若多个请求共享相同的系统提示词（prefix），其 KV cache 可被缓存在显存中复用，新请求在 prefill 阶段可以直接拷贝已缓存的 block，从而大幅降低 prefill 时间并进一步提高有效吞吐。Continuous Batching 的调度器可以在一次 iteration 内部感知这些可复用块并优先调度同源请求，放大整体收益。

定性效果（基于公开的行业经验，无统一基准）：在相同硬件与模型条件下，若并发请求数足够且长短差异明显，Continuous Batching 相较于静态批处理可将每秒生成 token 数提升 2‑10 倍，同时将 P99 尾延迟压低一个数量级。当请求稀疏（batch size 长期为 1）时优势不明显。

关键参数

以下参数没有全行业统一的标准数值，因为它们与模型尺寸、序列长度分布、请求到达模式强相关，但它们共同决定了 Continuous Batching 的最终表现。

• 最大批次大小（max batch size）：受 GPU 显存（尤其是 HBM）上限约束，Continuous Batching 追求实际“有效 batch size”尽可能长时间贴近该上限。
• 有效批大小（Effective Batch Size）：单次 forward 实际参与的请求数。其动态变化曲线是衡量调度器能力的重要指标，目标是在满足延迟 SLO 的前提下维持高位。
• 首 token 时延（Time to First Token, TTFT）：从请求发出到首个 token 生成的时间。Continuous Batching 下，即使当前活跃 batch 较大，得益于 dynamic 调度，TTFT 通常仍可控，但极端大 batch 时可能会因计算阵扩大而轻微上升。
• 每 token 生成时延（Token Per Output Token, TPOT / Inter-token Latency）：两个连续 token 之间的平均间隔。它与有效 batch size 正相关：batch 越大，单次 forward 的计算量越大，单 token 间隔越长，但整体吞吐可能更高。服务部署必须在吞吐与时延间进行权衡。
• KV cache 占用率：显存中已分配的 KV cache 比例。直接影响可并发请求数。PagedAttention 能将碎片率控制在极低水平，接近线性扩展。
• 队列等待时间：新请求在调度队列中的停留时长，反映调度的饥饿程度。精细的优先级策略和抢占机制（如 prefill 阶段可被 decode 请求抢占）可对其优化。
• Prefill 延迟：处理提示词并生成 KV cache 的阶段耗用计算和 I/O 很大，Continuous Batching 常将 prefill 与 decode 步骤分离调度或合并，如何平衡两者对整体效率影响显著。

（以上指标的具体数值高度依赖业务场景，没有任何权威机构发布过“标准值”。实践中，框架开发者常通过“吞吐‑延迟”帕累托曲线来评估调度算法优劣。）

技术路线

按照批处理调度的发展脉络，可梳理出三代路线，各自特点如下（以定性、近似经验描述，不做精确承诺）：

演进脉络：

• 2018‑2020 年，BERT 类编码器推理多用静态 padding 到最大长度，一次性处理整个序列。
• 2020‑2022 年，GPT 类自回归模型出现后，推理库开始引入动态轴（dynamic axis）批处理，但仍以“请求”为单位调度，请求完成后才能整批回收资源。
• 2023 年初，vLLM（UC Berkeley）以论文形式公开 PagedAttention 搭配 Continuous Batching，实现吞吐量飞跃，开源后迅速成为社区标杆；同年 NVIDIA 推出 TensorRT‑LLM 并内置 in‑flight batching，HuggingFace TGI 跟进实现。
• 2024‑2025 年，Continuous Batching 成为生产级推理栈的默认配置，并与 MoE 的 All‑to‑All 通信调度、推测解码、多 GPU 张量并行等深度协同，优化重心转向混合负载下的抢占式迭代调度、长上下文 KV cache 复用以及多模态请求的编排。

上游

Continuous Batching 高效运转依赖以下上游技术与硬件：

• GPU/NPU 硬件：高带宽存储器（HBM）容量和带宽决定可并发请求数的物理上限。NVIDIA H100、H200、B200 等不断扩展 HBM，使更大 batch 成为可能。近内存计算（如内存池化）也可能改变 cache 管理需求。
• 底层运算库：FlashAttention‑2/3、逐元素融合 CUDA kernel 等加速算子让每次 forward 时间足够短，支持高频 iteration 调度而不被计算开销吞没。
• KV cache 内存管理模块：PagedAttention 或类似的显存分配器（如 vAttention）是连续批处理的基石，负责快速的块分配、回收与映射，避免碎片。
• 模型压缩技术：量化（INT8/FP8）和稀疏化可缩小模型显存占用，同等物理显存下能容纳更多活跃请求，扩大 Continuous Batching 的收益基数。

下游

该技术的输出端变化直接影响整个生成式 AI 服务栈：

• 推理服务与 API：Chat API、代码补全、文本生成等几乎全部采用 Continuous Batching，吞吐提升直接转化为更低的每百万 token 单价，促使更多应用接入。
• 服务网格与网关：由于请求变成流式输出、不再成批返回，负载均衡需适配长连接与中断机制，部分网关需要支持请求的优先级控制和动态路由。
• 计费与成本模型：连续调度的吞吐增益使按 token 计费的云服务能够在激烈竞争中持续降价，也催生了“预留并发槽位”等新型定价模式。
• 推理芯片设计：连续批处理对显存管理器和调度器的要求正反向影响 NPU 架构设计，例如是否内置 page 管理单元、是否支持硬件级上下文抢占等。

受益公司

以公开信息为基础，列举技术应用链条上的典型受益组织，但不构成任何投资建议：

• NVIDIA：通过 TensorRT‑LLM 和 NIM 推理微服务推广 in‑flight batching，强化自家 GPU 在推理领域的软件护城河。据 NVIDIA FY2025 Q2 财报披露，数据中心收入中推理负载占比约 40%，连续批处理是提高推理性价比的核心技术。
• 云计算厂商（AWS、Microsoft Azure、Google Cloud）：均在其模型托管服务中应用连续批处理，降低自身算力成本并提升并发容量，Azure AI 在 2024 年公开文档中确认其推理 API 使用连续批处理。
• 独立推理平台（Together AI、Fireworks AI、Anthropic 等）：依靠持续优化的批处理技术提供高性价比的 API，参与价格竞争。Together AI 于 2024 年推出基于 TensorRT‑LLM 和自研调度的推理服务，Anthropic 在其内部推理系统中使用类似连续批处理的技术，但细节未公开。
• 开源项目商业支持方：Anyscale（vLLM 的商业化服务实体）将连续批处理整合进 Ray Serve，为中小企业提供部署方案。根据公开融资记录，Anyscale 在 2023 年 12 月完成约 1 亿美元的 C+轮融资，用于扩展推理服务能力（来源：Crunchbase）。
• 国内框架厂商：LMDeploy（上海人工智能实验室）、FastLLM 等将连续批处理作为默认特性，助力本土大模型推理部署，降低国产芯片上的推理门槛。

（以上公司受益程度因市场地位、客户覆盖等不同，暂未公开因连续批处理单独产生的营收份额。）

市场规模

目前缺乏专门针对“连续批处理技术”的独立市场规模统计，其价值内化于整个生成式 AI 推理市场。可以从几个侧面观察其经济影响力：

• 推理市场总盘：根据 Omdia 2024 年 3 月发布的《AI 推理服务器市场追踪报告》，2023 年全球 AI 推理服务器市场规模为 274 亿美元，预计 2028 年将达到 626 亿美元（来源：Omdia）。连续批处理通过提升 GPU 利用率，显著摊薄了单位推理成本，是该市场扩张的关键技术杠杆。
• 成本端体现：多家云厂商在过去 18 个月内大幅下调大语言模型 API 价格。例如 OpenAI 的 GPT‑4o 每百万 token 输出价格从 2023 年的 60 美元量级降至 2024 年 10 美元以下（来源：OpenAI 官方定价页，截至 2025 年 1 月），其中推理系统调度优化（包括连续批处理）是降本的支柱之一。
• 开源渗透率：vLLM 的 GitHub star 数从 2023 年 6 月的 0 快速攀升至 2024 年底的 30k+（来源：GitHub），反映大量开发者和企业正基于连续批处理构建推理系统，潜在可服务市场庞大。
• 硬件协同市场：NVIDIA H100/H200 的推理性能通过 in‑flight batching 改善，带动相关推理硬件出货。据 Mercury Research 2024 年 Q3 报告，数据中心 GPU 推理专用卡出货同比增长超过 200%，其中大部分受大模型推理负载驱动（来源：Mercury Research）。

（以上数字均注明来源与口径，若无对应细分数据则写“公开资料未见”。）

玩家对比

主流开源/闭源框架在连续批处理实现上各有侧重，下表基于公开文档、社区讨论和论文整理（截至 2025 年 2 月，特性可能随时变化）：

注：各框架在吞吐和延迟上的绝对数字高度依赖模型、请求分布和硬件，不宜直接横向评分。选择需基于自身业务负载进行多轮 PoC 测试。

风险

本节梳理 Continuous Batching 技术及产业环节可能面临的风险因素，非市场涨跌预测：

• 新技术迭代风险：推测解码（speculative decoding）和跳过解码（skip decoding）等加速方法可能降低对大批次依赖，若其独立实现足够高效，连续批处理的相对优势会被削弱；此外，稀疏专家模型（MoE）的 All‑to‑All 通信压力可能使 iteration‑level 调度的复杂度剧增，若优化不足，反而可能成为瓶颈。
• 硬件供给瓶颈：Continuous Batching 追求高并发，对 HBM 容量和带宽极度渴求。若未来先进封装产能受限或出口管制收紧，推理硬件的供给可能无法满足需求增长，限制技术推广。
• 碎片化与调度开销：在极高并发下，频繁的 slot 回收分配、调度器决策本身可能带来非忽略的 CPU 开销。国内部分团队报告在数千并发时，调度延迟上升，需要额外工程优化（来源：vLLM GitHub issues 讨论，无统一量化数字）。
• 开源商品化风险：vLLM 等开源方案的成熟可能使连续批处理能力迅速成为“标配”，独立推理厂商围绕该技术建立的差异化壁垒减弱，毛利率承压。部分云厂商已直接选用开源框架，削弱了自身推理引擎的商业价值。
• 标准竞争风险：NVIDIA 依托硬件生态推广闭源 TensorRT‑LLM，与开源社区形成路线分歧。若未来主流模型仅对某种调度接口优化，可能造成碎片化，增加企业技术选型成本。
• 安全与公平性：连续批处理中不同用户的请求同 batch 运行，若缺乏严格的租户隔离，可能出现侧信道攻击或在极端情况下造成 token 泄漏（已有学术论文讨论相关风险，但未见公开生产环境案例）。调度公平性若未妥善设计，也会导致部分用户饥饿，影响 SLA。

误读纠偏

误读 1：“Continuous Batching 就是 PagedAttention。”

• 纠正：PagedAttention 是一种 KV cache 内存管理算法，通过分页避免碎片化；Continuous Batching 是调度算法，定义何时将哪些请求打包计算。两者常被绑定讨论，因为 vLLM 同时引入它们且协同效果最优，但没有 PagedAttention 也可通过预分配连续缓存实现简配版连续批处理，只是并发上限和效率会大幅降低。

误读 2：“连续批处理总能无条件提高性能。”

• 纠正：在请求到达率极低、活跃 batch size 常为 1 的场景下，Continuous Batching 几乎没有额外收益；如果内存管理不当，频繁的 slot 回收甚至可能因碎片或 GC 开销导致吞吐下降。该技术的增益与“并发数和长度多样性”正相关。

误读 3：“使用连续批处理后，单 token 延迟不再受 batch 大小影响。”

• 实际上，单次迭代的矩阵乘法计算量正比于 batch size，大 batch 时 TPOT 必然上升。Continuous Batching 消除的是等待闲置，而非让大矩阵乘变快。部署仍需根据时延要求，设置合适的 max batch size 或调度策略，在吞吐与尾延迟间取得平衡。

误读 4：“只有 GPU 推理需要连续批处理。”

• 连续批处理同样适用于其他 AI 加速器（如 Google TPU、昇腾 NPU），核心是对显存/缓存的高效管理和动态调度。已有团队将其思想移植到 TPU v5e 上实现类似 in‑flight batching（来源：Google Cloud 博客 2024 年 9 月），表明该技术并非 GPU 专属。

最新事件

（以下事件基于公开报道、官方博客、代码仓库发布说明，截至 2025 年 2 月）

• 2023 年 6 月：vLLM 在 arXiv 发布论文《Efficient Memory Management for Large Language Model Serving with PagedAttention》，首次系统阐述连续批处理。同年该论文被 SOSP 2023 接收。
• 2023 年 10 月：NVIDIA 开源 TensorRT‑LLM，内置 in‑flight batching，同时支持 FP8 量化，显著提升 H100 上的推理性能。
• 2023 年 12 月：Anyscale 宣布完成 1 亿美元 C+轮融资，计划用于 Ray 与 vLLM 的集成及企业服务。
• 2024 年 3 月：vLLM v0.3.0 引入自动前缀缓存（prefix caching），使共享系统提示词的场景下吞吐再提升 2‑3 倍，进一步放大连续批处理收益。
• 2024 年 6 月：NVIDIA 推出 NIM（NVIDIA Inference Microservices），将 TensorRT‑LLM 的 in‑flight batching 封装为标准化微服务，一键部署。
• 2024 年 9 月：Google Cloud 在其 Vertex AI 中推出使用 TPU v5e 的 LLM 推理服务，官方博客确认采用了类似连续批处理的动态批处理策略。
• 2024 年 12 月：DeepSeek‑V3 推理系统公开部分技术细节，显示其通过细粒度调度实现了高吞吐，业界普遍认为吸收了连续批处理思想，但未确认具体实现。
• 2025 年 1 月：vLLM v0.6.2 发布，支持多模态模型（LLaVA）连续批处理，以及基于异步指令的 KV cache 卸载到 CPU 内存，缓解显存压力。

跟踪指标

若需跟踪 Continuous Batching 的技术演进与产业影响，建议持续关注以下指标（多数无官方定期报告，需从社区和财报中提取）：

• 主流框架 Star 数 / 下载量：vLLM、TensorRT‑LLM 的 GitHub star 和 Docker 拉取次数，反映开发者采用热情。
• 云 API 价格：OpenAI、Together AI、Fireworks 等每百万 token 的输入/输出价格变动，可间接反映推理成本下降曲线。参考 OpenAI 官方定价页面。
• 推理服务 SLA 参数：各框架公布的吞吐（tokens/s/GPU）和延迟（TPOT/TTFT）在标准测试（如 ShareGPT 数据集）下的数据，通常见于框架发布博客。
• 前沿论文：关注 MLSys、OSDI 等会议关于调度和 KV cache 管理的最新成果，例如 Sarathi、Orca、vAttention 等。
• 硬件规格：NVIDIA 新一代 GPU 的 HBM 容量和带宽（如 B200 192GB HBM3e），直接影响最大并发量。
• 专利与标准：检索 USPTO 和 CNIPA 中“continuous batching”或“in-flight batching”的专利申请变化，了解商业竞争布局。
• 安全事故：若出现跨租户 token 泄漏等安全事件，将对多租户推理部署产生重大影响，应纳入情报监控。

信源

以下为撰写本文引用的公开资料及推荐进一步阅读的文库（无外部超链接，可通过标题检索）：

• Kwon et al., “Efficient Memory Management for Large Language Model Serving with PagedAttention,” SOSP 2023.
• NVIDIA Developer Blog, “TensorRT-LLM: A Fast and Easy-to-Use Library for Large Language Model Inference,” 2023 年 10 月。
• Hugging Face Text Generation Inference 文档，https://huggingface.co/docs/text-generation-inference。
• vLLM 官方仓库与文档，https://github.com/vllm-project/vllm。
• Omdia, “AI Inference Server Market Tracker – 2024 Analysis,” 2024 年 3 月。
• NVIDIA FY2025 Q2 Earnings Call Transcript, August 2024.
• OpenAI API Pricing, https://openai.com/pricing , 截至 2025 年 1 月。
• Google Cloud Blog, “Serving large language models on TPU v5e with dynamic batching,” 2024 年 9 月。
• Anyscale 融资信息，Crunchbase，2023 年 12 月。
• Mercury Research, “GPU Market Share Report Q3 2024,” 2024 年 11 月。
• vLLM GitHub Issues 中关于高并发调度延迟的讨论。
• 各框架发布日志（vLLM v0.3.0、v0.6.2；TensorRT-LLM Release Notes）。