為什麼 Gemini API 定價其實比看起來更便宜

Gemini 的標價不算高，但真正的成本在整合、快取、模型選擇與上下文管理。

我認為 Gemini API 不是「貴」，而是「看起來簡單、實際上要會算」。它的 token 單價本來就有競爭力，但真正決定總成本的，往往是你選哪個模型、送多少上下文、是否啟用快取，以及是不是把非即時工作丟進 Batch。換句話說，Gemini 的便宜不是寫在首頁，而是藏在架構選擇裡。

第一個論點：標價只是門票，不是總帳單

以 Gemini 3.1 Pro 來看，200K 以下上下文的價格是每百萬 input token 2 美元、output token 12 美元，超過 200K 後則變成 4 美元與 18 美元。這個價目表看似直白，但產品團隊買的從來不是 token，而是答案；而答案的成本，取決於你是否把整份長上下文反覆塞回去。只要架構不對，低單價也會被高用量吃掉。

更重要的是，Gemini 不是只有一個價格點。Gemini 3.1 Flash-Lite 只要每百萬 input token 0.25 美元、output token 1.50 美元，Gemini 3 Flash 也只有 0.50 與 3.00 美元。這代表你不是被迫用旗艦模型硬扛所有任務，而是可以依照工作難度分流。對分類、路由、摘要這類任務來說，選錯模型才是真正的浪費。

第二個論點：上下文管理才是預算殺手

Gemini 3.1 Pro 的 2 百萬 token context window 很吸睛，但真正會讓財務部皺眉的是 200K 以上的價格跳檔。這意味著同一個產品，只因為你在每輪請求都重送一大包歷史內容，成本就可能從可控變成失控。對支援助理、研究工具或 coding assistant 來說，架構決定了你是在買「推理」，還是在買「重複傳輸」。

Google 提供的 context caching 正是答案。Gemini 3.1 Pro 的 repeated-context 成本可降到每百萬 token 0.20 或 0.40 美元，對大量重複提示的應用，官方資料甚至指出最高可省下 90%。這不是微調級的優化，而是商業模式級的差異：有快取的系統能活，沒有快取的系統看起來便宜，實際上會在流量上來時爆掉。

反方可能怎麼說

最強的反對意見是：Gemini 的定價太複雜，複雜本身就是成本。除了 token，還有 grounding with Google Search、音訊、圖片、影片、音樂生成等額外收費，而且 Vertex AI 與直接 API 的價格也不完全一樣。對很多團隊來說，光是理解帳單就要花時間，更別說避免誤用。

這個批評成立，而且應該被正視。若團隊沒有成本意識，Gemini 的多層價格確實會讓人誤判。但這不推翻「更便宜」的結論，反而說明便宜的前提是會設計：知道何時用 Flash-Lite、何時用 Pro、何時啟用快取、何時改走 Batch。複雜不是高價，複雜是要求你有工程紀律。

你能做什麼

如果你是工程師，先把成本寫進架構：簡單請求走 Flash-Lite，難題才升到 Pro；重複上下文一定做 caching；非即時工作一律丟 Batch。若你是 PM 或創辦人，不要問「Gemini 貴不貴」，要問「每個成功用戶動作的成本是多少」。算不出這個數字，就代表你還沒有定價策略，只有感覺。