37 篇博文 含有标签「finops」

在部署后的一个季度，AI 团队报告单次 API 调用平均成本降低了 25%。支持团队报告 AI 分流工单的平均处理时间从 4 轮增加到了 7 轮。这两个数字都是正确的。两个团队都在测量他们被要求优化的系统。夹在中间的财务团队无法核对仪表盘，因为这两个指标都不是以客户实际支付的东西来衡量的：一个已解决的工单。单次调用成本下降了，而单次任务解决成本上升了 40%。由于没有团队负责这个指标，所以没人注意到它的变动。

这是我在智能体（agentic）部署中见到的最常见的单位经济效益（unit-economics）失败，而且这不是一个测量上的 Bug，而是一个定义上的 Bug。供应商的价格页面展示了单次调用成本，因为这是他们计费的单位。由于电子表格的单元格刚好放得下，这个单位就被继承到了表格中。工程团队针对给定的单位进行优化。等到 API 经济与业务经济之间的鸿沟变得清晰可见时，这种影响已经累积了一个季度，而智能体整个时间都在基于错误的损失函数（loss function）被悄悄训练。

该项支出在六周内攀升了 130%，工程团队却无人察觉。PR（拉取请求）的合入速度变快了。仪表板上的单次 PR CI 成本看起来与上季度持平。Agent 的分支在第一次尝试时通过测试（显示为绿色）的频率比人类的分支更高，这实际上反而拉低了 CI 持续时间的中位数。财务部门在季度复核中发现了这一点，将其标记为不明变动，并要求工程部门提交事后分析报告（postmortem）。工程团队无话可说 —— 既没有事故，也没有回退，更没有部署失败。仅仅是一项预算支出在仪表板显示一切正常的情况下，悄无声息地翻了一倍。

这个“事后分析报告”式的缺口本身就是一个产物。成本从以人力为主的曲线转向了以基础设施为主的曲线，而负责人力预算的团队与负责基础设施预算的团队并非同一个。Agent 没有弄坏任何东西，它只是改变了损益表（P&L）中承担这项工作的科目。

使用曲线几乎没变。账单却上涨了 38%。

这是某中型金融科技公司的财务主管在季度第一个周一收到的邮件。三个月前，工程部门重新谈判了他们的 LLM 推理合同，通过承诺最低使用量，从谈判后的单价中又削减了相当大的一部分。财务模型将新的单价纳入了财年预测。没有人留意到定价表中的脚注：如果月度使用量连续三个月低于底线，折扣将失效。4 月至 5 月的季节性流量下降正好触发了这一条款。供应商将账户重新分档回原价。工程部门没有收到任何通知，因为通知发到了采购部门的收件箱，而自合同签署以来，那里就没人读过邮件。

你的团队与推理提供商协商了月度 Token 配额。合同规定了上限。提供商门户的仪表板显示昨天的使用情况，存在一天的延迟。API 本身返回每分钟速率限制头——anthropic-ratelimit-tokens-remaining、x-ratelimit-remaining-requests——而对于你实际需要规划的月度配额桶却只字未提。你的智能体集群没有机制在预算耗尽时减速，因为实时到达的唯一信号是 429 错误——而这个信号在预算已经用完后才出现，且伪装成重试逻辑通常会忽略的瞬时错误。

这是一个与速率限制（rate limiting）性质不同的问题。速率限制是一个快速波动的节流阀，消费者必须在几秒钟内做出反应；响应头告诉你桶里还剩一千个 Token，并在 40 秒内补满，一个编写良好的客户端会退避并重试。月度配额则是一个缓慢变化的预算，消费者必须以周为单位进行规划。这两者之所以容易混淆，是因为它们共享错误代码，有时甚至共享同一个仪表板，但它们需要不同的控制手段——而提供商公开的信息与消费者需求之间的差距，正是本月最严重事故的导火索。

迁移看上去很干净。评估已经针对新模型版本重新校准。Judge 提示词重新调校过。两周的影子流量显示行为对齐在容差范围内。p50 和 p99 延迟都在预算之内。周四下午的上线评审签字通过,团队各回各家。

到了周五早上,推理账单是平时的 3 倍。评估分数依旧没问题。延迟依旧没问题。上线评审上没有人想到要对缓存命中率做埋点,因为前缀根本没变 —— 系统提示词逐字节相同,工具定义逐字节相同,对话框架逐字节相同。变的是请求体里的模型版本,而供应商的前缀缓存键是 (前缀字节 + 模型版本)。切换之后的每一个请求都打到了一个冷缓存上。预热曲线靠自然流量花了六周才恢复,在此期间团队为每个请求的每一个 token 都支付了完整的未命中价格。

失败的智能体（Agent）运行成本很低。它可能会误导查询、陷入死胡同、返回“我无法提供帮助”，而执行这些操作可能只消耗几百个 Token。但成功的运行却是一场“灾难”。它检索上下文、进行反思、调用三个工具、再次反思，最后缝合出一个自信的、长达数段的答案——其 Token 消耗是那些几乎不花钱的失败运行的五十倍。

这就是智能体经济学中令人不安的现状：你的理想路径（Happy Path）就是你的高昂路径。你所销售的结果，也就是你在营销页面上承诺的、用户为此向你致谢的结果，正是你的系统所能执行的最昂贵的操作。如果你按照过去十五年 SaaS 的定价方式——按每个席位收取固定月费——那么智能体每出色地完成一次工作，都在悄悄侵蚀你的利润。

大多数团队是后知后觉才发现这一点的。他们观察成本仪表板，看到失败的成本很低，便得出结论：提高可靠性将节省资金。事实并非如此。提高成功率只会增加你的账单。

财务部门对你发布的每个功能都会问一个问题：“每个用户的成本是多少？”对于传统功能，答案是一个数字。页面渲染、数据库查询、推送通知 —— 每一个的边际成本在不同请求之间几乎没有波动。你测量一次，乘以用户数量，预测就能成立。

AI 功能打破了这种契约。问一下“这个智能体（agent）每次请求的成本是多少”，坦诚的回答不是一个数字，而是一张直方图。同一个智能体，处理上一个工单可能只花 2 美分，但在处理下一个工单时可能会烧掉 4 美元。因为用户问了一个模糊的问题，智能体循环调用了 11 次工具，而每次调用都将不断增长的对话全文重新输入模型。这两次请求的平均值 —— 2 美元 —— 既无法描述其中任何一次请求，更无法真实反映最终账单。

这就是陷阱。当你向财务提交一个单一的平均成本时，你并不是在简化混乱的现实。你是在报告一个在特定的、昂贵的方向上完全错误的数字。

按 token 付费的心智模型训练了一代工程师，让他们认为 AI 成本是使用量的函数。没有请求，就没有账单。这是一个令人慰藉的模型，对于 API 调用本身而言，这基本属实。但它只描述了生产级 AI 功能的一个层面，而并非那个悄悄吞噬预算的层面。

预置吞吐量、预留 GPU 容量、预热向量索引以及待机微调端点都是按时长计费，而不是按计数器计费。无论流量是否到来，它们都为你提供服务流量的权利而收费。即便周六没人碰某个功能，计费表依然在转动。在办公时间内由 12 个人使用的内部工具，每周 168 小时都在计费。你为了 3 月份发布而准备的资源预置，在 5 月份流量洪峰平息很久之后，依然占据着预留额度。

这就是闲置成本。它之所以野蛮生长，原因并非技术层面，而是组织层面：没有一个单一的角色能看到它，也没有一个单一的角色负责它。

十四个月前，在你公司的某个角落，一位财务总监和一位平台负责人签署了一份为期数年的算力加速器资源承诺协议。他们根据前一个季度的遥测数据构建了一个峰值负载模型，谈到了比按需计费价格低 40% 到 70% 的折扣，并锁定了集群的规格——而你现在的产品路线图必须去适应这个规格。产品团队中没有人参与过那次会议。应用工程团队中也没有人见过那份电子表格。这份合同具有法律约束力，只有在履行承诺的前提下才能享受折扣，而它买下的容量边界，现在成了产品经理们正在规划的每一个第三季度功能的隐形天花板。

大多数团队直到第二年才会察觉到这个差距：容量合同本质上是路线图决策，但它们是由那些看不见路线图的人，使用不包含路线图信息的输入数据做出的。产品“三人组”认为他们正从一个清晰的优先级积压任务中挑选功能。财务部门认为他们正在优化一个固定的预算边界。在各自的语境下他们都是正确的，而冲突则会在规划会议上显现——当架构师提议为新的助手功能使用 700 亿参数模型时，平台负责人会平静地说，集群使用率已经达到 85%，如果不挤掉其他项目，这个模型根本放不下。

每个人都在看的成本仪表盘是一个周滚动平均值，而那个平均值正在对你说谎。并不是说数字本身是错误的——它是计费事件流的忠实算术平均值——而是它隐藏了底层的成本曲线形态。周五晚上到周一早上之间的 token 消耗方式，与周二上午 10 点到周四下午 4 点之间截然不同。周六凌晨 3 点活跃的群体与周二上午 11 点活跃的群体并非同一拨人，这些群体的单用户经济效益（per-user economics）差异巨大，但没人记录这一点，因为仪表盘通过平均值将其抹平了。

大多数团队第一次发现这一点，是在周末自动化脚本烧光预算的时候。一个 LangChain 智能体在周五晚上陷入了无限对话循环，运行了大半周才被人发现，导致产生了一张五位数的账单，周一早上不得不向财务部门解释。事后回顾将其视为一次性事件——糟糕的重试逻辑、缺失的预算上限、没有触发值班报警。但是，那个隐藏了失控循环的仪表盘，同时也隐藏了同一现象的稳态版本：每周都会出现的非工作时间流量基准，其单位经济效益在结构上比工作时间基准更差，而周平均值让这一切变得不可见。

你的 AI 功能成本是一个分布，而不是一个数字。挂在研发财务作战室墙上的仪表盘显示，上个月支出了 187,000 美元，并按功能、模型和区域进行了细分。然而，这些视图都无法回答 CFO 真正想问的问题：“谁每月付给我们 40 美元，却消耗了我们 4,000 美元的成本？”当你按 customer_id 而不是功能进行排序时，原本平稳的柱状图会变成一条曲棍球棒曲线，而那些针对平均用户进行设计的团队会发现，他们在一个季度里一直在默默地为长尾头部的用户提供补贴。

这种模式是如此一致，以至于完全可以被称为定律。在生产环境的 LLM 工作负载中，前 1% 的用户通常驱动了 30–50% 的 token 支出，而在排名前 0.1% 和 0.01% 的用户中也会出现类似的分布形状。这并非某个产品的特例 —— 当你发布一个边际成本可变且定价统一的功能时，这必然会发生。平均用户的利润率看起来不错，中位数用户的利润率看起来非常好。但重尾部分的积分才是季度预算的真正去向。

在每一家发布托管 LLM 功能的公司，通常在第四个月左右都会召开一次财务会议。工程团队一直在记录每次请求的 Token 数量。财务团队手里拿着供应商的账单。两边的数字对不上。有时差距是 5%，有时则是 30%。工程师说是账单错了，财务团队说是日志错了。从技术上讲，双方都是正确的，但谁也不负责对账。

这种偏差并不是欺诈。它是一个结构性的衡量问题，而且这种结构至少包含六种相互叠加的独立失效模式。一个不掌握这些失效模式的团队，接下来的一个季度都会在给 FP&A（财务计划与分析部门）写道歉信，解释为什么预测失准，而真实的情况是，工程侧根本没有人审计过自己日志中的 “Token” 到底是什么意思。