你的 LLM 供应商声称 99.95% 的可用性。你的状态页显示绿色。你的延迟仪表盘在 SLO 范围内。但你的产品依然坏了 —— 助手在今天早晨开始拒绝常规请求，支撑下游解析器的 JSON 输出从紧凑变得啰嗦，而且你用模型分拣的支持工单中有三分之一返回了 “我无法提供帮助”。所有这些响应都在 800ms 内返回了 200 OK。它们都没有违反 SLA。这个 SLA 覆盖的是你实际上并没有遇到的故障模式。
这是采购谈判中没人预估到的差距。供应商出售的是 可用性（availability） —— 一种请求层面的承诺，即 API 及时响应了；而产品团队消费的是 能力（capability） —— 一种请求层面的承诺，即答案是可用的。这两者不是同一个指标，而混淆它们的团队离发现其中的区别只差一次静默的模型升级。
SLA 到底衡量了什么
阅读任何前沿模型供应商的可用性承诺，法律文本中都会出现同样的定义：一个 “可用” 的请求是指在一定的延迟范围内返回 2xx 响应。对于托管的基础设施服务来说，这个定义是一个合理的原语（primitive）。但它也遗漏了对于以 LLM 为核心的产品来说真正重要的每一种故障模式。
那些返回 200 OK 且从未出现在 SLA 报告中的故障列表长到可以自成一派：
- 拒绝率激增。 内容安全策略更新收紧了模型的拒绝倾向，昨天还能回答的提示词今天返回了 “我无法提供帮助”。HTTP 层显示成功。产品层显示停服。
- 静默模型升级后的能力退化。 供应商在不更改端点名称的情况下推送模型更新。你的 “长期更新” 别名（evergreen alias）指向了一个新的快照，而依赖于旧模型行为的工作流开始产生不同（有时是更差）的输出。供应商没有撒谎 —— 他们发布更新是因为这些更新在综合基准测试中有所提高 —— 但你的特定用例在没有发布说明的情况下退步了。
- 返回 200 但答案质量下降的配额限流。 在负载压力下，一些供应商会回退到较小的模型、更小的上下文窗口或更廉价的采样设置，而不是返回 429。调用成功了，账单涨了，但答案变差了。
- 作为功能更新发布的内容安全策略变更。 模型的行为受到系统级安全栈的塑造，而安全栈的演进独立于模型版本。由于模型周边的环境而非模型本身发生了变化，在不同日期对同一个固定快照发出的两次请求可能会表现出不同的行为。
- 区域容量下降导致整个大洲的流量被路由到行为不同的备份区域。 区域故障转移保持了 API 的可用性。但服务于该备份区域的模型可能运行着不同的版本、不同的量化方案或不同的系统提示词。你的用户访问相同的 URL，却得到了一个微妙不同的产品。
这个列表中的每一项都符合供应商的 SLA。但没有一项能通过用户的 “功能是否正常？” 检查。签署合同的团队得到了可用性的承诺。而运营产品的团队需要的是 功能可用性（functional availability） —— 这是供应商不衡量、不发布、也不承担责任的另一种 SLI。
为什么采购无法弥补这一差距
当你注意到这个差距时，直觉是将其推回给法务：谈判更严格的 SLA，要求模型版本稳定性的保证，在合同中写入拒绝率上限。这很少奏效，而且并非因为供应商不合作。
供应商无法承诺拒绝率上限，因为拒绝行为是你提示词的属性，而不是他们 API 的属性。供应商无法承诺能力的稳定性，因为他们正在不断地重新训练和重塑安全栈，而且 “你的特定任务变差了” 并不是他们能检测到的退化 —— 他们对自己的基准测试进行回归测试，而不是你的。供应商无法承诺服务于你区域故障转移的模型与主区域完全一致，因为运行多区域推理服务的运营现实包含由容量驱动的异构性。
功能可用性差距是结构性的，而非商业性的。供应商向你出售的是一件具有不可约减的、特定于应用程序的可靠性故事的基础设施。弥补这一差距取决于你如何进行监测，因为你是唯一知道产品 “正常工作” 意味着什么的一方。
弥补差距的监测手段
严肃对待这一问题的团队最终会建立四块基础设施，而这些供应商都不提供。它们共同将 “我们依赖 LLM 正常工作” 从一种愿望转化为一种可衡量的属性。
针对你的评测套件定义的、在生产环境中持续运行的功能可用性 SLI。 挑选一小组具有代表性的提示词，用来测试你的产品所依赖的能力 —— 例如解析器消耗的结构化输出提示词、客户支持分类路径、智能体工作流的规划步骤。以稳定的频率针对生产模型运行它们，并使用与离线评测相同的标准进行打分。将通过率作为一等公民指标与延迟和错误率一起发布。当它降至阈值以下时，即使供应商的状态页是绿色且你的 5xx 错误率为零，也要呼叫运维人员。这是能检测到供应商 SLA 遗漏的所有问题的 SLI。
值班团队将其视为信号而非谈资的拒绝率和退化率仪表盘。 为每个响应标记一个轻量级分类器，用于检测拒绝（“我无法提供帮助”、“我无法……”、结构化的策略拒绝输出）和退化模式（低于长度阈值的响应、缺少预期 schema 的响应、导致下游解析失败的响应）。将这些作为时间序列进行跟踪，并提供与延迟相同的告警能力。拒绝率激增也是一种事故，就像延迟激增一样 —— 产品退化了，用户受到了影响，需要有人介入。
通过对已知提示词和已知输出进行哈希锚定来检测静默模型变更的契约测试。 构建一小组提示词，其预期输出应具有足够的确定性以便进行比较。每小时运行一次。当输出哈希值改变时，你就知道底层发生了变动 —— 可能是快照指针、安全栈更新或区域配置更改。这相当于对你无法控制的上游二进制文件进行金丝雀测试。它会产生噪声，特别是对于生成式任务，因此请将其与语义字段的相似度检查结合使用，并将哈希检查保留给应当稳定的结构化输出。
区分 “API 在线” 与 “API 有效” 的供应商 escalation 路径。 当你因为拒绝率一夜之间翻倍而开启支持工单时，供应商的第一反应会引用正常运行时间数据。准备好重构对话的语言：包括评测通过率、拒绝率增量、发生反转的提示词以及时间戳范围。“你们的 API 在线，但我们的功能评测通过率在 UTC 03:00 到 03:14 之间从 94% 下降到 71%” 是一个有效的沟通起点。而 “模型坏了” 则不是。
实践中的具体表现
一个运行客服总结功能的团队在 2 月下旬注意到，总结质量的投诉已经持续上升了两周。供应商的仪表盘显示为绿色。团队的延迟、错误率和成本指标均处于正常范围。他们调用的模型别名（model alias）也没有改变。
功能可用性（functional-availability）仪表盘讲述了一个完全不同的故事。在同样的这两周窗口内，总结提示词（prompt）的评估通过率从 91% 飘移到了 83%，并在某个特定的周四出现了 4 个百分点的剧烈跌落。拒绝率仪表盘显示，在同一个周四，一个相关的提示词——要求模型从结构化工单中提取个人身份信息字段——的拒绝率有所上升。模型开始以隐私为由拒绝这些请求，而此前它是配合的。
将时间戳与供应商的公开变更日志进行交叉对比，一无所获。团队提交了一个工单，并在第一段就附上了评估和拒绝率的证据。不到一天，供应商就确认了在相关日期进行过安全栈更新。从用户感知的性能回退到得出诊断结果之间隔了 13 天。如果这些仪表盘早就在运行，那么从仪表盘报警到得出诊断结果的间隔可能只需要 1 小时。
教训并不是“供应商太差劲”。教训在于，供应商的可靠性叙述并不包含产品出现故障的那个维度，而在团队构建出监测工具之前，他们在这个维度上一直处于盲视状态。
将可用性与能力视为不同的关注点
采购谈判应该将供应商的 SLA 视为它本来的样子：它是底层基础设施的一个必要原语，但对于产品的可靠性叙述来说是不够的。架构审查应包括一个单独的功能可用性监测项，由应用团队负责，并根据 LLM 支持的功能的重要性来分配预算。值班人员应该明白，供应商状态页显示绿色而功能性 SLI 显示红色并不矛盾——这是 LLM 事故中最常见的形态。
这里有一个更深层次的架构启示。你的产品所依赖的其他每一个基础设施——数据库、缓存、队列、CDN——其 SLA 的单位都与产品的可靠性叙述相同。当数据库正常运行时，查询就能工作。当缓存正常运行时，查找就能命中。在大多数产品的历史中，LLM 是第一个供应商可靠性指标与产品可靠性指标以不同单位计量的依赖项。可用性（Availability）是供应商销售的单位。能力（Capability）是产品需要的单位。它们之间的差距并不是合同失效或供应商失职。它是该依赖项的一个属性，而想要可靠交付的团队必须建立起这座桥梁。
你的供应商给出的 99.95% 的数字是真实的。但它并不是决定你的功能明天早上是否正常的那个数字。那个数字是你必须自己去衡量的——而不这样做的团队，距离在生产环境中以惨痛代价认清“在线（up）”与“有用（useful）”之间的区别，只差一次悄无声息的模型更新。
会员专享
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- —完整文章，包含未公开存档的部分
- —可落地的工作框架，附带权衡与决策依据
- —新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部
