推理模型的温度调度：核采样的几个工程取舍

推理模型上线之后，采样参数往往比 prompt 更先被盯上。原因很简单：prompt 改一版要看半天评测，temperature 从 0.6 调到 0.8 只要改个配置。但核采样这套参数在推理模型上的行为和普通聊天模型并不一样，直接照搬「QA 就调低温度」的结论，容易踩坑。

温度改变的是 softmax 之前的 logits

先把机制说清楚。Top-k、top-p 作用在概率分布上，温度则更靠前：它把 logits 除以 T 再送进 softmax，改变的是分布本身的形状。T 越低，分布越尖锐，模型越倾向高概率 token；T 趋近 0 等价于 argmax，无限大则接近均匀采样。这一点在 llm_interview_note 那份解码策略笔记里写得很明确，也给了玻尔兹曼分布的对照。

Top-p 是另一回事。它按概率降序累加，取累积概率达到 p 的最小 token 集合采样，也就是核采样（nucleus sampling）。Top-k 固定取前 k 个，p 的问题在于每个位置的分布形状不同，k 很难有一个全局最优值，top-p 就是对这个缺陷的修正。代码实现上，NucleusSampler 会对概率排序、求累积和、把核外的 logits 置为负无穷，再从核内采样。

如果 top-k 和 top-p 同时开，p 在 k 之后起作用——先截断到前 k，再在剩余集合里找核。这个顺序很多人没注意，导致同时设了两组参数后发现实际候选集比预期小得多。

推理模型的分布让高温更危险

常规聊天模型的输出分布相对宽，温度调高主要是让措辞发散。推理模型不是这样。它在思考阶段大量产出的是收敛性极强的 token，长时间停留在少数几个高概率路径上。这时候把温度往上推，最先被拉回来的不是「更有创造性的解法」，而是那些本已被压到很低的错误分支。

有一篇研究值得看：Exploring the Impact of Temperature on Large Language Models: Hot or Cold? 它系统扫了 0 到 4.0 的温度区间，覆盖因果推理、创造力、上下文学习、指令遵循、机器翻译、摘要六类能力，并按模型规模分层（小 1B–4B、中 6B–13B、大 40B–80B）。结论里最关键的一条是小模型对温度更敏感，高温下性能容易骤降；机器翻译这个任务上，小模型的性能波动可达 192.32%，大模型是 76.86%。论文还验证了 FP16 与 4-bit 量化下温度效应的一致性，并尝试用 BERT 做温度选择器，在 SuperGLUE 上提升了中小模型的表现。

这些数字不是让我们照着抄配置，而是提醒一件事：温度的影响是任务相关、规模相关的，不存在一个「推理模型用 0.7」的说法。更麻烦的是，推理链很长，单个位置的尖峰经过几十步自回归放大，可能让整条链偏离。位置的方差会累积。

按阶段调度，而不是全局设一个值

我在推理服务里更倾向按阶段切温度，而不是整条请求用一个参数。一种常见切法：思考阶段低温甚至接近贪心，保证推理路径稳定；进入最终答案生成后，温度回升到基础模型的常规区间，避免答案过于僵硬、复述思考过程。这个折扣不是理论最优，但它把风险放在最需要确定性的地方。

实现上有两个细节要注意。

• 很多推理框架的 temperature 是请求级的。 想中途切换，要么拆分请求，要么依赖服务端支持按阶段覆盖参数。后者在开源栈上不是默认能力，需要确认接口。
• 阶段边界要显式定义。 靠解析特殊 token 判断阶段是可以的，但不同模型家族的 token 不一样，换模型就要重写判断逻辑。不如在调用层用两个显式请求，代价是推理前缀重复计算，如果前缀缓存能命中，这个代价可控。

还有一个误区：想让推理更「发散」以覆盖多解，不少人会同时拉高 temperature 和 top_p。Prompt Engineering Guide 和多数文档的建议是一致的——这两者改一个就行，同时改会互相抵消，还让线上问题无法归因。真要做多路径采样，那属于并行思维链的范畴，应该按分支设置不同的随机种子，而不是把两个参数一起调高。

一个实验组带给你自己的数据

阿里云开发者社区那篇采样参数文章用 vLLM 跑 Phi-3.5-mini-instruct，演示了如何观察单个位置的概率分布和参数影响。这个思路比背参数表有用得多：挑一批自己的任务样本，对固定的几条 prompt，扫温度网格，每条跑多次，记录准确率、长度分布、重复率，以及解析失败率。

关注指标也别只看准确率。推理模型尤其要看：

1. 推理长度随温度的变化——温度低了，模型可能提前收敛、跳过必要的推导；
2. 终止 token 的稳定性——高温下模型更容易吐出混乱的结束符，导致截断；
3. 格式违规率——需要结构化输出的场景，温度调高后 JSON 解析失败会显著上升。

这些指标都得按模型版本分开统计。同一组温度参数，在 4-bit 量化版本上的行为可能和 FP16 版本不一致，虽然论文验证了效应方向一致，但敏感性阈值未必重合。

一些实际使用时必须留意的点

温度不是万灵药。它只改变概率分布的形状，不引入任何新信息。模型在某个位置上就是不知道，低温和高温都救不了它。把采样参数调优当成提升推理质量的捷径，往往会得到一批在评测集上略好、在真实长尾请求上更不稳定的配置。

另外一点，min-p 这类较新的采样方法出现了，它的思路是相对最高概率设置一个阈值，而不是固定 p。作为动态阈值方案，它缓解了 top-p 在分布尖锐时保留过多尾部 token 的问题。生产环境是否要上，取决于推理框架是否支持。如果没有支持和可靠的对照组，我更倾向先巩固好温度加 top-p 的基础配置，而不是为了一两个点的指标引入新的不确定性。

调度本身也有成本。按阶段切换会增加请求拆分、前缀缓存命中率变化和日志字段复杂度。运维上要能接受多一个阶段的超时兜底和错误分类。如果流量不大，全局温和降温加固定 top-p 可能是更省事的开局。等有了从请求级别记录的温度-结果配对数据，再谈按任务、按阶段精细化调度。