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

我在上个季度交谈过的一个团队在财务伙伴指出 AI 账单时陷入了短暂的恐慌。他们原以为，像大多数团队一样，昂贵的支出项会是生成——即聊天、总结和智能体推理背后的 GPT 级调用。事实并非如此。他们的每月 Embedding 支出在 1 月悄然超过了生成支出，到 3 月翻了一番，并有望在年中翻两番。没有人为此建模，因为 Embedding 模型的每 Token 定价看起来就像舍入误差：小型模型每百万 Token 2 美分，大型模型 13 美分。按照这个费率，谁会为此做预算？

答案是：任何产品度过了原型阶段并开始大规模索引内容的团队。在不断增长的语料库上进行语义搜索、重复检测、分类、聚类、更换模型时的重新索引——每一个工作负载消耗的 Embedding Token 都是以十亿计，而不是以百万计。与受用户请求限制的生成不同，Embedding 的吞吐量仅受你决定索引的内容限制。而这一决定很少经过成本审查。

本篇文章将探讨 Embedding 支出升级的具体机制、改变成本曲线的架构杠杆，以及从托管 API 转向自建服务的盈亏平衡计算。

你的智能体刚刚花了 90 秒和几美元来修改一个只有三行代码的函数。在提交编辑之前，它列出了两个目录，打开了测试文件，运行了 grep 来查找调用者，读取了配置模块，检查了 CI 工作流，还调出了一个从未用过的类型定义。它产生的 diff 只有四行，而产生这个结果的 trace 却包含了 43 次工具调用。

这就是“首触工具损耗”（First-touch tool burn）：一种当智能体被分配了一个范围明确的任务时，却表现得好像每个请求都是一个研究课题的模式。探索行为先行且力度极大 —— 在向文件写入单个字符之前，60% 到 80% 的 token 预算都花在了列出目录、grep 和读取上。团队在第一次查看 trace 时发现了这一点，并意识到智能体为一个两分钟的任务做了相当于两小时的入职培训。

这种行为并非某个特定模型的 bug。它是这些系统的训练和评估方式的必然产物，与生产环境发生了碰撞。而生产环境衡量的是训练从未衡量过的东西：这项工作是否便宜到值得去做的程度。

强化思维在处理新颖的推理任务时表现出色。但在工具边界（即你的智能体必须选择调用哪个函数、何时调用以及传递哪些参数的时刻），同样的思维预算往往会适得其反。模型会权衡三个等效的工具，而快速模型原本只需要一个 token 就能消除歧义。它在原本不存在歧义的地方制造出听起来合理的歧义。它消耗了一千个推理 token 来反复质疑那个显而易见的 search 调用，结果最后还是调用了 search。你为一个不需要推理的决策支付了推理税。

这是 2026 年智能体系统中隐形的成本中心：问题不在于推理模型本身（其擅长领域的定价是合理的），而在于在错误的环节部署了推理模型。这种反模式（anti-pattern）就潜伏在显而易见的地方，因为顶层任务看起来很难（如“回答用户的问题”），所以团队将整个循环都包裹在深思熟虑的模式中，却从未意识到 80% 的思维预算都花在了对工具选择的微观决策上，而这些决策模型凭第一直觉就已经选对了。

打开一个智能体在长程规划任务中的追踪记录（trace），数一数模型写了多少次“让我重新考虑一下”、“经反思”或“更好的方法是”。现在，将它最终确定的计划与最初起草的计划进行对比。在我审计过的大多数追踪记录中，第二个计划其实就是换汤不换药的第一个计划 —— 同样的分解方式、同样的工具调用、同样的操作顺序，只是重命名了一些步骤标签并重新组织了理由的措辞。反思确实运行了。模型输出了看起来像是在重新考虑的 token。但计划本身纹丝不动。

这很重要，因为“带有反思”已悄然成为一种质量等级。团队在发布规划器时会加入一轮、两轮或三轮反思，并为此支付额外的成本。推理开支是真实且可衡量的。但计划层面是否真的发生了改变，几乎没有人去进行检测，而答案往往是：没有。

一个团队发布了一款支持聊天机器人。在测试阶段，每月账单看起来还在可控范围内——工程团队演示期间仅花费了几百美元。上线三周后，发票寄到了：4.7 万美元。没人虚报 Token 数量，也没人算错账。生产环境的工作负载与他们模拟的完全不是一回事。

这种模式在不断重复。团队估算 LLM 成本的方式就像估算数据库查询成本一样——通过测量一个典型的请求并乘以预期访问量。这种思维模型在 LLM 上彻底失效了，因为两个最大的成本驱动因素（输出 Token 长度和工具调用开销）是在推理阶段决定的，其行为在设计阶段无法完全预测。

本文讨论的是如何在发布前进行更好的预测，而不是在账单到期后如何优化。

你的产品路线图写着“进军日本和巴西市场”。你的财务模型显示 LLM API 支出项为每月 $X。这两个数字都是错的，而且你直到国际化推广前几周才会发现这一点。

Tokenization（分词）——将用户文本转换为模型可处理的整数的步骤——对英语有着深刻的偏向。一段日语文本所需的 Token 数量可能是同义英语句子的 2–8 倍。这个倍数直接影响到 API 成本、上下文窗口余量和响应延迟。那些根据英语基准测试来模拟 AI 预算，然后直接切换语言选项的团队，通常会被比预期高出 3–5 倍的账单吓一跳。

当你的团队第一次启用提示缓存时，感觉就像凭空得到了钱。几小时之内，token成本下降了40–60%，延迟也随之缩短。工程师们欢欣鼓舞，然后继续前行。三个月后，有人注意到成本悄悄地爬回去了。从72%起步的缓存命中率现在只剩18%。没有人故意破坏它，没有人注意到。

这是生产LLM部署中最常见的轨迹：缓存只被启用一次，从不被监控，随着代码库的演进而悄然退化。缓存命中率是LLM技术栈中最具影响力的成本杠杆，但大多数团队把它当作一次性的设置任务，而非生产指标。

一家中型 SaaS 公司的团队在阅读了一些基准测试后，在每个提示词中都加入了“让我们一步步思考”（let's think step by step）。他们的响应质量有了明显的提升——但他们的 LLM 账单也翻了三倍。当他们深入研究日志时，发现大部分额外的 Token 都花在了支持单分类和会议记录总结等任务上，而在这些任务中，额外的推理对输出质量并没有明显的改善。

扩展思考模型对于难题来说是真正的能力飞跃。但如果不加区别地应用，它们也是一个可靠的成本陷阱。一个经过良好调优的推理部署与一个昂贵的部署之间的区别通常归结为一点：理解哪些任务真正受益于思维链（chain-of-thought），而哪些任务只是在为显而易见步骤的冗长叙述买单。

每个构建AI Agent的团队都会做同样的粗略计算：用预期的工具调用次数乘以每次调用的成本，再加上一点缓冲。这个估算在离开白板之前就已经错了——不是错了10%或20%，而是错了5到30倍，具体取决于Agent的复杂程度。40%的Agentic AI试点项目在达到生产阶段之前就被取消，而推理成本失控是最常见的单一原因。

问题是结构性的。单次调用成本估算假设每次推理是独立的。在多轮Agent循环中，它们并非独立。每次工具调用都会增大后续所有调用必须支付的上下文。结果是一条二次方成本曲线伪装成了线性曲线，工程师们直到账单到来才发现这一点。

一个拥有 7.7 亿参数的模型在它擅长的任务上击败了一个拥有 5400 亿参数的模型，这听起来似乎是不可能的。但这正是经过蒸馏的 T5 模型在对抗 few-shot PaLM 时所取得的成就——仅使用了 80% 的训练样本，模型尺寸缩小了 700 倍，且每次推理成本仅为几分之一美分，而不再是数美元。这其中的秘诀并非更好的架构或更巧妙的训练方案。而是利用大模型生成标注数据，并用这些数据来训练小模型。

这就是知识蒸馏（Knowledge Distillation）。而且，你并不需要通过微调教师模型来使其生效。

大多数工程团队在第一次收到账单暴涨时都会发现同一件事：他们的系统提示词已经悄悄增长到4,000个token的精心指令，而模型也悄悄开始忽略其中一半。解决方法很少是添加更多指令，几乎总是删除它们。

追求面面俱到的本能是可以理解的。更多约束感觉像是更多控制。但随着系统提示词膨胀，存在一种可量化的质量下降——而且它与成本的复合方式在造成损害之前并不明显。研究一致发现，在大约3,000个输入token处准确率开始下降，远在达到任何名义上的上下文限制之前。模型不会拒绝遵守；它只是开始以难以查明的方式表现不佳。

本文的目的是使这种退化变得可见，理解其发生原因，并建立一套不需要寄希望于"不会出问题"的精简规范。

某中型 SaaS 公司的团队六个月前部署了一套模型路由器，目标明确：不再为 70% 的简单查询和格式转换任务支付前沿模型的高昂费用。他们运行了三个月，直到有人做了一道算术题。总推理成本上涨了 12%。

路由器本身并不贵——一个轻量级分类器，每个请求增加约 2ms 的开销。但分类器的决策边界校准有误：它将 60% 的查询升级到了昂贵模型，而非预期的 30%。那 40% 在本地处理的请求质量较差，导致用户重试率上升，进而拉高了总请求量。路由器的遥测数据显示"路由运行正常"，因为它确实在路由——只是路由得不好。

这种失败模式远比成功案例更为普遍。以下是如何构建真正能省钱的路由系统。