哪些 Gemini 模型的推理是关不掉的：思考参数怎么设
数据截至 2026-08，价格与限额以各官网为准。本文只讲计费与接入机制，不列具体价格数字。
一句话结论：在 Gemini 这边，“关掉思考”不是一个全局开关，而是一个按型号分叉的能力。官方文档在 OpenAI 兼容层那一节写得很直白——Gemini 2.5 系列可以把 reasoning_effort 设成 "none" 来关闭思考，而 Gemini 2.5 Pro 与 Gemini 3 系列无法关闭推理。这条差异不是文档措辞上的小细节，它直接决定了你能不能靠”关思考”这一招去压输出侧的开销：因为官方定价页的表头明文写着输出价格是包括思考 token 的。换句话说，在关不掉推理的那些型号上，思考产生的 token 会算进输出，你能做的只是调档，不是清零。
先看清 reasoning_effort 在 Gemini 这边到底映射到了什么
从 OpenAI 库那边平移代码过来的时候，很容易下意识把 reasoning_effort 当成一个跨厂商通用的旋钮。它在 Gemini 兼容层确实能用，但它不是原生参数，而是一个映射入口。
官方文档给出的映射关系是：OpenAI 的 reasoning_effort 映射到 Gemini 的 thinking_level（Gemini 3.x）或者 thinking_budget（Gemini 2.5）。注意这里是两个不同的原生参数名，按模型代际分叉——3.x 走 level，2.5 走 budget。你在兼容层里只看到一个参数，底下其实落到了两套机制上。
档位方面，官方列出的是 minimal / low / medium / high 四档。这是一组枚举取值，不是会随行情浮动的数字，可以当作稳定的接口约定来用，但具体取值以官方文档当前版本为准。至于 thinking_budget 的取值范围、thinking_level 各档在底层对应多少预算，官方文档里没有给出说明，这里不做推测。
这个映射带来的第一个直接后果是互斥：官方明确写了，reasoning_effort 与 thinking_level/thinking_budget 功能重叠，不能同时使用。也就是说你不能一边在顶层传 reasoning_effort，一边又从别的通道把原生思考参数塞进去。两个入口指向同一件事，同时给就是冲突。
顺带说一句接入形态。Gemini 的 OpenAI 兼容 base_url 是 https://generativelanguage.googleapis.com/v1beta/openai/，鉴权走 Authorization 请求头的 Bearer 形式；原生 REST 那一侧则是用 x-goog-api-key 请求头。官方原话是从 OpenAI 库切过来只需改三行——api_key、base_url、model。但官方同时给了一条容易被略过的建议：如果你还没有在用 OpenAI 库，推荐直接调用 Gemini 原生 API，而不是绕道兼容层。思考参数这件事恰好是个佐证：兼容层把两套原生参数收敛成一个旋钮，方便是方便，代价是型号差异被压平了，你反而更难看出自己踩没踩到那条”关不掉”的线。想横向理解不同厂商的兼容端点差异，可以对照看各家 OpenAI 兼容端点的差异。
关不掉的那条线，官方是这么划的
这是本篇的核心，也是唯一需要逐字记住的一条。
官方在”关闭思考”这一项下写的是两句话：Gemini 2.5 系列可将 reasoning_effort 设为 "none"；Gemini 2.5 Pro 与 Gemini 3 系列无法关闭推理。
读的时候要注意它的边界。第一，这句话的限定语境是 OpenAI 兼容层的思考参数映射，不要把它扩大成”Gemini 全线接口的通用行为”。第二，它把 2.5 系列整体和 2.5 Pro 单独拆开说了——同一个代际里，Pro 是例外。这种”同代不同档”的差异最容易被想当然抹平：看到 2.5 系列能设 none，就默认 2.5 Pro 也能设，结果参数传下去行为不符合预期。第三，Gemini 3 系列是整体不能关的，这一点和它同时支持 thinking_level 分档是自洽的——能调档不等于能归零。
至于其他型号、其他接口形态下的关闭能力，官方文档里没有找到相关说明，按型号逐个到官方文档确认是唯一靠谱的做法。模型代际更新很快，今天的分界线明天可能就换了位置，所以更值得记住的是”这条线存在”，而不是记住某个具体型号在线的哪一侧。
“不传参数”和”关掉思考”是两回事
这是第二个容易踩空的地方，而且比上一个更隐蔽，因为它不报错。
官方写得很清楚：不指定 reasoning_effort 时，走模型的默认级别或默认预算。默认级别、默认预算具体是什么，以官方文档当前版本为准，这里不写死。
关键在于”默认”不等于”没有”。你什么参数都不传，模型该思考还是思考，只是按它自己的默认档走。有人排查账单时会说”我又没开思考”，问题就出在这儿——思考不是需要你主动打开的功能，而是一个有默认值的档位。真要在支持的型号上关掉，得显式把 reasoning_effort 设成 "none"；而在 2.5 Pro 与 3 系列上，这个动作本身就不成立。
所以排查顺序应该反过来：先确认你用的型号在不在”能关”的那一侧，再去看参数传没传对，最后才去怀疑调用代码有没有别的地方覆盖了设置。顺序反了会白花很多时间在参数上。
关不掉的推理，账单是怎么算的
把能力问题落到钱上，才是这条差异真正的分量。
Gemini 官方 FAQ 里给的计费依据是四项：输入 token 数、输出 token 数、缓存的 token 数、缓存 token 的存储时长。而定价页表头明文写着”输出价格（包括思考 token）“。这两条拼起来的意思是：思考产生的 token 计入输出侧，在关不掉推理的型号上，它就是账单里去不掉的一块。
由此推出一个很实际的估算纪律：估月成本时，输出 token 不能只按你看到的回复文字长度去估。可见回复只是输出的一部分，思考部分同样在里面。如果你之前的成本模型是拿”平均回复字数”换算出来的，换到不能关推理的型号上，这个模型会系统性偏低。
那还能做什么？官方在长上下文那一节的 FAQ 里给了三条实操结论，虽然它们讲的是长上下文场景，但对压总 token 量同样直接有效：一是把查询或问题放在提示的末尾，也就是放在所有其他上下文之后，官方说在总上下文很长时这样效果更好；二是不需要传给模型的 token 就别传；三是有一组要重复使用的相似上下文时，用上下文缓存来降本。前两条压的是输入侧，第三条对应的正是计费四项里”缓存的 token 数”和”缓存存储时长”这两项——注意 Gemini 的缓存存储是单独计费的，用缓存换成本时这笔账要一起算进去。
再往上一层，成本这件事最终还是要靠监控兜住，而不是靠单次调参。建立可持续的API 成本监控习惯，比反复纠结某个参数值更有用；输出侧的整体控制思路也可以参考输出长度怎么控。
兼容层里想传 Gemini 自己的思考字段：extra_body
如果确实要在 OpenAI 兼容层里传 Gemini 专有字段，官方给的通道是 extra_body，路径是 extra_body.google.thinking_config，其下有 thinking_level 与 include_thoughts 两个字段。
这条通道的意义在于：兼容层不是一个只能走最小公约数的窄门，专有能力有正式出口。但要提醒一句，官方那条互斥规则的原文只写到参数层面——reasoning_effort 与 thinking_level/thinking_budget 功能重叠、不能同时使用；extra_body.google.thinking_config 这条通道官方没有单独说明它算不算同一件事。既然它传下去的字段名就叫 thinking_level，保守起见别两边都写，把档位固定在一个入口。
include_thoughts 这个字段的具体行为，官方文档里只给了字段名，没有找到进一步的说明，这里不替它编一个语义。要用之前请到官方参考文档核对。
Gemini 3 还多了一层思考签名
关不掉推理的型号上，还有一个配套机制值得提前知道：官方写明 Gemini 3 支持在 chat completions API 中使用 OpenAI 兼容的思考签名（thought signatures）。
这个机制在错误码体系那边有对应的落点。Gemini 的生成结构错误码里有一个 missing_thought_signature，含义是响应缺少必需的 thought 签名。和它同族的还有 malformed_function_call（函数调用无法解析）、malformed_tool_call、unexpected_tool_call（调用了请求中未声明的工具）、too_many_tool_calls（工具调用数超上限）等。这一族错误的共同点是：问题出在模型输出本身的结构上，不是你的请求格式错了，所以对照 API 参考检查入参往往查不出东西。
做 Agent 或者多轮工具调用的时候，这一族码值得提前认一遍。真遇到了，先分清它属于哪一族再动手，别拿处理 400 的思路去处理它。错误码分族这件事在 Gemini 这边尤其要紧，连 429 都分成两种语义完全不同的情况，退避重试只救得了其中一种。
流式调用时，思考相关的错误可能不在 HTTP 状态码里
最后补一个容易漏的场景。兼容层是支持流式的（stream=True），而 Gemini 的错误传递方式在流式与非流式之间不一样。
官方文档说明：标准的非流式请求，错误通过设置 HTTP 状态码加上 JSON body 里的 error 对象返回；而流式请求（SSE，stream: true）是通过 SSE 流发送 event_type 为 "error" 的事件，error 字段结构相同。
直接后果是：只判 HTTP 状态码的客户端，会漏掉流式过程中发生的错误。你的连接可能建立成功、状态码一切正常，错误藏在流里面。做长输出、开着思考、又用流式的组合时，这个漏判尤其致命——你看到的是一段截断的输出，代码那边却觉得请求成功了。详细的排查路径见Gemini 流式请求的错误不走 HTTP 状态码。
落到操作上：按这个顺序确认三件事
第一，确认你手上这个型号在不在”能关”的那一侧。官方明文只给了两条线：2.5 系列可设 "none"，2.5 Pro 与 Gemini 3 系列无法关闭推理。超出这两句话的型号判断，去官方文档查，别靠代际类推，也别拿别家平台的行为往这边套。
第二，确认参数只从一个入口进。reasoning_effort 和 thinking_level/thinking_budget 功能重叠不能同时用，extra_body.google.thinking_config 里的 thinking_level 也属于同一件事。团队协作时这条最容易破——有人在封装层里默认塞了一个档位，调用方又在业务代码里传了一次。
第三，如果型号确实关不掉推理，就别在参数上继续耗，把力气放到成本模型上：输出 token 包含思考 token，估算口径要相应调整；输入侧按官方那三条办法压，重复上下文用缓存换，同时把缓存存储的开销一并算进去。
最容易栽的坑就一句话：把”不传参数”当成”关掉了”，再把 2.5 系列能设 none 这件事顺手推广到 2.5 Pro 和 Gemini 3 上。这两个动作都不报错，账单会替你报。