企业官网建设流程全解析

大语言模型技术指南：temperature、top-k、top-p、repeat penalty 到底怎么调？生成参数实战详解

前面几篇，我们已经把这条主线往前推进到了这里：

• Transformer 为什么能成为大模型基础架构

• 预训练到底在学什么

• SFT、RLHF、DPO 这类对齐训练为什么必要

• 长上下文到底是怎么做出来的

接下来，终于要进入一个所有 LLM 使用者都会高频接触、但又最容易“凭感觉乱调”的环节：

生成参数。

几乎只要你用过 API、推理框架或者本地部署工具，就一定见过这些参数：

• temperature

• top-k

• top-p

• repeat penalty

• max tokens

• stop words

• seed

很多人第一次看到它们时，会把这件事理解成：

“无非就是调一调随机性。”

但真正从模型行为和部署工程角度看，这远远不够。

因为这些参数控制的不是一个抽象的“创意开关”，而是在直接影响：

• 模型下一步 token 的采样分布

• 回答的稳定性和发散程度

• 幻觉风险和重复风险

• 推理成本、时延和输出长度

• 某类任务到底是更适合保守生成，还是更适合保留探索性

所以这篇文章，我想把生成参数里最值得真正理解的几件事讲透：

1. temperature、top-k、top-p 分别在控制什么

2. 为什么它们经常不是单独起作用，而是联合作用

3. repeat penalty 到底在惩罚什么，什么时候会帮忙，什么时候会伤害质量

4. max tokens、stop、seed 这些看似“配角”的参数为什么也很关键

5. 不同任务下，参数模板应该怎么设

6. 从部署视角看，应该怎样在质量、稳定性、成本之间做权衡

如果这篇吃透，后面再去看：

• Agent 任务中的工具调用稳定性

• RAG 问答里的幻觉控制

• 代码生成里的确定性要求

• 本地部署时不同框架的采样配置

你会更容易调出可用结果，而不是一直靠试运气。

一、先说结论：生成参数不是“锦上添花”，而是模型行为控制面板

先把一个常见误区纠正掉。

很多人会把采样参数当成“最后随手调一下”的东西，觉得核心能力都由模型本身决定，参数只是轻微修饰。

这话只对一半。

更准确地说：

模型权重决定了“模型大致会什么”，而生成参数决定了“它这一次会怎样表现出来”。

同一个模型，在不同参数设置下，可能表现出完全不同的风格：

• 很稳，但过于保守

• 很活，但更容易跑偏

• 逻辑清楚，但语言有些机械

• 文风丰富，但事实一致性下降

• 能写出很多内容，但重复和废话明显增加

所以实际做产品或部署时，不能只问：

“这个模型强不强？”

还要问：

“在这类任务里，这个模型该用什么采样策略？”

这才是工程上真正影响效果的地方。

二、temperature 到底在控制什么

temperature 最容易被解释成“随机性”，但这个说法太粗。

更准确一点说：

temperature 控制的是 logits 在 softmax 前被拉平还是拉尖。

直觉上可以这样理解：

• temperature 更低时，高概率 token 的优势会被进一步放大，模型更倾向于选“最像标准答案”的词

• temperature 更高时，概率分布会变平，原本次优的 token 也更有机会被采样到，输出会更发散

所以 temperature 的核心影响不是“是否聪明”，而是：

模型愿意多大程度偏离当前最优候选。

1）低 temperature 的特点

常见区间比如 0 到 0.3。

优点：

• 输出更稳定

• 多次结果更一致

• 更适合抽取、分类、结构化输出、代码补全这类任务

缺点：

• 容易显得死板

• 遇到开放写作时表达可能发紧

• 某些情况下更容易陷入局部重复

2）高 temperature 的特点

常见区间比如 0.8 到 1.2。

优点：

• 更有发散性

• 更适合创意写作、头脑风暴、广告文案、多个备选方案生成

缺点：

• 更容易偏题

• 事实一致性下降

• 在需要严格格式时更容易出错

一个很实用的判断原则是：

任务越要求唯一正确、稳定复现、格式严格，temperature 越应该低；任务越允许开放表达和多样候选，temperature 才越有上调空间。

三、top-k 在做什么

top-k 的含义是：

每一步采样时，只保留概率最高的前 k 个 token，再从这 k 个里面抽样。

比如：

• top-k = 1，本质上就非常接近贪心解码

• top-k = 10，说明每一步最多只在前 10 个候选里选

• top-k = 50，则允许更大的候选池

它的作用很直接：

给模型的每一步输出加一个“候选上限”。

这有什么意义？

因为真实分布里，后面那些极低概率 token 往往噪声更大。如果完全不截断，模型在高 temperature 下就更可能抽到不靠谱 token。

所以 top-k 的价值在于：

• 防止采样尾部噪声过多

• 给生成加一个硬边界

• 在保留一定多样性的同时，避免分布拉得太散

但 top-k 也有局限。

因为不同步的分布形状并不一样。

有时前 10 个 token 已经覆盖了大部分概率质量；有时前 10 个还远远不够。也就是说，固定 k 是一种简单粗暴的截断方式。

所以现在很多系统里，top-k 常常不是主角，而是和 top-p 配合，或者甚至被弱化。

四、top-p 为什么更常用

top-p 也叫 nucleus sampling。

它的含义是：

每一步先按概率从高到低累计，只保留累计概率达到 p 的那一小撮 token，再从里面采样。

例如：

• top-p = 0.9，表示只在“累计概率达到 90%”的候选集合里抽样

• top-p = 0.95，则保留的集合会再大一点

相比 top-k，top-p 的优势在于它是自适应的。

因为当分布很尖时，只需要少量 token 就能覆盖大部分概率；当分布更平时，它会自动放宽候选集。

这比固定保留前 k 个更贴近模型当下的真实不确定性。

所以在很多现代 LLM 服务中，top-p 往往比 top-k 更常作为主要采样截断手段。

一个很实用的理解方式是：

• temperature 决定“分布有多敢放开”

• top-p 决定“即便放开，也最多放到多大范围”

这两者组合起来，比单独调任何一个参数都更有控制力。

五、temperature、top-k、top-p 为什么要一起看

很多初学者会问：

“我到底该调 temperature 还是调 top-p？”

这个问法本身就有点问题。

因为它们控制的不是同一个层面。

可以把一轮采样粗略理解成下面这个顺序：

1. 模型先给出原始 logits

2. temperature 改变概率分布的尖锐程度

3. top-k 或 top-p 再把候选集截断

4. 最后从候选里抽样

所以：

• 只调 temperature，不截断候选，可能让长尾噪声也被放进来

• 只调 top-p，不调 temperature，可能分布形状仍然不适合任务

• temperature + top-p 往往是最常见、也最实用的组合

经验上：

• 如果输出太死板，可以先小幅提高 temperature

• 如果输出太飘、太容易胡说，可以先下调 temperature 或收紧 top-p

• 如果模型偶尔跳出很奇怪的词，可以考虑加上 top-k 或进一步收紧 top-p

常见误区

1）temperature 和 top-p 一起调得很激进

比如 temperature 1.2、top-p 1.0，再不给任何约束，这通常会让输出变得非常不稳定。

2）参数太保守导致“假稳定”

有时 temperature 太低、top-p 太小，结果看起来更稳定，但其实只是模型一直在复读高频套路，并不代表真的更好。

3）跨任务照搬同一组参数

客服问答、RAG、代码生成、小说写作，用同一套采样参数，通常不会有最佳效果。

六、repeat penalty 到底在惩罚什么

repeat penalty 常被翻译成“重复惩罚”，但很多人并不知道它到底是在惩罚什么。

它的目标是：

降低模型再次生成已经出现过 token 的倾向。

这类机制很有用，因为自回归生成有一个经典问题：

模型一旦进入某种局部高概率循环，就可能开始：

• 重复短语

• 重复句式

• 重复解释同一个点

• 在长文本中越写越啰嗦

repeat penalty 会对历史中已经出现过的 token 做再打压，从而降低“陷入复读机状态”的概率。

它什么时候特别有用

• 长文本生成

• 开放问答

• 本地小模型推理

• 高 temperature 场景

• 容易啰嗦、容易重复的模型

它什么时候可能伤害质量

• 代码生成

• 数学推导

• 术语需要反复出现的技术写作

• JSON / XML / 表格类结构输出

因为这些任务里，某些 token 本来就应该重复出现。如果惩罚太强，模型可能为了“避免重复”而把本来应该复用的关键符号、字段名或术语也改乱。

所以 repeat penalty 不是越大越好。

经验上，轻微惩罚往往比重惩罚更稳。太高时常见副作用是：

• 用词怪异

• 本应一致的术语被换掉

• 结构化输出失真

• 中文技术文章里出现不自然改写

七、max tokens、stop、seed 为什么也很关键

很多人只盯着 temperature 和 top-p，但真正上线服务时，另外几个参数同样重要。

1）max tokens

它控制的是本次最多生成多少 token。

这直接影响：

• 成本

• 时延

• 输出完整性

• 模型是否容易越写越散

max tokens 太小，回答会被截断；太大，则会增加延迟和费用，还容易让开放任务输出越来越啰嗦。

所以它不是“给大点更保险”，而是应该按任务设上限。

例如：

• 分类、抽取：几十到一百多 token 往往就够

• 普通问答：几百 token 常见

• 长文写作：才需要更高上限

2）stop

stop 用于定义停止生成的边界，比如遇到特定分隔符、字段结束标记、角色切换标记时停止。

它对这些场景特别关键：

• 工具调用

• 结构化输出

• 多轮模板生成

• few-shot 提示词中防止串样例

如果 stop 设得好，往往比单纯压低 temperature 更能提升结果可控性。

3）seed

seed 控制随机采样过程中的可复现性。

它不是所有服务都稳定支持，但如果支持，在调参、AB 测试、排查线上波动时会非常有价值。

因为你可以把“模型随机波动”和“参数真的有改进”尽量分开。

八、不同任务下，参数应该怎么配

这里不给“万能参数”，而是给几套更实用的任务模板。

1）事实问答 / RAG 问答

目标：减少幻觉，优先稳定和贴近检索内容。

建议思路：

• temperature 偏低

• top-p 收紧一些

• max tokens 不要无上限

• 明确要求基于给定材料回答

• 如果是引用式问答，最好搭配 stop 或固定格式

典型倾向：

• temperature：0 到 0.3

• top-p：0.8 到 0.95

• repeat penalty：轻微或关闭

核心原则：宁可短一点、保守一点，也不要为了“像人”而放大幻想空间。

2）代码生成 / SQL / 结构化抽取

目标：高确定性、低格式错误率。

建议思路：

• temperature 很低

• top-p 不宜过大

• repeat penalty 谨慎使用

• 必要时限制 stop

• 对 JSON、函数调用、SQL 模板尽量提供明确 schema

典型倾向：

• temperature：0 到 0.2

• top-p：0.7 到 0.95

• repeat penalty：通常关闭或非常轻

核心原则：结构正确比文风丰富重要得多。

3）通用助手问答

目标：自然、稳定、不过分僵硬。

建议思路：

• temperature 中低

• top-p 保持适度开放

• max tokens 根据产品风格控制

典型倾向：

• temperature：0.3 到 0.7

• top-p：0.9 到 0.98

• repeat penalty：轻微开启

这类场景通常最适合做线上 AB 测试，因为“过保守”和“过发散”都很影响用户体验。

4）创意写作 / 头脑风暴 / 营销文案

目标：提高多样性和新鲜感。

建议思路：

• temperature 可以更高

• top-p 可以放宽

• 允许给多个候选

• 对事实性要求高的部分应另外校验

典型倾向：

• temperature：0.8 到 1.1

• top-p：0.95 到 1.0

• repeat penalty：中等偏轻

核心原则：让模型多想一点，但不要指望它在高发散状态下还保持严格事实可靠。

九、从部署视角看，调参不是只看“好不好看”，还要看成本和稳定性

真正上线服务时，采样参数不仅影响文本质量，还会影响系统行为。

1）输出越发散，线上波动通常越大

高 temperature 和宽 top-p 会让不同请求之间的结果分布更散。

这意味着：

• 用户体验更不稳定

• 回归测试更难做

• 工具调用成功率可能下降

• 客服、搜索、企业问答场景更难控风险

2）输出越长，延迟和成本越高

很多时候，质量问题并不是出在模型不会答，而是生成得太多。

所以除了采样参数，控制 max tokens、提示词约束和 stop 条件，往往是降低成本最直接的方法。

3）小模型通常比大模型更依赖保守采样

参数规模较小的模型，本身分布更脆弱。

这时如果你还给很高的 temperature，结果往往不是“更有创意”，而是“更容易坏”。

所以本地部署 7B、14B、32B 这类模型时，常常要比云端大模型更保守一些。

4）工具调用和 Agent 场景要优先保成功率

在 function calling、JSON schema、工作流编排里，最重要的通常不是语言多自然，而是：

• 参数填得对不对

• 格式稳不稳

• 会不会中途跑偏

这时一味追求“回答像真人”反而是错方向。应该优先降低 temperature、约束输出格式、减少无关文本。

十、一个实用的调参顺序

如果你在真实项目里要调参数，我更建议按这个顺序来，而不是一上来所有旋钮一起拧。

第一步：先定任务目标

先明确这到底是：

• 要求稳定复现

• 要求事实可靠

• 要求格式严格

• 还是要求创意多样

目标不同，参数方向完全不同。

第二步：先定 max tokens 和 stop

先把输出边界收住。

因为很多问题根本不是采样分布问题，而是模型输出空间过大导致的。

第三步：先调 temperature

先看模型在更保守或更开放之间，哪边更接近你的任务需求。

第四步：再调 top-p / top-k

当你确认大方向后，再用 top-p 或 top-k 去修边界，压噪声或放多样性。

第五步：最后再看 repeat penalty

只有当你真的观察到重复、啰嗦、循环输出时，再引入 repeat penalty。不要默认先加很重的惩罚。

这个顺序的好处是：

每一步都知道自己在解决什么问题。

而不是最后调出一组参数，却不知道到底是谁起了作用。

十一、几个最常见的错误调参方式

1）把 temperature 当成唯一旋钮

结果是明明问题出在输出边界或格式控制，却一直靠升降 temperature 硬调。

2）希望用高 temperature 解决“模型太笨”

高 temperature 解决的是多样性，不会让模型凭空学会不会的知识。

3）看到重复就把 repeat penalty 拉很高

最后虽然不重复了，但术语、代码变量名、结构字段也一起被打乱。

4）不同模型直接照搬参数

同样是 temperature 0.7，不同模型、不同量化版本、不同推理框架下的实际体感可能并不一样。

5）离线测得漂亮，线上却不稳

因为线上请求分布更复杂，长尾输入更多，真正应该看的不是单次 demo，而是：

• 成功率

• 格式错误率

• 幻觉率

• 平均输出长度

• p95 / p99 延迟

十二、最后给一个最简判断框架

如果你只想记住最核心的部分，可以记这一版：

• temperature：控制愿不愿意偏离最优候选

• top-k：给候选数设硬上限

• top-p：按累计概率做自适应截断

• repeat penalty：抑制复读，但过强会伤结构和术语一致性

• max tokens / stop：控制输出边界，很多时候比采样参数更重要

• seed：帮助复现和调试

对应到实战上，就是一句话：

越要求正确、稳定、结构化，参数越要保守；越允许开放表达和多样候选，参数才越能放开。

这不是玄学，而是生成机制本身决定的。

结语

生成参数之所以值得单独讲，不是因为它们有多复杂，而是因为它们恰好处在“模型能力”和“产品行为”之间。

模型再强，如果参数乱设，依然可能：

• 幻觉明显

• 工具调用失败

• 代码输出不稳定

• 成本高得不必要

反过来，就算模型不是最贵那一档，只要任务定义清楚、提示词合理、参数调得对，往往也能做出很稳的结果。

所以真正成熟的 LLM 使用方式，从来不是只盯模型排行榜。

会选模型，也要会调模型。