GPT Image 2.6 拆解：complexity 分开规划和渲染，GIF、SVG 怎么做

blackappleD
0 阅读9分钟

OpenAI 11 月 4 日发布了 Images 2.6，API 里对应 GPT-Image-2.6 Sunburst 和 Flare 两款模型。新闻稿主打「快 50%」和「能做 GIF」，但对开发者来说，更值得看的是新参数 complexity：它把「出图前想多少」和「画得多精细」拆成了两个独立设置。同日上线的标注编辑、SVG 和 GIF 输出，也都跟「先规划、再渲染」有关。

它是什么

项目内容
发布时间2026-11-04（官方公告、API changelog、系统卡同日）
产品形态ChatGPT 和 Codex 里叫 Images 2.6，所有订阅档位可用；API 里是两款模型
API 模型gpt-image-2.6-sunburst（细节和多轮编辑一致性）、gpt-image-2.6-flare（速度，海报和产品图排版）
端点v1/images/generations、v1/images/edits；模型页显示 Responses API 不支持
新能力complexity（low / medium / high，默认 high）、markup 标注编辑、SVG 输出、GIF 输出
速度官方称比之前快 50%；Flare 在 quality: low 时最快约 6 秒一张
价格按 token 计费，和 2.5 相同（文本输入 5 美元 / 百万 token，图像输出 30 美元 / 百万 token）；complexity 不单独收费
ChatGPT 侧GIF 生成（可调速度、编辑单帧）、保存参考图反复使用
来源标记C2PA 元数据 + Google DeepMind 的 SynthID 隐形水印（2.5 时已有）

原理：把「想清楚」和「画精细」拆成两个旋钮

complexity 和 quality 分别管什么

API 文档的说法是：complexity 控制模型渲染前规划多少；quality 控制渲染质量，2.5 / 2.6 支持 low、medium、high、xhigh、max。

prompt + 输入图 + 标注层
        │
        ▼
┌──────────────────────┐
│ 规划阶段  complexity   │  画面里有什么、放哪、元素之间什么关系
│ low / medium / high  │  （系统卡称为 configurable reasoning effort）
└──────────┬───────────┘
           ▼
┌──────────────────────┐
│ 渲染阶段  quality      │  细节多少、保真度多高
│ low … xhigh / max    │
└──────────┬───────────┘
           ▼
     PNG / JPEG / WebP / SVG / GIF

系统卡把它叫作「configurable reasoning effort」，说白了就是图像模型的推理档位。文本模型早就有这个：难题多想，简单题少想。图像这边以前「想」和「画」绑在一起，quality 调高，规划和渲染一起变慢。

为什么要拆开

很多任务只需要其中一样。改背景、改招牌上的字，构图已经定了，但输出可能要高清，适合低 complexity + 高 quality。信息很密的海报、物体位置关系复杂的场景，难点在构图，适合高 complexity，quality 可以先放低出草稿。官方建议也是这样：多数编辑用低 complexity，元素和约束多时再试 medium 或 high。

想得越多，改得越多

文档有一句容易被忽略：complexity 越高，延迟越高，也可能引入你没要的改动。 官方示例是同一提示词、同为 medium quality，Sunburst 在三档下画的剪纸风足球夺冠场景：

同一提示词在 low / medium / high 三档 complexity 下的输出

low 和 medium 把 CHAMPIONS 横幅放在前景、球衣是红色；到了 high，横幅挂上看台，球衣换成蓝色。我的理解是，规划多了，模型会更主动地重排画面，从零生成时是好事，只改一处时就是风险。

参数省略时默认是 high。以编辑为主的业务，升级后最好显式写 complexity: "low"，不然可能比 2.5 改得更多、跑得更慢。

三个新能力

标注编辑：用红圈代替遮罩

以前局部编辑靠 mask，文档也承认 GPT Image 的遮罩「完全基于提示词」，不一定严格按形状来。2.6 在 v1/images/edits 加了 markup：另传一张透明背景的 PNG，在上面画圈、画箭头，再在 prompt 里说改成什么、保留什么。支持的 2.5 模型也能用。

官方示例：红圈标出花瓶，Flare 把它改成钴蓝色

文档里的要求：标注层和第一张输入图宽高一致，不能把标注直接画在原图上；标注只作用于第一张图，其余当参考图；两者各自最多 16,777,216 像素，标注文件不超过 50 MB；不能和 mask、prompt_rewriter 同时用。

标注比遮罩能表达的更多，除了位置，还能画个大概形状、标个方向，正好对上系统卡说的「对草图和标注的响应更好」。但它同样不保证像素级精确。

SVG：先画位图，再转矢量

在生成端点设 output_format: "svg"。文档写明：API 先生成一张参考图，再用它产出 SVG，quality 控制的是这张参考图。

所以 SVG 不是模型逐 token 写出来的 XML，而是「先画再描」。画面质量和位图一致；限制也来自这里：n 只能是 1，不支持流式、partial images、output_compression、prompt_rewriter；编辑端点不能输出 SVG，SVG 也不能当编辑输入；返回的是静态矢量，不含脚本、外部资源和内嵌位图。适合图标、logo、简单插画。

GIF：一次请求出一整段循环

设 output_format: "gif"，用两个参数控制动画：

参数取值默认
frame_count2–64 帧9
frame_duration_ms每帧 20–2000 毫秒，按 10 毫秒取整200
sizeauto 或「宽x高」，都要是 16 的倍数auto

size 指每一帧的尺寸，帧数、单帧尺寸和动画数量要一起落在整次请求的像素预算里。按文档字段写的请求（本文未实测，以官方文档为准）：

import base64
from pathlib import Path

from openai import OpenAI

client = OpenAI()
result = client.images.generate(
    model="gpt-image-2.6-sunburst",
    prompt=(
        "A monkey in a green coat lifts a glowing lantern, blinks, "
        "and lowers it again. Seamless loop."
    ),
    output_format="gif",
    # SDK 版本较旧、还没有这两个字段时，用 extra_body 透传
    extra_body={"frame_count": 9, "frame_duration_ms": 200},
)

Path("lantern.gif").write_bytes(base64.b64decode(result.data[0].b64_json))

官方示例 GIF 拆出来的 9 帧（Sunburst，1.8 秒回到起始姿势）：

官方示例 GIF 的 9 帧

帧与帧之间人物、背景为什么不跑？官方没公开。线索有两个：一是各帧共享整次请求的像素预算；二是公告里 OpenArt 的示例提示词，要求模型画「一张 3 列 2 行、6 格等大的动画精灵图，固定机位、同一个角色」。我推测 GIF 很可能是在一张大画布上把所有帧一起规划、一起画，再切成帧，一致性来自「同一张图里的元素本来就一致」。这只是推测，没有官方确认。如果成立，帧越多每帧像素越少，它适合表情包、吉祥物、加载动画，做不了视频。

安全：动起来的图更难审

系统卡用 3,077 条专门构造的违规请求，对比 2.6 和 2.5 基线：

模型生成结果本身安全不安全但被拦下不安全且没拦下
2.5 Sunburst（基线）76.15%21.94%1.92%
2.6 Sunburst75.50%22.78%1.72%
2.5 Flare（基线）78.36%20.15%1.49%
2.6 Flare75.04%*22.81%*2.14%

星号表示和基线相比统计显著。2.6 Flare 自己画出违规内容的比例显著上升，被审核拦下的也更多；漏网的从 1.49% 到 2.14%，没标显著。OpenAI 的结论是整体与 2.5 持平。这组题是刻意刁难的样本，不代表线上比例。

GIF 专项：系统卡说动图有静态图没有的风险，比如带性暗示的动作、跨帧拼出的有害含义，部分类别在 GIF 上拦得更宽。在一组对抗 GIF 上，审核召回率总体 77.7%，各类别从 77.5%（自伤）到 96.6%（暴力活动）。OpenAI 自己写了「和动作相关的违规仍然难以检测」。

还有个细节：评估图像模型的网络安全等危险能力时，OpenAI 让模型生成一张带可见推理草稿和最终答案的图，只给图里的最终答案打分。结论是两款都没到 Preparedness 框架的 High 阈值。

对比

GPT Image 2.5GPT Image 2.6Google Nano Banana 2.1
发布2026-09-082026-11-042026-10-06（据 The Decoder 等报道）
规划档位无独立参数complexity 三档未见同类参数
局部编辑mask；markup 11-04 补上mask + markup对话式编辑
矢量 / 动图无SVG、GIF（2–64 帧）只出静态图（据第三方规格整理，未在官方核实）
速度—官方称快 50%；Design Arena 测得 Flare 约 2.6 倍、Sunburst 约 1.15 倍（据 OrcaRouter 转述）—
排名Artificial Analysis 文生图榜第一（1,224，11-05，据 OrcaRouter）OpenAI 引用 Design Arena 称 Sunburst 登上 Image Arena 第一，暂无公开分数；AA 未收录AA 文生图榜第四（1,176，同上）

「快 50%」是官方说法，第三方倍数差别很大：Flare 提速明显，Sunburst 不多。2.6 目前没有独立公开分数。Google 是否有类似规划档位，我没找到官方说明。

适用场景和局限

适合的：

  • 交互式编辑：用户圈一下、说一句「这里换蓝色」。markup + Flare + 低 complexity 是最直接的用法。
  • 设计素材：logo、图标直接出 SVG，路径能否直接进设计系统要自己验。
  • 短循环动画：吉祥物、加载动画、表情包。公告里的 Town 把动画角色放在输入框上方当「正在输入」提示。
  • 复杂海报和信息图：高 complexity 先排好布局，quality 先低后高。

要注意的：

  • 默认 high complexity，编辑任务不调低可能更慢、改到不该改的地方。
  • GIF 不是视频，最多 64 帧且共享像素预算；编辑端点不能输出 GIF。
  • SVG 和 GIF 都不支持流式和 prompt_rewriter，做实时预览要另想办法。
  • 2.6 只走 Image API，用 Responses 图像工具的 Agent 暂时用不上。
  • 文档列的老限制还在：复杂提示词最长约 2 分钟，文字排版和跨次生成的角色一致性仍可能出错。
  • GIF 审核召回率 77.7%，UGC 平台自己那层审核最好也覆盖动图。

我的判断

2.6 画得比 2.5 好多少，现在说不准，独立榜单还没收录。但 complexity 的方向我认为是对的，它很可能成为图像模型的标准接口。

文本模型用了一年多让大家习惯推理档位：不是每个问题都值得多想。图像模型一直只有 quality 一个参数，同时管构图和像素，结果要么简单编辑也付出完整的规划开销，要么复杂海报画得清楚却排得乱。拆开以后，「改一块招牌」和「从零画一张信息图」终于能分开处理。

不过官方示例已经说明，规划多了模型会更主动地改画面。默认值设成 high，对编辑类产品不太稳妥，接入时要自己调。

GIF 和 SVG 看着像小功能，背后是同一个方向：从「一次生成一张位图」变成「先规划画面，再按需输出成不同形态」。SVG 是先出位图再转，GIF 很可能是一张画布同时规划多帧（推测）。照这条路走下去，下一步大概是更长的帧序列和可编辑的分层输出，图像模型和视频模型、设计工具之间的界线会越来越模糊。

参考资料

avatar
文章
阅读
粉丝