gpt-image-2.6-sunburst/text-to-image 选型指南：按每张图定价做横向对比

这个模型解决什么问题

先说定位。gpt-image-2.6-sunburst/text-to-image 由 OpenAI 提供，输出类型是图像，能力范围就是 text-to-image：给一段文本提示词，返回一张图片。它的定价采用按张计费的粒度。

它不负责图生图、局部重绘、多图编辑或图像理解，这些不在本文讨论范围内。本文也不复述模型卡上的通用宣传语，而是站在工程团队的角度回答三个问题：按张计费怎么影响成本模型、横向对比时该看哪些维度、以及从现有模型切过来要付出什么代价。

一句话概括适用边界：如果你的业务是「提示词进、成品图出」的标准化生产，且单张成本可以被请求量线性外推，这个模型的形态就是匹配的；如果你需要可控的中间步骤（比如指定采样步骤数、控制分辨率档位来做精细成本分档），那要先确认这些能力是否具备，不能假设。

关于参数、上下文限制、并发额度等细节，以模型详情页和接口文档为准，本文只做选型层面的判断。

输入输出的最小契约

从集成角度看，这类接口的契约非常朴素：请求体里是 prompt，可能附带尺寸或数量一类的可选字段（以文档为准），响应里是图片结果，可能是二进制流，也可能是带过期时间的 URL。选型时先把这个契约确认清楚，因为它决定了你后面的存储策略、重试策略和幂等设计。

按张计费意味着什么

按张计费的核心特征是：计费单位等于成功产出的图片张数，而不是消耗的 token 数、采样步数或 GPU 秒数。已知定价是每张 $0.023，本文只在这个粒度上做算术，不外推任何未公开的计价规则。

成本公式

单次请求成本 = 请求张数 × 单价。月度成本 = 月度成功出图张数 × 单价。这个公式简单到看起来不值得写，但它带来两个工程后果。

第一，成本与「请求次数的成功部分」强绑定。失败请求如果未产生计费，成本不受影响；如果产生了部分计费，就必须在日志里区分。工程上要做的第一件事，是把「发起请求数」「成功出图数」「计费张数」三个指标分开埋点，而不是合并成一个 QPS 视图。

第二，重试直接等于成本翻倍风险。任何非幂等的重试都可能重复出图、重复计费。所以重试必须有上限，必须带幂等键，必须能识别「上一次其实已经成功了，只是响应超时」的情况。

重试开销要单独建模

假设一次业务请求平均触发 r 次尝试（含首次），那么账面上的有效成本会被放大到约 (1 + 额外尝试率) 倍。这个系数在按 token 计费的模型上通常被摊薄，因为单次调用便宜、失败重试的绝对增量小；但在按张计费下，每一张都是完整的一个计费单位，重试放大的绝对值是你必须写进预算的。

与用量型计费的差异

按分辨率、步数、token 一类用量维度计费的模型，成本曲线更细，但预估更难：你必须先知道典型请求的分布，才能算出平均值。按张计费的优势是可预测——业务侧说「这个月要铺 10 万张图」，预算立刻可算。劣势是缺乏弹性：你无法通过降低分辨率来把单张成本压下去，成本控制手段只剩「减少出图张数」和「提升一次成功率」。

失败与配额的保护

按张计费下，配额耗尽和限流错误的代价更高，因为它们的重试窗口里夹着真实成本。建议在客户端设置并发上限、按业务线的张数配额（不是请求数配额），并在配额接近上限时降级到缓存结果而不是继续打接口。

横向对比该看哪些维度

不要只比模型名和单价。下面这套维度不依赖任何具体参数，可以直接搬进评审表格。

输出类型与能力边界

先确认输出形态：是纯图像、图像加文本描述、还是支持多图输入。再确认能力范围：只有 text-to-image，还是包含编辑、重绘、扩图。能力越窄，接口越稳定，但业务侧的组合需求就越可能要你自己拼装。单一 text-to-image 的优势是职责清晰，适合做「一层能力」而不是「一个产品」。

调用方式

同步返回、异步任务、流式返回，三种形态对客户端架构要求完全不同。同步接口最省事，但超时和长尾失败更明显；异步任务需要任务查询和回调，集成成本高但更可控。选型时要问：我的调用栈里有没有现成的任务轮询基础设施。

计费粒度

这是本文的重点维度。把候选模型分成两类：按张/按次计费，和按用量维度计费。前者适合成本可预测的批量业务，后者适合请求分布高度不均、可接受预估误差的场景。两者不要用同一个成本模型去比较，否则结论一定是错的。

可控性需求

业务是否要求指定尺寸档位、风格一致性、可复现的随机种子。可控性越强，接口参数越多，迁移成本越高。反过来说，如果业务对一致性要求低（比如内容配图铺量），单一能力的模型反而更省心。

延迟敏感度

区分「用户在场等待」和「离线批处理」。前者对尾延迟敏感，需要支持超时降级和兜底图；后者可以容忍分钟级延迟，更适合异步任务形态。同一模型在这两类场景下的评分可能差异很大。

供应商锁定风险

评估三件事：接口协议是否标准、返回结果是否可直接迁移（URL 还是二进制）、以及能否通过统一入口在多家之间切换。最后一点决定了你未来议价和容灾的能力，值得在选型阶段就写进架构约束。

数据与合规

提示词和产物的留存策略、内容审核责任归属，这些不进成本表但会卡住上线。提前问清楚，比上线前一周才发现要改链路便宜得多。

什么情况下它更合适

结合 text-to-image 的单一能力和按张计费的可预测性，以下几类场景的判断依据比较明确。

批量出图

当业务侧的需求是「按内容量线性扩张的配图生产」，按张计费的线性成本模型最贴合。你可以用「预计张数 × 单价」直接出预算，不需要先做请求分布采样。这是它相对用量型计费最实在的优势。

原型验证与灰度试验

在验证「图文生成能力到底值不值得做进产品」的阶段，接口简单、计费单位清晰的模型能把验证周期压到最短。团队不需要先搭一套分辨率档位体系，也不用为了省钱去调参。

内容侧低成本铺量

对一致性要求不高、失败可接受重跑的场景（列表页配图、营销物料初稿、内容平台插图），按张计费配合重试上限是可接受的成本结构。

反过来看，什么情况下不该选

第一，需要对单张成本做精细化分档控制的场景。如果产品要求「低清预览走便宜通道、高清成品走贵通道」，而模型本身不暴露这类档位，你就只能靠后处理降采样，成本优势拿不到。

第二，需要图像编辑、局部重绘、多轮迭代的场景。单一 text-to-image 能力无法覆盖，硬拼装会带来多轮调用，按张计费下每轮都是完整计费单位，总成本会迅速超出预期。

第三，对输出一致性有强要求的场景，比如同系列素材要求风格严格统一。此时可控性权重高于单价，应当优先看可控性更强的方案。

第四，极端延迟敏感且无兜底的实时场景。如果超时后无法降级，按张计费下的重试会同时放大延迟和成本。

一个简单的判断顺序

先问「输出的张数是否可预测」，再问「是否需要编辑类能力」，最后问「是否要求强一致性」。三个问题里有一个落在反面，就该把候选清单扩展出去，而不是硬选。

接入实现与常见坑

下面是 text-to-image 接入的最小可行链路，与具体参数无关，可直接套用。

鉴权与请求构造

密钥只放服务端，不落客户端。请求体里把 prompt 作为唯一必需字段，其他字段一律显式传默认值，避免上游默认行为变更带来的隐性漂移。每次请求生成一个业务侧幂等键，写进日志和请求头（或元数据字段，以文档为准），这是后面重试安全的基础。

超时、重试与幂等

for attempt in 1..max_attempts:
  resp = call_api(prompt, idempotency_key, timeout=T)
  if resp.ok: break
  if resp.status in (400, 401, 403): break   # 不可重试
  if resp.status == 429 or resp.status >= 500: sleep(backoff(attempt)); continue

要点有三个：

• 超时不是失败。超时后先查结果（如果接口支持按幂等键或任务 ID 查询），再决定是否重发。
• 4xx 一律不重试，尤其是参数错误和鉴权失败，重试只会烧配额。
• 重试上限必须硬编码，且按张计费下要有「本次请求已重试 N 次」的成本告警。

结果存储

不要长期依赖返回的临时 URL。拿到结果后立刻转存到自己的对象存储，并在业务表里记录「幂等键 → 存储路径 → 计费张数」的映射。这套映射是后面做对账的唯一依据。

常见的四个坑

坑一：把超时当失败直接重发。 上游其实已经出图并计费，你重发一次就变成两张的成本。

坑二：没有按张数的配额。 只限 QPS 不限张数，一次批量任务就能把月度预算打穿。

坑三：prompt 拼接没有版本。 出图质量波动时无法定位是 prompt 变了还是模型变了，回滚无从下手。给 prompt 模板打版本号。

坑四：把同步接口塞进用户请求链路。 上游抖动会直接变成页面超时，且降级无路可走。要么走异步任务，要么加兜底图。

一个统一调用层的雏形

建议在业务代码和模型接口之间加一层薄适配，至少抽象出三个方法：generate(prompt, opts)、poll(taskId)、estimateCost(n)。前两个隔离协议差异，第三个让业务侧能在提交任务前看到预估张数成本，避免预算失控。

迁移与灰度切换注意事项

从现有图像模型切到 gpt-image-2.6-sunburst/text-to-image，顺序比速度重要。

第一步：影子流量对照

不要一开始就切真实流量。把线上请求复制一份发到新模型，只落库不返回给用户。对照评估两件事：出图质量是否满足业务底线，以及单张有效成本与现方案的差异。影子阶段的重试策略要完全一致，否则成本对照没有意义。

第二步：按业务线灰度

选一条对质量最不敏感、失败影响最小的业务线先切，把比例从少量逐步放开。灰度期间重点看三个指标：一次成功率、平均尝试次数、以及每千次业务请求的实际计费张数。第三个指标是这篇文章最想让你盯住的数字。

第三步：最后才调配额

只有在灰度的计费张数稳定之后，才去调整配额和预算科目。提前调额会让灰度期间的异常重试被预算掩盖，问题被推迟到全量才暴露。

迁移时需要抽象出的东西

• 能力抽象：业务代码只依赖「生成一张图」这个语义，不依赖某个模型的字段名。
• 计费口径抽象：每个模型适配器自己实现 estimateCost(n)，上层永远按「张数」而非「金额」做预算判断。
• 错误归一化：把上游的各家错误码映射成统一的几类（参数错、限流、上游故障、超时），重试策略只认归一化后的类别。
• 结果形态归一化：无论上游返回 URL 还是二进制，对内统一成「存储路径」。

切换时容易忽略的两点

一是 prompt 兼容性。不同模型对提示词长度、语言、特殊符号的容忍度不同，迁移前要用真实 prompt 样本做一批回归，尤其是含中文和结构化描述的模板。

二是回滚路径。灰度期间必须保留一键切回旧模型的开关，且旧模型的配额不能被立刻释放。回滚不是失败，是设计的一部分。

在聚合入口下做多模型切换时，上述抽象层基本可以直接复用，这也是把「统一调用层」写进架构约束的主要理由。

一份可直接用的选型清单

评审会上逐条过，确认后归档。

需求侧

• 业务只需要「文本进、图像出」，不需要编辑、重绘、多图输入。
• 出图张数可按业务量预测，能给出月度张数区间。
• 对输出一致性要求不高，或已接受不一致的业务风险。
• 用户在场等待的链路已有兜底图或异步化方案。

成本侧

• 已用「成功出图张数 × 单价」而不是请求数做预算。
• 已把重试放大系数写进预算（按平均尝试次数估算）。
• 配额按张数下发，不是按 QPS 下发。
• 已确认失败的请求是否计费，并在日志中区分三种计数。

工程侧

• 服务端持有密钥，客户端不接触。
• 每次请求带幂等键，且幂等键进了日志和结果表。
• 超时不直接重发，先查结果。
• 重试上限硬编码，4xx 不重试。
• 结果转存自有存储，不依赖临时 URL。
• prompt 模板带版本号。

迁移侧

• 已完成影子流量对照，质量和成本都有数据。
• 灰度按业务线推进，指标看的是每千次请求的计费张数。
• 配额调整排在灰度稳定之后。
• 保留一键回滚开关，旧模型配额未提前释放。

架构侧

• 业务代码不依赖任何具体模型字段。
• 成本估算接口以张数为输入。
• 错误码已归一化为四类，重试策略只认归一化类别。
• 结果形态对内统一为存储路径。

如果这张清单里有超过三行无法确认，建议先不要进灰度，把缺口补完再说。选型的本质不是选一个单价更低的模型，而是选一个你的成本模型、重试模型和回滚模型都能对得上的模型。完成清单后方可进入实施；后续参数与版本细节请以模型详情页和接口文档为准。