299 篇博文 含有标签「observability」

每个正在基于LLM构建系统的工程团队，都在做基础设施决策时忽视了一项隐性成本。你会追踪token数量、延迟和API开支，但几乎没有人追踪其运行的推理工作负载的碳排放——而这个缺口正在迅速收窄，来自监管和市场两个方向的压力都在增加。

AI系统现在占全球温室气体排放的2.5–3.7%，已正式超过航空业2%的贡献，且每年增长15%。仅2024年，运行AI专用服务器的美国数据中心就消耗了53–76 TWh的电力——足以为720万户家庭供电一年。这种规模已不再是假设，工程团队需要了解自身贡献的预期正成为真实的组织压力。

一个运行多智能体市场调研流水线的团队花了 11 天时间观察他们的系统正常运行——绿色的仪表盘、零错误、正常的延迟——而 4 个 LangChain 智能体却在无限循环中互相博弈。等到有人扫了一眼账单仪表盘时，这一周 127 美元的预估成本已经变成了 47,000 美元。这些智能体从未崩溃。API 从未返回过错误。每一个基础设施告警都保持沉默。

这就是 AI Oncall 的核心问题：你的系统在运维层面可以显示为绿色，但在其本应完成的任务上却发生了灾难性的失败。传统的监控旨在检测崩溃、延迟飙升和错误率。AI 系统可以在满足所有基础设施 SLO 的同时，悄无声息地产生错误输出、无限期地循环执行任务，或者在不产生任何有用结果的情况下消耗数千美元的计算费用。错误代码的缺失并不代表结果的正确。

METR 于 2025 年发布的一项研究，邀请 16 位经验丰富的开源开发者预测 AI 工具能让他们效率提升多少。他们猜测会快 24%。该研究随后对 246 个真实任务（包括修复 bug、开发功能、代码重构）进行了测量，这些任务被随机分配到"允许使用 AI"和"禁止使用 AI"两组。结果是：使用 AI 的开发者实际上慢了 19%。研究结束后，参与者再次接受调查。他们仍然认为 AI 让自己效率提升了 20%。

这种感知生产力与实测生产力之间的差距，并非某项研究的特例。这是大多数团队目前衡量 AI 功能时所面临的核心问题。那些看起来像成功的信号，在很多情况下衡量的是工具的新鲜感，而非其实用价值。而上线后的头 30 天，是最不适合观察的时间窗口。

当团队第一次将 LLM 接入日志管道时，演示效果非常惊人。你只需粘贴一段堆栈跟踪（stack trace），GPT-4 就能用通俗易懂的语言解释根本原因。因此，接下来的自然选择显而易见：将其自动化。将所有日志都发送给模型，让它寻找问题。

这就是你每月烧掉 125,000 美元，并用“幻觉”来骚扰值班工程师的方式。

计算过程简单而残酷。一个中型生产系统每天产生大约十亿行日志。按每条日志条目大约 50 个 token 计算，每天就是 500 亿个 token。即使按照 GPT-4o 折扣后的每百万输入 token 2.50 美元计算，在不计算输出成本、重试或推理开销的情况下，你每天也要支付 125,000 美元。对流式日志进行实时的前沿模型分析不是一个优化问题 —— 而是架构选型错误。

构建生产级 AI 系统的团队往往通过同一种方式发现“对齐税”：有人投诉延迟，另一个人将其追踪到审核流水线，于是原本隐性的成本项突然变得显而易见。到那个阶段，安全层已经层层堆叠 —— 拒绝分类器、输出过滤器、毒性评分器、人力介入队列 —— 却没有任何人对它们进行过单独测量。拆解它们是痛苦、昂贵且在政治上充满争议的，因为现在看起来你是在反对安全。

更好的路径是从第一天起就将安全开销视为一等公民的工程指标。对齐税是真实的，它是可衡量的，并且具有复利效应。150 ms 的防护栏检查听起来还可以，直到你在智能体工作流中将三个检查串联在一起，并纳闷为什么你的 P95 延迟达到了 4 秒。

你的支付服务拥有 99.9% 的可用性 SLA。请求要么成功，要么以文档记录的错误代码失败。当出现故障时，你清楚地知道哪里出了问题。

现在，想象你发布了一个封装了 LLM 的智能发票解析 API。在一个周一早晨，你最大的客户打来电话：“你们的 API 返回了一个有效的 JSON 对象，但在涉及外币的发票中，total_amount 字段的值差了十倍。” 你的服务返回了 HTTP 200。你的可用性仪表板显示绿色。根据每一个传统的 SLA 指标，你都没有违反任何规定。但你确实搞砸了——而且在契约语言中，你甚至找不到词汇来描述到底哪里出了错。

这就是当今大多数 AI API 部署的核心鸿沟。管理你的 API 承诺 的契约为确定性系统而写，而 LLM 并非确定性系统。

你的 Datadog 仪表盘一片绿色。Jaeger 链路看起来干净整洁。P99 延迟符合 SLA。而你的 Agent 流水线正在悄无声息地因重试死循环每天烧掉 4000 美元，却没有触发任何一条报错。

传统 APM 工具是为微服务设计的——确定性路径、有界载荷、可预测的扇出。Agent 流水线打破了所有这些假设。执行路径在运行时才能确定。工具调用深度变化剧烈。一次"请求"可能跨数分钟产生数十次 LLM 调用。而当出了问题，失败模式通常不是异常——而是一个悄然膨胀成本和延迟、却返回看似正常输出的静默重试级联。

结果是一代工程师在盲目飞行，信任着那些衡量错误事物的仪表盘。

大多数团队能把单智能体的可观测性做得足够好——加上链路追踪、统计 Token 用量、设置错误率告警。然后他们把并发智能体扩展到一百个，才发现整个监控体系一直在盯错方向。

摧毁集群的问题，并不是摧毁单个智能体的那些问题。一个陷入递归推理循环的智能体可以在一小时内烧光一个月的 API 预算。模型服务商悄无声息的质量降级，会让集群里的每一个智能体同时以满满的自信给出错误答案——而你的基础设施仪表盘依然一片绿灯。这些故障不会出现在延迟图表或 HTTP 错误率中，因为它们根本不是基础设施故障，而是语义层面的失效。

大多数生产环境中的 AI 失败都是“响亮”的。模型返回 5xx 错误。模式验证抛出异常。评估套件在发布前捕获了回归。但还有一类失败是完全无声的——没有错误，没有异常，没有警报触发——因为系统正完全按照设计运行。它只是在处理一个来自 18 个月前的现实快照。

你的 LLM 存在知识截止日期（Knowledge Cutoff）。这个截止日期不仅仅是文档中的一个脚注。它是模型认知的真实情况与实际现实之间日益扩大的鸿沟，而且你每在生产环境中多运行一天旧模型，这种差距就会累积。团队庆祝上线，随后眼睁睁看着用户信任在接下来的六个月里悄然瓦解——世界在前进，而模型却停滞不前。

你的单次请求错误率看起来很正常。延迟在 SLO 范围内。LLM 裁判对输出的评分是 87%。接着，一位用户提交了支持工单：“我把账号告诉了机器人三次，它却一直重复问我。”另一位用户说：“它先是同意退款，两轮对话后又否认该政策的存在。”

单轮失败是显而易见的。请求进来，模型出现幻觉或拒绝回答，你的评估 (eval) 捕捉到了它，然后你修复提示词。反馈循环很紧密。多轮失败则完全不同：会话开始时表现良好，随后逐轮恶化，而你的监控从未报警，因为每个单独的回复在技术上都是连贯的。问题出在整个会话上——而几乎没有团队为此建立观测机制。

对主要前沿模型（Claude 3.7 Sonnet、GPT-4.1、Gemini 2.5 Pro）的研究显示，从单轮转向多轮对话时，平均性能会下降 39%。这个数字掩盖了真相：只有大约 16% 的下降是由于能力损失。另外 23 个百分点则是一场可靠性危机——随着对话长度增加，模型在同一任务上的最佳表现与最差表现之间的差距翻了一番。你得到的不仅是质量更差的输出，还有极不稳定的输出。

你的监控显示一切正常。延迟处于正常水平。错误率平稳。然而，你的客服 AI 刚刚告诉 10,000 名用户退货是免费的——且是永久免费——而这根本不是公司的政策。没有触发任何报警。没有进行任何部署。模型只是自己决定这么做了。

这就是 AI 系统轮值（on-call）的现状：这类生产环境故障不会触发你构建的报警，无法追溯到某行代码，也无法通过回滚上一次部署来修复。标准的事件响应手册——检查日志、确定提交（commit）、回滚更改、验证恢复——是为确定性系统设计的。应用到 LLM 时，它们完全无法捕捉到真正的失败模式。

以下是真正有效的方法。

你的 p99 延迟刚刚飙升到了 12 秒。警报在凌晨 3:14 响起。你打开运维手册 (runbook)，看到如下指令：检查数据库连接池、验证负载均衡器、重启服务。你三样都做了。延迟依然居高不下。服务并没有宕机——它正在运行且有响应。但有些地方不对劲。事实证明，由于最近的一次提示词 (prompt) 变更无意中开启了“啰嗦”模式，模型生成的响应比平时长了三倍。运维手册里没有关于这一条的说明。

这是工程团队尚未准备好应对的新一类值班事故：系统正在运行，但模型表现异常。传统的 SRE 运维手册假设的是二进制的故障状态。AI 系统是以概率方式失效的，其症状看起来不像停机，而更像“漂移”(drift)。