調用 gemini-2.5-flash 時遇到 Thinking level is not supported for this model 錯誤,但切換到 gemini-3-flash-preview 就正常工作?這是 Google Gemini API 在模型代際升級中引入的參數設計變更。本文將系統解析 Gemini 2.5 和 3.0 在思考模式參數支持上的根本差異。
核心價值: 讀完本文,你將理解 Gemini 2.5 和 3.0 系列模型在思考模式參數設計上的本質差異,掌握正確的參數配置方法,避免因混用參數導致的 API 調用失敗。

Gemini 思考模式參數演進核心要點
| 模型系列 | 支持參數 | 參數類型 | 可用範圍 | 默認值 | 是否可禁用 |
|---|---|---|---|---|---|
| Gemini 2.5 Pro | thinking_budget |
整數 (128-32768) | 精確 token 預算 | 8192 | ❌ 不可禁用 |
| Gemini 2.5 Flash | thinking_budget |
整數 (0-24576) 或 -1 | 精確 token 預算或動態 | -1 (動態) | ✅ 可禁用 (設爲 0) |
| Gemini 2.5 Flash-Lite | thinking_budget |
整數 (512-24576) | 精確 token 預算 | 0 (禁用) | ✅ 默認禁用 |
| Gemini 3.0 Pro | thinking_level |
枚舉 ("low"/"high") | 語義化等級 | "high" | ❌ 不可完全禁用 |
| Gemini 3.0 Flash | thinking_level |
枚舉 ("minimal"/"low"/"medium"/"high") | 語義化等級 | "high" | ⚠️ 僅 "minimal" |
Gemini 2.5 vs 3.0 思考模式參數設計差異
核心差異: Gemini 2.5 系列使用 thinking_budget (token 預算制),而 Gemini 3.0 系列使用 thinking_level (語義化等級制)。這兩個參數完全不兼容,在錯誤的模型版本上使用會觸發 400 Bad Request 錯誤。
Google 在 Gemini 3.0 引入 thinking_level 的核心原因是簡化配置複雜度和提升推理效率。Gemini 2.5 的 token 預算制要求開發者精確估算思考 token 數量,而 Gemini 3.0 的等級制將這一複雜度抽象爲 4 個語義化等級,模型內部自動分配最優 token 預算,實現了 2 倍的推理速度提升。
💡 技術建議: 在實際開發中,我們建議通過 API易 apiyi.com 平臺進行模型切換測試。該平臺提供統一的 API 接口,支持 Gemini 2.5 和 3.0 全系列模型,方便快速驗證不同思考模式參數的兼容性和實際效果。
根本原因 1: Gemini 2.5 系列不支持 thinking_level 參數
API 參數設計的代際隔離
Gemini 2.5 系列模型(包括 Pro、Flash、Flash-Lite)在 API 設計中完全不識別 thinking_level 參數。當你在調用 gemini-2.5-flash 時傳遞 thinking_level 參數,API 會返回以下錯誤:
{
"error": {
"message": "Thinking level is not supported for this model.",
"type": "upstream_error",
"code": 400
}
}
錯誤觸發機制:
- Gemini 2.5 模型的 API 驗證層不包含
thinking_level參數定義 - 任何包含
thinking_level的請求會被直接拒絕,不會嘗試映射到thinking_budget - 這是硬編碼的參數隔離,不存在自動轉換或向後兼容
Gemini 2.5 系列的正確參數: thinking_budget
Gemini 2.5 Flash 參數規範:
# 正確配置示例
extra_body = {
"thinking_budget": -1 # 動態思考模式
}
# 或禁用思考
extra_body = {
"thinking_budget": 0 # 完全禁用
}
# 或精確控制
extra_body = {
"thinking_budget": 2048 # 精確 2048 token 預算
}
Gemini 2.5 Flash 的 thinking_budget 取值範圍:
| 取值 | 含義 | 推薦場景 |
|---|---|---|
0 |
完全禁用思考模式 | 簡單指令跟隨、高吞吐量應用 |
-1 |
動態思考模式 (最多 8192 tokens) | 通用場景,自動適配複雜度 |
512-24576 |
精確 token 預算 | 成本敏感型應用,需要精確控制 |

🎯 選擇建議: 在切換到 Gemini 2.5 Flash 時,建議先通過 API易 apiyi.com 平臺測試
thinking_budget參數的不同取值對響應質量和延遲的影響。該平臺支持快速切換參數配置,方便找到最適合業務場景的預算值。
根本原因 2: Gemini 3.0 系列不支持 thinking_budget 參數
參數設計的前向不兼容
雖然 Google 官方文檔聲稱 Gemini 3.0 爲了向後兼容仍然接受 thinking_budget 參數,但實際測試表明:
- 使用
thinking_budget會導致性能下降 - 官方文檔明確建議使用
thinking_level - 部分 API 實現可能完全拒絕
thinking_budget
Gemini 3.0 Flash 的正確參數: thinking_level
# 正確配置示例
extra_body = {
"thinking_level": "medium" # 中等強度推理
}
# 或最小思考 (接近禁用)
extra_body = {
"thinking_level": "minimal" # 最小思考模式
}
# 或高強度推理 (默認)
extra_body = {
"thinking_level": "high" # 深度推理
}
Gemini 3.0 Flash 的 thinking_level 等級說明:
| 等級 | 推理強度 | 延遲 | 成本 | 推薦場景 |
|---|---|---|---|---|
"minimal" |
幾乎無推理 | 最低 | 最低 | 簡單指令跟隨、高吞吐量 |
"low" |
淺層推理 | 低 | 低 | 聊天機器人、輕量級 QA |
"medium" |
中等推理 | 中等 | 中等 | 一般推理任務、代碼生成 |
"high" |
深度推理 | 高 | 高 | 複雜問題求解、深度分析 (默認) |
Gemini 3.0 Pro 的特殊限制
重要: Gemini 3.0 Pro 不支持完全禁用思考模式,即使設置 thinking_level: "low" 也會保留一定的推理能力。如果需要零思考響應以獲得最大速度,只能使用 Gemini 2.5 Flash 的 thinking_budget: 0。
# Gemini 3.0 Pro 可用等級 (僅 2 種)
extra_body = {
"thinking_level": "low" # 最低等級 (仍有推理)
}
# 或
extra_body = {
"thinking_level": "high" # 默認高強度推理
}
💰 成本優化: 對於預算敏感的項目,如果需要完全禁用思考模式以降低成本,建議通過 API易 apiyi.com 平臺調用 Gemini 2.5 Flash API。該平臺提供靈活的計費方式和更優惠的價格,適合需要精確成本控制的場景。
根本原因 3: 圖像模型和特殊變體的參數限制
Gemini 2.5 Flash Image 模型不支持思考模式
重要發現: gemini-2.5-flash-image 等視覺模型完全不支持任何思考模式參數,無論是 thinking_budget 還是 thinking_level。
錯誤示例:
# 調用 gemini-2.5-flash-image 時
response = client.chat.completions.create(
model="gemini-2.5-flash-image",
messages=[{"role": "user", "content": "分析這張圖片"}],
extra_body={
"thinking_budget": -1 # ❌ 錯誤: 圖像模型不支持
}
)
# 返回錯誤: "This model doesn't support thinking"
正確做法:
# 調用圖像模型時,不傳遞任何思考參數
response = client.chat.completions.create(
model="gemini-2.5-flash-image",
messages=[{"role": "user", "content": "分析這張圖片"}],
# ✅ 不傳遞 thinking_budget 或 thinking_level
)
Gemini 2.5 Flash-Lite 的特殊默認值
Gemini 2.5 Flash-Lite 與標準 Flash 版本的核心差異:
- 默認禁用思考模式 (
thinking_budget: 0) - 需要顯式設置
thinking_budget爲非零值才能啓用思考 - 支持的預算範圍: 512-24576 tokens
# Gemini 2.5 Flash-Lite 啓用思考模式
extra_body = {
"thinking_budget": 512 # 最小非零值,啓用輕量思考
}

| 模型 | thinking_budget | thinking_level | 圖像支持 | 思考默認狀態 |
|---|---|---|---|---|
| gemini-2.5-pro | ✅ 支持 (128-32768) | ❌ 不支持 | ❌ | 默認啓用 (8192) |
| gemini-2.5-flash | ✅ 支持 (0-24576, -1) | ❌ 不支持 | ❌ | 默認啓用 (動態) |
| gemini-2.5-flash-lite | ✅ 支持 (512-24576) | ❌ 不支持 | ❌ | 默認禁用 (0) |
| gemini-2.5-flash-image | ❌ 不支持 | ❌ 不支持 | ✅ | 無思考模式 |
| gemini-3.0-pro | ⚠️ 兼容但不推薦 | ✅ 推薦 (low/high) | ❌ | 默認 high |
| gemini-3.0-flash | ⚠️ 兼容但不推薦 | ✅ 推薦 (minimal/low/medium/high) | ❌ | 默認 high |
🚀 快速開始: 推薦使用 API易 apiyi.com 平臺快速測試不同模型的思考參數兼容性。該平臺提供開箱即用的 Gemini 全系列模型接口,無需複雜配置,5 分鐘即可完成集成和參數驗證。
解決方案 1: 基於模型版本的參數適配函數
智能參數選擇器 (支持全系列模型)
def get_gemini_thinking_config(model_name: str, intensity: str = "medium") -> dict:
"""
根據 Gemini 模型名稱自動選擇正確的思考模式參數
Args:
model_name: Gemini 模型名稱
intensity: 思考強度 ("none", "minimal", "low", "medium", "high", "dynamic")
Returns:
適用於 extra_body 的參數字典,如果模型不支持思考則返回空字典
"""
# Gemini 3.0 模型列表
gemini_3_models = [
"gemini-3.0-flash-preview", "gemini-3.0-pro-preview",
"gemini-3-flash", "gemini-3-pro"
]
# Gemini 2.5 標準模型列表
gemini_2_5_models = [
"gemini-2.5-flash", "gemini-2.5-pro",
"gemini-2.5-flash-lite", "gemini-2-flash", "gemini-2-pro"
]
# 圖像模型列表 (不支持思考)
image_models = [
"gemini-2.5-flash-image", "gemini-flash-image",
"gemini-pro-vision"
]
# 檢查是否爲圖像模型
if any(img_model in model_name for img_model in image_models):
print(f"⚠️ 警告: {model_name} 不支持思考模式參數,返回空配置")
return {}
# Gemini 3.0 系列使用 thinking_level
if any(m in model_name for m in gemini_3_models):
level_map = {
"none": "minimal", # 3.0 無法完全禁用,使用 minimal
"minimal": "minimal",
"low": "low",
"medium": "medium",
"high": "high",
"dynamic": "high"
}
# Gemini 3.0 Pro 只支持 low 和 high
if "pro" in model_name.lower():
if intensity in ["none", "minimal", "low"]:
return {"thinking_level": "low"}
else:
return {"thinking_level": "high"}
# Gemini 3.0 Flash 支持全部 4 個等級
return {"thinking_level": level_map.get(intensity, "medium")}
# Gemini 2.5 系列使用 thinking_budget
elif any(m in model_name for m in gemini_2_5_models):
budget_map = {
"none": 0, # 完全禁用
"minimal": 512, # 最小預算
"low": 2048, # 低強度
"medium": 8192, # 中等強度
"high": 16384, # 高強度
"dynamic": -1 # 動態適配
}
budget = budget_map.get(intensity, -1)
# Gemini 2.5 Pro 不支持禁用 (最小 128)
if "pro" in model_name.lower() and budget == 0:
print(f"⚠️ 警告: {model_name} 不支持禁用思考,自動調整爲最小值 128")
budget = 128
# Gemini 2.5 Flash-Lite 最小值爲 512
if "lite" in model_name.lower() and budget > 0 and budget < 512:
print(f"⚠️ 警告: {model_name} 最小預算爲 512,自動調整")
budget = 512
return {"thinking_budget": budget}
else:
print(f"⚠️ 警告: 未知模型 {model_name},默認使用 Gemini 3.0 參數")
return {"thinking_level": "medium"}
# 使用示例
import openai
client = openai.OpenAI(
api_key="YOUR_API_KEY",
base_url="https://api.apiyi.com/v1"
)
# 測試 Gemini 2.5 Flash
model_2_5 = "gemini-2.5-flash"
config_2_5 = get_gemini_thinking_config(model_2_5, intensity="dynamic")
print(f"{model_2_5} 配置: {config_2_5}")
# 輸出: gemini-2.5-flash 配置: {'thinking_budget': -1}
response_2_5 = client.chat.completions.create(
model=model_2_5,
messages=[{"role": "user", "content": "解釋量子糾纏"}],
extra_body=config_2_5
)
# 測試 Gemini 3.0 Flash
model_3_0 = "gemini-3.0-flash-preview"
config_3_0 = get_gemini_thinking_config(model_3_0, intensity="medium")
print(f"{model_3_0} 配置: {config_3_0}")
# 輸出: gemini-3.0-flash-preview 配置: {'thinking_level': 'medium'}
response_3_0 = client.chat.completions.create(
model=model_3_0,
messages=[{"role": "user", "content": "解釋量子糾纏"}],
extra_body=config_3_0
)
# 測試圖像模型
model_image = "gemini-2.5-flash-image"
config_image = get_gemini_thinking_config(model_image, intensity="high")
print(f"{model_image} 配置: {config_image}")
# 輸出: ⚠️ 警告: gemini-2.5-flash-image 不支持思考模式參數,返回空配置
# 輸出: gemini-2.5-flash-image 配置: {}
💡 最佳實踐: 在需要動態切換 Gemini 模型的場景,建議通過 API易 apiyi.com 平臺進行參數適配測試。該平臺支持完整的 Gemini 2.5 和 3.0 系列模型,方便驗證不同參數配置下的響應質量和成本差異。
解決方案 2: Gemini 2.5 到 3.0 的遷移策略
思考模式參數遷移對照表
| Gemini 2.5 Flash 配置 | Gemini 3.0 Flash 等效配置 | 延遲對比 | 成本對比 |
|---|---|---|---|
thinking_budget: 0 |
thinking_level: "minimal" |
3.0 更快 (約 2x) | 相似 |
thinking_budget: 512 |
thinking_level: "low" |
3.0 更快 | 相似 |
thinking_budget: 2048 |
thinking_level: "low" |
3.0 更快 | 相似 |
thinking_budget: 8192 |
thinking_level: "medium" |
3.0 更快 | 略高 |
thinking_budget: 16384 |
thinking_level: "high" |
3.0 更快 | 略高 |
thinking_budget: -1 (動態) |
thinking_level: "high" (默認) |
3.0 顯著更快 | 3.0 更高 |
遷移代碼示例
def migrate_to_gemini_3(old_model: str, old_config: dict) -> tuple[str, dict]:
"""
從 Gemini 2.5 遷移到 Gemini 3.0
Args:
old_model: Gemini 2.5 模型名稱
old_config: Gemini 2.5 的 extra_body 配置
Returns:
(新模型名稱, 新配置字典)
"""
# 模型名稱映射
model_map = {
"gemini-2.5-flash": "gemini-3.0-flash-preview",
"gemini-2.5-pro": "gemini-3.0-pro-preview",
"gemini-2-flash": "gemini-3-flash",
"gemini-2-pro": "gemini-3-pro"
}
new_model = model_map.get(old_model, "gemini-3.0-flash-preview")
# 參數轉換
if "thinking_budget" in old_config:
budget = old_config["thinking_budget"]
# 轉換爲 thinking_level
if budget == 0:
new_level = "minimal"
elif budget <= 2048:
new_level = "low"
elif budget <= 8192:
new_level = "medium"
else:
new_level = "high"
# Gemini 3.0 Pro 只支持 low/high
if "pro" in new_model and new_level in ["minimal", "medium"]:
new_level = "low" if new_level == "minimal" else "high"
new_config = {"thinking_level": new_level}
else:
# 默認配置
new_config = {"thinking_level": "medium"}
return new_model, new_config
# 遷移示例
old_model = "gemini-2.5-flash"
old_config = {"thinking_budget": -1}
new_model, new_config = migrate_to_gemini_3(old_model, old_config)
print(f"遷移前: {old_model} {old_config}")
print(f"遷移後: {new_model} {new_config}")
# 輸出:
# 遷移前: gemini-2.5-flash {'thinking_budget': -1}
# 遷移後: gemini-3.0-flash-preview {'thinking_level': 'high'}
# 使用新配置調用
response = client.chat.completions.create(
model=new_model,
messages=[{"role": "user", "content": "你的問題"}],
extra_body=new_config
)
🎯 遷移建議: 在從 Gemini 2.5 遷移到 3.0 時,建議先通過 API易 apiyi.com 平臺進行 A/B 測試。該平臺支持快速切換模型版本,方便對比遷移前後的響應質量、延遲和成本差異,確保平滑遷移。
常見問題
Q1: 爲什麼我的代碼在 Gemini 3.0 上正常,切換到 2.5 就報錯?
原因: 你的代碼中使用了 thinking_level 參數,這是 Gemini 3.0 專有參數,2.5 系列完全不支持。
解決方案:
# 錯誤代碼 (僅適用於 3.0)
extra_body = {
"thinking_level": "medium" # ❌ 2.5 不識別
}
# 正確代碼 (適用於 2.5)
extra_body = {
"thinking_budget": 8192 # ✅ 2.5 使用 budget
}
推薦使用上文的 get_gemini_thinking_config() 函數自動適配,或通過 API易 apiyi.com 平臺快速驗證參數兼容性。
Q2: Gemini 2.5 Flash 和 Gemini 3.0 Flash 的性能差異有多大?
根據 Google 官方數據和社區測試:
| 指標 | Gemini 2.5 Flash | Gemini 3.0 Flash | 提升幅度 |
|---|---|---|---|
| 推理速度 | 基準 | 2x 更快 | +100% |
| 延遲 | 基準 | 顯著降低 | 約 -50% |
| 思考效率 | 固定預算或動態 | 自動優化 | 質量提升 |
| 成本 | 基準 | 略高 (高質量) | +10-20% |
核心差異: Gemini 3.0 採用動態思考分配,只在必要時思考必要的長度,而 2.5 的固定預算可能導致過度思考或思考不足。
建議通過 API易 apiyi.com 平臺進行實際測試,該平臺提供實時性能監控和成本分析,方便對比不同模型的實際表現。
Q3: 如何在 Gemini 3.0 中完全禁用思考模式?
重要: Gemini 3.0 Pro 無法完全禁用思考模式,即使設置 thinking_level: "low" 也會保留輕量推理能力。
可用選項:
- Gemini 3.0 Flash: 使用
thinking_level: "minimal",接近零思考 (但複雜編碼任務可能仍會輕度思考) - Gemini 3.0 Pro: 最低只能設置
thinking_level: "low"
如果需要完全禁用:
# 只有 Gemini 2.5 Flash 支持完全禁用
model = "gemini-2.5-flash"
extra_body = {
"thinking_budget": 0 # 完全禁用思考
}
對於需要極致速度且不需要推理能力的場景(如簡單指令跟隨),推薦通過 API易 apiyi.com 調用 Gemini 2.5 Flash 並設置
thinking_budget: 0。
Q4: Gemini 圖像模型支持思考模式嗎?
不支持。 所有 Gemini 圖像處理模型(如 gemini-2.5-flash-image、gemini-pro-vision)都不支持思考模式參數。
錯誤示例:
# ❌ 圖像模型不支持任何思考參數
response = client.chat.completions.create(
model="gemini-2.5-flash-image",
messages=[...],
extra_body={
"thinking_budget": -1 # 觸發錯誤
}
)
正確做法:
# ✅ 調用圖像模型時不傳遞思考參數
response = client.chat.completions.create(
model="gemini-2.5-flash-image",
messages=[...],
# 不傳遞 extra_body 或傳遞其他非思考參數
)
技術原因: 圖像模型的推理架構專注於視覺理解,不包含語言模型的思考鏈機制。
總結
Gemini 2.5 Flash 報錯 thinking_level not supported 的核心要點:
- 參數隔離: Gemini 2.5 僅支持
thinking_budget,3.0 僅支持thinking_level,兩者完全不兼容 - 模型識別: 通過模型名稱判斷版本,2.5 系列用
thinking_budget,3.0 系列用thinking_level - 圖像模型限制: 所有圖像模型 (如
gemini-2.5-flash-image) 不支持任何思考模式參數 - 禁用差異: 只有 Gemini 2.5 Flash 支持完全禁用思考 (
thinking_budget: 0),3.0 系列最多隻能minimal - 遷移策略: 從 2.5 遷移到 3.0 時,需要將
thinking_budget映射爲thinking_level,並考慮性能和成本變化
推薦通過 API易 apiyi.com 快速驗證不同模型的思考參數兼容性和實際效果。該平臺支持 Gemini 全系列模型,提供統一接口和靈活計費方式,適合快速對比測試和生產環境部署。
作者: APIYI 技術團隊 | 如有技術問題,歡迎訪問 API易 apiyi.com 獲取更多 AI 模型接入方案。
