> ## 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/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/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/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/api-capabilities/gpt-image-2/overview.md) - 官转五款模型完整接入文档
* [GPT Image 2.6 新能力](https://docs.apiyi.com/api-capabilities/gpt-image-2/gpt-image-2-6.md) - `complexity`、SVG、GIF、标记引导编辑与 Playground
* [GPT-Image-2.6-All 概览](https://docs.apiyi.com/api-capabilities/gpt-image-2-all/gpt-image-2-6-all.md) - 官逆 2.6 全量参数、尺寸与错误码
* [GPT-image-2.5 / 2 官转 vs 官逆](https://docs.apiyi.com/api-capabilities/gpt-image-2/vs-gpt-image-2-all.md) - 上一代完整对比
* [输出格式与背景参数互斥条件](https://docs.apiyi.com/faq/gpt-image-output-format-background.md) - 官转 2.6 的 transparent × png / jpeg / webp / gif / svg 矩阵
* [SVG 推理档位怎么选](https://docs.apiyi.com/faq/gpt-image-svg-reasoning-effort.md) - 官转 SVG 的编写模型与 `svg.reasoning.effort`
* [图片 API 调用须知与最佳实践](https://docs.apiyi.com/api-capabilities/image-api-best-practices.md) - 超时、断连与重试
* [模型价格总表](https://docs.apiyi.com/models/index.md) - 两款官转与 2.6-all 的实时价格


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