> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apiyi.com/llms.txt
> Use this file to discover all available pages before exploring further.

# GPT-Image-2.6 官轉 vs 官逆 對比

> gpt-image-2.6-flare / gpt-image-2.6-sunburst（官轉，按 token）與 gpt-image-2.6-all（官逆，$0.025/張）逐項對比：計費、size / n / quality、GIF / SVG、透明底與 mask、響應格式、速度與邊界，附選型建議與常見問題。

## 一句話結論

| 你需要 | 選這個 |
| - | - |
| **與 OpenAI 官方欄位完全一致**、`quality` 六檔、任意合法尺寸、原生 2K/4K | 官轉：`gpt-image-2.6-flare`（速度優先）/ `gpt-image-2.6-sunburst`（精細編輯優先） |
| **成本必須封頂**：固定 \$0.025/張，2K/4K 同價，不隨尺寸和畫質浮動 | 官逆：`gpt-image-2.6-all` |
| **一次調用出多張**（1–4 張）或要 **24 小時直鏈 URL** | `gpt-image-2.6-all` |
| **GIF 的幀數、幀時長、單幀尺寸都要可控**，或要 SVG 指定編寫模型並精確核算文本費 | 官轉 2.6 兩款 |
| **精確 mask 局部重繪 / 多圖融合（最多 16 張）/ WebP 輸出 / 原生 4K** | 官轉 2.6 兩款 |
| **低成本 GIF、SVG**，且不想傳 `svg.model`、不想付編寫模型費 | `gpt-image-2.6-all` |

> [!NOTE]
>
> 本頁只對比 2.6 代的三款模型。2.5 / 2 代（`gpt-image-2.5-flare` / `sunburst` / `gpt-image-2` 與 `gpt-image-2-all` / `gpt-image-2.5-all` / 三款 `-vip`）的完整對比見 [GPT-image-2.5 / 2 官轉 vs 官逆](https://docs.apiyi.com/zh-Hant/api-capabilities/gpt-image-2/vs-gpt-image-2-all.md)。`gpt-image-2.6-all` 是 2.6 的新官逆線，**不是** `gpt-image-2.5-all` 的改名，兩者行為和引數邊界不同。

## 完整對比表

| 維度 | 官轉：`gpt-image-2.6-flare` / `gpt-image-2.6-sunburst` | 官逆：`gpt-image-2.6-all` |
| - | - | - |
| **通道性質** | OpenAI Images API 官方直連，欄位、錯誤碼與官方一致 | 逆向 ChatGPT 網頁版 Images 2.6 |
| **計費方式** | **按 token 實計**：文本輸入 \$5 / 圖片輸入 \$8 / 圖片輸出 \$30（每 1M tokens） | **按次計費**：\$0.025/張，2K/4K 不加價；`n` 張按張疊加 |
| **單張成本** | 隨 `quality`、`size`、參考圖數量浮動，約 \$0.006–\$0.21 量級（1K 參考值，以 `usage` 為準） | 固定 \$0.025/張（`n=4` 即 \$0.10） |
| **推薦端點** | `/v1/images/generations` + `/v1/images/edits` | `/v1/images/generations` + `/v1/images/edits` |
| **單次出圖數 `n`** | 1 張（要更多張請客戶端併發） | 1–4 張（`n=5` 起 400） |
| **`size`（原生檔）** | 任意合法尺寸：兩邊 16 的倍數、比例 ≤3:1、總畫素 655,360–8,294,400、最大邊 3840；另有 8 個預設尺寸 | 長邊 512–1536 **任意整數**（不要求 16 倍數）、比例 ≤3:1，精確輸出 |
| **`size`（2K / 4K）** | **原生畫素**（2048×2048、2048×1152、3840×2160 等）；超過 2560×1440 官方標記為實驗性 | **超分放大**：常見 2K/4K 尺寸可精確交付；不匹配返回 502；方形上限 2880；4:1 直接 400 |
| **`quality`** | `auto` / `low` / `medium` / `high` / `xhigh` / `max` 六檔 | 僅 `auto` / `medium` / `high`；`low` / `hd` 返回 400；三檔暫無可驗證的畫質差異 |
| **`complexity`（2.6 新引數）** | ✅ 已通過原生透傳支援：`low` / `medium` / `high`（省略預設 `high`），不單獨計費；建議同提示詞對比後再定檔位 | **不支援**該引數 |
| **輸出格式** | `png` / `jpeg` / `webp` / `gif` / `svg` | `png` / `jpeg` / `gif` / `svg`；**WebP 返回 400** |
| **透明背景** | `background=transparent` + `png` / `webp`；與 `jpeg` 互斥（400）；GIF 為 1-bit 透明；SVG 不寫背景 | 僅 `png`：2K 以內穩定，4K 不穩定 |
| **GIF 控制** | 幀數、幀時長、單幀尺寸都可控，但有拼影像素預算（1024² / 2048² 單幀不可用） | 幀數 / 幀時長精確；**成片尺寸由上游決定**，必須顯式傳 `output_format=gif` |
| **SVG** | 必須傳 `svg.model` 指定編寫模型，文本模型費用另計；僅 generations、`n=1` | 不需要 `svg.model`（傳了也被忽略）；無文本模型費；`viewBox` 跟隨 `size` |
| **mask 局部重繪** | 官方語義支援（PNG + alpha 通道，仍屬軟引導） | 接受，但**不承諾只改蒙版區** |
| **多圖參考** | 最多 16 張（`image[]`） | 實測 2 張可用；更多建議客戶端拼圖或分步編輯 |
| **響應格式** | 固定 `b64_json`（純 base64，無字首）；**不接受 `response_format`**，傳了 400 | 預設 `b64_json`；支援 `response_format: "url"`（24 小時簽名連結；url 響應可能無 `size`） |
| **速度** | 官方稱 2.6 整體提速 50%，`flare` 在 `low` 下最快 6 秒（官方最佳情況）；高畫質與 2K/4K 明顯更慢 | 典型 10–46 秒（1K 10–22 秒、2K 12–24 秒、4K 15–42 秒），尾延遲實測可達 198 秒 |
| **建議客戶端超時** | `low` ≥120 秒 / `medium` ≥240 秒 / `high` ≥600 秒 / `xhigh` ≥300 秒 / `max` ≥600 秒 | ≥600 秒 |
| **令牌與分組** | 需「按量優先」令牌；Default 分組，高峰期可切 `image2Enterprise` 企業分組（1.2x） | 按次計費模型，Default 分組即可；URL 輸出不需要額外分組 |
| **穩定性** | 官方通道，錯誤碼與官方一致；Default 高峰期偶發 429 | 反向上游；2K/4K 偶發 502，需要重試；尺寸不匹配會明確報錯，不靜默改尺寸 |
| **適合** | 品質敏感、需要官方欄位與原生畫素、可接受按量浮動的生產場景 | 成本封頂、批量出圖、2K/4K 大圖相容、GIF / SVG / 多張 / URL 場景 |

> [!NOTE]
>
> 表中的成本量級來自 **2.5 同價檔實測**（2026-09-09，UTC+8）與 2K/4K 畫素外推；2.6 官轉尚無公開的分層實測資料，實際費用以每次響應裡的 `usage.output_tokens` 為準。2.6-all 的按次價以「模型價格」欄目和最終賬單為準。

## 計費方式與成本

兩條線最本質的差異是**計量方式**：官轉按 token 實計，2.6-all 按張封頂。這決定了不同場景下誰更省。

### 1024×1024 單張成本參考

| 畫質 | 官轉 2.6（按 token 實計） | `gpt-image-2.6-all` |
| - | - | - |
| `low` | ≈\$0.006（2.5 同價檔 196 tokens）；2.6 單點實測 824 tokens ≈ \$0.025 | \$0.025 |
| `medium` | ≈\$0.013（439 tokens） | \$0.025 |
| `high` | ≈\$0.053（1,756 tokens） | \$0.025 |
| `xhigh` | ≈\$0.094（3,122 tokens） | \$0.025 |
| `max` | ≈\$0.211（7,024 tokens） | \$0.025 |

> [!NOTE]
>
> 模型價格與官網對齊，且可能隨官網調整；上表僅供參考，具體以頂部導航「模型價格」欄目為準：[模型價格](https://docs.apiyi.com/zh-Hant/models/index.md)。

### 2K / 4K 與多張、編輯、SVG

| 場景 | 官轉 2.6（按 token 實計） | `gpt-image-2.6-all` |
| - | - | - |
| 2048×2048 `medium` / `high` | ≈\$0.21 / ≈\$0.84（畫素外推，非官方價） | \$0.025 |
| 2048×1152 `medium` / `high` | ≈\$0.06 / ≈\$0.25（畫素外推） | \$0.025 |
| 3840×2160（4K）`medium` / `high` | ≈\$0.22 / ≈\$0.87（畫素外推） | \$0.025 |
| 同提示詞出 4 張 | 4 次呼叫，按 token 累加 | 4 × \$0.025 = \$0.10 |
| 編輯，1 張 1024² 參考圖 | 輸出 token + 輸入費（1024² 參考圖 ≈\$0.0082） | \$0.025/張 |
| SVG | 影像段 + 編寫模型文本費：`gpt-6-luna` ≈\$0.026、`gpt-5.6-terra` ≈\$0.039 | \$0.025 |
| GIF，512² 2 幀 | ≈\$0.017 | \$0.025 |

> [!WARNING]
>
> **2K/4K 的官方成本並沒有固定表。** 官方只公佈 1K 的每張參考價，上表 2K/4K 數字是按畫素比例從 1K 外推的估算值，誤差可能較大；`high` 且超過 2560×1440 還是實驗檔位。真實成本請以每次呼叫的 `usage.output_tokens` 為準。2.6-all 的 \$0.025/張、2K/4K 同價為文件口徑，最終以賬單為準；具體價格見頂部導航「模型價格」欄目：[模型價格](https://docs.apiyi.com/zh-Hant/models/index.md)。

**怎麼快速判斷：** 純輸出口徑下，官轉 \$0.025 對應約 **833 個 output tokens**，大致落在 2.5 檔位的 `medium` 與 `high` 之間。所以：

* **1K 中低畫質**：兩邊成本處於同一量級，官轉按實測 `usage` 可能更便宜；但 2.6 的單點實測（`low` 824 tokens ≈ \$0.025）說明這一優勢在 2.6 上可能已經不明顯，**不要按 2.5 的數字直接下結論**。
* **1K `high` 及以上、2K/4K 中高畫質**：2.6-all 的固定 \$0.025 有絕對優勢，高畫質 2K/4K 可相差一個數量級。
* **帶參考圖的編輯**：官轉每張 1024² 參考圖約 \$0.0082 輸入費，多圖會明顯推高單次成本；2.6-all 按張計價，參考圖不額外疊加。

> [!TIP]
>
> 上生產前用自己的提示詞各跑一輪，把兩條線的 `usage` 和耗時都記下來：官轉看 `output_tokens` 折算成本，2.6-all 看張數 × 單價。同一個「價效比」結論只對同一批提示詞成立。

## 關鍵差異詳解

### 1. `size`：官轉是「任意合法尺寸 + 原生 2K/4K」，2.6-all 是「1536 原生 + 超分 2K/4K」

**官轉 2.6** 沿用官方尺寸規則，四條同時滿足即可：

1. 最大邊 ≤ 3840
2. 兩條邊都是 16 的倍數
3. 長短邊比例 ≤ 3:1
4. 總畫素數在 655,360–8,294,400 之間

預設尺寸有 8 檔：`auto`、`1024x1024`、`1536x1024`、`1024x1536`、`2048x2048`、`2048x1152`、`3840x2160`、`2160x3840`。2K/4K 是**原生畫素**，不是放大出來的。

**2.6-all** 分兩段：

* **原生檔**：長邊 512–1536，任意整數都精確輸出，不要求 16 的倍數（`1000x1000`、`1280x720`、`1536x864` 都能過），比例 ≤3:1
* **超分檔**：`2048x2048`、`2048x1152`、`2048x1536`、`1920x1080`、`3840x2160`、`2880x2880` 等常見尺寸可精確交付；不匹配時返回 **502 `size_not_deliverable`**，不會靜默換成別的尺寸。方形上限 2880（`4096x4096` 會 502），`4096x1024` 這類超過 3:1 的比例直接 400

> [!NOTE]
>
> 還有一個容易忽略的差別：官轉光柵圖有**最小畫素預算**（約 655,360），`512x512` 這類小圖會被拒；2.6-all 可以出 `512x512`、`512x384`。做小尺寸圖示或縮圖時，2.6-all 更靈活。

### 2. `n`、`quality` 與 `complexity`：官方檔位 vs 三檔 + 多張

* **`n`**：官轉固定 1 張，多張只能客戶端併發；2.6-all 支援 1–4 張，按張計費，`n=5` 起 400。
* **`quality`**：官轉六檔全開（`low` / `medium` / `high` / `xhigh` / `max` / `auto`），是官方承諾的畫質控制；2.6-all 只接受 `auto` / `medium` / `high`，`low` / `hd` 直接 400，且三檔目前沒有可驗證的畫質差異——**不要用它來控畫質，也不要指望它控尺寸**。
* **`complexity`**：2.6 引入的新引數。官轉已通過原生透傳支援官方三檔（`low` / `medium` / `high`，省略時預設 `high`），不單獨收費，較高檔位可能增加耗時，建議先用同一提示詞對比結果再決定檔位；**2.6-all 不支援該引數**。

### 3. GIF 與 SVG：一個重控制，一個重成本

**GIF**

| 維度 | 官轉 2.6 | `gpt-image-2.6-all` |
| - | - | - |
| 幀數 | 2–16，預設 9 | 文件未給範圍；實測 4 / 6 / 8 幀均精確 |
| 幀時長 | 20–2000ms，預設 200ms，按 10ms 取整 | 實測 120 / 150 / 300ms 均精確 |
| 單幀尺寸 | 必須是 16 的倍數；受拼影像素預算約束 | **`size` 不生效**，成片尺寸由上游決定 |
| 成片尺寸 | 可預期：512×512 全幀數可用；1024² / 2048² 單幀不可用 | 不保證：實測出現過 384×512、507×506、619×623 |
| 編輯介面 | 支援 | 文件只演示 generations 端點，編輯 + GIF 需自行驗證 |

官轉 2.6 的 GIF 是先把所有幀畫進一張拼圖再切幀，所以限制落在拼圖上：單邊 ≤3840、總畫素 ≤8,294,400、長短邊比 ≤3:1。方形單幀上限隨幀數變化：2–9 幀 960×960、10–12 幀 816×816、13–16 幀 720×720。超過預算會返回 400；`frame_count` 傳 1 或 17 不報錯，但會回退成預設 9 幀 / 1.8 秒，要用 `ffprobe` 驗真實幀數。

**SVG**

| 維度 | 官轉 2.6 | `gpt-image-2.6-all` |
| - | - | - |
| 必填欄位 | `output_format="svg"` + `svg.model`（編寫模型） | 只要 `output_format="svg"` |
| 額外費用 | 編寫模型按所選文本模型的輸入 / 輸出單價另計（單張約 \$0.001–\$0.013） | 無，按次 \$0.025 |
| 端點 / 張數 | 僅 generations、`n=1`；編輯介面不支援 SVG | generations；`viewBox` 跟隨 `size` |
| 尺寸 | `viewBox` 跟隨 `size`，大尺寸尚無公開實測 | 實測 `viewBox` 到 8192；4:1 比例也不受光柵 3:1 限制 |

> [!WARNING]
>
> 官轉 2.6 的 SVG 必須自己指定編寫模型（漏傳直接 400 `SVG generation requires 'svg.model'`），費用由「影像段 + 文本段」兩部分組成；2.6-all 不需要 `svg.model`，傳了也會被忽略。需要精確核算 SVG 文本成本時選官轉，需要便宜、少欄位依賴時選 2.6-all。

### 4. 響應格式：`b64_json` vs `b64_json` + URL

* **官轉 2.6**：固定返回 `b64_json`（純 base64，無 `data:` 字首），**不接受 `response_format`**，傳了直接 400。需要 URL 必須自己轉存。
* **2.6-all**：預設 `b64_json`，也可以顯式傳 `response_format: "url"` 拿 24 小時簽名連結。注意 **url 響應可能沒有 `size` 欄位**，b64 響應才有；URL 過期後要重新生成，服務端應及時轉存。

兩者的 `b64_json` 都不帶 `data:` 字首，解碼邏輯可以共用。

### 5. 編輯能力：mask、多圖與 markup

| 能力 | 官轉 2.6 | `gpt-image-2.6-all` |
| - | - | - |
| mask 局部重繪 | 官方語義：PNG、帶 alpha、小於 4MB，但仍是軟引導，不保證邊界畫素級精確 | 接受，但不承諾只改蒙版區；複雜修改建議在提示詞裡寫清「只改哪裡、保留哪裡」 |
| 多圖參考 | 最多 16 張（`image[]`），prompt 裡可用「圖1/圖2」指代 | 實測 2 張可用；更多建議先拼圖或分步編輯 |
| 編輯 `auto` 尺寸 | 由官方語義決定 | 輸出會歸一到約 1.57MP 並保持原圖長寬比，不保證原影像素尺寸 |
| markup 標記編輯 | 2.6 新增能力，但不同路由的透傳情況需在你的分組單獨實測 | 文件未承諾 |

### 6. 速度、超時與穩定性

**速度口徑要分清「官方表述」和「實測」：**

* 官轉 2.6：官方稱整體提速 50%，`flare` 在 `low` 下最快 6 秒。這是官方最佳情況，不代表所有請求都能達到。站內目前沒有 2.6 的分層實測表，可參考 2.5 同價檔的實測：`2.5-flare` 1024² `low` 10 秒 / `high` 21 秒 / `max` 45 秒，`2.5-sunburst` 14 / 42 / 142 秒。高畫質與 2K/4K 會明顯更慢。
* 2.6-all：典型 10–46 秒（1K 10–22 秒、2K 12–24 秒、4K 15–42 秒），但尾延遲實測可達 198 秒，客戶端建議統一按 600 秒配置。

兩個通道都是**同步呼叫**：沒有任務 ID，客戶端斷開連線結果就丟失，但請求照常計費。超時、反向代理、Serverless 執行上限都要一起放寬。

**併發與穩定性：**

* 官轉走官方通道，預設約 100 RPM，實際隨平臺總並發動態調整；Default 高峰期偶發 429，可切 `image2Enterprise` 企業分組（1.2x）過渡。
* 2.6-all 在 1K 檔實測 12×2、16×1、8 路併發全部通過、無 429；2K/4K 未做併發壓測，建議先從 4–8 路起觀察尾延遲。2K/4K 偶發 502 `size_not_deliverable`，重試或改用支援尺寸即可。
* 兩條線遇到 5xx 與超時都建議指數退避重試 2 次；429 退避重試。

## 選型場景

> [card] 選官轉 gpt-image-2.6-flare / sunburst
>
> * **欄位與行為要和 OpenAI 官方完全一致**：已有官方 SDK / 官方欄位的專案零改動遷移
> * **要 `quality` 六檔**，尤其是 `xhigh` / `max` 的成品級畫質
> * **要原生 2K/4K 畫素**，印刷、精細紋理、對細節有硬要求
> * **要精確 mask、多圖融合（16 張）、WebP 輸出**
> * **GIF 要可控單幀尺寸，或 SVG 要指定編寫模型並精確核算費用**
> * 可接受按 token 計費的成本浮動，換官方通道的穩定性

> [card] 選 gpt-image-2.6-all（官逆）
>
> * **成本必須封頂**：固定 \$0.025/張，2K/4K 同價，預算好算
> * **批次生產**、資訊圖、營銷物料、電商素材
> * **2K/4K 大圖相容**：要更大畫布，但不需要原生畫素細節
> * **低成本 GIF / SVG**：SVG 不用 `svg.model`，也沒有文本模型費
> * **一次多張（1–4 張）或要 24 小時直鏈 URL**
> * 快速迭代、ChatGPT 原生畫質（1536 以內帶指紋）

## 客戶端呼叫建議

| 配置項 | 官轉 2.6 | `gpt-image-2.6-all` |
| - | - | - |
| **客戶端超時** | `low` ≥120 秒、`medium` ≥240 秒、`high` ≥600 秒、`xhigh` ≥300 秒、`max` ≥600 秒 | ≥600 秒 |
| **重試策略** | 5xx 與超時指數退避 2 次；429 退避 | 同左；502 `size_not_deliverable` 先換尺寸再重試 |
| **併發** | 預設約 100 RPM；高峰切 `image2Enterprise` | 1K 檔 10–16 路起步；2K/4K 先 4–8 路 |
| **返回處理** | 固定 b64，自己 decode；不要傳 `response_format` | b64 或 url；url 需及時轉存，且可能沒有 `size` |
| **尺寸驗收** | 按官方四條約束校驗 | 以響應 `size` 和圖片實際寬高為準；顯式尺寸不匹配會 502 |
| **成本核算** | 記錄 `usage.output_tokens`，按 \$30/1M 折算 | 記錄返回張數 × \$0.025 |
| **令牌型別** | 必須「按量優先」 | 按次計費模型，Default 分組即可 |

```python theme={null}
import base64
import os

from openai import OpenAI

client = OpenAI(
    api_key=os.environ["APIYI_API_KEY"],
    base_url="https://api.apiyi.com/v1",
    timeout=600,
)

# 官轉 2.6：六檔 quality + 原生尺寸
official = client.images.generate(
    model="gpt-image-2.6-flare",
    prompt="極簡風格的精品咖啡海報，突出產品與清晨自然光，預留標題區域",
    size="2048x1152",
    quality="high",
)

# 2.6-all：固定按次價；要直鏈時顯式傳 response_format
reverse = client.images.generate(
    model="gpt-image-2.6-all",
    prompt="極簡風格的精品咖啡海報，突出產品與清晨自然光，預留標題區域",
    size="2048x1152",
    quality="medium",
    response_format="b64_json",
)

with open("coffee-official.png", "wb") as f:
    f.write(base64.b64decode(official.data[0].b64_json))

with open("coffee-reverse.png", "wb") as f:
    f.write(base64.b64decode(reverse.data[0].b64_json))
```

## 常見問題

> [accordion] 只改 model 名就能在兩條通道間切換嗎？
>
> 基礎文生圖和編輯可以共用一套程式碼，但**引數語義並不完全等價**，切換時要做一次歸一：
>
> * `size`：官轉要求 16 倍數 + 總畫素區間；2.6-all 原生檔接受任意整數，2K/4K 是超分
> * `quality`：官轉六檔；2.6-all 只有 auto / medium / high
> * `response_format`：官轉傳了 400；2.6-all 可傳 url
> * `n`：官轉只出 1 張；2.6-all 1–4 張
> * GIF / SVG：欄位要求和邊界不同
>
> 返回的 `b64_json` 兩邊都不帶 `data:` 字首，解碼邏輯可以複用。

> [accordion] 為什麼 2.6-all 便宜這麼多？畫質會差嗎？
>
> 原因有三：**按次計價**覆蓋 1K–4K（官轉按 token 實計，高畫質/大尺寸 token 量急劇上升）；**2K/4K 是超分放大**，不是原生畫素；**quality 檔位更少**。畫質上兩者定位不同：2.6-all 在 1536 以內保留 ChatGPT 網頁版原生畫質與指紋；官轉走官方 API 的原生品質檔位。沒有同提示詞的公開盲評，不做「誰更好」的結論，建議用自己的素材各跑一組對比。

> [accordion] 什麼場景必須用官轉？
>
> 需要以下任一項時，選官轉 `gpt-image-2.6-flare` / `sunburst`：與 OpenAI 官方欄位完全一致、`quality` 六檔（含 `xhigh` / `max`）、原生 2K/4K 畫素、精確 mask、多圖融合（最多 16 張）、WebP 輸出、GIF 單幀尺寸可控、SVG 指定編寫模型並精確核算文本費。

> [accordion] 什麼場景優先選 2.6-all？
>
> 成本必須封頂、批量出圖、2K/4K 大圖相容、低成本 GIF / SVG、一次要 1–4 張、要 24 小時直鏈 URL，或者只是快速迭代草稿——這些場景 2.6-all 的 \$0.025/張更划算。注意它的 2K/4K 是超分，圖更大不等於細節更多。

> [accordion] 2K/4K 怎麼選：原生還是超分？
>
> **要原生細節、印刷級交付、4K 硬要求**：選官轉，原生畫素，但按 token 計費會明顯更貴。**只是要更大的畫布**（海報、大屏、電商長圖）且成本要封頂：選 2.6-all 的超分檔，常見 2K/4K 尺寸可以精確交付，畫質優先控制在 1536 以內的原生檔。

> [accordion] 2.6-all 請求 2K/4K 一定成功嗎？
>
> 不一定。常見尺寸（`2048x2048`、`2048x1152`、`2048x1536`、`3840x2160`、`2880x2880` 等）可精確交付；方形超過 2880、4:1 比例、部分 4K 透明底會失敗（502 `size_not_deliverable` 或 400）。請以響應 `size` 和圖片實際寬高驗收，失敗時換尺寸或重試。

> [accordion] GIF 能指定成片尺寸嗎？
>
> 官轉可以控制單幀尺寸（16 的倍數，且受拼圖預算約束）；2.6-all **不能**，`size` 對 GIF 不生效，只保證幀數與時長，成片畫素由上游決定。要固定 GIF 尺寸，目前只能在客戶端拿到檔案後自行縮放/裁切。

> [accordion] SVG 兩個通道怎麼選？
>
> 要指定編寫模型、和 OpenAI 官方欄位一致、能接受文本模型另計費：選官轉（必須傳 `svg.model`，否則 400）。要便宜、少欄位依賴、`viewBox` 可以做大：選 2.6-all（不需要 `svg.model`，按次 \$0.025）。

> [accordion] complexity 引數可以用嗎？
>
> `complexity` 是 2.6 新增的規劃控制引數。官轉已通過原生透傳支援官方三檔（`low` / `medium` / `high`，省略時預設 `high`），不單獨收費，較高檔位可能增加耗時；**2.6-all 不支援該引數**。建議先用同一提示詞對比結果，再決定生產檔位。

> [accordion] 可以兩個通道同時接入做兜底嗎？
>
> 可以，而且推薦。常見做法：按成本或容量主用一條，另一條做兜底——官轉 Default 高峰期 429 時切 2.6-all；2.6-all 內容策略或尺寸失敗時切官轉。兩邊都走 `/v1/images/generations` 與 `/v1/images/edits`，業務層把響應欄位和引數做一次歸一即可。

## 相關文件

* [GPT-Image-2.6 / 2.5 / 2 官轉概覽](https://docs.apiyi.com/zh-Hant/api-capabilities/gpt-image-2/overview.md) - 官轉五款模型完整接入文件
* [GPT Image 2.6 新能力](https://docs.apiyi.com/zh-Hant/api-capabilities/gpt-image-2/gpt-image-2-6.md) - `complexity`、SVG、GIF、標記引導編輯與 Playground
* [GPT-Image-2.6-All 概覽](https://docs.apiyi.com/zh-Hant/api-capabilities/gpt-image-2-all/gpt-image-2-6-all.md) - 官逆 2.6 全量引數、尺寸與錯誤碼
* [GPT-image-2.5 / 2 官轉 vs 官逆](https://docs.apiyi.com/zh-Hant/api-capabilities/gpt-image-2/vs-gpt-image-2-all.md) - 上一代完整對比
* [輸出格式與背景引數互斥條件](https://docs.apiyi.com/zh-Hant/faq/gpt-image-output-format-background.md) - 官轉 2.6 的 transparent × png / jpeg / webp / gif / svg 矩陣
* [SVG 推理檔位怎麼選](https://docs.apiyi.com/zh-Hant/faq/gpt-image-svg-reasoning-effort.md) - 官轉 SVG 的編寫模型與 `svg.reasoning.effort`
* [圖片 API 呼叫須知與最佳實踐](https://docs.apiyi.com/zh-Hant/api-capabilities/image-api-best-practices.md) - 超時、斷連與重試
* [模型價格總表](https://docs.apiyi.com/zh-Hant/models/index.md) - 兩款官轉與 2.6-all 的即時價格


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.