Continuous Batching（连续批处理）
Continuous Batching请求随到随批
亦作、亦称：连续批处理 · Iteration-level Batching
连续批处理（Continuous Batching）是大语言模型推理服务中的动态调度机制，允许服务器在每个解码迭代结束后随时插入新请求、释放已完成请求，从而消除静态批处理中因等待最长序列而造成的 GPU 空闲。该技术由首尔大学团队在 2022 年 OSDI 论文《Orca》中以「迭代级调度」（Iteration-level Scheduling）的形式正式提出，是 vLLM、TGI 等主流推理框架高吞吐的核心支撑。
概述
连续批处理（Continuous Batching）是大语言模型推理服务中的动态调度机制，允许服务器在每个解码迭代结束后随时插入新请求、释放已完成请求，从而消除静态批处理中因等待最长序列而造成的 GPU 空闲。该技术由首尔大学团队在 2022 年 OSDI 论文《Orca》中以「迭代级调度」（Iteration-level Scheduling）的形式正式提出，是 vLLM、TGI 等主流推理框架高吞吐的核心支撑。
静态批处理的痛点
传统静态批处理将一批请求打包后统一执行，直到批内所有序列全部完成才能接入下一批。
- GPU 空闲浪费：短序列提前完成后只能等待同批最长序列，算力长时间闲置
- 排队延迟高：新到请求必须等当前批次结束才能进入，首 token 延迟（TTFT）随并发量线性增长
- 吞吐瓶颈：批大小固定，无法自适应请求流量的动态变化
- 内存利用低：为对齐序列长度需要大量填充（padding），实际有效计算占比低
核心机制
连续批处理将调度粒度从「请求级」降至「迭代级」，每完成一次前向传播即重新调度。
- 迭代级调度：每次迭代结束，调度器检查哪些请求已生成终止符（EOS），立刻将其移出批次
- 即时插入：等待队列中的新请求在下一迭代开始前填入空出的槽位，无需等待整批完成
- 动态批大小：实际批大小随请求完成与到达动态伸缩，GPU 利用率始终保持高位
- 预填充与解码共存：新请求的 prefill（处理 prompt）可与在途请求的 decode（自回归生成）在同一迭代中并行执行
- 无需修改模型权重：调度逻辑完全在推理引擎层实现，对模型本身透明
发展脉络
连续批处理从学术原型到工业标准经历了快速演进。
- 2022：首尔大学 Yu 等人在 OSDI 提出《Orca》，以迭代级调度实现相较同期系统最高 36.9× 吞吐提升
- 2023：UC Berkeley《vLLM》将连续批处理与 PagedAttention 结合，大幅降低 KV Cache 碎片化，论文发表于 SOSP 2023
- 2023：HuggingFace TGI（Text Generation Inference）集成连续批处理，推广至更广泛工程场景
- 2024 至今：SGLang、LMDeploy、TensorRT-LLM 等框架在此基础上叠加 前缀缓存、推测解码 等优化，持续刷新推理吞吐记录
性能优势
与静态批处理相比，连续批处理在多项关键指标上带来显著改善。
- 吞吐量：Orca 论文报告最高 36.9× 提升；Anyscale 实测在相同延迟预算下吞吐提升约 23×
- 首 token 延迟（TTFT）：新请求可在毫秒级进入执行，而非等待当前批次结束
- GPU 利用率：消除填充空转，SM 占用率显著提升
- 长尾延迟改善：短请求不再被长请求拖累，P99 延迟分布更收敛
- 成本效益：相同硬件可服务更多并发用户，单 token 推理成本下降
工程挑战
连续批处理在工程实现层面仍面临若干复杂权衡。
- 内存管理：KV Cache 大小随批内序列长度动态变化，需精细的显存分配策略（vLLM 的 PagedAttention 专门解决此问题）
- prefill-decode 干扰：新请求的预填充阶段计算量大，与进行中的解码请求共享批次会增加解码延迟（chunked prefill 是常见缓解手段）
- 调度公平性：贪心插入策略可能导致长序列请求长期饥饿，需引入优先级或抢占机制
- 显存溢出处理：序列长度不可预测，需实现请求抢占（preemption）或换出（swap）以防显存耗尽
生态与应用
连续批处理已成为生产级 LLM 推理服务的事实标准组件。
- vLLM：最广泛采用的开源推理引擎，将连续批处理与 PagedAttention 深度融合
- SGLang：引入 RadixAttention 前缀缓存，在连续批处理基础上进一步提升共享前缀场景吞吐
- TensorRT-LLM：NVIDIA 官方推理库，将连续批处理（In-flight Batching）与 CUDA 内核深度优化结合
- HuggingFace TGI：面向生产环境的托管推理服务，内置连续批处理支持
- 云服务商 API：OpenAI、Anthropic、Google 等主流 API 服务均在后端采用类似机制保障高并发吞吐
常见误解
日常交流中容易听到的简化说法，未必准确，但能帮助理解误解从何而来。
- 「请求随到随批」
- 「不等凑满 batch」
- 「提高 GPU 利用率」
相关术语
和本术语关联紧密的其他词条，便于串联理解。
🎯 考点练习
含该术语的高频面试题，含标准答案与追问。
- 高级系统设计高频查看详解 →
如何设计支撑高并发的模型推理服务？
continuous batching + KV Cache + 量化 + 多副本自动扩缩 + 排队限流 + 多级缓存，围绕 TTFT/TPOT 这两个 SLO 优化。
- 中级场景查看详解 →
离线批量推理如何高效跑大规模请求？
离线批量推理以吞吐为先：大 batch、连续批处理、按长度排序减 padding、多副本并行。
- 中级概念查看详解 →
连续批处理（Continuous Batching）为什么能提升 LLM 服务吞吐？
以迭代为粒度调度：每步把完成的序列换出、新请求即时填入，消除静态批里等齐木桶效应造成的 GPU 空转。
- 高级系统设计查看详解 →
如何设计 Compute-Optimal 推理路由系统，在成本与质量间取得最优平衡？
按问题难度动态路由到轻量/标准/深度推理模型，结合 PRM 过程奖励模型做过思考检测、语义缓存命中复用、推理 token 预算控制，实现成本降 4 倍而质量不降。
延伸阅读
从知识库精选 3 篇文章，帮助深入理解该术语。
- 1
LLM 推理优化：量化、剪枝、蒸馏与推理加速实战
系统讲解大语言模型推理优化的四大核心技术——量化（Quantization）、剪枝（Pruning）、知识蒸馏（Knowledge Distillation）和推理引擎加速，覆盖从原理到实战的完整链路
- 2
LLM 推理加速（四）：新范式从 Speculative Decoding 到 DFlash
2026 年 4 月，z-lab 开源的 DFlash（Block Diffusion for Flash Speculative Decoding）一周内突破 2,000 星，将推测解码技术推向了新的高度。从 2023 年的 SpecInfer 到 2024 年的 Medusa、Eagle，再到 2025 年的 Lookahead Decoding 和 2026 年的 DFlash，LLM 推理加速经历了从「验证单 Token」到「预测 Token 块」再到「扩散式生成」的范式跃迁。本文深度解析推测解码的完整技术演进路线，对比 5 种主流方法的原理与性能，提供完整的 Python 实现代码，并给出生产部署的实战指南。
- 3
端侧 AI 技术路线：从 NPU 到 Agent 的完整指南
系统讲解端侧 AI（Edge AI）的完整技术体系——从为什么需要端侧 AI 出发，深入解析 NPU/APU/GPU 三大端侧 AI 处理器架构，对比联发科天玑、高通骁龙、苹果 A/M 系列芯片的 AI 能力差异，探讨端侧模型压缩技术（量化/剪枝/蒸馏/知识蒸馏），并展望端侧 Agent 时代的到来。本文是理解 AI 从云端走向设备端的技术必读。