SH

Soloharness

概念 · 辨析 · Agent

← 返回概念辨析

Concept Contrast Fable

在线推理和批量推理

一个要求毫秒级响应,用户等着看结果;一个可以排队跑几个小时,第二天再来收答案。选错推理模式,要么成本爆炸,要么客户等不起。

寓言

即时厨房和中央厨房

城中心开了一家餐厅,主打现点现做。客人坐下来点菜,厨房三分钟内出菜。主厨很骄傲,墙上贴着一张字条:我们只做即时出餐。

生意越来越好,开始有公司找来订团餐。第一次是一百份盒饭,中午十一点半要送到。主厨早上九点接到订单,心想:一百份,一份三分钟,三百分钟,五个小时。来不及。他拒绝了。

旁边的中央厨房听说了这件事,主动接过来。中央厨房凌晨四点开工,用大锅一次出五十份,两条流水线并行,八点全部装车,十一点准时送到公司食堂门口。老板来结账的时候发现,同样一道菜,中央厨房的单价只有即时厨房的三分之一。

主厨不服气,说中央厨房的东西不够新鲜。老板反问他:团餐需要的是十一点半准时到门口、每一份都一样、价格在企业餐标以内。新鲜感在这儿不是卖点,准点和一致性才是。

主厨回去想了想,把业务拆成了两条线。前厅还是三分钟出餐,接散客,菜单照旧,高峰期排号限流。后院的旧仓库改成了小批量加工间,专门接预定单——最少五十份起,提前十二小时下单,第二天统一装车配送。两条线工人共用,但出餐流程和排班表完全分开,前厅的炉灶不做团餐,加工间的大锅不上散台。

半年后,餐厅的营收翻了一倍。前厅利润率高,但翻台率有上限,每天最多接两百单。后院的加工间利润率低一些,但可以同时接十几个团餐单,走量,每天能出上千份。两条线用同一套菜谱、同一个采购渠道,区别只在出餐节奏和交付承诺。

主厨后来跟同行分享经验时说了一句:同一道菜,等的人不同,出菜的方式就该不同。

后来车行分了两条道:街口等客的马车随叫随走,夜里运粮的车队攒满再发。急活和批活终于不再抢路。 后来车行把急客价和夜运价分开写,谁要立刻走就付即时的钱,谁能等一晚就省批量的钱。

在线推理

请求一到就立刻处理,延迟在毫秒到秒级。适合聊天、搜索、实时推荐等需要即时反馈的场景,单次成本较高。

批量推理

把大量请求攒成一批统一处理,延迟在分钟到小时级,但单位成本大幅降低。适合离线标注、报告生成、数据清洗等对时效不敏感的任务。

故事对应

  • 前厅三分钟出餐:在线推理,低延迟、高单价。
  • 中央厨房大批量出餐:批量推理,高吞吐、低单价。
  • 一百份团餐订单:大批量任务,对延迟不敏感但对成本和一致性敏感。
  • 共用菜谱和采购渠道:同一模型可以同时支持在线和批量两种推理模式。

落到项目里

做架构设计时把请求分为两类:实时类走在线推理,报告类、分析类、批量处理类走批量推理。批量推理的单位 token 成本可能只有在线推理的 50% 甚至更低,但前提是你可以接受延迟。另外注意:批量推理的结果如果要在实时场景里用,需要额外加一个缓存层。