大模型为什么可以调节推理的强度？

同一道题，同一个模型。

把推理强度从 low 调到 high，答案有时会明显变好。

但模型参数没有增加，神经网络层数没有变化，训练也早已结束。多出来的能力，究竟从哪里来？

关键不在于模型突然知道了更多东西，而在于它在给出最终答案之前，被允许投入更多计算。

这正是 reasoning effort 背后最重要的变化：

大模型的表现，开始不仅取决于训练时学到了什么，也取决于回答当前问题时投入多少计算。

过去，我们主要通过更换模型来调整能力：简单任务使用小模型，复杂任务使用大模型。

现在，同一个推理模型也可以运行在不同档位下，在答案质量、响应速度和计算成本之间作出取舍。

reasoning effort 调节的其实是：

这个问题，值得模型走多少步、检查多少次，又应该在什么时候停下来。

一、普通聊天模型也会推导，但通常更快进入最终回答

大语言模型最基本的工作方式，是预测下一个 Token。

用户输入问题后，模型读取当前上下文，预测接下来最可能出现的 Token；生成以后，后续预测会以这个新 Token 为条件，继续生成下一步。

这个过程可以表示为：

tₙ₊₁ ~ Pθ(tₙ₊₁ | x, t₁, t₂, …, tₙ)

其中：

x 是用户输入；
t₁ 到 tₙ 是已经生成的 Token；
tₙ₊₁ 是下一步要生成的 Token；
θ 是模型训练完成后固定的参数。

这条公式说明了一件很重要的事：

模型每生成一个新 Token，后续预测就会把它作为新的条件。

从数学表达上看，模型下一步会参考此前的全部上下文。工程实现中通常会使用 KV Cache 进行增量计算，而不是每生成一个 Token 就从头计算完整上下文。

普通聊天模型同样能够表现出分析和推导能力。有时，让它“分步骤说明”，它也能写出一段看起来相当完整的逻辑过程。

因此，推理模型与普通聊天模型的区别，并不是前者会思考、后者完全不会。

更准确的区别在于：

是否经过专门的推理后训练；
是否能稳定利用更长的中间计算过程；
是否会在最终答案前分配专门的推理预算；
是否支持通过参数控制这部分计算投入。

许多传统聊天模型可以生成推导过程，但通常没有暴露可调的推理预算，也未必经过专门训练，去稳定地利用更长的测试时计算。

对于翻译、改写、分类和信息提取等任务，这通常已经足够。但面对复杂问题时，第一时间想到的答案往往只是一个起点。

例如，用户提出这样一个问题：

一个订单接口偶尔发生重复扣款，应该从哪里排查？

一个快速回答可能是：

检查接口是否重复提交，并为支付请求增加幂等机制。

这个答案并不算错。

但真实的重复扣款可能来自很多不同环节：

用户连续点击；
客户端超时后重试；
API 网关自动重试；
支付成功，但响应在网络中丢失；
消息队列重复投递；
支付回调被重复消费；
数据库事务提交成功，但业务状态没有及时更新；
幂等键只在部分链路中生效。

复杂任务需要的不只是快速给出一个看起来合理的答案，而是展开一段完整的处理过程：

确认现象，拆分可能原因，获取证据，排除假设，验证修复方案，最后给出结论。

推理强度影响的，正是这段过程可以展开到什么程度。

二、大模型所谓的“多想一会儿”，计算上发生了什么？

高推理强度并不是临时给 Transformer 增加更多网络层。

也不能简单理解为：low 使用小模型，high 偷偷换成了大模型。商业系统中可能存在服务端路由，但可变推理本身并不要求更换模型。

更准确的解释是：

模型在输出最终答案之前，形成了更长的中间推理轨迹，因此执行了更多串行的自回归计算。

一次推理可以抽象成：

x → z₁ → z₂ → … → zₖ → y

其中：

x 是原始问题；
z₁ 到 zₖ 是中间推理状态；
y 是最终答案；
k 表示推理轨迹的长度。

每一个中间状态都通过模型继续生成：

zᵢ ~ Pθ(zᵢ | x, z₁, z₂, …, zᵢ₋₁)

最终答案则基于此前形成的推理轨迹生成：

y ~ Pθ(y | x, z₁, z₂, …, zₖ)

在公开的可变推理模型中，模型权重可以保持不变，而推理轨迹长度 k 的分布会随推理等级发生变化：较高档位通常允许模型形成更长的中间过程。

对于闭源系统，工具预算、停止策略、候选搜索和服务端路由也可能同时变化，具体实现并未完全公开。

回到重复扣款的例子。

模型可能首先形成一个中间判断：

先区分重复扣款发生在请求侧、支付侧，还是异步回调侧。

下一轮计算时，模型看到的不再只有用户最初的问题，还会受到这个新形成状态的影响。

随后，它可能继续判断：

如果支付平台只收到一次请求，但系统记录了两笔订单，问题更可能位于本地事务或回调消费环节。

这个判断又会成为下一步分析的条件。

推理轨迹可能逐步展开：

订单重复扣款 → 区分重复请求与重复消费 → 检查支付平台请求记录 → 检查网关及客户端重试 → 检查消息消费与回调幂等 → 检查事务边界 → 设计验证方法 → 给出修复优先级

模型的物理网络深度没有变化，但它获得了更多串行计算步骤，形成了一条更长的有效计算路径。

推理 Token 为什么具有计算价值？

因为生成出来的 Token 会影响后续预测。

中间 Token 可以承担类似这些作用：

保存当前假设；
记录已经排除的方向；
保存中间计算结果；
标记尚未解决的问题；
记录工具返回的数据；
提醒下一步需要验证什么。

它有点像草稿纸，也有点像程序中的临时变量。

工程师排查重复扣款时，不会每一步都从原始问题重新开始。他会记录：

支付平台只有一条扣款记录；
网关发生过一次超时重试；
回调消费者没有唯一约束；
数据库中存在两条相同业务流水。

这些记录构成后续判断所依赖的状态。

推理 Token 对模型也可以发挥类似作用。

不过，需要避免一种过度拟人化的理解：模型的中间推理并不一定是一篇完整、清晰、能够供人类直接阅读的文章。

更准确地说：

推理 Token 可以作为中间状态的序列化载体，为后续计算保存有用信息。

模型完整的内部状态仍然存在于隐藏表示、注意力机制和 KV Cache 等计算结构中，不能被完全等同于可见的文字 Token。

三、让模型写得更长，并不会自动产生更强推理

既然更长的中间轨迹能提供更多计算机会，是否只要提高最大输出长度，任何模型都会变聪明？

事情没有这么简单。

一个没有经过专门推理训练的模型，即使获得更多生成空间，也可能只是：

重复已经说过的观点；
在错误假设上继续展开；
编造更多无法验证的细节；
不断改写同一个结论；
明明已经得到答案，却不知道应该停止。

更多 Token 只代表更多计算机会，并不保证这些机会会被有效利用。

给一名学生更多答题时间，也不会自动提高成绩。

如果他不会拆题、验算和纠错，额外两个小时可能只是让他在错误答案上停留得更久。

要让更多计算真正转化成能力，模型需要学会一套推理策略：

先处理哪些条件；
怎样拆分复杂问题；
什么时候尝试另一条路线；
如何识别前后矛盾；
什么时候调用外部工具；
如何验证结果；
什么时候停止。

这也是推理后训练发挥作用的地方。

从强化学习的视角看，模型面对的已经不只是：

下一个 Token 应该是什么？

而是：

当前状态下，采取什么下一步动作，更可能最终完成任务？

这里的“动作”是一种抽象。它可能表现为：

形成一个中间结论；
拆分一个子问题；
修改当前假设；
调用搜索工具；
运行代码；
检查答案；
结束推理。

在可验证任务中，训练系统可以较明确地判断结果好坏：

数学题答案是否正确；
代码能否通过测试；
工具调用是否完成目标；
输出是否满足约束；
执行结果是否通过验证器。

模型会尝试不同的推理轨迹。

有些路径短而有效，有些路径很长却没有价值，还有些路径能在中途发现错误并回退。

经过监督微调、强化学习、可验证奖励以及针对工具使用的后训练，更有效的策略会逐渐被强化：

先拆分，再执行；发现证据冲突时回退；关键结论需要验证；答案足够可靠时及时结束。

所以，推理模型的突破并不只是能够输出更多文字。

真正重要的是：

模型开始学会把更长的生成过程组织成有效计算。

四、Reasoning Effort 到底控制了什么？

当模型具备了推理能力后，还需要学习在不同任务中使用不同的推理档位。

“把一段文字改得更通顺”和“排查一个分布式系统故障”，显然不应该消耗同样多的计算资源。

为了描述这个过程，可以使用一个概念模型：

Pθ(z, y | x, e)

其中：

x 是任务输入；
e 是推理强度，例如 low、medium、high；
z 是中间推理轨迹；
y 是最终答案。

这不是厂商公开的精确网络结构或训练目标，而是一种帮助我们理解可变推理的数学抽象。

它表达的是：

在同一个问题 x 下，不同的推理强度 e，可能让模型形成不同的中间轨迹 z，进而生成不同的最终答案 y。

利用条件概率的链式分解，还可以写成：

Pθ(z, y | x, e) = Pθ(z | x, e) × Pθ(y | x, z, e)

第一部分表示：

在当前问题和推理强度下，模型会形成怎样的推理过程。

第二部分表示：

在这条推理过程的基础上，模型会生成怎样的最终答案。

较低推理强度下，模型通常更倾向于：

快速识别主要模式；
减少搜索分支；
少做重复验证；
更早生成最终答案。

较高推理强度下，模型可能更倾向于：

拆出更多子问题；
探索替代解释；
检查关键假设；
回退并尝试新路线；
在支持工具调用的模型中更积极地调用工具；
延后最终作答。

回到重复扣款的例子。

低推理强度可能迅速锁定“幂等”这一常见原因，并给出通用建议。

高推理强度则可能继续追问：

重复扣款是否真的发生在支付平台？
是同一支付单被扣两次，还是系统生成了两个支付单？
请求是否携带稳定的业务幂等键？
幂等记录是在事务前写入，还是事务后写入？
网关、客户端和消息系统是否各自存在重试？
第三方回调是否可能并发到达？
数据库唯一约束能否作为最后一道防线？
修复方案是否覆盖“扣款成功但响应丢失”的场景？

这不是单纯把答案写得更长，而是展开了更多假设、检查与验证步骤。

已经可以确认的部分

从公开资料和公开模型中，可以较有把握地确认：

推理强度会影响平均推理 Token 使用量；
较高推理强度通常会增加延迟和计算成本；
同一套模型权重可以对不同推理等级进行条件化；
在部分支持工具调用的模型中，推理强度会影响工具调用倾向；
不同任务从额外推理中获得的收益并不相同。

公开权重模型 gpt-oss 支持 low、medium 和 high 等推理等级。公开资料显示，提高推理等级会增加平均思维链长度，并在部分复杂评测中呈现随测试时计算增加而改善的趋势。

API 也可以单独统计 reasoning tokens。降低 reasoning effort，通常能够减少推理 Token，并降低响应时间。

尚未完全公开的部分

闭源模型内部如何把 low、medium、high 转换成具体执行策略，厂商通常不会完整披露。

可能涉及的系统机制包括：

隐藏控制 Token；
不同档位的软性推理预算；
动态停止阈值；
最大工具调用次数；
多候选路径生成；
额外验证器；
解码策略调整；
服务端模型路由。

这些都是合理的工程实现可能性，但不能把它们当成所有闭源模型都采用的确定机制。

所以，把推理强度直接等同于一个固定数字并不准确，例如：

low 等于 500 个 Token，high 等于 5000 个 Token。

真实系统更可能把它实现为一组经过训练和校准的策略。

Reasoning Effort 更像计算策略等级，推理 Token 则是这一策略产生的可观测结果之一。

五、成熟的推理系统，难点不是“多想”，而是“何时停手”

既然额外计算有可能提高质量，为什么不让所有任务都使用最高推理强度？

因为推理存在成本，也存在边际收益。

可以用一个概念模型表示：

U(k) = Q(k) − λC(k)

其中：

k 是已经投入的推理步骤；
Q(k) 是这些步骤带来的预期答案质量；
C(k) 是对应的计算、延迟和工具成本；
λ 表示系统对成本的敏感程度；
U(k) 是综合效用。

是否值得继续推理，可以进一步表示为：

ΔQ > λΔC

也就是说：

只有当下一步推理带来的预期质量提升，仍然大于它产生的额外成本时，继续计算才值得。

这不是厂商公开的精确训练公式，而是用来理解推理预算和停止机制的概念模型。

在低推理强度下，可以把 λ 理解为相对较大。

系统更重视速度和成本，因此更倾向于提前结束。

在高推理强度下，可以把 λ 理解为相对较小。

系统愿意投入更多计算，尝试降低答案的不确定性。

继续分析重复扣款问题时，最初几步通常很有价值：

明确重复发生在哪一层；
找到重试来源；
检查幂等键；
检查唯一约束和事务边界。

但继续无限展开，模型也可能开始讨论：

极低概率的支付平台异常；
与当前架构无关的跨区域一致性；
没有证据支持的网络攻击；
实际系统中根本不存在的组件。

推理停得太早，会漏掉关键条件。

推理停得太晚，又可能把简单问题复杂化，甚至引入新的错误假设。

更高的推理强度也不会自动修复：

错误知识；
错误输入；
错误目标；
错误前提；
缺失的关键数据。

模型思考得更久，可能发现错误。

也可能把错误解释得更加完整。

一个成熟的推理系统，首先要学会的不是不断延长推理链，而是判断：

继续计算还值不值得。

六、哪些任务值得投入更多推理？

推理强度的收益高度依赖任务类型。

下面是一种经验分类，而不是适用于所有模型和所有数据集的统一规律。实际收益仍然需要通过评测确认。

额外推理通常收益较低

信息提取；
文本分类；
格式转换；
改写；
翻译；
简单摘要。

额外推理可能有中等收益

常规编程；
文档分析；
多条件方案比较；
数据解释；
一般性的架构设计。

额外推理更可能获得较高收益

复杂代码调试；
数学与科学推理；
深度研究与交叉验证；
长程 Agent；
多工具协作任务；
错误成本较高的复杂分析。

简单任务的答案路径通常很短。

从邮件中提取日期、把一段内容转成 JSON、判断文本属于哪个分类，都不需要长时间搜索解法。

此时提高推理强度，往往只会增加等待时间和成本。

复杂任务则不同。

例如重复扣款排查，模型需要同时管理多组假设，区分不同系统层，读取日志，检查数据库，甚至调用查询和代码工具。

它的过程更接近：

估计问题范围 → 拆分可能原因 → 获取证据 → 排除假设 → 执行验证 → 修正方案 → 输出结论

这类任务存在更多中间节点，也就有更多机会从额外推理中获得收益。

公开资料也显示，不同任务对推理强度的敏感程度存在明显差异。一些较简单的长上下文检索任务，在低档以上继续增加推理的收益有限；复杂视觉推理等任务则可能获得更明显的提升。

在真实产品中，不能只看答案是否变好，还要衡量：

成功率提高了多少；
响应延迟增加了多少；
推理 Token 增加了多少；
工具调用成本增加了多少；
每一次成功解决问题的综合成本是多少。

更可靠的指标不是“单次答案得分”，而是：

每次成功解决任务的成本 = 全部请求的总成本 ÷ 成功完成的任务数量

以及：

每次成功解决任务的延迟 = 全部请求的总耗时 ÷ 成功完成的任务数量

最优选择通常不是永远使用 high，而是让任务复杂度、错误风险和计算预算相匹配。

七、真正的变化，是模型开始参与计算资源的分配

表面上看，reasoning effort 只是 API 中多了一个参数。

但从更长的时间尺度看，它代表着大模型的一次结构性变化。

过去，我们习惯把模型看成一次性的输入输出函数：

y = Fθ(x)

输入问题，得到答案。

推理模型则越来越像一个持续更新状态的执行过程。

可以用一个抽象公式表示：

sₜ₊₁ = Fθ(sₜ, x, e, oₜ)

其中：

sₜ 是当前任务状态；
x 是用户目标；
e 是推理强度；
oₜ 是工具或环境返回的观察结果；
sₜ₊₁ 是更新后的状态。

这同样是一个概念抽象，不代表某家厂商公开的具体网络接口。

它想表达的是：

系统不再只进行一次输入输出，而是可以形成当前判断、采取行动、读取结果、更新状态，再决定继续还是停止。

在普通问答中，这可能只是多检查几步。

在 Agent 系统中，它可能意味着：

多搜索一次资料；
多读取一份文档；
多执行一次数据库查询；
多运行一轮测试；
根据失败结果重新规划；
调用另一个工具交叉验证。

推理预算控制的，不再只是最终答案之前的一段“思考”，而可能是整个任务执行过程可以使用多少资源。

今天，这个预算常常由用户或开发者手动设置：

low、medium、high

未来，更成熟的系统可能会自行判断：

任务有多难；
当前结论有多不确定；
出错代价有多高；
用户能接受多长延迟；
当前预算允许多少计算；
是否需要外部证据；
是否值得再执行一次验证。

执行过程可能逐渐变成：

估计难度与风险 → 分配初始预算 → 开始执行 → 检查当前不确定性 → 必要时追加计算 → 收益不足时停止

这就是自适应推理。

简单任务快速完成，复杂任务获得更多资源，高风险任务自动增加验证。

从这个角度看，大模型竞争正在出现一个新的维度。

过去比的是谁拥有更强的固定能力。

接下来还要比：

谁能更准确地判断任务难度；
谁能用更少计算完成相同任务；
谁知道什么时候应该继续；
谁知道什么时候应该停止；
谁能把推理、工具和验证组合得更有效。

结语

reasoning effort 调节的，不是模型存储了多少知识，也不只是最终答案写得有多长。

它控制的是模型在当前问题上愿意走多少步、展开多少假设、执行多少检查，以及何时结束。

理解它，可以抓住四层原理。

第一层，模型通过自回归逐 Token 运行：

tₙ₊₁ ~ Pθ(tₙ₊₁ | x, t₁, t₂, …, tₙ)

第二层，中间 Token 可以承载推理过程中的有用信息，形成一条可变长度的计算轨迹：

x → z₁ → z₂ → … → zₖ → y

第三层，推理强度作为控制条件，影响模型选择怎样的推理策略：

Pθ(z, y | x, e)

第四层，系统需要在潜在质量收益与计算成本之间决定继续还是停止：

U(k) = Q(k) − λC(k)

过去，我们问的是：

应该使用哪个模型？

接下来更重要的问题会是：

这件事，值得模型花多少计算去完成？

这才是 reasoning effort 真正值得关注的地方。

它把“思考时间”变成了一个可以训练、控制和调度的系统变量。