大模型定价战打到今天：谁在真降价，谁在偷偷涨价

每家大模型官网第一眼都在写”降价 XX%“。价格战是真的，每百万 token 的价格确实在掉，有的型号降了十倍不止。

但另一件事也是真的：很多团队的账单并没跟着降。

两件事同时成立，是因为定价结构变了。标签上降的是最容易降的那一格，而实际使用中增长最快的，是原来标签上没有的那几格。

一、四种常见套路

1. 输入输出分开计价，输出贵 4–8 倍。表面看输入很便宜，但生成类任务里输出才是大头。提示词 2000 token、输出 4000 token，按”输入 1 元、输出 8 元”算，94% 的成本来自输出。

对策：比较价格时按你真实的输入输出比例加权，别看首页单一数字。

2. 长上下文阶梯价。超过 32K 或 128K，单价翻倍甚至更高。设计合理，但副作用是：上下文慢慢膨胀的 Agent 会在某天悄悄跨过阶梯线，说明还藏在文档深处。

实测最极端的一次：某 RAG 系统上下文从 3 万涨到 3.5 万 token，账单涨了 2.3 倍。

对策：把”单次调用输入 token 分布”做成监控，看 P95/P99 而不只是均值。均值 20K、P99 40K，说明有一小部分请求在偷偷吃钱。

3. 缓存看似免费，但要求严格。前缀缓存命中后输入成本能降到 10%–25%，这是真降价。但前提是前缀完全一致。实践中命中率低的常见原因：

• 系统提示里带了时间戳或随机 ID
• 检索文档顺序不固定
• 把动态内容放在了静态内容前面

对策：prompt 结构固定成「静态系统提示 → 固定文档 → 动态用户问题」。这一个改动常能把命中率从 10% 提到 70%。

4. 推理模型按”思考 token”计费。这是 2026 年增长最快的一项：思考过程计入输出，且长度不可控——同一个问题有时想 300 token，有时想 3000。把推理模型用在改写、分类、抽取上，单次成本是普通模型的 5–10 倍，效果却没区别。

对策：做模型路由，只有明确需要多步推理的请求才走推理模型，通常能省 40% 以上。

二、算一个真实的混合场景

一个客服 Agent，每天 10 万次请求，单次构成：

项目	数量	相对单价	成本
输入（系统提示+知识库）	8000 token	1	8.0
其中命中缓存部分	6000 token	0.15	0.9
输出（回答）	500 token	8	4.0
工具往返 3 次	3000 token 输入	1	3.0

缓存把 6000 token 从 6.0 降到 0.9，省了 5.1。但若换成推理模型（思考 1000 token，输出单价翻倍），输出部分从 4.0 变成 24.0，单次成本几乎翻倍。

数字本身不重要，重要的是：成本优化的杠杆点不在”选便宜模型”，而在”减少重复传输”和”选对档位”。

三、三条防爆表习惯

1. 每次发布前跑成本回归。把成本当成和准确率一样的指标，用固定 100 条样本对比上次结果。上下文变长、工具变多、模型换版本，一个测试全抓住。

2. 给每个功能加预算上限。按功能打标签设日预算，超了自动降级到小模型或返回缓存，而不是继续烧。

3. 月度只看三个数：单次请求平均成本（不是总成本，总成本随业务涨很正常）、缓存命中率、模型档位分布。这三个数稳定，业务翻倍成本也是线性增长；只要都在恶化，账单一定会爆。

小结

定价战是真的，但你省不省钱取决于自己的用量结构。别盯着首页价格标签，去看 token 分布、缓存命中率、模型档位——这三个数决定了你的账单，也决定了你有没有在替别人的营销买单。