LLM 采样参数到底怎么调：temperature、top-p、top-k

大多数 API 控制台里都摆着这三个参数，默认写着 0.7，很多人用了半年也没动过。但它们决定一件具体的事：模型一次生成一个 token 时，从候选词池里按什么规则挑词。这一步直接影响输出稳定性，甚至影响一批任务的真实成本。这篇把三个参数拆开讲，再说清哪些场景该动哪个。

三个参数各自改的是什么

模型吐字是一个 token 一个 token 进行的。每出一个 token，模型先对词表（几万条）算一遍概率，再按规则把候选池收窄到一小撮，最后按概率抽签。

- **temperature（温度）**：在算概率之前把 logits 除以 T。T 越小，高概率的词越突出；T 趋近 0 就退化成贪心解码，永远只挑最高的那个，输出完全确定。T 越大，分布越平，低概率词的机会越多。

- **top-k**：按概率只保留前 k 个候选，其余直接扔掉。

- **top-p（核采样）**：按概率排序后，取累计概率刚好够到 p 的最小那一段，其余扔掉。和 top-k 的区别在于候选池大小随上下文浮动——模型很自信时，池子自动变小。

三个场景的具体手感

**抽取 JSON、分类打标**：用 temperature 0 或 0.1，top-p 可以压到 0.1–0.5。这类任务要的是同一份输入永远产出同一组字段，任何词的稳定度波动都可能让你多一个逗号、少一个字段，而坏掉的那几个只能靠重试兜底，成本翻倍。

**创意文案、头脑风暴初稿**：temperature 0.9–1.2，top-p 0.9–0.95。这类场景的价值恰恰在偶发的意外选词，重复调用要拿到不同的稿子，太稳定反而是在浪费并行成本。

**代码生成、长文写作**：temperature 0.2–0.4 是常用平衡点。主体要稳，但保留一点词面波动，避免同一份代码连跑六次六次一模一样。

两个工程细节容易踩坑。第一，别把三个参数同时拧到极限。top-k 和 top-p 同时设小，候选池被裁两次，行为很难推断。常见做法是 temperature 和 top-p 一起管，top-k 保持默认不动。第二，"不稳定"要先查提示词再查采样。答疑答得"虚"，多半是系统提示写得含糊、few-shot 例子太少，或者一次任务的粒度太大。采样参数只改变"在模型能力范围内挑哪个词"，不扩展能力本身——一个答不好的模型，把温度调高只是让它用不同的方式错了。

生产里怎么快速试

把两件事固定下来：输出格式约束（JSON Schema 或 few-shot 示例）和一份固定的评测样例（20–30 条代表输入）。然后一次只动一个参数，用同一批样例打分，看两个指标：结构错误率（JSON 能否解析、字段是否齐全）和同输入多次输出的一致率。如果 temperature 已经压到 0.1 结构错误率还不降，问题基本不在采样环节，回去改提示词或拆任务粒度。

再加一个经常被忽略的参数：**seed**。很多推理服务支持指定随机种子。temperature 不为 0 时，每次抽到的词不一样；seed 固定后，同样的输入、同样的参数会抽到同样的结果。它的正确用法不是"让生产输出固定"，而是做回归对拍：改提示词前后各跑一遍同一批样例（seed 相同），diff 一次就能看到改动到底把哪些输出带偏了，比凭感觉判断可靠得多。注意不同服务对 seed 的实现不保证完全一致，换服务后对拍结果不能直接沿用。

常用组合可以直接抄：

| 场景 | temperature | top-p | top-k |

|---|---|---|---|

| 抽取 / 分类 | 0–0.1 | 0.1–0.5 | 默认 |

| 运行时代码生成 | 0.2–0.4 | 0.8–1 | 默认 |

| 创意初稿 | 0.9–1.2 | 0.9–0.95 | 默认 |

总结：三个参数看起来三件套，其实只做一件事——给选词收窄候选池。要稳定的任务收窄到极限，要新意的任务留间隙。输出不稳定时，先改提示词和格式约束，再动采样；顺序反了，就是花几天调 temperature 然后把答案率调得更看不清。