同时对接多家大模型 API 的人一定有过这种体验：明明参数名字都差不多，换个模型就 400 了。temperature 都叫 temperature，范围却不一样；thinking 都能开，开了之后别的参数还能不能用，各家说法完全不同。
这篇文章把 Anthropic Claude、OpenAI GPT、DeepSeek、GLM（智谱）四家的核心 API 参数拉到一起做对比。重点讲两件事：推理模式怎么控制，采样参数有哪些暗坑。
一、推理模式：四家四种玩法
"让模型先想再答"是当前大模型最热的能力方向，也是 API 参数分化最严重的地方。
Anthropic：精确到 token 的预算制
Claude 的做法最直白——你告诉模型"最多花多少 token 想"：
{
"thinking": {
"type": "enabled",
"budget_tokens": 8000
}
}
budget_tokens 最小 1024，必须小于 max_tokens。这种精确控制的好处是可预测——你能精确估算推理成本。
新版模型引入了自适应思考，不再接受 budget_tokens，模型自行决定思考深度。注意：对着自适应模型发 budget_tokens 会直接 400。同一家的不同模型版本，参数都不通用。
OpenAI：档位制，简单粗暴
OpenAI 的 Responses API 没有显式的 thinking 开关，用 reasoning.effort 来控制推理深度：
{
"reasoning": {
"effort": "high",
"summary": "auto"
}
}
就四档：minimal / low / medium（默认）/ high。没有精确的 token 预算概念，模型自己决定具体花多少算力。
这种设计对普通开发者友好——不需要理解"8000 token 的思考预算意味着什么"，选个档就行。
DeepSeek：兼容协议 + 私有扩展
DeepSeek 走 OpenAI 兼容协议，但 thinking 是私有扩展，得塞进 extra_body：
// 需要通过 extra_body 发送
{
"thinking": {
"type": "enabled"
}
}
它也有 reasoning_effort，但只有 high 和 max 两档——跟 OpenAI 的四档不兼容，跟 GLM 的七档更不兼容。
GLM：档位最多，还有独有参数
GLM 同样通过 extra_body 开启 thinking，语法和 DeepSeek 一致。
独特之处有两个：
clear_thinking 参数（布尔值）：控制多轮对话时是否保留上一轮的思考链上下文。这在连续推理场景下很有用，其他厂商都没有对应功能。
七档 reasoning_effort（新型号）：none / minimal / low / medium / high / xhigh / max，粒度是所有厂商中最细的。
推理模式对比
| 开启方式 | 原生字段 | reasoning.effort 隐式 | extra_body | extra_body |
| 深度控制 | token 预算（精确值） | 4 档 | 2 档 | 7 档（新型号） |
| 自适应 | 部分新模型 | 默认全部自适应 | 无 | 无 |
| 独有能力 | budget 精确控制 | summary 摘要输出 | — | clear_thinking |
二、推理开启后的连锁反应
这是最容易踩坑的地方：推理模式开启后，采样参数的行为会发生变化，而且各家处理方式不同。
| Anthropic | temperature 强制锁 1.0，top_p/top_k 被忽略（不报错但无效） |
| OpenAI Responses | 本就不支持这些参数，发了直接 400 |
| DeepSeek | 可以发，但被静默忽略 |
| GLM | 可以发，行为未定义（官方未说明） |
这意味着：如果你的接入层在发送请求前不检查 thinking 状态，用户设置的 temperature 可能"看起来生效了"但实际完全没用，造成难以排查的效果偏差。
三、采样参数：范围和规则的差异
temperature 的范围陷阱
| Anthropic | 0 – 1 |
| OpenAI Chat Completions | 0 – 2 |
| DeepSeek | 0 – 2 |
| GLM | 建议 0.2 – 0.8 |
| OpenAI Responses API | ❌ 不支持 |
你在 OpenAI 上调到 1.5 的效果很满意，直接转发给 Claude 就炸了。统一接入层要么做范围裁剪，要么在 UI 层就按最严约束（0–1）暴露。
temperature 与 top_p 的互斥问题
这两个参数的关系，各家态度不同：
- GLM：强制互斥，同时发直接报错
- Anthropic：明确推荐只设其一，同时发行为未定义
- OpenAI / DeepSeek：文档说"建议只调一个"，实际同时发不报错
最安全的策略：适配层做互斥拦截，两个都有值时保留 temperature、置空 top_p。
各家独占参数
有些参数只有特定厂商支持，在其他地方发了要么报错要么被忽略：
| top_k | Anthropic | 限制候选 token 数，其他家都没有 |
| frequency_penalty | OpenAI Chat Completions | 基于频率惩罚，范围 -2 到 2 |
| presence_penalty | OpenAI Chat Completions | 惩罚已出现 token，范围 -2 到 2 |
| clear_thinking | GLM | 控制多轮思考链是否保留 |
stop sequences 的上限差异
| Anthropic | 8191 条 |
| DeepSeek | 16 条 |
| OpenAI | 4 条 |
差距极大。如果你依赖大量 stop sequences 做结构化输出，切到 OpenAI 时可能需要完全换策略。
四、完整速查表
采样参数支持矩阵
| temperature | ✅ 0–1 | ✅ 0–2 | ❌ | ✅ 0–2 | ✅ |
| top_p | ✅ | ✅ | ❌ | ✅ | ✅ |
| top_k | ✅ | ❌ | ❌ | ❌ | ❌ |
| frequency_penalty | ❌ | ✅ | ❌ | ❌ | ❌ |
| presence_penalty | ❌ | ✅ | ❌ | ❌ | ❌ |
| stop sequences | ≤8191 | ≤4 | ❌ | ≤16 | 未明确 |
| max_tokens | ✅（必填） | ✅ | ✅ | ✅ | ✅ |
互斥与约束规则
| temperature 与 top_p 互斥 | GLM 强制，Anthropic/OpenAI 推荐 | GLM 报错，其他行为不确定 |
| thinking 开启 → 采样参数失效 | 全部 | 各家处理方式不同（见第二节） |
| Responses API 不接受采样参数 | OpenAI o 系列 / GPT-5 | 直接 400 |
五、设计建议
如果你正在做多模型统一接入，以下是几条实战建议：
参数范围取交集。统一 UI 上的 temperature 暴露 0–1，stop sequences 上限取 4 条。超出范围在适配层裁剪，别让用户直面 400 错误。
thinking 状态要感知采样参数。推理模式开启时，适配层应自动屏蔽或忽略 temperature / top_p 的用户设置，而不是透传后让模型自己处理（因为各家处理方式不一致）。
用 capability 描述而非 if-else。每接一个新模型就加一堆条件判断会很快失控。更好的做法是维护一份模型能力描述（支持哪种 thinking、temperature 范围多少、哪些参数互斥），让适配逻辑基于描述驱动。
区分用户可调和系统配置。适合放进对话界面让用户随时调的：temperature、thinking 开关、reasoning effort。应该锁在后台配置的：stop sequences、penalty 参数、budget_tokens、clear_thinking——要么太技术化，要么太场景化。
写在最后
四家厂商的参数设计反映了不同的产品哲学：
- Anthropic 给你精确控制权——预算精确到 token 数，但也要求你理解这意味着什么
- OpenAI 替你做选择——四个档，够用就行
- DeepSeek 走兼容路线——协议复用但功能私有扩展
- GLM 追求粒度最大化——七档 effort，还有多轮思考链控制
对接一家时这些差异无所谓，同时对接四家时就变成了工程问题。没有银弹，只能逐个参数对齐。但至少，你可以提前知道坑在哪。
