21 篇博文 含有标签「finops」

用户提交了一个 $0.01 的请求。你的智能体读取了一个网页。40 秒后，该次对话的推理账单变成了$42。该查询在技术上是成功的——智能体返回了一个合理的答案。只是为了得到这个答案，它经历了三个嵌套的子智能体、一次 200K token 的文档获取，以及一个递归的计划优化循环。这些扇出（fanout）操作并非用户的本意，而是隐藏在智能体所读取页面中的一句话。

这就是代币放大（token amplification）：一种提示词注入攻击，它不窃取数据，不调用未授权工具，也不会留下明显的安全特征。它只是烧光你的账单。云账单是攻击载荷，而用户的请求则是载体。

当你的 AI 账单月额度首次突破七位数时，预算会议的形式就会发生变化。在那之前，问题是“我们能否负担得起”。在那之后，问题变成了“谁能分到多少”——而大多数工程团队会实时发现，他们根本没有应对这一问题的政策框架。那个发布了最响亮演示的团队会意外地获得最高配额。财务部门则在推行扁平的人均上限，这让那些从事最高杠杆工作的团队陷入困境。安全部门则完全被排除在对话之外，直到有人发现评估团队过去六个月一直在通过个人 Token 额度拉取生产流量。

这种对话之所以总是感觉像是在争论云成本，是因为它确实接近云成本，但不完全是。在云端，浪费的单位是一个被遗忘的 EC2 实例，最坏的情况是账单翻三倍。而对于 Token 配额，浪费的单位是一个失控的 Agent 循环，而准入的单位则是面向用户的功能：谁掌握了预算，谁就能发布功能。后一种特性使得 Token 分配更接近基于能力的安全性（Capability-based security），而不是云 FinOps。配额不仅仅是一个支出上限。它是执行一类推理的权利。

在每月 50,000 美元的水平时，你基础设施账单上的“计算 + Token”这一项只是可以忽略不计的零头。但当每月达到 5,000,000 美元时，它就是一个 CFO 级别的问题。这两个阶段之间的转变并不是渐进的——它是组织讨论模型支出方式的一种“相变”，而大多数工程组织对于随之而来的社会和政治工作都准备不足。账单依然是那简单的一行；但围绕它的对话却不再简单。

改变的是谁有资格问“为什么”。当三个产品团队共享一个 API Key 和一个预留容量时，每一个配额争论的结构都是相同的：某人正以牺牲他人的利益为代价获胜，而没有中立方来主持公道。当一个团队的发布第一次因为另一个团队上线了一个“话痨”智能体（agent）而受到限制时，整个工程组织会立刻感受到治理机构缺失带来的痛苦。在压力之下召开会议并凭空发明流程，是设计流程最糟糕的时机。

你的停止按钮是个谎言。当用户点击它时，你的 UI 停止渲染 Token；但在大多数配置下，你的供应商仍在继续生成它们。这些字节从未到达浏览器，但却出现在你的发票上。用户看到的与你支付的之间的差距就是“取消税”（cancellation tax），它是 AI 成本仪表盘上被低估最严重的支出项。

取消税的存在是由结构性原因导致的。自回归推理是一个受 GPU 限制的流水线：当你的客户端关闭 TCP 连接时，模型已经排好队、完成了 KV 缓存，并正以每秒 30–200 个 Token 的速度输出。大多数推理服务栈在 Token 之间不会检查客户端的活跃状态。它们完成任务，记录用量，然后向你收费。客户端看到了 10 个 Token，而日志记录了 800 个。Langfuse、Datadog 以及所有其他观测平台都会忠实地报告这 800 个 Token，因为那是供应商 usage 数据块报告的内容。

你的财务团队可以准确告诉你，上个月你在 Anthropic 和 OpenAI 上花了多少钱。你的产品团队可以告诉你，哪些功能的用户点击量最高。但公司里没人能告诉你 Draft-Email 是否盈利，Summarize-Thread 是否应该保留在免费层级，或者新的 Rewrite-Tone 功能是否在单用户成本上蚕食了 Draft-Email 的利润。你拥有两个声称追踪同一笔支出的仪表盘，但它们都无法回答那个真正驱动产品决策的问题。

这就是分配缺口。你按端点（endpoint）测量 Token 支出，因为这是供应商 API 提供的数据。但 /chat 端点服务于 12 个刚好共享同一个提示词模板的功能，“按端点”统计将这 12 个功能全部合并到了同一个细目中。在有人完成将 Token 成本导回至产生成本的功能这一底层工作之前，定价层级、功能权限管理、弃用决策以及“我们要不要发布这个功能？”的讨论，全都只能靠直觉。

这项底层工作并不光鲜。它是请求级标记（request-level tagging）、追踪与遥测数据的关联（trace-to-telemetry joins），以及一种坚决的态度：如果不带成本标签，就不发布任何 AI 功能。将此视为基础设施投资的团队，最终会获得按用户群细分的单功能利润报告。而将其推迟到下季度的团队，最终在 18 个月里只能凭感觉做定价决策，并在事后发现，某个单一客户群在负利润的情况下消耗了一半的推理账单。

一家中型 AI 公司的财务负责人在上个季度告诉我，他们通过将 Agent 骨干模型从 Sonnet 切换到 Haiku，“优化了他们的 LLM 支出”。Token 账单下降了 22%，而每个已解决工单的总推理成本仅下降了 4%。当我们进行完整的成本拆解时发现，模型这一项支出大约仅占单次请求成本的三分之一。检索、重排序（reranking）、可观测性、重试放大以及人工介入（human-in-the-loop）审核队列吃掉了剩下的部分——而且当你更换模型时，这些环节都没有变得更便宜。

这是我目前在 AI 团队中看到的最常见的财务核算错误。Token 成本是你每月支付的发票上的分项，因此它成了每个人都在优化的数字。但对于任何非平凡的生产系统——RAG、Agent、任何带有工具调用或评估门控的系统——模型推理往往只占实际单位经济效益的 30% 到 50%。剩下的部分隐藏在你的工程仪表盘不会显示、且财务团队不会将其归类为 “AI 支出”的地方。

你技术栈中最灵敏的泄露信号并不在 SIEM 中。它隐藏在财务人员月初打开的一份电子表格里。当攻击者窃取了 LLM API 密钥、利用提示词注入（prompt injection）窃取数据，或者通过被入侵的租户会话查询相邻客户的内存时，痕迹首先会表现为 Token 使用异常——这远在任何 DLP 规则触发、任何身份验证警报响起或任何终端代理察觉到异常之前。财务看到了，而安全部门却没看到。

这种差距并非理论上的。Sysdig 的威胁研究团队在观察到攻击者利用窃取的云凭据产生每日五位数的账单后，创造了“LLMjacking”一词。这一类别现已演变成一个有组织的犯罪产业，出现了每个账号 30 美元的交易市场，且有记录显示某些活动让受害者的损失每天超过 100,000 美元。OWASP 记录了一家初创公司因为密钥泄露，在 48 小时内产生了 200,000 美元的账单。斯坦福大学的一个研究小组由于在 Jupyter notebook 中遗忘了一个 Token，在 12 小时内烧掉了 9,200 美元。所有这些事件的共同点是：在安全团队察觉之前，账单图表就已经在几个小时甚至几天前揭示了真相。

你的财务团队想要一个数字。AI 智能体系统每月会花费多少钱？你根据平均 Token 使用量给出了估算，乘以预计的请求量，并加上了安全余量。三个月后，实际账单是预测值的 3 倍，而且没人能解释原因。

这并非预算编制的失败，而是建模的失败。传统的成本预测假设单次请求的成本会聚集在一个可预测的平均值附近。智能体系统在每一个层面上都打破了这一假设。执行路径是多变的。每次请求的 LLM 调用次数是多变的。每次调用的 Token 数量是多变的。这些变量之间的相互作用产生了一个带有“肥尾”（Fat tail）的成本分布，从而吞噬了你的利润。

一个 Shopify 规模的商户助手，每天处理 1,000 万次对话，在不进行优化的前提下每月成本高达 210 万美元 —— 而经过优化后，成本仅需 45 万美元。这 78% 的差距并非源于算法上的突破，而是来自缓存、路由以及一些大多数团队在收到账单前都会忽略的工程规范。

AI Agent 并不只是多了几个步骤的聊天机器人。单次用户请求会触发规划、工具选择、执行、验证，通常还有重试循环 —— 消耗的 token 数量大约是直接对话交互的 5 倍。一个运行 10 个周期的 ReAct 循环，其 token 消耗量可能是单次交互的 50 倍。在顶级模型的价格体系下，这种计算开销很快就会变成一项财务负担。

这篇文章将涵盖 Agent 成本的来源机制，以及能够真正产生影响的具体技术（附带数据支持）。