采样参数：temperature、top_p，以及它们正在退场

1. temperature 和 top_p 分别在调什么？为什么一般只调一个？
2. temperature=0 能不能保证同样输入同样输出？
3. 新一代模型不让设 temperature 了，那「稳定性」这件事该由谁负责？

一个发票信息抽取服务。为了追求稳定，团队把 temperature 固定成 0，代码注释写着「保证输出确定」。跑了一年，翻了两次车。

第一次：QA 拿同一张发票连跑 20 遍，其中 2 遍的金额字段差了一位小数。开发的第一反应是「不可能，温度是 0」，于是花了两天去查 OCR、查预处理、查网络重试——最后发现这三处都没问题。

第二次（今年）：升级到新一代模型，服务直接 400。报错不是说值不对，是说这个参数不该出现。而 SDK 里字段还在，代码编译得好好的，只有服务端拒。

两次翻车指向同一个认知缺口：把采样参数当成了确定性的保证，而它从来不是；并且到了 2026 年，它连「主要旋钮」都不再是了。

上一篇讲到，模型每一步吐出的是一个在词表上的概率分布。采样（sampling） 就是从这个分布里挑一个 token 的规则。

把模型想象成一个厨师，每一步都端上一桌候选菜，每道菜标了推荐度：

• Temperature（温度） 调的是这桌菜「推荐度差距」的对比度。温度低，差距被放大，最推荐的那道几乎必被选；温度高，差距被抹平，冷门菜也有机会。数学上就是把 logits 除以 T 之后再做 softmax。
• Top_p（核采样 / nucleus sampling） 调的是「允许上桌的范围」。按推荐度从高到低累加，累计概率到 p 就停，后面的直接撤下。
• Top_k 是更粗暴的同类：只留前 k 个候选。
• Greedy decoding（贪心解码）：永远取概率最高的那个，等价于 T→0。

一句话把两者分开：temperature 改分布的形状，top_p / top_k 砍分布的尾巴。

这也正是「一般只动一个」的原因。两个一起收紧，候选很容易被压到只剩一个，输出变得机械重复；两个一起放开，你就不知道是谁在起作用，调参失去可归因性。

def sample(logits, temperature=1.0, top_p=1.0):
    if temperature == 0:
        return int(argmax(logits))              # 贪心：不再随机
    probs = softmax(logits / temperature)       # 改形状
    order = argsort(probs, descending=True)
    cum, keep = 0.0, []
    for i in order:                             # 砍尾巴
        keep.append(i)
        cum += probs[i]
        if cum >= top_p:
            break
    return random_choice(keep, weights=probs[keep])

为什么 temperature=0 也不保证复现——这是本篇最值钱的一段。

贪心解码消除了「采样」这一层随机，但它上游还有一堆不确定：

1. 浮点加法不满足结合律。GPU 上的归约（reduce）顺序会随批次和调度变化，末位差异足以翻转两个接近的 logits 的大小关系；
2. 动态批处理（continuous batching）。你的请求跟谁拼在一个 batch 里，会影响 kernel 选择与计算路径；
3. MoE（专家混合）路由在批内是有交互的；
4. 版本漂移。供应商随时可能对同名模型做小版本更新。

所以准确的表述是：temperature=0 让输出高度稳定，但不等于确定性可复现。 想真复现，得靠固定模型版本号（不要用浮动别名）、把结构交给约束解码、以及最终——把确定性需求下沉到代码里，别指望模型。

表 1：还能调参数时的经验取值

表 2：这层旋钮的退场（2026 年的核心考点）

背后是同一条逻辑：推理型模型在内部要跑多条推理路径再择优，把温度压到 0 会让这些路径塌缩成同一条，反而破坏了机制本身。所以厂商干脆把这个旋钮收了回去。OpenAI 侧的推理模型同样拒绝非默认的采样参数——这不是某一家的选择，是一个行业方向。

避坑清单

1. 别在代码里无条件塞 temperature 字段。 跨模型的网关层要按模型能力白名单剔除参数，否则每次升级模型必炸。这是 2026 年最常见的一类 400。
2. 别把 temperature=0 当「确定性」写进设计文档。 写「高度稳定」，并配一个多次采样一致率的指标。
3. 稳定性的责任要重新分配：格式稳定交给结构化输出（T1-2），事实稳定交给检索与校验，风格稳定交给系统提示词，深度与成本交给 effort。一个参数扛不动四件事。
4. 迁移时要重做效果基线。 参数没了不是「降级」，是控制维度换了一套，旧的调参经验不能直接映射过去。

面试官怎么问。 一面必问基础版（Q1-03）；有经验的面试官会在你答完后立刻追一句「那 temperature=0 能保证复现吗」——这是最经典的一道分水岭；2026 年新增的压力分支是「你依赖 temperature=0 的服务遇到参数被弃用怎么办」。

答题结构建议：形状 vs 尾巴（讲清分工）→ 场景取值（给具体数）→ 反向判断（0 不等于确定性；这层旋钮正在被收回）。第三段是拿分点，前两段只是入场券。

分水岭信号

• 只读过：把 temperature 说成「创造力」；建议「两个都调到 0.2 更稳」；认为 temperature=0 输出必然一致；不知道推理型模型不接受这个参数。
• 真做过：说得出自己项目里两类任务用了不同取值以及是怎么定的；说得出 temperature=0 仍然不一致的具体机制（浮点归约 / 动态批处理 / 版本漂移）；知道跨模型网关要按能力剔参数；能把「稳定性」拆给四个不同的责任方。

一句话收口：temperature 改形状、top_p 砍尾巴，两个都不给你确定性；而在 2026 年，这层旋钮正被 effort 这类「花多少力气」的高层控制取代。

• 关联题目：Q1-03
• 延伸：T0-5（思考档位：从 budget_tokens 到 effort）、T1-2（结构化输出与兜底）、Q6-09（token 成本治理）