📋 目录
- 一、两个模型，一个价
- 二、纠错一：跑量模型不等于更便宜
- 三、纠错二：贵的是 quality，而且它默认不贵
- 四、逐档成本表，和一个反直觉的发现
- 五、纠错三：分辨率不是按像素收费
- 六、参考图才是隐藏的成本项
- 七、失败也是成本：两起 moderation_blocked
- 八、可复现的验收清单
- 九、对企业：把"默认"变成"显式"
- 十、结语
一、两个模型，一个价
先把这批数字摆清楚，因为 OpenAI 这次的定价结构是反直觉的。
2026 年 9 月 8 日，OpenAI 发布 GPT Image 2.5，同时进了 ChatGPT（所有档位）和 API。API 侧拆成两个模型：
| Model ID | 官方定位 | 延迟（官方口径） |
|---|---|---|
gpt-image-2.5-flare | 快速默认，日常生成 | 比 GPT Image 2 低最多 50% |
gpt-image-2.5-sunburst | 编辑精准度，高端创意 | 单次生成耗时更长 |
通常的做法是：拆两个模型，然后给它们定不同的价——一个高端版、一个批量版，价卡直接告诉你哪个是哪个。OpenAI 反其道而行，把价卡保持完全一致。
两个模型同价这件事有多不寻常，值得停一下：整个 API 都和gpt-image-2保持同样的 token 定价，一分没涨。
这里有一处必须纠正的流传说法：发布期有报道称"GPT Image 2.5 把每 token 价格翻倍了"。这与 API 实际计费不符。多家第三方核对过 API 返回的实际用量，两款模型都严格落在gpt-image-2的费率上。引用"翻倍"这个说法是错的。
能力上的升级是真的，不是营销：新支持尺寸最高到 3840×2160（横）/ 2160×3840（竖），约 830 万像素；quality 档位在上次天花板之上新增xhigh和max两级；参考保真度、定向编辑、多轮编辑不累积退化、复杂版式的透明背景都做了提升。
消费端 ChatGPT Images 2.5 向所有 ChatGPT、ChatGPT Work 和 Codex 用户（桌面/移动/网页）开放，另加 Sketch 工具、格式模板、图内评论、Prompt 分享。这一半是功能投放，不是采购决策——没人需要为它花钱。
二、纠错一：跑量模型不等于更便宜
这是本文最核心的纠错，因为几乎所有解读都搞反了。
官方定位是"Flare 跑量、Sunburst 精修"。厂商定位通常暗示"高端版更好所以更贵"。但实测结果推翻了这个直觉。
三组独立实测的结论高度一致：
| 实测方 | 样本 | 结论 |
|---|---|---|
| Thumix | 逐档读取 API 返回的 usage | 输出 token 数在每个质量档逐字节相同；唯一差别是速度，且 Sunburst 更慢 |
| GenFlick | 142 次调用，140 张成图 | 12 个匹配条件中Flare 在 10 个的中位延迟更低 |
| Elite Cloud | 分档计时 | medium 档 Sunburst 平均慢约 38%；high 档差距扩大到 65% |
GenFlick 的分档数据最具体：
| 设置（1024 方图，无参考图） | Flare 中位延迟 | Sunburst 中位延迟 |
|---|---|---|
| low | 10.4 秒 | 15.7 秒 |
| high | 18.1 秒 | 29.9 秒 |
| max | 45.6 秒 | 85.0 秒 |
所以真相是：Flare 和 Sunburst 在同样的质量档位下花同样的钱，Flare 还更快。
那么"精修"体现在哪？答案是：体现在速度上，不体现在价格上，也不体现在 token 数上。
这里有一个重要的例外条件要注意。Sunburst 的官方指导是"编辑精准度最重要时用"。上面的数据说明的是"同样的请求参数下两者行为一致"。如果 Sunburst 在特定编辑任务上真的输出更好，那可能是"编辑后保真度更高导致 token 数不同"——但目前没有独立数据能确认这一点。有一篇实测提到"更长的生成本身会发出更多输出 token"，但另一家实测在逐档核对后明确说两者 token 数相同。这两方说法冲突，我倾向于"逐档读数"的证据更硬（直接读 API 返回值 vs 从原理推断），但这条保留。
三、纠错二：贵的是 quality，而且它默认不贵
如果 Flare 和 Sunburst 不是成本决策，那什么才是？
答案是 quality 参数，而且它的摆幅比大多数人意识到的更大。
先看完整档位和它的出厂默认值：
| 质量档 | 单价范围 |
|---|---|
auto（默认值） | — |
low | 最便宜 |
medium | — |
high | — |
xhigh | — |
max | 最贵 |
关键在这里：默认值是auto。而多家实测都发现auto产出的token 数和账单与low完全一致。
GenFlick 的数据：两个模型的 auto 调用在无参考图时都是 $0.023925，有参考图时都是 $0.063748。
Thumix 的数据更直接：“auto 产出的正是同样的 196 token 和同样的 $0.006 账单，与 low 完全一致。如果直接调 API 且没有设置 quality，你拿到的是最便宜那档。”
换句话说：如果你不显式设置 quality，你拿到的是最便宜的档位，而且你不会收到任何提示。
这引出一个更要紧的推论：对于要交付正式素材的场景，"默认最便宜"通常不是好事。一张 $0.006 的图和一个真正高质量的图，交付标准完全不同。而API 不会告诉你质量档选错了。
所以正确做法是显式设置 quality，永远不要依赖 auto。Thumix 明确说自己默认把每次 2.5 生成设为 medium，就是这个原因。
顺带说一句：auto不是一个固定价格的快捷方式。GenFlick 发现参考图条件下，auto的变化远不止输入成本——输出 token 数也跟着变了。所以需要可预测预算的场景，必须选显式档位。
四、逐档成本表，和一个反直觉的发现
这是本文最实用的一张表，全部来自实测读数，可以直接拿去做预算。
纯文本场景（1024 方图，无参考图），两个模型同价：
| 质量档 | 单张成本 |
|---|---|
| low | $0.006 |
| medium | $0.013 |
| high | $0.053 |
| xhigh | $0.094 |
| max | $0.211 |
从 low 到 max 是 33倍摆幅。换算成批量场景：
| 档位 | 1000 张 | 10000 张 |
|---|---|---|
| low | $6 | $60 |
| medium | $13 | $130 |
| high | $53 | $530 |
| xhigh | $94 | $940 |
| max | $211 | $2110 |
这才是该关注的那条新闻：GPT Image 2.5 不是一次降价或涨价，而是一次区间拉宽。你原本以为"图像生成"是一个成本类别，现在它是一个 33 倍的区间，而你可能会不知不觉落在区间里某个位置。
和上一代对比，同一个精确数字下：
| 质量档 | GPT Image 2 | GPT Image 2.5 | 变化 |
|---|---|---|---|
| low | $0.006 | $0.006 | 持平 |
| medium | — | $0.013 | — |
| high | $0.053 | $0.053 | 持平 |
| max | — | $0.211 | — |
| （2 的 high） | $0.211 | — | 2.5 的 max 和 2 的 high 同价 |
这个对比结果非常反直觉，值得单独说：2.5 的 high 比 2 的 high 便宜约 75%，但 2.5 的 max 和 2 的 high 价格完全一样。
也就是说——如果你现在用 GPT Image 2 的 high 档，迁到 2.5 的 high 档能省 75%；如果你需要 2.5 的 max 档，钱和原来 2 的 high 一样多。这个迁移决策要按档位分别算，不能整包推。
同样的价格下，延迟差异巨大：Flare max 45.6 秒、Sunburst max 85.0 秒、GPT Image 2 high 154.7 秒。所以"同价位下2.5 更快"这个说法是成立的——但注意这不是视觉质量的证明，只是延迟对比。
五、纠错三：分辨率不是按像素收费
一个很自然但错误的假设是：像素越多越贵。实测证明不是。
| 分辨率 | quality | 成本 | 中位延迟（文本场景） |
|---|---|---|---|
| 1024×1024 | high | $0.053 | Flare 18.1s / Sunburst 29.9s |
| 1536×864 | high | $0.033 | — |
| 3840×2160 | high | $0.101（无参考图） | Flare 27.5s / Sunburst 33.5s |
注意 1536×864 的 high（$0.033）比 1024×1024 的 high（$0.053）更便宜。而3840×2160 的 high（$0.101）大概只有 1024 方图的 2倍——它有 830 万像素，是 1024 方图（100 万像素）的 8.3 倍。
结论是：输出 token 数取决于尺寸和形状的设定，而不是一个简单的线性像素税率。
还有一个更反直觉的发现：quality 不改变输出尺寸。所有档位返回的都是同一张 1536×1024 图像。quality 是模型内部的渲染预算，不是分辨率设置。
这条对做批量脚本的人特别重要：如果你以为调 quality 是在调清晰度，那是理解错了。它调的是模型的细节投入，尺寸是另一个独立参数。
六、参考图才是隐藏的成本项
如果只看上面的表格，参考图好像只是"多传一张图"。实测给了更精确的数字。
GenFlick 的数据：在固定质量档下，加上角色参考图及其条件指令，每张 2.5 核心图增加 $0.010573：
| 质量档 | 无参考图 | 有参考图 | 涨幅 |
|---|---|---|---|
| low | $0.006 | $0.017 | 约 166% |
| high | $0.053 | $0.064 | 约 20% |
注意低档的涨幅是高的四倍多。
必须加的限定：这个数字不是通用的"每张参考图固定费用"。它取决于实际的参考图 token 数，换一张图数字就变。这只是那一次实测的读数。
一个很反直觉的推论：参考图在 low 档是最大的成本项，在 high 档却只占约 20%。如果你的工作流是"低质量档大批量生成 + 关键几张加参考图精修"，参考图应该放在最后一步用，不要从头就带上。从 high 档的数字看，参考图在高档位的边际成本反而很低。
原生 4K 是支持的，但有实测明确建议：把 4K 当实验性功能对待，那些单次调用延迟只是示例值。
七、失败也是成本：两起 moderation_blocked
这一节很短，但我认为是本文最实用的一段。
GenFlick 的 142 次调用里，Sunburst 有两次纯文本核心请求返回了 HTTP 400moderation_blocked——而这两次用的是和成功调用完全相同的良性场景提示词。没有重试。
两个关键点：
第一，同一个提示词有时过有时不过。这意味着内容审核不是确定性的——你无法靠"这个提示词之前成功过"来判断它还会成功。
第二，这两次因为没有返回 usage 数据，计费状态未知，且没有被当作免费处理。
所以批量生成脚本里必须有一条：失败请求的计费状态要单独跟踪，不能假设失败不花钱。很多成本报表会漏掉这部分。
还有一条实测细节值得记：后台响应在进程退出后仍能恢复。两个模型在有无参考图的情况下都返回了queued 响应 ID，之后由另一个进程取回并拿到成图。提交确认耗时 0.6~7.8 秒。这意味着异步取图是可行的，不是必须同步等待。
八、可复现的验收清单
把上面的结论整理成可以直接照做的流程：
第一步：显式设置 quality，不要用 auto。
| 用途 | 建议档位 |
|---|---|
| 草稿、内部探索 | low |
| 常规交付 | medium |
| 正式素材 | high |
| 精品、需要细节的成品 | xhigh / max |
第二步：默认用 Flare。同样的价、更快的速度。只有在实测确认编辑精修效果确实更好时才用 Sunburst，并且要自己测一遍，不要照抄官方定位。
第三步：参考图放最后。先不用参考图生成满意构图，最后一步再带参考图锁定主体——尤其在 low/medium 档，参考图涨幅超过 100%。
第四步：4K 当实验。实测显示 4K 不按线性像素计价，但延迟和稳定性需要自己验证。
第五步：把验收标准写成清单，别靠"看着还行"。
那个实测者给出的建议非常实用，值得原样引用：
我们建议的测试是：用一个真实的交付物，配一份简短的验收清单。比如瓶子那张图：三条文案正确、泵头完好、轮廓未变、给标题留出足够空间。
这一条是本文的方法论核心。"生成一张好看的图"不是验收标准。一个可交付标准应该是可勾选的列表：文案对不对、元素在不在、留白够不够。这和我之前写的"没有可验证判据的任务，模型只能产出看起来对的东西"是同一个道理，只不过这里的主语从代码变成了图。
第六步：成本监控按档位设告警，不要按总账设。因为单张成本区间是 33 倍，总账上的小幅波动可能掩盖了某次运行悄悄用了 max 档。
九、对企业：把"默认"变成"显式"
按本栏目的惯例，把上面这些问题落到平台机制上。因为这类"默认值陷阱"如果在组织里不管，几个月后没人说得清钱花在哪了。
| 问题 | 机制 | 落点 |
|---|---|---|
| 谁在调图像模型、调哪个档位？ | 统一出口登记模型与档位，禁止开发者直连 | iPaaS 接入层统一凭据与配额 |
| 谁在用付费档位？ | 按部门分配档位配额，超出需审批 | 配额策略可配置 |
| 生成物能不能追责到业务用途？ | 输出留档：谁、什么档位、什么提示词、产出了什么 | 资产与调用记录关联 |
| 输入素材有没有合规问题？ | 生成前登记素材来源与授权情况 | 治理中心前置 |
| 交付标准是什么？ | 任务派发时登记可勾选的验收清单 | 与验收判据登记同机制 |
这里有一条特别值得说：把 quality 从"默认值"变成"必须显式填写的字段"。
技术上这是改一行配置。但它的意义是把一个隐式的、可能造成 33 倍成本差的选择，变成一个显式的、可审计的、被记录下来的决定。这就是"默认"和"显式"的全部区别——不是哪个更好，是哪个能被追溯。
对应到领码 SPARK 融合平台：平台层的价值恰恰在这类地方。一个团队用API 直连，能做到的是"能生成图"；能通过平台做到的是"知道每张图是谁、用什么档位、为什么用这个档位生成的，以及它的素材是否合规"。前者是工具，后者是能力。
需要克制说一句：这些机制解决的是可追溯和可管控，不解决"该不该用高���档位"这个判断。什么场景值得用 max，那是业务负责人和设计负责人该定的。平台能保证的是这个决定被记下来了，而不是悄悄发生的。
十、结语
这次发布真正的故事不在图像质量，在定价结构。
三个该记住的点：
一，两个模型同价，所以"跑量版 vs 精修版"这个直觉是错的。独立实测显示它们在每个质量档的输出 token 数逐字节相同，唯一差别是速度，且 Flare 更快。选型不改变预算。
二，成本摆动 33 倍的是 quality 参数，而它出厂默认是 auto，也就是最便宜那档。"默认最便宜"对交付质量是个隐患——显式设置档位，是本文最值得抄走的一条实操。
三，"GPT Image 2.5 涨价/降价一倍"的说法不成立。API 定价与gpt-image-2完全一致。真正的变化是区间拉宽：low 的 $0.006 到 max 的 $0.211。而"2.5 high 比 2 high 便宜 75%、2.5 max 和 2 high 同价"这个反直觉对比，才是迁移决策该依据的东西。
还有两个容易漏的成本项：参考图在低档位会加价 166%（所以放最后一步用），以及失败请求的计费状态要单独跟踪（同提示词时过时不通过是常态）。
最后回到那句最实用的建议：验收标准要是可勾选的清单，不是一句"看着还行"。三个文案正确、泵头完好、轮廓未变、留白够——能列成清单的才是交付物，"好看"不是。
一个可操作的自查：如果你正在批量生成素材，去查一下你的代码里quality字段是显式传的还是留默认的。如果留默认，你可能在用最低档的画质交付正式素材而不自知；如果显式传了，再去查有没有人悄悄设成了 max 档而账单上多花了 33 倍。
你在生成图像时quality 是显式设的还是留默认的？评论区聊聊——特别想知道有没有人踩过"默认 lowest 档导致交付质量不够"或者"某次跑出33 倍单价的账"这两种坑。如果你自己做了批量生成脚本，也欢迎说说你在质量档位上怎么定的标准。
参考来源：OpenAI 官方 GPT Image 2.5 发布公告（2026-09-08）与 API 定价页、Thumix 逐档 API 用量读数、GenFlick 142 次调用实测基准、Elite Cloud 分档延迟实测、PoloAPI 对同价不同速的分析、多家平台整理的迁移说明。本文核对时间为 2026-10-14；文中标注"保留"的两方冲突数据已明示，未做取舍断言。
本文根据「AIGC新知」视频号《一手实测：GPT-Image2.5，20+ 条提示词抄了就能用》主题整理并扩展，原视频与流传报道中的数据问题（含"涨价一倍"误传、跑量模型不等于更便宜、默认档位隐藏成本）已在文中逐一核实与纠正。
