大模型推理强度控制：从test-time scaling到Agent动态调度实战

1. 推理强度不是“温度”能调出来的东西很多人第一次接触大模型推理控制脑子里蹦出来的第一个旋钮就是 temperature。调高一点显得有创意调低一点显得严谨——这套逻辑在早期聊天场景里勉强够用但一旦进入复杂推理任务比如多步数学证明、代码调试、Agent 长链路规划你会发现 temperature 几乎帮不上忙。原因很简单temperature 控制的是采样分布的随机性而不是模型在得出答案前愿意花多少算力去思考。这两件事在本质上是正交的。一个模型可以用极低的 temperature 输出一个完全错误的答案因为它压根没往深了想也可以用较高的 temperature 在多个候选路径中反复试探最终收敛到正确答案。前者是“确定性犯错”后者是“随机性探索后成功”。推理强度inference intensity要解决的是后者——让模型在测试阶段动态决定投入多少计算资源。这个方向在学术界通常被归入test-time scaling的范畴。它的核心命题是模型的能力不只在参数里还在推理时分配的计算预算里。同一个模型给它 100 个 token 的思考空间和给它 10000 个 token 的思考空间表现可能天差地别。OpenAI 的 o 系列、DeepSeek 的 R1 系列本质上都在做这件事——把“思考深度”变成一个可调节、可训练的维度。所以这篇文章不打算泛泛聊“怎么让模型更聪明”而是聚焦一个工程问题在实际系统里我们有哪些手段去控制大模型的推理强度各自的代价是什么什么场景该用哪种。关键词里的 test-time scaling、RL、Agent 三条线会贯穿始终因为它们是当前控制推理强度的三大支柱。2. 从 token 预算到思考深度推理强度的四层控制手段2.1 第一层输出长度约束——最粗暴但最直接最原始的控制方式就是限制模型能生成多少 token。max_tokens这个参数几乎每个 API 都有但大多数人只把它当成“防止无限输出”的保险丝没意识到它其实是一个推理强度旋钮。当你把max_tokens从 512 提到 4096模型在数学题上的准确率往往会有肉眼可见的提升。原因在于现代大模型在预训练和后训练阶段已经学会了“用更多 token 换更高正确率”的模式。给它足够的空间它会自发地展开中间步骤、做验算、尝试不同路径。你可以在 prompt 里明确要求“先写出完整推理过程再给答案”配合足够的max_tokens效果立竿见影。但这一层的局限也很明显模型不一定“均匀地”使用这些 token。有些简单问题它可能 200 token 就答完了有些难题它写到 4000 token 还在绕圈子。你没法精确控制它在每个子问题上花多少力气。而且长输出带来的延迟和成本是线性的——token 翻倍费用和等待时间基本也翻倍。实操心得在批量推理场景里我习惯给max_tokens设一个偏大的值比如 2048同时在 prompt 末尾加一句“如果问题简单直接给答案如果复杂展开推理”。这样模型自己会做粗粒度的预算分配比一刀切设小值要好得多。2.2 第二层思维链与结构化思考模板比单纯给 token 更进一步的是用 prompt 结构去引导模型的思考路径。这就是大家熟悉的 Chain-of-ThoughtCoT及其变体。但很多人对 CoT 的理解停留在“加一句 lets think step by step”这其实只用了它 10% 的威力。真正有效的做法是把思考过程结构化。比如在 Agent 场景里我会要求模型按固定格式输出[分析] 问题拆解为哪几个子问题 [计划] 每个子问题打算用什么方法 [执行] 逐步计算或推理 [验证] 回头检查关键步骤 [结论] 最终答案这种结构化模板的好处是它强迫模型在每个阶段都分配一定的“思考预算”而不是一股脑往前冲。实测下来在数学和逻辑题上结构化 CoT 比自由 CoT 的准确率能高出 10 到 15 个百分点。更进阶的做法是self-consistency让模型用不同的推理路径多次回答同一个问题然后投票选最一致的答案。这本质上是用采样次数来换推理强度。代价是推理成本翻 N 倍但在离线场景比如批量数据处理里非常划算。2.3 第三层RL 训练出的“思考模式”前面两层都是在推理时做文章第三层则是在训练阶段就把“如何分配思考强度”内化到模型权重里。这就是 RL强化学习路线也是 o1、R1 这类模型的核心。具体来说训练流程大致是这样的模型在大量难题上生成多个候选答案根据最终正确与否给出奖励信号然后用 PPO 或 GRPO 之类的算法更新策略。关键在于奖励不仅看答案对不对还看推理过程是否高效。如果模型用 5000 token 绕了一大圈才得出正确答案而另一个路径只用 800 token 就直达答案后者会获得更高的奖励。经过这种训练模型会学会一种“元认知”能力遇到简单问题快速作答遇到难题自动展开长链条思考。你不需要在 prompt 里手动加“请仔细思考”它自己就知道什么时候该想、什么时候该答。但这一层的门槛很高。你需要有高质量的难题数据集、稳定的 RL 训练框架、大量的 GPU 算力。对于大多数团队来说直接使用已经训练好的推理模型如 DeepSeek-R1 系列、QwQ 系列比自己训更现实。关键词里提到的“大模型微调实战”“qwen2.5-7b 微调行业大模型”其实就和这条线相关——如果你有特定领域的难题可以在开源推理模型基础上做 SFT 或轻量 RL把领域内的思考模式固化进去。2.4 第四层Agent 架构下的动态计算分配到了 Agent 场景推理强度的控制就变成了一个系统级调度问题。一个 Agent 可能需要在一次任务中调用多次模型规划一次、执行多次、反思一次、修正一次。每次调用的推理强度可以不同。我的做法是给 Agent 的每个阶段配置不同的“思考预算”阶段推荐推理强度典型 max_tokens说明任务规划高1024-2048需要拆解复杂目标值得多花算力工具调用参数生成低256-512格式固定不需要深度思考结果验证中512-1024需要一定判断力但不需要长链条错误反思与重规划高1024-2048需要分析失败原因重新规划这种分层策略能把整体推理成本压下来 40% 以上同时不牺牲关键环节的质量。关键词里的“agent 架构”“agent 记忆”“agent 开发学习路线”都和这个思路有关——Agent 的智能不仅体现在单次推理多强更体现在知道什么时候该用力想、什么时候该快速过。3. test-time scaling 的工程账本多花算力到底值不值3.1 推理强度与准确率的边际曲线test-time scaling 有一个残酷的现实边际收益递减。从 512 token 加到 2048 token准确率可能从 60% 跳到 85%但从 2048 加到 8192可能只从 85% 爬到 89%。多出来的 6000 token 换 4 个百分点在很多场景里是不划算的。我做过一组实测用同一个模型在 GSM8K 数学题上跑不同max_tokensmax_tokens准确率平均延迟相对成本25652%1.2s1x51271%2.1s1.8x102483%3.8s3.2x204888%7.5s6.3x409690%14.2s12x可以看到1024 是一个比较甜的平衡点。再往上加成本涨得比准确率快得多。当然这个曲线会因模型和任务而异但“先快速找到拐点再决定预算”这个思路是通用的。3.2 什么任务值得高推理强度不是所有任务都值得让模型“深思熟虑”。我一般用三个维度来判断错误代价如果答错了后果严重比如代码生成、医疗建议、财务计算那就值得多花算力。问题复杂度需要多步推理、跨领域知识整合的任务推理强度收益大简单分类、抽取、翻译收益很小。延迟容忍度离线批处理可以慢慢想实时对话就得控制思考时间。一个实用的判断规则如果人类专家做这个任务也需要停下来想很久那模型也值得多花 token。反之如果人类扫一眼就能答模型加再多思考预算也提升有限。3.3 用 RL 信号反向指导推理预算一个比较前沿的做法是训练一个轻量级的“难度预测器”在推理前先判断这个问题需要多少思考预算。这个预测器可以是一个小模型也可以是基于规则的特征工程比如问题长度、涉及的知识领域、是否需要计算。更优雅的方式是在 RL 训练中让模型自己学会“什么时候该停”。DeepSeek-R1 的论文里提到模型会自发地在简单问题上缩短思考链在难题上延长。这种自适应能力是训练出来的不是 prompt 出来的。对于没有 RL 训练能力的团队可以用一个折中方案先用小max_tokens跑一遍如果模型输出里出现“不确定”“需要更多信息”之类的信号再用大max_tokens重跑。这种两阶段策略能在成本和准确率之间取得不错的平衡。4. Agent 场景下的推理强度调度实战4.1 为什么 Agent 比单轮对话更需要强度控制单轮对话里推理强度就是一个max_tokens的事。但 Agent 不一样——它可能在一个任务里调用模型十几次每次的推理需求都不同。如果每次都按最高强度跑成本会爆炸如果都按最低强度跑关键决策环节又会掉链子。我踩过的一个坑是早期做 Agent 时所有模型调用都用同一个配置结果规划阶段想得不够深导致后续执行全跑偏而工具调用参数生成阶段又浪费了大量 token 在无意义的“思考”上。后来改成按阶段配置整体效果和成本都好了很多。4.2 规划阶段的“深度思考”配置Agent 的规划阶段是最值得投入推理强度的地方。我的配置通常是max_tokens: 2048temperature: 0.3-0.5需要一定探索性但不能太随机prompt 里明确要求输出结构化的任务分解关键技巧是要求模型输出多个候选计划然后选一个最合理的执行。这本质上是在规划阶段做 self-consistency。虽然多花了几倍 token但规划错了后面全错这个投入是值得的。4.3 执行阶段的“快速通过”策略到了具体执行阶段大部分操作是确定性的调用 API、格式化参数、解析返回结果。这些不需要深度思考max_tokens设 256-512 就够了。我甚至会用一个更小的模型来处理这些步骤把大模型留给真正需要推理的环节。关键词里的“agent 框架”“agent 开发”其实都在强调这种分层思想。一个好的 Agent 框架应该允许你为每个节点单独配置推理参数而不是全局一刀切。4.4 反思阶段的“回溯验证”Agent 执行失败后的反思阶段推理强度要重新拉高。模型需要分析哪一步出了问题是规划错了还是执行错了有没有替代方案这个阶段我通常给 1024-2048 token并且要求模型输出具体的失败原因和修正计划。一个实用技巧是在反思 prompt 里附上之前的执行轨迹trace让模型基于事实反思而不是凭空猜测。这能显著提高反思质量减少“幻觉式反思”。5. 本地部署与微调中的推理强度调优5.1 本地推理框架的参数映射关键词里出现了“ollama 本地部署大模型”“llamacpp 部署大模型”“ai 大模型本地部署配置”这些场景下控制推理强度的方式和 API 调用略有不同。以 llama.cpp 为例除了n_predict对应 max_tokens还有几个参数会影响推理行为top_k/top_p控制采样范围间接影响模型是否愿意探索不同推理路径repeat_penalty防止模型在长思考链里反复绕圈子n_batch批处理大小影响推理速度但不影响质量Ollama 的 Modelfile 里可以设置num_predict和temperature但更细粒度的控制需要直接调 llama.cpp 的 API。我的经验是本地部署时把num_predict设大一点比如 2048配合repeat_penalty1.1 左右能在长推理和防重复之间取得平衡。5.2 微调时如何注入“思考强度”信号如果你在做领域微调关键词里的“大模型微调”“qwen2.5-7b 微调行业大模型”可以在训练数据里显式标注思考强度。比如简单样本answer直接答案/answer复杂样本thinking详细推理过程/thinkinganswer最终答案/answer这样训练出来的模型会学会根据问题难度自动切换模式。更进一步可以在数据里加入“思考预算”标签让模型学会在有限 token 内完成推理。但要注意微调数据里的思考过程必须是高质量的。如果推理链本身有错模型会学会错误的思考模式反而降低推理强度带来的收益。5.3 量化对推理强度的影响一个容易被忽略的点是模型量化会影响推理强度。4-bit 量化的模型在长链条推理上往往比 fp16 更容易“断片”——推到一半忘了前面在说什么。如果你打算让模型做高强度推理建议至少用 8-bit 量化或者干脆用 fp16。关键词里的“rx6750gre 训练大模型”“gpu 微调大模型”也涉及硬件对推理强度的制约。显存不够时你没法开大 batch 也没法跑长上下文推理强度自然受限。这种情况下与其硬堆 token不如把问题拆小分多次推理。6. 那些没人告诉你的推理强度陷阱6.1 过度思考导致的“分析瘫痪”推理强度不是越高越好。我见过模型在简单问题上写了 3000 token 的“思考过程”最后答案还是错的——因为它想太多了把自己绕进去了。这在 RL 训练过的推理模型上尤其常见它们有时候会“为了思考而思考”。判断标准很简单如果模型的思考链长度远超问题本身的复杂度那就是过度思考。这时候需要降低max_tokens或者在 prompt 里加一句“简明扼要地回答”。6.2 思考链里的“幻觉传播”长思考链有一个隐蔽的风险前面某一步的幻觉会沿着链条传播最终导致错误答案。而且因为思考过程看起来很有条理用户容易误以为答案可靠。缓解办法是在思考链的关键节点插入验证步骤。比如每推三步就要求模型“回头检查前两步是否正确”。这会增加 token 消耗但能显著降低幻觉传播的概率。6.3 推理强度与安全性的权衡一个比较少被讨论的点是高推理强度可能让模型更容易被“越狱”。因为长思考链给了模型更多空间去“合理化”不当请求。在实际部署中我通常会在高推理强度场景下加一层输出过滤或者在 system prompt 里强化安全约束。6.4 成本失控的隐形杀手最后说一个工程上的坑推理强度的成本不是线性的。因为长输出会占用更多 KV cache导致并发能力下降。在高峰期一个高推理强度的请求可能阻塞后面十个普通请求。所以生产环境里一定要做分级限流——高推理强度请求走独立队列避免影响整体吞吐。7. 我个人的推理强度配置清单经过一年多的折腾我目前在生产环境里的默认配置是这样的普通对话max_tokens512, temperature0.7不强制 CoT数学/逻辑题max_tokens2048, temperature0.3强制结构化 CoT代码生成max_tokens1536, temperature0.2要求先写思路再写代码Agent 规划max_tokens2048, temperature0.4输出多候选计划Agent 执行max_tokens384, temperature0.1只输出工具调用参数Agent 反思max_tokens1536, temperature0.5附执行轨迹这套配置不是最优解但在我经手的几个项目里表现稳定。核心思路就是一句话把推理强度当成一种稀缺资源来分配而不是一个全局开关。如果你刚开始接触这个方向建议先从max_tokens和结构化 CoT 入手这两个改动成本最低、收益最明显。等跑顺了再考虑引入 RL 训练的推理模型或者做 Agent 级别的动态调度。关键词里那些“大模型学习路线”“agent 开发学习路线”的内容其实最终都会落到这个点上——不是模型越大越好而是在正确的地方花正确的算力。