如果你从GPT-4o切换到o1或o3这类推理模型，第一件事很可能就是踩到temperature这个坑：原本运行得好好的请求突然返回400错误，提示Unsupported parameter: temperature is not supported with this model。这个报错让很多人困惑，temperature从GPT-3时代就是最常用的调参手段，为什么到了推理模型反而不能用了？这篇文章就来把这件事讲清楚，包括背后的原因、接口差异以及迁移时的正确写法。
一、o系列模型为什么要禁用temperature
先看结论：o1、o3、o4-mini等o系列推理模型在API调用时不接受temperature、top_p、frequency_penalty、presence_penalty这些采样参数，只允许使用默认值1。如果你显式传入temperature=0.7这样的配置，服务端会直接拒绝请求并返回400错误，而不是像传统模型那样默默生效。
这么做的原因和推理模型的工作机制有关。传统GPT-4o这类模型是逐token采样的，temperature控制的是采样分布的平坦程度：温度越低，模型越倾向于选择概率最高的词元，输出越确定；温度越高，分布越平坦，输出越发散。而o系列模型在生成最终回答之前，会先在内部执行一段长长的思维链推理，这个推理过程的质量直接决定最终答案的准确性。如果允许开发者用低温去压缩推理链的采样空间，思维链可能会过早收敛到某个错误方向，反而损害模型的推理能力。
换句话说，OpenAI为了保证推理链的充分探索，把采样策略锁死在了一个经过验证的默认状态。这是一种工程上的取舍：牺牲灵活性，换取推理结果的稳定性。对于数学、代码这类有明确对错的任务，这个设计是合理的。
二、两种接口下的具体表现
Chat Completions接口是最容易踩坑的地方。下面这段代码在GPT-4o上完全正常，换成o3就会报错：
from openai import OpenAI
client = OpenAI()
# 错误写法：o系列模型不支持temperature
resp = client.chat.completions.create(
model="o3",
messages=[{"role": "user", "content": "证明根号2是无理数"}],
temperature=0 # 会抛出400错误
)
# 正确写法：直接省略所有采样参数
resp = client.chat.completions.create(
model="o3",
messages=[{"role": "user", "content": "证明根号2是无理数"}]
)
print(resp.choices[0].message.content)注意不只是temperature，top_p、frequency_penalty、presence_penalty这几个参数同样要整体省略，传成默认值也不行。另外早期o1版本对max_completion_tokens的命名也做了调整，旧字段max_tokens已废弃，迁移时要一并改掉。
如果使用较新的Responses接口，参数体系有所变化，采样参数同样不在可配置范围内，但多出了一个很有用的参数reasoning_effort。它可以设置为low、medium、high三个档位，控制模型在生成答案前投入多少推理算力。档位越低，响应越快、token消耗越少；档位越高，推理链越长，适合复杂问题。
resp = client.responses.create(
model="o3",
input="分析这段代码的时间复杂度并给出优化方案",
reasoning={"effort": "high"} # 通过推理深度间接影响输出
)三、想要确定性输出该怎么办
很多开发者想调低temperature，本质需求是让输出更稳定、更可复现。既然o系列模型封死了这条路，就需要换一种思路来满足这个需求。
第一种思路是用reasoning_effort代替。对于有明确标准答案的任务，把effort设为high，模型会进行更充分的推理，答案的正确率和稳定性都会提升，效果上接近甚至优于低温采样。相反，如果是简单分类、信息抽取这类任务，用low档位既省钱又快，还不容易过度思考。
第二种思路是靠提示词约束。o系列模型对system prompt和开发者指令的遵循度比早期模型高很多，通过在提示词中明确要求固定格式、固定风格，可以稳定输出结构。配合JSON模式使用时，用response_format指定json_schema，输出格式是完全可控的，弥补了一部分采样参数缺失带来的影响。
resp = client.chat.completions.create(
model="o3",
messages=[
{"role": "system", "content": "始终以JSON格式输出，字段固定为answer和confidence"},
{"role": "user", "content": "北京的人口大约是多少"}
],
response_format={
"type": "json_schema",
"json_schema": {
"name": "answer_schema",
"schema": {
"type": "object",
"properties": {
"answer": {"type": "string"},
"confidence": {"type": "number"}
},
"required": ["answer", "confidence"]
}
}
}
)第三种思路是接受一定的不确定性并做好工程兜底。即使是temperature=1，o系列模型在数学和逻辑题上的表现也远比传统模型稳定，因为确定性主要来自推理链本身而不是采样温度。在业务层加上重试、校验和结果比对逻辑，往往比纠结采样参数更实际。
四、迁移清单与常见坑
总结一下从传统模型迁移到o系列时需要检查的项目：第一，删掉所有采样参数，包括temperature、top_p和两个penalty；第二，把max_tokens改成max_completion_tokens；第三，注意部分o系列模型对system消息的支持情况，旧版o1-preview只能用developer角色；第四，评估是否需要开启streaming，推理模型的首token延迟较长，流式输出对用户体验改善明显。
还有一个容易忽略的坑是成本估算。推理模型消耗的token包含思维链部分，这部分在响应中不一定完整返回，但计费时会算进去。用reasoning_effort的low档位可以显著压缩这部分隐性开销，做容量规划时一定要把这个因素考虑进去，不要直接套用GPT-4o的用量数据。
总的来说，temperature在o系列模型上被禁用不是功能倒退，而是推理模型架构下的必然选择。理解了思维链与采样策略的关系，用reasoning_effort加上结构化输出这些新工具来替代传统的调温手段，迁移工作就会顺畅很多。
OpenAI API推理模型temperature参数修改时间：2026-09-12 00:26:34