Google I/O 2026 上发布的 Gemini 3.5 Flash 有个参数很多人没注意到：thinking_budget。这个参数能控制模型"想多久再回答"，直接影响输出质量和 token 消耗。

我花了两天时间，用同一批测试题，跑了 4 档思考强度（0、512、2048、不限），记录了每次的 token 用量、响应时间和回答质量。结果挺有意思——不是"想得越多越好"，而是大部分场景下 512 就够了，开到不限反而浪费钱。

先说清楚 Gemini 3.5 Flash 是什么

5月19日 Google I/O 上发布的新模型，定位是"给 Agent 用的 Flash"。几个关键数字：

• 模型 ID：gemini-3.5-flash
• 上下文窗口：100万 token（1,048,576）
• 最大输出：65,536 token
• 输入价格：$1.50 / 百万 token
• 输出价格：$9.00 / 百万 token
• 缓存输入：$0.15 / 百万 token（原价的十分之一）

跟上一代 Gemini 3 Flash 比，价格贵了两倍（3 Flash 是 $0.50/$3.00），但编码能力从 Terminal-Bench 的 52% 跳到了 76.2%。工具调用可靠性（MCP Atlas）83.6%，比 3.1 Pro 还高。

简单说：它不是便宜货了，是真正能干活的 Agent 底座。

thinking_budget 到底是什么

Gemini 3.5 Flash 默认开启"动态思考"——模型先在内部推理一遍，再输出最终答案。推理过程消耗的 token 叫 thinking token，按输出价格（$9.00/百万）计费。

thinking_budget 参数控制模型最多花多少 token 去"想"。设成 0 就不想，直接答。设成 -1 就不限制，想多久想多久。

API 调用方式：

from openai import OpenAI

client = OpenAI(
    api_key="你的key",
    base_url="https://generativelanguage.googleapis.com/v1beta/openai/"
)

response = client.chat.completions.create(
    model="gemini-3.5-flash",
    messages=[
        {"role": "user", "content": "用 Python 写一个线程安全的 LRU 缓存"}
    ],
    max_tokens=4096,
    extra_body={
        "thinking": {
            "thinking_budget": 512
        }
    }
)

注意 extra_body 的写法——这不是标准 OpenAI 参数，是 Gemini 的扩展字段。

实测方案

我准备了 4 类测试题，每类 5 道，共 20 道题：

简单题（分类/提取）：从一段新闻里提取时间、地点、人物；判断一段文字的情感倾向 中等题（生成/摘要）：写一封拒绝合作的邮件；把 2000 字的文章缩到 200 字 复杂题（代码/调试）：用 Python 写一个支持超时的重试装饰器；找出一段有 3 个 bug 的异步代码 高难题（推理/数学）：解一个动态规划问题；证明一个递归算法的时间复杂度

每道题用 4 档 thinking_budget（0、512、2048、-1）各跑一次，记录：

1. 总 token 数（输入 + 输出 + thinking）
2. 响应时间（首 token 到最后一个 token）
3. 回答质量（我自己打分，1-5）

结果数据

简单题（分类/提取）

thinking_budget	平均总 token	平均耗时	平均质量
0	380	0.8s	4.6
512	620	1.4s	4.8
2048	890	2.1s	4.8
-1	1100	2.6s	4.8

简单题设成 0 就行。质量差 0.2 分，但 token 省了近 3 倍。模型分类和提取这种活儿不需要"想"，直接答反而更干脆。

中等题（生成/摘要）

thinking_budget	平均总 token	平均耗时	平均质量
0	850	1.9s	3.4
512	1200	2.8s	4.4
2048	1500	3.5s	4.6
-1	1800	4.2s	4.6

这里 512 和 2048 差距不大（4.4 vs 4.6），但 0 和 512 差了整整 1 分。写邮件、做摘要这种任务，模型稍微想一下，结构和措辞好很多。512 是性价比拐点。

复杂题（代码/调试）

thinking_budget	平均总 token	平均耗时	平均质量
0	1200	3.1s	2.6
512	1800	4.5s	3.8
2048	2600	6.2s	4.4
-1	3400	8.1s	4.6

代码题差别明显。thinking_budget=0 写出来的代码经常漏边界条件，3 个 bug 的调试题只能找到 1-2 个。2048 档位能稳定找全，而且修复方案也靠谱。

高难题（推理/数学）

thinking_budget	平均总 token	平均耗时	平均质量
0	1500	4.0s	1.8
512	2200	5.8s	2.8
2048	3200	8.5s	4.0
-1	5800	14.2s	4.4

高难度场景 thinking 差距最大。不让它想（budget=0），动态规划题基本写不对。开到 2048 才比较稳。-1 档位质量略高但 token 消耗翻倍，不太值。

成本换算

按 $9.00/百万 token 的输出价格算 thinking 成本（输入 token 另算）：

假设你一天调 1000 次 API，全是中等难度任务：

thinking_budget	日均 thinking token	日成本
0	0	$0
512	~350K	$3.15
2048	~650K	$5.85
-1	~950K	$8.55

每天差几美元，看起来不多。但如果你跑 Agent 工作流，一个任务可能连续调用 10-20 次 API，成本就放大了。

我踩的坑

坑1：thinking token 不在 max_tokens 里

max_tokens=2048 只限制最终输出，thinking token 是额外消耗。如果你设了 thinking_budget=-1，一个复杂问题可能产生 8000+ thinking token。月底账单会吓你一跳。

# 生产环境一定要设上限
response = client.chat.completions.create(
    model="gemini-3.5-flash",
    messages=messages,
    max_tokens=2048,
    extra_body={
        "thinking": {
            "thinking_budget": 1024  # 别用 -1
        }
    }
)

坑2：流式输出拿不到 thinking token 数

用 stream=True 的时候，response 里没有 reasoning_tokens 字段。你得用非流式请求才能拿到实际的 thinking 消耗量：

# 监控 thinking 消耗
usage = response.usage
print(f"输入: {usage.prompt_tokens}")
print(f"输出: {usage.completion_tokens}")
# Gemini 扩展字段
if hasattr(usage, 'completion_tokens_details'):
    details = usage.completion_tokens_details
    print(f"thinking: {details.reasoning_tokens}")

建议：开发阶段用非流式，摸清各类 prompt 的 thinking 消耗规律，再上流式。

坑3：缓存 + thinking 配合有讲究

如果你用 prompt caching 缓存长文档，文档部分按 $0.15/百万收费，但 thinking token 还是按 $9.00 算。一个常见误区是以为开了缓存就便宜了——文档部分确实便宜，但 thinking 部分没折扣。

# 长文档 + thinking 的正确姿势
response = client.chat.completions.create(
    model="gemini-3.5-flash",
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": long_document,  # 这部分走缓存
                    "cache_control": {"type": "ephemeral"}
                },
                {
                    "type": "text",
                    "text": "总结这篇文档的三个核心观点"
                }
            ]
        }
    ],
    max_tokens=1024,
    extra_body={
        "thinking": {
            "thinking_budget": 512  # 摘要任务 512 够了
        }
    }
)

坑4：国内直连不稳定

Gemini API 的地址是 generativelanguage.googleapis.com，国内直连经常超时。两个方案：

方案 A：走代理中转（各种 API 聚合平台都支持 OpenAI 兼容接口） 方案 B：用 Google Cloud 的 Vertex AI 端点，部分地区延迟更低

我自己用的方案 A，延迟多了 200-300ms，但胜在稳定。

我的参数选择建议

跑完这 80 次测试（20题 × 4档），我给自己定了一套规则：

分类 / 提取 / 简单问答 → thinking_budget=0
邮件 / 摘要 / 翻译 → thinking_budget=512
代码生成 / 代码审查 → thinking_budget=2048
数学证明 / 复杂推理 → thinking_budget=2048（别用-1，性价比低）

如果你在生产环境跑 Agent，建议在 Agent 的路由层做判断：根据任务类型自动设置 thinking_budget。简单的工具调用给 0，复杂的规划步骤给 2048。

一个简单的路由示例：

def get_thinking_budget(task_type: str) -> int:
    budgets = {
        "classify": 0,
        "extract": 0,
        "summarize": 512,
        "generate": 512,
        "code": 2048,
        "reason": 2048,
    }
    return budgets.get(task_type, 512)

# 在 Agent 循环里用
budget = get_thinking_budget(current_step.task_type)
response = client.chat.completions.create(
    model="gemini-3.5-flash",
    messages=messages,
    extra_body={"thinking": {"thinking_budget": budget}}
)

跟 Claude Sonnet 4.6 的 extended thinking 比怎么样

简单对比：Claude 的 extended thinking 是全有或全无——要么开，要么不开。Gemini 3.5 Flash 的 thinking_budget 能精细控制，适合在 Agent 流水线里按步骤调节。

成本方面，Claude Sonnet 4.6 的输出价格是 $15.00/百万，Gemini 3.5 Flash 是 $9.00/百万。如果你的任务 thinking token 量大，Gemini 便宜不少。

但 Claude 在文字生成质量上还是更稳。写邮件、写文档，Claude 的遣词造句更自然。Gemini 3.5 Flash 更适合代码和工具调用场景。

所以不是非此即彼。我现在的做法是：文字生成用 Claude，代码和 Agent 调度用 Gemini 3.5 Flash。

总结

Gemini 3.5 Flash 的 thinking_budget 是个被低估的参数。用好了，同样的任务成本能省 60-70%。用不好（比如全部 -1），月底账单会很难看。

三句话：简单任务关掉 thinking，中等任务给 512，复杂任务给 2048。不用 -1，性价比太低。生产环境一定要监控 reasoning_tokens。