正在加载，请稍候
同一批任务、同一个模型，账单能差近 7 倍。2026 年三项基准测试指向同一结论：先处理框架启动税与缓存命中，模型选型放在最后。
同一批任务、同一个模型，两个团队的月度账单能差近 7 倍。差距不在模型选型，而在编排框架每轮固定携带的启动税，和网关路径决定的缓存命中。
2026 年公开的三项基准测试把这件事讲清楚了。对做预算的人来说，坏消息是便宜模型救不了失控的账单；好消息是最大的两个漏洞都在软件侧，改起来比换模型更快、更可逆。
2026 年 8 月，Composio 用同一个模型跑了 8 种智能体框架、30 个企业工作流，共 240 次任务执行，其中 129 次成功。评分由程序化验证器给出，测试数据隔离并预置了干扰项。结果：每次成功完成任务的美元成本，最低一档 0.028，最高一档 0.195。另一种框架的通过率与最贵那档完全相同，但每次成功执行的成本只有它的四分之一。
6 月的另一项测试把样本扩到 12 种配置，跑在相同任务、相同 API 之上。它衡量的是用量（Token）而不是金额：每解决一个任务，消耗从约 3,500 到 292,000，跨度超过 80 倍。Artificial Analysis 的编码智能体指数覆盖面更大——326 项任务，每项跑三次取平均，同时报告单任务成本、用量与耗时。
三项测试的方法各有取舍，指向却一致：框架这个软件层对账单的影响，量级上不小于模型权重本身。逐条拆解见 InfoQ 对三项测试的复盘。至于网关本身被并入支付平台之后怎么改写采购账，我们在 模型网关结算一体化 里单独谈过；那一篇解决的是买什么，这一篇要解决的是钱花在哪一步。
6 月那项测试提出了一个指标：启动税。在模型开始处理任务之前，框架先把自己携带的负担发过去——系统提示、工具说明、环境配置。最省的一档约 700，最重的一档约 26,000，相差约 40 倍。
单次支付还能忍，问题是它每一轮都重复。一个每轮至少携带 26,000 输入、连续跑 15 轮的任务，光脚手架就要吃掉约 390,000 输入量，而模型真正读到的任务内容可能只有几千。
作者把「启动税 × 轮数」直接拿去预测每个已解决任务的用量，在两个互不相关的模型上，决定系数 R² 都是 0.99。这个数字的含义很直接：想压账单，先看提示词的最低开销和轮数，再谈更复杂的优化。
这里有一条我们自己的教训。上半年评审一个内部工具链项目时，我们把框架开销当成固定成本，优化精力几乎全押在模型选型上——比价、换供应商、谈折扣。看完 6 月那组数据才发现方向反了：同一批配置换到另一个模型，框架之间的排名几乎没有变化，说明差异出在软件侧而不是模型行为。后来我们把动作顺序倒过来——先砍工具说明里的冗余条目，再合并重复的确认轮次，模型反而是最后才动的一环。
第二个机制更隐蔽。Composio 披露，某款 CLI 编码工具的输入只有 1.5% 来自缓存，Codex 约 70%，另一款工具约 57%。未命中缓存的输入，价格约为命中部分的五倍。
于是出现一种反直觉的账单：用量相当的两个框架，实际支出差一截。6 月测试中，Codex 在某个模型上为整套测试计费超过 100 万，其中 77% 是缓存读取、按约十分之一计价；按真实账单核算，它每解决一个任务反而更便宜，尽管原始用量只有对手的一半。
作者把原因归到服务路径而非提示词：那款命中率极低的工具，是唯一通过 Anthropic 风格 messages 端点接入的，网关做协议转换后命中率被拉低；同样的流量走 OpenAI 风格端点原本可以有更高命中率。测试方也提示，网关行为会变，这应被当作一条实测路径而非通用结论。
对做预算的人，实操含义是：网关不只是一层转发，它决定缓存能不能命中，而命中率直接改写单价。
如果暂时不想改框架代码，最便宜的一层是网关配置。三件事值得先做：
两个容易忽略的细节：限额是最终一致的，当前请求的成本在完成后才记账，并发突发可以短暂超出上限；如果要自建路由层，LiteLLM 一类的方案已经内置轮询、权重、最低成本、延迟优先、限流感知等策略，用 Redis 跟踪冷却与用量，并支持失败回落、超时与退避重试——这些是配置项，不必自己写。
补一个规模参考。蚂蚁在 QCon 上海 2026 分享的执行边界实践里，成本治理落在 CPU 超卖、混部、空闲回收、缓存池容量控制与配额计量上，支撑的是数万级每日沙箱创建与千万级日请求。该场分享的公开摘要值得架构负责人读一遍。
把手段摊开看，作用点和代价并不一样：
| 手段 | 作用点 | 生效速度 | 代价与风险 |
|---|---|---|---|
| 精简启动税 | 系统提示与工具说明 | 周级，需改代码 | 工具说明砍过头会拉低工具选择的准确率 |
| 压缩轮数 | 编排与确认逻辑 | 周级 | 过度压缩会伤长任务成功率 |
| 提高缓存命中 | 端点协议与网关路径 | 天级 | 换端点可能带来能力差异 |
| 金额限额 + 降级路由 | 网关配置 | 小时级 | 最终一致，突发时短暂超限 |
| 换更便宜的模型 | 模型选型 | 小时级 | 要重跑评测，质量可能下滑 |
按「生效速度 × 可逆性」排序即可：网关限额和降级路由先上，可逆、当天见效；再动框架开销，它不可逆性更高、需要重跑评测；模型选型放最后，因为它常常只是看起来最省事的那一步。
通常不行。6 月与 8 月两组数据都显示，同一批配置在模型之间迁移时，框架之间的相对排名基本稳定，差距来自软件侧。换模型可能让单价下降，但如果框架每轮还在多发两万多输入，账单不会同步下降。这与我们在 企业 AI 应用采购策略 里的结论一致：供应商格局变化时，先改口径，再改选型。
先按维度分桶，而不是设一个总量。按用户或按智能体分桶能定位异常消耗方，按模型分桶能锁住昂贵模型的敞口。同时记住限额是最终一致的，不要把并发峰值场景下的上限当硬保证。
不是。8 月那组数据里，通过率从 46.7% 到 66.7% 不等，成本最低的一档并不是通过率最高的一档。真正的判断标准是「每次成功执行的成本」，而不是「每次调用的成本」——失败重试很贵。
至少要能看到缓存读取与未命中输入的分开计价。如果供应商只给总量，就无法判断服务路径是否在拖低命中率，这也是选网关时一个具体的评估项。
调用集中在单一供应商、月度支出可控时，网关的收益主要来自可观测性而不是省钱。一旦出现两个以上供应商，或者有按智能体、按团队分账的需求，它就从可选项变成必需项。如果已经在自建平台，可以顺带对照一下 私有化部署的高可用取舍，避免把网关做成单点。
如果你正在给智能体项目做成本核算，建议先按「启动税 × 轮数」和「缓存命中」两个口径把现状量出来——多数团队的结论会推翻自己的第一直觉。口径拿不准，可以把你们的框架清单与轮数统计发给我们，蓝曜炬辉（www.lanyaoai.com）按同一口径帮你复算一遍，再判断该动网关还是动代码。