Gemini 3.1 Pro 的 thinking_level 怎么选、账单怎么控：开发者上手笔记

2 月 19 号 Google 发了 Gemini 3.1 Pro。宣传语照例是"most advanced model for complex tasks"，我关心的是三件事：API 怎么接、thinking_level 怎么配、一个月下来到底花多少钱。

跑了一周，把这几件事搞清楚了。也踩了一些坑。

先说 thinking_level，这是 3.1 Pro 最值得关注的变化

之前我写过一篇 Opus 4.6 的 effort 参数分档。Gemini 3.1 Pro 有个类似的东西叫 thinking_level，分 LOW、MEDIUM、HIGH 三档。

3.0 Pro 只有 LOW 和 HIGH。3.1 Pro 加了 MEDIUM，同时把 HIGH 档的推理能力大幅增强——挂载了一个叫 Deep Think Mini 的内部推理引擎。ARC-AGI-2 跑出 77.1% 就是 HIGH 档的成绩，LOW 档跑同样的题只有 30% 出头。

三档的实际表现差异很大：

thinking_level	推理 token 预算	典型响应时间	适合场景
LOW	200-500 tokens	1-3 秒	分类、翻译、提取、路由
MEDIUM	~8,192 tokens	3-10 秒	代码审查、摘要、一般分析
HIGH	~32,768 tokens	30 秒以上	数学证明、复杂推理、竞赛级编程

一个容易搞混的点：3.0 Pro 的 HIGH 大致等于 3.1 Pro 的 MEDIUM。如果你之前在 3.0 Pro 上用 HIGH 跑得好好的，切到 3.1 Pro 可以先试 MEDIUM，效果差不多但便宜一截。

API 接入

Python SDK

from google import genai
from google.genai import types

client = genai.Client()

response = client.models.generate_content(
    model="gemini-3.1-pro-preview",
    contents="分析这段代码的性能瓶颈",
    config=types.GenerateContentConfig(
        thinking_config=types.ThinkingConfig(
            thinking_level="MEDIUM"
        )
    ),
)

print(response.text)
print(f"思考 token：{response.usage_metadata.thoughts_token_count}")
print(f"输出 token：{response.usage_metadata.candidates_token_count}")

thoughts_token_count 这个字段很关键。后面算账全靠它。

REST API

{
  "contents": [{"parts": [{"text": "你的 prompt"}]}],
  "generationConfig": {
    "thinkingConfig": {
      "thinkingLevel": "MEDIUM"
    }
  }
}

如果不设 thinkingLevel，默认走 HIGH。这意味着你的每次请求都在触发 Deep Think Mini，产生大量推理 token。很多人第一个月账单偏高就是这个原因。

OpenAI 兼容格式

一些第三方网关支持 OpenAI 格式调用：

import openai

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

response = client.chat.completions.create(
    model="gemini-3.1-pro-preview",
    messages=[{"role": "user", "content": "你的 prompt"}],
    extra_body={
        "thinking": {"type": "enabled", "budget_tokens": 8192}
    }
)

budget_tokens 和 thinking_level 的大致对应关系：8192 ≈ MEDIUM，32768 ≈ HIGH。

定价：看着便宜，但推理 token 是个坑

先列基础价格：

项目	标准价（≤200K 输入）	长上下文价（>200K 输入）
输入	$2.00 / 百万 token	$4.00 / 百万 token
输出（含推理 token）	$12.00 / 百万 token	$18.00 / 百万 token
缓存读取	$0.20 / 百万 token	$0.40 / 百万 token
缓存写入	$0.50 / 百万 token	—
缓存存储	$4.50 / 百万 token / 小时	—

重点在"输出（含推理 token）"这行。推理 token 按输出价格计费，$12/百万。HIGH 档一次请求可能产生 3 万推理 token，光推理部分就是 $0.36。如果你的实际输出只有 500 token（$0.006），推理 token 是实际输出的 60 倍。

拿三个场景算一下：

场景	thinking_level	输入 token	推理 token	输出 token	单次成本
代码审查（200 行）	MEDIUM	3,000	8,000	800	$0.112
代码审查（200 行）	HIGH	3,000	30,000	1,500	$0.384
文档摘要	LOW	50,000	300	500	$0.110
文档摘要	HIGH	50,000	25,000	2,000	$0.424
数学推理	HIGH	500	32,000	1,000	$0.397

同一个任务，LOW 和 HIGH 之间可以差 3-4 倍。日调用量上千的话，一个月差几百美元。

和 Opus 4.6、GPT-5.2 对比

模型	输入价	输出价	上下文窗口
Gemini 3.1 Pro	$2.00/M	$12.00/M	1M tokens
Claude Opus 4.6	$5.00/M	$25.00/M	200K（1M beta，Tier 4）
Claude Sonnet 4.6	$3.00/M	$15.00/M	200K（1M beta，Tier 4）
GPT-5.2	$1.75/M	$14.00/M	400K tokens

Gemini 3.1 Pro 的输入价比 Opus 4.6 便宜 60%，输出价便宜 52%。和 Sonnet 4.6 比也有优势。GPT-5.2 输入稍便宜，但输出贵 $2。

按月 5000 万 token（1500 万输入 + 3500 万输出）算：

• Gemini 3.1 Pro：$450/月
• Claude Sonnet 4.6：$570/月
• Claude Opus 4.6：$950/月
• GPT-5.2：$516/月

差距在百美元级别。选谁不完全看价格，但价格确实是 Gemini 3.1 Pro 的优势。

省钱的两个关键操作

Batch API：所有 token 价格打五折。输入 $1.00/M，输出 $6.00/M。代价是异步处理，通常 24 小时内返回。数据标注、批量分类、报告生成这类不需要实时响应的任务，没理由不用 Batch。

Context Caching：如果你的 system prompt 或参考文档在多次请求间重复，缓存可以把重复部分的读取成本从 $2.00/M 降到 $0.20/M，降了 90%。举个例子：5 万 token 的 system prompt，每月调用 1 万次，不缓存要 $1,000，缓存后约 $100。最低缓存门槛是 4,096 token。

跑分：赢在哪，输在哪

直接上对比表：

基准测试	Gemini 3.1 Pro	Claude Opus 4.6	GPT-5.2	说明
ARC-AGI-2	77.1%	68.8%	52.9%	抽象推理
GPQA Diamond	94.3%	91.3%	92.4%	科学推理
AIME 2025	91.2%	84.5%*	82.1%*	数学竞赛
SWE-Bench Verified	80.6%	80.8%	80.0%	代码修复
MMLU	90.4%	91.8%*	90.2%	知识问答
VideoMME	87.2%	79.2%	81.3%	视频理解
LM Arena Elo	1,489	1,462	1,452	人类偏好
GDPval-AA Elo	1,317	1,606	—	专家偏好

*部分数据来源为 Opus 4.5/GPT-5.1 时期，仅供参考

几个值得注意的点：

ARC-AGI-2 领先幅度很大，比 Opus 4.6 高了 8 个百分点。但这是 HIGH 档（Deep Think Mini）跑出来的，推理成本也高。

SWE-Bench 三家几乎打平，差距在 0.8 个百分点以内。选谁都不会在代码修复能力上吃亏。

GDPval-AA Elo 是专家盲评偏好，Opus 4.6 的 1,606 远超 Gemini 的 1,317。跑分赢了不代表实际用起来专家就更满意。这中间有一段距离。

VideoMME 是 Gemini 的强项，比 Opus 4.6 高了将近 8 个百分点。如果你的业务涉及视频分析，这个差距有实际意义。

3.1 Pro 相比 3.0 Pro 的提升也值得看：

基准	3.0 Pro	3.1 Pro	提升
SWE-Bench Verified	67.2%	71.4%	+4.2pp
AIME 2025	86.0%	91.2%	+5.2pp
GPQA Diamond	84.1%	87.8%	+3.7pp
VideoMME	84.8%	87.2%	+2.4pp

同价升级，没有不换的理由。

已知问题

跑了一周碰到的问题和社区反馈汇总。

配额消耗异常

多个用户反馈配额掉得比 3.0 Pro 快大约 2 倍。我自己测试时也注意到了，同样的 prompt 在 3.0 Pro 和 3.1 Pro 上的 token 消耗不一样。3.1 Pro 的 HIGH 档因为推理更深，一次请求的总 token 数可以是 3.0 Pro 的好几倍。

锁号

GitHub 讨论里最多的投诉是锁号。付费用户（AI Pro 订阅）用 Gemini CLI 时，触发 5 小时配额窗口三次后被锁 90-99 小时。有人报告只用了一小时就被锁了 3-7 天。

这个问题目前没有官方解决方案。API 密钥用户不受影响，只有 Google 账号登录的用户才会碰到。

工具调用兼容性

Tool calling 在几个主流框架上有问题。社区报告 LangChain4j、n8n、RooCode、Cursor 里的工具调用存在不同程度的 bug。Vercel AI SDK 的结构化输出和 Code Execution 工具同时使用会报 AI_NoOutputGeneratedError。

如果你的应用依赖 tool calling，建议先在测试环境验证，不要直接切生产。

发布日延迟

这个是情绪问题，不影响技术选型。Google 官宣"今日可用"，但 Gemini CLI 用户等了好几天才拿到访问权限。API 密钥用户倒是当天就能用。中间的信息差引起了不少抱怨。

首日延迟

发布当天有用户测到单次请求延迟 104 秒。这应该是容量问题，后面几天恢复正常了。但如果你赶在发布当天就切生产，可能会被坑一下。

什么时候用 Gemini 3.1 Pro，什么时候不用

适合用的场景

长文档处理。1M 上下文窗口是默认可用的，不需要特殊申请。Claude 的 1M 是 Tier 4 beta，GPT-5.2 只有 400K。如果你要处理完整代码库、长篇合同、多小时会议记录，Gemini 3.1 Pro 是当前选择最少麻烦的。

视频分析。VideoMME 87.2% 是所有主流模型里最高的。支持最长 1 小时视频（无音频）或 45 分钟（有音频）。如果你在做视频内容理解、会议分析，这是最强选项。

成本敏感的通用任务。以 MEDIUM 档跑日常的代码审查、文档摘要、数据分析，成本比 Opus 4.6 低 50% 以上，能力上够用。

从 3.0 Pro 升级。同价升级，全面提升。除了 preview 状态可能有稳定性风险，没有不换的理由。

不太适合的场景

需要 SLA 保障的生产系统。Preview 状态意味着没有正式的可用性承诺。Google 可能在 GA 之前更新模型权重。

对输出质量有极高要求。GDPval-AA Elo 差了将近 300 分，说明专家在盲评时更偏好 Opus 4.6 的输出。如果你的用户是行业专家，对措辞和准确性非常敏感，Opus 4.6 可能更合适。

重度依赖工具调用。当前工具调用在多个框架上有兼容性问题。如果你的 Agent 架构高度依赖 function calling，建议等这波 bug 修完再切。

thinking_level 分档策略

和 Opus 4.6 的 effort 参数一样，关键是给不同任务配合适的档位。

策略一：按任务类型固定

最简单，适合明确知道自己业务场景的团队：

• 分类、路由、提取、翻译 → LOW
• 代码审查、摘要、一般分析 → MEDIUM
• 数学推理、复杂编码、安全审计 → HIGH

策略二：先低后高

先用 LOW 跑一遍。如果输出不符合预期（太短、置信度低、缺关键信息），自动升到 MEDIUM 或 HIGH 重跑。

from google import genai
from google.genai import types

client = genai.Client()

def smart_generate(prompt, contents):
    for level in ["LOW", "MEDIUM", "HIGH"]:
        response = client.models.generate_content(
            model="gemini-3.1-pro-preview",
            contents=contents,
            config=types.GenerateContentConfig(
                thinking_config=types.ThinkingConfig(
                    thinking_level=level
                )
            ),
        )
        if quality_check(response):
            return response
    return response

def quality_check(response):
    if response.usage_metadata.candidates_token_count < 100:
        return False
    # 你自己的质量判断逻辑
    return True

大部分请求在 LOW 就能解决的话，总成本会下降不少。

策略三：主 Agent HIGH，子 Agent LOW

如果你在搭多 Agent 系统，规划 Agent 用 HIGH，执行 Agent 用 LOW。逻辑和 Opus 4.6 的 effort 分级一样：决策层不能省，执行层可以省。

监控建议

上了 Gemini 3.1 Pro 之后建议盯两个指标：

按 thinking_level 分组统计每次请求的 thoughts_token_count。如果 LOW 档的推理 token 数突然偏高，说明有些请求对 LOW 来说太复杂了，模型在"挣扎"。

监控 stop_reason 为 max_tokens 的比例。HIGH 档容易产生大量 token，撞到 max_tokens 上限。如果这个比例超过 5%，要么调高上限，要么降低 thinking_level。

---

如果你之前在用 Gemini 3.0 Pro，换 3.1 Pro 只需要改一下 model ID。注意默认 thinking_level 是 HIGH，先改成 MEDIUM 试试，大概率够用，还能省不少钱。

如果你在 Opus 4.6 和 Gemini 3.1 Pro 之间犹豫，建议的做法是拿你实际的 prompt 跑一轮对比。跑分表上的数字和你的具体任务不一定对得上。Gemini 赢在价格和上下文窗口，Opus 赢在输出质量和工具调用稳定性，两边的优势领域不重叠。