76 篇博文 含有标签「cost-optimization」

六个月前,你的提示词前缀是 4,000 tokens。它稳定、缓存预热,几乎可以摊销到不计成本——系统指令的每次调用附加费,相比每次响应的成本,只是一个舍入误差。今天那个前缀变成了 11,000 tokens,你的缓存命中率从 92% 滑到了 31%,你的推理账单上升了 4 倍。团队里没有人能指出是哪个 PR 干的。没有一条 commit message 写着"将提示词增加 7,000 tokens"。每一次修改都很小,每一次修改都有理有据,每一次修改都干干净净地合入了。

提示词前缀长出胳膊和腿,就像地下室积攒纸箱一样。一个团队需要注入用户的订阅等级,这样 agent 才能解释套餐限制。另一个团队需要用户时区的今天日期,这样"明天提醒我"才能工作。第三个团队把当前 A/B 变体名硬塞进去,这样 eval traces 才能切片。市场团队加进了当前促销 banner,这样 agent 才能适时提及它。合规团队加进了功能标志清单,这样模型才能拒绝那些不在灰度名单里的用户访问 beta 功能。每一条都是一行的添加。每一条单独看都站得住脚。但加起来摧毁了你的缓存。

部署在 Web 集群前的负载均衡器之所以有效，是因为每台机器都会上报信息：CPU、队列深度、错误率、延迟。均衡器根据这些负载信息进行路由。模型路由器（Model Router）则拿不到这些遥测数据。它在模型执行任何操作之前，仅凭查询内容就决定由哪个模型来处理。路由器根据提示词（Prompt）预测难度。但真正的难度只有在生成答案时才会显现。当信号产生时，路由决策已经过去三秒钟了，而廉价模型可能已经向你的用户发送了一个自信但错误的回复。

这是模型路由核心的结构性缺陷，但大多数团队在发布路由器时从未这样审视过它。他们将其视为一个分类器——训练一个模型将查询标记为“简单”或“困难”，在预留集上进行验证，当准确率超过 90% 时就发布。分类器的隐喻在关键之处是错误的。分类器预测的是一个已经存在的标签。而路由器预测的是一个尚不存在、直到被路由的模型给出答案后才会存在、且可能永远不会以足够干净的形式存在以便学习的标签。

打开任何一个生产环境智能体的 trace，看一看在用户提问和第一个真正有用的动作之间到底跑了哪些工具调用。你会看到一个 get_user_profile 返回了一个根本没人用的名字、一个 check_status 返回绿色然后再也没被引用、一个 list_recent_orders 的结果被总结成"ok"然后直接丢掉。这些调用没有一个改变了最终答案。但每一个都花了真金白银的钱、真实的延迟，以及在 trace 里真实占一行。你的智能体已经学会了表演勤奋——而表演勤奋如今是你最大的单一浪费来源。

这就是填充式工具调用：智能体发出一个动作，不是因为它需要那个结果，而是因为"先想一想，再行动"的整体模式在训练时被反复奖励，多到模型现在会把"显得周全"当作回答任何问题的副作用来执行。这是一个 LLM 版本的初级分析师，故意打开五个根本不会读的标签页，好让坐在对面的高级同事看到自己很忙。区别只在于：初级分析师会累。智能体永远不会。

一次 10 轮的对话成本并不是单轮对话的 10 倍，而是接近 55 倍。这是大多数团队在建模 AI 功能的单位经济效益（unit economics）时最容易犯的错误，也是为什么一个在表格上看起来有利可图的产品在生产环境中却在不断亏钱的原因。

错误在于将对话视为一系列独立的请求。事实并非如此。由于 LLM API 是无状态的，每一轮对话都会重新发送累积的全部历史记录。第一轮发送 1 个单位的上下文，第二轮发送 2 个，第十轮发送 10 个。整个会话中计费的总 Token 数是 1 + 2 + ... + N 的总和，其增长趋势为 N²/2 —— 即平方级增长 —— 而你的产品几乎肯定收取的是固定的线性价格。

那些最喜欢你产品的用户，正是那些进行最长对话的用户。他们也是在悄无声息中摧毁你利润空间的人。

财务团队指出，本季度的 LLM 账单上涨了 18%。一名工程师调出使用情况仪表板，发现 70% 的流量现在流向了经济型模型（budget model）而非前沿模型（frontier model），他感到有些困惑：路由更改本应是为了削减开支。每 token 价格确实如电子表格预测的那样下降了。但账单还是上涨了。

这不是计费错误。这是成本优化在悄无声息中发生逆转的最常见方式。证明降级合理的电子表格衡量的是一件事——token——而生产系统支付的是完全不同的另一件事：完成的任务。较弱的模型不仅仅是产生更便宜的 token。它还会改变其周围每个组件的行为，而这些二阶效应最终都会反映在同一张发票上。

这个陷阱非常诱人，因为一阶数学逻辑确实是正确的。经济型模型的每 token 价格可能比前沿模型便宜 10 到 30 倍，且对于大部分流量，它返回的答案在质量上是难以区分的。错误不在于路由决策。错误在于在错误的边界衡量路由决策。

按 token 付费的心智模型训练了一代工程师，让他们认为 AI 成本是使用量的函数。没有请求，就没有账单。这是一个令人慰藉的模型，对于 API 调用本身而言，这基本属实。但它只描述了生产级 AI 功能的一个层面，而并非那个悄悄吞噬预算的层面。

预置吞吐量、预留 GPU 容量、预热向量索引以及待机微调端点都是按时长计费，而不是按计数器计费。无论流量是否到来，它们都为你提供服务流量的权利而收费。即便周六没人碰某个功能，计费表依然在转动。在办公时间内由 12 个人使用的内部工具，每周 168 小时都在计费。你为了 3 月份发布而准备的资源预置，在 5 月份流量洪峰平息很久之后，依然占据着预留额度。

这就是闲置成本。它之所以野蛮生长，原因并非技术层面，而是组织层面：没有一个单一的角色能看到它，也没有一个单一的角色负责它。

一个团队将自我批判循环（self-critique loop）投入生产，因为基准测试数据看起来令人无法拒绝：Self-Refine 报告称在七项任务中平均提升了 20% 的绝对性能，Chain-of-Verification 在问答任务中将幻觉减少了 50% 到 70%，而在一篇被广泛引用的论文中，反思提示词（reflection prompts）将数学方程的准确率提高了 34.7%。一个月后，财务审查揭示了账单。产品的单次请求成本大约增加了三倍，p99 延迟增加了三倍，而实际在生产流量中表现出的质量提升更接近 3% 而非 30%。自我批判循环确实做到了它宣传的效果，只是团队从未计算过它的代价。

这就是自我批判税：一种在 PPT 上看起来像是免费提升质量，但在发票上却表现为结构性成本增加的可靠性模式。模式本身是合理的——在某些实际情况下，“生成并验证”确实是正确答案。失败的原因在于将其作为默认配置而非经过校准的干预手段进行部署，并在季度的错误时间点发现“模型检查自己的工作”实际上是一项采购决策。

由财务主导的“切换到更小模型”的指令，是让你的 LLM 账单季度环比增长最可靠的方式之一。采购团队盯着的仪表盘——单次调用成本、每次请求的平均 token 数——一直在下降。与此同时，发票金额却在不断攀升。当有人终于把这两者对上账时，团队已经花了六个月的时间进行提示词（prompt）迭代，以补偿那个在任务处理上表现更差的模型，而且团队已经陷得太深，如果不承认最初的切换是个错误，就无法走回头路。

错误不在于定价，而在于计量单位。当推理深度、重试次数和提示词大小都随模型而异时，单 token 价格是一个具有误导性的维度。正确的指标是“单次成功完成所需的 token 数”，在这个维度上，更便宜的模型往往会输。

我在上个季度交流过的一个团队花了六周时间追踪其智能体（agent）平台上的内存压力报警。这些智能体的运行成本很低——每次运行只需几美分。但追踪（trace）却不是。他们的遥测流水线消耗的预算是其所监测的 LLM 调用预算的三倍，而且大部分支出都花在了几个月没人看过的字段上：每个 span 上存储的完整 prompt 正文、在父级和子级追踪中重复出现的工具输出，以及一个在每次捕获的追踪上重新支付推理费用的 LLM-judge 评估器。

这是 AI 可观测性成本危机的缩影。一份 2026 年的行业报告模拟了一个拥有 10,000 个对话且每个对话有五轮互动的客户服务机器人——这相当于每天 200,000 次 LLM 调用、4 亿个 token，以及大约 100 万个追踪 span。Datadog 用户广泛报告，在处理其 REST API 的相同后端上监测 AI 工作负载后，可观测性账单飙升了 40-200%。流水线在为同样的 token 支付两次费用：一次是为了生成它们，一次是为了记住它们。

解决方法不是“减少日志”。解决方法是将 AI 系统的可观测性视为一种具有自身单位经济效益的工作负载，与传统服务发出的请求-响应遥测分开处理。传统日志是你可以压缩并遗忘的结构化字段；AI 日志则是无限制的文本正文，每当有人读取它们时，就会重新计入推理预算。这种区别就是“Token 感知日志”的含义。

每个上线 AI 功能的工程团队最终都会碰到同一堵墙：财务部门要看一份证明支出合理性的表格，但你做的那份根本行不通。

问题不在于 AI 功能缺乏 ROI，而在于 AI 的经济逻辑打破了标准 ROI 模型的每一个假设——固定资本、线性成本曲线、可预期的回收时间线。把 AI 支出当作 SaaS 许可费来处理的团队，要么在上线前看到虚高的数字，要么在投产六个月后看着数字崩塌。有计划的 AI 项目（ROI 达 55%）与随意部署的项目（ROI 仅 5.9%）之间近十倍的差距，几乎完全来自于团队是否在上线之前就建立了正确的度量模型。

当你的AI功能上线时，你会制定延迟预算：模型调用需要多长时间、检索需要多长时间、完整请求的p99是多少。但你几乎可以肯定没有为那些在没有用户观察时发生的推理制定预算。

每个拥有持久化状态的AI产品都在后台运行不可见的工作。文档在上传时被预处理。长对话在会话边界处被重新摘要，以防下一个会话撑爆上下文窗口。主动建议按照没人刻意设定的计划表被生成。当有人更新模式时，嵌入向量被重新生成。这些都不会出现在你的延迟仪表盘上，通常也不在你的成本模型中，几乎从未被监控到。

这就是你AI产品的暗能量——那些解释了你的推理账单"应该是多少"与"实际是多少"之间差距的计算。

大多数 AI 流水线（pipelines）在编写时，都好像每一个请求都值得进行一次完整的 LLM 调用。用户提交一条消息，流水线将其传递给模型，等待响应并返回——每一次都无条件地如此操作。这虽然可行，但既昂贵又缓慢，而且通常是不必要的。

实际上需要完整 LLM 推理的请求比例比大多数工程师预想的要小。关于 token 级别路由的研究表明，1.5B 和 32B 参数模型之间只有约 11% 的 token 存在差异，且只有 4.9% 的 token 是真正的“发散性”的——这意味着如果由较小的模型处理，它们会改变推理路径。生产环境中的语义缓存显示，65% 的传入流量在语义上与流水线已经回答过的内容相似。这些并不是边缘案例。它们占据了流量的大部分，而你却在为处理它们支付全额费用。

解决方法是惰性求值（lazy evaluation）：在确认确实需要昂贵模型之前，不要调用它。