跳轉到主要內容

模型卡

完整價格對比、按次/按量計費與令牌選擇建議,見 Nano Banana 系列價格總覽。

實測效果展示

以下兩張圖均由 Nano Banana 2 Lite(gemini-3.1-flash-lite-image)實測生成,展示文生圖與圖片編輯效果;結果僅代表該模型和本次提示詞,不等同於系列內其他模型的效果保證。 文生圖 · 16:9 寬幅街景(僅提示詞:雨後老城巷子,青石板積水映著暖黃路燈,遠處有人撐傘走過,16:9 構圖):8.3 秒出圖,aspectRatio: 16:9 真實生效,招牌上的「老茶館」「客棧」「酒肆」都能讀清。
Nano Banana 2 Lite 文生圖實測:16:9 雨後老城巷子,暖黃路燈與中文招牌清晰
圖片編輯 · 黃昏改光並加招牌(參考圖為街邊咖啡館,提示詞:光線改成黃昏暖調,在店面上方加中文招牌「轉角咖啡」,其餘部分保持不變):19.3 秒出圖,招牌筆畫清晰、貼合牆面透視,綠植與腳踏車的投影隨光線一起變暖。
Nano Banana 2 Lite 編輯實測:咖啡館外景改為黃昏暖調,並加上中文招牌「轉角咖啡」

尺寸控制

  • 遵循原圖比例:不傳 aspectRatio 即可;在多圖編輯場景裡,以最後一張圖的尺寸為準
  • 解析度 imageSize:支援 1K / 2K / 4K
    • Nano Banana(第一代)僅支援 1K
    • Nano Banana 2 新增 512px
    • Nano Banana 2 Lite 僅支援 1K(不支援 2K/4K/512px)
用同一套程式碼呼叫第一代 gemini-2.5-flash-image 時,必須去掉 imageSize 引數(它不支援 2K / 4K),否則會呼叫失敗。

接入方式

官方文件

  • 谷歌官方文件:ai.google.dev/gemini-api/docs/image-generation
  • 接入 API易 只需把請求地址 + KEY 替換為 API易 的即可,其餘引數與官方一致

官方狀態查詢(排查上游故障)

Nano Banana 系列底層依賴谷歌 AIStudio / Gemini API。少數情況下 2K / 4K 出圖變糊或報錯,可能是谷歌官方側的問題、而非接入層——可在谷歌官方狀態頁核對(請自行復制訪問):aistudio.google.com/status。 例如 2026 年 6 月 19 日,該頁報道過「Issues with Nano Banana」:Gemini API 與 AI Studio 上的 Nano Banana 2 / Pro 在 2K 或 4K 解析度下出現問題。遇到類似現象,先比對官方狀態頁即可快速判斷是否為上游故障。
API易 為 Nano Banana 系列提供 AIStudio + Vertex 雙通道冗餘:官方單通道異常時可由另一通道頂上,儘量保障服務可用性。

端點支援

  • 推薦端點(Gemini 原生):https://api.apiyi.com/v1beta/models/gemini-3-pro-image:generateContent
  • 支援 OpenAI 相容模式呼叫(/v1/chat/completions,可用 image_url 傳 Base64 或公網連結)
  • 不支援 /v1/image/generations

開發格式(預設推薦)

  • 【推薦】使用谷歌原生端點格式
  • 圖片:Base64 上傳、下載轉存
  • 呼叫方式:同步多執行緒呼叫,暫不支援非同步呼叫

輸入圖片要求

  • 單圖不能超過 7MB(谷歌規則);若通過 Google Cloud Storage 匯入,單檔案上限 30MB
  • 每個提示最多 14 張圖
  • 支援的 MIME 型別:image/png、image/jpeg、image/webp、image/heic、image/heif(jpg 格式 API易 已相容)
  • Base64 體積膨脹:圖片轉 Base64 後體積增加約 33.3%(7MB 的圖約為 9.3MB)
  • API易 限制:單次請求上傳圖片總量需低於 100MB——均為同步呼叫,過大會導致記憶體爆炸
谷歌 Gemini 3 Pro Image 官方技術規範表:單圖上限 7MB,每個提示最多 14 張圖,支援的寬高比與 MIME 型別

谷歌官方技術規範:內嵌/控制台上傳單檔案上限 7MB,支援 png/jpeg/webp/heic/heif

Base64 體積計算說明:7MB 原圖按 4/3 比例編碼後約 9.33MB

Base64 編碼使體積增加約 33.3%:7MB 圖片約等於 9.3MB

最佳實踐:傳給介面前對圖片做無失真壓縮,避免超大解析度拖慢請求速度。 谷歌官方規格說明(請自行復制訪問):docs.cloud.google.com/vertex-ai/generative-ai/docs/models/gemini/3-pro-image

URL 圖片輸入說明

除了 Base64,Gemini 原生端點還支援用 fileData.fileUri 直接傳圖片 URL,請求體更小,也省去自己下載、轉碼的步驟。 URL 傳圖時,圖片是由谷歌的伺服器去下載的,不是 API易。 所以能不能用、快不快,取決於谷歌訪問你的圖床順不順,跟你自己的瀏覽器能不能開啟沒有關係。下面這些要求和排查方法,都是從實際工單和實測(2026-10-16,NB2 / Pro,三條線路)裡總結出來的。
條件允許的話,優先用 Base64(inlineData)。 圖片由你自己下載後放進請求體,不依賴谷歌去拉圖,是穩定性最高的方式。URL 傳圖適合圖片本來就放在海外全球 CDN 上、又想控制請求體積的場景。

什麼樣的連結能用

http:// 和 https:// 連結實測都可以。gs://(Google Cloud Storage)只有部分線路能讀,不建議通過 API易 使用。

請求寫法

  • 多張圖:每張一個 fileData,按順序放在 parts 裡。也可以和 inlineData 混用,實測 2 張 URL 加 1 張 Base64 一次請求正常出圖
  • mimeType 按圖片的真實格式寫。實測寫錯或不寫,當前線路也能識別,但不要依賴這一點
  • 欄位命名:推薦與谷歌官方一致的駝峰寫法 fileData / fileUri / mimeType。實測下劃線寫法 file_data / file_uri 目前也能識別

確認參考圖真的被讀到了

連結拉取失敗時,有的線路不會報錯:返回 200、照常出圖並計費,但結果完全沒參考你的圖。所以不能只看狀態碼,要看響應裡的 usageMetadata.promptTokensDetails:
有 IMAGE 這一項,說明圖片讀到了(實測預設設定下 Nano Banana 2 每張約 1120 tokens,Pro 每張約 560 tokens);只有 TEXT,說明谷歌沒拿到圖,這次結果不會參考原圖。下面的 Python 示例已經內建了這道檢查。

拉圖失敗的幾種表現

同一個連結重試會變快,不代表問題解決了。 谷歌會快取拉過的圖片,第二次請求同一個 URL 往往直接命中快取;換一張新上傳的圖,還會再超時。自己測試時,可以在連結後加一個隨機引數(如 ?v=隨機數)避開快取,才能測出真實的拉圖速度。
超時問題的完整案例見 圖片編輯報 Unable to process input image 怎麼辦(同頁也講了 Base64 為空導致的報錯,兩者經常被混淆)。

Curl 示例(fileUri)

Python 示例(fileUri)

OpenAI 相容端點能傳 URL 嗎

可以。/v1/chat/completions 裡用 image_url 傳公網連結,實測 Nano Banana 2 與 Pro 都能正常讀到圖片並出圖。連結要求與上文相同;需要多輪編輯、精確控制解析度等能力時,仍推薦原生端點。

計費基礎(重要)

  • 同步呼叫耗時:Pro / 2 在 4K 下的合理生成時間約 30–150s
  • 超時主動斷開仍計費:例如生成需 120s,但客戶端把超時設為 100s 主動斷開,仍會計費
  • 429 / 503 不收費:請求不通時不計費(我們儘量不讓客戶久等、不卡死遲遲不出圖)
  • 內容安全拒絕仍計費:客戶輸入存在內容安全問題、谷歌拒絕出圖時,狀態碼 200 仍會計費——詳見下方錯誤處理與保障計劃

Google 搜尋接地會在按次價之外另收費

Pro 支援 googleSearch 工具(實測 3/3 觸發接地,返回完整 groundingMetadata),用來畫天氣卡、股價圖這類需要即時資訊的圖。 但搜尋呼叫費是加在 $0.09 按次價之上的,不含在裡面:
搜尋次數由模型自己決定,客戶無法預先控制。實測一次出圖請求會自主發起 1–3 次檢索,所以開了這個工具之後單次成本是一個區間($0.104–$0.132),不再是固定的 $0.09。做成本預估時按上限算。
圖片搜尋接地(searchTypes.imageSearch)在 Pro 上不生效,實測 0/2 未觸發,groundingMetadata 裡不出現 imageSearchQueries。這是 Nano Banana 2(gemini-3.1-flash-image)的獨有能力,用法見 Nano Banana 2 · 影響計費的三個引數。

thinkingLevel 對 Pro 無效,不要照搬 NB2 的寫法

generationConfig.thinkingConfig.thinkingLevel 是 Nano Banana 2 系列獨有的開關。給 Pro 傳 high:
  • 不報錯,請求正常返回 200
  • 但完全不生效:實測 thoughtsTokenCount 在 108–156 之間,與不傳時的 130–159 完全重疊
  • Pro 的思考恆開、無法調節,官方文件亦如此說明
而且 Pro 按次固定計價,思考多少都不進賬單——所以在 Pro 上調這個引數既無效果、也無成本意義。需要控制思考開銷請改用 Nano Banana 2 的按量計費。

超時設定(重要)

4K 出圖的整體耗時較長,包含圖片上傳、API 處理、Base64 圖片下載等環節(我們後臺按 API 處理用時計費)。正常情況下 4K 用時約 50s(不含輪詢),但客戶端若把超時設得過短,就會在出圖完成前主動斷開並報錯:
呼叫日誌:gemini-3-pro 4K 出圖首位元組耗時 43 到 61 秒

呼叫日誌:4K 出圖首位元組耗時約 43–61s,預設 120s 超時偏緊

為更保險,建議按解析度設定超時時間:

多輪對話式編輯(原生支援,逆向不支援)

Nano Banana 系列走 Gemini 原生格式,支援真正的對話式多輪編輯:把模型每一輪產出的圖作為 role: "model" 的 inlineData 回填進 contents,再發下一條 user 指令,模型會基於完整對話歷史繼續修改並累積效果(如先改沙發顏色、再加配飾,上一步的改動會保留)。 這一點與”逆向”影像模型有本質區別,接入前務必分清:
實測:把上一張圖放進 model 角色回填,Nano Banana 2(gemini-3.1-flash-image)能正確基於它繼續編輯並累積修改;而逆向模型只認最後一條 user 訊息裡的參考圖,靠保留對話歷史做多輪在逆向上無效。
最小示例(每輪把產出圖回填進同一個 contents):
完整說明(含”對話歷史回填” vs “重新喂圖”兩種寫法、從已有圖片開始多輪)見 圖片編輯 API · 多輪對話式編輯。

取圖必須遍歷 parts,不要按下標

parts 是一個異構陣列:裡面可能只有圖片段,也可能文本段與圖片段混排,段數和順序都不做保證。因此 parts[0] / parts[1] 這類寫死下標的取法一定會間歇性失敗。 實測出現過的三種排列: 文本段的來源不止一種:responseModalities 裡含 TEXT、提示詞要求模型給出文字說明,都會讓模型在圖片之外再返回一段文本;文本段排在圖片前還是圖片後也不固定。因此圖片落在哪個下標並非定值,同一份程式碼在不同請求下可能拿到不同結構。
寫死下標的兩種寫法是互補的:圖片必落在 [0] 或 [1],無論選哪個,都存在拿不到圖的請求。在 [0] 和 [1] 之間來回改解決不了問題,只有按欄位特徵篩選才穩定。
正確寫法是按欄位特徵篩選,而不是按位置索引。注意取的是最後一個 inlineData 而非第一個——複雜任務下模型會返回多張圖,最後一張才是最終稿(見下一節):
加固手段:在 generationConfig 裡顯式宣告 responseModalities: ["IMAGE"],表明只要圖片,可減少多餘文本段。但這是加固、不是替代——遍歷篩選仍需先落地。反向並不成立:傳 ["TEXT","IMAGE"] 並不保證一定返回文本段,模型也可能只給圖片。
mimeType 同樣不要寫死。響應裡的圖片格式並不恆定,image/png 與 image/jpeg 都出現過。若按固定 .png 字尾落盤,會得到副檔名與實際內容不符的檔案——一律以響應裡的 mimeType 為準決定字尾。

偶現多圖輸出是怎麼回事

呼叫 gemini-3-pro-image 時,偶爾會看到同一個響應裡返回多張圖片 part(實測 2–10 張),日誌裡對應偶發的 6000+ 乃至上萬的輸出 tokens。這不是異常:谷歌官方文件說明 Gemini 3 圖片模型預設啟用”思考”(無法在 API 中關閉),模型會生成臨時圖片來測試構圖和邏輯,這些中間稿與最終稿一併出現在 parts 裡,且”思考中的最後一張圖片也是最終渲染的圖片”(官方文件:ai.google.dev/gemini-api/docs/image-generation)。基於 2026 年 7 月實測(Google 原生 generateContent 格式): 觸發因素是提示詞的任務複雜度,不是”圖片編輯”本身。多張圖仍在同一個 candidate 內(不是多 candidates),每張都是完整的成圖——它們是思考過程中對同一設計的逐稿修正(構圖相同、細節略有差異),最後一張 part 即最終稿。這些中間稿以普通圖片 part 返回(帶 thoughtSignature 欄位、無 thought: true 標記);官方稱思考最多生成兩張臨時圖片,實測複雜任務下最多見 10 張。 對計費的影響:每張圖按固定 tokens 計費(1K/2K 解析度每張 1120 tokens,4K 每張 2000 tokens),輸出 tokens 隨圖片數嚴格線性增長。日誌裡偶發的 6000+(極端可達 1.3 萬+)輸出 tokens 就是 4–10 圖響應,不是異常計費。 下游程式碼建議:
  • 必須遍歷 parts,不要假設單響應單圖;按張計數、落盤的邏輯要以實際 part 數為準
  • 只要一張時取最後一張:前面的迭代稿細節未修完,品質略低,不建議取第一張
  • 提示詞控制張數基本無效(實測”只輸出一張”類指令不敏感),請在程式碼層處理
  • 多圖響應耗時 35–142s(1K 解析度,張數越多越久),顯著長於單圖,超時請沿用上文建議(≥ 5 分鐘)
usageMetadata 各欄位的完整口徑(details 與總量的差值、拒絕響應的計數特例等)見 usage 欄位與輸出解讀。

常見問題

錯誤處理指南

出圖失敗的三大判斷指標、內容稽核政策與友好提示方案

常見開發問題必讀

出圖失敗排查與常見疑問

出圖失敗保障計劃

非主觀原因導致的失敗,按條數核算後補發額度
完整報錯形如:
這種錯誤往往是上傳的圖片體積過大,請求體超限把連線壓崩了。請按以下最佳實踐處理:
  • 控制圖片張數:保持在官方規則內(每個提示最多 14 張圖,見上方官方技術規範)。
  • 控制單圖體積:每張圖儘量不要超過 5MB——官方單圖上限為 7MB,且 base64 編碼後體積還會膨脹約 1/3,原圖請留足餘量。
  • 前端先壓縮再上傳:在前端(或服務端中轉層)壓縮後再提交給介面,常見做法是限制最長邊、轉 JPEG/WebP 並控制品質引數。
  • 改用 URL 傳圖:Gemini 原生格式支援 fileData.fileUri 直接傳圖片 URL,可避開 base64 請求體過大的問題,見上文 URL 圖片輸入說明。

應用場景

  • AI 對話客戶端:Cherry Studio 等客戶端可直接配置 API易 出圖
  • 出圖測試:可在對話客戶端或控制台快速驗證模型效果

高階需求

  • 圖片上傳想用 URL? Gemini 原生端點用 fileData.fileUri 傳入,OpenAI 相容端點用 image_url 傳入;圖片由谷歌伺服器下載,對圖床要求較高。連結要求、拉圖失敗的判斷與程式碼示例見上文 URL 圖片輸入說明。
  • 圖片下載想直接拿到 URL(而非 Base64)? 使用 NB-OSS 分組——詳見 Nano Banana OSS 分組。