——为什么"聪明"不等于"划算"

 

你有没有想过，同一个问题问两个不同的AI模型，准确率差不多，但花的钱可能差好几倍？

 

一项覆盖24个主流大模型的独立测评（Token Burn, 2026）发现：同样是给出正确答案，最高效和最低效模型的实际成本差距高达470倍。

 

不是单价差470倍——是"效率"差470倍。有的模型三言两语就能答对，有的模型说了一大堆废话才蒙对。

 

更麻烦的是：没有一张排行榜把这个差距写进去。

 

一、只看能力，不看效率

 

打开LMSYS Arena、MMLU、HumanEval这些主流排行榜，你会发现它们都在回答同一个问题：这个模型能不能做对？

 

但没有人问：它花了多少才做对？

 

这就好像你去打车，所有平台只告诉你"都能到机场"，但不告诉你一辆走了高架、一辆绕了三环——虽然都是"到了"，费用可能差3倍。

 

这种评估方式在LLM发展早期问题不大。模型都贵，大家比的是"谁更聪明"。但当价格战打到DeepSeek V4 Flash百万token输出只要0.28美元、Gemini Flash只要0.60美元的时候，一个更现实的问题浮出水面：

 

便宜不等于省钱。

 

一个模型每token只要$0.60，但它需要1500个token才能答对一道题；另一个模型每token要$8，但只需要400个token。谁更省钱？答案不是看一眼价格表就能知道的。

 

另一项覆盖53个模型的大规模评测LLMThinkBench（ACL 2026 Findings）发现了一个更讽刺的事实：推理模型（如o3、DeepSeek-R1）虽然"想得更深"，但生成的token量是普通模型的18倍，有时准确率反而更低。o系列推理模型从低→中→高推理努力，token消耗大幅增加，但准确率提升并不显著——想了更多，并没有答得更好。

 

二、废话的代价，比你想的大

 

"废话"这个词可能不够精确。让我们用一个更严谨的说法：冗余token消耗。

 

Google研究团队在ICLR 2026 Workshop的一篇论文（CROP）中证明了一件事：在不显著损失准确率的前提下，LLM推理过程中超过80.6%的token消耗其实是冗余的。也就是说，模型说的大部分话，可能都是"不必要的"。

 

假设你问一个编程问题，模型回答了一大段——先是"让我分析一下这个问题"，然后是"首先我需要考虑几个方面"，接着是三个方向的探索，最后才是真正的答案。其中真正有价值的，可能只是最后那200个token。但你需要为前面1000个token也付钱。

 

那些"走错方向又折回来"的推理链，你也看不出来——因为它被混在最终答案里了。但它在消耗你的token、你的钱、你的API配额。

 

微软研究院开发的LLMLingua提示压缩工具能把输入文本压缩到原来的1/20，同时保留98.5%的任务准确率（据论文报告）。输入端都能压缩20倍，输出端的冗余程度可想而知。

 

三、Agent时代：效率差距被乘法放大

 

如果说单次对话中冗余token只是浪费了点钱，那么在Agent应用中，效率差距变成了致命问题。

 

云成本平台Vantage实测了50轮Agent编程会话，发现一个典型模式：一个Agent完成一个完整编程任务，需要消耗约100万输入token和4万输出token——输入输出比高达25:1。为什么输入这么多？因为AI没有持久记忆。每次操作都要重新读取全部上下文。一位独立开发者追踪自己一个月的Claude Code使用，发现99.4%的token是输入，读写比165:1。

 

打个比方：聊天像你问同事"这bug怎么改"，Agent像派了个实习生去把bug真改好——自己读代码、想方案、动手改、跑测试、没过、再改、再跑。实习生干的活越多，消耗的token越多。

 

在这种场景下，模型选择的效率差距不再是加法，而是乘法。

 

举个例子：如果一个模型单次API调用成功率95%，当Agent为完成复杂任务需连续调用15次时，任务终极成功率将降至约46%（0.95的15次方）。超过一半的概率Agent会"死锁"或跑偏——而所有失败的尝试，都消耗了token。

 

企业已经在为这种"乘法效应"买单。Uber在2026年前4个月就花光了全年的AI编程预算；Meta员工30天消耗60.2万亿token，成本超1亿美元。基于Vantage实测数据推算，假设每人每天使用2次Agent编程，25人团队使用Claude Opus的年化成本可达7.2万美元。

 

还有一个隐藏成本：推理token。o3、DeepSeek-R1这类推理模型会生成大量"思考token"——用户看不见，但计费。LLMThinkBench的实测数据表明，推理模型生成的token量是普通模型的18倍，其中大量是用户不可见的推理链。你看到的账单，永远比预期高。

 

效率，从来不是锦上添花。它是生死线。

 

四、一个被忽视的维度：ECET

 

我们提出一个简单但关键的指标：ECET（Expected Cost of an Effective Turn）——"获得一次合格回答的期望Token消耗"。

 

通俗地说，它不是在问"模型说了什么"，而是在问"花了多少Token才说对"。

 

核心计算只有一行：

 

ECET = 全部迭代Token消耗总量 ÷ 成功次数

 

更紧凑地写：

 

ECET = Σ T_all / n_success

 

T_all = 每一次尝试消耗的token（无论成败）；n_success = 合格回答的次数

 

 

注意：那些失败尝试的token不是"不算"，而是分摊到了每一次成功里。这才是真实的成本。

 

比如100次尝试总共花了50万token、成功了25次，ECET就是2万token/次——每一次"说对"，你实际付出了2万token的代价。

 

为什么要这么算？因为LLM不是确定性的。同一个模型、同一个问题，每次回答都不一样。你不可能只挑好的那次算成本——失败的尝试花的钱是真花了的。ECET把所有花费都算进去，再用成功次数来"均摊"，得到的才是你真正需要为"一次成功"付出的代价。

 

这里还有一个容易忽略的区分：可见token和全部token。你看得见的回答是可见token，但推理模型那些"思考过程"虽然不可见，也在计费。所以ECET有两个版本——ECET_visible只算可见token，ECET_total算全部token（含隐藏推理token）。排行榜排名应该用total版本，因为那才是你真正买单的成本。

 

降低ECET有三条路径：让正确的回答更精炼（减少合格回答的token）、让错误的尝试更快停下来（减少失败轮次的浪费）、让模型本身准确率更高（提高成功次数p）。这三条路径可以独立优化，也可以叠加。

 

但光有平均值还不够。你怎么知道模型A比模型B真的更高效，而不是碰巧这次测出来比较好？

 

这就需要统计学方法帮忙。简单说：多次测量取范围（Bootstrap置信区间），看看差距是"真的不同"还是"运气波动"（假设检验），再排除"比多了总有一组碰巧显著"的干扰（多重比较校正）。这些方法听起来很学术，但解决的是一个非常实际的问题——你怎么确定你选的模型真的更高效，而不是运气好？

 

五、学术界在关注，但角度不同

 

ECET不是凭空提出的。学术界已经开始关注LLM的token效率问题，只是切入角度各有侧重。

 

LLMThinkBench（ACL 2026 Findings）揭示了一个关键现象：推理模型的token消耗与准确率之间存在"非单调关系"——不是想得越多就答得越好。这为效率评测提供了动机。

 

Beyond Accuracy（2026）则提出了一个反直觉的发现：在不同benchmark之间，模型的"效率排名"远比"准确率排名"更稳定。换句话说，效率是一种比准确率更可靠的模型特质。这为"效率应该成为独立评测维度"提供了统计层面的支撑。

 

在token压缩方向，CROP证明了超过80%的token可以压缩，LLMLingua展示了20倍的输入压缩潜力。在效率分解方向，Token Burn对24个模型做了标准化经济效率评测。

 

但这些工作从不同角度切入——有的关注"过度思考"，有的关注"效率分解"，有的关注"prompt压缩"。ECET问的是另一个维度的问题：稳定地说对一次，平均要花多少？ 它不是对现有指标的修补，而是一个新的评测视角。

 

还有一个容易被忽略的基础问题：Tokenizer差异。同一篇中文文章，GPT-4o每字需要约1.4-1.8个token，Qwen每字只需约1.0-1.1个——还没开始回答，输入成本就差了近一倍。多项研究表明，非英语语言在西方模型的tokenizer中通常需要2-4倍的token数量来表达相同语义。跨模型比较"谁更省token"之前，必须先做tokenizer归一化，否则比的不是"谁更聪明"，而是"谁的切词方式更细碎"。

 

六、效率管理，也是安全护栏

 

写完这些，我想分享一个个人感受。

 

我自己最近在用Agent做任务时，开始注意到一个现象：同一个任务，换了一个模型，token消耗差了3倍，但结果质量差不多。这让我开始认真思考——我们是不是一直在用"最聪明"而不是"最高效"的方式选模型？

 

在整理这套方案的过程中，我越来越意识到：Token效率管理不只是"省钱"的事。当你监控一个Agent系统的token消耗时，异常的token膨胀可能意味着模型被劫持了、被注入了恶意prompt、或者陷入了死循环。

 

这和我们之前讨论的"驾驭工程"（Harness Engineering）理念一脉相承——效率管理是驾驭框架的核心功能之一。一个高效的Agent系统，不只是省钱的系统，也是更安全的系统。

 

当你看到某个Agent任务的token消耗突然飙升，第一反应不应该是"模型变笨了"，而是"是不是哪里出了问题"。效率监控，本质上是一种异常检测信号。

 

七、这是一个邀请

 

这篇文章没有实验数据。

 

我们提出了一个问题——LLM评测体系缺了效率维度——和一个思路——ECET加上统计学方法。但"提出思路"和"验证思路"之间还有很长的路。

 

我们正在构建这套评测体系（LTEB），后续文章会分享具体的实验设计、方法论细节和跨模型对比数据。

 

在那之前，我想先问你一个问题：

 

在你的应用场景里，Token效率是问题吗？

 

如果你正在跑Agent系统、做RAG、或者每天调用LLM API超过1000次——答案大概率是"是"。只是你可能还没有一个量化的方式来衡量它。

 

这就是我们想做这件事的原因。

 

参考文献

 

[1] Srivastava, G. et al. "Do LLMs Overthink Basic Math Reasoning? Benchmarking the Accuracy-Efficiency Tradeoff in Language Models." ACL 2026 Findings. https://arxiv.org/abs/2507.04023

 

[2] Kaiser, D. et al. "Beyond Accuracy: Decomposing the Reasoning Efficiency of LLMs." 2026. https://arxiv.org/abs/2602.09805

 

[3] Shah, D. et al. "CROP: Token-Efficient Reasoning in Large Language Models via Regularized Prompt Optimization." ICLR 2026 Workshop LLM Reasoning. https://openreview.net/forum?id=O2LmrF5Yzq

 

[4] Universal Value Advisors. "Token Burn: An Empirical Analysis of Economic Inefficiency in Premium LLMs." 2026. https://universalvalueadvisors.com/blog/token-burn-llm-economic-inefficiency

 

[5] Jiang, H. et al. "LLMLingua: Compressing Prompts for Accelerated Inference of Large Language Models." EMNLP 2023. Microsoft Research. https://arxiv.org/abs/2310.05736

 

[6] "TokLens: A Multilingual Lens on Tokenizer Quality for LLMs." ACL 2026 SRW. https://aclanthology.org/2026.acl-srw.18.pdf

 

[7] Vantage. "The Hidden Cost Driver in Agentic Coding." 2026. https://www.vantage.sh/blog/agentic-coding-costs

 

[8] "Why AI Coding Agents Burn Tokens." 2026. https://docs.bswen.com/blog/2026-03-10-ai-coding-context-window-problem/

 

[9] "LLM Tokenizer Efficiency Comparison." presenc.ai. 2026.