17 篇博文 含有标签「llm-cost」

你教会了 Agent 在上下文不足时说"我不知道",然后把这当成一次安全胜利。OpenAI 账单确实降了。所有人都同意这是负责任的做法。三个月后,你的客服 VP 在追问为什么人头预算偏差 40%,AI 团队里没人答得上来——因为你跟踪的指标是弃答率,而真正动起来的指标是每周工单数,而那条把它们加起来的曲线没有任何 owner。

这就是弃答税。它不是一种模型成本。它不会出现在推理账单上。它出现在下游:出现在每接住一句"我无法回答"就要排队处理的人工团队队列深度里,出现在针对人工额外补足后的上下文再跑一次的第二次模型调用里,出现在等待期间流失掉的客户身上。只看模型成本的那张账面,悄悄把它藏了起来。再加上 AI 团队负责弃答、运营团队负责队列的那道组织接缝,意味着没有人有动力去看清这件事。

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

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

公司里的某个地方，四个人各自都相信第五个人在管推理账单。工程把它当成云账单的一项。AI 团队把它当成做产品的成本。财务把它当成毛利率的可变输入，默认工程那边已经在管了。产品把它当成工程吸收的间接成本。账单一直在涨，唯一达成共识的是：这账不是我的。

这不是预算问题，而是所有权真空。它第一次浮出水面，往往是因为这条线大到 CFO 在董事会上点名问起。到那时，大家临时拼凑的回答——"我们会优化"、"我们会多做缓存"、"我们会换模型"——描述的是干预手段，却没有指出谁负责。本该在一年前发生的对话，并不是怎么把账单压下去，而是这笔账究竟属于谁的损益表。

这是结构性的变化。推理在企业 AI 支出中的占比，从 2024 年的 15% 涨到 2026 年的大约 85%；同一时间窗口里，企业平均的 AI 预算从 120 万美元涨到了 700 万美元左右。一项原本属于零头的科目，现在已经是董事会会注意到的数字，而那张在变化之前画好的组织架构图里，根本没有给它留一行。

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

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

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

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

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

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

只要为你的智能体连接一个 GitHub MCP 服务端，在用户输入一个字之前，你可能就已经消耗了 1.2 万到 4 万个 token。连接一个文件系统服务端、一个日历、一个数据库、一个内部 CRM 以及一个第三方工具目录，据测算，一个重型桌面配置的纯工具披露 (tool disclosure) 就会产生 6.6 万个 token —— 这几乎占了 Claude Sonnet 200K 上下文窗口的三分之一，而且在每一个规划轮次 (planning turn) 都要付费。智能体还没开始干活，用户还没开始提问，账单就已经开始计费了。

这就是“披露税” (disclosure tax)，它是目前交付的智能体系统中定价最低估的条目。团队添加 MCP 服务端的方式就像曾经添加微服务一样 —— 每一个集成看起来都像是一个免费的组合原语 (composition primitive)，采购理由也顺理成章（“更多工具 = 更多能力”）。而单位经济效益仪表盘 (unit economics dashboard) 从未反映出每个服务端的成本，因为成本隐藏在 token 桶里，没有人将其归因于连接器。结果是，每当有人添加另一个集成时，智能体就会变得更慢、更笨、更贵，而团队却通过重新调整提示词 (prompt) 和催促模型厂商发布新版本来解释这种退化。

控制面板上的对话情况看起来很健康。每次调用的平均 token 数合理，p50 输入长度舒适地处于缓存前缀（cached prefix）之内，供应商的发票按照财务部门批准的速度增长。然后，有人导出了一个包含 200 轮对话的单次编程会话，该用户的单项支出就超过了团队其余成员每日流量的总和。控制面板没有撒谎 —— 它只是在算平均值。账单来自于长尾（long tail），而长尾并不会随着轮次增加而线性增长。

每一个多轮对话的 AI 功能最终都会遇到这种“惊喜”。每次调用的 token 数是一个错误的衡量单位，因为 30 轮对话的成本不是单次调用的 30 倍 —— 而是 50 倍到 200 倍之间，这取决于历史记录的结构方式、提示词缓存（prompt cache）的衰减情况，以及一旦输入超过 200K token 后请求所处的计费层级。根据单次调用数据为功能定价的团队，实际上是在为他们从未建模过的长尾风险承保。

一个长时间运行的智能体（agent）会话最初以 2K 上下文开启，现在却在为 40K token 的“死状态”买单。第三轮的检索结果、智能体早已跳过的目录列表、工具调用返回的 JSON 转储（即便其答案只是一个整数）—— 所有这些都在随后的每一次推理调用中如影随形，全额计费，并拖累注意力。这种模式在结构上与内存泄漏完全一致：无引用的数据无限制增长。但没有剖析器（profiler）能发现它，因为泄漏并不存在于进程内存中。它存在于对话历史里，而大多数智能体框架在发布时都没有配备回收机制。

成本同时体现在两个地方。token 账单呈二次方增长 —— 一个 20 步的循环，每一步贡献 1,000 个 token，累计产生约 210,000 个输入 token，而不是 20,000 个，因为之前的每一轮对话都会在后续的每一次调用中重新计费。而且模型本身也开始退化：当积累了 50K token 的噪声时，即使是拥有 1M token 窗口的模型，在实际任务上的准确度也会出现两位数的下降。你在花更多的钱，让模型更差地去思考它在三轮前就已经解决的问题。

当财务团队第一次要求 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 价格的上调。其中任何一项都是你在单个季度内无法通过定价页面逆转的利润事件——而且它们往往会成群结队地到来。

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

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

无状态的聊天补全（Stateless chat completion）耗电量极低。一次中等规模的 Gemini 文本提示耗电约为 0.24 Wh；一次简短的 GPT-4o 查询约为 0.3–0.4 Wh。这些数字微乎其微，甚至没人会把它们放进董事会演示文稿里。

智能体任务（Agent task）并非普通的聊天补全。一个典型的“研究该客户并起草回复”的工作流可以扇出（Fan out）到 30 多个工具调用、10–15 次模型调用，且上下文窗口随着每一步不断增长。能源成本随调用图（Call graph）呈复合增长。当智能体返回结果时，你消耗的不是一个推理单元，而是五十到两百个。突然之间，每个任务的碳足迹便与视频流达到了同一数量级。

这种算术题很快就会在工程部门之外产生影响。欧盟的 CSRD 使范围 3（Scope 3）排放披露成为受规制公司的强制要求，并要求从 2026 年起提交机器可读的 iXBRL 报告。尽管 SEC 在其最终规则中删除了范围 3，但任何在欧盟有业务的跨国公司仍然必须回答这个问题。采购团队已经开始在供应商调查问卷中加入“你的 AI 功能每个用户任务的碳足迹是多少？”这类问题。大多数工程团队无法回答，因为从来没有人测量（Instrumented）过它。