← 返回概念辨析

Concept Contrast Fable

模型服务和推理引擎

模型服务和推理引擎在技术栈里挨得很近,但职责完全不同。推理引擎是灶台本身——负责把模型跑起来的计算内核;模型服务是厨房总管——负责调度哪张单子上哪个灶、什么时候添柴、灶台不够了租不租隔壁。把灶台和总管当成一个角色,要么灶台被管理拖累,要么总管被计算细节淹死。

寓言

同一个厨房,灶台和总管的职责

城南厨房分成灶房和前堂。老钱管灶房,知道每口灶的火力上限、适合炖还是炒、连续烧两小时后会多热。

老周管前堂调度,决定哪张单子先下、哪道菜上哪口灶、灶不够时是否借隔壁。他不拆灶,也不研究柴火,只管排班和交付。

一次连锁饭馆投诉味道忽好忽坏。老周查排班,每张单都按时送到灶边;老钱查火力,每口灶也都烧满。两人对坐半天,才发现慢炖菜被分到了快炒灶。

灶没有坏,排班却分错对象。更麻烦的是,有口灶连续工作后散热变差,老周不知道,还在高峰期往上压单,菜没有报错,却越来越生。

他们做了对接层。灶房把当前温度、还能撑多久、适合什么菜挂在牌上;前堂按这些信号分单。灶房不必理解整张菜单,前堂也不必拆开灶台。

后来厨房租来不同厂家造的灶,有的快热,有的稳温,有的省柴但启动慢。只要每口灶都把状态说清,前堂就能对号入座。厨房终于分清:一边负责把火烧好,一边负责把单派好,中间的信号线值一年的食材损耗。

学徒后来问,为什么不让老钱也排班,或让老周也管火。老钱说,灶房需要懂物理极限,前堂需要懂订单承诺,混在一起反而没人专心。

他们真正共享的是信号。温度牌、排班簿、异常铃和备用灶清单,让两个角色互相理解边界。厨房扩得越大,这条分界越值钱;分清之后,才知道该修灶还是该改排班。 后来新手入门时,老师傅不再先讲抽象名目,而是让他们复盘那次失误:原先哪里靠直觉,第一次修补为什么不够,新的安排怎样把风险留在能检查的位置。等他们能说清这些细节,还能指出什么时候该沿用、什么时候该升级,才算真正懂了这套办法。 后来他们还把这套办法交给新人演练:先让新人按旧办法做一遍,看错误怎样出现;再按新规矩重做,看哪一步被提前拦住,哪一步留下了证据。新人若只会背名字,仍会在相似场景里乱用;只有能说出适用边界、代价和失败后的补救,才被允许独立接活。

模型服务

管理模型在生产环境中的部署、调度、扩缩容和监控的系统层,负责把推理请求路由到合适的计算资源并保障服务可用性。

推理引擎

实际执行模型推理计算的软件内核,如 vLLM、TensorRT-LLM、TGI 等,负责张量运算、KV 缓存管理、批处理优化等底层计算任务。

故事对应

  • 灶台(推理引擎):执行模型计算的内核,管火候、批处理、内存
  • 总管(模型服务):调度和运维层,管排班、扩缩、健康检查
  • 慢炖菜分到快炒灶:调度器不理解引擎特性导致资源错配
  • 散热效率下降:引擎物理极限未被服务层感知
  • 对接层:引擎暴露温度/负载信号,服务层据此做调度决策

落到 Soloharness 项目里

选推理引擎时不要只看 benchmark 跑分,要看它能不能把运行时状态透传给模型服务层——GPU 利用率、批处理队列深度、KV 缓存压力,这些信号决定了调度器能不能在流量尖峰时做出正确决策。部署方案要写清楚:模型服务用的是哪种调度策略,推理引擎用的是哪个版本、暴露了哪些指标,两个组件之间的信号协议是什么。