GPT-Image-2.6 对比 GPT-Image-2.5：切换只需改一个字符串，账单却并非如此

从 GPT-Image-2.5 迁移到 GPT-Image-2.6，在 API 层面是 OpenAI 今年推出的最平淡无奇的升级。还是那两个端点，还是同样的价目表，还是同样的 Flare 与 Sunburst 之分。模型字符串变了，其他都不必变。陷阱也正在这里。GPT-Image-2.6 新增了一个 GPT-Image-2.5 从未有过的参数——复杂度调节旋钮——而不传它并不等于把它关掉。它默认是高。一个只换字符串就上线的流水线，并不是用同样的钱买同样的工作量；它买的是更多工作量，这就是为什么迁移后的第一份成本报告可能会变化，尽管公布的价格并没有变。

两个模型以相同的商业条款正式全面可用，这正是这次比较不同寻常的原因。价格上没什么可争的。争论完全在于新增工作量花在哪里，以及你的流量形态是否能让它从中受益。

API 接口确实可以直接替换——但其中有一个缺口。

OpenAI 于 2026 年 11 月 4 日发布了 GPT-Image-2.6，以两个 API 模型而非一个的形式推出，沿用了其在 2.5 中确立的结构。注重细节与一致性的层级是 GPT-Image-2.6 Sunburst；速度层级是 GPT-Image-2.6 Flare。它们的前代 GPT-Image-2.5 Sunburst 和 GPT-Image-2.5 Flare 保留相同名称，并保持彼此之间相同的关系。

• 模型字符串 — gpt-image-2.6-flare 和 gpt-image-2.6-sunburst 取代 gpt-image-2.5-flare 和 gpt-image-2.5-sunburst，命名逻辑相同，一个侧重低延迟，一个侧重细节。

• 端点 — /v1/images/generations 和 /v1/images/edits，保持不变。无需集成新端点。

• 费率 — 每百万文本输入 token 5 美元，每百万图像输入 token 8 美元，每百万图像输出 token 30 美元，缓存输入分别为 1.25 美元和 2.00 美元。与 2.5 逐字节完全相同。

• 质量层级 — low、medium、high、xhigh、max 和 auto。同样的阶梯。

推荐尺寸——1024×1024、1536×1024 和 1024×1536 仍在文档中占据主导，自定义尺寸需为 16 的倍数，宽高比支持 1:3 至 3:1。

• 短板——2.6 无法通过 Batch API 使用。如果你的图像开销依赖半价的夜间任务，那么这项任务目前还无法迁移。

最后一行才是真正会出问题的地方。它上面的所有内容都只是字符串替换和回归运行。批处理缺口恰恰是这些工作负载在架构层面的阻塞点——批量目录、夜间回填、大规模 A/B 生成——而对这类工作负载来说，50% 的折扣正是它们得以存在的根本原因。

复杂度旋钮才是真正的亮点，而它的默认设置才是出人意料之处

复杂度是一个与质量并列、而非从属于质量的新维度，而这一区别比听起来更重要。质量控制渲染：有多少输出 token 投入到画面中。复杂度控制规划：模型在开始渲染之前进行多少推理。你可以要求一张复杂场景的低质量图像，也可以要求一张简单场景的高质量图像，而在 2.6 中，这确实是两种彼此独立的请求。

文档明确指出，省略该参数时其默认值为 high。因此，调用方若只是把 2.5 请求的模型名改掉、其余一概不动，就会在每次调用时不知不觉地选用最大规划预算。这不是缺陷——对于一个以“能做更多思考”为卖点的模型来说，这是合理的默认设置——但这确实意味着，2.6 流量第一个月的数据与 2.5 流量最后一个月的数据并非同口径比较。

至少有一个公开数据点也指向同一结论。11 月 4 日发布的一项三图实测报告称，2.6 的输出费用为 $0.1245，而同样的静态图在 2.5 上为 $0.0446——约为三倍，且价目表并未改变。三张图片不是基准测试，也不应被当作基准测试引用；样本太小，远不足以确定一个倍数。它确实展示了这一机制，而该机制有文档记录：每次请求使用更多规划 token，默认开启，按每百万 $30 计费。

如果你从本文中只采取一个操作步骤，那就采取这个。显式设置复杂度——对于匹配 2.5 时代的行为，medium 是一个合理的初步猜测——然后在前后分别测量每次请求的输出 token。不要测量每次请求的美元成本。每次请求的美元成本只会告诉你费率卡没有变化，而这是你已经知道的事。每次请求的 token 数会告诉你模型是否在做比你要求更多的工作。

所谓的 50% 提速实际究竟能达到什么程度

OpenAI 称 GPT-Image-2.6 整体大约快 50%，但各档位的数字比这个总体数字有意思得多，而且这些是厂商自己提供的数据，并非独立测量所得。据报道，Flare 约为其前代的 2.6 倍，低质量渲染最快可在六秒内完成。据报道，Sunburst 约为 1.15 倍。

这两个数字描述的是两种完全不同的升级。如果你的流水线在迭代环节运行 Flare——缩略图探索、提示词调优，或任何有人等待结果的场景——2.6 是一次阶跃式提升，仅凭注意力成本的节省，迁移就能回本。如果你的流水线为了最终输出质量而运行 Sunburst，15% 的延迟改进在大多数托管环境的运行间波动范围内，速度完全不是迁移的理由。

值得诚实指出的是：同一个报告了 token 膨胀的小规模实测，也报告 2.6 在其三张图像上比 2.5 更慢，这与厂商的说法相矛盾。以 n=3 来说，那只是噪声，不是反驳。但它提醒我们，“快 50%”是发布材料中跨不同质量档位汇总出来的数字，而真实流水线只会在某一个质量设置下看到某一个档位。

还没有人拿到2.6分，2.5仍然是第一名

这正是大多数报道轻描淡写带过的对比环节。Artificial Analysis 以其 AA-Image-T2I v2.1 及编辑榜单进行评测，但在 2026 年 11 月 5 日查阅时，GPT-Image-2.6 根本没有出现在任何一行里。不是分数低——而是压根没有这一行。

那些榜单确实显示，被替换的模型仍然在它们上面获胜：

• 文生图——GPT-Image-2.5 Sunburst（max）以 13,153 票获得 1,224 Elo，排名第一。GPT-Image-2.5 Flare（max）以 12,498 票获得 1,207 Elo，排名第二。GPT Image 2（high）以 1,188 Elo 排名第三。

图像编辑——GPT-Image-2.5 Sunburst（max）在 18,370 票中获得 1,200 分，排名第一。GPT-Image-2.5 Flare（max）在 19,259 票中获得 1,183 分，排名第三，落后于获得 1,197 分的 MAI-Image-2.7-Preview。

OpenAI 的发布材料援引 Design Arena，称 2.6 Sunburst 获得第一名。这是真实榜单上的真实说法，但它来自不同的评分者群体、不同的评分尺度；而厂商挑选一个能美化其发布成绩的榜单，并不能构成买家可用的任何证据。2.6 的可比、第三方、经投票得出的数字尚不存在。在它出现之前，站得住脚的立场是：2.5 是两大主要榜单上独立评分最高的图像模型，而 2.6 尚未得到验证——它在 OpenAI 所称更优的那些具体方面确实更好，但在其他所有方面都未经过测量。

一个下午就能完成的迁移

这种替换的成本足够低，因此明智的做法不是搞大爆炸式的一次性迁移，而是采取有分寸、循序渐进的迁移，并且要跑在你自己的提示词上，而不是跑在任何人的基准提示词集上。

先把复杂度固定为你选定的一个值，这样这项变化就是你主动做出的，而不是默认带来的。然后从生产日志中重新运行几百条真实提示词——不是测试夹具里那些干净的提示词，而是那些带有拼写错误和别扭宽高比的杂乱提示词。比较两个数字：每张被接受图片的输出 token 数，以及每百次尝试中被接受的图片数。第二个数字才是一致性改进会体现出来的地方，而且它才是真正决定这次升级是否省钱的数字，因为一张被你丢弃的图片会消耗完整的 token 预算，却什么都换不回来。

为批处理工作保留一条回退到 2.5 的路径，因为 2.6 目前还无法承载这类工作。同时，要把任何 Sunburst 流量当作质量问题而非速度问题来处理——如果接受率没有变化，那你换来的就只是 15% 的延迟改善和一张更大的规划账单。

何时继续使用 2.5 才是正确答案

有三种情况足够明确，可以直接点名。批处理工作负载应保持不变，因为 2.6 不在 Batch API 上，而 2.5 在。旭日图质量流水线应保持不变，除非接受率测试表明并非如此，因为 1.15× 的加速不足以抵偿一次成本模型变更。而任何当前接受率已经可接受的人都应保持不变，因为新能力——SVG 导出、动画 GIF、标记引导编辑——是附加功能，而非质量改进，只有当你有一个需要它们的交付物时，你才需要它们。

这次升级是实实在在的。它只是集中在 Flare 的延迟表现和新的输出格式上，而这两方面的范围比“一个全新模型”所暗示的要窄。

可用性，以及拆分式迁移的尴尬形态

OrcaRouter 提供GPT-Image-2.5 Flare 和 GPT-Image-2.5 Sunburst，今日按标价、0% 加价，因此提供商的价格就是你支付的价格，上面不叠加任何利润。截至 2026 年 11 月 5 日——即发布后第二天——GPT-Image-2.6 尚未进入目录，这使得眼下实际的问题不是建模问题，而是路由问题：在对比评测期间，2.5 的流量通过一个密钥运行并带有自动故障转移，而 2.6 的流量则依据第二份合同、第二份账单直接发往 OpenAI。

这种差异值得提前规划，而不是等发现后再应对。在把生产路径确定到 2.6 之前，先查看目录，因为对于一个发布仅二十四小时的模型，任何路由服务都无法承诺发布日对等。等它真正上线时，透传规则意味着供应商的费率就是你当天支付的价格——OpenAI 一侧的价格变动会直接传导过来，而我们这边无需重新谈判——但在那之前，对情况的诚实解读是：2.5 可路由，2.6 不可路由。

这也是支持“下午就能完成的迁移”而非“周末才能完成的迁移”的另一个理由。让 2.5 走路由器，保持成本基线稳定，并在测量出复杂度默认值会对你的 token 数量造成什么影响后，再把 2.6 放到功能开关后面。模型不会消失，而批处理端点会在你下一个季度规划周期到来之前就到位。