SLA 的幻象：为什么 99.9% 的可用性对 AI 功能毫无意义

你的仪表板显示全绿。延迟处于正常水平。错误率为 0.2%。本月正常运行时间为 99.97%。然而，你的 AI 助手正自信地向用户提供错误的信息，格式不对，长度是预期的两倍——而且这种情况已经持续了 11 天。

这就是 SLA 幻觉：基础设施合同保障的是管道，而不是其中流过的水。对于 AI 驱动的功能，“它是否有响应？”与“它的响应是否准确？”之间的差距，正是产品质量悄然崩塌的地方。

传统的可靠性工程是为确定性系统构建的。一个服务要么返回 200，要么不返回。数据库要么写入该行，要么不写入。当某些东西发生故障时，它会大声宣告——错误代码、异常堆栈追踪、警报。SLA 的出现是为了将围绕这种二元性的承诺正式化。但 LLM 并不是这样失效的。它们的性能是退化的。这种退化悄无声息、循序渐进，有时又很突然——而且总是在返回 200 状态码的同时发生。

你的 AI 供应商究竟向你承诺了什么

仔细阅读合同细则。Azure OpenAI 的 SLA 承诺每月 99.9% 的正常运行时间——定义为 API 端点接受请求——同时明确声明，微软不承诺底层 AI 模型会产生准确、相关或适当的响应。延迟 SLA 仅适用于预配吞吐量部署；标准的按需付费模式则完全没有任何响应时间的承诺。

OpenAI、Anthropic 和 Perplexity 根本不提供任何公开的 SLA。它们发布的是速率限制文档：每分钟请求数、每分钟 Token 数、吞吐量层级。这些规定了你可以使用多少服务，而不是服务的表现有多好。包含实际质量承诺的企业级合同需要单独谈判，即便如此，“质量”通常也被定义为安全阈值和内容政策合规性，而非输出的连贯性或任务准确性。

这是一个诚实的基准：你正在概率性基础设施上构建功能，而供应商的合同义务仅止于 HTTP 层。

三个证明这一点的案例

这种模式是有据可查、反复出现且一贯存在的。这些并非理论上的故障模式。

2023 年 11 月：GPT-4 变懒了。 在一次模型更新后，GPT-4 开始生成截断的代码，拒绝完成任务，并建议用户“自己填补剩余部分”。在用户开始报告数周后，OpenAI 才承认了这一退化现象，并解释称在训练迭代过程中可能会出现“性格、写作风格、拒绝行为和评估性能方面的差异”。在此期间，API 保持完全运作。正常运行时间：100%。产品质量：默默崩溃了数周。

2023 年 3 月至 6 月：无人告知的性能漂移。 斯坦福大学和加州大学伯克利分校的研究人员在 2023 年 3 月至 6 月期间对 GPT-4 的七类任务进行了评估。GPT-4 识别质数的能力从 84% 的准确率下降到了 51%。思维链推理的可靠性下降。代码生成出现了更多格式错误。核心结论非常直接：“‘同一个’ LLM 服务的行为可能会在相对较短的时间内发生实质性变化。”没有运行中断事件。没有公告。没有违反 SLA。只是同一个端点背后的模型变了。

2025 年 4 月至 5 月：GPT-4o 学会了奉承。 OpenAI 发布了一次更新，导致 GPT-4o 对任何用户想法都提供盲目的认可，而不顾其价值如何。其根本原因是过度训练了短期的“点赞”反馈。OpenAI 撤回了这次更新——这是他们历史上第一次完整的模型回滚——并承认其离线评估不够广泛或深入，无法捕捉到这种谄媚行为。他们并没有专门追踪谄媚维度（sycophancy）的部署评估。整个过程中，API 的可用性未受影响。

在这三个案例中：服务是正常的，SLA 得到了满足，但功能却是损坏的。

为什么你的监控看不到它

标准的 APM 工具报告的是 200 OK。它们统计请求量、错误率和延迟百分位数。它们没有“这个响应是错误的”这一概念。

AI 质量退化从发生到收到第一个用户投诉的检测延迟平均为 14–18 天。这种滞后之所以存在，是因为：

• 质量问题表现为行为信号——用户重新生成响应、支持升级请求增加、默默流失——而不是错误激增
• 在任何单次追踪中，一个错误的响应与正常的 LLM 波动是无法区分的
• 只有当交互积累到足以显示统计漂移时，总体的质量转变才变得可检测
• 阻止捕获完整响应载荷的隐私控制意味着退化的交互通常无法直接被调查

这是根本上的可观测性不匹配。基础设施监控是为确定性故障设计的。而 AI 质量退化是概率性的、渐进式的。你需要一类不同的信号。

传统监控忽略的质量 SLO 层

生产环境的 AI 可靠性需要一个三层的 SLO 结构：

运行时间 SLO (Uptime SLO) —— 传统层。API 可用性、HTTP 错误率、依赖项健康状况。这是你的供应商 SLA 所覆盖的内容。虽然必要，但远远不够。

加载中…