SH

Soloharness

概念 · 辨析 · Agent

← 返回概念辨析

Concept Contrast Fable

模型服务和推理引擎

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

寓言

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

还是城南那家厨房,但这次说的是灶台和总管的关系。灶台由老钱负责——他知道每口灶的火力上限、哪种火适合炖哪种菜、连续烧两小时后锅会多热。灶台就是模型跑起来的那个地方:火够不够旺、油热得快不快、一锅能同时做几份。老钱只管一件事:让灶台烧出厨师要的火候。

总管老周管的是调度——哪张单子先下锅、哪道菜上哪个灶、灶台不够了要不要租隔壁的临时灶房。他不管火候,但他管什么时候添柴、什么时候让灶台歇一歇。灶台和总管各司其职,但出了事谁也说不清是谁的锅。

一次连锁餐馆投诉菜的味道忽好忽坏。老周查了调度记录,每次订单都按时分配到灶台了。老钱查了灶台日志,每口灶的火力都是满的。两人对坐了半个小时,才发现问题出在中间:老周把一道慢炖菜误分到了快炒灶上,灶台火力开满了,但快炒灶的温区设计根本不适合慢炖。灶台没犯错,是总管分错了对象。

更麻烦的是老钱的灶台有个隐藏特性——连续工作两小时后散热效率下降。老周的调度器不知道这个特性,还在高峰期持续往同一口灶上压单子,灶台没报错,但火力其实已经掉了一半。总管不知道灶台的物理极限,灶台不会告诉总管自己快撑不住了。

他们决定做一个对接层:灶台把自己的当前温度、还能跑多久、最适合什么菜告诉调度器;调度器按这些信号分配订单。灶台不必理解菜单,老周不必拆开灶台研究电热丝——各管各的,但对齐了信号。灶台换了厂家,总管不用换脑子。

后来厨房扩建,老周从外面租了一批不同厂家造的灶台。有的快热、有的稳温、有的省柴但启动慢。老钱说这下调度难度大了。老周反而笑了:不难,每口灶把自己的曲线告诉我,我对号入座。只要灶台的信号接口一样,里面是什么构造跟我没关系。

新学徒上岗那天,老周带他看了一圈厨房,最后指着墙上一行字:灶台管火候,总管管排班;灶台不报温度,总管就瞎排。老钱在旁边补了一句:总管不知道灶台会累,等于让一口锅从早烧到晚不翻面。

后来有个大厨来面试,看了一眼厨房说:你们这不就是把火候和排班拆开了嘛,南边的大酒楼也是这么分的——灶房管火,前堂管单。老周没接话,指了指灶台旁边的温度牌:你记住的不是名字,是为什么温度牌和排班簿之间的那条线值整个厨房一年的食材损耗。

模型服务

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

推理引擎

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

故事对应

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

落到 Soloharness 项目里

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