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

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

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

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

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

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

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

几乎每家持续交付 AI 功能的公司都会出现这样一种架构：流水线中的每一次转换、每一个路由决策、每一次分类、每一个格式化步骤，全都经过 LLM 调用。它通常始于一个合理的场景——LLM 确实解决了一个棘手问题。然后团队内化了这个模式，开始反复套用。直到整个系统变成一条 LLM 接 LLM 的链条：一串文字从一端进入，另一串从另一端出来，中间经历了十二次 API 调用，全程没有任何确定性可言。

这就是 AI 泛滥反模式，它现在已成为构建一个缓慢、昂贵且无法调试的生产系统的最可靠方式。

Prompt 缓存听起来是一个稳赢的方案：Anthropic 和 OpenAI 都宣传缓存命中可享受 90% 的折扣，且文档中展示了令人印象深刻的成本削减图表。团队实施了它，观察着缓存命中率计数器不断上升，并理所当然地认为自己在省钱。但实际上，有些团队支付的费用比完全不使用缓存时还要 多。

问题在于“写入溢价”（write premium）。每当你缓存一个前缀时，你都需要支付额外的费用——在 5 分钟的缓存窗口内是 1.25 倍，在 1 小时的窗口内是 2 倍。如果你的命中率太低，这些写入溢价的累积速度会超过读取折扣所节省的费用。缓存并不是免费的保险；它是你对自己流量模式下的一场赌注。

检查你代码库中每一次 LLM 调用里的 max_tokens 参数。如果你和大多数团队一样，这个参数要么没设置，要么设成了模型的最大值，或者是半年前随便选的一个像 4096 这样的整数，之后就再也没动过。它是 API 请求中一个显眼的预算旋钮，却在默默地为你从未使用过的冗余买单。

在中等商业模型上，输出 token 的成本大约是输入 token 的四倍，而在昂贵模型上甚至高达八倍。生成步骤的经济效益完全是失衡的：你在 max_tokens 中留下的每一分未使用的余量，都是你可能需要支付的成本；而且由于解码是顺序进行的，你生成的每一个 token 都会线性地增加你的 P50 延迟。然而，大多数生产系统都将此参数视为安全阀——设置得高高的，然后忘掉它，继续开发。

大多数团队选择 LLM 的方式就像选择数据库引擎一样：在架构评审时选一次，然后再也不改。你选了 GPT-4o 或 Claude 3.5 Sonnet，把它写进配置文件，然后上线。这个选择感觉无法逆转，因为更改它需要重新部署、跨服务协调，以及针对本周 eval 的回归测试。

这种思维方式是错误的。你的流量并不是同质的。"总结这篇文档"和"调试这个神秘堆栈跟踪"两个请求同时打到同一个接口，对能力的需求天差地别——但从静态模型选择的基础设施视角来看，两者毫无区别。你要么对其中一个过度供给，要么对另一个供给不足，而且每一个请求都是如此。

模型路由将 LLM 的选择视为运行时分发决策。每个进入的查询都会根据能预测该请求最合适模型的信号进行评估，并据此进行分发。路由层不存在于配置文件中——它运行在你的请求路径上。

大多数团队只有在账单出现时才会发现重试问题。智能体（Agent）“运行正常”；延迟仪表盘保持绿色；错误率看起来也没问题。然后财务部门询问为什么本月的推理支出翻了一番，这时才有人终于去翻看日志。结果发现，一个 3 步操作的智能体中，20% 的工具调用在静默重试，每次重试都重放了完整的提示词（prompt）历史记录，而账单已经连续几周在攀升。

这背后的数学逻辑并不神秘，但极其反直觉。20% 的单步重试率听起来还可以接受 —— 大多数工程师看一眼就会忽略它。但一旦考虑到现代智能体框架的重试方式，实际的 Token 成本会更接近 2 倍而非 1.2 倍。而且，这种失败模式对于团队通常关注的每一项指标都是不可见的。

重试预算（Retry budgets）—— 这是一个源自 Google SRE 工作的旧概念 —— 是最简洁的解决方案。但该模式的 LLM 版本需要调整，因为 Token 的行为方式与 RPC 不同。

大多数团队发布第一个 AI 功能时都会使用最好的模型，因为演示（demo）就是在那上面跑的，而且没人有时间深入思考。接着第二个功能也用了同样的模型。然后是第三个。六个月后，每个功能的每次调用都指向了前沿层级（frontier tier）——而账单比实际需要的数额高出五到十倍。

令人不安的事实是，你的生产系统处理的 40%–60% 的请求根本不需要前沿级别的推理。它们只需要称职的文本处理。而购买称职的文本处理服务的成本要低得多。

2021 年，GPT-3 的价格是每百万 token 60 美元。到 2026 年初，同等性能的模型只需 0.06 美元。三年内降价 1000 倍。与此同时，企业 AI 支出增长了 320%——从 115 亿美元攀升至 370 亿美元。而在 AI 上花费最多的那些组织，恰恰正是从价格下降中受益最大的那批人。

这并不矛盾。这就是杰文斯悖论（Jevons Paradox），而它正在侵蚀你的 AI 预算。

几乎每个 AI 产品在达到数十万活跃用户时都会出现一种模式：团队开始增加个性化——在每个 Prompt 中注入用户历史、偏好信号和行为数据——然后看着产品略微变好，而基础设施账单却大幅增加。当他们最终拉取日志并衡量每增加一个 token 带来的质量增量时，曲线的形状几乎总是一样的：早期增益陡峭，随后进入漫长的平台期，最后是你支付全价却只能换来微乎其微的回报。

大多数团队只有在深陷泥潭时才会进行这种分析。这篇文章将探讨为什么这个陷阱会存在，个性化在何处停止产生回报，以及在生产环境中真正有效的架构是什么样的。

微软的 Copilot 发布时讲了一个清晰的故事：每用户每月 30 美元，生产力倍增。但实际的账单却丑陋得多。一旦将企业基础许可证成本、每个活跃用户的算力成本以及支持运维开销合并计算，微软每个用户每月亏损超过 20 美元。财务部门没有立即发现这个问题，因为这些成本挂在基础设施预算下，而不是产品损益表里。工程团队知道 Token 账单数额庞大，但没有人把这两条线连接起来。

这正是大多数 AI 团队在构建产品时不知不觉埋下的计费问题。这不是定价策略问题——那是产品决策。这是一个工程问题：你没有任何基础设施来衡量 AI 功能在每个客户、每个功能、每个请求粒度上的实际成本，而任何定价模式的运转都需要这种精度。

大多数团队都是以同样的方式发现请求合并的：收到一张出乎意料的大额账单。他们上线了基于 LLM 的功能，使用量增长，然后账单仪表板显示他们每天为五万个请求付费，而仔细观察后发现其中大约三万个请求在问同一件事，只是措辞略有不同。每一个"总结这份文档"的改写都单独命中了模型。每一个近乎重复的请求都触发了完整的推理周期。成本随流量规模线性增长，而不是随用户实际想要的语义多样性增长。

请求合并正是解决这一问题的模式。它不是单一技术，而是一种分层架构：用于防止并发重复的飞行中去重、用于重复相同提示的精确缓存，以及用于捕捉中间改写变体的语义批处理。顺序很重要，阈值很重要，理解该模式何处会失效——尤其是围绕流式传输——是可用实现与那种在暂存服务器上节省了钱但在生产中引发隐蔽 bug 的实现之间的差别所在。