← 返回概念解读

Concept Fable精修版

推理引擎

Inference Engine · AI engineering / infrastructure

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

寓言故事

厨房换了总灶台,队伍才真正流动起来

渡口饭铺有一本好菜谱,师傅照着做,味道稳定。客人少时,一口锅、一把勺就能应付。

后来渡口开了夜船,客人一批批涌来。菜谱没有变差,饭铺却开始慢:有人等汤,有人等饭,有人只差最后一道配菜却被堵在灶口。

掌柜先责怪厨师手慢,又贴出更短的出餐口号。厨师跑得满头汗,锅却常空着等料,或者一口锅被一道大菜占住。某晚三十桌同时点菜,灶台彻底乱了。好菜谱救不了坏调度,热油、案板、锅位和上菜顺序互相卡住,客人只看见等待。

新来的总灶师不改菜谱,先改厨房。他把相似菜合并起锅,把半成品排队,把锅位、火候、盘子和传菜口统一调度。他还记住每桌已经备好的底料。下一道菜若能复用,就不再从头切配;需要快上的菜走小锅,需要吞吐的大席走大锅。

掌柜第一次看见,厨房效率由锅位、备菜、排队、复用底料和上菜节奏共同决定。后来饭铺换菜谱时,仍先问总灶台能否承受:流式上菜、长菜单、多人并发、低成本夜宵,走的不是同一种灶法。

掌柜请来灶台匠,重排炉口、备料台和传菜口。小菜走快锅,大菜走深锅,快好的汤不再被刚上炉的整羊挡住。

新灶台还会看队伍长短。夜船靠岸时先出能快速完成的饭,空锅立刻接下一单,缺料的菜被移到旁边等补。菜谱没有变,饭铺却顺了。真正让客人吃上饭的,是把请求、锅、火候和队伍调起来的那套灶台。

这次小事故让众人停下来复盘。他们没有急着换一套更响亮的说法,而是把出错的入口、被误解的规则和需要保留的边界逐一写清。掌柜明白,会做菜只是开始。真正把菜稳定端到许多客人面前,需要一套让炉灶、案板和传菜口高效运转的总灶台。

揭示

这个故事讲的是:推理引擎

推理引擎负责高效执行模型前向计算,并管理显存、KV cache、批处理、并发调度、流式输出和硬件加速。对企业 LLM / Agent 服务,推理引擎直接影响延迟、吞吐、成本和稳定性,常见相关系统包括 vLLM、TensorRT-LLM、TGI、llama.cpp、ONNX Runtime 和 Triton Inference Server。

它重要的地方在于:它不只是一个术语,而是在真实 AI / Agent 系统里会反复出现的结构性问题。理解它,才能判断什么时候该加模型,什么时候该改流程,什么时候该补治理。

隐喻映射

  • 菜谱:训练好的模型权重
  • 厨师:计算硬件和运行时执行能力
  • 灶台混乱:没有优化的 serving / inference 路径
  • 总灶台:Inference Engine
  • 合并起锅:batching / continuous batching
  • 记住底料:KV cache、prefix cache 或中间结果复用
  • 小锅和大锅:针对 latency 与 throughput 的不同调度策略
  • 最后洞察:推理引擎把模型能力转化为可承载业务请求的速度、吞吐和成本结构

Soloharness 判断

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

vLLMTensorRT-LLMllama.cppONNX RuntimeTriton Inference ServerKV cache

相关辨析

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