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

一个平台团队发布了一次提示词重构，将平均响应成本降低了 32%。这个改动非常简单：剥离了 “解释你的推理过程” 前导语，要求模型仅返回 JSON 对象，并删除了从模型文本中解析推理逻辑的后处理步骤。仪表板变绿了。季度回顾中的单位经济效益页面从黄色变为了金色。平台团队中没有人想到要咨询风险团队，因为这个改动没有触及客户收到的任何答案。

两个季度后，一位受监管客户的审计员要求提供一份六个月前的贷款拒绝信的决策理由。团队调取了追踪记录。输入在那，输出也在那。推理过程消失了 —— 不是因为有人删除了它，而是因为它在重构发布的那天起就停止生成了。客户的合规计划一直运行在推理逻辑存储在追踪记录库中的假设之上；平台团队一直运行在推理逻辑不是任何人的问题，因为面向客户的答案没有变化的假设之上。孤立来看，这两个假设都是正确的。但结合在一起，它们让客户面临了一项监管违规审计发现，并让平台团队失去了一份合同续签。

产品团队发布了个性化功能。智能体（Agent）现在会直呼用户姓名，根据用户的偏好调整回答长度，了解用户在医疗行业工作，并尊重用户在提及日期时所处的时区。用户满意度的提升是真实且可衡量的——A/B 测试显示点赞率提升了四个百分点，随后功能全量上线。三周后，财务部门指出推理成本大约翻了三倍，而 AI 团队中没人能立即解释原因。

解释就在系统提示词（System Prompt）构建器中一行被埋没的代码修改里。每个用户的上下文——姓名、偏好的回答长度、行业、时区——都被添加到了系统提示词的开头，以便模型在每一轮对话中都能看到。这使得从第一个 Token 开始，每个用户的 Prompt 都是独一无二的。你的供应商提供的 Prompt 缓存——原本能以标准价格的十分之一服务大约 90% 的输入 Token——失效了。延迟几乎没有波动，所以性能仪表盘（Performance Dashboard）依然显示绿色。直到月底，计费仪表盘才反映出这一情况。

你的规划器输出了五次工具调用。从纸面上看，这是一个干净的解决方案：lookup_user、search_documents、call_external_api、spawn_sub_agent、request_human_approval。轨迹优雅、逻辑自洽，智能体最终也会给出正确答案。可在生产环境中，这五个步骤分别耗时 12 毫秒、800 毫秒、4 秒、2 分钟和 6 小时。规划器从未察觉，它这五步计划在成本上跨越了九个数量级。


这并不是幻觉。模型选对了工具，顺序也合理。它做不到的——工具模式根本没给它做这件事的途径——是去推理：计划的最后一步在性质上和第一步完全不同。在规划器眼里，工具就是工具，计划图中每个节点的权重都是 1。

六个月前,你的提示词前缀是 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 感知日志”的含义。