什么是连续批处理？动态插队的调度

大模型服务端有种调度办法叫连续批处理：一批请求还在生成中，新到的请求就能插进这批里一起算，算力席位不空等。它改的是传统批处理“凑齐一伙、干完一伙”的规矩，让 GPU 这种昂贵算力尽量不闲着，是提升吞吐的关键一招。

一批没完一批就来

传统批处理像坐大巴：凑够一车人才能发车，车上所有人都下车了，下一班才开门。连续批处理改成了地铁：每节车厢到站就上下客，不用等整车清空。具体到模型服务，就是每生成完一步，就检查有没有新请求可以加进来，随时补位。

这种调度对吞吐的改善很直接。席位不空等，意味着同样一块卡，单位时间能吞吐更多请求。代价是管理变复杂：每个请求写到哪一步、各自占多少上下文空间，都要单独记账，调度器得像列车调度员一样心里有本明细账。

像餐厅翻台不等齐

理解连续批处理，可以类比餐厅翻台。一桌客人吃到一半，旁边有空位，新来的客人先坐下点菜，不用等前桌全撤。厨房同时照看着处在不同进度的桌子：这桌快上齐了，那桌刚开火，互不耽误，翻台率就这么拉上去了。

翻台类比还解释了插队的公平性。新客人坐下，不影响老客人继续吃；服务端里，新请求插入，也不打断正在生成的请求。大家共享厨房的产能，只是把“等整桌人走齐”的浪费省掉了。

翻台类比的两处偏差

这个类比有两处对不上。其一，餐厅里每桌占用固定一张桌子，模型的每个请求占用的是上下文空间，有的请求刚开头占得少，有的写到一半占得多，席位大小是动态变化的。其二，餐厅厨房的产能可以按桌分摊，模型的算力在同一步计算里被所有请求共享，一个请求变长，会拖慢同批所有请求的那一步。

还有一处容易误解：连续批处理不是让单个请求变快，它提升的是系统整体吞吐。落到个人体感上，好处是高峰期等待更短，而不是某个回答突然写得更快——那是每秒 token 数的范畴；输出侧的攒批发送，则见流式输出的缓冲。

把餐厅类比和推理服务的实情逐项摊开，是这样。

插队对谁有好处

这套调度对三方都有利。服务方提高了硬件利用率，成本降下来；新来的请求不用苦等整批清空，等待时间短一截；已经开跑的请求也不被打断，节奏保持稳定。并发规模能往上抬，靠的正是这类调度改进。这套调度也解释了为什么小模型服务更便宜：单请求占用的上下文空间小，同样一块卡能塞进更多请求，吞吐上限自然高。用大模型换质量、用小模型换规模，是产品侧常见的分工，背后都是这笔席位账。

DeepSeek 在推理服务上做过不少工程优化，公开资料里提到过吞吐提升的思路；扣子这类智能体平台面向的是海量轻请求，同样依赖高效的批处理调度。带走一个判断：连续批处理解决的是“席位别空着”，它让系统更忙，未必让某个人更快，理解这一点，就不会在产品变慢时误判为故障，排查也有了方向，该看负载看负载，该看调度看调度。

速查表：连续批处理=生成中随时插新请求；类比餐厅翻台；失效在席位大小动态、同批共享单步算力；提升吞吐不提速单人；配合并发指标看。

换个问法再问连续批处理三句

• 新请求插入会让老请求变慢吗？理论上会分摊单步算力，实践中调度会权衡，通常影响远小于空等的浪费。
• 它和普通批处理差在哪？普通批处理等整批完成才开下一批，它每一步都检漏补缺，席位不空转。
• 为什么吞吐上去了体感不一定快？它优化的是系统总量，单请求节奏由解码速度决定，两件事。