供应商 SLA 差距：为什么你的 LLM 提供商的运行时间忽略了导致产品崩溃的故障模式

你的 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 的属性。供应商无法承诺能力的稳定性，因为他们正在不断地重新训练和重塑安全栈，而且 “你的特定任务变差了” 并不是他们能检测到的退化 —— 他们对自己的基准测试进行回归测试，而不是你的。供应商无法承诺服务于你区域故障转移的模型与主区域完全一致，因为运行多区域推理服务的运营现实包含由容量驱动的异构性。

功能可用性差距是结构性的，而非商业性的。供应商向你出售的是一件具有不可约减的、特定于应用程序的可靠性故事的基础设施。弥补这一差距取决于你如何进行监测，因为你是唯一知道产品 “正常工作” 意味着什么的一方。

加载中…