When2Think: 学习难度感知的长度控制以实现高效混合推理模型

TL;DR 提出 When2Think 框架，通过难度感知奖励塑造让模型对简单题直接作答、对难题保留深度推理，在 AIME24 上 Pass@3 提升 10.0% 且 token 减少 27.9%，缓解大推理模型的过思与欠思问题。

问题

问题背景

大推理模型（Large Reasoning Models, LRMs）在数学、代码等复杂任务上表现突出，但推理效率 成为部署瓶颈：模型往往在简单题上生成过多中间步骤（overthinking），在难题上又过早收敛于错误答案（underthinking）。

现有方法局限

主流方案分为两类：

• 统一长度惩罚：对生成 token 数施加全局正则，简单题变短的同时也压缩难题必要推理深度，导致困难样本准确率下降。
• 刚性路由：用固定阈值或分类器决定是否开启思考模式，但阈值与分类器依赖训练分布，面对难度漂移时误判率高，且无法细粒度控制推理长度。

二者共同问题是效率税（efficiency tax）：节省的计算量与准确率损失不成比例，缺乏实例级别的难度感知与连续控制信号。

为什么这个问题难/重要

难度标签并非显式存在，只能从参考统计（如多次采样准确率、平均 token 数）间接估计；而正确率与推理长度 是多目标冲突，过短导致欠思考，过长造成资源浪费。业界在推理 API 成本与延迟压力下，迫切需要一种稳定、无需额外奖励模型（critic-free）的在线优化方法，同时避免训练过程中的优势估计崩溃。

行业类比

这一挑战类似于自适应推理服务：根据输入问题复杂度动态选择 early-exit 或全量 Transformer 计算，在保证准确率的同时降低 GPU 成本与端到端延迟。

核心洞察

• 把高效推理从“统一长度惩罚或固定路由”重构为“逐实例难度自适应计算分配”，消除了原有方法在简单题上节省计算、却在难题上损失精度的效率税。现有压缩或路由方法对所有样本施加同一约束，抹平难度信号；When2Think 使用预计算参考统计（accuracy 与 token usage）作为难度先验，通过 IDAC 奖励塑形让策略在简单实例上直接回答、在困难实例上保留长链推理，从而在 AIME24 上 Pass@3 提升 10.0%、token 用量下降 27.9%。
• When2Think 提出无 critic、无学习奖励模型的稳定优化组合：IDAC 奖励塑形 + 可验证奖励 + 批量标准化优势（BWS），避免了在线参考模型查询与奖励模型训练的额外成本。与 GRPO 等组内标准化方法不同，BWS 在 batch 内保留跨实例难度全局信号，不压低难题的相对优势；IDAC 仅依赖离线预计算统计，深度控制信号主要来自 IDAC 与 BWS，而非重要性采样，消融显示 IS 主要改善效率而非精度。

方法

输入

When2Think 的输入是**大规模推理模型（LRM）**在数学推理任务上的生成结果与对应奖励信号。训练数据包含问题、模型生成的推理轨迹（分为 Think 与 NoThink 两种模式），以及源自数学验证器的二元正确性反馈。

关键模块

1. 参考统计与难度表征
   预计算每个问题的参考准确率与参考 token 用量，将其组合为实例难度信号。难度信号决定该问题应分配的计算预算：简单问题倾向直接回答（System 1），困难问题倾向延长推理（System 2）。

2. Instance-level Difficulty-Aware Control (IDAC)
   核心奖励塑形机制。IDAC 将难度信号转为奖励修正项：当模型在简单问题上使用过长推理时给予负奖励，在困难问题上推理不足时同样惩罚，从而引导模型学习与难度匹配的推理深度。该机制不依赖在线参考模型或学习式奖励模型，仅使用预计算统计量。

3. Instance-Adaptive Reward
   最终奖励由两部分组成：数学验证器给出的正确性奖励 + IDAC 奖励项。两者通过系数平衡，使模型在保持准确率的同时提升效率。

4. Batch-Wise Standardized Advantage (BWS)
   替代 GRPO 等基于群体相对优势的方法。BWS 对每个 batch 内的奖励进行标准化处理，保留跨实例的全局难度信号，避免 GRPO 因组内比较而丢失难度结构。该技术稳定了无 critic 的优化过程，并提升样本效率。

输出

训练得到的混合推理策略：模型能根据问题难度动态选择 NoThink（直接生成答案） 或 Think（多步推理），在简单实例上显著降低 token 消耗，在困难实例上保持甚至提升准确率，实现“右上角”的准确率-效率权衡改进。

与同类方法的差异

不同于统一长度惩罚或刚性路由（它们会引入 efficiency tax，即在简单实例上节省计算却牺牲困难实例精度），When2Think 通过实例级难度感知的连续控制和批量标准化优势，实现了无效率税的自适应计算分配。

实验

实验设计概述

论文提出 When2Think，一种混合推理后训练框架，核心是 Instance-level Difficulty-Aware Control (IDAC) 奖励塑形，利用预计算的参考统计量（准确率与 token 使用量）调节推理深度。训练结合 verifier-based rewards 与 batch-wise standardized advantages，实现无 critic 模型的稳定优化。评估在多个数学基准上进行，包括 AIME24、AIME25、GSM-Plus、MATH-500 等，并与压缩类与路由类基线对比。

关键结果

在 AIME24 上，Pass@3 提升 10.0%，同时 token 使用量降低 27.9%（相对 base model），实现了准确率-效率的右上角改进。AIME25 上取得 40.0% Pass@3，优于压缩与仅路由基线。消融表明 IDAC 提供难度感知的深度控制信号，BWS 稳定优化过程，IS 主要在效率而非准确率上起作用。案例分析显示，When2Think 能在简单问题上偏向 System 1 (NoThink) 直接回答，在困难问题上保留 System 2 (Think) 扩展推理。

与基线的对比解读

与 uniform length penalties 或 rigid routing 相比，When2Think 避免了 efficiency tax：前者对简单问题过度惩罚或对困难问题造成精度损失，属于压缩式思路；后者固定分配推理模式，无法按实例难度动态调整。When2Think 通过奖励塑形鼓励简单实例直接回答、困难实例持续推理，学习的是 何时思考 的元策略，而非单纯压缩或路由，因此能在不牺牲困难实例精度的前提下显著降低整体 token 消耗，适合部署在延迟敏感且难度分布不均的场景。

行业影响

落地场景

When2Think 适用于所有部署 large reasoning models 的推理型 API 与对话式 AI 产品。典型场景包括:

• 电商智能客服: 高频的退换货、物流查询等简单问题直接走 System 1 快速响应; 涉及多方责任判定的复杂纠纷触发 System 2 深度推理。
• 金融合规审查: 规则明确的交易监控用浅层模式匹配即可; 复杂关联交易、可疑网络分析则调用长链路推理。
• 教育解题助手: 基础算术题直接给出答案; 竞赛级数学题保留多步证明。

商业价值

核心收益在降本与体验提升两条线:

• 在 AIME24 上 token 消耗减少 27.9%, 直接对应 GPU 推理成本与 API 延迟下降, 提高服务吞吐。
• 同时 Pass@3 提升 10.0%, 意味着硬问题上减少 underthinking 导致的错误, 降低人工复核与用户流失。
• 避免了 uniform length penalty 的 efficiency tax: 不会为了省 token 而牺牲难题准确率, 可支撑按难度分级的 SLA 定价。

与现有产品/工作流接口

When2Think 是 post-training 框架, 无需改动模型架构或推理引擎:

• 基于 verifier-based rewards 与预计算的 reference statistics 构造 IDAC 奖励, 不需要额外训练 reward model 或在线查询 reference model。
• 可直接集成到现有 RLHF/GRPO 训练流水线, 用 BWS 替代标准 advantage 计算。
• 部署时保持同一模型响应所有请求, 推理服务无需区分 System 1/2, 由模型内部决定思考深度, 对 vLLM/SGLang 等 serving stack 透明。
• 相比 routing-only 基线, 不需要训练额外 router, 避免 router 误判带来的 latency/accuracy 抖动。

局限

• 方法依赖预计算参考统计（reference statistics），这些统计来自基模型在训练样本上的 token 用量和准确率，但获取这些统计本身需要额外的推理成本，且在任务分布偏移时可能变得不准确。论文未深入讨论参考统计的更新策略或对分布外难度的鲁棒性，这限制了方法在动态变化的生产环境中的实用性。
• 虽然 When2Think 声称 critic-free、不依赖 learned reward model，但仍需要 verifier-based rewards（双数学验证器）来计算序列级奖励。数学领域的验证器容易构建，但推广到自然语言推理、开放域问答或代码生成等难以自动验证的任务时，方法可能失效或需要昂贵的人工标注反馈，削弱了其通用性。
• 实验主要在 AIME24、AIME25 等数学基准上评估，且指标偏向 token 使用量和 Pass@3，缺少对推理延迟、显存占用、批量处理吞吐等实际部署指标的测量。此外，与 compression 和 routing-only baselines 的对比细节较少，难以判断改进是否源自特定实现选择而非核心方法。