正在加载，请稍候
Web 端 AI 产品的账单大头往往不在词元单价，而在每轮都被重新计费的会话上下文。用二次方增长模型、三个可测公式和六个成本科目，把成本测算做成上线前的工程护栏。
Web 端 AI 产品的账单里，真正失控的部分通常不是词元单价，而是每一轮都会被重新计费的会话上下文。
很多团队把预算做成「单价 × 预计请求数」，上线第一个月还对得上，第三个月开始对不上。偏差不在供应商报价，而在 Web 这个形态本身：会话是长连接的，历史要回传，用户可以在浏览器里无限追问。我们在 小程序端的成本账里看到的规律类似，但 Web 端因为会话更长，乘数效应更明显。
Fireworks 研究团队在 2026 年 9 月发布 Ember-1 时给出了两条关键观察。第一，推理模型有时会把超过 90% 的生成词元花在内部推理上。第二，多轮智能体负载的上下文会随轮数大致呈二次方增长——早期轮次的长轨迹会在后面每一次调用里被重新读取、重新计费。
把这两条放进 Web 场景，结论很直接：成本更接近「轮数² × 每轮新增内容」，而不是「请求数 × 单价」。Fireworks 的发布说明选择从模型侧解决——通过后训练让推理轨迹更紧凑，以约少 40% 的词元达到同档质量，而不是简单调低推理强度。值得注意的是，这个「调低推理强度」的代价并不小，推理强度校准的实测结论正好可以作为对照。模型侧的改进值得关注，但它不解决架构侧的浪费。
把账单拆开看，单价只占其中一项。下面六个科目是我们在实际项目里逐条核对过的。
| 科目 | 计费口径 | Web 端典型诱因 | 可控手段 |
|---|---|---|---|
| 会话上下文回传 | 按输入词元，每轮全量重算 | 长连接会话、无限追问 | 摘要压缩、检索替代全量回放 |
| 内部推理 | 按输出词元 | 所有任务不分级都走旗舰档 | 按难度路由不同模型 |
| 重复工具调用 | 按调用次数与结果词元 | 前端触发的重复动作 | 调用去重、次数阈值告警 |
| 失败重放 | 按重放的整段上下文 | 限流、超时、网络抖动 | 幂等设计、断点续跑 |
| 检索与向量库 | 按存储与查询次数 | 全库召回、无缓存 | 分层召回、热数据缓存 |
| 边缘出网 | 按带宽与长连接并发 | 流式输出常驻连接 | 压缩、就近接入、按需断连 |
前四项都跟「回传的历史」和「重复的动作」有关。这也是为什么单纯换一个更便宜的模型，通常只能把总账压下去一成到两成——它动的是单价，没动乘数。
三个公式里最有用的其实是第三个。它把「便宜」和「可靠」放进同一个数，避免为了省词元把成功率压下去——那种省法在下一轮会被重放成本加倍还回来。
2026 年 9 月 27 日，小米公开了 MiMo-V2.6 工具调用重复问题的技术复盘，里面有一组少见的成本数字。官方内部评估显示响应级重复率超过 0.05%，且不同执行框架之间差异明显：OpenCode 下 Flash-RL 为 1.02%、Pro-RL 为 0.54%，而 Codex 下分别是 0.23% 和 0.07%。
回放强化学习各阶段的检查点后，团队发现调用泛滥率随训练从 11.1% 升到了 24.6%，原因是 32 次调用这个惩罚阈值定得过宽。看起来改一个阈值就行，实际上直接调低阈值需要重启 20 步 MixRL，估计成本 231 万美元，而内部测试里重复率只从 13.45% 降到 3.83%。最终他们换了另一条路线，把修复成本压到该方案的 4%。小米的完整复盘给出了归因实验的全过程，值得逐段读。
这个案例对做成本测算的人有两层意义。第一，重复调用是真实存在的隐性账单，而且与执行框架强相关——同一个模型换一个 harness，重复率可以差一个数量级，所以「换个框架更省钱」这种判断必须用实测数据支撑。第二，修复方案自身的代价也要进成本模型：要按「改一次花多少 + 改完每个周期省多少」来算，而不是只看当期账单。
顺序建议如下，前三步一周内就能落地。
作为价格参照，Arena 在 2026 年 9 月 26 日记录 Claude Opus 5.5 (High) 的混合价格为每百万词元 16 美元、进入文本榜 Pareto 前沿（Arena 榜单快照）。旗舰档的价格带仍在这个量级，这意味着一次结构性的浪费就足以吃掉整月的预算弹性。
先砍上下文回传，而不是换更便宜的模型。会话轮数翻倍时，上下文开销大致翻四倍；而单价下调 30% 只带来线性的三成节省。两者不在同一个量级。
用轮数平方的一半去乘每轮新增内容长度，再乘输入单价。轮数越多这个估算越贴近真实账单；轮数少于 3 时误差较大，直接用实际值更准。
不一定。Fireworks 的思路是砍掉冗余的推理循环、保留有效的自我反思，以约少 40% 的词元维持质量。相比之下，直接调低推理强度属于牺牲质量换成本，两条路的代价完全不同。
先量再改。用每成功任务成本看分布，如果尾巴来自失败重放和重复调用，换模型不会解决问题——问题在编排层。只有当分子里「正常输入输出」占大头时，换模型或换计价档才有效。
按周看趋势、按月看结构。周度追踪每成功任务成本的漂移，月度重新拆一次六个科目的占比；某一项占比连续两个月上升，就值得立项处理。
如果你正在给 Web 端 AI 产品做上线前的预算评审，可以把当前架构与用量画像发给我们。
蓝曜炬辉 会按上面六个科目做一次逐项测算，标出结构性浪费的位置，并给出可落地的护栏清单。联系我们获取评估，也可以先看 已交付案例 里同类项目的成本结构。
本文数据分别来自：Fireworks Research 关于 Ember-1 的发布说明（2026 年 9 月 28 日，经 AIHOT 收录）、小米 MiMo 官方关于 MiMo-V2.6 工具调用重复的技术复盘（2026 年 9 月 27 日）、Arena 文本榜 2026 年 9 月 26 日的定价快照。三条来源的原文地址已在上文以超链接形式给出，不再重复列出。