完整文档索引见 llms.txt。 在任意 URL 后追加 `.md` 即可查看该页面的 Markdown 版本。
LLM 推理参数
Inference parameters 是你随 LLM 请求一起传入的设置，用于控制模型如何生成响应。它们不会改变模型权重。 相反，它们会影响 decoding process，例如：
- 如何选择下一个 token
- 模型可以持续生成多长时间
- 何时应该停止
- 允许多少重复
有些参数主要影响输出质量和风格，另一些则会直接影响 serving 层面的调度、 throughput、内存使用和生产成本。
常见 inference parameters
你会在托管 API、 OpenAI-compatible servers、 像 vLLM 和 SGLang 这样的 inference frameworks 以及 agentic frameworks 中看到这些参数。下面是常见参数的快速总结：
| 参数 | 控制内容 | 常见用途 |
|---|---|---|
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 | 惩罚重复的 prompt 或输出 token | 常见于 open-source serving stacks |
seed | 采样使用的随机种子 | 提升测试过程中的可复现性 |
logprobs | token 概率细节 | 调试、评分或检查输出 |
n / best_of | 候选输出数量 | 生成多个备选，但成本更高 |
并非每个 provider 都支持每个字段，具体名称也可能不同。即使字段名相同，不同模型和 framework 的行为也可能不同。应把这些配置视为评估面的一部分，而不是可移植的保证。
温度（Temperature）
temperature 控制模型在采样前，如何在高概率和低概率 token 之间分散概率。
较低的 temperature 会让概率分布更尖锐。换句话说，模型更倾向于选择最高概率 token，因此输出会更稳定、更可预测。
较高的 temperature 会让分布变平。较不可能的 token 也有更大机会出现，因此输出可能更加多样、出人意料或更具创造性。
常见模式：
- 对事实问答、抽取、分类和 structured workflows 使用较低 temperature。
- 对聊天、总结和产品文案，如果可以接受一定变化，可使用中等 temperature。
- 对头脑风暴、小说、命名和其他创意任务，使用更高 temperature。
- 当你希望使用 greedy 或接近确定性的 decoding 时，使用
temperature: 0或接近 0 的值。
低 temperature 不保证事实正确性。它只是在 decode 阶段降低随机性。如果 prompt 缺乏依据、模型缺少相关知识，或应用没有验证输出，模型仍然可能自信地给出错误答案。
Top-p 和 top-k sampling
top_p 和 top_k 会在采样前限制哪些 token 有资格参与。
Top-p
top_p，也叫 nucleus sampling，会保留累计概率达到某个阈值所需的最小 token
集合。例如，top_p: 0.9 表示采样器会考虑那些合起来覆盖约 90%
概率质量的最可能 token。
这种方式会根据模型的不确定性自适应变化。如果下一个 token 几乎是显而易见的，候选集可能很小；如果很多 token 都合理，集合就会变大。
Top-k
top_k 只保留最可能的 k 个 token。例如，top_k: 50
表示模型只从前 50 个候选中采样，忽略其余所有 token。
这种方式简单且可预测，但它不会根据概率分布的形状自适应调整。有时前 50 个 token 包含太多弱候选；有时合理选项又可能超过 50 个。
下面的可视化展示了同一分布在这两种过滤方式下的差异。切换查看尖峰型、混合型和平坦型分布，注意当一个答案占主导时，top-p 保留的 token 更少；当许多候选都合理时，保留的 token 更多。而 top-k 无论分布形状如何，始终保留固定数量。
应该调哪个参数
许多系统允许你同时使用 temperature、top_p 和
top_k。这可能很有用，但也会让行为更难推理。
一个实用的起点是：
- 先调
temperature。 - 如果你希望模型在每一步都选择最高概率 token，可以使用 greedy decoding。 在固定 serving 设置下它是确定性的，但可能容易重复。
- 当你希望截断长尾、同时保持采样自适应时，使用
top_p。 - 当你的 inference framework 或模型家族建议使用它，或者你需要对候选 token
数量设置硬上限时，使用
top_k。 - 组合使用
top_k和top_p：在许多 sampler 中，top-k 先移除低排名长尾，然后 top-p 再进一步收紧候选集合。 - 在评估过程中避免同时修改这三个参数。
输出长度
长度参数会直接影响 latency 和成本，因为 LLM 在 decode 期间是逐 token 生成的。
max_tokens 设置模型可生成的最大 token
数量。这是最重要的生产控制项之一。如果它太小，响应会被截断；如果它太大，糟糕的
prompt 或边缘情况会浪费 GPU 时间，并增加 tail latency。
min_tokens 要求模型在允许停止前至少生成一定数量的
token。使用时要谨慎。它可以帮助避免空响应或过短响应，但也可能迫使模型在自然答案已经完成后继续输出。
良好的默认值取决于应用场景：
- 短分类或抽取：较小的
max_tokens，通常低于 100。 - 客服回答：要有足够空间给出完整答案，但也要限制上界，避免啰嗦。
- 代码生成或长文写作：使用更大的限制，同时更严格地监控延迟和成本。
- 批处理任务：明确设置长度限制，避免单个坏输入主导整个运行。
对 inference 系统来说，输出长度也会影响调度。长生成会更长时间持有活跃请求状态，更长时间占用 KV cache，并可能干扰对延迟敏感的流量。
停止序列（Stop sequences）
Stop sequences 告诉服务器在出现特定文本时结束生成。有些 API 使用字符串
stop，例如 stop；更底层的引擎还可能支持 token ID，例如 stop_token_ids。
当输出有清晰边界时，它们非常有用：
- 在聊天转录格式中遇到
"\n\nUser:"时停止。 - 在 structured prompt 中遇到
"</json>"或其他分隔符时停止。 - 在一个列表项、一条 SQL 语句或一次 tool call 后停止。
Stop sequences 不能替代 schema enforcement。它们只是在某个序列出现时结束生成。如果你需要保证 JSON 正确，请在 provider 支持时使用 structured outputs 或 constrained decoding。
要小心常见子串。如果某个 stop sequence 会出现在正常内容中，它可能会截断本来有效的答案。
重复惩罚（Repetition penalties）
Penalty 参数会根据已经出现过的内容修改 token 分数。它们是减少循环和重复措辞的实用工具。
presence_penalty会在某个 token 曾经出现过的情况下惩罚它。更高的值会鼓励模型引入新的 token 或主题。frequency_penalty会随着 token 出现次数增加而加大惩罚。当模型反复重复同一个单词或短语时，这很有用。repetition_penalty会惩罚在 prompt 或已生成文本中出现过的 token。通常大于1的值会抑制重复，小于1的值则会鼓励重复。
这些参数确实有帮助，但它们是比较钝的工具。如果模型重复的根因是 prompt 含糊、上下文嘈杂，或任务本身要求重复输出，那么 penalty 可能只是在掩盖症状。惩罚过强还可能让文本变得别扭，因为模型会回避本来合理的重复术语。
多候选输出
有些 API 可以为一个 prompt 返回多个 completion。
n 通常表示返回的输出数量。best_of 通常表示在返回最佳 n
个结果前，内部实际生成了多少候选。
当你希望获得多个创意选项，或让另一个系统对候选进行打分时，这会很有帮助。代价是成本更高。如果你请求五个候选，系统的生成工作量通常接近五倍。best_of
甚至可能更昂贵，因为它可能会生成一些最终不会返回的候选。
应当有意识地使用它们：
- Good fit：头脑风暴、reranking、test-time selection、评估数据生成。
- Poor fit：高吞吐生产请求，因为每个额外 token 都会带来成本。
- Risky fit：对延迟敏感的聊天，因为候选生成可能增加 tail latency。
可复现性与 log probabilities
LLM sampling 涉及随机性。如上所述，在每一步中，模型都会基于 temperature 和
top_p 等参数，以概率方式选择下一个 token。seed
会初始化驱动该采样过程的随机数生成器。在相同 seed、相同输入、相同参数以及稳定
serving 设置下，你通常可以得到相同或近乎相同的输出。这对测试
prompt、比较模型版本或调试异常输出很有帮助。
不过，不要把 seed 当成生产环境中的完美保证。当模型版本、tokenizer、serving framework、硬件 kernel、batching 行为或浮点实现发生变化时，可复现性仍然可能改变。
logprobs 会返回已生成 token 的概率信息。有些系统还支持
prompt_logprobs，用于返回 prompt token 的概率信息。
这些字段适用于：
- 检查模型为何选择某个 token。
- 构建置信度启发式。
- 比较候选 completion。
- 调试分类 prompt。
- 衡量模型对某个受约束标签的偏好强度。
它们会增大响应体积，而且并非所有 chat API 都支持。只在你确实需要这些信号时启用，而不要默认对每个生产请求都开启。
高级控制项
更高级的 inference parameters 可以直接限制或改变 token 选择。一些常见示例包括：
logit_bias可以提高或降低特定 token 的分数。这可以将模型轻推向或远离某些词、标签或格式标记。bad_words会阻止某些词序列。allowed_token_ids会将生成限制在特定 token 集合内。它们很强大，但也很容易误用，因为 tokenization 并不总能与人类可见的词严格对应。
当输出要被软件消费时，应使用这些高级控制。例如，抽取流水线、 function calling 和 structured data generation 通常需要比仅靠 prompt 指令更强的保证。
推荐起点
不存在放之四海而皆准的最佳参数配置。好的默认值取决于任务、模型家族和 serving stack。即使参数相同，不同模型的行为也可能差异很大。
尽管如此，下面这些范围仍然可以作为评估时有用的起点：
| 用例 | Temperature | Top-p | max_tokens | 说明 |
|---|---|---|---|---|
| Classification | 0.0–0.2 | 1.0 | Small, often < 20 | 优先追求确定性输出 |
| Extraction / structured parsing | 0.0–0.2 | 1.0 | Small | 尽量减少变化和格式漂移 |
| RAG / factual QA | 0.1–0.5 | 0.9–1.0 | Moderate | 更低随机性可能有助于减少幻觉 |
| General chat assistant | 0.5–0.8 | 0.9–1.0 | Moderate | 在稳定性和变化性之间取得平衡 |
| Summarization | 0.2–0.7 | 0.9–1.0 | Moderate | 取决于你希望总结更偏抽取式还是更偏生成式 |
| Code generation | 0.0–0.3 | 1.0 | Moderate to large | 更低 temperature 通常会提升语法稳定性 |
| Brainstorming / ideation | 0.7–1.2 | 0.9–0.95 | Moderate to large | 鼓励更多样的输出 |
| Creative writing | 0.8–1.3 | 0.9–0.95 | Large | 多样性更高，但不稳定性也更高 |
这些只是起点，不是规则。请始终使用你真实的 prompts、模型版本和工作负载来评估参数。
对生产系统来说，参数调优同时也是基础设施问题。例如，更长的输出和更探索式的 sampling 可能会增加 latency、GPU 利用率、KV cache 压力，以及负载下的 tail latency。
常见问题
inference parameters 和 model hyperparameters 是一回事吗？
不是。Hyperparameters 通常指训练时使用的设置，例如 learning rate 或 batch size。Inference parameters 则是对已训练模型生成输出时使用的请求期设置。
为什么我的输出会提前停止？
常见原因包括 max_tokens 太低、某个 stop sequence
在正常文本中出现、模型生成了 end-of-sequence token，或 provider
侧的安全/长度限制触发。
所有模型都支持相同参数吗？
不是。托管 provider、OpenAI-compatible servers 和 open-source 引擎暴露的参数子集各不相同。有些参数可能会被忽略、被拒绝，或者根据 serving stack 的不同而有不同实现。