SH

Soloharness

概念 · 辨析 · Agent

← 返回概念辨析

Concept Contrast Fable

模型服务和推理端点

很多人把推理端点当成模型服务的全部——能调通 API 就觉得部署搞定了。但推理端点只是那扇递单子的窗口,模型服务是窗口后面整座厨房:负载均衡、模型版本、弹性伸缩、监控告警,全在这里。把一扇窗当成整座厨房,高峰期一来就知道疼了。

寓言

厨房的后厨和传菜口

城南有一家智能厨房,门口只开了一扇传菜口。客人把订单从窗口递进去,过一阵子,菜从同一个窗口递出来。外面的人看不见厨房里面——不知道灶台有几口、备菜几个人、高峰期怎么调度。他们能摸到的,只有那扇传菜口。

传菜口后面是一整座厨房系统:食材入库要验货、菜谱版本要更新、灶台火候要按订单量动态分配、多台灶同时出菜要合流装盘。厨房师傅老赵管的就是这套系统,他每天盯着火候表、备料库存和出菜速度板。传菜口只管一件事:把收进来的订单递进去,把做好的菜递出去。

有一回一家连锁餐馆接入了这扇传菜口。头一个月订单少,传菜口反应很快。第二个月午餐高峰,窗口开始排队。连锁店的采购立刻打电话来质问:你们的接口是不是坏了?老赵派人去查,发现传菜口本身一秒都没卡——是厨房里面的一号灶台过热降频了,五口灶只有四口在工作。传菜口忠实地把每一单都递进去了,但厨房的调度器没有自动把负载挪到空闲灶台上。

连锁店的工程师说,我们理解不了你们内部,我们只测传菜口——传菜口没挂,我们就认为服务正常。老赵苦笑,把厨房监控面板截图发过去:看到没有,你的订单被收进去了,但锅不够。接口通着,不等于厨房转得动。

后来老赵在传菜口旁边装了一块小屏幕,实时显示厨房内部的灶台状态和当前等待数。接入方不用进厨房,也能看到服务好不好。老赵解释说:传菜口告诉你能不能点菜,屏幕告诉你菜什么时候能出来。一个是门,一个是门里面的流水线——各自有各自的指标。

年底厨房把账单拆清楚:传菜口的费用是固定月费,厨房内部的扩容按灶台数量和调度复杂度计费。连锁店终于不再为一锅慢菜投诉一扇无辜的窗——他们知道该投诉调度器还是传菜口,也愿意为调度升级单独加预算。

老赵对新来的工程师说了三句话:别把一扇窗当成整座厨房。别把能递进订单当成能出菜。别在传菜口挂了的时候才想起灶台可能早就跳闸了。

后来有竞争对手来参观,问老赵你们的秘诀是什么。老赵指了指墙上的架构图:我把厨房和传菜口画成了两个独立模块,厨房坏了传菜口还能告诉外面的人暂停接单,传菜口坏了厨房还能把菜从侧门递出去。分开了,反而都更稳了。

模型服务

模型部署与运维的完整系统,涵盖负载均衡、版本管理、弹性伸缩、健康检查、日志监控等能力,确保模型在生产环境中稳定可用。

推理端点

暴露给调用方的 API 入口地址,负责接收推理请求并返回结果,是模型服务对外可见的一扇窗口,本身不承载调度和运维能力。

故事对应

  • 传菜口(推理端点):API 入口,接单和出菜的唯一对外窗口
  • 厨房系统(模型服务):灶台调度、版本更新、弹性伸缩、监控的全套运维能力
  • 灶台过热降频:服务内部资源瓶颈,端点通着但后端无力处理
  • 小屏幕:可观测性面板,把内部状态透传给调用方
  • 分开计费:端点月费与内部扩容费分开,责任边界清晰

落到 Soloharness 项目里

客户问你推理端点是否稳定时,你要能分清他问的是 API 的连通性还是后端服务的承载能力。部署方案里把推理端点和模型服务拆成两行:端点负责接入和安全鉴权,模型服务负责扩缩容和版本灰度。端点通了不代表服务好,厨房空了端点还是绿的——这个认知差别会让你的 SLA 承诺多留一层安全垫。