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

你的应用程序开启了一个包含 4 万 token 系统提示词和完整工具库的长对话。第一轮对话按写入费率为前缀付费，且提供商的 KV 缓存（KV cache）开始预热。第二轮对话在 90 秒后到来。你假设这会命中缓存。有时确实如此。但有时，同样的 4 万 token 会再次以未缓存的价格出现在你的账单上，而你的代码在第一轮和第二轮之间没有任何改动。

改变的是别人的流量。KV 缓存是共享基础设施。你的租户被分配到一个推理节点上，而在你的两轮对话之间的 90 秒内，该节点接纳了足够多的其他租户，从而将你的前缀从内存中驱逐。提供商的控制台会将其描述为“缓存压力（cache pressure）”。你的财务团队会将其描述为一项翻倍的支出项。这两种描述都是准确的，但原因都不在你的代码里。

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

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

发布说明只有两行。“改进了多语言分词（Tokenization）。模型输出无破坏性变更。”一共不到二十个字。你的评估（Evals）确认了这一点：相同的提示词，相同的生成内容，相同的评分。你的平台团队在周五下午批准了升级。到了周二早上，你的缓存命中率从 80% 下降到 4%，每日推理费用翻了两番，而凌晨 6 点把你叫醒的轮值工程师在你的代码里找不到任何一行改动。

你的代码确实没有任何改动。但服务商发布了一个新的分词器，它对某个 Unicode 字符的一个字节划分与旧版本不同。你系统中每个缓存的前缀现在都是基于一个已不再存在的 Token 序列生成的指纹。模型的表现完全一致 —— 这确实是事实。但发布说明中未曾提及的缓存层，却为此付出了全额代价。

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

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

你教会了 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 窗口的模型，在实际任务上的准确度也会出现两位数的下降。你在花更多的钱，让模型更差地去思考它在三轮前就已经解决的问题。