一、先分清不稳定的四种形态

形态之一是随机性波动。同一输入多次调用，结果内容不同、详略不同、措辞不同。这是采样机制本身带来的现象，不是故障。多数情况下它可以被调节，但不可能被完全消除——只要还在做概率采样，输出就存在分布上的差异。

形态之二是格式漂移。要求返回结构化内容时，模型偶尔在结果前后加上解释性文字，或者字段顺序与约定不一致，导致下游解析报错。这类问题通常不是采样参数的问题，而是约束方式不够硬。

形态之三是被截断。回答写到一半停止，或者刚好停在关键结论之前。原因多半是输出长度上限设置得不够，而不是模型"想不出来"。

形态之四是内容层面的偏差，包括事实性错误、语义重复、偏离角色设定、跑题。这一类与采样的关联最直接，也最需要通过参数与提示词共同处理。

把四种形态分开判断，是调参之前必做的第一步。很多人一遇到不稳定就去动参数，结果调了半天，问题其实出在输出长度上限或提示词约束上。

二、采样参数各自管什么

要调得准，先要明白每个参数的作用位置。可以把生成过程理解为两步：先决定"从哪些候选里挑"，再决定"挑的时候有多大胆"。

temperature 控制的是第二步。它调整候选概率分布的陡峭程度：取值越低，分布越陡，模型越倾向选择概率最高的那一个，输出越确定、越保守；取值越高，分布越接近均匀，低概率的候选也有机会被选中，输出越跳脱、越多样。当它取到极低值时，理论上等价于每次都选概率最高的候选，行为接近确定，但不同实现对极低值的处理有细微差别，不要把它当成绝对的确定性保证。

top_p 与 top_k 控制的是第一步。top_p 的做法是把候选按概率从高到低累加，直到累计值超过设定阈值，这一组候选才进入候选池；top_k 则更直接，只保留概率最高的前若干个候选。前者是动态的，分布集中时候选池小，分布均匀时候选池自动扩大；后者是固定的。想让输出更收敛，优先调 temperature；想压住长尾上的怪词，top_p 更见效。

frequency penalty 与 presence penalty 管的是重复。前者按出现频次施加抑制，一个词出现次数越多，模型越不愿意再用；后者对已经出现过的候选一律施加抑制，鼓励引入新内容。长文本出现复读现象时，调高这两个值往往立竿见影。

max_tokens 是输出长度上限。它既是成本控制手段，也是格式保证手段。输出被截断时，先看这里。

stop 是停止序列，用来告诉模型遇到什么内容就停下，对多轮结构与批量生成很有用。

seed 是随机种子。在支持的情形下，相同的种子与相同的参数组合，可以让输出具备可重复性，这在回归测试里价值很高。

三、这些参数能否自定义

可以。在标准的推理服务调用中，上述参数都可以通过请求字段传入，由服务端在做推理时应用。这一点在息壤Token服务这类标准化推理服务中同样成立：调用方在请求中携带参数，服务端按参数执行生成，并把本次调用的消耗按Token口径记账。

但有三点需要留意。其一，取值范围有约束。各参数都有允许区间，超出区间会被拒绝或自动夹到边界值。常见约定是 temperature 落在零到二之间，实际有效区间往往更窄；top_p 落在零到一之间。其二，默认值各有不同。不传参数时使用服务端默认配置，而默认值未必适合你的任务，因此显式声明比依赖默认更稳妥。其三，个别参数受服务端策略影响，比如是否支持种子、是否支持特定的停止方式，需要以服务端的接口说明为准。

还有一个常被忽略的细节：参数是否被真正应用，要在返回结果中验证。有的框架在未开启采样时，会忽略 temperature 与 top_p，直接走概率最高的路径——此时无论怎么调都不会有变化。确认参数生效的方法很朴素：用同一段提示词跑两次，观察输出是否随参数变化而变化。

四、按任务给出取值区间

参数没有万能值，但有与任务匹配的区间。以下区间来自大量工程实践，可作为起点，再按实际表现微调。

结构化抽取、字段识别、分类判定、数学计算这类任务，追求的是稳定与可解析。temperature 取零到零点三，top_p 取较小值，让输出尽量收束到确定的形态。这类任务上，输出多样性是负担而非优势。

日常问答、公文起草、摘要归纳、客服回复，需要在稳定与自然之间取中。temperature 取零点四到零点七，top_p 取零点八到零点九，通常能兼顾条理与可读性。

创意文案、故事构思、命名建议、头脑风暴，需要多样性来打开思路。temperature 可以取零点八到一点二，top_p 相应放宽。但需要留意，超过一点三之后，语义重复、逻辑松脱、语法走形的概率明显上升，除非刻意追求非常规效果，一般不建议越过这条线。

角色设定类任务还要额外考虑一致性：严谨的角色设定用偏低的取值，活泼的表达用中等偏高的取值。但要清楚，角色一致性主要靠系统提示与示例维持，参数只是辅助。

无论哪一类，都要规避两个极端：一是把所有参数拉满，以为这样更有创造力，实际只会得到更混乱的输出；二是期望通过参数彻底消除波动，这超出了参数能力范围。

五、参数之外的四个抓手

参数能解决的是采样层面的问题，另外四类问题要靠别的手段。

第一个抓手是提示词。许多"不稳定"的根源是指令含糊：任务描述不清、边界未定义、缺少输出格式示例。把要求写具体，把反例写出来，把输出格式用样例固定住，效果往往比调十次参数更明显。

第二个抓手是示例。给一到三个输入输出样例，等于把期望的分布直接展示给模型，对格式稳定性的提升特别显著。样例要覆盖边界情形，而不只是最典型的那种。

第三个抓手是输出约束。需要结构化结果时，应明确约定字段名、顺序、层级与取值枚举，并在下游做校验与重试。把格式交给模型自觉，不如交给约束与校验双保险。

第四个抓手是路由与重试。对准确率要求高的环节，可以让同一请求跑两次并比对结果，不一致时转人工或降级处理；对时延敏感的环节，则用小参数档模型配合更硬的约束。路由策略把不同要求的请求分给不同配置，比所有请求共用一套参数更有效。

此外，上下文管理也不容忽视：过长的上下文会稀释指令，把关键信息放在开头与结尾，比堆在中间更容易被遵循。

六、一套可复用的诊断流程

遇到问题，建议按固定顺序排查，而不是凭感觉试。

第一步，固定变量。把提示词、上下文、模型版本、参数全部固定下来，跑十次，观察波动范围。这一步的目的是确认问题的量级，而不是急着改。

第二步，单变量扫描。每次只动一个参数，按小步长扫过区间，记录每种取值下的表现。同时只改一项，才能把效果归因到具体参数上；一次改多项，效果对不上就无从判断。

第三步，构造回归集。从真实业务中抽取代表性请求，覆盖高频场景与边界场景，形成几十到几百条的集合。每次调整后跑一遍，用同一批数据比对，不看个别案例，看整体分布。

第四步，量化评价。给回归集定可衡量的指标：格式正确率、字段完整率、长度均值、重复率、人工抽检通过率。有指标才能判断"变好了"是真变好还是错觉。

第五步，留痕。把每次调整的参数组合、回归结论、决策人记下来。参数组合本身也是配置资产，应当与代码一样纳入版本管理。

七、工程侧的固化做法

调好参数只是开始，让它长期稳定才是目的。

其一，参数配置化。不要散落在各处调用里，集中到一处配置，按场景分档管理。新场景接入时复制一份再微调，而不是从头试。

其二，参数版本化。参数组合的变更要有记录，与模型版本、提示词版本一起管理。出问题时能快速定位是哪一次变更引入的。

其三，日志留痕。每次调用把实际使用的参数值、模型标识、消耗记入日志。排查个案时，没有这些字段就只能靠猜。

其四，监控指标。对格式失败率、截断率、响应时长均值、重复率设置常态监控，指标异常时先按场景与参数档下钻。

其五，灰度切换。参数调整影响面大时，先小流量验证再全量放开，并保留回退配置。

结语

输出不稳定不是一个问题，而是一类问题的统称：随机性波动来自采样，格式漂移来自约束不足，截断来自长度设置，内容偏差要靠参数与提示词共同治理。采样参数完全可以通过标准请求字段自定义，取值的关键是与任务匹配——严谨任务取低，创作任务取中高，越过一点三要格外谨慎。把诊断流程固定成"固定变量、单变量扫描、回归集比对、量化评价、留痕"五步，再把参数配置化、版本化并纳入监控，模型的输出表现就会从忽好忽坏，变成可控、可解释、可追溯。