同一个模型，为什么每次回答不一样？

你把同一句话发给大模型，第一次回答很稳，第二次换了个说法，第三次甚至突然跑偏。很多人会把这种差异归因于“模型有随机性”，但真正控制这份随机性的，往往就是 Temperature、Top-K 和 Top-P。

这三个参数都发生在推理阶段。它们不会重新训练模型，也不会给模型增加知识，只是在模型已经算出的候选 token 里，改变“谁更容易被选中、谁有资格进入候选池”。

一、模型生成文字，其实是在不断做选择题

大模型不是一次性把整段话写出来，而是一个 token 一个 token 地往后生成。每一步，它都会为词表中的所有 token 计算一个原始分数，这个分数叫 logits。经过 Softmax 后，logits 会变成总和为 1 的概率分布。

例如输入“周末去公园……”，模型可能认为“散步”最合适，“跑步”“拍照”“野餐”也说得通，而“量子”“关机”明显不合语境。概率分布表达的，就是模型对这些候选的相对信心。

如果每次都直接选概率最高的 token，就是贪心解码；如果按概率进行随机抽取，就是采样。Temperature、Top-K 和 Top-P 的作用，就是在采样前改造这份概率分布。

二、Temperature：控制概率分布有多“尖”

Temperature 的中文一般叫温度。它不会直接规定要选几个 token，而是先改变每个 token 的相对概率。常见写法如下：

pᵢ(T) = exp(zᵢ / T) ÷ Σⱼ exp(zⱼ / T)

其中 zᵢ 是第 i 个 token 的 logit，T 就是 Temperature。直观理解：

• T < 1：概率分布被压得更尖，高概率 token 更占优势，输出更稳定。

• T = 1：保持模型原始概率分布。

• T > 1：概率分布被摊得更平，低概率 token 也获得更多机会，输出更丰富。

在许多推理框架中，Temperature 只有在采样模式开启时才会生效。以 Hugging Face Transformers 为例，需要启用 do_sample；在 vLLM 等框架中，Temperature 为 0 通常会切换为贪心生成。具体行为仍应以当前模型和推理服务文档为准。

三、Top-K：固定保留概率最高的 K 个候选

Top-K 的做法非常直接：把 token 按概率从高到低排序，只保留前 K 个，剩下全部过滤掉，然后在保留下来的候选里重新归一化并采样。

它的优点是简单、速度快，能有效避免从词表长尾中抽到非常离谱的 token。但它也有一个天然局限：K 是固定的。

当模型对答案非常确定时，可能只需要 1～3 个合理候选，Top-K=50 会保留太多无意义选项；当任务非常开放时，合理候选可能很多，固定的 K 又可能把好选项提前裁掉。

四、Top-P：让候选池跟着上下文自动变化

Top-P 也叫 Nucleus Sampling，中文常译为核采样。它不是固定保留多少个 token，而是从概率最高的 token 开始累加，直到累计概率达到阈值 P，保留这个最小集合。

Top-P=0.9 的含义不是“保留 90% 的词表”，而是“保留累计概率达到 90% 的最小候选集合”。候选集合可能只有一个 token，也可能有几十个 token。

这就是 Top-P 相比 Top-K 更灵活的地方：模型越有把握，候选池越小；模型越犹豫，候选池越大。Holtzman 等人在 Nucleus Sampling 论文中提出，动态截断可以在开放式生成中减少长尾噪声，同时保留必要的多样性。

五、三个参数，到底有什么区别？

可以把整个采样过程想成抽签：Temperature 决定每张签的权重差距；Top-K 决定只让排名前 K 的签入场；Top-P 则根据总概率动态决定让多少张签入场。

因此，它们的作用有交集，但并不等价。Temperature 不一定改变候选数量，Top-K 和 Top-P 则会把一部分 token 的概率直接变成零。

六、三个参数同时设置，会发生什么？

很多框架允许同时设置 Temperature、Top-K 和 Top-P。概念上，通常先对 logits 做温度缩放，再依次执行候选过滤，最终在剩余 token 中采样。

同时设置并不是“完全不可预测”，它仍然是明确的计算过程；真正的问题是参数之间会互相影响。比如升高 Temperature 会让分布变平，而很低的 Top-P 又会迅速裁掉大量候选，最终效果很难仅凭直觉判断，也不容易定位是哪个参数造成了变化。

七、不同场景，参数应该怎么设置？

不存在适合所有模型的“万能参数”。不同模型、聊天模板、推理框架和任务目标都会影响最佳配置。下面的范围更适合作为起始点，而不是最终答案。

对于 JSON、函数调用、字段抽取等格式严格任务，采样参数只能降低随机性，不能替代结构化输出约束。生产系统更稳妥的做法是同时使用 JSON Schema、语法约束、结果校验和失败重试。

对于代码和推理任务，也不能简单地认为 Temperature 越低越好。如果只需要一份稳定答案，可以使用低温；如果采用多样本生成、Pass@K 或自一致性策略，则可以适当提高 Temperature，让不同样本覆盖更多解题路径，再由测试用例或评分器筛选。

八、真正可靠的调参方式：用测试集，不要凭感觉

调采样参数最容易犯的错误，是只看一两次输出就下结论。随机采样本来就会波动，必须用固定测试集和多次运行观察整体结果。

测试指标也不应只有“看起来顺不顺”。可以同时记录正确率、格式通过率、重复率、答案长度、多样性、人工偏好、延迟和 token 成本。对于客服、金融、医疗等高风险场景，还要单独统计事实错误和安全违规。

建议先扫描 Temperature，找到稳定与多样性的平衡点；再固定 Temperature，小范围测试 Top-P。Top-K 通常可以保持模型默认值，只有在本地模型长尾噪声明显或模型卡明确推荐时再加入实验。

九、常见误区

还有一个经常被忽视的问题：即使 Temperature=0，同一请求也不一定在所有环境中逐字一致。GPU 并行计算、浮点精度、动态批处理、服务端路由、模型版本更新，都可能带来细微差异。需要强可复现时，应固定模型版本、推理框架、随机种子和运行环境，并保存完整请求参数。

十、面试和项目中，怎么用一句话讲清？

可以这样回答：大模型先为所有候选 token 计算概率，Temperature 负责改变概率分布的尖锐度，Top-K 固定保留概率最高的 K 个 token，Top-P 保留累计概率达到 P 的最小候选集合。工程上不要迷信固定参数，要从模型默认值出发，用固定评测集一次只调一个主变量。