连续批处理Continuous Batching：大模型推理调度优化-北京尧图网络

大模型推理服务的吞吐量上不去绝大多数时候不是模型本身的问题而是调度策略把它拖住了。我见过不少团队在单卡上跑一个7B模型显存明明还剩一大截QPS却死死卡在个位数调大batch size也没用——因为请求是一个一个来、一个一个走的GPU大部分时间在等。这就是Continuous Batching要解决的问题。这篇内容围绕Continuous Batching连续批处理展开讲清楚它为什么能把推理吞吐量拉高几倍甚至十几倍、底层调度的核心逻辑是什么、自己动手实现时哪些细节最容易被忽略、以及上线后哪些指标才是真正该盯的。无论你是刚接触推理优化、只听说过vLLM这类框架名字的新手还是已经在做推理服务、想搞明白调度器内部怎么转的工程师都能从下面这些拆解里拿到可以直接复现的东西。全文以一个请求在调度器里到底经历了什么为主线把原理、实现、踩坑和调优串起来讲。1. 先搞清楚静态批处理为什么注定浪费算力要理解Continuous Batching的价值得先看清它要取代的东西有多低效。很多人第一次做推理服务用的都是最直觉的方式攒一批请求凑够N条一起送进模型等这一批全部生成完再收下一批。这个做法在教科书里叫静态批处理Static Batching在早期推理框架里非常普遍。1.1 一个被最短请求拖死的批次静态批处理最大的结构性缺陷在于一个batch的完成时间由batch里最长的那个请求决定。假设一批里同时进来了四条请求输出长度分别是20、50、200、800个token。GPU必须等到那条800 token的请求吐完最后一个token整批才算结束才能释放资源接收新请求。前面三条早就在几十、几百步之前就结束了但它们占用的显存槽位一直空转不能还给调度器。这个浪费有多严重算一笔账就明白了。假设单步解码也就是生成一个token耗时固定为10毫秒那么请求输出长度实际需要时间被强制占用时间空转占比A20 token200 ms8000 ms97.5%B50 token500 ms8000 ms93.75%C200 token2000 ms8000 ms75%D800 token8000 ms8000 ms0%四条请求GPU真正干活的时间只有2005002000800010700毫秒的等价工作量但总占用时长是4×800032000毫秒。也就是说算力利用率不到34%。如果batch更大、长度分布更离散这个数字还会继续往下掉。真实业务里的输出长度分布恰恰非常离散——有人问一句今天几号输出5个token有人让模型写一篇长文输出两三千token。把这两类请求塞进同一个静态batch短的必然陪跑。1.2 显存槽位和计算槽位是两回事理解这个问题还需要区分两个概念很多资料混着讲容易把人绕晕。显存槽位KV Cache slot每个请求在prefill阶段要为所有输入token算好Key和Value并缓存起来解码阶段每生成一个token还要往缓存里追加一份。这部分显存是按槽位预分配的一个请求占一个槽位请求不结束槽位不释放。计算槽位compute slotGPU的并行计算单元在每个解码步能同时处理多少条序列取决于batch size和显存带宽。静态批处理的问题在于它把这两个槽位强行绑死了一个请求结束前既占着显存槽位又占着计算槽位。可实际上请求A在第20步就没事干了它完全可以把计算槽位让出来给别人用只保留自己已经生成的KV Cache虽然它其实也不需要保留了。Continuous Batching的核心洞察就在这里——把是否还在计算和是否还占着显存解耦让每个解码步都能重新决定谁能上GPU。1.3 请求到达的泊松特性放大了浪费还有一个常被忽视的维度请求到达不是均匀的。真实线上流量往往呈现明显的突发性早高峰和低谷的QPS能差一个数量级。静态批处理在这种场景下会陷入两难批次攒小了GPU喂不饱批次攒大了排队延迟爆炸而且用户等半天等来的还是一个被长请求拖住的批次。我在一个模拟项目里做过压测同一批流量走静态批处理P99延迟是同吞吐下Continuous Batching的3到4倍原因就是尾部请求总是被前面的批次卡住。所以静态批处理不只是吞吐低它的延迟分布也更难看只是很多人只盯着平均值没发现。2. Continuous Batching的调度内核到底在做什么抛开各种框架的实现差异Continuous Batching的调度逻辑可以浓缩成一句话每一个解码步decode step都是一次全新的组批机会。这就是它名字里continuous的含义——批次不是固定的而是连续流动的。2.1 从迭代级调度看请求的完整生命周期我把一个请求在调度器里的路径拆成五个阶段按这个顺序走一遍比看任何架构图都清楚入队Enqueue请求到达后被放进waiting队列携带自身的输入token、采样参数、目标输出长度上限等元信息。预填充Prefill调度器在某个解码步决定接纳它把它和同批的其他新请求一起做一次前向算出全部输入token的KV Cache并写入显存池。这一步是计算密集型的token数量大耗时明显高于后续单步解码。解码Decode进入running队列每个解码步只输入上一个生成的token输出下一个token同时把新的KV追加进缓存。逐出Preempt如果显存池不够了调度器会把某些请求踢回waiting队列释放其KV空间等有空间了再重新prefill。这一步是Continuous Batching实现里最容易被写得很难看的部分后面单独讲。完成Finish命中EOS结束符或达到最大长度释放槽位把结果返回。关键在于第2、3、4步之间没有批次边界这个概念。每一步开始前调度器都重新扫一遍running队列和waiting队列算一笔账现有running请求的KV占用多少、还剩多少显存块、能塞进几个新请求、塞进来的prefill开销会不会把这一步的延迟拉爆。算完再决定这一步跑谁。2.2 KV Cache分页让槽位可以像内存一样碎片化利用如果KV Cache还是按每个请求预分配最大长度的连续显存来管Continuous Batching根本跑不起来——因为没人知道一个请求最终会生成多长按最大值预分配等于提前把显存锁死动态调度也就失去了意义。真正的解法借鉴了操作系统的虚拟内存分页思想业界一般叫PagedAttention。核心做法是把KV Cache切成固定大小的块block比如每个block装16个token的KV。一个请求的KV不再需要连续存放而是维护一张逻辑块到物理块的映射表物理块从全局块池里按需分配。这个设计带来三个直接好处按需增长请求生成到第17个token时才去申请第二个block显存占用跟着实际长度走不再有预分配浪费。业界实测这种做法的显存浪费率能从60%以上压到4%以下。块可复用系统提示词这类多个请求共享的前缀其KV块可以被多个请求的映射表同时指向只存一份。对于带长系统提示的场景这一项能省下相当可观的显存和prefill计算。碎片可控块大小固定物理块池的分配和回收就是简单的位图或空闲链表操作不会出现有空间但凑不出连续大块的经典碎片问题。提示block size不是越大越好。块太大一个短请求也要占满一整块尾部浪费明显块太小映射表变长调度器每次要遍历的条目变多CPU侧开销上升。常见的取值在8到32之间需要按你的平均输出长度和并发量实测对比。2.3 Chunked Prefill把长输入的大计算拆开摊平纯Continuous Batching还有个隐患prefill是要么全做要么不做的。一个两万token的长输入请求被接纳时它的一次prefill就要吃掉大量算力导致同一步里其他正在解码的请求全部被拖慢P99延迟出现尖刺。用户体感就是我聊得好好的突然卡了一下。Chunked Prefill分块预填充就是补这个洞的。它把一个长prefill按token数切成若干chunk每个解码步只处理一个chunk剩下的留到后续步骤继续。这样每个解码步的总计算量更平稳解码请求不会被长输入突然挤占。代价是长请求自己的首token延迟TTFT会变长因为它的prefill被摊到了多步。所以这里有个明确的调参取舍你要的是TTFT低还是ITL相邻token间隔稳。线上一般配置一个单步token预算上限比如每步最多处理2048个token新请求的prefill按剩余预算切块进入超出的部分顺延。这个预算值直接决定了延迟曲线的形状值得花时间压测。2.4 调度器每一步要做的三个决策抽象一下调度器每个step其实就在做三件事把这三件事的判定顺序理清楚自己写调度器就不会乱决策判定依据常见策略这一步要不要跑新请求的prefill剩余token预算、显存块余量、waiting队列是否非空优先保解码预算有余再插prefill这一步要不要逐出running请求显存块池是否耗尽、是否存在可回收空间逐出KV占用最大或最久未推进的每步实际batch大小上述两者的结果、硬件并行度上限动态不设死上限靠预算约束这三件事的判定顺序很关键。我的做法是先算显存能不能容纳现有running集合再算token预算够不够插prefill最后才决定逐出。顺序反了会出现刚逐出一个请求下一步发现其实不用逐出的抖动白白多了一次重新prefill的开销。3. 自己动手搭一个能跑的最小调度器知道原理和写出来能跑中间隔着一堆具体问题。这一节按从零到能压测的路径走给出可落地的结构设计和关键代码片段。语言用Python描述逻辑实际生产环境的调度器多用C或Rust写以压低CPU开销但逻辑是同一套。3.1 数据结构设计三个队列加一个块池先把核心数据结构定下来这是整个实现的地基。from dataclasses import dataclass, field from typing import List, Optional dataclass class Sequence: seq_id: int prompt_ids: List[int] output_ids: List[int] field(default_factorylist) # 逻辑块 - 物理块的映射 block_table: List[int] field(default_factorylist) # prefill 是否完成 prefilled: bool False # 本轮 prefill 已处理到第几个 token prefill_cursor: int 0 max_new_tokens: int 256 finished: bool False class BlockPool: def __init__(self, num_blocks: int, block_size: int 16): self.block_size block_size self.free_blocks list(range(num_blocks)) self.used set() def allocate(self, n: int) - Optional[List[int]]: if len(self.free_blocks) n: return None got self.free_blocks[:n] self.free_blocks self.free_blocks[n:] self.used.update(got) return got def release(self, blocks: List[int]): for b in blocks: if b in self.used: self.used.remove(b) self.free_blocks.append(b)三个队列分别是waiting待prefill、running解码中、finished已完成待回收。请求进入waiting后只有在调度器判定显存够 token预算够时才会被搬进running。这里我特意把prefill_cursor放进Sequence里是为了支持前面说的chunked prefill——它不是一次性把prompt喂完而是记住进度分步推进。有个细节值得强调block_table必须是逻辑到物理的映射而不是物理块编号的列表。因为你后面要支持前缀共享多个Sequence的block_table里会指向同一个物理块回收时靠引用计数判断能不能真正释放。如果偷懒直接存物理块列表共享和回收都会出错。3.2 单步调度循环的骨架写法调度主循环是这套东西的心脏写清楚它的顺序比堆功能重要得多。def schedule_step(running, waiting, block_pool, token_budget): # 第一步先看 running 集合能不能装下装不下就逐出 need sum(estimate_new_blocks(seq) for seq in running) while need len(block_pool.free_blocks): victim pick_victim(running) # 选一个逐出 release_seq(victim, block_pool) running.remove(victim) waiting.insert(0, victim) # 放回队首优先重入 need sum(estimate_new_blocks(s) for s in running) # 第二步在剩余预算内插入新的 prefill budget_left token_budget prefill_batch [] while waiting and budget_left 0: seq waiting[0] chunks min(len(seq.prompt_ids) - seq.prefill_cursor, budget_left) blocks_needed blocks_for_tokens(seq.prefill_cursor chunks, block_pool.block_size) if block_pool.allocate(blocks_needed - len(seq.block_table)) is None: break # 显存不够这一步不插了 seq.prefill_cursor chunks budget_left - chunks if seq.prefill_cursor len(seq.prompt_ids): seq.prefilled True running.append(waiting.pop(0)) prefill_batch.append(seq) decode_batch [s for s in running if s.prefilled] return prefill_batch, decode_batch这段骨架里有三个地方最容易写错逐个说。第一处是逐出的选择策略。pick_victim选谁很有讲究。选错会导致频繁重入、反复prefill。我一般的策略是优先逐出KV块占用最多的请求腾出的空间最大但如果所有请求的占用都差不多就选最近刚被逐出过的避免同一个请求来回被踢。更稳的做法是给每个请求记一个已等待步数的优先级逐出时选等待最久的、或者按LIFO逐出后进先出因为后进的请求往往输出还没开始重算代价小。第二处是逐出后的重入位置。看代码里waiting.insert(0, victim)放队首不是随手写的。被逐出的请求已经浪费了一次prefill如果还排到队尾重新等用户感知的延迟会非常难看。放队首让它尽快重入虽然会牺牲一点公平性但对P99延迟的改善非常明显。第三处是分配失败时的处理。代码里显存不够就break这一步不再插新请求。但这里要小心一个陷阱如果waiting头部那个请求特别长一直分配不到足够的块它会永久堵住队首后面的短请求全被饿死。这是个经典的队头阻塞问题解决方式是允许跳过队首、尝试队列中其他能装下的请求或者对超长请求做长度上限校验后拒掉。3.3 逐出与重入的账它到底有多贵很多人讨论Continuous Batching时把逐出当成免费的实际上它有明确代价算清楚才能定策略。被逐出一个请求意味着它已经生成的KV全部作废重新进来时要从头prefill整个prompt加上已经生成的输出。假设一个请求prefill了1000个token生成到第300个token时被逐出那么重入时prefill的量变成1300个token。按前面10ms/token的粗算这一下就多花十几秒的等价算力实际prefill是并行的耗时会小很多但token量级的浪费是实打实的。更麻烦的是抖动。逐出频繁发生时系统会出现周期性的吞吐塌陷逐出N个—重新prefill—再逐出N个。我在一个模拟项目里测过当显存余量低于总量的15%时逐出频率呈指数上升吞吐反而比不加逐出策略还低。围绕这个实际调参有三条经验一是留足余量别把块池吃到满留20%到25%的空闲块作为缓冲二是尽量用前缀共享降低重算量系统提示词那部分被缓存住了重入时这部分KV可以直接复用不用重算三是给逐出降温连续若干步都在逐出就说明显存是真的不够此时应该考虑降低并发上限或者把请求排到别的实例而不是硬撑。3.4 采样与分词这些外围环节的坑调度器跑通之后问题往往出在调度器外面。我在模拟项目X里遇到的几个坑都跟外围环节有关。采样的随机性来源要统一。Continuous Batching要求一批里的每个序列用各自的采样参数temperature、top_p、seed但很多框架的采样kernel是按整批一个参数写的。如果你直接把它用在异构批次上会出现这批请求全部按第一个请求的参数采样的诡异现象而日志上看不出报错。排查方式就是固定一个seed构造两条需求明显不同的请求看输出分布是否一致。分词器的批处理路径和调度器的批处理路径要对齐。分词通常在主进程做调度在推理进程做两边对一条请求的边界理解必须一致尤其是遇到超长prompt被截断时截断点要明确在分词侧还是调度侧。我踩过一次因为截断在两侧重复发生导致模型生成的回答开头总是莫名其妙地重复半句话。流式输出和批次完成不同步。用户那边是streaming的一个token一个token往外推调度器这边是批次整体前向一次返回一批token。要保证每个请求的token按序、及时推给对应的流式连接中间的缓冲队列设计不能偷懒否则会出现早完成的请求最后才吐出来的错乱。4. 上线前必须压的几组指标与调参手感代码能跑不代表能用。这一节讲我在压测阶段的观察顺序以及那些文档里不写、但不调就出事的参数。4.1 别只看吞吐四个指标要一起看推理服务的质量不是一个QPS能概括的。我压测时固定看这四个缺一个就会判断错。指标含义关注点TTFT首token延迟从请求到达到吐出第一个token受prefill排队、chunked prefill的块大小影响最大ITL / TPOT相邻token间隔受单步batch大小、逐出抖动影响最大是用户卡不卡的直接体感吞吐 tokens/s单位时间生成的token总数综合指标要和上面两个一起看单看会骗人有效并发同时在跑的请求数用来判断显存余量和并发上限的合理区间这四者的关系是相互拉扯的。batch size调大吞吐上去但ITL变差chunked prefill的块调大TTFT改善但ITL变差块池余量留多抖动少、ITL稳但吞吐上不去。所以不存在最优参数只有针对你的SLA的最优参数。我的做法是先给TTFT和ITL定一个硬上限比如TTFT不超过800ms、ITL不超过100ms然后在这两个约束下把吞吐往死里调。4.2 长度分布决定你的参数该往哪调一个反直觉的结论平均输出长度对你的调参几乎没指导意义P95和P99的长度才有。因为决定批次完成时间和显存峰值的是尾部请求。我压测时会把实际的输出长度分布画出来重点看P99。如果P99长度是平均值的10倍以上说明你的流量里有长尾请求那么块池余量要给得更足、逐出策略要更保守宁可排队也别逐出、chunked prefill的预算要给得稍微宽一点让长请求尽快过去。如果分布很集中就可以把余量压紧、追求更高吞吐。还有一个实操建议对超长输出设置硬上限。不加限制的话个别请求生成几千token会长时间占着槽位把整个池子拖慢。设max_new_tokens上限并配合提前截断是成本最低的稳定性保障。截断时返回一个明确的结束原因让调用方能处理。4.3 逐出阈值没设计好会触发雪崩前面提过逐出抖动这里把现象和处置讲透。现象是吞吐曲线原本平稳加载到某个并发后突然掉到原来的六成同时ITL的P99飙高日志里逐出计数暴涨。此时如果你继续加压情况不会更糟但也不会好转系统卡在一个低效的平衡态。根因是块池余量低于缓冲线后每个step都在逐出—释放—分配—再逐出之间循环真正用于计算的block占比下降等效batch变小吞吐自然掉。处置顺序我一般这样走第一步先看逐出率逐出次数/总请求数超过5%就说明余量不够把空闲块缓冲从15%提到25%试试第二步确认是否有个别超长请求长期占位如果是给它加长度上限或优先级降级第三步如果还不行说明并发上限设高了该在入口层做限流而不是让调度器硬扛。注意不要把逐出次数多直接等同于显存不够也有可能是你的block size设得太小导致块数虚高或者是前缀共享没生效。先排除这两个再动显存配置。4.4 前缀共享的收益要用真实流量验证前缀共享听起来很美但收益高度依赖流量特征。带统一系统提示的场景比如所有请求前面都挂一段一千多token的角色设定收益非常显著能省下大比例的prefill计算和显存。但如果每条请求的prompt都完全独立前缀共享几乎是零收益反而增加了映射表管理的开销。验证方法很简单统计真实流量里前N个token的重复率。做法是把最近的请求prompt按前缀截断到比如128token做一次频次统计看最高频的那段前缀覆盖了多少比例的请求。覆盖率超过50%就值得开前缀共享而且要把这段前缀放在显存里长期驻留别被回收掉。5. 几个绕不开的实现难点与我的处理办法这一节是把前面分散提到的坑集中讲清楚都是我在模拟项目里真实撞过、并且找到稳定解法的。5.1 prefill和decode混批时的数值一致性一个批次里同时有prefill的请求和decode的请求是Continuous Batching的常态也是很多实现翻车的地方。原因是这两类请求的计算模式不同prefill是矩阵乘吃的是大块tokendecode是逐token生成每个序列只有一个token。强行拼成一个batch需要构造特殊的attention mask通常叫打包序列或用变长的cu_seqlens让每个序列只能看到自己的部分。这里的坑在于mask写错不会报错只会让结果变差。你可能会发现输出还是通顺的但质量微妙地不对比如重复、跑题。排查方式是构造一个极端case把一条100token的请求和一条5token的请求混在一批然后分别单批跑一遍对比两者的输出logits。如果对不上就是mask的问题。这个对比测试我建议固化成回归用例每次改调度逻辑都跑一遍。5.2 优先级与公平性别让短请求饿死线上流量通常混杂着不同优先级的请求而且用户对简单问题的响应期待更高。纯FCFS 优先逐出长请求的策略容易让长请求一直排队。反过来如果为了照顾长请求而放松余量短请求又开始排队。我的处理是按输出长度做预估分级但并不真的预测长度预测不准反而添乱而是用一个静态的段位prompt短的、且max_new_tokens设得小的请求进快车道其余进普通道。快车道有独立的token预算配额比如每步预留30%的预算给快车道保证这类请求的TTFT有下限保障。这个改动实现起来不复杂但对体感延迟的改善立竿见影。提示快车道的配额不能给太高否则普通请求的prefill一直排不上又会引发另一头的饥饿。经验值是20%到35%之间。5.3 多卡并行下的调度边界单卡调好了上多卡张量并行之后调度会变复杂。核心区别在于prefill的chunk切分要在所有卡上保持同步——不能这张卡切2048、那张卡切1024那样每步的通信量和计算量都对不齐反而更慢。另外一个容易被忽略的点是逐出的粒度。在多卡设置下一个请求的KV是分布在多张卡上的逐出必须全卡同步释放否则会出现这张卡上已经释放了、那张卡还占着的状态不一致。实现时要在调度器里维护一个全局的逐出决策然后广播给各卡的执行端而不是各卡自己判断。我在模拟的跨平台系统里就吃过这个亏单卡跑得好好的调度逻辑铺到四卡上之后隔一段时间就会出现一次明显的卡顿排查下来是某张卡的块池先耗尽触发了局部逐出其他卡跟着等。改成全局统一决策后卡顿消失。5.4 调度器本身的开销不能无视调度逻辑跑在CPU上每步都要扫队列、算块数、维护映射表。当batch很大、步频很高比如每步10ms甚至更短时调度开销占比会上升甚至成为瓶颈。极端情况下GPU那边等CPU算调度利用率掉下来。控制手段有几个一是控制块表的规模block size别设太小二是队列扫描做增量化别每步全量遍历维护一个可调度的候选集合三是把调度器写成编译型语言Python虽然好写但在高频路径上确实吃亏。我在一个Demo里做过对比同样的逻辑从Python移到C后高频小batch场景下的吞吐提升接近两成主要就是省下来的调度开销。6. 落地时的取舍清单最后把这一路下来我认为最值得记住的几个判断列出来都是需要你自己在真实流量上验证的。batch size不要设成固定值。Continuous Batching的整个思路就是让批次动态变化如果你非要加一个硬上限就把它设成一个绝不会成为瓶颈的值。真正的约束应该是token预算和显存余量而不是一个拍脑袋的数字。显存余量比峰值吞吐更重要。留20%到25%的空闲块看着像是浪费实际是在买稳定性。余量不足带来的逐出抖动会让你损失远超这部分余量能带来的吞吐。chunked prefill的预算和你的SLA强绑定。TTFT和ITL是一对矛盾预算大小就是在两者之间挪移。先定SLA再倒推预算别反过来。长度上限不是限制是保护。对输出长度设死上限配合明确的截断返回能避免个别请求把整个池子拖进低效状态。这是成本最低的一项稳定性措施。回归用例要覆盖混批场景。prefill和decode混批、逐出重入、前缀共享命中这三个场景的数值一致性都要固化下来定期跑。出了问题这几个用例能在几分钟内帮你定位到是不是调度逻辑改坏了。我在实际项目里最大的体会是Continuous Batching的框架选型其实不难难的是把自己流量特征摸清楚然后耐心地把那几个参数压到合适的位置。同一套代码参数调对了和调错了吞吐能差两三倍而且差的那版看起来一切正常就是慢。压测阶段多看延迟分位数、少看平均值能少走很多弯路。

连续批处理Continuous Batching：大模型推理调度优化

相关推荐

OkHttp极简封装：Kotlin扩展与请求归一化实战

独立开发者如何打造年入18万美金的设计工具

Oracle学生考勤系统课程设计：12张表DDL避坑与数据库端实现

更多资讯

揭秘电商智能系统：从选品到私域的全链路优化

MoE混合专家模型：稀疏激活、路由机制与推理部署优化全解析

AI Agent专用数据库MemoryDB架构与实战

云端计算在气象干旱监测中的应用与SPI分析实践

Zcode OSS上传风波复盘：从抓包误读到harness诊断机制的技术真相

curl命令分层实战：接口调试、耗时打点与自动化脚本

今日更新

AI辅助技术栈评估：提升研发决策效率60%

从生成Token到直接决策：Jev如何重塑AI Agent工程实践

32G统一内存跑大模型：内存账、TPS实测与端云分流

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？