47 篇博文 含有标签「finops」

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

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

当财务团队第一次要求 AI 产品团队预测单位经济效益（unit economics）时，对话往往如出一辙。团队打开推理仪表盘，指着每月的 token 支出说：“这就是我们的销售成本（COGS）。”CFO 乘以预估业务量，在图表上画出一条线，并询问毛利率曲线何时能跨过 70%。六周后，当实际损益表（P&L）出炉时，仪表盘上的推理数字是正确的，但毛利率却比预测低了 20 个百分点。没人撒谎。推理费用其实只占 Agent 实际成本的一半。

另一半成本分散在 AI 团队中无人负责的各个分项中。向量数据库的账单在悄无声息地增长，因为检索量随使用量增加，而重新索引的成本计入了计算费用，而非存储费用。可观测性平台的发票则从平台团队的预算中支出。嵌入重构（Embedding regeneration）表现为 CI 成本。遥测数据存储被归入数据仓库。人工审核则计入客户成功（customer-success）的人员成本。这些项目单独看都不起眼 —— 这正是为什么整合后的数字会让所有人大吃一惊。

当团队发布“每个席位 $X 美元的无限 AI”订阅层级时，定价会议上没有人意识到这是一个衍生品头寸。它看起来就像一个普通的 SaaS 定价页面——一个数字、一个层级、一个行动召唤（CTA）。但现在，该页面带来的每一美元收入都暴露在供应商设定的 Token 成本曲线之下，而该供应商的路线图根本不在乎你的毛利率。你写的不是定价页面，而是一份针对 Token 波动性的裸卖空合约，而行权价就是你的供应商在下季度收取的费用。

数学计算很快就显现出结果。少数重度用户发现了工作流，并开始在他们能塞进的最长上下文中运行它。竞争对手的 UX 变化重新训练了中位数用户，让他们发送长出 40% 的查询。你的功能所绑定的前沿模型因为旧版本层级被弃用而迎来了每百万 Token 价格的上调。其中任何一项都是你在单个季度内无法通过定价页面逆转的利润事件——而且它们往往会成群结队地到来。

你所在的平台团队计划在第三季度调查的影子 IT 事件，其实早在 1 月份就已经发生了。情况大致是这样的：某个产品团队的一名高级工程师本月要发布产品。而平台团队的“官方” LLM 网关还在“下季度”的路线图中。于是，这位工程师用公司信用卡开通了 OpenAI 账号，将 API 密钥丢进 .env 文件，发布了功能，并赶上了公开的截止日期。发布非常成功。六个月后，FinOps 团队发现了三个无人认领的供应商账号，安全团队发现包含客户数据的 Prompt 被路由到了不受数据处理协议（DPA）保护的地区，而平台团队发现他们花了两个季度构建的网关只有 14% 的采用率，因为每个需要 AI 的团队都在没有它的情况下完成了发布。

这不是安全方面的失败，也不是纪律方面的失败。这是平台与产品交付速度之间的不匹配，如果将其视为其他任何问题，那么你发布的下一个网关注定会遇到同样的采用率问题。

晨会上出现了一个回归问题：支持代理昨晚回答错了三个客户问题。有人说：“我们试试在这个路径上用 Opus，看看能不能解决。”四十分钟后，评估通过率回升了，团队关闭了工单，而该路径上的推理账单悄然翻了三倍。六周后，同样形式的回归出现在另一个路径上，并采用了同样的修复方法。你的团队刚刚训练出了一种巴甫洛夫反射：质量回归 → 增加算力。更大的模型是你的技术栈中最昂贵的调试工具，而你现在却首先想到它。

问题不在于更大的模型没有帮助。它们确实有——有时甚至很大。问题在于，更大的模型是一种绝对占优的“掩盖”策略。当提示词指令冲突、检索返回了过时的块、工具描述被误读，或者评估集没有覆盖失效的分布时，更强大的模型会绕过这些故障而不修复其中的任何一个。下一次回归仍具有相同的根本原因，账单已经复加，而底层系统变得更加脆弱，而非更加稳健，因为升级带来的缓冲空间让所有人都不再去探究底层逻辑。

我认识的一个团队在上个季度通过将支持邮件分类流程从顶级模型（frontier model）迁移到中级模型，将推理费用降低了 40%。CFO 还专门发了感谢信。六个月后，客户支持团队增加了两名全职员工（FTE），平均解决时间上升了 35%。没有人把这些点联系起来，因为这些“点”分布在不同的仪表盘上：推理费用在平台团队的仪表盘上，而支持工作量在运营团队的仪表盘上。在所有人都在追踪的唯一指标上，这次迁移看起来是一次胜利。但指标错了。

这就是“单 Token 成本”（cost-per-token）陷阱。你的账单告诉你花了多少钱在 Token 上，但它无法告诉你每个“正确”任务花了多少钱，因为推理供应商根本不知道在你的领域里什么是“正确”。他们卖给你的是原始算力。而你买的是结果——或者你以为你买的是结果。这两个单位之间的差距，就是 AI 单元经济（unit economics）悄然崩溃的地方。如果不去衡量正确的分母，团队就只算了一半的账，而在另一半的交付上处于盲目状态。

一名开发者在 9:00 打开 IDE 的 Copilot，在早会前问了三个问题，然后一直开会到 11:30。聊天面板仍然打开着，对话依然可以滚动查看。模型在两个半小时内没有生成一个 token。然而，这个无人问津的会话整个上午都在悄悄地产生费用。KV 缓存被占用。提示词缓存（Prompt cache）通过定期 ping 保持活跃。对话状态保存在热存储（hot store）中。追踪流水线每跳动一次心跳就写入一行记录。模型提供商预留了并发槽位。乘以一万个席位，这笔账单是真实存在的。

这就是“闲置智能体税”（idle agent tax）。它是你推理预算的一部分，用于支付用户并未使用的容量。由于大多数工程仪表盘是为无状态 API 构建的，因此它在仪表盘上是不可见的。一个请求进来，一个响应出去，容器关闭。搞定。智能体产品在两年前就打破了这一模型，而大多数团队尚未根据这一变化重新调整其架构的成本模型。

FinOps 团队在一年前推出了 AI 内部计费（Chargeback）。仪表盘非常华丽。每个功能团队都能精确到分地看到上个月的推理账单，平台 PM 的幻灯片展示了 SKU 级别的业务线归因。相比一年前，组织拥有了更多的 AI 功能，但 AI 的质量却变差了。目前还没有人将这两个事实联系起来，但它们其实是同一件事。

用一句话概括这种失败模式：内部计费为推理 Token 定价，却悄无声息地忽略了评估 Token 的定价。因此，组织架构中的每一位 PM 都面临着一个奖励模型升级、惩罚评估规范的激励结构。12 个月后，评估覆盖率在萎缩，而账单却在增长——这与 FinOps 项目最初设想的激励效果完全背道而驰。这并不是仪表盘的漏洞，而是内部计费模型在严格执行其设计逻辑，只是在 AI 领域，源自云成本 FinOps 的设计假设已不再适用。

你的财务团队会要求你提供一份你写不出来的容量规划。这不是因为你缺乏经验，也不是因为模型是新事物，而是因为经典容量规划所依赖的两个假设——可衡量的负载分布和在季度维度上稳定的单位成本——在 AI 工作负载面前都失效了。你交给他们的数字从第一天起就会是错的，而当偏差出现时，随后的讨论将不仅仅关乎账单。

《2026 年 FinOps 现状报告》将 AI 列为增长最快的新支出类别，大多数受访者表示 AI 成本超出了最初的预算预测——对于许多企业来说，推理现在消耗了 AI 账单的大部分。用 SaaS 风格的容量规划来管理它的本能反应——选择一个峰值 QPS，乘以单位成本，再加上 30% 的缓冲——产生的数字看起来像预测，其实际预测能力却如同占星术。你真正需要的容量规划看起来更像是 FinOps 场景模型，而不是采购电子表格，而生成它所需的工程工作属于平台工作，会一直与功能开发竞争资源，直到财务部门失去耐心。

我在上季度接触的一个团队在他们的推理账单上发现了一笔 4200 美元的条目，没人能解释其来源。控制面板显示的流量正常，延迟图表也很平稳。原因最终被发现是一个 Agent 陷入了长达 6 小时的“礼貌”重试循环中，它不断地通过指数退避（最高限制为 30 秒后重启）来重放一个包含 4 万个 Token 的工具链。这套重试策略是直接从 2019 年为基于 HTTP 的 JSON 服务编写的内部 SRE 手册中照搬过来的。它运行得非常完美——只是用错了系统。

这就是那种不会出现在容量规划表中的账单。行业标准化的无状态 REST API 重试策略模式默认了三个前提，而 LLM 工作负载在悄无声息中违背了这些前提：故障是瞬时的、单次额外尝试的成本是有限的，以及重试有合理的成功机会。每一个前提曾是关键的支撑，而现在每一个都是错的。这种成本模型从未捕获的偏差，正潜伏在每一份月度账单的底部。

那些还没有根据 Token 经济学重建重试策略的团队，正在缴纳一种隐形税。这种税收随着你本就最担心的查询难度而增加——那些长文本、Agent 类以及带有深层工具链的查询。在 LLM 技术栈中，经典韧性工程提供给你的安全网，反而成了勒紧脖子的绞索。

你的可持续发展仪表盘报告显示：“本季度 AI 能耗：2.3 GWh，同比下降 4%”，这张幻灯片在 ESG 评审中得到了礼貌性的认可。六个月后，CFO 走出分析师电话会议，向平台负责人提出了一个听起来很简单的问题：“我们的每瓦特 Token 数（token-per-watt）是多少？与竞争对手相比如何？”仪表盘无法回答。这并不是因为数据缺失——仪表盘里堆满了数据——而是因为它将推理视为单一的条目，将任务视为产品概念，而 AI 可持续性唯一真实的单位存在于这两者的交汇点。

这种错位并不是报告中的 Bug。这是一个分类错误，现有的碳核算指南（为基于 CPU 小时和每台虚拟机 kWh 的云工作负载而完善）无法独自解决。推理并不是一种具有稳定能量特征的工作负载。每 Token 的瓦特数会根据响应请求的模型层级（model tier）产生 30 倍的变化，根据调用时的批处理大小（batch size）产生 4 倍的变化，并根据前缀缓存（prefix cache）是否命中而产生另一个数量级的差异。将这些汇总成一个单一的 GWh 数字，就像在包含踏板车、轿车和 18 轮大卡车的车队中报告“平均汽车燃油效率”一样——在最无用的层面上，它是准确的。

模型发布的公告在周二早上落地。博客文章开头是一张图表：HumanEval 提升了 4 个点，SWE-bench Verified 提升了 6 个点，MATH 提升了 3 个点，而当前流行的 Agent 测试套件提升的数值在一年之前足以写成一篇研究论文。到了周二下午，你公司的 Slack 频道里就会出现该图表的截图，随之而来的还有一个类似决策的问题：“我们要切换过去吗？”这个讨论线程将基准测试的增量视为一种预测 —— 仿佛这些数字描述了新模型在 你的 产品中、使用 你的 提示词、在 你的 工具链下、针对 你的 评估准则所能表现出的效果。事实并非如此。厂商给出的数字是你可能看到的性能上限。你实际获得的提升大约在零到该标题数值的一半之间，如果不运行一次厂商从未运行过的评估，你无法得知确切结果。

这并非在抱怨基准测试的有效性。基准测试是真实的。它们是针对真实的评估套件运行的。厂商没有撒谎。问题在于厂商的评估套件是一个理想化的环境，剥离了生产部署中引入的每一个变量，而在这些条件下生成的数字在结构上无法预测模型在你环境下的行为。将其视为一种预测是一种范畴错误 —— 它会导致采购决策、容量规划承诺以及发布时间表都基于虚构的事实进行校准。