← 返回概念辨析

Concept Contrast Fable

推理引擎和 vLLM:一个定型,一个跑量

做模型部署时最容易把推理引擎和 vLLM 混为一谈。推理引擎是决定如何高效计算的软件框架,vLLM 是其中一个具体的开源实现。选型时没分清,结果可能是方案上写的引擎名字,买到的是与现有基础设施不兼容的运行时。

寓言

赛车设计局和量产工厂

城北设计局有一套发动机图纸,能把木料、铜管和火候算成马车动力。图纸精细,适合造样车;谁要使用它,就按图纸和师傅时辰付费。

后来订单暴涨,样车图纸仍好,却不适合日日量产。车间里工位拥挤,半成品排队,炉火忽大忽小。师傅们发现,决定产量的不只是图纸本身,还有工位怎样排、材料怎样等、空炉怎样补。

有个年轻管事把车间重排:相近零件合炉,等待的车架按长短穿插,常用工具放在手边,空出来的火口立刻接下一件。图纸没变,出车速度却上去了。

采购人一开始问‘买哪张图纸更聪明’,老管事摇头:图纸管能不能算出车该怎么跑,量产车间管同一时间能跑出多少辆、花多少柴、排队多久。

设计局的人起初不服:没有好图纸,工厂再会排队也造不出车。管事承认这一点,却指着院里堵住的车架说,图纸说明怎样造,工厂决定能不能连续、便宜、稳定地造。

后来采购人学会分开问。要判断车能不能跑,看设计图;要判断一天能交多少辆、旺季会不会堵、火口如何复用,就看量产工厂的调度本事。

量产工厂也不是万能。若设计图本身会炸炉,再会排工位也没用;若图纸可靠却车间混乱,订单照样堆成山。采购人把这两件事分开看,才知道该找设计师改图,还是找管事改车间。 后来设计局和工厂开始分工说话。设计局保证车能按原理跑,工厂保证许多车能连续交付。买家终于不再把样车能力和量产能力混成一笔账。

从此设计局分清两件事:一件是让机关能回答,一件是让回答在大量请求里高效流动。前者像发动机原理,后者像专门为吞吐而建的车间。

推理引擎

负责模型推理计算的软件框架,定义算子优化、内存管理和计算调度策略,是抽象的设计方案层。

vLLM

一个具体的开源推理引擎实现,基于 PagedAttention 等机制提供高性能 LLM 推理服务,是承载运行的实例。

故事对应

  • 设计局画发动机图纸:推理引擎,定义计算的抽象方案
  • 量产工厂每天下线几千台:vLLM,具体的生产级推理运行时
  • 采购单必须写明归属:项目立项时区分引擎选型和运行时选型
  • 方案授权和服务器租费绑死:引擎与基础设施耦合导致迁移成本

落到 Agent 项目里

技术选型文档里,把推理引擎方案和具体运行时实例分成两节来写。引擎方案回答“采用什么优化策略、支持哪些模型架构”,运行时实例回答“部署在什么硬件上、并发多少、延迟上限多少”。预算表里也别把这两行合在一起,否则换硬件或换引擎都会额外付账。