Gemini 3.5 Flash thinking_level 怎么迁移：从 thinking_budget 到四档推理强度的选择与验收

直接把Gemini 2.5的 thinkingBudget 硬套到Gemini 3.5 Flash上，最常见的问题不是语法报错，而是参数虽然能正常发送出去，但最终输出的推理强度和你之前在旧版本上跑出来的基线完全对不上。Google给Gemini 3.x系列更推荐用 thinking_level，直接把过去“给多少token作为思考预算”的机制，改成了直接选择对应档位的推理强度。

先分清 Gemini 2.5 与 Gemini 3.x 的参数边界

thinkingBudget 是 Gemini 2.5 系列专属的数值预算配置入口，常用的赋值是 0、-1 或者模型允许范围内的任意整数。Gemini 3.x 的官方文档建议直接用 thinkingLevel，在REST JSON请求里通常对应的字段名是 thinking_level 来表示推理强度。

这根本不是简单的单位换算问题。旧配置里设的7500，不可能机械对应到某一个固定的档位。各个档位本质是模型侧预设的一组策略集合，实际请求的复杂度、模型本身的默认值、上下文长度变化，都会最终影响实际消耗的思考资源。

最小迁移写法：只替换思考配置，不改提示词

先把模型名称、提示词内容、输出格式完全固定下来，只调整思考相关的参数。这样测出来的差异才完全来自推理档位的变化，不会因为同时改了提示词混淆变量。

generation_config = {
    "thinking": {
        "thinking_level": "medium"
    }
}

如果你用的是新版Google GenAI SDK，对应的字段名可能会被SDK自动做映射；如果是直接发REST JSON请求，以当前接口文档里标注的 thinking_level 为准就行。旧项目可以先保留一个完全独立的配置分支：

if model.startswith("gemini-2.5"):
    thinking = {"thinkingBudget": 0}
else:
    thinking = {"thinking_level": "minimal"}

上面的分支逻辑只是示意，实际接入的时候还要把模型名、请求体结构和响应解析逻辑一起纳入回归测试。千万不要在同一次实验里同时切换模型、修改系统提示词、更换输出schema。

四档等级怎么选：从任务压力出发

我们之前内部评测的结果显示，短文本分类用 minimal 就可以跑通；需要在多条规则之间做取舍的场景，low 的表现会更稳定；多步骤代码审查、跨文件信息推断这类场景，通常从 medium 开始测试效果才达标；只有复杂规划、深层逻辑分析，或者对漏判容错率极低的任务，才有必要尝试 high。

• minimal：意图明确、输出答案短、偶尔出错可以快速重试的任务。
• low：字段抽取、简单路由分发、短代码解释这类只需要少量逻辑判断的任务。
• medium：多条件交叉比较、常规代码审查、带明确约束的方案设计类任务。
• high：长链路规划、复杂边界条件分析，宁可适当降低响应速度也要尽可能压低漏判概率的任务。

档位越高不等于输出质量一定越好。对于结构完全固定的抽取任务，拉高档位可能只会白白增加延迟；对于需要连续多步推断的任务，低档配置反而可能更快返回一个看起来完整实则漏了关键判断条件的结果。

用同一组样本做迁移验收

至少提前准备三类测试样本：一个短文本分类用例、一个多约束问答用例、一个故意埋了边界条件的代码或数据问题用例。每个档位都跑完全相同的样本集，完整保存请求参数和响应里的usage字段。

checks = {
    "minimal": {"latency_ms": 0, "quality": 0, "thought_tokens": 0},
    "low": {"latency_ms": 0, "quality": 0, "thought_tokens": 0},
    "medium": {"latency_ms": 0, "quality": 0, "thought_tokens": 0},
    "high": {"latency_ms": 0, "quality": 0, "thought_tokens": 0}
}

把抽象的“输出质量”拆成一个个可以自动复核的断言：返回的JSON能不能正常解析、所有必填字段有没有缺漏、生成的代码能不能通过单测、引用的事实信息是不是在允许的范围内。不要用“感觉结果更聪明”这种主观感受替代标准化验收。

• 请求层：确认模型名和思考等级确实正确写入了最终发出去的请求体。
• 响应层：记录请求完成状态、输出文本、usage字段里的思考token和总token消耗。
• 业务层：跑一遍预设的固定断言，统计漏判、格式错误和需要重试的比例。
• 运营层：按照真实流量规模估算延迟长尾表现和整体成本，不要只拿平均值做对比。

哪些场景不该直接升到 high

如果你的任务是固定标签分类、简单字段抽取或者短文本改写，先从 minimal 或者 low 开始测，慢慢收集失败样本。只有确认失败原因确实是推理能力不足，而不是schema写错、提示词有漏洞或者输入数据没清洗干净，升档才有实际意义。

反过来讲，复杂的多步任务也没必要一上来就直接锁死 high。先用 medium 跑一轮全量样本，检查输出质量是不是已经达到业务要求的阈值；如果拉高档位之后只变长了延迟，关键错误却没有明显减少，直接回退到更低档位就好。

常见问题

Gemini 3.5 Flash 还能继续传 thinkingBudget 吗？

迁移到Gemini 3.x系列之后，优先改用 thinking_level。接口会不会兼容旧字段以当前模型的实际返回为准，不要把临时的兼容现象当成长期生效的契约。

thinking_level 能和 thinkingBudget 同时传吗？

不要把两套不同体系的参数塞在同一份请求里。按照你当前使用的模型系列选其中一套参数就好，在请求构造层写清楚明确的分支逻辑。

怎么证明 high 档位值得它对应的额外成本？

用固定测试样本跑对比，分别统计关键错误数、延迟长尾表现和思考token消耗。只有质量提升的收益能覆盖额外增加的业务成本时，再把high档位切到生产流量里。

切换等级后为什么结果还是不稳定？

先排查随机性、模型版本、提示词内容和上下文有没有同步变动，再看测试样本量是不是足够。思考等级本身不是确定性输出的开关。

迁移后的回滚清单

上线之前要保留旧版本模型的完整配置和一组验证过的基线样本；灰度放量的时候按档位分别记录延迟、失败类型和思考token消耗；如果出现格式大范围错误或者成本异常飙升，先回到上一个已经验证通过的稳定档位，再慢慢定位问题出在参数、提示词还是业务断言环节。整个迁移完全是可回滚的配置变更，不需要做一次性的全局押注。