大模型推理调度优化中的连续批处理技术

近两年大模型火出天际，围绕它的优化技术也层出不穷。这个系列会逐一拆解那些常见的大模型优化手段，从原理到落地，争取讲透。

• 大模型推理优化技术-KV Cache
• 大模型显存优化技术-PagedAttention
• 大模型优化技术-FlashAttention
• 大模型推理优化技术-Flash-Decoding
• 大模型显存优化技术-ZeRO系列
• 大模型解码优化-Speculative Decoding及其变体
• 大模型推理服务请求调度优化技术-Continuous batching

先交代一个核心背景：类GPT的模型推理分两个阶段——预填充和解码。解码阶段一次只吐一个token，吐出来的token会跟输入拼在一起再喂回去，不断重复直到碰到终止符。这种机制天然就带着大量冗余计算。好在Self Attention带了Mask，前面生成的token不需要跟后面的算Attention，所以前面算好的K和V完全可以缓存起来复用——KV Cache就是这样来的。说白了，这是一种用内存换计算、用空间换时间的优化，能显著降低推理延迟。

但要是跳出单模型视角，从系统层面看，还有更大的优化空间。本文要聊的Continuous batching，就是通过提高硬件利用率来提升系统吞吐量，堪称所有优秀LLM推理框架的标配技术。

批处理基本概念

单处理

单处理，就是每条提示（Prompt）单独送入模型，一个batch里永远只有一条数据。虽然简单灵活，但对GPU资源的利用率极低，毕竟每次只处理一个请求。

静态批处理（static batching）

静态批处理把多个Prompt打包成一个批次，等批次里所有Prompt都生成完毕后才一起返回。批处理的大小在推理完成前保持不变。

问题是，LLM推理是迭代的——同一个批次里，不同序列的生成长度差很远。有的Prompt早就生成完了，却要等最长的那个结束，GPU根本闲不住。

动态批处理（Dynamic batching）

动态批处理允许把多个推理请求动态组合成一个批次，目标是最大化吞吐量。拿Triton推理服务来说，它会把输入请求收集起来，没有延迟直接组批，不过用户也可以设置一个有限的延迟窗口，等更多请求来了再一起处理。

看个对比：如果不做动态批处理，所有请求顺序处理，假设每个请求耗时X ms，5个请求就要5X ms；用了动态批处理，打包后只需3X ms；如果再留一点延迟凑更多请求，可能2.5X ms就搞定。当然这是理想情况，实际并没那么完美并行，大批次执行时间会更长，但整体延迟和吞吐量改善还是肉眼可见的。

变长输入批处理（Ragged Batching）

Triton的动态批处理默认要求所有输入的形状相同。可真实场景里输入长度千差万别，客户端通常得填成一样长。Ragged batching则允许指定某些输入不需要形状检查，从而避免显式填充。

具体做法：在模型配置里把某个输入字段的allow_ragged_batch设为true。后端会把所有请求的输入连接成一维张量，同时额外提供一个批处理输入（比如INDEX）来描述每个请求的偏移量。这样客户端不用填充，后端也能分辨出哪些token属于哪个请求。这对LLM推理特别适用——TensorRT-LLM的kernel实现就考虑到了这种情况，而图像场景一般用不上。

连续批处理（Continuous Batching）

动态批处理和静态批处理都默认请求的输入输出形状一致，但自回归大模型里同一批次的输入输出长度五花八门，它们都不太灵。Continuous batching（也叫Inflight batching或Iteration batching）应运而生——请求到达时就组批，但不等批次所有序列都完事，而是一个输入提示生成结束后，立刻把新的提示插进来。因为每次迭代的batch大小是动态的，也有人叫它动态批处理，但为了避免概念混淆，本文统一叫Continuing Batching。可以说，这几乎是所有优秀LLM推理框架的标配。

静态/动态/连续批处理对比

• 静态批处理：客户端打包多个Prompt，等批次里所有序列完成才返回。
• 动态批处理：服务端内部动态打包多个请求。短响应或长度一致时接近最优，但参数不同时效果不佳。
• 连续批处理：请求到达就组批，但不在批次级别等全部完成，而是在迭代推理层级组合序列。吞吐量比静态批处理高10～20倍，是目前最先进的方法。

ORCA 原理

主流的Continuous batching实现都源自一篇论文：Orca: A Distributed Serving System for Transformer-Based Generative Models。后来vLLM把它推到大众视野，成了推理框架的标配功能。不同框架的差异主要体现在prefill的处理方式上——是把prefill单独拎出来，还是跟decoding融合？以什么粒度融？这些都值得琢磨。先看看ORCA是怎么做的。

现有系统按批次处理时，有的请求提前完成却没法及时返回，增加了延迟；新请求又得等当前批次全部跑完，排队时间也长了。ORCA的解决方案有两个：

• 迭代级调度（Iteration-level Scheduling）：以迭代为调度单位，而不是整个请求。每次迭代后，检测到完成的请求就立即返回token，新到达的请求在下一轮迭代就有机会被处理。调度器可以精确控制每次迭代要处理哪些请求、处理多少。
• 选择性批处理（Selective Batching）：批处理时只对部分操作（那些与不规则输入兼容的操作）应用批处理。所有非注意力操作（线性、层归一化、Add、GeLU等）不需要区分不同请求的张量元素，直接批量处理；而注意力操作则需要区分请求，在每个请求的token之间单独计算。ORCA在注意力的前后分别做了Split和Merge，这样既能发挥批量计算的优势，又不会因为长度不一而出错。

此外，ORCA作为一个分布式服务系统，还采用了模型并行策略（层内和层间并行）来支撑大模型。系统架构分为请求池、调度器和执行引擎三部分。

ORCA 与现有系统（FasterTransformer）流水线并行对比

ORCA的调度器让引擎中的Worker可以在多个批次之间流水线式执行——调度器不等待一个调度批次返回，只要当前批次数还小于Worker数就继续注入新批次。图8a展示了3个Worker上的流水线：一开始调度器选请求A和B组成批次AB，三个Worker依次处理；同时调度器可以继续注入批次CD和EF，等AB返回后立即调度下一轮。

相比之下，Triton+FasterTransformer那种组合因为受限于请求级调度，不允许在批次完成前注入新请求。为了在限制下启用流水线，FasterTransformer会把一个批次拆成多个微批次，然后在微批次之间流水化执行。但微批次太小，批处理收益就变小；微批次太大，流水线又容易产生气泡。ORCA由于迭代级调度，完全不用做这种取舍，可以轻松地在不拆分批次的情况下流水线处理请求。

Continuous batching 在 LLM 推理框架中的应用

如今Continuous batching已经渗透到主流推理框架中。下面逐个看看它在各框架里的落地情况。

vLLM 中的 Continuous Batching

vLLM通过LLMEngine引擎类接收请求并生成文本。每一次迭代级调度在step()方法里完成——整个prefill阶段算一次推理，decode阶段每生成一个token算一次推理。执行流程分三步：

1. 安排下次迭代要执行的序列，以及要换入换出的token块（序列可能被抢占或重新排序）。
2. 调用分布式执行器跑模型。
3. 处理模型输出：解码、更新序列组、释放已完成的序列组。

vLLM用三个双端队列维护所有请求：waiting（等待Prefill）、running（正在或即将推理）、swapped（暂时换到CPU内存的）。当有空闲KV Block时，把waiting中的请求移到running；当内存不够时，根据抢占策略——Swapping模式把被抢占序列的块换到CPU；Recomputation模式直接丢弃，恢复时重新计算。

和ORCA不同，vLLM在组批时prefill和decoding是分开的：一个step要么处理prefill要么处理decoding。这样实现更简单——prefill阶段用xformers处理计算密集的Attention，decode阶段用手写CUDA的PagedAttention处理访存密集的Attention。但缺点是prefill阶段会抢占decode阶段的step优先处理，导致decode都要等，输入prompt太长时延迟会更明显。

DeepSpeed-MII 中的 Dynamic SplitFuse

在TGI和vLLM里，生成阶段会被抢占来执行提示处理，然后再继续生成。Orca则不加区分，只要序列数没到上限就把提示加进去。这两种方法在长提示场景下都要暂停生成。DeepSpeed-MII提出了Dynamic SplitFuse，通过动态分解提示和生成来统一优化。

它的核心是两个动作：

1. 把长提示切分成小块，分散到多个前向传递中调度，只在最后一个前向传递时才生成。
2. 短提示组合起来精确填充目标token预算，必要时也分解。

效果很明显：

• 长提示不用再经历极长的前向传递，客户端延迟更低。
• 短提示融合到更大的token预算中，模型保持高吞吐。
• 前向传递大小一致，延迟更稳定，生成频率也更一致。

下图对比了Orca、vLLM和DeepSpeed-MII的批处理策略。vLLM在一个前向传递中要么生成要么处理提示；Orca在生成过程中以完整长度处理提示；DeepSpeed-FastGen则执行固定大小批次的动态组合，同时包含生成和处理提示。

vLLM 与 DeepSpeed-FastGen 性能基准

在NVIDIA A100-80GB上用LLaMA-7B测试：当工作负载以长提示短输出为主时，DeepSpeed-FastGen表现更好；其他场景下vLLM更优。

LMDeploy 中的 Persistent Batching

LMDeploy的TurboMind推理引擎实现了Persistent Batching（类似于Continuous batching）。它的结构包括LLaMA模型支持、persistent batch推理模式和可扩展的KV缓存管理器。

Persistent Batching需要请求队列和Persistent线程：

• 预先准备N个batch slots。
• 有空闲slot时，新请求加入batch；请求生成完毕后slot立即释放。
• 命中缓存时，历史token不必每轮解码，生成即刻开始。
• batch自动扩缩容避免无用计算。

结合KV Cache管理器的LRU淘汰机制，当缓存池满时踢除最近最少使用的sequence，把slot分给新请求。被踢的sequence转换成token IDs，等后续命中时再重新解码。对用户来说，就像系统有无限设备内存一样。

TensorRT-LLM 中的 in-flight batching

TensorRT-LLM通过批处理管理器（Batch Manager）支持In-flight Batching。这个组件允许在每次迭代中把新到达的请求塞进来，同时把已完成的请求返回出去。用户需要注册函数指针来定义如何读取新请求、如何返回已完成的请求。

LightLLM 中的 Continues Batching

LightLLM是一个纯Python的推理框架，同样实现了Continues Batching。Prefill和Decode可以在同一个step里处理。它还改进了PagedAttention，推出了TokenAttention——在token级别管理KV缓存，减少内存碎片，实现高效内存共享。框架也引入了SplitFuse特性。

总结

本文先梳理了批处理的基本概念，从单处理、静态批处理到动态批处理、变长输入批处理，最后引出连续批处理。然后重点剖析了Continuous batching的原理（以ORCA为例），以及它在vLLM、DeepSpeed-MII、LMDeploy、TensorRT-LLM、LightLLM等主流框架中的实现差异。可以说，Continuous batching是提升大模型推理吞吐量的杀手级技术，值得每一位做模型服务和系统优化的人深入理解。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：大模型推理调度优化中的连续批处理技术要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题