← 返回概念解读

Concept Fable精修版

连续批处理

Continuous Batching · Inference optimization

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

面馆的锅不再等整桌人吃完才下新面

码头面馆有一口大锅。过去伙计凑齐十碗面才下一锅,煮好后一起捞出,再等下一批客人凑满。

客人少时这很整齐。后来有人只要一小碗,有人要加肉加蛋,有人吃得快,有人还在等汤。大锅经常半空,门口却排着长队。

掌柜先规定必须满十碗才开锅,又给迟到的客人发号牌。看似公平,实际让一碗快面也被慢面拖住。

有个伙计试着把所有客人的面强行同一时间捞出,结果有的夹生,有的糊掉。批量不是把不同进度抹平。

新厨师改了调度:锅里一直有面,哪碗熟了就捞出,空出来的位置立刻放下一位客人的面。每碗仍按自己的火候走,只是共享同一口锅。

他还把相近火候的面放在一起,给快出的单子留小格,给长煮的单子安排后位。锅不再等最慢的人,队伍也不再等整批结束。

很快,面馆发现单位时间出面更多,客人首口等待也更稳。最难的不是煮面,而是让不同长度、不同进度的订单在同一资源上流动。

掌柜明白,旧批处理适合整齐队伍,真实码头却永远参差不齐。持续把新请求塞进正在运行的批里,才能让昂贵的大锅不空转。后来面馆只看两个数:锅的利用率和客人的等待。能同时守住这两者的调度,才是真正适合高并发服务的调度。新伙计后来明白,锅里的面并非混成一团;每碗都有自己的入锅时刻、火候和出锅位置。真正的手艺,是让参差的订单共用热锅,却不互相拖垮。掌柜后来训练伙计看锅面,而不是只看队尾。哪里刚空出一格,哪里适合塞进短单,哪里会拖慢整锅,都要在几息之间判断。等夜市开张,客人来得更碎,这套安排才显出价值。

揭示

这个故事讲的是:连续批处理

连续批处理是在模型运行过程中,动态把多个请求的 token 放在一起调度。某些序列结束后,新请求可以进入仍在运行的 batch,而不用等整批请求全部结束。

这样能提高 GPU 利用率和吞吐量,尤其适合请求长度差异很大的 LLM 服务。但调度策略要控制单个请求的等待时间,否则整体吞吐变高,用户体验可能变差。

隐喻映射

  • 大锅:GPU batch execution
  • 十碗凑齐再下锅:静态批处理
  • 快面被慢面拖住:不同序列长度导致 head-of-line blocking
  • 空位立刻放新面:continuous batching
  • 每碗按自己的火候走:每个请求有独立 decode progress
  • 锅利用率:GPU utilization 和 tokens/sec
  • 客人等待:latency 与 TTFT
  • 最后洞察:Continuous Batching 让批次持续流动,用调度提升吞吐,而不是让请求被固定批次绑死

Soloharness 判断

这个概念的实战价值,是帮你把“看起来聪明的 AI 功能”拆成可交付、可验收、可治理的工作单元。

Dynamic batchingvLLMschedulerthroughputlatencyserving optimization

相关辨析

这个概念容易和相邻概念混用,建议继续看对比页。