Gemini 3.6 Flash：把成本拉動 30 倍的思考旋鈕（實測）

Gemini 3.6 Flash 除了對答案計費，還會另外對思考 token 計費，而它花多少思考 token 是你可以在每個請求裡調的旋鈕。同一個 120 字的寫作任務，預設設定計費 $0.03316，minimal 設定計費 $0.00110，相差 30 倍，而讀者根本分不出兩者的輸出有什麼不同。這個旋鈕是這個模型上最重要的成本決策，但它帶著一個鋒利的邊角。Gemini 3.6 Flash 於 2026-07-21 正式上線，輸入每百萬 token $1.50、輸出每百萬 token $7.50，比 3.5 Flash 的輸出 $9 降了下來。它與 Gemini 3.5 Flash-Lite 以及一個為安全調校的 3.5 Flash Cyber 一同推出；本文實測的是兩個通用等級：3.6 Flash 和 Flash-Lite。

TL;DR

• reasoning_effort: "minimal" 相較預設把單次呼叫成本砍掉 91–97%（在 120 字任務上相差 30 倍），在單步、結構化輸出和 tool-calling 工作上不用付代價，但多步數學會從 3/3 崩到 0/3。
• Google 說的「輸出 token 少 17%」要看工作負載：我們那些偏重推理的任務少了 19%（便宜 32%），我們的 agent 測試組則多了 9%（便宜 6%）。
• 1M context 是真的（在 972K token 處放的針有被找回來），prompt caching 也精準符合 Google 公布的 4,096-token 下限，是一次乾淨的規格對得上，不像某些「1M context」模型實際達不到自己宣稱的數字。

以下所有數據都在 2026-07-24 透過 Synthorai 閘道實測，重複的 prompt 都加了鹽以避開快取；每個數字背後都有原始的用量記錄佐證。

Gemini 3.6 Flash 在預設設定下每個任務要花多少？

推理主導了輸出帳單，而且不管你看不看得到都要付錢。在預設 effort 下，模型花在思考的 token 遠多於花在回答的，而這些推理 token 是以完整的 $7.50/M 輸出費率計費：

要記住的規律是這樣：一個兩個 token 的事實型答案，背後仍帶了 69 個推理 token；而 120 字段落花在思考的 token 是花在寫作的 30 倍。推理 token 列在 completion_tokens_details.reasoning_tokens 裡，所以你看得到數量，但永遠看不到內容。Gemini 完全不回傳任何思考摘要或軌跡，是我們在 token 用量剖析 研究中畫出的光譜裡最封閉的一端；相較之下，Kimi K3 會回傳完整的思考鏈，GPT-5.6 則回傳摘要。下一節就來談怎麼把這筆花費調下來。

thinking 旋鈕實際上在做什麼？

它是一個真正的、單調變化的成本槓桿，而且在大多數任務類型上幾乎是白賺的。把 reasoning_effort（或原生的 thinking_config.thinking_level）設成 minimal，會讓 reasoning token 歸零，每個任務的成本降低 91–97%：

這個旋鈕是真的有效，可接受的值有 minimal、low、medium（預設）和 high；在我們的測試裡，每往上一階都單調地買到更多 reasoning（minimal 0 個 token、low 約 180、medium 約 530、high 約 650）。minimal 唯一做不到的就是思考，而多步驟算術正需要思考：強迫模型用最精簡的方式回答那道鉛筆與袋子的文字題，三次全錯，而且答案各不相同，不是同一種系統性錯誤。至於檢索、分類、格式化和單步驟問題，minimal 準確度不變，帳單卻降了一個數量級。

實務上的準則跟我們在 Kimi K3 上發現的一致：對於擷取、查找和格式化，minimal 是站得住腳的預設值，但對任何需要中間步驟的任務就是個坑。要按 route 設定，不要全域設定，而且在把它用到偏重推理的任務上之前，先用你自己的任務驗證準確度。

兩種高流量的生產型態能把這件事講清楚：結構化輸出和 function calling 在預設值下都會花掉 reasoning token，而兩者跑 minimal 都很安全。一個受 schema 約束的擷取任務（帶 JSON schema 的 response_format）在預設值下計費 337 個 reasoning token，回傳了合法的 JSON；換成 minimal 後 reasoning 計費為零，一樣回傳符合 schema 的合法 JSON，成本低了 9 倍。function call 的表現一樣：預設值下用了 74 個 reasoning token 並產生正確的 get_weather(city) 呼叫，而 minimal 下 reasoning 為零、同樣產生正確呼叫，便宜了 4 倍。這些都是披著「結構化」外衣的單步驟任務，模型不需要靠思考才能填進一個它早就被告知要填的欄位。所以如果你的流量是擷取或工具路由，minimal 幾乎就是白賺的。

「輸出 token 少 17%」這個說法站得住腳嗎？

要看 workload，而且拆開來看很有意思。Google 在發布時把 3.6 Flash 定位成：在 Artificial Analysis Index 上輸出 token 比 3.5 Flash 少約 17%（在個別 agentic 評測上最高可達 65%）。我們拿兩個自己的測試環境跑了這兩個模型，結果符號正好相反：

在重推理的短任務上，這個說法不只重現，還超過了官方數字：總輸出下降 19%，接近 Google 的 17%，而且降幅幾乎全部來自 thinking，不是答案本身。我們把兩個模型配對重跑一次並拆分輸出 token，可見的答案只縮了 4%，reasoning 卻降了 19%，主要集中在數學和寫作任務——3.6 用更少的思考就得出相同結果。這就是 benchmark 背後的機制：在依賴 thinking budget 的工作上，3.6 在相同答案下確實更有效率。

在 agentic 的多輪流量上，符號反過來了：整個套件中 3.6 的輸出比 3.5 多約 9%。效率增益發生在 reasoning 階段，而 agent loop 在這階段花的預算比例較低，所以可省的空間有限，3.6 稍長的每輪輸出反而占了上風。無論哪種情況帳單都會下降，因為兩種效應疊加的方式不同：重推理任務同時省下 token 和 $9→$7.50 的費率調降（−32%），agent 流量則只靠價格省（−6%）。老實說，「輸出 token 少 17%」在 thinking 主導輸出時是真的，在不主導時則會反轉，所以要量測你自己的流量組合，別直接套用官方數字，另外要記得，上一節提到的那個旋鈕對結果的影響遠比版本升級來得大。

1M context window 是真的嗎？

是真的，而且它出錯時會明確報錯，不會悄悄失敗。我們把一根 recall needle 放在逐漸加大的 prompt 前段：在 972K input token 時仍能正確 recall，而超過上限的 prompt 會回傳乾淨的 400 input token count exceeds the maximum，不會默默丟掉內容。這值得一提，因為市面上並不是每個號稱「1M-context」的模型都真的能服務它宣傳的視窗。給想重現這個測試的人一個提醒：用多樣、句子形態的填充內容來 pad，因為用單一 token 重複堆出來的 prompt，會讓模型在遠未達到大小上限前就退化成亂碼。

Prompt caching 是自動的，而且在關鍵數字上符合規格。Google 記載 Flash 模型的 context caching 最小值是 4,096 個 token，我們的掃描結果正好落在這裡：前綴在 ~2.1K 或以下時從不 cache，命中從約 4.1K token 開始，每次命中會留下最後大約 2.1K 未 cache，且需要 5 到 8 次呼叫暖機。Cached input 讀取價為 $0.15/M，相對 $1.50 的原始費率有 10 倍折扣。這值得直說，因為它是令人放心的情況：我們量測過一些模型，其宣傳數字誇大了 endpoint 實際交付的能力，而 Gemini 3.6 Flash 的 cache 門檻和 1M 視窗都做到了文件所說的內容。Caching 仍然只有在真正又長又穩定的前綴上才划算，另外要注意 Flash 系列只支援自動（隱式）caching，不支援顯式的 cached-content API，所以你無法手動釘住一份大文件、在門檻以下重複使用。

Gemini 3.5 Flash-Lite 適合放在哪裡？

Flash-Lite 是成本可預測的層級。它不會偷偷花掉 reasoning token，帳單和可見的輸出一一對應。同一道多步驟數學題，Flash-Lite 只收 $0.00057，3.6 Flash 的預設模式則要 $0.00368，大約便宜 6 倍，而且它是把推導過程攤在明處算出答案，而不是藏在隱藏的 reasoning 欄位裡。輸入 $0.30/M、輸出 $2.50/M，對於高流量、對延遲敏感的單步驟任務，這是合理的預設選擇；當任務需要 dial 能補回來的推理能力時，再升級到 3.6 Flash。tokenizer 不只在這三個新模型之間沒有改動，一路回推到 Gemini 2.5 Flash 也一樣：我們檢查過的每一代，英文、中文、日文、韓文和 Python 的 token 數量都完全相同，所以為 2.5 建立的各語言預算可以直接沿用到 3.6，不必重新校準基準。

FAQ

Gemini 3.6 Flash 可以完全關掉推理嗎？

reasoning_effort: "minimal"（或 thinking_level: "minimal"）在我們的測試中把 reasoning token 壓到零，也是 dial 的最低檔；可接受的檔位是 minimal、low、medium、high。沒有另外的「停用」狀態，硬要關掉推理的嘗試會在上游被拒絕，所以 minimal 就是最低了，而對單步驟任務來說已經夠低。

為什麼我的 Gemini 帳單比可見的答案看起來還高？

因為 reasoning token 是照完整輸出費率計費，而且不在你拿到的文字裡。一個兩 token 的答案，可能帶著幾十到幾千個計費的 reasoning token；看 completion_tokens_details.reasoning_tokens（或用 total_tokens − prompt − completion 對帳）就能看到真正的輸出費用，能調低的地方就把 dial 調低。

Gemini 3.6 Flash 還是 Claude Haiku 4.5？

兩者佔據同一個快速層級，價格接近，差別在工作負載，而不是誰全面勝出。從我們的成本角度看，3.6 Flash 的 thinking dial 是關鍵差異：minimal 讓它在單步驟流量上便宜一個數量級，而它的預設模式會花掉 Haiku 4.5（$1/$5）不會花的推理。已公布的 benchmark 上，Haiku 4.5 在程式碼深度佔優，3.6 Flash 則在數學和純 token 價格領先；按你流量的組成來選，正式採用前先在自己的任務上把兩者都量過一遍。

Gemini 3.6 Flash 比 3.5 Flash 便宜嗎？

在我們量測的每一種工作負載裡都便宜，差多少要看任務型態。輸出從 $9/M 降到 $7.50/M，而在推理量大的短任務上，3.6 也花更少的輸出 token，成本因此降了約 32%；在 agent 流量上它花的 token 略多，省下的部分只來自費率調降，約 6%。無論哪種情況都更便宜；先遷移，再用自己的流量組合重新量測。想了解各系列每個 token 的成本拆解，可以看我們的 token 用量剖析研究。

量測於 2026-07-24，透過 Synthorai 閘道對 gemini-3.6-flash、gemini-3.5-flash 和 gemini-3.5-flash-lite 進行；task-matrix 與 agent-suite 的 token 數來自每次呼叫的用量記錄，effort-dial 結果來自加鹽的五任務消融實驗（每格 n=3），context 與 cache 探測來自 needle-recall 與 prefix sweep。準確率統計只採用有單一可核對答案的任務。價格與行為可能變動，請對照你自己的用量記錄驗證。

← 返回部落格