20 篇博文 含有标签「slo」

产品团队将新 AI 摘要器的 SLO 设置为 200ms TTFB，因为这是产品其他部分在 p50 下的表现。会议上没人问这 200ms 是怎么来的。它源于十年来通过 CDN 边缘缓存提供的静态资源和 JSON 响应，其缓存命中率为 85%，大多数请求从未到达源站，即便到达了，数据量也很小。而这个摘要器是针对每个用户的，每次调用都是重新生成的，且每次请求都要经过“边缘 → 源站 → 模型提供商”的路径。从第一天起，这个 SLO 在结构上就是无法实现的。团队在第六周才发现这一点，而此时仪表盘已经红了整整六周。

这是 AI 功能发布中反复出现的一种模式。组织在某种物理规律基础上建立的延迟标准，被一个遵循完全不同物理规律的功能所继承。于是，继承目标与可实现底线之间的差距，变成了一个长达数月的缓解项目，而不是第 0 天的设计约束。数字并不关心你是否出于诚意与客户协商了该 SLO。

一个优化单一损失函数的模型路由器会准确地交付该损失函数所要求的结果，除此之外别无他求。当该函数的目标是“保持在 p95 延迟目标之下”时，每一个本可以从深度推理（extended reasoning）中获益的查询都会被强行分配到路由器能辩护的最廉价路径上，因为快速模型能在 SLO 范围内返回，而缓慢但正确的模型则不能。延迟仪表板变绿了。综合评估指标（aggregate eval）仅波动了不到一个百分点，团队便将其视为噪声忽略不计。而没人绘图的分片视图（per-slice view）才是真正发生质量回归（regression）的地方：它集中在那些多步骤、模糊且分布外（out-of-distribution）的查询中，这些查询本应被路由到推理模型，结果却分配给了那些运行迅速但错误得很有底气的模型。

这不是路由 bug。路由器正在准确地执行其设计任务。Bug 出在框架设定上——如果一个系统的优化器完全以延迟为基准，它就会产生质量回归，而这些回归在团队为了 KPI 而维持“绿色”的指标中是不可见的。随后，它会默默地发布这些回归，因为盯仪表板的人并不是盯答案的人。

你的供应商状态页面显示为绿色。每秒 token 数 (TPS) 仪表盘显示的曲线一如既往地平稳。SLA 报告显示你完全处于合同约定的速率范围内。然而，支持队列里挤满了用户，他们形容聊天输出“一跳一跳的”、“断断续续”、“比上周还差”。你的监控指标中没有任何一项能证实他们的说法，因为你的监控根本没有在测量他们真正在关注的东西。

这是没有人察觉到的供应商交付故障模式。他们没有突破速率限制，而是重新定义了单位。每秒到达的 token 数量没变，但它们是以单 token 块的形式流式传输的，而不是针对渲染器优化过的 4 token 块。平均吞吐量依然完好，但感知质量却被毁掉了。SLO 依然达标，因为 SLO 是针对网络传输（wire）制定的，而网络传输是供应商控制的那部分系统。

产品规格说明书规定用户在说完话后的 600 毫秒内听到回复。LLM 供应商的仪表盘显示首个 Token 时间（TTFT）为 280 毫秒。你查看的每一张图表都在 SLO 范围内。但用户仍然抱怨智能体有延迟，当你亲自拨打电话时，确实能感觉到明显的停顿——每次都在 600 毫秒以上。仪表盘没有撒谎。它测量的是一个不包含 TTS 流水线、音频传输或接收端抖动缓冲（jitter buffer）的数值。流式传输的最后一个 Token 与第一帧音频之间存在的 350 毫秒差距是真实存在的，只是它没有出现在 LLM 团队的图表上。

Bug 不在模型中。Bug 出在 SLO 上。它被定义在了错误的堆栈层级。供应商的出站（egress）并不是用户的耳朵，任何忽视这一点的延迟契约都会在生产环境中显得数据健康，而产品体验却是一团糟。

我上季度合作的一个团队在周二发布了推理层升级，周三就开始收到支持工单。用户反映助手感觉“坏了”、“冻结了”或“卡住了”。值班工程师查看了延迟仪表盘，没发现任何异常。p99 首字延迟（first-token latency）为 612 毫秒——远低于团队花了一个季度建立的 800 毫秒 SLO。仪表盘是一片绿色。电话却响个不停。

问题的根源在于 14 个月前做出的一个埋点决策，当时生产环境中还没有推理模型。标记为 “first token” 的指标测量的是供应商发出的第一个数据块（chunk）的时间戳。升级后，第一个 chunk 变成了推理 token——这对用户不可见，也从未渲染，但在 SLO 中却被计为“首个”。模型在流式传输第一个用户可见字符之前，会先发出 4 到 7 秒的内部思考过程。每个图表依然是绿色的。每个用户却在黑暗中等待。

这不是一个关于指标好坏的故事。指标对于它最初设计的模型来说是正确的。这是一个关于当你的埋点边界不再是用户的感知边界时会发生什么的故事——以及在不知不觉中发布这种偏差是多么容易且危险。

你与模型提供商签订了合同。你的运行手册（runbook）处理了该提供商降级的情况。当他们的仪表板变黄时，你的状态页订阅会向你发送告警。你觉得万无一失。然后，在某个周三下午，你提供商运行的基础云区域开始出现局部降级，你提供商的故障转移区域也受到了影响，因为他们为了控制单位经济效益而整合了容量。由于签署合同时上游两层的供应商决策，你的产品在 90 分钟内处于半瘫痪状态。

第二天早上，客户的事后分析（postmortem）请求出现在你的收件箱里。他们想要找到根本原因。根本原因存在于你的状态页无法看到的层级，也是你的合同无法约束的层级。这一层级正是所谓的第四方风险——它不是一个采购复选框，而是一个无形的依赖层，它会向上层传导故障，只会衰减而不会被吸收。

设计文档写着“人机回环”。发布演示稿写着“默认安全”。六个月后的事故回顾则写道，由于审批人在吃午饭，智能体（Agent）花了 90 分钟才给客户发送发票。这些文档都没有撒谎。它们只是在描述同一个组件在负载曲线不同位置的表现——而其中只有一份准确抓住了全貌。

当你在智能体与不可逆操作之间加入人工干预时，你并没有增加一个安全原语（safety primitive）。你实际上是增加了一个服务，它带有队列、吞吐量限制、质量负载曲线以及可用性概况。如果一个团队在发布智能体时没有命名那个服务，那么他们交付的产品的关键路径将取决于一段他们拒绝去运维的基础设施。

一个用户询问你的智能体（agent）企业版的当前价格档位。智能体检索了一个分块（chunk），读取并回答：“每月 2,000 美元。” 信心满满，来源明确，格式优美。问题在于价格在四天前已经变了。智能体引用的数字在上周是真实的。它检索到的分块是在变更之前嵌入的，而索引还没有赶上进度。

没人决定让这种情况发生。没有设计评审说“智能体可以根据长达四天前的数据进行回答”。只是有一个每晚或每周运行的重新索引任务，以及一个随心所欲编辑内容的团队，而这两个时钟之间存在一个没人衡量的缺口。那个缺口就是一个服务等级目标（SLO）。无论你是否写下来，它都存在。唯一的问题是你是有意设定它的，还是由于意外继承下来的。

传统的 HTTP 请求只有一个关键的延迟：从请求到响应的时间。那个数字的 p95 就是契约。SRE 监视它，SLO 是针对它编写的，当它退化时就会有人收到告警。一个数字，一个仪表盘，一个真相。

流式 AI 功能在响应变为流的一刻就打破了这一模型，而大多数团队还未察觉。现在有了两种延迟，而且它们是发散的。首字延迟（Time-to-first-token） 是用户在任何事情发生前盯着加载图标的时间。完成时间（Time-to-completion） 是直到回答完全写完的时间。它们受不同力量的影响，由不同的杠杆修复，并且用户感受到的情感权重完全不同 —— 而几乎每个团队都只衡量第二个指标，因为那是 HTTP 框架免费提供给他们的数字。

每个智能体（agent）功能都有一个“后门”。有的团队称之为“转人工支持”，有的称之为“路由至人工审核员”，还有的则使用模板化的回复：“我无法处理此事——让我为你联系能提供帮助的人。”无论标签是什么，每个生产环境中的智能体都有一条放弃用户请求并将其移交给人工的路径。而生产流量采取该路径的比例，是少数几个不依赖标注员、评审员或手动构建测试集的信号之一。这是系统在生产环境中告诉你，模型无法处理用户实际发送的请求。

这个信号几乎总是被错误的团队读取。在大多数公司中，转人工率（Escalation rate）是一个劳动力规划指标：它决定了下一季度排队系统需要多少人工客服。它存在于运营团队审查的仪表板上，其审查频率与 AI 团队读取评估分数（eval scores）的频率完全不同。30% 的周环比转人工增长在周一的运营审查中表现为一个人员配备问题，而 AI 团队的评估套件依然显示绿色，领导层的报告也显示功能状态良好。两个团队看着同一个生产系统，却得出了截然相反的结论：运营团队认为他们需要更多人手，而 AI 团队认为模型运行良好。

仪表盘显示 0.5% 的请求触发了回退（fallback）。仪表盘这么显示已经持续六个月了。直到有人从头重新运行遥测数据（telemetry），发现次级模型正承载着 38% 的流量，而预设回复（canned-response）层级则处理了另外 9% 的流量。团队在路线图评审中一直讨论的尖端模型“主路径”，实际上已沦为少数派体验。没有人注意到这一点，因为没有任何警报被触发 —— 每次降级都是一个小规模的、理由充分的、局部正确的决定，而累积的偏差从未超过任何人事先设定的阈值。

这就是我想要定义的失效模式：成了默认项的回退机制。这不是故障，也不是单个组件的回归。它是产品表面的缓慢轮转，退而求其次的路径不再是安全网，而成了核心体验。团队的心理模型与生产现实渐行渐远，而这种差距是隐形的，因为现有的度量指标（meters）旨在检测失败，而非检测组合（mix）。

我要提出一个更强有力的观点：如果你的 AI 功能拥有两个以上的服务层级，那么你的层级组合（tier mix）本身就是一个 SLO。如果你没有测量它，你其实并不知道你发布了什么。

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

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