理解大模型生成参数：Temperature、Top-p 与重复惩罚 / starzn

大语言模型通常逐个 token 生成文本：每一步先为候选 token 计算分数，再按解码和采样策略选择下一个 token。Temperature、Top-p、Top-k 和重复惩罚都在这个选择阶段发挥作用，但它们不是模型能力或事实准确性的开关。

最重要的前提是：参数名称相似，不代表不同供应商、端点和模型具有相同范围、默认值或实现。 使用前必须查看目标模型的当前 API 文档。

先看职责边界

Temperature 较低时，原本概率较高的 token 通常更占优势；较高时，概率分布通常更平缓，低概率候选更有机会被选中。

较低 Temperature
高概率候选 ━━━━━━━━━━━━━
其他候选   ━━ ━ ━
 
较高 Temperature
高概率候选 ━━━━━━━
其他候选   ━━━━━ ━━━━ ━━━

因此低温输出往往更集中，高温输出往往更多样，但“集中”不等于“正确”，“多样”也不等于“有创造力”。模型可能在低温下稳定地产生同一个错误，也可能在高温下只是更不稳定。

temperature: 0 也不能被跨平台地理解成“每次输出完全相同”。服务端实现、并行计算、模型版本、工具结果和供应商路由都可能带来差异；有些 API 还明确说明零温度并不保证完全确定性。

Top-p 又称 nucleus sampling。它把候选 token 按概率从高到低排列，保留累计概率达到阈值的最小集合，再从集合中采样。

假设候选概率如下：

当 top_p 为 0.9 时，候选集需要包含 A、B、C、D 才能越过 0.9。它保留多少个 token 取决于当时的概率分布，因此不是固定的“前 90% 词汇”。

Top-k 则直接限制候选数量。例如 top_k: 3 只保留概率最高的三个候选。某些实现会组合 Top-k、Top-p 和 Temperature，但具体顺序属于实现细节，不应把某个供应商的流程图当作通用标准。

两种惩罚都根据已经生成的 token 调整后续分数：

它们操作的是 token，不是“词语”或“话题”的语义。例如一个中文词可能被拆成多个 token，同义词也可能完全不受已出现 token 的惩罚。惩罚过高还可能破坏专业术语、代码标识符、JSON 字段或长文的一致性。

因此，遇到重复问题时不应立即拉高 penalty。还要检查提示词是否要求重复格式、上下文是否塞入重复材料、停止条件是否合理，以及模型是否陷入循环。

固定的“代码用 0.2、写作用 0.9”表格看起来方便，却忽略了模型差异：

OpenAI 的部分 API 提供 Temperature 和 Top-p，并建议通常只调整其中一个；具体模型可能限制这些参数。
Anthropic 已在 Claude 4.7 及之后的模型中停止支持非默认的 temperature、top_p 和 top_k，建议通过提示词引导行为。
Google 对 Gemini 3.x 建议保留采样参数默认值，因为修改它们可能让推理任务出现循环或性能下降。
同一个参数值换到另一模型、另一版本或另一服务商，不代表相同的实际随机程度。

所以参数配置应该绑定到明确的供应商、API 端点和模型版本，而不是写成跨模型常量。

固定任务与评测集
      ↓
使用默认参数建立基线
      ↓
一次只改变一个参数
      ↓
重复采样并计算指标
      ↓
保留有可重复收益的配置

如果目标是稳定的 JSON、函数参数或分类标签，优先使用供应商提供的结构化输出、Schema 约束或工具调用能力。降低 Temperature 只能减少部分变化，不能替代输出验证。

Temperature 控制概率分布的形状，Top-p 和 Top-k 控制候选集合，Frequency 与 Presence penalty 调整已出现 token 的分数；它们都是生成策略参数，不是准确性旋钮。先确认目标模型是否支持，再用评测数据决定是否偏离默认值。