108 篇博文 含有标签「llm-ops」

我在上个季度交流过的一个团队花了六周时间追踪其智能体（agent）平台上的内存压力报警。这些智能体的运行成本很低——每次运行只需几美分。但追踪（trace）却不是。他们的遥测流水线消耗的预算是其所监测的 LLM 调用预算的三倍，而且大部分支出都花在了几个月没人看过的字段上：每个 span 上存储的完整 prompt 正文、在父级和子级追踪中重复出现的工具输出，以及一个在每次捕获的追踪上重新支付推理费用的 LLM-judge 评估器。

这是 AI 可观测性成本危机的缩影。一份 2026 年的行业报告模拟了一个拥有 10,000 个对话且每个对话有五轮互动的客户服务机器人——这相当于每天 200,000 次 LLM 调用、4 亿个 token，以及大约 100 万个追踪 span。Datadog 用户广泛报告，在处理其 REST API 的相同后端上监测 AI 工作负载后，可观测性账单飙升了 40-200%。流水线在为同样的 token 支付两次费用：一次是为了生成它们，一次是为了记住它们。

解决方法不是“减少日志”。解决方法是将 AI 系统的可观测性视为一种具有自身单位经济效益的工作负载，与传统服务发出的请求-响应遥测分开处理。传统日志是你可以压缩并遗忘的结构化字段；AI 日志则是无限制的文本正文，每当有人读取它们时，就会重新计入推理预算。这种区别就是“Token 感知日志”的含义。

你的 AI 评估测试集（eval suite）有 800 个测试用例。你又增加了 200 个。现在你的模型在评估中得分 94%，你满怀信心地发布了。三天后，一名用户发现了一个回归（regression）问题，而你那 1000 个测试用例中没有一个捕获到它。

这不是运气不好 —— 而是结构性问题。回归问题的存在恰恰是因为你扩充测试集的方式，而不是尽管你扩充了测试集才存在。当出现故障时增加更多评估指标（evals）的本能在理论上是正确的，但在实践中却适得其反。更多的测试并不自动意味着对重要事项的覆盖率更高。它们意味着对那些易于测试的事项有了更好的覆盖，而这完全是两回事。

当你的 AI 功能输出错误答案时，第一个问题总是：“是模型的问题吗？”大多数工程师会进行模型评估，运行几个测试提示词，并得出模型看起来没问题的结论。他们通常是对的。模型没问题。故障发生在其他地方——在你的组件相互通信的那些无形接缝处。

这一结论的证据是一致的。对生产环境 RAG 部署的分析显示，73% 的故障是检索故障，而不是生成故障。在多智能体系统中，最常见的故障模式是消息顺序冲突、状态同步间隙和 schema 不匹配——这些都不会出现在任何单组件健康检查中。GPT-4 在处理复杂的提取任务时，产生无效响应的比例接近 12%，这不是因为模型坏了，而是因为模型与下游解析器之间的输出格式契约从未被强制执行。

模型背了锅，边界才是元凶。

你共享驱动器上那份签署了 14 个月的 AI 供应商合同是根据 SaaS 模板起草的。它保证了正常运行时间，指定了安全联系人，并将责任上限设定为 12 个月的费用。但对于你的提示词是否会被喂进下一次训练运行，当你依赖的模型被悄悄换成更小的变体时会发生什么，或者当监管机构询问时你的推理日志存放在哪个地区，它却只字未提。起草它的律师利用他们掌握的词汇量完成了一项称职的工作。但这些词汇量比现在的覆盖范围落后了一个世代。

采购团队仍在为错误的合同进行优化。标准的 MSA（主服务协议）打的是 2010 年代的战争——停机补偿、漏洞通知窗口、进入源代码仓库的知识产权赔偿。AI 供应商关系有着不同的攻击面，而最重要的条款往往在现有模板中连个标题都没有。如果一个团队任由去年的采购指南来处理今年的供应商技术栈，那么他们正在签字放弃一年内就会需要的筹码。

我在上个季度交谈过的一个团队发布了一个微调模型，该模型在内部评估中比基础模型高出 4 分，但在接下来的 6 周内，他们却眼睁睁地看着排名前三的客户流失。评估结果没问题。聚合指标没问题。微调模型只是恰好在中位数用户（即询问简短事实性问题的小型企业买家）身上表现出色，而在企业法律客群中悄悄退化了，而后者那些长篇、包含大量引证的查询才是真正的营收驱动力。没有人按照客户等级对评估进行切片分析，因为建模端的人并不知道客户等级至关重要。

大多数关于微调的讨论都处于两个极端之一。一端是“一个微调统治所有”的方法，它在所有客户数据的混合体上训练单个专业化模型，并冲刷掉了原本在基础模型中区分各细分市场的特定客群行为。另一端是“单客户微调”方法，它为每个租户训练一个单独的适配器（adapter），这在客户数量少于 100 个时在运维上是可以忍受的，但在达到几百个左右时就会崩溃。一个有趣的中间地带——由少数几个客群感知微调模型来服务细分的客群——在大多数生产实践手册中是缺失的。

AI 功能上线后的 Bug 数量并非质量问题。它是一个发现序列——一个非常可预测的序列，以至于你可以在发布公告发布之前，在白板上逐周、逐个工单地勾勒出来，并且在仪表盘数据跟上时，你会发现自己预测得惊人地准确。每个上线 AI 功能的团队都会经历这个序列。唯一的选择是，你是带着操作手册（runbook）去执行，还是通过一系列临时的紧急会议来应对。

我已经观察了足够多的发布，足以相信这个序列实际上与工程质量无关。它关乎信息差。发布前，团队拥有合成流量组合、精选的评测集（eval set）、理想路径的演示和董事会演示文稿。发布后，真实用户带着合成流量从未模拟过的意图蜂拥而至，市场团队开展了工程团队仅略有耳闻的营销活动，模型提供商发布了未经团队授权的更改，而隐私审查员在功能上线时正在休假。下面的序列就是当这两个世界碰撞时产生的摩擦。

我的团队第一次发现我们依赖的模型即将退役时，是从客户那里得知的。弃用通知邮件躺在一个被三名工程师退订了的共享收件箱里。提供商的状态页上挂着横幅。Webhook 事件发射到了虚空中，因为我们从未配置过接收端。60 天的预警时间，被我们浪费成了 0 天，最终以一场停机事故和塞满“紧急迁移”同步会的日程表收场。

我交流过的大多数团队目前都处于这种状态，只是他们自己并不知道。每个主流 LLM 提供商都在悄悄构建通知层面 —— 针对故障的 Webhook、变更日志中的弃用事件、通过电子邮件发送的账户警告、账单异常提醒、区域故障转移信号 —— 而大多数团队要么禁用了这些功能，要么将其路由到了一个没人看的邮件列表。提供商一直在提前告诉你坏消息。是你选择不去听。

我上个季度交流过的一个团队，他们的所有仪表盘都显示绿色。工具错误率稳定在 0.3%。端到端成功率为 98%。SLO 预算几乎没动过。但他们的 Token 支出却是预计的四倍，而且没人能解释原因。当他们最终对每个 Trace 的重试深度进行埋点时，情况发生了反转：成功请求的中值实际上进行了 2.7 次工具调用，而不是架构图里承诺的 1.0 次。智能体（Agent）并没有失败。它是在同一个 Span 内部不断失败又不断恢复，而成功率指标根本无法体现这一点。

这是传统可靠性词汇无法涵盖的智能体可靠性部分。MTBF（平均故障间隔时间）假设故障是断续的、可观测的事件，你可以在两次故障之间进行计数。你测量间隔，计算平均值，并在间隔缩短时发出警报。这对于硬盘、网络和确定性服务都很有效。但对于那些在单个用户可见的操作内部进行重试、重定向、降级并静默恢复的系统来说，它失效了。

你账单上的模型名称与上季度完全一致。API 响应中的版本字符串也没有改变。模型卡片和定价页面看起来也一模一样。然而，你的评估得分却下降了 0.5 分，拒绝模式以你提示词中未要求的方式发生了偏移，上周二还收到了几起客户投诉，称输出结果“感觉不一样”。你调试了代码，却一无所获。代码没变。权重变了。

静默量化（Silent quantization）是你合同约定的模型与供应商实际交付的模型之间的差距。之所以发生这种情况，是因为推理经济学持续收紧——每一美元的 GPU 算力在本季度必须承载比上季度更多的请求——而消化这种压力的最廉价方式，就是在更廉价的精度层级上重新托管同一个模型。FP16 变成了 FP8。在某些路由中，FP8 变成了 FP4。混合精度分片被替换进来。版本字符串没有变动，因为版本字符串从来都不是精度合约，而是一份营销合约。

发布前的成本模型通常是一张精美的电子表格。它假设通过代表性的提示词（Prompt）运行模拟流量，并在测试过的缓存命中率和干净的工具调用路径下运行。但发布后的现实是，一旦功能真正开始运作，这些假设都将不复存在。模拟流量未涵盖的意图恰恰是用户最常使用的。工程团队没收到会议通知的营销活动所带来的流量，最终落在了路由树中成本最高的分支上。在第三周，使用量超过中位数 40 倍的重度用户群体才会开始出现。

这类问题在全行业内已屡见不鲜：调查显示，约 80% 的企业对 AI 成本的预测偏差超过 25%，并报告在成功发布后的几个月内，成本通常会增加 5 到 10 倍。这些数字中关键的细节是“成功”二字。失败的 AI 功能才能维持在预算内。成本偏差是由功能的成功运行驱动的，而不是因为团队做错了什么。这使得它成为一个规划产物（planning artifact）问题，而不是工程问题 —— 而大多数团队依赖的规划产物，即每月账单，其实是最糟糕的检测器。

你的 AI 产品上有两个正在走动的时钟，且它们并不同步。模型厂商的更新节奏大约是季度性的——2026 年 2 月发布 Claude Opus 4.6，3 月发布 GPT-5.4，4 月发布 Claude Opus 4.7，一周后发布 GPT-5.5。而你的产品路线图在 1 月份就已经确定，直到 7 月才会再次评估。在这期间，你花了 8 个工程周构建的功能可能变成了一个单行 API 参数，而团队中没有人有一套流程来察觉这一点。

这不是一个预测问题。这些发布早有预兆——任何阅读变更日志（changelog）的人都能预见到。这是一个规划产出物（planning-artifact）的问题。路线图是为那个底层平台十年才更新一次的世界而发明的。现在的平台每季度更新一次，而这种产出物却没有跟上。

凌晨 3 点因为宕机而把你吵醒的告警其实是简单的。供应商返回了 40 分钟的 503 错误，你的回退机制生效了，运维手册（runbook）启动了，复盘报告（post-mortem）几乎可以自动完成。而那些没有吵醒你的告警——那些在所有仪表盘都显示绿色的情况下，让你的支持队列在 6 小时内堆满的告警——才是渐变故障（brownout）。供应商的 API 仍然有响应。状态页依然显示“运行正常（operational）”。你的 p99 延迟已悄然从 2.1 秒漂移到 14 秒，错误率从 0.1% 上升到 4%，而唯一察觉到的人是那些已经流失的用户。

供应商的可用性并不是非黑即白的二元状态。大多数团队编写的回退逻辑——“如果供应商宕机，则切换到备用方案”——本质上是用一个只有两种状态的状态机去应对一个连续变量，当供应商处于“惨淡运行”而非“彻底宕机”的状态时，这种机制根本不会触发。为渐变故障（brownouts）而设计是一个与处理宕机完全不同的设计问题，我所见过的几乎每一个生产环境中的 Agent 调度框架在发布时都没有解决这个问题。