模型卡
完整價格對比、按次/按量計費與令牌選擇建議,見 Nano Banana 系列價格總覽。
尺寸控制
- 遵循原圖比例:不傳
aspectRatio即可;在多圖編輯場景裡,以最後一張圖的尺寸為準 - 解析度
imageSize:支援1K/2K/4K- Nano Banana(第一代)僅支援 1K
- Nano Banana 2 新增 512px
- Nano Banana 2 Lite 僅支援 1K(不支援 2K/4K/512px)
接入方式
官方文件
- 谷歌官方文件:
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/png、image/jpeg、image/webp、image/heic、image/heif(jpg格式 API易 已相容) - Base64 體積膨脹:圖片轉 Base64 後體積增加約 33.3%(7MB 的圖約為 9.3MB)
- API易 限制:單次請求上傳圖片總量需低於 100MB——均為同步呼叫,過大會導致記憶體爆炸

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

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 上傳僅在 Gemini 原生端點可用;OpenAI 相容模式不支援 URL 上傳,需改用 Base64。
Curl 示例(fileUri)
Python 示例(fileUri)
計費基礎(重要)
- 同步呼叫耗時:Pro / 2 在 4K 下的合理生成時間約 30–150s
- 超時主動斷開仍計費:例如生成需 120s,但客戶端把超時設為 100s 主動斷開,仍會計費
- 429 / 503 不收費:請求不通時不計費(我們儘量不讓客戶久等、不卡死遲遲不出圖)
- 內容安全拒絕仍計費:客戶輸入存在內容安全問題、谷歌拒絕出圖時,狀態碼 200 仍會計費——詳見下方錯誤處理與保障計劃
超時設定(重要)
4K 出圖的整體耗時較長,包含圖片上傳、API 處理、Base64 圖片下載等環節(我們後臺按 API 處理用時計費)。正常情況下 4K 用時約 50s(不含輪詢),但客戶端若把超時設得過短,就會在出圖完成前主動斷開並報錯:
呼叫日誌:4K 出圖首位元組耗時約 43–61s,預設 120s 超時偏緊
多輪對話式編輯(原生支援,逆向不支援)
Nano Banana 系列走 Gemini 原生格式,支援真正的對話式多輪編輯:把模型每一輪產出的圖作為role: "model" 的 inlineData 回填進 contents,再發下一條 user 指令,模型會基於完整對話歷史繼續修改並累積效果(如先改沙發顏色、再加配飾,上一步的改動會保留)。
這一點與”逆向”影像模型有本質區別,接入前務必分清:
實測:把上一張圖放進
model 角色回填,Nano Banana 2(gemini-3.1-flash-image-preview)能正確基於它繼續編輯並累積修改;而逆向模型只認最後一條 user 訊息裡的參考圖,靠保留對話歷史做多輪在逆向上無效。contents):
偶現多圖輸出是怎麼回事
呼叫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 分鐘)
常見問題
錯誤處理指南
出圖失敗的三大判斷指標、內容稽核政策與友好提示方案
常見開發問題必讀
出圖失敗排查與常見疑問
出圖失敗保障計劃
非主觀原因導致的失敗,按條數核算後補發額度
報錯 connection reset by peer / write_response_body_failed(500)是什麼原因?
報錯 connection reset by peer / write_response_body_failed(500)是什麼原因?
完整報錯形如:這種錯誤往往是上傳的圖片體積過大,請求體超限把連線壓崩了。請按以下最佳實踐處理:
- 控制圖片張數:保持在官方規則內(每個提示最多 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 分組。