GPT Image 2 国内生产接入：兼容网关与令牌分组怎么选

国内应用接入 GPT Image 2，建议先选一套明确的“服务商 + 接口地址 + 令牌分组 + model + 参数”组合，再接入任务队列和账单核对。只替换 SDK 的 base_url，最多证明请求能发出去；生产可用还需要图片确实保存、参数确实生效，以及超时后不会被应用反复提交。

如果优先控制单次预算，可以先验证按次产品；如果需要按官方输入输出 tokens 核算，或者采购要求指定上游来源，就比较相应按量分组。已经使用某家网关的团队，先验证现有账户的对应分组，通常比为了一个相似组名再迁移一套账户更直接。以下按 2026 年 9 月 6 日公开文档区分配置，选择方法与上线门槛属于工程建议，性能结论需来自你的实际业务样本。

先决定买哪种服务，再复制模型名

官方 gpt-image-2 支持图片生成和编辑，但第三方网关可能另外定义模型别名、参数范围与结算方式。官方模型能力只能作为参照，网关交付以具体产品文档和账户配置为准。OpenAI 模型说明

LaoZhang 的分组与规格来自其 GPT Image 2 文档；API易的分组与倍率见 官转模型说明；Packy 的配置见 GPT Image 接入文档。这些名称是各家控制台的配置，不是 OpenAI 通用档位。

最容易配错的是：把 GPTImage2 Enterprise 写进请求的 model，或者给 API易令牌套用 LaoZhang 的 Sora2Official 名称。分组由创建令牌时的账户配置决定，model 是请求里的模型标识。 Packy 的 sora 在这里是令牌组名，不能据此把请求改成视频接口。

对于没有既有供应商的团队，我会这样缩小选择：尺寸固定且每张预算明确，先验证按次产品；成本需要随输入图、质量和输出变化精算，先验证按量产品；合同明确要求上游来源，再以供应商的书面承诺和可核实材料筛选。公开的“Enterprise”名称或 1.2x 倍率，都不足以替你证明成功率、延迟和服务承诺。

国内网络能访问网关，也不能推出获得了 OpenAI 对中国大陆的直接支持。截至上述日期，官方支持地区清单未列中国大陆，并提示清单外访问或提供访问可能导致账户被限制。涉及客户原图、肖像或企业素材时，应在采购阶段确认数据处理地区、留存和删除方式，不能从域名或连通性推断这些属性。OpenAI API 支持地区

把配置作为一个整体保存

每套生产配置至少记录下面这些信息。Key 只放在后端密钥管理中，配置和日志保存 Key 的内部别名，不保存明文。

LaoZhang 文档给出的基地址是 https://api2.laozhang.ai/v1，生成路径 为 /v1/images/generations，编辑路径为 /v1/images/edits。API易官转基地址为 https://api.apiyi.com/v1。使 用 SDK 时，base_url 通常保留末尾 /v1；直接发 HTTP 时使用完整接口 URL。切换服务商时同时换地址和该服务商的 Key，不能混用。

第一轮只测试业务必须的字段。文生图成功后，再用真实的编辑素材测试 multipart 上传；需要蒙版、多图输入或其他可选参数，再逐项确认网关支持情况。不要为了“兼容 OpenAI”一次加入所有官方参数。官方 Images 指南展示了生成结果的 b64_json 解码和编辑上传方式，但网关可能只实现其中一部分。官方 Images 使用指南

下面的 Python 示例用于 API易官转 gpt-image-2 的单次联通验证，采用其建议的 360 秒读取超时，只读取 b64_json，不发送其不支持的 response_format。这个超时值来自该产品文档，不能直接视作其他网关的承诺。API易图片接口最佳实践

运行前安装 requests 和 Pillow，在后端环境设置 IMAGE_API_KEY。代码不会自动重试；一经运行会向服务商提交真实请求，可能产生费用。

python
import base64
import io
import os
from pathlib import Path

import requests
from PIL import Image

endpoint = "https://api.apiyi.com/v1/images/generations"
output = Path("acceptance-image.png")
if output.exists():
    raise SystemExit("输出文件已存在，请更换文件名，避免覆盖。")

response = requests.post(
    endpoint,
    headers={"Authorization": f"Bearer {os.environ['IMAGE_API_KEY']}"},
    json={
        "model": "gpt-image-2",
        "prompt": "为咖啡店创作一张产品海报，杯子旁准确写出：今日手冲。",
        "n": 1,
    },
    timeout=(15, 360),
)
# 保存便于查单的标识；不同网关未必返回此响应头。
print("HTTP:", response.status_code)
print("request_id:", response.headers.get("x-request-id", "未提供"))
response.raise_for_status()
result = response.json()
items = result.get("data")
if not isinstance(items, list) or len(items) != 1:
    raise RuntimeError("没有收到预期的一张图片结果，请保留记录查单。")
encoded = items[0].get("b64_json")
if not isinstance(encoded, str) or not encoded:
    raise RuntimeError("缺少 b64_json，请核对产品响应格式。")
raw = base64.b64decode(encoded, validate=True)
with Image.open(io.BytesIO(raw)) as im:
    im.load()  # 验证完整图片可解码，而不只检查文件头。
    print("图片:", im.format, im.size, "字节:", len(raw))
    im.save(output, format="PNG")
print("已保存:", output.resolve())

图片落盘后，还要打开成品检查文字、素材保留和业务要求；程序可解码不代表海报可用。示例也没有核对账单，x-request-id 缺失时应保留提交时间、账户、Key 别名和业务任务号，以便与供应商记录匹配。示例没有经过在线调用验证，不能据此认定该账户已通过接入验收。需要从原始 HTTP 请求开始排查，可参考图片生成 API 的 cURL 调用方法。

超时之后，先查结果再决定重试

图片生成适合由后端任务承接。前端创建任务后拿到你自己的任务号，定期查询你的后端；后端工作进程保持与图片 API 的请求连接，收到图后存入持久存储，再把任务改成完成。这样前端刷新或页面等待超时，不必立刻重新提交一张图。

这里有两个完全不同的任务号：业务任务号由你的系统创建；上游 task_id 只有服务商实际返回并提供查询接口时才存在。 API易文档明确说明其图片 API 为同步接口、无异步任务 ID，且断连丢失结果仍可能计费。给同步接口外面加一层队列，不会让上游自动拥有结果查询功能。

建议在你的任务表中区分这些状态：

对“结果未知”的任务，先用请求标识查是否完成、扣费以及是否能找回结果。如果该服务商没有查询或恢复能力，就保留未知状态，让应用按预设成本政策处理：等待人工查单，或明确接受可能重复付费后发起一个新的尝试。不要伪造一个上游轮询地址，也不要默认换网关能够取消原来的请求。

同一任务的重复点击，可以由你自己的数据库唯一约束或任务锁挡住；但这只能减少应用重复提交，不能证明上游会按幂等键去重。还要检查负载均衡、反向代理、工作进程和部署平台的连接及执行时限。仅把 Python 的读取超时改大，不能解决中间代理提前断开、进程被回收或任务租约过期的问题。

用有效交付成本做验收，不只看单价

按次和按量应放到同一业务口径下比较：

有效交付成本 = 本批次实际结算总额 ÷ 本批次验收通过并交付的图片数。

分子包含这批任务中已结算的失败尝试和重试费用，并扣除已实际到账的退款；尚未结算或退款未到账的任务单独列出，不能假设已退。分母按图片而不是 HTTP 请求数计，返回多张时要逐张验收。没有可交付图片时不计算一个看似正常的均价，应把该批次记为交付失败。

例如，假设一个批次有 100 次已结算请求，每次 0.03 美元，最终只有 90 张通过业务验收且交付，总费用为 3 美元，有效交付成本约为 0.0333 美元／张。这只是计算示例，100 次与 90 张不是任何服务商的实测成功率。按 tokens 结算也用实际账单代入，不能把宣传倍率直接当作每张价格。

生产验收可以按以下顺序执行，并给每批样本保留独立记录：

1. 单次闭环。 使用将要上线的配置生成一张业务图片，检查 HTTP、JSON、真实图片字节、解码、存储读取和最终结算。每层分别记录，避免用 HTTP 200 代替交付成功。
2. 参数与内容。 对必须的尺寸、质量、文字、编辑保留要求建立样例。指定尺寸时核对实际像素；不能只看请求体里有没有 size。若产品不支持该字段，换产品或调整业务要求，不能依赖“服务器没报错”。
3. 预计负载。 从低并发递增至业务预计峰值，记录从入队到可读取图片的总耗时、上游耗时、队列长度、交付通过率与结算。p95 按相同起止点计算，失败和超时单列，不能从延迟统计中消失后又被当作成功。
4. 故障与重复。 检查用户重复点击、工作进程重启、响应超时和存储失败。先用模拟响应验证状态流转，再决定是否承担真实故障演练费用；目标是每一次额外提交都有记录和原因。
5. 账单对齐。 逐项关联业务任务号、尝试次数、供应商请求号、配置版本、图像地址与费用。账单暂不可见就标为待核对，不补写为零费用。

上线门槛应由业务先定，再看测试结果。比如你要求每张海报包含指定中文、最长可等待多久、每张有效交付能接受多少费用，这些都应写成可判定的条件。没有通用的“跑通十张即可上线”，也不能只凭公开分组介绍对几家网关做稳定性排名。

切换生产时，连同参数和失败策略一起切

给每套配置一个版本号，让任务在创建时绑定版本。准备备用供应商时，用同一套代表性素材单独验收；如果备用只支持基础尺寸，主配置依赖 4K 或特定质量，必须提前决定是拒绝降级、向用户说明后降级，还是暂不切换。这项决定属于产品行为，不能隐藏在替换 Key 的代码里。

正式切换可先分配一小部分新任务到新配置，观察有效交付、等待时间和费用，再逐步扩大。比例和观察窗口按任务量与风险确定，不需要照搬固定百分比。达到回退条件时，让后续新任务恢复旧配置；已经发出的旧请求继续按其原状态处理，结果未知的任务进入查单流程。回退新流量不等于取消正在生成的图片。

一次可交接的上线记录，应该能回答：现在用哪套配置、哪些参数通过了业务验收、图片保存在哪里、未知结果谁处理、预算超出或错误增多时如何停止新提交，以及备用配置能交付哪些同等结果。做到这一步，网关与令牌分组的选择才真正进入了可维护的生产系统。