这次我们来看一个和 LLM 推理效率直接相关的研究课题Knowing When to Quit: Diagnosing and Training LLMs to Abort Futile Reasoning。翻译过来就是“教大模型判断什么时候该放弃并通过训练让它真的能在无效推理中及时中止”。它不是在讲怎么让模型“更会推理”而是讲怎么让模型“在推理没有意义的时候停下来”。这个问题恰好是长思维链、Agent 自主推理和规模化推理成本控制里最难处理的部分。从标题拆解这项研究要解决两个核心问题。第一是诊断如何判断一段推理链里哪些 token 属于无效推理futile reasoning也就是“继续推下去也不会改变答案甚至会把答案带偏”的部分。第二是训练如何让模型本身学会在这些位置输出中止信号而不是永远把max_tokens用完。如果读者正在做长思考模型、数学推理任务、Agent 规划或者 LLM 服务成本优化这篇内容值得仔细看。需要提前说明本文是基于论文标题、关键词和 LLM 推理研究的一般路径进行的技术拆解不替代论文原文。论文中的具体数据集、实验配置、训练超参和准确率数字请以原文为准。下面我会把这类研究的常见做法拆成“问题定义、诊断流程、训练方法、评测指标、资源观察、排错清单”六块帮助你先判断这个方向值不值得跟进以及如果自己复现第一步应该做什么。1. 核心结论速览先把整个研究方向的关键信息压成一张表方便快速判断。项目维度说明研究对象LLM 多步推理尤其是数学、逻辑、代码、Agent 规划等长思维链场景核心问题无效推理futile reasoning继续生成推理 token 不提升答案质量甚至降低答案质量论文主张先诊断推理链中的无效推理段再通过训练让模型在无望时主动中止主要方法推理轨迹采样、无效段标注、SFT / 偏好优化 / 过程监督训练推理阶段收益在保持正确率的前提下降低平均 token 消耗、响应延迟和服务成本硬件需求取决于模型规模和训练方式7B 模型 LoRA 微调通常 24G 显存可跑纯推理要求更低启动方式不是一键启动工具需要按实验流程准备模型、数据、推理服务和训练脚本API 能力不直接提供业务 API但可以通过 vLLM 等推理服务批量采样和部署训练后的模型批量能力数据生成、无效段标注、评测阶段都适合批量处理主要风险训练后期模型“过度放弃”导致准确率回退适合读者LLM 训练工程师、推理优化工程师、Agent 成本和延迟优化人员这里没有给出具体显存数字是因为 7B、32B、72B 模型的推理和训练显存差异非常大而且是否量化、是否使用 LoRA、batch size 多大都会直接影响占用。稳妥的做法是先确定模型规模再用nvidia-smi和训练框架的日志观察实际占用。2. 为什么“会放弃”比“能推理”更值得训练先聊一个背景为什么长思维链模型容易出现无效推理。从研究趋势看当前很多 LLM 推理模型都采用“测试时计算”test-time computation策略也就是在最终答案之前生成大量中间推理 token。这种策略在数学、代码、逻辑推理上确实显著提升了准确率。但它有一个副作用模型不知道什么时候该停。同一道题简单题目可能生成几百 token困难题目可能生成几千 token但两者的推理质量不一定和 token 数量成正比。模型经常出现三种浪费行为绕圈反复用不同的说法表达同一个中间结论推理链没有实际推进。自我怀疑刚给出一个结论马上否定然后再次得出同一个结论来回拉锯。越修越错原本已经接近正确答案后续推理把答案改成了错误结果。这和“自我修正可能有害”的结论一致并不是所有修正都有正向收益。这三种行为统称为无效推理。它的危害不只是浪费算力还包括更长的响应延迟、更高的 API 成本和更差的产品体验。当推理服务要按 token 计费时一次多余的 2000 token 推理会直接把单次请求成本翻倍而用户拿到的答案质量并没有变化。这个课题的定位也很清晰。它和 ReAct “推理与行动结合”、DeepSeekMath “在数学推理中用强化学习提升能力”这类工作关注点不同前两者侧重“怎么让模型想得更深”而这个课题关注“怎么让模型在已经想不出新东西时体面地停止”。类比到工程上就是给推理链加一个“止损条件”避免模型在局部最优点上无限震荡。3. 什么是无效推理诊断标准怎么定要训练模型学会放弃第一步不是改模型而是给“无效推理”一个可操作的定义。如果连“什么时候算无效”都无法判定训练数据就没法标注。一个比较稳的定义是在推理链的某个前缀之后继续生成的 token 不再改变最终答案的概率分布或者会把最终答案从正确推向错误那么这段后续推理对当前问题就是无效的。换句话说它没有给问题带来增量信息。实际操作里诊断时通常观察下面这些信号。信号类型可观测特征标注难度答案停滞截取不同长度前缀模型给出的最终答案不再变化低自我重复推理中 n-gram 重复率明显上升论证结构没有推进低原地修正模型反复否定同一结论然后再次得出相同结论中发散漂移推理离题引入与当前目标无关的前提中负向修正从原本正确的答案被“修正”成错误答案高从工程实践看“答案停滞”是最容易被自动化的信号。我们可以在推理链上按固定 token 步长做多次截断每次只保留前一部分然后看模型的答案是否保持不变。如果连续多段答案一致就可以判定后续推理的边际收益为零。这个判断不需要完整跑完整个推理链成本相对低。不过纯规则信号有一个明显缺陷它只能检测“结果不变”不能判断“中间推理是否在错误调整”。所以更完整的诊断方案是引入一个判断器。思路是把模型当前已生成的推理前缀发给一个较便宜的 Judge 模型指令是“仅判断当前推理是否已经具备给出确定答案的条件”输出continue / stop / revise三选一。这样可以把“有没有价值”的判断从规则层面提升到语义层面代价是引入判断器的噪声和额外推理成本。4. 诊断流程从采样到给推理链打标下面给出一套通用诊断流程。我没有绑定某个具体模型和框架路径需要按实际环境替换但整体顺序在大多数 LLM 推理项目中是通用的。第一步构造多步推理评测集。常见选择是数学应用题、逻辑推理题、代码题每个问题至少要有标准答案。第二步采样完整推理链。建议一个问题采样 8 到 16 条使用温度 0.7 左右让推理轨迹有足够多样性。推理服务可以用 vLLM 或兼容 OpenAI 协议的本地服务。# 采样推理链示例OpenAI 兼容接口需按实际环境替换模型名和服务地址 import requests def sample_traces(question: str, n_traces: int 8, base_url: str http://127.0.0.1:8000/v1, model: str your-model) - list[str]: traces [] for _ in range(n_traces): payload { model: model, messages: [{role: user, content: question}], temperature: 0.7, max_tokens: 4096, } response requests.post( f{base_url}/chat/completions, jsonpayload, timeout300, ) traces.append(response.json()[choices][0][message][content]) return traces第三步对每条推理链做前缀截断分析。按固定 token 步长切段每次只保留推理链的前一段输入给模型观察答案是否停滞。def is_prefix_stable(trace_tokens: list[str], answer_extractor, step: int 128, min_steps: int 4) - tuple[bool, int]: 以固定 token 步长截取推理链前缀 如果连续若干段前缀得到的最终答案一致 就认为后续推理的边际收益为零。 这是启发式基线论文级别的诊断通常需要更细的标注器。 answers [] for i in range(step, len(trace_tokens) 1, step): prefix trace_tokens[:i] answers.append(answer_extractor(prefix)) if len(answers) min_steps and len(set(answers[-min_steps:])) 1: return True, i return False, len(trace_tokens)第四步对规则结果做抽样复核。随机抽 20% 样本用人工或者更强的模型判断“这条推理链的哪一段开始变得没有贡献”。这个环节的目的是给诊断规则纠偏避免把合理的多角度论证误判为无效推理。第五步生成标注数据。如果判断器输出stop就把该位置记为停止点如果输出revise则说明模型需要调整方向而不是立刻停止这类样本在训练阶段应该单独处理不能和stop混在一起。这套流程跑完之后你会得到一批带“停止点”的推理轨迹这些数据就是后续训练的主要原料。5. 训练方案让 LLM 学会在无望时中止诊断只是第一步。真正难的是把“知道什么时候该停”变成模型自己的能力。下面按训练成本从低到高介绍三种可行路径。5.1 数据构造把“放弃点”变成监督信号无论用哪种训练方式数据格式都要先定下来。一个典型的三字段结构如下。{ question_id: math_001, question: 一个水池有甲乙两根进水管单开甲管 4 小时注满单开乙管 6 小时注满两管同时开多久注满, trace: [理解题意, 设水池容量为 1, 甲管速度 1/4, 乙管速度 1/6, 合计速度 5/12, 时间 12/5 小时], stop_point: 5, label: should_stop }这里的stop_point来自诊断阶段的标注结果。训练时有两种用法如果做 SFT把完整推理链截断到stop_point并追加一个类似Final Answer:的结束标记让模型学习“在这里收尾是好的”。如果做偏好优化把“提前结束且答案正确”的推理链作为chosen把“绕了很多圈但答案相同或错误”的推理链作为rejected构造配对数据。5.2 SFT 先让模型“见过”正确的停止模式SFT 的目标很直接让模型在相似场景下看到“推理已经收敛”时能够输出一个终止标记而不是继续生成。建议先用一个较小的 LoRA 微调做验证数据量不需要一开始就很大500 到 2000 条高质量轨迹足够看趋势。SFT 的优点是稳定、简单、不容易出现奖励信号噪声。缺点是它只能模仿训练数据里的停止模式泛化能力有限。一个没见过的新题型模型可能仍然不知道什么时候该停。5.3 偏好优化让模型在“继续推”和“停止”之间学会选择偏好优化是更靠近该课题核心的方案。核心思想是构造成对样本让模型偏爱“简短且正确”的轨迹而不是“冗长且无效”的轨迹。{ prompt: 一个水池有甲乙两根进水管单开甲管 4 小时注满单开乙管 6 小时注满两管同时开多久注满, chosen: 设水池容量为 1。甲管速度 1/4乙管速度 1/6合计速度 5/12所以时间是 12/5 小时。Final Answer: 2.4 小时。, rejected: 设水池容量为 1。甲管速度 1/4乙管速度 1/6合计速度 5/12。等等我是不是应该考虑两管同时开的时间是的还是 5/12。我再检查一遍甲 4 小时注满乙 6 小时注满同时开是 12/5 小时。没错最终答案是 2.4 小时。 }用这类数据做 DPO 或类似方法模型的偏好会被向“更少无效 token”的方向调整。这种训练方式的优点是不需要显式设计复杂的奖赏模型缺点是对数据质量敏感。如果rejected轨迹不够典型模型可能学不到“放弃”这个动作只学到“少说话”。5.4 过程监督和强化学习给“每一步”直接打分如果要更精确地控制停止点可以引入过程奖励。基本做法是在 RL 训练中每一步奖励 该步对最终答案的边际增益。如果某一步之后答案没有任何变化则给接近 0 的奖励如果继续推反而导致答案从正确变错误则给负奖励。这种方式最接近论文标题里“诊断 训练”的理想闭环但工程成本最高。你需要一个可靠的逐步验证器、稳定的 RL 训练框架还要处理奖励噪声。对团队来说建议在前两种方式看到明确效果后再上。5.5 训练注意事项最需要警惕的是“过度放弃”。模型一旦学会尽早停止就可能在推理链刚刚开始、答案还没稳定时直接收尾造成准确率回退。解决思路有两个第一在偏好数据里保留一部分“必须长推理才能做对”的困难样本让模型知道哪些场景不该放弃第二训练完成后做一次重启点扫描对比不同放弃阈值下的准确率和 token 数选择折中点。6. 评测不只看到准确率还要看 token 效率训练完成后评测不能只看准确率。如果一个模型准确率不变但平均推理 token 从 1800 降到了 600这是很大的收益。反之如果准确率掉了 2 个百分点token 降了 60%那就要判断这 2 个百分点是否可接受。推荐建立三个核心指标。指标含义统计方式Accuracy答案正确率正确答案数量 / 总样本数Avg Reasoning Tokens平均推理 token 数总推理 token / 总样本数Token Efficiencytoken 转化效率Accuracy / Avg Tokens越高越好def compute_efficiency(results: list[dict]) - dict: results 中每个元素包含 correct 和 tokens 两个字段。 返回准确率、平均 token 和 token 转化效率。 total len(results) correct sum(1 for r in results if r[correct]) acc correct / total avg_tokens sum(r[tokens] for r in results) / total token_per_point avg_tokens / max(acc, 1e-6) return { accuracy: acc, avg_tokens: avg_tokens, token_per_point: token_per_point, }除了这些总体指标建议额外统计两个行为指标放弃率多少比例的样本在诊断标记点之前就结束推理。放弃率过高可能意味着模型“不敢想”。放弃后的正确率模型提前结束的那些样本里答案正确的比例。这个指标能反映放弃是否发生在正确时机。评测集不要只用单一类型。数学题、逻辑题、多跳问答、Agent 规划任务都应该覆盖一部分因为不同任务的最优推理长度差异很大。一个在数学题上学到“及时停止”的模型放到需要多步工具调用的 Agent 场景里可能根本不适用。7. 实验资源与运行成本观察如果准备复现这个方向资源规划按三个阶段来看。第一阶段是数据生成和诊断。这一步主要消耗推理算力。建议先拿一个 7B 或 14B 模型跑通流程单卡即可。采样 8 到 16 条轨迹、每条最长 4096 token跑 200 道题总 token 量大概在百万级别用 vLLM 批量跑一张 24G 显存显卡完成整个采样和诊断通常可行。这里没有给精确数字因为模型量化方式、并发参数和重复采样次数都会影响实际耗时。第二阶段是训练。先做 LoRA7B 模型在 24G 显存上起步比较稳妥。如果显存吃紧可以降低 batch size、开启梯度累积、使用 4bit 量化。全参数微调建议放到多卡环境单卡很容易在序列长度 4096 时显存溢出。第三阶段是评测和部署。推理阶段可以用 vLLM 起一个服务批量请求并发评测。重点关注两个数字响应平均延迟和服务吞吐。如果把 1800 token 的冗余推理降到 600 token在同等并发下吞吐能明显提升这是这个方向最直接的工程收益。观察资源占用时不要只盯训练曲线。用nvidia-smi记录显存峰值用推理服务日志记录每轮请求的输入输出 token 数。如果批量任务卡住优先检查是不是服务端max_tokens设置过小导致请求被截断以及并发数是否超过 GPU 容量。8. 常见问题与排查方法这个方向容易踩的坑集中在数据标注、训练稳定性和评测口径三块。问题现象可能原因排查方式解决方案模型训练后准确率明显下降偏好数据里“简短错误”样本太多模型学会了草率收尾检查 chosen / rejected 对中正确率分布增加困难样本限制放弃触发场景模型几乎不放弃训练数据里停止点标注过晚模型没有学到早期停止信号统计 stop_point 分布重新诊断把停止点标注前移判断器输出不稳定同一个前缀多次判断结果不同判断器本身噪声大对同一前缀采样多次取投票换成更强判断器或者降低判断温度规则诊断把多角度论证误判为无效只用了答案停滞信号没有看推理内容抽样复核被标记为 futile 的样本引入语义判断器用“是否有增量信息”代替单纯答案比较训练时显存溢出序列过长或 batch size 过大查看训练日志和 nvidia-smi减小 batch size、开启梯度累积、用 LoRA 或 QLoRA批量推理请求超时单条推理链太长服务端处理不过来查看服务端日志的 token 数和时延缩短 max_tokens或拆成多个并发批次DPO 训练不稳定配对数据包含相似文本偏好信号不明显计算 chosen 和 rejected 的文本相似度过滤相似度过高的样本确保对比足够鲜明另外如果训练后模型在简单题目上表现正常但在困难题目上频繁放弃大概率是数据构造阶段把“放弃信号”和“题目难度”错误地关联了。建议在训练集里对题目难度做分层保证简单题和困难题各占合理比例。9. 最佳实践与合规边界整套方案落地时建议遵守下面几条工程规范。第一先小规模跑通闭环。不要一开始就上 70B 模型全参数训练。先用 7B 模型、200 道题、500 条轨迹把采样、诊断、标注、微调、评测的完整链路跑一遍确认每个环节的输出格式都正确再扩大规模。第二数据目录要严格分开。原始推理链、诊断结果、训练数据、评测结果、模型输出分别放在独立目录文件名带上版本号。无效推理诊断这种环节非常依赖数据可追溯性一条轨迹来自哪个模型、哪个温度、哪次采样都应该能查回来。第三批量任务必须加日志和断点恢复。采样 5000 条推理链时任何一次网络抖动或服务重启都可能中断任务。建议按文件粒度写入结果而不是全部存在内存里最后统一落盘。每完成一批写入一个 JSONL 文件重跑时跳过已有数据。第四推理服务要限制访问范围。如果部署在服务器上服务端口不要直接暴露到公网用本地回环地址或内网访问。训练脚本里的数据路径不要硬编码绝对路径避免换机器后脚本不可用。第五合规边界必须重视。如果推理链来自真实用户问题诊断和训练时要注意隐私涉及个人数据、商业数据或受版权保护的内容需要先做脱敏和授权确认。如果这个方案用在 Agent 产品中让模型“放弃推理”可能导致任务提前终止发布前需要人工复核低置信度输出防止模型在关键任务上过早收尾造成业务损失。10. 总结与下一步这个课题最值得尝试的地方是它把“推理质量”从单纯的“答案对不对”扩展到了“推理过程值不值”。对于正在做长思考模型和 Agent 成本控制的团队来说一个能让模型在无望时主动放弃的训练方案可以直接转化为延迟下降和 token 成本下降。如果要开始复现最先跑的实验不是训练而是诊断。拿一个 7B 模型选 200 道多步推理题采样几千条推理链画出“推理 token 数”和“答案稳定性”的关系曲线。曲线会直接告诉你哪些问题类型里存在大量无效推理哪些问题本来就不需要长推理。这一步成本最低信息量最大。最容易踩的坑是过度放弃。训练目标里只要存在“减少 token”的信号模型就会想方设法走捷径。解决办法是在数据和评测层面同时设防数据里保留足够多的困难样本评测里同时监控放弃率和放弃后的正确率。后续可以扩展的方向包括把诊断器和训练器做成联合优化让模型在推理过程中动态决定是否切换策略给推理链加上置信度校准让“放弃”动作和模型自身的不确定性对齐以及在 Agent 多步工具调用场景中测试这套方法因为 Agent 场景的无效推理成本更高收益也可能更大。建议收藏备用。这个方向如果跑通对 LLM 推理效率优化的参考价值会持续很久。