LLM 推理参数

推理参数(Inference parameters)是你随 LLM 请求一起传递的设置,用于控制模型如何生成响应。它们不会改变模型权重,而是影响解码过程,例如:

• 如何选择下一个 token
• 模型可以持续生成多长时间
• 何时应该停止
• 允许多少重复

有些参数主要影响输出质量和风格,而另一些则对调度、吞吐量、内存占用和生产成本有直接的服务影响。

常见的推理参数

你会在托管 API、OpenAI 兼容服务器、推理框架(如 vLLM、SGLang 和 MAX)以及智能体框架中看到这些参数。这里快速总结一下常见的:

参数	控制内容	常见用途
temperature	token 选择中的随机性	低值用于稳定答案,高值用于创意写作
top_p	采样时考虑的累积概率质量	将采样限制在一组可能的 token 中
top_k	考虑的最大候选 token 数量	移除排名很低的 token
max_tokens	输出 token 的最大数量	约束延迟和成本
min_tokens	输出 token 的最小数量	避免响应过早停止
stop / stop_token_ids	结束生成的文本或 token 模式	在分隔符、章节或工具边界前停止
presence_penalty	惩罚已经出现过的 token	鼓励新的话题或措辞
frequency_penalty	根据重复频率惩罚 token	减少重复的词或短语
repetition_penalty	惩罚重复的提示或输出 token	在开源服务技术栈中常见
seed	采样的随机种子	在测试期间改善可复现性
logprobs	token 概率详情	调试、评分或检查输出
n / best_of	候选输出的数量	生成替代方案,但成本更高

并非每个提供商都支持每个字段,而且确切的名称可能有所不同。即使字段名相同,不同模型和框架的行为也可能不同。请将这些配置视为你评估面的一部分,而不是可移植的保证。

温度(Temperature)

temperature 控制模型在采样之前,将概率分散到可能和不太可能的 token 上的程度。

较低的温度会使概率分布更尖锐。换句话说,模型更倾向于选择概率最高的 token,因此输出变得更稳定、更可预测。

较高的温度会拉平分布。不太可能的 token 有更多机会出现,这可以使输出更多样、更出人意料或更有创意。

常见模式:

• 对事实性问答、提取、分类和结构化工作流使用低温。
• 如果你能接受一定的变化,对聊天、摘要和产品文案使用中等温度。
• 对头脑风暴、虚构故事、命名和其他创意任务使用较高温度。
• 当你想要贪心(greedy)或接近确定性的解码时,使用 temperature: 0 或接近零的值。

低温并不保证事实准确性。它只是减少了解码步骤中的随机性。如果提示缺乏依据、模型缺乏知识,或者应用不验证输出,模型仍然可能给出自信的错误答案。

Top-p 和 Top-k 采样

top_p 和 top_k 在采样前限制哪些 token 有资格被选中。

Top-p

top_p,也叫核采样(nucleus sampling),保留累积概率达到某个阈值的最小 token 集合。例如,top_p: 0.9 意味着采样器考虑最可能的那些 token,它们合计覆盖约 90% 的概率质量。

这会适应模型的不确定性。如果下一个 token 很明显,候选集可能很小。如果许多 token 都合理,候选集就会变大。

Top-k

top_k 只保留最可能的 k 个 token。例如,top_k: 50 意味着模型从前 50 个候选中采样,并忽略其余所有候选。

这很简单、可预测,但它不能适应概率分布的形状。有时前 50 个 token 包含太多弱选项。有时合理的选项可能超过 50 个。

下面的可视化工具展示了同一分布在两种过滤器下的差异。在尖峰、混合和扁平分布之间切换,观察 top-p 如何在一个答案占主导时保留更少的 token,而在多个答案都合理时保留更多。无论形状如何,top-k 总是保留相同数量。

提示: 若无法显示,请直接打开 独立工具页面。

应该调哪个

许多系统允许你同时使用 temperature、top_p 和 top_k。这可能有用,但也会让行为更难以推理。

一个实用的起点:

• 先调 temperature。
• 如果你想让模型在每一步都选择概率最高的 token,可以使用贪心解码。它在固定的服务环境中是确定性的,但容易出现重复。
• 当你想约束长尾并保持采样自适应时,使用 top_p。
• 当你的推理框架或模型系列推荐使用 top_k 时,或者当你需要对候选 token 设置硬上限时,使用 top_k。
• 组合 top_k 和 top_p: 在许多采样器中,top-k 会先移除排名较低的尾部,然后 top-p 进一步细化候选集。
• 在评估期间,避免同时更改所有参数。

输出长度

长度参数直接影响延迟和成本,因为 LLM 在解码期间一次生成一个 token。

max_tokens 设置模型可以生成的最大 token 数量。这是最重要的生产控制之一。如果太低,响应会被截断。如果太高,糟糕的提示或边缘情况会浪费 GPU 时间并增加尾部延迟。

min_tokens 要求模型在停止前至少生成一定数量的 token。请谨慎使用。它可以帮助避免空响应或过短的响应,但也可能迫使模型在自然答案完成后继续写下去。

好的默认值取决于应用:

• 短分类或提取: 小的 max_tokens,通常低于 100。
• 客户支持回答: 为完整答案留出足够空间,但要设限以避免冗长。
• 代码生成或长篇写作: 更大的限制,并对延迟和成本进行更强的监控。
• 批处理作业: 明确的长度限制,这样单个坏输入不会主导整次运行。

对于推理系统,输出长度还影响调度。较长的生成会占用活动请求状态更久,占用KV 缓存更久,并可能干扰对延迟敏感的流量。

停止序列(Stop sequences)

停止序列告诉服务器,当出现特定文本时结束生成。一些 API 使用字符串停止符,如 stop,而更底层的引擎可能还支持 token ID,如 stop_token_ids。

当输出有清晰的边界时,它们很有用:

• 在聊天记录格式中,在 "\n\nUser:" 处停止。
• 在结构化提示中,在 "</json>" 或其他分隔符处停止。
• 在一个列表项、一条 SQL 语句或一次工具调用后停止。

停止序列并不能替代 schema 强制。它们只会在某个序列出现时结束生成。如果你需要保证 JSON,请使用结构化输出,或在你的提供商支持时使用约束解码。

注意常见的子串。出现在正常内容中的停止序列可能会截断有效的答案。

重复惩罚(Repetition penalties)

惩罚参数会根据已经出现过的内容修改 token 分数。它们是减少循环和重复措辞的实用工具。

• presence_penalty 会在 token 出现过时惩罚它。较高的值鼓励模型引入新的 token 或话题。
• frequency_penalty 会随着 token 出现频率增加而加大惩罚。当模型太多次重复同一个词或短语时,这很有用。
• repetition_penalty 惩罚出现在提示或生成文本中的 token。高于 1 的值通常会抑制重复,而低于 1 的值则会鼓励重复。

这些参数可能有帮助,但它们是很粗糙的工具。如果模型因为提示含糊、上下文嘈杂或任务要求重复输出而自我重复,惩罚可能只是在掩盖症状。过度的惩罚还会让写作变得别扭,因为模型会回避合法的重复术语。

多个候选(Multiple candidates)

一些 API 可以为单个提示返回多个补全结果。

n 通常表示返回的输出数量。best_of 通常表示在返回最好的 n 个之前,内部生成的候选数量。

当你想要几个创意选项,或者当另一个系统会对候选进行评分时,这会很有帮助。代价是成本。如果你要求五个候选,系统可能要付出接近五倍的生成工作量。best_of 可能更昂贵,因为它可能生成从未返回的候选。

要有意识地使用它们:

• 适合: 头脑风暴、重排序、测试时选择、评估数据生成。
• 不适合: 高吞吐的生产请求,因为每个额外的 token 都很重要。
• 有风险: 对延迟敏感的聊天,因为候选生成可能增加尾部延迟。

可复现性与对数概率(Reproducibility and log probabilities)

LLM 采样涉及随机性。如上所述,在每一步,模型都会根据 temperature 和 top_p 等参数概率性地挑选下一个 token。seed 初始化驱动采样的随机数生成器。在相同的 seed、相同的输入、相同的参数以及稳定的服务环境下,你通常可以获得相同或几乎相同的输出。这对测试提示、比较模型版本或调试意外输出很有用。

然而,不要将种子视为完美的生产保证。当模型版本、分词器、服务框架、硬件内核、批处理行为或浮点实现发生变化时,可复现性仍可能改变。

logprobs 返回生成 token 的概率信息。一些系统还支持 prompt_logprobs,它报告提示 token 的概率信息。

这些字段对以下方面很有用:

• 检查模型为什么选择了某个 token。
• 构建置信度启发式。
• 比较候选补全结果。
• 调试分类提示。
• 衡量模型对受约束标签的偏好程度。

它们会增加响应体积,而且并非总是被聊天 API 支持。在你需要这些信号时启用它们,而不是为每个生产请求默认开启。

高级控制(Advanced controls)

更高级的推理参数可以直接限制或改变 token 选择。一些常见的有:

• logit_bias 增加或减少特定 token 的分数。这可以推动模型朝向或远离特定的词、标签或格式标记。
• bad_words 阻止某些词序列。
• allowed_token_ids 将生成限制到特定的 token 集合。这些功能很强大,但容易误用,因为分词并不总是与人类可见的词匹配。

当输出由软件消费时,使用高级控制。例如,提取流水线、函数调用和结构化数据生成通常需要比单纯提示指令更强的保证。

推荐的起点

不存在通用的最佳参数配置。好的默认值取决于任务、模型系列和服务技术栈。即使设置相同,不同模型的行为也可能差异很大。

尽管如此,以下范围是评估时有用的起点:

使用场景	Temperature	Top-p	max_tokens	说明
分类	0.0–0.2	1.0	小,通常 < 20	优先确定性输出
提取 / 结构化解析	0.0–0.2	1.0	小	尽量减少变化和格式漂移
RAG / 事实性问答	0.1–0.5	0.9–1.0	中等	较低的随机性可能减少幻觉
通用聊天助手	0.5–0.8	0.9–1.0	中等	在稳定性与变化之间取得平衡
摘要	0.2–0.7	0.9–1.0	中等	取决于你希望摘要是抽取式还是创造式
代码生成	0.0–0.3	1.0	中到大	较低的温度通常能提高语法稳定性
头脑风暴 / 构思	0.7–1.2	0.9–0.95	中到大	鼓励更多样的输出
创意写作	0.8–1.3	0.9–0.95	大	更多样性,但也不稳定

这些只是起点,不是规则。始终使用你的实际提示、模型版本和工作负载来评估参数。

对于生产系统,参数调优也是一个基础设施问题。例如,更高的输出长度和更多的探索性采样会增加延迟、GPU 利用率、KV 缓存压力,以及在负载下的尾部延迟。

常见问题

推理参数和模型超参数一样吗?

不一样。超参数通常指训练期间使用的设置,如学习率或批大小。推理参数是在已训练模型生成输出时使用的请求时设置。

为什么我的输出提前停止了?

常见原因包括 max_tokens 过低、正常文本中出现了停止序列、模型生成了序列结束 token,或者提供商端的安全或长度限制。

所有模型都支持相同的参数吗?

不是。托管提供商、OpenAI 兼容服务器和开源引擎暴露了不同的子集。某些参数可能会被忽略、拒绝,或根据服务技术栈的不同而以不同方式实现。