Skip to main content

模型卡

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

尺寸控制

  • 遵循原圖比例:不傳 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-preview:generateContent
  • 支援 OpenAI 相容模式呼叫(注意:不支援 URL 上傳,需用 Base64)
  • 不支援 /v1/image/generations

開發格式(預設推薦)

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

輸入圖片要求

  • 單圖不能超過 7MB(谷歌規則);若通過 Google Cloud Storage 匯入,單檔案上限 30MB
  • 每個提示最多 14 張圖
  • 支援的 MIME 型別image/pngimage/jpegimage/webpimage/heicimage/heifjpg 格式 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(圖床 / OSS 地址),省去本地編碼上傳的步驟。
URL 上傳對圖床、OSS 地址的要求較高:如果不是全球 CDN(例如騰訊雲物件儲存預設走國內 CDN),很可能無法被谷歌伺服器識別,進而請求失敗(典型表現為不參考圖)。如果條件允許,儘量用 Base64 方式上傳,穩定性更高——在平臺視角,這是通用能力上投入運維資源最多、最可靠的方式。
URL 上傳僅在 Gemini 原生端點可用;OpenAI 相容模式不支援 URL 上傳,需改用 Base64。

Curl 示例(fileUri)

Python 示例(fileUri)

fileDatamimeTypefileUri 必須使用駝峰命名(不是 file_data / file_uri),否則引數不生效、表現為不參考圖。

計費基礎(重要)

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

超時設定(重要)

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-preview)能正確基於它繼續編輯並累積修改;而逆向模型只認最後一條 user 訊息裡的參考圖,靠保留對話歷史做多輪在逆向上無效。
最小示例(每輪把產出圖回填進同一個 contents):
完整說明(含”對話歷史回填” vs “重新喂圖”兩種寫法、從已有圖片開始多輪)見 圖片編輯 API · 多輪對話式編輯

偶現多圖輸出是怎麼回事

呼叫 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 傳入圖片 URL;但 OpenAI 相容模式不支援 URL 上傳,需改用 Base64。程式碼示例與注意事項見上文 URL 圖片輸入說明
  • 圖片下載想直接拿到 URL(而非 Base64)? 使用 NB-OSS 分組——詳見 Nano Banana OSS 分組