47 篇博文 含有标签「finops」

你的基础设施账单上的每一项其他支出都经过了审核。有人为数据库集群提交了采购订单。有人在购买可观测性 SaaS 之前清点了席位。有人在团队将 Kubernetes 占用空间翻倍之前进行了容量审查。然后，模型 API 出现了，而这一切都没有发生。

一名工程师将他们的 API 密钥添加到了配置文件中。他们写了一个 create() 调用，看起来与代码库中的其他函数调用完全一样。它上线了。而财务部门第一次得知这个功能作为一个成本中心存在，是在月度发票上的一个差异项——一个没人预测过、没人批准过、也没人能立即解释的数字。

这就是 AI 的 FinOps 鸿沟，它不是一个监控问题。它是一个披着监控外衣的治理问题。即使你拥有完美的仪表板，依然会感到惊讶，因为早在支出出现在图表上之前，它对你的审批流程就是不可见的。

大多数团队购买推理资源的方式，就像他们的前辈在 2010 年购买 EC2 时一样：全部按需（on-demand），按 token 计费，且在两个维度上同时让人措手不及。账单是一个意外。速率限制（rate limit）是另一个——在发布的中途出现的 429 错误，就在你从未预留的按需资源池被其他同样选择支付零售价的人争抢时。然后有人打开定价页面，发现供应商一直都在悄悄销售预留容量：预置吞吐量（provisioned throughput）、承诺使用折扣（committed-use discounts）、按单位小时计费而不是按百万 token 计费。云计算行业花了十年时间才内化的预留实例决策，现在就摆在 token 面前，但几乎没有人移植这一套玩法。

这种现象的原因并非无知。而是你为计算资源学习的预留实例数学模型无法直接迁移，而它失效的方式恰恰是在惩罚那种天真的承诺。预留一个 EC2 实例是在赌你一年后仍然需要那种实例类型。预留一块 token 吞吐量则是在赌你一年后仍然需要 那个模型——而模型的生命周期是以月计算的，而不是以十年计算。承诺的结构很熟悉，但你所承诺的对象却并非如此。

一切都没坏。这正是让人困惑的地方。没有部署失败，没有延迟报警，错误率也没有上升。有人合并了一个只有一行的 PR，在系统提示词（system prompt）末尾添加了一句话——一个新工具的描述、一条政策提醒，或者是“今天的日期是”的页眉——结果第二天早上，推理账单就高出了三到五倍。流量平稳，模型没变，代码也完全按照预期运行。

改变的是那一行代码放错了位置，导致你集群中所有的缓存前缀（cached prefix）瞬间失效。你的缓存命中率在一个请求周期内从 90% 降到了零，原本几乎免费的每个 token 开始按全价计费。这就是 Prompt 缓存悬崖（prompt-cache cliff），它是生产环境下 LLM 系统中最昂贵的故障模式，而且没人会对它进行威胁建模，因为它看起来根本不像故障。

财务在月底打开发票。一个供应商。一个数字。它比上个月大，而且下个月还会更大。然后他们提出了唯一重要的问题 —— 这是哪个功能花的钱？ —— 房间里没人能回答。

这是在生产环境中运行 AI 的一种隐蔽失败模式。并不是说账单数额巨大；如果价值匹配，数额大也没关系。失败之处在于账单是无法归因的。它作为一个单一的费用项出现 —— OpenAI、Anthropic、Bedrock、Azure —— 没有任何财务部门真正需要的维度：没有按功能、按团队、按客户，也没有按成功的任务进行拆分。你能看到总额在上升。但你看不出 原因，而当发票寄到时，原本可以解释它的请求上下文早已消失了。

你的云账单可以具体到标签，告诉你上个月一个被遗忘的 S3 存储桶花费了 14,000 美元。但如果你问 LLM 账单同样的问题——到底是哪个功能烧掉了价值 40,000 美元的 token——大多数公司的真实反应只能是耸耸肩。供应商的发票上每个模型、每个 API 密钥只有一行记录，而三个团队共享这个密钥，财务报表中的 “AI 成本” 行则是根据人头、感觉，或者在上次规划周期中抱怨最少的人来分摊的。

这不仅仅是一个小的簿记烦恼。当没人能说出每一美元的 token 支出背后具体对应哪个功能时，会出现两种失败模式。低成本的功能被限制了，因为它们与昂贵的功能共用一个预算额度。而真正浪费的功能却永远存在，因为它们的成本是隐形的——被分摊到了共享的密钥、共享的缓存以及服务于六个不同产品界面的共享智能体（agent）循环中。

FinOps 基金会 2026 年的调查发现，目前 98% 的组织都在积极管理 AI 支出，而一年前这一比例为 63%，再前一年仅为 31%——这是该基金会有记录以来最快的采用曲线。每个人突然都在做 “AI 领域的 FinOps”。但很少有人注意到，云 FinOps 的核心原语——资源标签（resource tag）——在 token 的世界里并不存在，而且现代 LLM 使用的三个特定机制正活跃地破坏着成本归因。

每一个内部 LLM 平台都会经历同样的曲线。在第一个月，推理是免费的：平台团队买单，产品团队疯狂实验，每个人都在为增长曲线欢呼。到了第六个月，账单增长了 10 倍，财务部门开始提出尖锐的问题，平台团队发现 80% 的支出由三个团队产生——其中一个团队还在运行一个没人记得批准过的夜间批处理作业。本能的反应是安装计量器并开始收费。这种本能如果应用得过于幼稚，正是你毁掉平台的方式。

这是一个令人不安的事实：按 Token 计费的分摊机制（Chargeback）恰恰惩罚了你构建平台所鼓励的行为。正在原型化可能改变支持流程的智能体（Agent）团队消耗 Token 就像熔炉一样——智能体工作负载每个任务消耗的 Token 是简单聊天补全（Chat Completion）的 5 到 30 倍。如果从第一天起就按原价向他们收费，他们就会停止原型开发。与此同时，运行成熟且经过优化的功能的团队只需支付微薄的费用，看起来非常“节俭”。你构建了一个对学习征税、对停滞奖励的定价系统。

这里有一个事实打破了大多数工程仪表盘的逻辑：两个完全相同的推理请求，返回相同的 token，按相同的 API 费率计费，但其碳足迹（Carbon Footprints）可能相差五倍。相同的模型，相同的提示词，相同的花费。唯一改变的是由哪个数据中心响应以及当时的时间。如果你的可持续发展指标是根据支出金额推导出来的——几乎所有人都是这么做的，因为支出是唯一被真正追踪的数字——那么你的可持续发展指标就是错误的，而且当你越是努力优化成本时，这种错误就越严重。

美元和焦耳看起来应该是一致变动的。更多的 token，更多的计算，更多的钱，更多的能源。对于在单一瞬间、单一地点处理的单个请求，它们确实大致一致。但是，当你开启那些能实现大规模廉价推理的杠杆——激进的批处理（Batching）、模型路由（Model Routing）、非高峰期调度、多区域故障转移——这两个指标就会脱钩。成本是合同的函数，而碳排放是物理学和电网的函数。它们不是同一种函数，将其中一个作为另一个的代用指标，最终会导致你在可持续发展报告中填入一个审计员可以证伪的数字。

你的财务团队构建了一个精美的 AI 成本仪表盘。Token 支出，按功能划分。Embedding 支出，按供应商划分。每个季度，按功能的面板都会在领导会议上接受审查，有人会问为什么支持聊天（support-chat）的工作流增长了 12%，而产品经理会给出一个合理的解释。每个季度，按供应商的面板都会在基础设施会议上接受审查，有人会问为什么 OpenAI 的支出增长了 8%，而平台工程师会给出一个合理的解释。然而，每个季度，真正让你 AI 账单翻倍的那一行——语料库重索引（corpus re-index）——却落入了一个名为“基础设施”的第三个篮子里，没有人审查它，因为没有人负责。

那个篮子是 40% 的 AI 支出在没有归属的情况下白白流失的地方。本可以优化它的团队从未见过它。而能看到它的团队却无法告诉你它是为哪个功能服务的。仪表盘对它能解释的所有成本都保持诚实，而对它无法解释的成本保持沉默，而这恰恰是至关重要的成本。

你的财务团队发起了一项申诉并失败了。该账单项是“输出 token”，它比你交付 token 总数的统计指标高出了 14%。供应商的支持工程师以“流式传输取消下的预期行为”为由关闭了工单，并附上了一份文档链接，上面写着“取消操作将在最后一个交付的 token 处停止计费”。这两句话都是事实，而它们之间的差距，正是你尚未编写的那行代码。

你阅读的合同是一回事，推理调度器的实际操作是另一回事。这种不匹配既不是 bug，也不是计费错误，更不是恶意欺诈——它是一个分层系统，取消信号必须穿越三个边界（浏览器、边缘节点、GPU），而计费表位于第三个边界，但你的“停止生成”按钮却位于第一个边界。缩小这一差距是一个由财务负责人发起的工程项目。

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

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

财务部门在周一发了一份备忘录。到周五，每个产品团队都上线了 Prompt 的变更，而接下来的周二，支持队列增加了三分之一。没有人动过模型。没有人动过产品。唯一改变的是，LLM 账单现在流回了发起调用的团队——而团队的反应就像任何理性的成本中心对损益表（P&L）上的新条目所做的那样：削减它。

事后公司内部流传的是关于 Prompt 工程、或模型退化、或是由于用户流量波动导致的一周的故事。而更真实的真相是，财务部门通过一项费用分摊（Chargeback）政策，悄无声息地成为了产品经理。成本归因仪表盘成为了一个没人审查、没人为其准备监控工具、也没人负责的产品质量杠杆。当它发生波动时，公司里的每一个 Prompt 都随之波动，而导致质量退化的权衡取舍，从未被那些职责本应是监控这些变化的人察觉。

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

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