一句話結論:API易 所有圖片模型均為同步呼叫——發出請求後保持連線等待,生成結果直接在響應裡返回。沒有非同步任務 ID、沒有輪詢介面;客戶端提前斷開,這次的結果就拿不回來了,但請求仍會計費。因此,留足 timeout 是圖片 API 開發的第一原則。
三個必須先知道的事實
全部同步呼叫
一次 HTTP 請求全程阻塞等待,與官方介面形態一致,沒有「提交任務 → 輪詢結果」模式。部分上游本身是非同步的(如 FLUX),也已被閘道封裝成同步,無需自己寫輪詢。
沒有任務 ID
不存在 task_id 查詢介面,也無法憑 request_id 事後找回圖片。API易 原廠透傳、不儲存生成結果,斷開連線後結果不可恢復。
斷連仍計費
客戶端超時主動斷開後,服務端與上游的生成仍會跑完,該次請求照常計費。timeout 設得太小 = 花了錢卻拿不到圖。
模型系列速查表
各圖片模型系列的推薦 timeout、輸出格式與 URL 支援一覽:計費與價格影響
新手最常問的計費問題:「參考圖是每張定量,還是圖片越大消耗 token 越多?」先建立三個直覺:成本大頭是輸出
以 gpt-image-2 為例:文本輸入 $5/M、圖片輸入 $8/M、輸出 $30/M。影響價格最大的永遠是輸出的尺寸和畫質(quality × size),其次才是參考圖張數。
輸入圖不是每張定量
GPT 系輸入圖按尺寸/寬高比對映成 tokens(越大越多,但有下限也有封頂),張數嚴格線性累加。Gemini 系則相反——輸出圖按解析度檔固定 token/張。
以介面返回的 usage 為準
輸入/輸出 token 都在響應裡:GPT 系看
usage.input_tokens_details.image_tokens,Gemini 系看 usageMetadata.promptTokensDetails。對賬、核價都以此為準,不要按張數估。兩大體系的 token 口徑對照
多圖輸入的費用直覺
- 單張參考圖約 800-1600 image tokens ≈ $0.008-0.012(gpt-image-2 實測,含尺寸/寬高比浮動);
- 張數線性累加:16 張 ≈ $0.13,與一張
high輸出(≈$0.21)同量級——多圖融合場景輸入成本不可忽略; - token 由畫素尺寸決定、與檔案體積無關:壓縮體積是為上傳穩定,不省 token;省 token 靠減少張數(超大圖有封頂,不必擔心費用爆炸)。
timeout 配置建議
為什麼預設 timeout 會誤傷
主流 HTTP 客戶端的預設超時普遍在 30-60 秒(requests 甚至預設不限時但常被框架包一層 30 秒),而圖片生成是真正的「長請求」:
- GPT-Image-2 在
high畫質 + 2K/4K 解析度下,實測整體耗時 3-5 分鐘; - Nano Banana 系列 4K 出圖約 50 秒起步,高峰期更久;
- 多圖融合、圖片編輯類請求普遍比文生圖更慢。
按模型分檔設定
重試策略
不是所有失敗都值得重試,先分清計費口徑:內容稽核攔截的計費分情況:按 token 計費的模型(gpt-image-2 官轉等)觸發稽核通常直接返回 400 錯誤,不計費;僅按次計費的 Nano Banana Pro 會遇到「HTTP 200 但出圖失敗」的谷歌側攔截,該次會計費——API易 對此類非主觀失敗提供 出圖失敗包補計劃,按條數核算後補發額度。
base64 資料處理要點
字首差異對照
不同系列返回的 base64 欄位格式並不統一,這是新接入時最常見的坑:
字首行為隨渠道版本變化過,寫程式碼時務必先做
startsWith("data:") 檢測:有字首的剝掉字首再解碼(或直接用作 img src),無字首的直接解碼,避免「雙重拼接」或「帶字首解碼」產出損壞的圖片。
解碼寫檔案
Playground 渲染限制
base64 模式的響應往往有數 MB,瀏覽器 Playground 可能彈出請求時發生錯誤: unable to complete request——這不代表請求失敗,實際請求已成功並已計費,只是瀏覽器無法渲染這麼長的字串。驗證效果請用程式碼呼叫,或改用支援 url 輸出的模型/引數。
輸入圖片格式預處理
圖片編輯 / 參考圖類介面(如 gpt-image-2 的/v1/images/edits)對輸入圖片只接受 png / jpg / webp 三種標準格式。「使用者上傳實拍圖」類業務最容易踩一個隱蔽的坑:手機原拍照片經常不是標準 JPEG。
典型症狀:400 invalid_image_file
.jpg 內嵌 HDR 增益圖副幀,實為 MPO。這類檔案的隱蔽性在於——檔案頭同為 FFD8,副檔名、HTTP Content-Type、file 命令全都顯示 JPEG,只有按幀解析才能識別:
建議:服務端統一重編碼
與其逐張排查,不如在上傳鏈路統一做一次重編碼,順帶相容 HEIC、CMYK 等其它非標準輸入:需要 URL 輸出怎麼辦
一共三條路徑,按可靠程度排序:- 原廠預設就是 URL:FLUX(僅約 10 分鐘有效且無 CORS 頭,必須服務端立即下載轉存)和 Seedream(BytePlus TOS,約 24 小時)的原廠輸出格式本身就是 URL,無需任何配置。
- OSS 分組(確定性 URL 輸出,推薦生產使用):
image2_OSS分組:適用於 GPT-Image-2-All / VIP(1x 倍率、不加價),令牌分組切換後穩定輸出 URL、不降級為 base64;官轉 GPT-Image-2 暫不支援。NB_OSS內測分組:適用於 Nano Banana 系列,圖片 URL 出現在text欄位中,詳見 NB-OSS 分組說明。
- 顯式傳
response_format: "url":僅 GPT-Image-2-All / VIP(R2 CDN,約 24 小時)和 Seedream 支援,適用面窄——官轉 GPT-Image-2 傳了直接 400。預設分組下這是逐請求切換,強依賴 URL 的業務建議直接用 OSS 分組。
超時與斷連排查
如果你已經把 SDK timeout 調大了卻仍然頻繁「超時」,按這個順序排查:1
確認客戶端 SDK 的真實 timeout
有些框架會在 HTTP 客戶端外再包一層超時(如任務佇列的 worker 超時、Serverless 函式的執行上限),任何一層小於模型生成時間都會掐斷請求。
2
排查中間層:nginx / 負載均衡 / CDN
自建反向代理的
proxy_read_timeout、雲負載均衡的空閒連線超時、CDN 的回源超時預設值普遍是 60 秒,會先於你的客戶端斷開連線。長請求鏈路上的每一跳都要放寬。3
啟用 keep-alive,避免連線被中間裝置回收
長時間無位元組傳輸的連線可能被 NAT / 防火牆靜默回收,開啟 TCP keep-alive 或 HTTP keep-alive 可顯著降低機率。
4
用請求 ID 與後臺日誌確認是否已計費
記錄響應頭中的
x-request-id,再到 API易 後臺的呼叫日誌中核對:如果日誌裡能查到這次呼叫,說明服務端已完成生成並計費,問題出在你這一側的連線被提前斷開。想做非同步任務管理?
平臺不提供非同步介面,但你完全可以在同步介面之上自建非同步外殼:為什麼沒有非同步介面
FAQ:圖片生成有非同步介面嗎?支援任務 ID 查詢結果嗎?
自實現非同步佇列
工程實踐:把同步呼叫包進任務佇列,自己生成 task_id、落庫、重試
NB-OSS URL 輸出分組
Nano Banana 系列改為 URL 輸出,減輕 base64 傳輸壓力