Token 消耗降了三分之二，任务成本为何反升？

一、一对矛盾的数字，都是真的

模型换代评测里经常出现这样的组合：新一代模型每个任务的 token 消耗只有前代的三分之一；同一份报告又显示，它每个任务的综合成本比前代贵了 75%。两个数字都真实，出自同一份测试。矛盾感来自把两个不同量纲的指标当成了同一件事：token 消耗量衡量的是“干一件活烧多少料”，任务成本衡量的是“干一件活花多少钱”，两者之间隔着一个单价变量。

把基本关系写出来，矛盾就消失了一半：

单任务成本 = Σ（各轮次输入 token × 输入单价 + 输出 token × 输出单价）

消耗量降三分之二、单价涨到 2.5 倍，乘积约为 0.83——变相降价；消耗量只降 10%、单价涨 2.5 倍，乘积约 2.25——明显涨价。同一个模型在不同任务类型上，完全可能同时落在两种情形里。

二、先对齐量纲：token 消耗量到底在测什么

2.1 消耗大头不在答案，在试错

很多人直觉里 token 消耗约等于“模型说了多少话”。对聊天场景大致如此，对 agent 场景完全不是。一次编码任务的 token 消耗从任务开始累计到结束，中间每一轮读取文件、推理、写代码、跑测试、看报错、返工，全部计入。以任务完成度计分的主流 agent 评测，统计的正是这个累计值。

示意一下 agent 循环里 token 是怎么烧掉的：

total_tokens = 0
for step in agent_loop(task):
    prompt = rebuild_context(memory, step)   # 上下文重建：每轮都在烧输入 token
    resp = llm(prompt)
    total_tokens += count(prompt) + count(resp)
    if not verify(resp):                     # 验证失败 → 返工
        memory.rollback()                    # 前面轮次的 token 全部沉没
        continue
    memory.persist(extract_notes(resp))      # 成功经验沉淀为笔记

跑过长任务的人都有体感：返工的损耗大头往往不是“写错了代码”本身，而是“丢了上下文”。模型每压缩一次上下文，“当时为什么这么改”的决策依据就被挤掉一分，于是用双倍 token 把同样的坑重新踩一遍。

2.2 降耗的来源：把草稿纸带在身上

新一代模型在 token 效率上的架构级进步，核心几乎都指向同一件事——跨上下文窗口的信息保留：

• 工作笔记持久化：关键决策、已验证的结论、失败的尝试被压缩成结构化笔记，跨窗口携带，后续轮次不必从零重建语境；
• 机制速记：评测回放里能看到模型把没见过的框架行为浓缩成自创的规则表随身携带，遇到同类问题直接查表，而不是重新试错；
• 更聪明的压缩：压缩时优先保留“为什么”，而不是只保留“是什么”。

草稿纸能带着走，浪费自然就下来。这也解释了为什么 token 效率的提升幅度在不同任务类型上差异巨大：强依赖多轮试错的 agent 任务收益最大（消耗可降到前代的三分之一甚至五分之一，多个档位站上“分数-成本”平面的帕累托前沿）；而以长文理解、知识问答为主的任务上下文重建占比低，降幅往往只有 10% 左右。

三、单价与用量的乘法：成本在场景间分岔

3.1 一道算术题

假设某次换代把输入、输出单价都上调到前代的 2.5 倍（示意数字，实际以各平台定价为准），两类任务的净效应完全不同：

任务类型	token 变化	单价变化	单任务成本变化	结论
编码 agent	降至 1/3	×2.5	≈0.83×	变相降价
长文/知识型	降至 0.9	×2.5	理论 ≈2.25×	明显涨价

编码 agent 场景里，消耗降三分之二不仅吃掉了涨价，还倒赚出空间：同档位成本与前代打平甚至更低，任务分数还更高；拉到同等分数比较，单任务成本可以显著低于前代。对以 agent 为主力的开发者，这是一次实质降价。

长文与知识型任务则相反：token 只省了约 10%，架不住单价乘 2.5，综合下来每个任务比前代贵出一大截。省出来的 token，全被单价吃了回去。

3.2 理论与实测的差距，恰恰是要自己测的理由

细心的读者会发现：0.9 × 2.5 = 2.25，理论上限是 +125%，而实测往往在 +75% 左右。中间的差额来自输入/输出 token 配比、上下文缓存命中、不同任务的结构差异。这个差距本身就是重要结论——任何“单价 × 用量”的纸面推算都只能给出区间，真实成本必须用自己的工作负载实测。

四、看懂定价策略：效率标题与账单逻辑的两套话语

放在行业背景下，这种“消耗降、单价涨”的组合并非偶然。这一年里，轻量低价模型在降价、开源方案逼近免费，“便宜”这个维度已经卷不动了；旗舰模型的换代策略于是反着走：把架构进步和涨价都押注在编码 agent 这一个高价值场景上，再用“token 消耗降三分之二”这类效率标题，掩护其他场景的实际涨价。

对媒体标题要多留一个心眼：标题只告诉你第一个数字（消耗量），账单只认乘积（成本）。转述文章引用哪个数字，往往已经预设了立场。

订阅用户则是另一笔账。订阅制不按 token 计费，按限额走——token 效率提升意味着同样的限额能干近三倍的活。对订阅党，效率提升是实打实的福利；对按量付费的用户，必须把单价乘进去再下结论。同一个模型，两种计费方式，两个方向的结论。

五、开发者的一套成本评估框架

把上面的分析沉淀成可执行的方法论，无论模型来自自部署还是百度智能云等云平台的模型服务，这套框架都适用：

1. 对齐量纲：永远用“单任务成本”而不是“单 token 成本”做决策。记录每个任务的累计 token、轮次数、重试率、最终得分。
2. 用自己的负载实测：准备 20～50 个有代表性的真实任务，跨模型跑对照，纸面推算只用来圈定区间。
3. 在“分数-成本”平面看帕累托前沿：同等分数下成本更低、或同等成本下分数更高的档位才值得考虑，单点分数没有意义。
4. 把上下文管理当第一优化对象：外部记忆、工作笔记持久化、把反复出现的机制沉淀成规则表，往往比换模型更能降耗。
5. 区分场景选型：agent 重场景优先看 token 效率与任务得分；长文场景优先看综合单任务价格；两者别用同一把尺子。
6. 叠加通用降本手段：提示词缓存、批处理、输入输出分别压测，这些与模型换代无关，却能稳定削减账单。

一个极简的核算函数，可以直接放进评测脚本：

def task_cost(tok_in, tok_out, price_in, price_out):
    """tok_*: 单任务累计 token（含全部中间轮次）
       price_*: 每百万 token 单价"""
    return tok_in / 1e6 * price_in + tok_out / 1e6 * price_out
def cost_ratio(old, new):
    """new.cost / old.cost：<1 变相降价，>1 实际涨价"""
    return new.cost / old.cost

六、结语

token 消耗量降了、任务价格涨了，两件事同时成立，而且都写在同一份报告里。想明白它们如何共存——消耗量是用量维度，价格是单价维度，成本是二者的乘积，而乘积在不同场景下指向不同方向——你对这代模型的理解，就已经超过了大多数只转述单个数字的文章。模型评测如此，一切技术选型的账单核算，皆是如此。