从 GPT Image 2.5 迁到 2.6：新参数、新格式与文档差异须如实核对
OpenAI 于 2026 年 11 月 4 日发布 Images 2.6，API 侧提供 gpt-image-2.6-flare 与 gpt-image-2.6-sunburst。Changelog 摘要为：可调 complexity、SVG 生成、动画 GIF 生成，并为受支持的 GPT Image 2.5 与 2.6 增加 markup 引导编辑。产品公告称生成速度较此前平均提升约 50%，Flare 在低质量档可约六秒出图，Sunburst 在中高质档强调细节与编辑一致性。迁移的关键不是改一个 model 字符串，而是弄清哪些是 2.6 新增、哪些在 2.5 已部分可用，以及指南正文示例与模型页端点表是否一致。
👉 在 PoYo 体验 GPT Image 2.6 API：查看按张价格与在线体验。
相对 2.5 的能力增量
据图像生成指南的「GPT Image 2.6」专节，Flare 与 Sunburst 均通过 Image API 支持：complexity 控制、markup 引导编辑、SVG 输出与动画 GIF 输出。指南正文的多数代码示例仍以 GPT Image 2.5 模型 ID 演示通用生成与编辑流程，并写明「下列既有示例使用 GPT Image 2.5」——阅读时勿把示例中的 gpt-image-2.5-* 误当成 2.6 默认值。
| 维度 | 2.6 侧文档要点 |
|---|---|
complexity | low/medium/high；省略时默认为 high；与 quality 独立；不另收费 |
| GIF | 仅 generations；frame_count、frame_duration_ms；不可流式 |
| SVG | 仅 generations；n=1；不可流式；不可作 edits 输入/输出 |
| markup | edits 端透明叠加层；不可与 mask 或 prompt_rewriter 并用；2.5/2.6 均支持 |
| 双档 | Flare 快迭代；Sunburst 细节与编辑一致性 |
图像提示指南给出迁移清单：保存基线提示与样张；原 2.5 Flare 先测 2.6 Flare，原 2.5 Sunburst 先测 2.6 Sunburst；首次对照固定提示、参考图、尺寸、质量与输出格式，complexity 先留模型默认；一次只改质量或复杂度中的一项；按工作流分批放量并跟踪延迟、失败、重试与单张接受成本。编辑请求应省略旧版 input_fidelity；GPT Image 2.6 不支持 reasoning.summary。
Responses API：指南示例与模型页须分开读
图像生成指南仍以 Responses API 说明多轮对话式图像工具，示例中的图像工具模型字段使用 2.5 标识符。与此相对，GPT‑Image‑2.6 Flare 与 Sunburst 模型页的 Endpoints 表均将 v1/responses 标注为 Not supported，同时标明 v1/images/generations 与 v1/images/edits 为 Supported。2.6 专节亦强调 complexity、markup、SVG、GIF「通过 Image API」提供。
因此，生产迁移应默认：把 2.6 接到 Image API 的生成与编辑端点；不要假设可以把 2.5 时期 Responses 工具配置里的模型字段原样换成 2.6 ID。若业务强依赖多轮对话式编辑，须以模型页端点表为最终依据重新核对文档是否已更新，而不是凭指南中仍以 2.5 为例的 Responses 段落外推。这是文档层面的真实差异，不是「谁写错了」的口头争议——接入方应以模型页为准做配置门禁。
迁移验收建议
将验收拆成三层。能力层：在业务语料上验证 GIF/SVG/markup/complexity 是否真正缩短迭代或降低误改。质量层：同一提示对照 2.5 与 2.6 对应档，检查文字、身份、产品几何与透明通道。接入层：确认组织验证、safety_identifier、错误码处理（审核拦截勿盲目重试），以及配置中不出现未支持的 Responses 绑定。定价上，本稿可核对的 2.6 两档单价一致，勿假设「更快档一定更便宜」。
实务上还应注意参数习惯的变化。2.5 工作流若从未显式设置 complexity，迁到 2.6 后若继续省略该字段，将落到默认的 high，可能拉长编辑延迟并带来多余改动；官方对多数编辑任务的建议反而是显式使用 low。GIF 与 SVG 仅存在于 generations，编辑管线若仍假定「任意格式可来回改」，会在 2.6 上直接撞墙。Markup 虽同时覆盖受支持的 2.5 与 2.6，但与 mask、prompt_rewriter 互斥，迁移脚本需做字段互斥校验。提示指南还提醒：编辑请求省略 input_fidelity；2.6 不支持 reasoning.summary。这些都是「能编译通过却在运行期失败或行为漂移」的常见坑。
对照实验应固定尺寸、质量与输出格式，一次只动模型 ID 或 complexity 之一，并保存中间样张。若业务同时使用 ChatGPT 产品侧的 Images 2.6 与 API，须分开记账：产品名不等于 model ID，配额与验证状态也不自动同步。放量策略上，先小流量验证失败率与单张接受成本，再扩大默认路由；保留 2.5 回滚窗口，直到业务语料上的延迟与质量曲线稳定。
结语：2.6 相对 2.5 的可陈述增量是速度与双档强化，以及 complexity、GIF、SVG、markup 所构成的控制面。迁移成功与否，取决于是否按提示指南做同条件对照，以及是否正视「指南仍示 2.5 Responses、模型页标 2.6 不支持 Responses」这一文档事实并以模型页为生产依据。