LLM 系统上线后，先盯四个指标

上线第一周，团队通常只监控一件事：接口有没有报错。等到第二周账单来了，才发现真正的故障是另一类——系统一直在正常返回，只是每十次里有三次答错了。

一、发生了什么

Stack Overflow 博客的 LLM 系统工程系列写到了第五层，主题是可运维性，篇幅是六层里最长的。它的统一设计是三个东西：一个瓶颈点、一个贯穿全链路的决策标识、领域层不感知具体供应商。

监控模型在常规的速率、错误、延迟之外，加了一层"决策"指标。文章列了 13 个，分成四族：决策（数量、自动执行比例、置信度、耗时）、安全（护栏拦截、评审模型分歧）、成本性能（token、美元、模型延迟）、质量（影子评估通过率、人工推翻率）。

如果只能留四个，作者给的是：自动执行比例、护栏拦截总数、美元成本、人工推翻率。理由是这四个分别对应"系统有多自主""它拦住了什么""花了多少""人还认不认"。

告警阈值写得很具体。评审模型分歧率超过 0.15 报严重；影子评估通过率低于 0.95 报严重；模型调用 p99 超过 8 秒且持续 10 分钟；自动执行比例相对七天基线变化超过 15%；护栏拦截速率达到前一小时均值的三倍；每小时花费超过日预算的二十四分之一。

SLO 有四条：99.9% 的决策能返回提案，注意"无法决策"才算故障，500 不算；质量不低于基线 2 个百分点，滚动七天；延迟看 p95，不含人工时间；每千次决策的成本控制在计划的上下 20%。

成本部分有一个观点值得记住：最强的杠杆是不调用模型。其次是批处理、缓存、选型、精简提示词。文章说便宜模型常常省 5 到 20 倍。预算示例是每分钟 20 万 token、每天 50 美元，而且限流要按预估 token 数计，不是按调用次数，否则 token 预算永远不会触发。

延迟优化给了实测数字：一个看起来像模型瓶颈的匹配任务，九成时间花在一亿次嵌套比较上；换成哈希连接后，耗时从 180 秒降到 12 秒，再批处理到 6 秒，并行后 1.8 秒，质量与基线持平。

二、跟你有什么关系

刚上线第一个 AI 功能的团队。 先有决策标识，再有指标。没有它，每次排查都是考古。

成本已经失控的团队。 检查两个静默放大器：失败重试风暴，和没有上限的工具循环。它们不会报错，只会让账单翻倍。

要给人用的高风险场景。 熔断开关要有三态：正常、只给人建议、完全停止。很多事故需要的不是"关掉"，是"把人放回环里"。

三、怎么用

1. 给每次请求生成一个决策标识，从入口带到出口。日志、指标、追踪都用它串起来。
2. 先上四个指标，别一次上十三个。自动执行比例、护栏拦截、成本、人工推翻率。
3. 设三个告警：分歧率、影子评估、成本。前两个管质量，第三个管钱。
4. 成本在网关按租户和能力归属。在业务代码里各自记账，最后一定对不上。
5. 预算做两层：单租户上限和平台总上限。只有单租户上限，等于没有总闸。
6. 熔断开关读不到时，返回"只给人建议"，不要返回正常。这是失败向安全。
7. 每季度做一次混沌测试：杀掉模型供应商，看系统是转人工还是报错。

四、三个别信的说法

"模型自己报的置信度可以当指标。" 文章明确把它列为反模式：未校准。要么用组合置信度并对照结果验证，要么别拿它做路由决策。

"面板上有 token 数就叫可观测。" token 数只是成本的一个因子。没有按租户、能力、模型的归属，没有重试与工具循环的标记，你看到的是总量，不是原因。

"重试是无害的。" 校验抖动会引发重试风暴，一个失败请求变成五次调用。重试必须有上限、有退避、有独立指标。

五、一句话结论

LLM 系统的运维不是把模型跑通，是让每一次决策都留下能归因的痕迹，并且在必要时能体面地停下来。

信息来源

• Part 5: Operating an LLM system: observability, cost, routing, and the platform underneath，2026 年 10 月 9 日

功能与价格以官方公告为准。本文写于 2026 年 10 月 19 日。