SH

Soloharness

概念 · 辨析 · Agent

← 返回概念辨析

Concept Contrast Fable

来了就做和一攒够了再做

连续批处理在请求到达时动态组建批次、请求完成就释放槽位,目标是降低在线服务的等待延迟。批量推理收集一批请求后统一处理,目标是用更高的 GPU 利用率换吞吐量。两者都在批处理,但一个面对在线延迟,一个面对离线吞吐。

寓言

两家面馆,一家来客就煮,一家攒齐了再下锅

老城有两家面馆,隔着一条街。甲馆的大灶一次能下八碗面,但老宋的规矩是来一碗下一碗——灶上空了位就补新的,早来早下、吃好就走。乙馆的大灶也是一次八碗,但老田的规矩是凑满八碗再开灶——早来的客人等后面的,灶不开不煮。

赶时间的脚夫都去甲馆。一碗面下锅,翻个身的功夫就熟了端着走,灶上八格看上去永远是满的——旧碗翻走、新碗补上。脚夫们说这叫来得快走得快,灶不等人。乙馆那边,一个脚夫等了快两柱香,灶上还差三碗凑不够数,老田不急,说凑满八碗第一锅味道才正。

但是另一类客人在乙馆更划算。东家们办宴席,一次叫四十碗面。乙馆的大灶分五批,每批八碗一起下锅,灶火利用率高,老田一次能出一大桌。甲馆的单碗单煮,到第几碗时灶上始终有进有出,但四十碗面断断续续要等一个时辰——因为前一个人吃完后一个人才坐下,灶上好些格被慢吃的客人占着。

老宋和老田被叫到商会上辩论。老宋说我的灶任何时候都在出活,不存在灶空着等客人的情况。老田说我的灶每次开火用满,没有灶格被一碗面一直占着拖慢全局的问题。商会的人听出来了,两边都在批处理,但一个优先处理在线延迟——端上桌的速度,另一个优先处理离线吞吐——单位时间能出多少碗。

真正让两边分出胜负的是一桩混合订单。一个商队在两家分别下了单,要求脚夫的快食早点出、宴席的凉菜不能等太久。老宋的快食比老田快了整整两倍,但宴席端上桌的时间反而比老田慢——因为灶格被快食客人占着,宴席碗只能挤在剩余的格子里慢慢出。老田的宴席到齐后同时上桌,但有三个脚夫因为等凑满而饿到转了别家。

后来商会给出了分类建议。客人不需要同步等待、只追求一口灶一整天能出多少碗时,用老田的方式,凑够一锅下,把灶火利用率拉满。客人需要来了就吃、吃完就走时,用老宋的方式,来了就进槽,完成就释放。

两家面馆后来在菜单上加了一行说明:来客就煮叫连续批处理,凑满再煮叫批量推理。灶是一样的灶,开火方式决定了谁在等、等了多久。

连续批处理

在线服务中动态组建批次——请求到达时立即入槽,单个请求完成后槽位立刻释放给新请求。目标是最小化单个请求的等待延迟,适合实时场景。

批量推理

收集一批请求后统一处理,槽位填满后才开始推理,完成后整批返回。目标是最大化 GPU 利用率和吞吐量,适合离线批处理场景。

故事对应

  • 甲馆来一碗下一碗:连续批处理,请求到了就进槽、完了就释放
  • 乙馆凑满八碗再煮:批量推理,等批满了统一处理
  • 脚夫都去甲馆:连续批处理降低单个请求延迟
  • 宴席四十碗乙馆更快:批量推理在吞吐量场景下利用率更高
  • 混合订单两边各有输赢:场景决定批处理策略的优劣
  • 灶是一样的灶、开火方式不同:相同的硬件,不同的调度策略导致不同的性能特征

落到推理服务部署

在线推理服务(对话、代码补全、搜索推荐)默认用连续批处理——请求到达后立刻入槽,完成即释放,保证单个请求的延迟体验。离线推理任务(批量评测、数据标注、内容处理)用批量推理——凑满批次后统一处理,把 GPU 利用率拉满。如果有混合需求,建议在入口层做分流,不要用同一种模式同时服务两种场景。