Firebase AI Logic 新增 Gemini 3.1 支援

Firebase AI Logic 已加入 Gemini 3.1 模型支援，並替 Gemini 2.0 與 Imagen 設下退場日期。

Firebase 這次更新很直接。你如果還在用舊模型，現在就該看遷移清單。Gemini 2.0 Flash 和 Flash-Lite 會在 2026 年 6 月 1 日停用，Imagen 系列則在 2026 年 6 月 24 日結束。

說白了，這不是單純加新功能。這是在逼開發者整理依賴。對做 App、後端服務，或 AI 功能實驗的人來說，模型名稱現在已經像套件版本一樣重要。

Firebase 這次到底在講什麼

講白了，Firebase AI Logic 的模型清單往前推了一代。新的重點是 Gemini 3.1，包含 Gemini 3.1 Pro、Flash、Flash-Lite。對開發者來說，這代表官方支援重心已經往新家族移動。

這件事很重要，因為很多團隊是直接透過 Firebase AI Logic 在前端或行動端呼叫 Gemini API。少了一層自己維護的伺服器整合，開發快很多，但也更容易把模型名稱寫死在程式裡。

Firebase 也把命名規則寫得很清楚。Gemini 2.5 之後的穩定模型名稱，不會用三位數後綴。也沒有那種會自動跟著升級的別名。這種設計看起來小事，實際上很容易踩雷。

• Gemini 3.1 Pro：適合複雜推理
• Gemini 3.1 Flash：適合速度與成本平衡
• Gemini 3.1 Flash-Lite：適合大量請求
• Gemini 2.5 系列：目前仍列在可用清單

模型命名不是小事

很多團隊遷移出問題，不是模型不行，是字串寫錯。你只要把模型名稱硬編進程式，後面一改版就可能出事。這種 bug 很煩，因為前一天還能跑，隔幾週就開始吐錯。

Firebase 這次特別提醒命名規則，代表官方真的怕大家亂接。尤其是用 remote config、feature flag，或在客戶端切模型的人，更容易中招。你今天選的是 Flash，明天可能還是 Flash，但背後行為已經不一樣。

對產品團隊來說，這種變化也會影響測試策略。你不能只看「有沒有回應」，還要看延遲、成本、輸出格式、工具呼叫穩定性。模型一換，整個體驗都可能變。

“The current generation of Gemini models is the most capable and useful family we’ve ever built.” — Demis Hassabis，Google DeepMind，Google I/O 2025 主題演講

這句話很符合 Firebase 現在的路線。Google 不是把舊模型留著慢慢用，而是把資源往新家族集中。這種做法很合理，因為模型線太散，開發者會更難選。

但對工程師來說，合理不代表省事。你還是得做遷移。尤其是商用 App，模型一停用，使用者看到的就是錯誤畫面，不會管你內部有多忙。

新舊模型怎麼比

從 Firebase 的文件看起來，3.1 系列是新主力。Pro 偏向深度推理，Flash 偏向速度，Flash-Lite 則偏向成本控制。這種分層很像雲端服務常見的計價策略，讓你按需求挑，不用一把梭。

比較有意思的是 Gemini 3.5 Flash 也在清單裡。它被放在「快、成本壓力較低」的位置。對大量聊天、摘要、分類、抽取資料這類工作，這種模型通常最實用。

圖像生成這邊更明確。Firebase 已經把重心移到 Gemini 圖像模型，像是 Gemini 3 Pro Image、Gemini 3.1 Flash Image、Gemini 2.5 Flash Image。舊的 Imagen 系列則進入退場流程。

• Gemini 3 Pro Image：偏專業素材產出
• Gemini 3.1 Flash Image：偏速度與大量生成
• Gemini 2.5 Flash Image：偏效率與成本控制
• Imagen：已淘汰，需盡快改接

如果你是做設計輔助、行銷素材，或電商圖像產生，這個變動就很實際。你不能等到 2026 年 6 月才看。圖像管線通常最難改，因為它常常牽涉前端預覽、後端排程、儲存空間與審核流程。

數字拉出來看更清楚

這次更新最值得記住的，不是新名字，而是時間表。Firebase 已經把兩個停用日寫死。這表示你可以直接把遷移排進專案計畫，不用猜。

如果你手上有多個產品線，最好先盤點哪些功能真的碰到模型 API。很多公司以為自己只用了「一點點 AI」，結果一查才發現客服、搜尋、摘要、圖片處理全都接上了。

以下這幾個數字，應該直接寫進內部任務單：

• 2026 年 6 月 1 日：Gemini 2.0 Flash / Flash-Lite 停用
• 2026 年 6 月 24 日：Imagen 系列停用
• 3.1：Firebase 新增支援的模型代號
• 2.5：目前仍保留的穩定家族之一

你也可以把它想成版本管理。模型不是永遠免費待命的雲端資源。它比較像外部依賴。只要供應商改規則，你就得跟著修。

這也是為什麼我一直覺得，AI 開發跟一般軟體開發最大的差別，不在語法，而在依賴管理。模型、Token、價格、延遲，全部都會變。你不記錄，就會忘。

開發者現在該做什麼

第一步很單純。去掃程式碼裡的模型字串。前端、後端、測試環境、腳本檔，全都要看。不要只查主線程式，很多舊功能藏在角落。

第二步是做對照表。把目前用的模型，對應到 Firebase 文件裡的新選項。像是 Gemini 2.0 Flash，先找能替代它的 3.1 或 2.5 方案。圖像功能則直接規劃從 Imagen 移出。

第三步是重測。不要只測成功回應。要測延遲、品質、錯誤率、費用。AI 服務最常見的坑，就是功能看起來沒壞，帳單卻先壞了。

• 盤點所有 Firebase AI Logic 呼叫點
• 把舊模型對應到新模型
• 先處理 2026 年 6 月 1 日前會停的項目
• 再處理 2026 年 6 月 24 日前會停的圖像流程

如果你的產品有 AB test，這時候就很好用。你可以先把一小部分流量切到新模型，觀察結果。這樣比一次全切安全多了。

這波變動放在產業脈絡裡看

Firebase AI Logic 的角色，其實很像「把 AI 接進 App 的捷徑」。對很多前端團隊來說，它比自己拉一套伺服器、串權杖、處理授權簡單太多。這也是它受歡迎的原因。

但捷徑的代價，就是你更依賴平台節奏。Google 這次把模型更新、停用時間、遷移方向都寫得很清楚。這種透明度對工程師有幫助，但也提醒大家：平台不是你的長期保證。

從更大的角度看，這類更新會逼團隊建立模型治理流程。你得知道每個功能用了哪個模型，何時到期，誰負責換。沒有這套流程，AI 功能越多，後面越亂。

我覺得這才是重點。不是 Gemini 3.1 多強，而是你的系統有沒有能力跟上。真正成熟的團隊，不會只問哪個模型最好，而是問哪個模型最適合、最穩、最容易維護。

現在就該開始排遷移

如果你已經在 Firebase AI Logic 上跑 AI 功能，建議這週就動手盤點。先找出所有 Gemini 2.0 和 Imagen 的使用點，再看能不能直接換到 3.1 或 2.5 家族。

別等到停用日期逼近才處理。那時候通常不是技術問題，而是排程問題、測試問題、上線窗口問題一起爆。這種事我看太多了，最後都變成大家週末加班。

我的建議很簡單：把模型當成正式依賴管理。寫進文件，寫進監控，寫進 release checklist。這樣你才不會被下一次模型調整打個措手不及。