90分钟实测：最强推理模型为何被“思考税”拖垮？

90分钟，三个模型，我把同一批任务原封不动跑了一遍。结果是：Claude Opus 5.5 和 GPT-6 系的“双雄”不仅没有碾压局，反而在简单问题上活活把自己卷死了——Opus 5.5 面对一道初中数学题思考了快三分钟，输出了一篇小论文，最后答案还是错的。与此同时，降价潮的公告就在我屏幕上挂着，单价确实低了，可我的账单一点没少。

这不是段子，是“过度思考”（overthinking）在真实场景里的翻车现场。地表最强的推理模型，被自己的思维链反噬，token 预算被内耗填满，推理时间被反思循环拉爆。这篇文章会把这场 90 分钟测试的完整数据、触发机制和根治手段一次说清，适合所有正在调 API、做 Agent、或者被模型账单折磨的开发者——尤其是那些刚把默认模型切到最强档、结果发现延迟和成本一起起飞的人。

1. 90分钟极限对决：同一批任务，三个模型的真实表现

先说测试是怎么设计的，毕竟“双雄决战”这种标题，不给个可复现的样本就是耍流氓。

1.1 测试任务与测试条件

我选了 90 分钟窗口，三类任务各 10 道，总共 30 道题，三个模型各跑一遍，共90次调用。任务覆盖：基础数学（初中到高中难度）、逻辑推理（类似脑筋急转弯但带坑）、多轮规划任务（比如“规划一次搬家流程，考虑天气和预算”）。每个任务只给一次机会，不重试、不救场。

参数上，我把三个模型的 temperature 都设为 0.7、max_tokens 设为 32000，禁用所有外部工具和联网检索，纯靠模型自身能力回答。这样才能排除掉变量——我只想测一件事：同样条件下，谁的推理效率更高、谁更容易被无意义的思考拖死。

1.2 翻车现场速写

跑完第一轮我就发现问题不对。基础数学题上，Opus 5.5 的平均响应时间接近 87 秒，GPT-6 Sol 约 64 秒，Luna 反而最快，只要 19 秒。但 Luna 的正确率只有 50%，Sol 是 80%，Opus 5.5 是 90%。看正确率，最强模型确实最强；看时间和 token 消耗，它也是最贵的——同样一道题，Opus 5.5 消耗的 token 是 Luna 的 4.7 倍。

最离谱的是那道七年级的分数混合运算。Opus 5.5 愣是用了 157 秒，生成了 1600 多字的推理过程，在“分母通分”的问题上反复自我怀疑，做了三种解法交叉验证，最后因为过度校验导致符号抄错。这是典型的“能力越强，越容易把简单问题复杂化”。

1.3 先给结论：撑爆模型的不是算力不足，是 token 预算被“思考税”吃干

所谓“撑爆”，不是显卡烧了，而是推理链太长、token 窗口被中间步骤占满。模型在生成正确答案之前，会生成大量“元思考”：我这样想对吗？换个角度试试？刚才的假设是不是站不住？这些元思考消耗 token，但不贡献答案。当 max_tokens 到了上限，模型被迫在错误位置截断，反而把本来能答对的题答砸了。

所以“地表最强智力被撑爆”的本质是：推理系统的成本函数里，多了一个“自我审视”的开销项，而这个项在最强模型上被放到了最大。接下来拆开看这个机制到底怎么运作的。

2. “过度思考”是怎么把最强智力拖垮的——拆开推理链看病因

我在测试后把 Opus 5.5 的完整推理链导出，逐段标注它的思考类型。结果很有意思：大约 35% 的 token 花在“重复验证”，28% 花在“备选方案探索”，只有 37% 左右真正用于推导答案。换句话说，模型一大半的思考，是在为自己兜底。

2.1 token 耗尽效应：反思一轮，预算就没了

推理模型的核心机制是，每多思考一步、多生成一个 token，模型就有机会修正之前的方向。但这同时意味着，每一步都可能引入新的分歧。在传统 Transformer 的生成机制里，后续 token 依赖前文，前文如果出现一个“假设性错误”，模型可能花费更多 token 去纠正。

我用一个简化数据说明：假设一个任务正确推理链需要 300 个 token。模型在第 120 个 token 处产生了一个不自信信号（概率一度降到 0.6 以下），它就开始分支探索另一条路线。这个分支又占掉了 250 个 token。最后模型回到主路，但剩余 token 只够推 130 个，距离答案还差 50 个。结果就是：正确答案本来在 300 token 处，模型却在 500 token 处被迫截断。这就是 token 耗尽效应。

2.2 置信度惩罚与自否定循环

更隐蔽的是置信度惩罚机制。训练过程中，模型被奖励“找错”的能力，导致它对每个结论都倾向于加一个“但有没有可能是这样”的尾巴。在复杂推理里这是优点，但在简单任务上就成了过度拟合的怀疑论。

我把一个代表性句子贴出来：

“上述解答看似正确，但需要验证——如果 a 取负值，通分过程会改变不等号方向吗？让我们从头检查。实际上，我选择使用最小公倍数 12，但也许 24 更合适？不，12 是正确的。等等，原题中分母是 4 和 6，最小公倍数是 12，我无需使用 24。修正：继续。”

这句话本身逻辑没毛病，但完全没有产生新的推导信息。它只是模型在自我审讯。每执行一次“修正声明”，消耗 40-80 个 token，这在简单任务上是纯粹的浪费。

2.3 能力边界错觉：权威模型把自己包装成深度

还有一个心理层面效应，在模型上同样成立：能处理复杂问题的系统，会因为训练分布里“长推理 = 高难度”的关联，把简单题也拉成长推理。模型学到的不是“这个问题简单”，而是“这类问题的训练样本往往需要长回答”。这个分布偏差导致模型对简单问题的输出长度先天偏长。

三个模型里，Opus 5.5 的训练数据里“详细的逐步推理”占比最高，所以它的平均输出长度也最长。Luna 作为轻量版，训练时刻意削减了“元认知”语料，反而在简单任务上更果断。这是模型的“能力-废话诅咒”。

3. Sol / Luna 双模型架构：快思维与慢思维的分工实验

这次测试里，GPT-6 系拆成 Sol 和 Luna 两个档位，Sol 偏重推理深度，Luna 偏重响应速度。这个拆分思路值得单独聊——它本质上就是 Daniel Kahneman 说的 System 1 / System 2 在模型架构上的实现。

3.1 为什么拆成两个模型，而不是调一个模型的参数

很多人会问：同样一个底层模型，把 temperature 调高、把 max_tokens 调低，不就变成快思维了吗？实测下来不是这么回事。

一个已训练好的模型，它的“思考习惯”是固化在权重里的。temperature 只影响采样的随机性，不能删除模型内部的自我审视链路。Opus 5.5 就算把 temperature 拉到 1.2，它还是会在简单问题上长篇大论，只是逻辑碎片化更严重。换句话说，temperature 改变的是“话风”，不是“思考结构”。

Luna 是单独蒸馏出来的轻量模型：它保留了解题能力的主干路径，但裁剪了“反思层”。我用一组任务对比了“Opus 5.5 低温 + 短 max_tokens”与“Luna 默认参数”的效果：前者因为硬截断导致正确率跌到 40%，后者因为本身不内耗，正确率稳定在 70%。这说明什么？思考习惯取决于模型的训练结构，外部参数只是给你一个约束工具，不能替代架构层面的取舍。

3.2 蒸馏路线的收益与损失

Luna 的收益很直观：响应快、token 省、成本低。从我这次测试的数据看，Luna 在简单逻辑题上的 token 开销大约是 Sol 的 31%，在中等难度任务上是 45%。如果你做的是大量低难度分类、抽取、改写任务，用 Luna 能把成本打下来一个量级。

但损失也很明确。Luna 在需要隐性推理的任务上（比如多步数学证明、法律条款衔接、代码边界条件分析），正确率会明显下滑。个别测试里，Luna 会给出“看起来合理但中间跳步”的答案。这在工程上很危险——它不是错误，而是不可验证。

我的策略是：当任务需要“可解释的确定性”时，必须用 Sol 或 Opus 5.5 这类满血模型；当任务只需要“看起来能用的结果”时，Luna 是首选。开发者不要指望一个模型通吃，而是要在结果可靠性和开销之间做路由。

3.3 API 路由与成本权重：什么时候该用哪个

我目前在生产环境采用的方案是：先让 Luna 跑一轮快速结果，接入一个轻量校验器（可以是规则，也可以是一个更便宜的分类模型），校验不通过再升级到 Sol。按我的日志统计，约 67% 的请求在 Luna 层就被接受了，剩下 33% 升级到 Sol。整体成本比原来全量用 Opus 5.5 低了 42%。

排行榜上的“最强模型”对应的是能力上限，但生产环境的核心指标是“最少 token 达成目标”。这就是模型分层的价值——它把“能力”和“成本”做了切割。

4. 实测数据里的“思考税”：哪些任务最烧 token，哪些白烧

我整理了这次测试里比较典型的几组数据，做成表格方便大家参考。

注意看，任务越简单，Opus 5.5 和 Luna 的差距越大。初中数学题上差了接近 5 倍，而复杂规划任务只差了不到 2 倍。这说明过度思考的压力，在简单任务上最夸张。你的应用如果 80% 都是简单任务，却把默认模型设成 Opus 5.5，你的钱 80% 都烧在了多余的自审上。

4.1 被撑爆的典型案例复盘

案例一：一道初中数学题。Opus 5.5 生成了三种解法，并在第三种解法里推翻了自己第二种解法的结论，最后以第三种解法的答案为准，答错了。而 Luna 在 20 秒内用最直接的分数运算给出正确答案。这个案例完美展示了“多思考”不等于“想得对”——有时多出来的思考，反而引入了新的错误路径。

案例二：多轮规划任务。我让它规划一次三天两夜的城市搬家，考虑天气、预算和物品打包顺序。Opus 5.5 的响应结构非常完整，甚至生成了“风险登记册”和“备选仓库方案”，但总共消耗 12480 token，耗时 132 秒。这个结果对大部分用户来说，信息密度太低。 Luna 给出的 6420 token 的版本，重点突出，操作性强，步骤少了三分之一，但够用。

案例三：代码 review。我给它一段 30 行的 Python 函数，要求指出边界条件问题。Opus 5.5 花了 9100 token，像个审稿人一样评价了代码风格、命名规范、可读性，最后才提了一嘴越界问题。Sol 则直接聚焦到边界条件，给了三段修复示例。Sol 在这里的体验明显更好——它知道审代码和审风格是两件事。

4.2 降价潮的真面目：单价降了，账单没降

标题里提到的“暴烈降价潮”，账得好好算。早上我看到公告，Opus 5.5 的输出价格从 15 美元/百万 token 降到了 9 美元，GPT-6 Sol 的价格也有下调。表面上看，成本降了 40%，但结合过度思考的问题，实际账单可能毫无变化。

逻辑很简单：输出单价下降了 40%，但如果模型因为过度思考把输出 token 数增加了 80%，那么单次请求的总成本反而上升了 8%。你得到的不是降本，是变相涨价。我在 90 分钟测试里按新价格计算过：因为 token 消耗量的增长，我的总成本和降价前持平。这说明模型厂商降价，可能不是为了让你省钱，而是为了让你敢用更强的模型、生成更长的输出、消耗更大算力。

4.3 开发者应该怎么读这份价格表

我建议所有靠 API 吃饭的团队，不要只看官网价格表，而要建立一个“任务级成本监控”：每一类任务的平均 token 消耗、平均响应时间、正确率。用这套数据来决定模型路由策略。降价潮真正的红利，不是“最强模型变便宜了”，而是“便宜的模型和贵的模型之间的价差，给了你新的分层空间”。

5. 驯服过度思考的六个实操手段（API 开发者向）

绕了一大圈，落到工程层面。怎么让最强模型别在简单任务上过度思考？我分享六个我用下来有效的方法，按优先级排序。

5.1 温度、top_p、frequency_penalty 怎么配

先说结论：不要为了“抑制思考”而把 temperature 调低。

我在测试里把 Opus 5.5 的 temperature 从 0.7 降到 0.1，输出反而更长——因为低温会让模型更倾向选择“最稳妥但最冗长”的路径，一个分支走到黑。温度设成 0.9-1.0 时，模型更容易在早期“跳出不自信的分支”，反而缩短了推理链。

top_p 同理，不要设到 0.5 以下。采样范围太小，模型会反复确认同一个结论；采样范围大一点，模型能更快放弃坏思路。frequency_penalty 我建议设成 0.2-0.4，可以惩罚“重复论证”这类行为，实测能把 token 消耗拉低 8%-12%。

5.2 用 max_tokens 和 reasoning effort 给思考上锁

如果 API 支持 reasoning effort 参数（Opus 5.5 和 Sol 都有），把它调到 “low” 或 “medium”，不要一直用 “high”。“high” 意味着模型会在每个子结论上做三遍验证，在你不需要“证明级确定性”时，这是纯浪费。

max_tokens 也要根据任务类型设置，而不是统一给满。简单分类题给 1024，中等推理给 4096，复杂任务才给 8192 以上。我给其中一个测试任务设了 2048 上限后，Opus 5.5 正确率从 90% 降到 76%——这说明截断确实会牺牲质量，但如果你本来就不需要 90% 的正确率（比如初筛场景），这种牺牲是值得的。

5.3 提示词里的“思考预算”写法

提示词里可以直接给模型立规矩。这招对 Opus 5.5 尤其好用。

一个模板：

你是一个资深工程师。请注意：本任务难度不高，请直接给出答案。 约束：推理过程不超过 150 字；不要罗列多种解法；不要自我反驳； 如果第一次推理已经得出结果，直接输出最终结论。

我实测过，这个提示词能把 Opus 5.5 在简单任务上的输出 token 从 4700 降到了 1900，正确率只掉了 3 个百分点。核心是给了模型一个“答案是简单的”的先验信号，让它的能力分布里“简单任务的简洁模式”被激活。

5.4 任务分块与思考跳板

过度思考的根源之一是模型要同时处理太多子问题。把大任务切成小任务，每个小任务单独调用模型，能显著降低单次推理的复杂度。

比如“写一份季度汇报”，如果你让模型一次性输出全文，它会反复纠结结构、语气、数据颗粒度，token 消耗巨大。拆成三步：先让模型输出大纲（max_tokens: 800），再让模型逐个写章节（max_tokens: 1500），最后让模型合并并统一语气（max_tokens: 1000）。三步总 token 消耗，比一次生成少了约 35%，而且每个环节的质量都更容易控制。

5.5 禁用反思的几种有效 prompt 模板

针对特别容易触发自否循环的任务，我试过几类模板，效果排序如下：

1. “只允许使用一个解决方案。禁止出现‘但’、‘另一种方法是’、‘虽然’等转折词。”
2. “假设前 80% 的推理是正确的，直接完成最后 20%，不要重新审视前半部分。”
3. “输出结构：结论 → 关键依据 → 所需修正。不要包含思考过程。”

模板 1 最为直接，适合简单任务。模板 3 适合报告类输出，能极大压缩 token。这里要注意，这些约束只在简单任务上有效；对真正的难题，禁止反思会直接拉低正确率。

5.6 三分钟压测你的调用成本

最后，建议你用这个思路跑一个自己的压测脚本：准备 5 道简单题、5 道中等题；两个模型（最强 + 轻量）分别跑；统计平均 token、平均时间、正确率。代码很简单，核心就几行，统计 token 用 API 返回的 usage 字段即可。

根据我的经验，压测结果超过 70% 概率会和本文结论一致：最强模型在简单任务上的过度思考会导致成本倒挂。有了你自己的数据，再去做模型路由，就不会被厂商的价格表带偏。

6. 降价潮背后的行业信号：推理成本重新定价，模型分层成为刚需

最后聊一聊这次降价潮背后，我看到的三个信号。

6.1 为什么是这个时间点降价

推理模型的商业化压力，已经从“训练成本”转移到了“推理成本”。训练阶段是一次性投入，而推理阶段是持续性的—每次用户调用都在烧钱。模型越强，平均推理链越长，单次推理成本越高。厂商降价，本质上是在利用规模效应摊薄成本，同时吸引更多开发者把业务逻辑跑在最强模型上。

但你要理解：厂商的商业模式里，最理想的情况是用户用最强模型处理所有任务，哪怕其中 60% 不需要那么强的推理。过度思考对厂商是利润来源，对你是成本黑洞。

6.2 token 路由与模型选择的未来

接下来的应用开发趋势，一定是“token 路由”成为基础设施的一部分。不是用一个大模型处理所有请求，而是根据任务特征自动分配模型：简单任务走轻量模型，中等任务走中等模型，极限推理才动用 Opus 5.5 或 Sol。

这个路由可以自己做，也可以用 Anthropic 和 OpenAI 未来可能提供的自动路由功能。不管怎样，结论是一致的：应用层开发者脑子里要有“模型预算”的概念，就像前端开发者关心带宽一样。

6.3 对应用开发者的直接影响

这次降价加上过度思考的叠加效应，对我最大的启发是：不要把“最贵模型设为默认”当作对用户的尊重。用户要的是“快的正确答案”，不是“长篇大论的最强答案”。把 Luna 设为默认，复杂请求再升级到 Opus 5.5，在产品体验和成本控制上都是更优解。

这次 90 分钟测试之后，我把生产环境全部改成了分层路由策略。账单降下来的那一刻，我才算真正理解了“最强模型”该怎么用：不是让它处理所有任务，而是在它真正不可替代的地方，让它发挥最强的那一面。