← 返回概念辨析

Concept Contrast Fable

在线推理和批量推理

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

寓言

即时厨房和中央厨房

河边饭馆一边接散客,一边给书院做百人午饭。厨娘阿桂管着两摊看似相近的事:一摊是客人坐下就点、锅边立刻出菜,另一摊是清晨按名单备好一批饭盒。新伙计嫌麻烦,把两本册子合成一本,觉得反正都和成败有关。

最初没人反对。掌柜把两边都按“做饭”记账,临时客也等大锅,饭盒也一份份现炒,掌柜看见页数少了,还夸他们省事。可旺季一到,旧账忽然说不清:到底是前一摊没做完,还是后一摊没守住,谁也答不上来。

他们先补了更多章印和口号,要求每个人写得详细些。结果册子更厚,争执更多。出事时,每个人都能找到一句为自己开脱的话,却没人知道该先救哪一头。

老管事把众人叫到院里,让他们按真实经过重走一遍。凡是关心眼前动作的,放在第一本;凡是关心后续承担的,放在第二本。两本册子互相引用,却不再混成同一页。

午市时散客等得发火,书院那边又因分批太慢误了上课。分开之后,很多旧结论改了:有些活看着热闹,其实没有挡住麻烦;有些安排平时不起眼,灾时却保住了全局。

为了防止新人再混,老管事让他们各办一件小案。只有当两本册子分别能回答自己的问题,又能在交界处互相接上,这件小案才算过关。若有人仍把两摊事写成一页,就必须回到现场重新看一遍谁先动手、谁最后担责;看不清时,宁可多问一次,也不让糊涂账过夜;因为真正出事那天,少一行分辨就会多一队人白忙。

阿桂把前厅和后院分开:前厅小锅快炒,后院按清单集中洗切蒸煮;两边共用米面,却按不同节奏排活。后来新人入行,老管事只让他们记一句:有人等在桌前,就要立刻回应;一批名单早已确定,就该攒齐后一气完成。

在线推理

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

批量推理

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

故事对应

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

落到项目里

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