Nano Banana 2.1：Gemini 圖像模型、其家族，以及費用

Nano Banana 2.1是供應商以 API 識別碼gemini-nano-banana-2.1所提供的影像生成與對話式編輯模型。供應商自家的文件賦予它 Gemini Nano Banana 2.1 這個產品名稱，並稱之為Nano Banana 2的更新版，後者的識別碼為gemini-3.1-flash-image。同一家族中還有另外兩個模型與它並列：Nano Banana 2 Lite（gemini-3.1-flash-lite-image）位階在它之下，而 Nano Banana Pro（gemini-3-pro-image）則位階在它之上。這就是這東西的輪廓——一個三層級的影像家族，再加上一個仍留在文件中的較舊成員——而圍繞這個名稱的多數混淆，都源自產品名稱與端點字串從未被設計成彼此相符。本頁是這個模型本身的參考資料：它是什麼、由誰發布、你可以輸入什麼並取回什麼、供應商聲稱什麼，以及你今天如何取用它。以下每一項數據皆引自供應商自家的模型卡、影像生成指南、定價頁面與變更記錄，以其在 2026 年 10 月 13 日的狀態為準，且每一項都標註為供應商自述；唯一使用的獨立來源會在出現之處具名。

它是什麼，以及為什麼識別碼才是關鍵的部分

供應商的模型目錄列出 gemini-nano-banana-2.1，狀態為「New Stable」，描述為「高效能的影像生成與編輯模型，具備更佳的視覺品質、文字排版與多輪對話一致性。」影像生成指南對它的定位更為直白：它是「Nano Banana 2 的更新版本，作為影像生成與對話式編輯的主要高效能主力模型。」

命名是讀者遇到的第一個實際問題，因此值得直截了當地說清楚。在這個系列中，產品名稱無法從識別碼推導出來：

• Nano Banana 2.1 — 產品名稱「Gemini Nano Banana 2.1」、API 識別碼 gemini-nano-banana-2.1，目前的高效率主力。

• Nano Banana 2 — API 識別碼 gemini-3.1-flash-image。識別碼中完全沒有版本編號，這就是為什麼「Nano Banana 2」與「gemini-3.1-flash-image」是同一個模型。

• Nano Banana 2 Lite — API 識別碼 gemini-3.1-flash-lite-image。Google 的指南稱其為該系列中的效率專家，專為超低延遲與高流量互動使用而打造。

• Nano Banana Pro — API 識別碼 gemini-3-pro-image，被描述為具備推理核心的專業設計引擎，主打複雜版面與精準的文字渲染。

如果你正在串接什麼東西，可靠的依據是識別碼，而不是行銷名稱。這不是什麼風格問題：Google 的變更日誌把gemini-3.1-flash-image移至已棄用狀態，而且就在它發布gemini-nano-banana-2.1的同一天；那筆棄用紀錄靠的是識別碼，而不是行銷名稱。

誰出版它？

Google 有，而且是以託管 API 模型的形式發布，而非可下載的模型——沒有可供取得的檢查點，也沒有授權條款可讀，因為權重並未釋出。權威資料是 Google 自家的 Gemini API 文件集：ai.google.dev 上的模型目錄與各模型卡、圖像生成指南、定價頁面，以及 Gemini API 變更記錄。本頁若給出數字，其來源就是這裡，而且是廠商來源。

家族關係比發行系列更重要，因為它決定了你實際上能在哪些選項之間做選擇。相對於它的前一世代 Nano Banana 2，2.1 是 Google 引導新專案採用的世代；相對於 Nano Banana 2 Lite，2.1 以相符的入門價格換得更高的上限，因為兩者 1K 影像的計價都是 $0.0336（廠商定價，標準層級）。Lite 在三項有文件記載的方面放棄了這點：它只支援 1K 輸出、沒有 Search grounding，而且 Google 的指南說它「未針對多個參考輸入或多輪序列編輯進行最佳化」。如果你的工作負載是大量地單張影像輸入、單張影像輸出，Lite 是較便宜的工程選擇；如果你需要 2K 或 4K、多個參考，或與影像進行對話，Lite 根本不在候選之列。

它接受什麼以及它回傳什麼

這就是這個模型比其名稱所暗示的涵蓋範圍更廣的地方，值得直接查看廠商提供的模型卡，而不是從「image」這個詞去推斷。Google 為gemini-nano-banana-2.1所列出的模型卡，將可接受的輸入資料類型列為文字、圖像、影片和 PDF，輸出類型則列為圖像和文字。因此，輸入端接受提示、一或多張圖像、影片或 PDF 文件——而不只是文字——輸出端則可在圖像之外一併傳回文字，這正是讓對話式編輯得以實現的原因：模型可以針對它剛剛生成或修改的圖片作答。

其餘的範圍，全部由廠商依據模型卡、指南與更新日誌回報：

• 輸出解析度 —— 1K、2K 與 4K。Nano Banana 2 提供的 512px（0.5K）級別被明確標示為「在 Gemini Nano Banana 2.1 上不支援」，因此在此模型上，最低規格為 1K。參數必須使用大寫 K；Google 的指南指出，小寫值如 1k會遭到拒絕。

• 長寬比 — 本指南現在提供各模型的對照表，而 2.1 那一欄列出十四種：1:1、1:4、1:8、2:3、3:2、3:4、4:1、4:3、4:5、5:4、8:1、9:16、16:9 與 21:9。其中包括 1:4、4:1、1:8 和 8:1 這些寬幅與全景比例，指南也將其歸功於 Gemini 3.1 Flash Image。Lite 僅列出十種常規比例。

• 參考圖片——根據指南，「混合最多 14 張參考圖片以產生最終圖片」，而指南的表格現在會依模型分配額度，這在本頁最初起草時並沒有清楚地做到。在標題為「Gemini Nano Banana 2.1 與 Gemini 3.1 Flash Image」的欄位中，拆分方式為最多 10 張高保真物件圖片，以及最多 4 張角色一致性圖片；指南的正文給出相同數字，表示 2.1 支援「在單一工作流程中最多 4 個角色的角色相似度，以及最多 10 個物件的高保真度」。樣式參考僅列於 Gemini 3 Pro Image，因此在此不要規劃使用它們。

• Token 限制 — 依據模型卡，輸入 Token 上限為 131,072 個，輸出 Token 上限為 32,768 個。該模型卡未載明此模型的知識截止。

• — 支援，且指南明確指出，在 Gemini 3 圖像模型上，它「預設為啟用，且無法在 API 中停用」。模型最多會產生兩張過渡圖像來測試構圖與邏輯，而那些思考圖像在後端可見，但不計費。一個 thinking_level 可以在生成設定中設定；指南本身的範例是 high。

• 接地 — 搜尋接地在模型卡上列為支援功能，而更新日誌將 Google 搜尋接地列為 2.1 的功能。Nano Banana 2 Lite 則不具備此功能。

• 浮水印 —「所有生成的圖片都包含 SynthID 浮水印。」這項機制適用於整個系列，並非可有可無。

• 卡片標示為不支援的項目——音訊生成、快取、程式碼執行、檔案搜尋、函式呼叫、Google 地圖接地、Live API、結構化輸出和 URL 脈絡。支援 Batch API；不支援 Flex 與 Priority 推論。

文字渲染與編輯，如文件所述

有兩項已記錄的行為，會把像這樣的模型與單純的文字轉圖像端點區隔開來；而 Google 是在圖像生成指南中描述這兩者，而不是在基準測試中。

第一項是排版。指南將這項能力列為「進階文字渲染：能夠為資訊圖表、菜單、圖表和行銷素材生成清晰易讀、具風格化的文字」，而更新日誌特別將改良的文字渲染歸功於 2.1。模型卡則以「排版」一詞呼應這點。值得精確說明那究竟是什麼：那是對一項能力的描述，而不是實測的準確率。Google 並未公布任何字元錯誤數字、易讀性分數，也沒有公布其自身較早模型在文字渲染任務上的比較，因此任何人若引用某個數字來說明 2.1 渲染字母的效果有多好，引用的都不是 Google 的數據。

第二個是編輯，指南將其視為模型的對話模式。在編輯時，「模型會配合原始影像的風格、光線與透視」——編輯是在既有畫面內套用，而不是產出同一類型的新圖片。至於 inpainting（局部重繪），指示更為狹窄：只改變你指名的元素，並保留「原本的風格、光線與構圖」。更新日誌針對 2.1 在這條軸線上的主要宣稱，是改進的多輪角色一致性，而這項特性決定了某個物件或人物能否在連續五次編輯後仍看起來像自己。該說法由廠商自行回報，而且截至今日，在 Google 之外尚未被重現。

Google 所宣稱的內容，對比實際測量到的結果

Google 於 2026 年 10 月 6 日的 changelog 條目指出，2.1「維持 Flash 級別的速度與成本效率」，同時新增「視覺品質、提示詞遵循度、多輪角色一致性、文字渲染方面的顯著改善」，以及寬幅與全景長寬比。模型目錄則補充「改善的視覺品質、排版與多輪一致性」。這些都是供應商自己的說法，屬於方向性而非量化的描述，且並未附上任何由供應商執行的基準測試。

接下來有三件事，而它們是證據的誠實狀態，而非含糊其辭的規避。

首先，Google 並未針對 Nano Banana 2.1 公布任何自家的基準測試數據——在其文件頁面上，沒有 Elo、沒有勝率，也沒有任何形式的分數。若有任何關於此模型品質的數字被當成 Google 的數據來呈現，那就是 Google 未曾公布的數字。

第二，在相同設定下，Nano Banana 2.1 與 Nano Banana 2 之間並沒有廠商進行的直接對比。Google 宣稱每一代相較於前一代都有所改進；但它並未發布在相同提示、相同解析度與相同投入程度下的配對評估，讓讀者得以權衡兩者。任何人暗示這兩者之間存在可量測的差距，都是在暗示一件沒有人實際執行過的事。

第三，獨立評估確實存在，而這個測試框架值得指名道姓，好讓讀者自行判斷：Artificial Analysis 在其 Image Arena 中運行 Nano Banana 2.1，該平台涵蓋文字轉圖像與圖像編輯，並公布其分數背後的投票。這就是可用來判斷定位的第三方來源。這個模型在該處的具體名次與 Elo 分數，和本頁所回答的問題是兩回事，而且是依本頁無法控制的排程計算——請直接到來源查核，而不要對照從任何地方複製來的數字，包括我們在內。

今天如何取得，以及費用是多少

取用方式是透過 Google 自家的 API。你以模型識別碼 gemini-nano-banana-2.1 來呼叫 Gemini API；這個識別碼是穩定版本，而變更記錄中針對 gemini-3.1-flash-image 的淘汰條目所指名作為遷移目標的正是它。這裡沒有自架路徑、沒有權重下載，也沒有社群檢查點，因為這個圖像系列沒有任何部分是以那種方式釋出的。

定價，全部取自 Google 定價頁面的標準方案，且全部由供應商回報：

• 權杖 — 文字、圖像與影片的輸入為每 100 萬個權杖 $1.50；文字與思考的輸出為每 100 萬個權杖 $7.50，圖像則為每 100 萬個權杖 $30.00。

• 每張圖片 — 1K 為 $0.0336，2K 為 $0.0504，4K 為 $0.113。Google 也發布了 1K 情況的換算範例：1024×1024 的輸出會消耗 1,120 個圖片 token。

• 批次 — 標準費率的一半：每 1M 輸入 $0.75、每 1M 圖像 token $15.00，換算下來每張 1K / 2K / 4K 圖像為 $0.0168 / $0.0252 / $0.0567，以換取最多 24 小時的交付時間。

• 接地——圖片本身沒有獨立的項目。Google 將網頁與圖片搜尋接地功能與 Gemini 3 圖像模型綁售，每月提供 5,000 次免費搜尋請求，由所有 Gemini 3 及更新模型共用，之後每 1,000 次請求收費 $14；擷取的內容不會以輸入權杖計費。

• 免費方案 — 定價頁面的「免費方案」欄位中，上述每一項數字都顯示「無法提供」。此模型沒有提供圖片輸出的免費額度。若出現免費額度，只會顯示在該處，不會出現在其他地方。

• 同系列內的等級比較——Nano Banana 2 Lite 每 1K 張圖像為 $0.0336，與 2.1 的 1K 費率相同，但它並未公布 2K 或 4K 價格，因為它不提供這些尺寸。Nano Banana 2（Gemini 3.1 Flash Image）為每 1K $0.067、每 2K $0.101，因此在兩者共有的每個尺寸上，2.1 都更便宜。Nano Banana Pro（Gemini 3 Pro Image）為每 1K 或 2K 圖像 $0.134，4K 則為 $0.24，大約是 2.1 在 2K 及以下費率的兩倍，而在 4K 則略高於兩倍。

• 為了完整起見，舊版成員——最初的 Nano Banana（gemini-2.5-flash-image）已遭棄用，定價頁面上載有日期為 2026 年 10 月 2 日的停用通知。該模型在任何實際運作意義上都不是 2.1 以下的層級；此系列目前的入門選擇是 Nano Banana 2 Lite。

那組數字中有一個對不上，而這值得指出來，而不是挑選比較整齊的數字。Google 的定價頁面指出，此模型的一張 4K 圖片會消耗 3,780 個 token，並標示每張 4K 圖片為 $0.113；這兩者在每 100 萬個圖片 token 為 $30 時相符。圖片生成指南的逐模型表格給出與定價頁面相同的 1K 和 2K token 數量（1,120 和 1,680），但 4K 卻列為 2,520，以相同費率計算會約為 $0.0756。兩者都是 Google 頁面，而它們彼此不一致。價格才是應該緊抓的數字，因為那是向你收費的頁面上的數字，而這個差異正是你在據此建立成本模型之前，應該回到原始來源重新查核的那類問題。

還有一句讀者可能想知道的，就照實說：Nano Banana 2.1 目前不在 OrcaRouter 的即時模型清單上，因此本頁不宣稱能在此呼叫它。至於清單上有的，則是其直接前代模型，識別碼為google/gemini-3.1-flash-image-preview，而字串會遷移到 2.1 的正是這個模型。OrcaRouter 以 0% 加價直接傳遞供應商定價於其路由的模型上，因此供應商對路由模型的價格變動會在同日反映於此，而非延遲——這正是 Google 不斷重新分級此系列時，這個系列該留意的特性。

簡短版本

Nano Banana 2.1 是 Google 中階的 Gemini 圖像模型：可輸入文字、圖像、影片與 PDF；輸出圖像與文字；支援 1K、2K 與 4K；最多可用 14 個參照，拆分為十個物件與四個角色；具備網頁與圖片搜尋接地；每項輸出都帶有 SynthID；預設開啟思考功能；每 1K 張圖像 $0.0336。它的定位高於 Nano Banana 2 Lite——後者 1K 價格與其相同，但僅支援到 1K，且不提供搜尋接地——並低於 Nano Banana Pro，後者費率約為兩倍，是通往複雜版面與精準文字的昂貴途徑。它的識別碼，gemini-nano-banana-2.1，是唯一不會誤導你的名稱——而附加其上的品質宣稱是 Google 的說法，未經我們轉述。模型頁面是了解它是什麼的地方；如果你是基於它與 Nano Banana 2 之間的品質差異而選擇它，唯一能看到那項差異被權衡比較的地方是獨立競技場，而不是供應商的發布說明。