大语言模型技术指南:temperature、top-k、top-p、repeat penalty 到底怎么调?生成参数实战详解
大语言模型技术指南temperature、top-k、top-p、repeat penalty 到底怎么调生成参数实战详解前面几篇我们已经把这条主线往前推进到了这里Transformer 为什么能成为大模型基础架构预训练到底在学什么SFT、RLHF、DPO 这类对齐训练为什么必要长上下文到底是怎么做出来的接下来终于要进入一个所有 LLM 使用者都会高频接触、但又最容易“凭感觉乱调”的环节生成参数。几乎只要你用过 API、推理框架或者本地部署工具就一定见过这些参数temperaturetop-ktop-prepeat penaltymax tokensstop wordsseed很多人第一次看到它们时会把这件事理解成“无非就是调一调随机性。”但真正从模型行为和部署工程角度看这远远不够。因为这些参数控制的不是一个抽象的“创意开关”而是在直接影响模型下一步 token 的采样分布回答的稳定性和发散程度幻觉风险和重复风险推理成本、时延和输出长度某类任务到底是更适合保守生成还是更适合保留探索性所以这篇文章我想把生成参数里最值得真正理解的几件事讲透temperature、top-k、top-p 分别在控制什么为什么它们经常不是单独起作用而是联合作用repeat penalty 到底在惩罚什么什么时候会帮忙什么时候会伤害质量max tokens、stop、seed 这些看似“配角”的参数为什么也很关键不同任务下参数模板应该怎么设从部署视角看应该怎样在质量、稳定性、成本之间做权衡如果这篇吃透后面再去看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-ktop-p 的优势在于它是自适应的。因为当分布很尖时只需要少量 token 就能覆盖大部分概率当分布更平时它会自动放宽候选集。这比固定保留前 k 个更贴近模型当下的真实不确定性。所以在很多现代 LLM 服务中top-p 往往比 top-k 更常作为主要采样截断手段。一个很实用的理解方式是temperature 决定“分布有多敢放开”top-p 决定“即便放开也最多放到多大范围”这两者组合起来比单独调任何一个参数都更有控制力。五、temperature、top-k、top-p 为什么要一起看很多初学者会问“我到底该调 temperature 还是调 top-p”这个问法本身就有点问题。因为它们控制的不是同一个层面。可以把一轮采样粗略理解成下面这个顺序模型先给出原始 logitstemperature 改变概率分布的尖锐程度top-k 或 top-p 再把候选集截断最后从候选里抽样所以只调 temperature不截断候选可能让长尾噪声也被放进来只调 top-p不调 temperature可能分布形状仍然不适合任务temperature top-p 往往是最常见、也最实用的组合经验上如果输出太死板可以先小幅提高 temperature如果输出太飘、太容易胡说可以先下调 temperature 或收紧 top-p如果模型偶尔跳出很奇怪的词可以考虑加上 top-k 或进一步收紧 top-p常见误区1temperature 和 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但真正上线服务时另外几个参数同样重要。1max tokens它控制的是本次最多生成多少 token。这直接影响成本时延输出完整性模型是否容易越写越散max tokens 太小回答会被截断太大则会增加延迟和费用还容易让开放任务输出越来越啰嗦。所以它不是“给大点更保险”而是应该按任务设上限。例如分类、抽取几十到一百多 token 往往就够普通问答几百 token 常见长文写作才需要更高上限2stopstop 用于定义停止生成的边界比如遇到特定分隔符、字段结束标记、角色切换标记时停止。它对这些场景特别关键工具调用结构化输出多轮模板生成few-shot 提示词中防止串样例如果 stop 设得好往往比单纯压低 temperature 更能提升结果可控性。3seedseed 控制随机采样过程中的可复现性。它不是所有服务都稳定支持但如果支持在调参、AB 测试、排查线上波动时会非常有价值。因为你可以把“模型随机波动”和“参数真的有改进”尽量分开。八、不同任务下参数应该怎么配这里不给“万能参数”而是给几套更实用的任务模板。1事实问答 / RAG 问答目标减少幻觉优先稳定和贴近检索内容。建议思路temperature 偏低top-p 收紧一些max tokens 不要无上限明确要求基于给定材料回答如果是引用式问答最好搭配 stop 或固定格式典型倾向temperature0 到 0.3top-p0.8 到 0.95repeat penalty轻微或关闭核心原则宁可短一点、保守一点也不要为了“像人”而放大幻想空间。2代码生成 / SQL / 结构化抽取目标高确定性、低格式错误率。建议思路temperature 很低top-p 不宜过大repeat penalty 谨慎使用必要时限制 stop对 JSON、函数调用、SQL 模板尽量提供明确 schema典型倾向temperature0 到 0.2top-p0.7 到 0.95repeat penalty通常关闭或非常轻核心原则结构正确比文风丰富重要得多。3通用助手问答目标自然、稳定、不过分僵硬。建议思路temperature 中低top-p 保持适度开放max tokens 根据产品风格控制典型倾向temperature0.3 到 0.7top-p0.9 到 0.98repeat penalty轻微开启这类场景通常最适合做线上 AB 测试因为“过保守”和“过发散”都很影响用户体验。4创意写作 / 头脑风暴 / 营销文案目标提高多样性和新鲜感。建议思路temperature 可以更高top-p 可以放宽允许给多个候选对事实性要求高的部分应另外校验典型倾向temperature0.8 到 1.1top-p0.95 到 1.0repeat 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 使用方式从来不是只盯模型排行榜。会选模型也要会调模型。