多数日常生图任务，可以先用 Flare；对商品细节、品牌元素和局部修改有严格要求的图片编辑，优先把 Sunburst 纳入对比。 这是基于 OpenAI 在 2026 年 9 月 8 日发布时的定位：Flare 是面向多数应用的默认选择，Sunburst 更强调编辑精度，代价是更长的生成时间。OpenAI 官方发布说明
这个区别不意味着“Flare 只能生图、Sunburst 只能修图”。两者都能根据文字生成图片，也都接受图片输入并执行编辑。真正需要判断的是：你的任务能容忍多少变化，错误细节会增加多少返工，以及使用者愿意等多久。
本文依据 2026 年 9 月 9 日核验的官方文档整理，未进行两款模型的 API 画质、延迟或计费实测。下文的商品编辑案例是选型时可使用的检查方法；配图用于说明任务，不是两款模型的实测结果。
先看交付要求，再选模型
如果你要为一篇文章生成配图、探索一组社交媒体视觉方向，通常会先判断主体、风格和构图是否合适。画面中的杯子换了一种把手形状，未必影响采用。此时可以从 Flare 开始，把迭代速度纳入选择。
如果输入的是客户已经确认的商品图，要求只换瓶盖颜色，那么瓶身比例、商标位置和标签文字就是不能随意变化的部分。画面再漂亮，只要商品结构被改了，也可能无法交付。这类任务更贴近 Sunburst 的官方定位，但最终仍要检查它在你的参考图上是否减少了这些错误。Sunburst 模型说明
| 你的实际任务 | 建议的起点 | 决定是否继续使用的检查项 |
|---|---|---|
| 从文字探索插画、封面或宣传创意 | 先用 Flare | 主体和风格是否符合需求，迭代等待是否可接受 |
| 日常配图批量生成，允许适度视觉变化 | 先用 Flare | 实际采用率、总用量和交付时间 |
| 改商品图的某一处，其他商品细节必须保留 | 重点比较 Sunburst | 指定部位是否改对，非目标区域是否出现意外变化 |
| 同一张品牌素材连续修改背景、道具和布局 | 两者用相同修改要求比较 | 每轮修改后，前面确认的内容是否仍保留 |
| 当前 Flare 结果已经符合交付要求 | 继续使用并记录表现 | Sunburst 是否带来足以抵消额外等待的收益 |
这里的建议是试用顺序，不是已测出的胜负。OpenAI 将 Flare 描述为面向日常高质量生图的快速模型；它同样支持图片编辑，因此简单改背景或更换整体风格不必一开始就排除 Flare。Flare 模型说明
“编辑更精确”应该检查什么
以一张饮料瓶商品图为例，制作方提出：“把蓝色瓶盖换成哑光黑色，其他部分保持原样。”评估时应拆成两个独立问题。
第一个问题是该改的有没有改对：颜色是否变成黑色，材质是否表现为哑光，修改是否覆盖完整瓶盖。第二个问题是不该改的有没有保住：瓶盖螺纹和瓶口结构、瓶身轮廓、标签上的品牌名称、容量文字，以及原有构图是否仍然符合要求。只看整体观感，容易漏掉后一组问题。
可以把编辑要求写成这样：
“仅把瓶盖的蓝色表面改为哑光黑色。保留瓶盖外形、螺纹和瓶口位置；保留瓶身轮廓、标签文字和图案、画面比例及背景。不要增加新的标识或装饰。
这段文字用于让修改要求可检查，不保证模型一定遵守。检查结果时，把原图和完整输出并排查看；标签、接缝、透明边缘等关键位置需要放大。用于商品详情页的图片，应按实际发布尺寸再看一次，确认缩放后仍能读清必要信息。
掩膜也不能替代这一步。官方文档说明，GPT Image 的掩膜通过提示引导编辑，并不保证严格遵守掩膜形状；文字渲染、主体一致性和复杂构图仍存在限制。选择 Sunburst 不能据此承诺“区域外像素完全不变”或“品牌文字绝不会出错”。掩膜编辑说明、已知限制
如果“完全不变”指逐像素保留，把生成结果作为局部素材再用常规图片工具合成，通常更容易控制交付边界。模型负责提供可用的修改素材，最终商品信息和固定元素由制作流程核对。
model 与 quality 要分开决定
两款模型都支持 low、medium、high、xhigh、max 和 auto，默认是 auto。model 决定使用哪款模型，quality 决定本次生成的质量档位。把 Flare 从 high 改成 max，调用的仍然是 Flare；它不会因此切换到 Sunburst。官方尺寸与质量参数
第一次做模型对比时，建议把尺寸与质量写明确，例如两者均使用 1536x1024、high，并提交同一份提示词和参考图。这样可以减少设置差异对判断的干扰。相同参数也不保证画质、耗时或用量一致，它只是一个容易复核的比较起点。
确认哪款模型更适合任务后，再调整质量档位。草图和方向探索可以从官方建议的 low 开始；准备交付的素材则比较更高档位是否改善了实际缺陷。如果问题是主体理解错误或不该改的标签被改写，不能仅凭提高档位就认定问题已解决。
分辨率也不是两者的主要区别。二者都支持相同约束下的自定义尺寸；没有必要把“需要横图”当作改用 Sunburst 的理由。对比时优先使用业务真实需要的尺寸，而不是为了展示模型能力一律开到最大。
API 接入时，具体改哪个 model
通过 Image API 调用时，在生成或编辑请求的 model 字段直接指定以下一个值：
| 模型 | 可调用的模型 ID | 当前带日期的快照 |
|---|---|---|
| Flare | gpt-image-2.5-flare | gpt-image-2.5-flare-2026-09-08 |
| Sunburst | gpt-image-2.5-sunburst | gpt-image-2.5-sunburst-2026-09-08 |
两款模型的当前快照和接口支持可在 Flare 模型页 与 Sunburst 模型页 核对。“GPT Image 2.5”是系列名称，接入时要使用具体 ID。做可复核的对比时，记录实际使用的模型 ID；若需要固定本轮版本，可使用对应的日期快照。
如果你使用 Responses API，顶层 model 选择的是支持图片工具的主模型；Sunburst 或 Flare 要放在 image_generation 工具的 model 字段中。单次生成或编辑可以使用 Image API；需要在对话中连续修改图片时，Responses API 提供多轮编辑能力。图片生成接口指南
接入后要确认拿到了可以打开的图片文件，而不仅是请求成功。Image API 的常见返回字段是 data[0].b64_json，需要解码并保存。账户是否有模型权限、是否需要组织验证和当前速率限制，应在自己的 API 项目中确认；ChatGPT 中能生成图片不等于该项目已经能调用这两个 ID。
速度和价格，哪些结论现在还不能下
“Flare 延迟降低 50%”不是说它比 Sunburst 快 50%。 官方发布的 API 比较基准是上一代 GPT Image 2。它不能换算成任意提示词下固定多少秒，也不能作为两款 2.5 模型之间的延迟差。官方发布中的速度说明
你的使用者等待多久，还包含上传参考图、请求处理、下载图片和重试。评估交互体验时，应从开始提交到完整图片可用计时，并观察常见请求与较慢请求各是什么表现。不要只挑最快一次作为服务承诺。
价格方面，2026 年 9 月 9 日的官方 Standard 费率中，Sunburst、Flare 与 GPT Image 2 的对应 token 单价相同：未缓存文本输入为每百万 token 5 美元，未缓存图片输入为 8 美元，图片输出为 30 美元。把旧模型的 Batch 价格与新模型的 Standard 价格放在一起，不能得出“2.5 定价翻倍”的结论；当前 Batch 表也未列出两款 2.5 模型。OpenAI 官方价格表
相同单价不等于每张图费用相同，更不等于每张实际采用的图片成本相同。 实际用量受输入和生成设置影响，而返工会继续消耗费用。完整的质量档位估算、参考图输入、缓存和预算计算，见 GPT Image 2.5 API 价格说明。本页不把价目表当作“哪款更便宜”的实测结果。
用自己的任务做最后决定
先从日常工作中选取有代表性的任务，而不是只用一条容易出好图的提示词。新图生成、商品局部修改和连续编辑应分开记录，因为同一款模型在不同任务里的价值可能不同。提交前写清采用标准；例如商品编辑必须同时满足“瓶盖颜色正确”和“品牌标签无变化”，不能事后为了保留某张好看的图而放宽要求。
比较时保存相同的输入、显式尺寸与质量、模型 ID、完整输出、端到端耗时和响应 usage。对图片按预先写下的要求判断是否采用，并简短记录不采用的原因。若做重试，也保留这些请求和实际费用，避免只统计成功结果。
可以用一个直接关系到交付的指标看成本：
text每张实际采用图片的 API 成本 = 本组任务实际产生的 API 总费用 ÷ 最终采用张数
人工修图时间单独记录，不要隐含在这个美元数里；如果没有任何结果被采用，就记录采用数为零，不能给出一个有意义的平均单图成本。使用 Responses API 时，还要把主模型费用纳入对应工作流的总费用。
最后按任务分配模型：Flare 能稳定满足要求，就继续用于这类日常任务；Sunburst 若在关键编辑中减少意外改动、反复生成或人工修补，再把这些任务交给它。如果两者都无法保住必须准确的商品信息，就调整编辑和合成流程。对团队最有用的结论，是哪一种任务应该调用哪一个模型，以及交付前还必须检查什么。
