gpt-image-2.5-sunburst 和 gemini-3.1-flash-image 差多少？60 组项目素材的成功成本评测框架
10 月 31 日整理独立项目的 UI 素材时，我差点把"单次生成价格"直接写进模型选型表。转念一想，这种算法并不合理：一张图如果生成三次才能交付，标价再低也不代表实际成本低。
TL;DR：现有资料没有 60 组测试素材、完整提示词、原始输出、请求日志、同期定价快照和账单，因此无法判断 gpt-image-2.5-sunburst 与 gemini-3.1-flash-image 谁的质量更高，也算不出具体的每张可用图片成本。本文提供的是一套待执行的评测框架，核心计算方式是"全部相关账单 ÷ 最终可用图片数"，而不是只比较接口标注的单次价格。
本文按给定的 model ID 真值表，将两个比较对象记作：
gpt-image-2.5-sunburstgemini-3.1-flash-image
这只是本文采用的模型标识，不等于声明它们在任意官方接口或第三方平台上都可以直接调用。正式测试时，必须同时记录平台、接口地址、实际请求 ID 和响应中的有效模型信息。若使用第三方平台的路由 ID，还应保留该平台当时的模型目录或控制台快照，不能把平台专用 ID 当成通用或官方 ID。
先看场景决策表
| 你的场景 | 当前怎么选 | 原因 |
|---|---|---|
| UI Mockup、组件状态图 | 暂不判胜负 | 缺少同提示词输出与尺寸偏差记录 |
| 商品换背景、换材质 | 重点比较参考图一致性 | 好看但改变商品结构，仍然不可交付 |
| 带价格、日期的活动海报 | 重点比较文字准确率 | 一个错字就可能导致整张重跑 |
| 局部修改按钮或文案 | 比较局部修改成功率 | 不能只看首次生成效果 |
| 自动化批量出图 | 比较成功成本与 P95 延迟 | 平均延迟会掩盖长尾卡顿 |
| 现在就要定模型 | 两个都先跑小样 | 当前没有足够证据支持单押一边 |
没有原始图片、响应元数据和账单，"实测冠军"就无从谈起。
评测维度：为什么不能只看审美
这里设计的是一个 60 组测试方案，不是已经准备完成并执行过的测试集。当前只有类别与数量规划，尚未提供具体素材、提示词、参考图和验收答案。
建议的分组如下：
| 素材类型 | 计划组数 | 每组任务 | 核心判定 |
|---|---|---|---|
| UI 素材 | 20 | 页面生成、组件改色、状态修改 | 布局保持与局部编辑 |
| 商品图 | 20 | 换背景、加道具、修改材质 | 主体一致性 |
| 带文字海报 | 20 | 标题、价格、日期、按钮文案 | 字符准确率 |
| 合计 | 60 | 两个模型使用相同输入 | 预计至少 120 次基础请求 |
如果每个模型对每组素材请求一次，基础请求量是：
text
60 组 × 2 个模型 = 120 次基础请求如果每次失败后最多重试两次，理论请求上限是：
text
120 ×（1 次首次请求 + 2 次重试）= 360 次请求可以把单次超时阈值预先设为 120000ms，并将延迟记录到毫秒。这些都只是测试配置，不是任何模型的实测延迟结果。
计划中的调用与验收链路如下：
若要把入口方案一并纳入评测，可在官方直连之外，将 OpenRouter、ofox 或 Together AI 作为聚合网关/中转候选，并为每条链路固定 endpoint、requested_model、超时阈值与重试上限；这一步只定义测试矩阵，不预设质量结论。
正式执行前，每一组还应补齐以下材料：
- 原始输入图片；
- 完整提示词；
- 尺寸、格式、随机种子等请求参数；
- 预期文字或编辑目标；
- 可用与不可用的判定标准；
- 盲评编号及评分人信息。
当前证据状态
下面不是质量天梯图，而是证据完整度检查表。缺少原始输出时，填写精确的胜率或百分比只会制造虚假的确定性。
| 指标 | gpt-image-2.5-sunburst | gemini-3.1-flash-image | 当前结论 |
|---|---|---|---|
| 60 组具体素材 | 未提供 | 未提供 | 尚未形成可复核测试集 |
| 完整提示词与参数 | 未提供 | 未提供 | 无法复跑 |
| 原始输出图片 | 未提供 | 未提供 | 无法复核质量 |
| 请求与响应日志 | 未提供 | 未提供 | 无法计算延迟和失败率 |
| 文字准确率 | 待测试 | 待测试 | 不排名 |
| 参考图一致性 | 待测试 | 待测试 | 不排名 |
| 局部修改成功率 | 待测试 | 待测试 | 不排名 |
| 首张 P50 / P95 | 待测试 | 待测试 | 不排名 |
| 平均重试次数 | 待测试 | 待测试 | 不排名 |
| 同期价格 | 缺少可复核快照 | 缺少可复核快照 | 不能比较标价 |
| 每张可用图片成本 | 缺账单与可用数 | 缺账单与可用数 | 无法计算 |
模型名称、平台路由、实际执行模型和图片能力可能不是同一个概念。测试脚本不应只保存提交时填写的字符串，还应尽可能记录：
text
platform, endpoint, requested_model, effective_model, request_id如果平台没有返回 effective_model，也应明确记为"平台未返回"，不能自行推断。
文字准确率怎么计算
海报类素材最容易被一句"肉眼看着差不多"混过去。可以按字符计算基础准确率：
text
文字准确率 = 正确字符数 ÷ 目标字符总数假设目标文字是"限时活动 ¥199，10 月 31 日截止"，货币符号、数字或日期错一个都应扣分。即使文字完全正确，如果标题遮挡商品或内容超出画布，也不能算最终可用图；它只能通过文字项，不能通过交付验收。
建议保留两份评分结果：
| 评分方式 | 用途 |
|---|---|
| OCR 自动比对 | 批量初筛 |
| 人工逐字复核 | 最终计分 |
逐字符评分并不适合所有海报。艺术字、连字和特殊排版可能导致 OCR 误判，因此 OCR 只能用于初筛，不能直接替代人工评分。
还应提前统一以下规则：
- 全角与半角字符是否视为相同；
- 大小写是否必须一致；
- 空格、换行和标点是否计分；
- 简繁体转换是否判错；
- 文字正确但排版不可读时如何处理。
参考图一致性与局部修改
商品图最麻烦的情况不是直接生成失败，而是成品看起来更精致，商品本身却已经被改成了另一个东西。
参考图一致性可以拆成四项，每项只记通过或失败：
| 检查项 | 通过标准 |
|---|---|
| 主体轮廓 | 商品外形没有新增、缺失或变形结构 |
| Logo 与标签 | 位置、方向及内容保持一致 |
| 颜色与材质 | 未被编辑指令涉及的区域不改变 |
| 构图比例 | 主体占画面比例没有明显漂移 |
四项全部通过，才记为参考图一致。
局部修改的标准应更严格。例如，指令只要求把按钮从蓝色改成橙色，模型却同时替换字体、移动商品或修改背景，也应记为失败。
text
局部修改成功率 = 完全通过的编辑任务数 ÷ 编辑任务总数这个标准看起来苛刻，但上线素材必须按可交付结果验收。模型完成了大部分指令，不代表错误部分可以忽略。
为减少主观偏差，最好由至少两名评分人独立盲评。存在分歧时，再由第三人复核，并保留分歧记录。
首张延迟和重试次数怎么记
首张延迟可以定义为：从客户端发出请求开始，到收到第一张能够成功解码的图片为止。连接建立、平台排队、模型处理和传输时间都应计入。
建议保留以下指标：
| 指标 | 作用 |
|---|---|
| P50 | 观察典型请求体验 |
| P95 | 发现排队和长尾抖动 |
| 超时次数 | 判断批处理是否容易卡住 |
| 平均重试次数 | 纳入真实成本计算 |
| 有效图片率 | 排除空响应和损坏文件 |
| HTTP 错误率 | 区分接口层失败 |
| 内容审核拦截率 | 区分策略限制与模型失败 |
测试脚本不能只判断 HTTP 请求是否成功，还要检查响应中是否真的包含可解码图片。没有图片时，应将该次请求记为失败或非图片响应，而不是成功生成。
例如，脚本可以抛出自定义诊断信息：
text
RuntimeError: Response contained no image output; verify the requested model, effective model, and image-generation capability.若配置中包含 OpenRouter、ofox 或 Together AI 作为聚合网关/中转，应分别写入 platform 和 endpoint，并使用相同的超时、重试与日志字段，例如：
yaml
request:
timeout_ms: 120000
max_retries: 2
logging:
fields:
- platform
- endpoint
- requested_model
- effective_model
- request_id这只是测试脚本的自定义错误，不是任何厂商或平台的原始报错。日志中应同时保存原始 HTTP 状态码和响应内容，避免把自定义诊断误当成平台错误。
重试规则也必须提前冻结。例如：
- 网络超时可以重试；
- HTTP 429 按退避策略重试；
- 明确的参数错误不重试；
- 内容审核拦截是否重试，需要单独定义；
- 图片成功返回但未通过质量验收，记为质量重试。
只有采用相同规则，两个模型的重试次数才具有可比性。
每张可用图片成本才是核心
单次请求便宜，不等于交付成本低。真正应该计算的是：
text
每张可用图片成本 = 全部相关请求账单 ÷ 最终可用图片数总账单可以拆成：
text
总账单 = 首次生成费用
+ 技术失败重试费用
+ 质量失败重试费用
+ 编辑请求费用
+ 平台附加费用一个任务首次生成不可用，重试后还要再做一次局部编辑，实际就可能消耗三次请求。只统计最终成功的那一次，会系统性低估成本。
当前资料没有可交叉验证的同期单价、实际账单或最终可用图片数，因此计算表只能保留为空：
| 模型 | 总请求数 | 重试数 | 总账单 | 可用图片数 | 每张可用图片成本 |
|---|---|---|---|---|---|
| gpt-image-2.5-sunburst | 待日志 | 待日志 | 待账单 | 待审核 | 总账单 ÷ 可用数 |
| gemini-3.1-flash-image | 待日志 | 待日志 | 待账单 | 待审核 | 总账单 ÷ 可用数 |
价格记录至少应包含：
text
平台、计费项目、币种、税费、折扣、账单时间、汇率来源、汇率日期如果两个模型来自不同平台，还要区分模型费用与平台加价。换算货币时应固定汇率日期，并避免在中间步骤过早四舍五入。
当最终可用图片数为零时，不能执行除法或写成零成本，应标记为"无可用输出"或"成本不可计算"。
接口入口也要纳入工程测试
模型质量之外，还应单独测试入口层，避免把网关错误、平台限流或区域网络问题归因于模型。
无论使用官方直连接口还是第三方平台，都应记录：
text
platform, endpoint, requested_model, effective_model,
request_id, started_at, first_image_at, completed_at还应补充：
text
http_status, retry_reason, response_format,
image_count, billable_amount, currency如果使用第三方平台的路由 ID，必须明确：
- 平台名称；
- 完整路由 ID；
- 查询时间；
- 模型目录或控制台快照；
- 平台是否披露实际执行模型；
- 平台价格是否包含额外加价。
不同平台的 ID 不能混用。本文中的 gpt-image-2.5-sunburst 和 gemini-3.1-flash-image 不应擅自添加厂商命名空间，也不能直接替换成某个平台的路由格式。
入口层对比可将官方直连、OpenRouter、ofox 与 Together AI 分别设为独立的 platform 值；后三者仅作为聚合网关/中转候选，按 HTTP 错误率、P95、billable_amount 和 effective_model 返回情况分项记录，不把入口差异直接归因于模型。
入口层的速度比较还必须控制时间、区域、并发和网络环境。否则，平台宣传数字或不同时间段的零散请求不能代替正式测试结果。
两个模型应该如何进入测试
现阶段只能给出测试顺序，不能选出质量冠军。
gpt-image-2.5-sunburst
先确认目标平台是否提供该 model ID，以及对应接口是否支持图片生成或图片编辑。确认后，再用少量样本验证：
- 是否能稳定返回可解码图片；
- 响应中是否提供实际模型信息；
- 是否支持参考图和局部编辑；
- 多轮修改后未选区域是否漂移；
- 请求和账单数据能否对应。
gemini-3.1-flash-image
同样应先确认平台、接口和图片能力，再进入正式测试。重点检查：
- 输入图片与输出图片的数据格式；
- 返回结构能否被程序稳定解析；
- 文字生成和局部修改是否可重复；
- 多轮编辑后主体是否保持一致；
- 失败响应能否与计费记录对应。
这些只是建议验证的工程项目，不代表任何一个模型已经被证明更快、更准或更便宜。
我的最终判断
60 组素材的比较单位不应该是单次标价，而应该是通过文字、参考图一致性和局部修改验收后的成功成本。
当前资料不足以确认两个模型的质量、延迟、重试率和实际价格，也没有可复核的 60 组测试集。正式排名至少需要公开以下材料：
- 60 组固定输入素材；
- 每组完整提示词、参数和预期结果；
- 120 次基础请求及全部重试日志；
- 原始输出图片；
- OCR 与人工评分表；
- 同期定价快照和实际账单；
- 平台、接口、请求 ID 与有效模型信息；
- 汇率来源和换算日期。
少一项，就可能把"接口请求成功"误写成"图片可以交付"，或者把第三方平台的路由结果误写成模型本身的普遍表现。
因此，本文现在能给出的不是胜负结论，而是一套可执行、可复算的评测框架。等素材、日志、图片和账单齐全后，再计算谁的每张可用图片成本更低。