GPT Image 2.5 Flare 和 Sunburst 怎么选？场景与成本对比
对通过 EvoLink 构建创意 SaaS 或电商图片流水线的团队来说，两类任务的差别很具体：布局草稿不合格，可以再试一次；商品标签被悄悄改动，则可能让整张看起来不错的图片失去交付价值。即使用同一套图像 API，也应为它们设置不同的验收规则。
拿到结果后，按以下顺序决策：
- 保留 Flare： 它能满足任务的硬性要求和交付限制，而 Sunburst 带来的改善不足以抵消额外费用或等待时间。
- 为某类任务选择 Sunburst： 配对测试表明，它能解决商品细节被改动等关键失败，并且仍在交付预算内。其他任务可以继续使用原来的配置。
- 保留现有流程或转人工编辑： 两款模型都不达标，或样本太少、差异尚不足以支持切换。若要求商品完全不变，可以把原商品抠出，合成到单独生成的背景上。
Flare 与 Sunburst 的核心区别
max 也不会把一个模型变成另一个。它们有各自的模型 ID，同时支持下表列出的官方画质选项。Flare 模型文档、Sunburst 模型文档| 决策维度 | Flare | Sunburst |
|---|---|---|
| 官方模型 ID | gpt-image-2.5-flare | gpt-image-2.5-sunburst |
| OpenAI 定位 | 日常生成、快速迭代，大多数应用的默认选择 | 最重视精度的生成与编辑任务 |
| 建议从哪类任务开始评估 | 验收规则明确、需要频繁出草稿和变体的任务 | 必须保留已确认细节的编辑任务 |
| OpenAI 画质选项 | low、medium、high、xhigh、max、auto | low、medium、high、xhigh、max、auto |
| 输入与输出 | 文本和图像输入；图像输出 | 文本和图像输入；图像输出 |
| 标准 token 单价 | 与 Sunburst 公布的费率相同 | 与 Flare 公布的费率相同 |
| 需要在自己的任务中验证什么 | 更快迭代能否同时产生足够多的合格结果 | 验收率的提升是否值得额外等待 |
low 至 max），默认 medium；官方表格里的 auto 不是 EvoLink 的画质选项。详见 Flare 参数概览 与 Sunburst 参数概览。从“图片怎样才算可用”开始选模型
先找出生成之后最难补救的要求。布局草稿可能最重视信息层级，商品图可能最重视标签的形状和位置。比较输出前就把要求写下来，否则很容易被漂亮的风格吸引，忽略任务本身没有完成。
以下起点是把 OpenAI 定位应用到常见任务后的评估建议，需要用自己的素材验证。
| 工作流 | 优先评估 | 什么算通过 | 什么时候重新考虑 |
|---|---|---|---|
| UI 概念图与落地页草稿 | Flare，同时保留 Sunburst 对照组 | 层级正确、标签可读、必需参考元素齐全、构图可用 | 其他模型或配置持续减少布局修正 |
| 多种尺寸的社交素材 | Flare | 文案准确、品牌特征可识别、所需尺寸下的裁切可用 | 反复被拒的结果抵消了延迟或费用优势 |
| 商品图更换背景 | Sunburst，与 Flare 配对 | 商品轮廓、颜色、标签和确认过的细节均可接受 | 任一模型改动了受保护细节；交付前必须审核 |
| 人物融入新场景 | 两者使用同一组参考图 | 身份特征、光线、纹理与场景一致性通过审核 | 好看的样图在整组测试中无法通过身份或纹理检查 |
| 连续多轮局部编辑 | Sunburst，与 Flare 配对 | 先前修改得到保留，未修改区域仍可接受 | 累积偏移已需要回到早先验收通过的图片 |
| 海报与透明背景品牌素材 | 两者都指定明确的输出设置 | 文字准确、边缘可用、构图正确、透明度满足要求 | 提高画质后仍无法满足具体交付要求 |
两个任务案例：从输入素材走到选型决定
下面用不同验收方法，把 Flare 的日常生成定位与 Sunburst 的编辑重点落到具体任务上。这些案例不能预测任何一款模型的通过率。
任务一：可以交给设计师的 UI 草稿
将自己的参考素材配合以下提示词使用：
Create a desktop dashboard concept using the attached wireframe.
Preserve its four regions: navigation, upload, job queue, usage summary.
Use these labels exactly: "Upload images", "Queue", "Usage", "Settings".
Keep the supplied logo unchanged. Use a neutral background and teal accents.
Do not add features, pricing cards, or navigation items.
The deliverable is a visual design reference, not working interface code.先审核必需内容，再评价视觉风格：
| 检查项 | 通过条件 | 拒绝条件 / 下一步 |
|---|---|---|
| 信息架构 | 四个区域与必需控件均存在 | 缺少上传区或队列：判失败，检查参考图与提示词是否一致 |
| 文案与品牌 | 标签准确，Logo 可用 | 标签或 Logo 被改动：判失败；考虑在设计工具里放入准确文字和 Logo |
| 交接可用性 | 层级与间距可以直接实现，无需重新设计整个页面 | 好看但结构混乱：记录为布局失败 |
这是一个出草稿、反复迭代的任务，因此先从 Flare 开始。如果它满足这些规则，而 Sunburst 主要改变了审美风格，那么在实测交付成本或延迟更优时，可以保留 Flare。如果 Flare 反复遗漏必需区域，而 Sunburst 在对照组中持续保留这些区域，可以考虑让 Sunburst 处理这类需求。单独一张漂亮的 Sunburst 图片不足以证明这种规律。
如果两款模型都做不好准确排版，将构图生成与文字放置拆开处理，不要只是一再提高画质。这个要求可能更适合由设计工具完成。比较最终交接成本时，也要计入这部分收尾时间。
任务二：更换背景，同时保留商品原样
Replace the background of the attached product photograph with a light
stone surface and a warm off-white wall. Match the reference background's
lighting. Add a natural contact shadow beneath the bottle.
Preserve the bottle shape, cap, label lettering, logo, and liquid color.
Do not add props, alter the camera angle, crop the bottle, or redesign it.这里把 Sunburst 作为第一个候选，因为编辑精度是核心要求。同时保留 Flare 对照组：编辑导向的定位，并不能证明每次简单换背景都必须使用 Sunburst。
接着测试一个短编辑序列：调暖墙面颜色、柔化阴影、移除背景上的干扰痕迹。本任务要求每个分支连续编辑三次，并保存每张中间图。每一步都复查受保护细节，也要确认先前要求的修改仍然保留。只有最终交付图通过完整清单，这条编辑序列才算通过。
比较每张可用图片的成本
usage，因为消耗取决于模型和设置。官方输出估算器覆盖输出成本，完整请求还可能包含输入费用。使用 Responses API 时，还要计入主模型的用量。OpenAI 成本与延迟说明本次比较采用以下定义：
每张可用图片成本 =
整批评估中实际发生的生成与重试总费用
/ 通过验收规则的图片数量对于编辑会话，分母应计入通过验收的最终交付图，而不是每张中间图；分子要包含所有步骤和重试的费用。如果整批没有合格交付图，应报告为失败，该单位成本未定义，不能记成零。先单独记录审核与修复人工成本，再将其加入总交付成本对比。
成本算例：何时值得接受更高的整批账单
| 示例批次 | 任务数 | 总费用 | 最终合格图数 | 每张可用图片成本 |
|---|---|---|---|---|
| Flare 示例 | 20 | $4.00 | 10 | $0.40 |
| Sunburst 示例 | 20 | $6.00 | 18 | 约 $0.33 |
在这组假设中，Sunburst 的账单高出 50%，但每张可用图片的成本约低 17%。不过，只有延迟及其他交付要求也通过，它才是更合适的配置。
还可以算出持平点：总费用为 $6 时，Sunburst 需要 15 张合格图，才能持平 Flare 的 $0.40；至少 16 张才更划算。如果另一个 Flare 配置用同样的 $4 得到 16 张合格图，Flare 的单位成本变成 $0.25，结论就会反转。实际改变配置也可能改变账单，所以必须重新计算费用和合格图数量，不能假设费用总是不变。
这也是相同 token 费率无法直接决定选型的原因。需要同时比较合格输出这一分母和完整账单。对于超时或失败请求，要按供应商计费规则核对，既不能默认失败免费，也不能默认一定重复扣费。
画质档位需要单独比较
auto 会引入另一个变化因素；不同模型使用同名档位，也不证明计算量、视觉质量或总费用相同。官方指南按模型记录 token 估算，并建议用实际 usage 核对消耗。图像生成指南先在相同显式设置下比较，再针对观察到的失败测试另一个画质档。例如 UI 配置遗漏必需区域，可以分别检查修改提示词、提高画质或换成 Sunburst 能否解决问题。一次只改一个变量。确定配置后将它固定，再用新的任务需求验证，然后才采用；用同一批样本同时选配置和验证，可能高估改善幅度。
max”的规则。标签拼错、指令不完整、参考图不合适或裁切错误，都需要先定位原因。提高画质只是一种待测试的改进手段，不能代替对失败原因的理解。运行测试并填写决策表
保存配置记录，包括具体模型或快照、供应商、提示词版本、参考素材、画质、尺寸、输出设置和重试策略。编辑序列还需保存每一步的父级输出和修改要求。在相近负载下交替安排两款模型的请求顺序，避免繁忙时段系统性地只影响其中一款。若目的是迁移，还应把现有工作流作为基线加入测试。
先判断能否交付，再比较偏好
先检查前面的任务硬性要求，再给三个软指标打分：构图、光线与视觉协调、完成度。每项 0 至 2 分：0 代表需要大量修复，1 代表少量修复，2 代表可以用于预定交接。这个示例规则要求所有硬性检查通过，且总分至少 5/6。实际阈值应在查看模型标签前确定。
因此，商品标签被改动的漂亮图片，即使审美评分 6/6 也不通过；包含全部必需元素、三项得分为 2/2/1 的 UI 草稿，则通过这套示例规则。仍需记录剩余修复时间，不能将其视为免费。
run_log_reference 关联包含原始 usage 的请求日志。completed、failed 或 unfinished；验收与截止时间字段填写 yes / no。请求完成并不代表图像通过验收。没有合格输出时，“得到合格结果的耗时”留空。账单在核对完成前标为 pending，等整批费用全部核对后再比较成本，不能忽略未结算任务或将其视为免费。分别汇总每个工作流：
| 决策字段 | Flare | Sunburst |
|---|---|---|
| 配置 ID 与样本数 | 待填 | 待填 |
| 最终合格交付物 / 尝试任务数 | 待填 | 待填 |
| 按原因分类的硬性失败 | 待填 | 待填 |
| 核对后的批次费用 / 合格交付物数 | 待填 | 待填 |
| 得到合格交付物的耗时；未完成任务 | 待填 | 待填 |
| 审核与修复分钟数 | 待填 | 待填 |
| 是否满足本工作流的交付限制？ | 是 / 否 / 证据不足 | 是 / 否 / 证据不足 |
报告耗时时保留未完成任务。一款模型不能因为只计时最容易成功的任务，就在大量失败的情况下显得更快。对于这轮小规模筛选，展示观察到的耗时与错过的截止时间即可，不要声称得到了可靠的 p95 或广泛适用的性能结论。
把表格转成选型决定
如果 Flare 通过 12 个、Sunburst 通过 18 个，并且日志表明差异反复来自商品标签保持，那么可以让 Sunburst 进入新一组商品编辑验证。但如果额外等待超过交付期限，它仍然不能通过最终决策。两款都达不到 16 个时，保留现有流程、调整任务或转人工。这些数字只用于演示决策规则，不是实测结果或通用验收目标。
将结果落实为按任务分配模型的规则
固定配置通过新的验证集后，再将其引入该类任务中的有限范围。Flare 和 Sunburst 的选择要按任务分开：商品编辑更好，不意味着 UI 草稿也应该一起迁移。保留之前有效的配置与已确认素材，以便在费用、拒绝率或交付时间超出限制时退回原方案。
初始规则可以区分四种结果：
| 结果 | 建议动作 |
|---|---|
| 输出通过任务验收规则 | 交付；保留足够的配置与账单证据以复盘表现 |
| 请求完成，但具体视觉要求未通过 | 记录失败原因；在重试预算内尝试已验证的其他配置，或转审核 |
| 请求因传输、限速或供应商可用性而失败 | 按文档执行重试和状态查询；适用时使用已核验的备用方案 |
| 预算耗尽、要求互相冲突或审核持续失败 | 停止生成，返回任务补充要求或交由人工处理 |
技术失败与质量失败要分开。换模型可能改善身份特征保持，却不能通过反复切换修好格式错误的请求。超时后，如果渠道支持状态查询，应先核对原请求状态，再提交可能再次计费的新任务。
保存最近一次验收通过的素材和有效配置。新模型在编辑序列中偏移时，从已确认检查点恢复，不要在已经不合格的图上反复编辑。采用新配置后按工作流复查延迟与验收率，不要只看成功的 API 响应总数。
如何通过 EvoLink 执行
使用统一网关时，把任务分配规则与供应商请求细节分开。应用需要知道某个任务为什么采用某个配置；接入实现则应提供经过核验的模型 ID、参数与计费行为。
生产任务经 EvoLink 调用前，应分别测试 Flare 和 Sunburst：核对可接受参数，各完成一次生成和一次编辑，并核对每款模型的账单。你在一个变体上通过的集成测试，不能替代另一个变体的验收；两款模型均已在 EvoLink 上线。上面的规则是应用设计建议，并不表示 EvoLink 提供这两个变体间的自动故障切换。
常见问题
Flare 和 Sunburst 应该先试哪个？
日常生成和频繁出变体，先评估 Flare；编辑精度和保留已确认细节是主要难点时，优先评估 Sunburst。这个顺序来自 OpenAI 定位，最终选择仍要由自己的验收规则决定。
Sunburst 一定比 Flare 更好吗？
本文不能支持这个结论。工作流需要的是在延迟与成本预算内获得合格结果。即使某个配置需要更多资源，也只有改善了该任务真正关心的问题才有价值。设为默认之前，用困难案例同时评估两者。
Flare 更便宜吗？
官方标准 token 单价相同。要比较实际输入与输出用量、重试和合格图数量。Flare 在某类任务上可能更经济，但模型名称与共用的费率表都不能直接证明这一点。
每张最终图都应该用 max 吗？
选择经过测试、满足交付要求且成本最低的配置。低档失败时可以评估高档，但要检查它是否解决了实际失败原因。对比费用时继续计入审核时间与重试。
Sunburst 能保证多轮编辑不改变商品细节吗？
本文使用的来源不能证明这种保证。将受保护细节列为明确的验收标准，测试完整编辑序列，并保留已确认的源图，以便恢复或人工合成。
能用 Flare 出草稿，再让 Sunburst 做最终编辑吗？
这是值得评估的流程。衔接本身也要测试：第二个模型必须接收正确的参考素材，并保留已确认的选择。将两个阶段的总费用与完成时间，同全程使用单一模型进行比较。
能从图片看出 ChatGPT 用了哪个变体吗？
仅凭外观不足以判断，本文也未核验 ChatGPT 或 Codex 的单次请求。要进行可复现测试，请显式选择并记录图像模型；两张官方模型页均记录了 Images API 与 Responses 图像工具的模型选择方式。缺少配置、尝试次数和费用的社区截图，不能构成配对 API 测试结果。
EvoLink 能调用这两个变体吗？
gpt-image-2.5 别名，请在请求中写明变体。来源与更新规则
- Introducing ChatGPT Images 2.5：官方定位与发布背景；2026 年 9 月 9 日核验。
- GPT-Image-2.5 Flare 模型文档：模型 ID、输入输出、画质选项和标准费率；2026 年 9 月 9 日核验。
- GPT-Image-2.5 Sunburst 模型文档：模型 ID、输入输出、画质选项和标准费率；2026 年 9 月 9 日核验。
- OpenAI 图像生成指南：模型选择、用量与成本说明；2026 年 9 月 9 日核验。
- 12ui 作者分享的 UI 生成对比：已披露产品关联的社区演示，不作为独立核验的性能来源。
模型行为、官方设置、经核验的路由可用性或可比任务结果变化后，重新评估本文建议。补充实测时记录准确配置和测试日期，并持续区分供应商说法、第三方报告与 EvoLink 自测。
