首页/AI/大模型部署与运维速查/temperature:控制输出随机性
推理参数与优化50 条

temperature:控制输出随机性

采样前对 logits 做缩放:温度越低分布越尖锐、输出更确定,温度越高越发散;接近 0 时基本退化为贪心解码(以框架实现为准)。

temperature 是什么

温度是采样前对输出分布做的缩放系数:把模型的原始打分除以温度后再做归一化。温度低,分布更尖锐,高概率词的优势被放大,输出稳定;温度高,分布更平坦,低概率词也有机会被选中,输出发散。降到接近 0 时基本退化为贪心解码,即每步都取概率最高的词。它不改变模型权重,只改变挑词的方式。

基本信息

适用平台OpenAI 兼容接口、vLLM、Transformers、llama.cpp 等同名参数
取值类型浮点数,通常 0 到 2 之间,超过 1 后质量下降明显
默认值各实现不同,不要假设与云端 API 一致
与 top_p 关系两者都做分布裁剪,一般只调其中一个
典型用法抽取与分类取低值,创作类取中高值

取值参考

任务类型参考区间原因
信息抽取与结构化输出0 到 0.2要的是稳定命中,发散只会带来格式错误
分类与判定0 到 0.3同一输入应得同一结论,便于回归与对账
代码与命令生成0.1 到 0.3语法要求严格,随机性主要带来无效尝试
常规问答与摘要0.3 到 0.7兼顾表达自然与事实稳定
创意写作与头脑风暴0.7 到 1.0需要多样性,但仍要有基本连贯性

典型使用场景

  • 线上抽取任务固定温度:让同样的输入稳定产出同样的结构,方便对账与回归
  • 客服与知识问答压低温度:减少自由发挥,降低编造细节的概率
  • 创意类功能放宽温度:文案与命名的多样性来自采样空间,而不是模型本身
  • 排查输出格式问题:先把温度归零排除采样干扰,再判断是提示词还是模板问题
  • 对比模型效果:评估时统一温度与其它采样参数,否则差异无法归因

两种调用方式

两种调用方式
# OpenAI 兼容接口:参数与 messages 同级
curl http://127.0.0.1:8000/v1/chat/completions -H 'Content-Type: application/json' -d '{
  "model": "<模型名>",
  "messages": [{"role": "user", "content": "把下面这段文本抽成 JSON"}],
  "temperature": 0
}'
# Python SDK:base_url 指向自建服务,key 可留占位
python - <<'PY'
from openai import OpenAI
client = OpenAI(base_url="http://127.0.0.1:8000/v1", api_key="EMPTY")
r = client.chat.completions.create(model="<模型名>",
    messages=[{"role": "user", "content": "你好"}], temperature=0.2)
print(r.choices[0].message.content)
PY
温度与核采样阈值同时大改会让效果无法归因:调参时固定其余参数,一次只动一个,记录每次改动前后的输出样例。
自建服务与云端 API 的默认温度可能不同:迁移到自建引擎后先回归对比输出质量,尤其是抽取与分类这类对稳定性敏感的功能。

易错点

  • 把 temperature=0 当作完全确定:批处理与算子差异仍可能影响极少数 token 的选择,强复现要求还要固定随机种子与实现版本
  • 温度与核采样阈值一起调:出问题时无法判断是哪个参数导致的变化
  • 线上不显式设置温度而依赖默认值:换引擎或升级版本后默认值变化,输出风格悄然改变
  • 用高温度掩盖提示词缺陷:提示词本身不明确时,提高温度只会让不稳定更明显
  • 只在单条样例上验证温度效果:至少用一批固定测试集对比,观察整体的稳定性与正确率

数据来源与参考

  • OpenAI API 参考:temperature(platform.openai.com/docs)
  • Hugging Face 文本生成文档(huggingface.co/docs/transformers)
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌