模型服务

它是什么

模型服务是把模型变成一个能长期被调用的东西，并持续维持它的四件事：并发（同时多少请求）、延迟（单次多久）、版本（换模型怎么换）、容量与成本（贵不贵、撑不撑得住）。[S1]

它和「部署」的差别是时间尺度上的：部署是一个动作，做完了事；服务是一个持续状态，每天都要维护。把模型服务当成一次性部署任务，是这类项目最常见的起点错误——上线那一刻系统是好的，问题是它还需要在第一百天也是好的。

为什么需要它

因为调用模型的成本结构和使用方式，与调用传统接口很不一样：

• 延迟不是常数。 同一模型在不同长度输入、不同并发下的响应时间差别很大，而且流式输出让「首字延迟」和「整体完成时间」成了两个不同指标。
• 成本随用量线性涨、且随输入长度涨得更快。 输入与输出分别计价，上下文越长单次越贵——这直接决定了上下文工程要省着用，也决定了缓存与路由的价值。
• 容量有硬上限。 上游有速率限制，撞上去不是慢，是被拒。所以「流量涨了就自动扩容」这条路在模型服务里经常走不通——你得先有配额。

对产品经理来说，理解这一层的原因是：很多「体验问题」其实是服务问题。用户抱怨「有时候特别慢」，往往不是模型变笨了，而是并发上来之后排队了、或撞到了限流。

它如何工作

围绕上面四件事，通常有这几种手段：

• 缓存：相同或语义相近的请求直接复用结果。它对重复率高的场景收益极大（客服问答里同一类问题反复出现），对一次性场景几乎无效。要做对需要在缓存键上想清楚——语义缓存 与精确缓存命中率差别很大，也各有误命中风险。
• 批处理与流式：把短时间内的多个请求合并，提升上游吞吐；同时用流式输出压低用户感知的首字延迟。两者一个优化成本、一个优化体验，常需要同时用。
• 路由与降级：简单请求走小模型、复杂请求走大模型；上游不可用时降级到备用模型或缓存结果。研究里把这套组合称为对成本敏感的服务策略——用便宜模型先处理大部分请求，只在必要时升级。[S2]
• 限额与配额：对调用方做限流，把配额按用户或团队分配，避免单个客户把共享配额打满。
• 版本与灰度：模型换版本时先小流量放出去，比较质量与延迟，再逐步切量。这一步需要前一站的度量能力——评估与可观测性是它的前提。

必须澄清的误会

模型服务 ≠ 推理服务器。 推理服务器是组件：负责加载模型、接收请求、返回结果。模型服务是一组持续的管理职责：并发怎么限、延迟超标怎么处理、版本怎么切、成本怎么控。这个区分在工程上很实用——换一个推理服务器往往不难，难的是在不停服的情况下把它换掉，那属于服务层的设计。

模型服务 ≠ 模型部署。 部署是动词，服务是状态。这条差别决定了你要不要准备「第 100 天」的清单：容量告警、配额预算、版本回滚方案、灰度节奏。只做部署的团队，通常在第 30 天左右遇到第一次配额撞顶。

它不是「运维的事」。 缓存策略影响用户看到什么、降级策略影响用户得到什么、限额影响哪些用户被排队——这些都是产品决策，只由运维单方面决定会在体验上留下很多说不清的取舍。

还有一条容易被忽略的：质量与成本在这里是同一个问题的两面。 用更大的模型、更长的上下文、更贵的检索，通常能提升质量；而服务的所有手段都在压成本。所以「模型服务」这一层实际上是把质量预算花在哪里的决策层，它不该被理解成单纯的省钱。

真实例子

一个面向内部员工的问答助手，服务层的配置可以是这样的：对高频重复问题启用语义缓存，命中即返回并标注「来自缓存」；按问题类型路由——常见政策问题走小模型，跨系统查询走大模型；上游超时超过 3 秒降级为「先返回缓存中最接近的一条 + 提示可能不是最新」；每日配额按团队分配，个人超额后排队而不是直接拒绝；模型换版本时先对 5% 流量放量，比较通过率与延迟后再全量。[S1][S3]

这里最值得抄的是降级与排队的选择：超额时排队而非拒绝，是因为这类内部工具的失败代价是「等一会儿」而不是「用不了」。反过来，如果是面向客户的实时场景，排队带来的体验损失可能大于直接给出一个「稍后再试」——这个取舍应该由产品决定，而不是由默认配置决定。

什么时候适合与不适合

适合：调用量有稳定规模、对延迟与成本有明确要求、需要多版本并行或灰度。这类场景里，服务层投入的回报是可测量的。

不适合：仍在验证阶段、调用量很小的产品。此时过度设计服务层（复杂缓存、多模型路由）会拖慢迭代，而收益几乎为零——先用最简配置跑通，等量上来再优化，代价更小。

这里有两种失败要分别设防，它们的对策不在同一层。 一种是静默降级：上游出问题时系统返回了缓存或旧结果，但没有任何标注，用户以为拿到的是新答案。降级必须可见，否则它会把一次可用性故障变成一次数据错误。另一种是缓存误命中：语义缓存把「看起来相似但结论相反」的问题当成同一个，返回了错误答案。缓存要按后果分级——事实类查询适合缓存，涉及权限或时效的问题不适合。

亲自试一下

用约 40 分钟为你的服务写下三个硬指标与超限时的行为：

1. 延迟上限：用户可接受的第 95 百分位延迟是多少？（注意区分首字延迟与整体完成时间）
2. 并发上限：上游配额是多少？撞上之后是排队、降级还是拒绝？
3. 成本上限：单次调用的成本上限是多少？超过时优先砍什么——上下文长度、模型档位，还是调用次数？

再加一条：模型换版本时，谁在什么条件下决定全量切换？ 如果你想不出一个具体的判据，说明当前版本切换还依赖「感觉差不多」，那正是下一站（给判断）要解决的问题。

接下来学什么

模型服务是这一站（给接口）里负责「长期可调用」的那一层。它下面的组件是 推理服务器 与 模型部署；对外的契约是 模型 API；配套机制还有 限流、语义缓存 与 成本优化。

如果你想弄清「为什么上下文越长越贵」，那是第一站（给地基）的 Token 与 上下文窗口。如果你要判断「换个更便宜的模型会不会让质量掉下来」，那是 给判断 的事：先有 评测集，再谈降本。

来源与修订

关于按用量与输入长度计价、缓存与批处理对成本的收益，参考 OpenAI 的 Cost optimization 与 Google Cloud 的 AI and ML perspective: Cost optimization；关于「先用便宜模型处理，必要时再升级」的级联策略及其成本与质量权衡，参考论文 FrugalGPT。[S1][S2][S3]

需要说明一处边界：「并发 / 延迟 / 版本 / 成本」这个四件事的划分，以及「降级必须可见、缓存要按后果分级」这两条要求，是本站在梳理服务层职责时总结的，不是上述来源的原文。三份来源主要讨论成本优化手段，不给出服务层的职责清单。

2026-09-21 按决策页规范重写，本次修订把服务层拆成并发、延迟、版本、成本四件事，并补入「降级必须可见」这条约束。