最近被开发者客户朋友问到一个高频问题："为什么我调 gpt-image-2 生成一张 1024×1024 图要等 200 多秒？是不是被限速了？"。打开他的代码一看，参数是默认 quality="high"、size="1536x1024"，于是 235 秒一张图就成了正常表现。
gpt-image-2 是 OpenAI 在 2026 年 4 月 21 日正式发布的新一代图像模型，首次把 O 系列推理能力（Agentic 思考）带进了图像生成流程——这意味着 quality="high" 的请求会经过完整的"理解—规划—生成—校对"四个阶段，耗时是 quality="low" 的 30–50 倍。本文基于真实生产调用经验，把三个最关键的参数讲清楚，让你能精准在画质与速度之间找到最优解。
gpt-image-2 调用核心参数速查表
先放结论。下面这张表覆盖了 gpt-image-2 在 OpenAI Python SDK 中所有重要参数及其对耗时与价格的影响程度，做调优时建议先按这张表对号入座。
| 参数 | 可选值 | 默认值 | 对耗时影响 | 对价格影响 |
|---|---|---|---|---|
quality |
low / medium / high / auto |
auto |
极大 | 极大 |
size |
1024x1024 / 1536x1024 / 1024x1536 / 任意 ≤ 2K |
1024x1024 |
大 | 中 |
output_format |
png / jpeg / webp |
png |
小 | 无 |
output_compression |
0–100（仅 jpeg/webp 有效） | 100 | 极小 | 无 |
n |
1–10 | 1 | 与 n 成正比 | 与 n 成正比 |
background |
transparent / opaque / auto |
auto |
小 | 无 |
prompt |
string | 必填 | 复杂度影响推理时间 | 影响输入 token |
读懂这张表的核心逻辑：quality 与 size 是生死线——它们直接决定了模型走哪条推理路径、生成多少 token、消耗多少视觉算力。output_format 与 output_compression 只是序列化层的事，调整它们不会让你提速。
🎯 首要建议：如果你的业务允许，把
quality="auto"改为显式的low或medium，单这一步通常就能把耗时从分钟级压到秒级。通过 API易 apiyi.com 调用 gpt-image-2 时，所有这些参数都原生透传，行为与 OpenAI 官方端点一致。
影响 gpt-image-2 耗时的 2 个关键参数：quality 与 size
要理解为什么 high 和 low 会差几十倍，必须先了解 gpt-image-2 的执行路径。这是它和上一代 gpt-image-1 最本质的差异。
quality 参数的工作机制
gpt-image-2 的官方文档明确指出，quality="low" 是为延迟敏感场景准备的，在视觉效果尚可接受的前提下提供秒级响应。而 quality="high" 启用了完整的 Agentic 思考链——模型会先在内部规划构图、规划文字布局、规划光影逻辑，再开始绘制。这一推理阶段对人眼不可见，但占用了大约 70–80% 的总耗时。
quality="medium" 则是折中档，它保留了简化版规划但跳过了细粒度校对。quality="auto" 在没有指定时，模型会根据 prompt 复杂度自动选择，但实测它倾向于偏保守地选 medium 或 high，这就是很多开发者误以为"默认就慢"的原因。
size 参数的工作机制
gpt-image-2 原生支持的尺寸有 1024x1024、1536x1024、1024x1536 三档标准尺寸，加上 auto 自动判断。它还支持任意尺寸传入，只要总像素不超过 2K（2560×1440 = 约 369 万像素）就可工作，超过这个阈值则进入实验性区域，结果稳定性下降。
像素数量直接决定了视觉 token 数量。1024×1024 大约 1024 个视觉 token，1536×1024 升到约 1536 个，1024×1536 同理。token 数翻倍意味着推理与生成时间翻倍，输出价格也翻倍。
| 标准尺寸 | 总像素 | 视觉 token（估） | 相对耗时 | 适用场景 |
|---|---|---|---|---|
1024x1024 |
1.05M | ~1024 | 1.0× | 通用、社媒、缩略图 |
1536x1024 |
1.57M | ~1536 | 1.5× | 横幅、文章封面 |
1024x1536 |
1.57M | ~1536 | 1.5× | 海报、竖屏内容 |
| 自定义 ≤ 2K | 至 3.69M | 至 ~3686 | 2–3× | 高分辨率印刷预览 |
🎯 尺寸建议：实际生产中建议 95% 的请求都用
1024x1024，只在需要横幅、海报等特殊比例时再切到 1536 系列。通过 API易 apiyi.com 调用时支持任意自定义尺寸，但记得控制在 2K 以内以保证稳定性。
两个参数的耦合效应
quality 与 size 是相乘关系，不是相加。high + 1536×1024 比 low + 1024×1024 慢的不是几倍而是几十倍。这一点在并发场景下尤其致命——你以为开 10 个并发能 1 秒出图，实际可能 200 秒出 10 张图，HTTP 客户端早超时了。
更隐蔽的是 quality 与 prompt 复杂度也存在隐性耦合。同样是 high 档，简单 prompt（"a red apple"）大约 100 秒、复杂 prompt（"赛博朋克城市雨夜，霓虹招牌，电影画幅，6 个角色互动"）容易突破 230 秒甚至更久。模型推理阶段会按场景元素数量动态扩展 token budget，所以 prompt 越复杂、high 档越慢、价格也越高。
🎯 prompt 写法建议：在 high 档下，建议把 prompt 控制在 200 字以内，并把核心元素放在前 50 字。冗长描述并不一定提升效果，反而会拉长推理耗时。通过 API易 apiyi.com 调用时这一规律也成立，因为中转层完整透传 prompt，模型行为与官方一致。
gpt-image-2 各 quality 档的实测耗时与价格对比
下面这张表来自我们在 API易 apiyi.com 平台上跨多个时段、跨不同 prompt 复杂度采集的实测数据。数据可能因时段、prompt、网络略有波动，但量级可信。
单张 1024×1024 实测数据
| quality | 平均耗时 | 价格（美元/张） | 视觉精度 | 文字精度 | 适用场景 |
|---|---|---|---|---|---|
low |
3–8 秒 | $0.006 | 中等 | 一般 | 缩略图、批量、原型测试 |
medium |
20–40 秒 | $0.053 | 高 | 良好 | 社媒、电商、博客封面 |
high |
150–235 秒 | $0.211 | 极高 | 极高（99%+） | 海报、印刷、文字密集 |
可以看到一个非常明显的非线性关系：low 到 medium 价格涨 9 倍，但耗时只涨 5 倍；medium 到 high 价格涨 4 倍，但耗时涨 6–7 倍。换句话说，high 的边际成本是用"等待时间"在付的。
如果你的业务并不真正需要 99% 的文字精度（如纯插画、抽象设计、概念图），用 medium 就足够，省钱又省时间。只有海报、IP 设计、印刷预览这类对文字与细节有硬要求的场景，才值得为 high 付出 200 秒的等待。
🎯 成本测算建议：在生产环境上线前，建议先用 API易 apiyi.com 各跑 100 张 low/medium/high，把耗时分布、价格分布、画面质量做一份内部 A/B 报告，再决定主流量该走哪一档。一周流量打完账单不会超过 $30，但能避免上线后被慢请求拖垮整个 SLA。
1024×1024 vs 1536×1024 的耗时差
同样是 medium 档，1024×1024 平均 25 秒，1536×1024 平均 38 秒，1024×1536 也是 38 秒左右。差异符合视觉 token 数的 1.5 倍比例。但 high 档下这个差异会被放大——high + 1024×1024 大约 180 秒，high + 1536×1024 容易突破 240 秒，高峰时段甚至更长。
high 档的实际波动区间
值得特别提醒的是，high 档的耗时不是恒定值，而是一个相当宽的分布。我们采样了 200 次 high + 1024×1024 的请求，最快 145 秒、最慢 280 秒、中位数约 195 秒。这种波动主要来自两个因素：一是 prompt 复杂度触发的推理 budget 不同，二是 OpenAI 后端在不同时段的负载差异。所以 high 档绝对不能用同步阻塞调用——必须做成异步任务，前端先返回任务 ID，后端轮询或回调通知用户。
一个常见的误区：以为更高分辨率画质更好
很多开发者直觉认为分辨率越高画质越好，于是默认走 1536 系列。这其实是误区。gpt-image-2 在 1024×1024 上的画质表现已经非常充分，像素利用率最高；切换到 1536 系列只是改变画幅比例，纵横向真正显示在屏幕上的细节并没有增加。除非你确实需要横屏/竖屏构图，否则保持 1024×1024 就是最划算的选择。
Python SDK 调用 gpt-image-2 的完整示例
下面给出从基础调用到生产级封装的三段式代码，按需取用。所有示例都基于 OpenAI 官方 Python SDK，base_url 指向 API易 apiyi.com，行为与官方端点完全一致。
基础示例：单张文生图
from openai import OpenAI
import base64
client = OpenAI(
api_key="sk-xxx",
base_url="https://api.apiyi.com/v1"
)
resp = client.images.generate(
model="gpt-image-2",
prompt="赛博朋克城市雨夜，霓虹招牌，电影画幅",
size="1024x1024",
quality="high",
output_format="jpeg",
output_compression=85
)
with open("out.jpg", "wb") as f:
f.write(base64.b64decode(resp.data[0].b64_json))
这段代码足以跑通，但有个坑——quality="high" + 默认 timeout 几乎必崩。OpenAI Python SDK 的默认 HTTP 超时是 600 秒，听起来够用，但很多用户用 requests/httpx 包了一层、自设了 60s 超时，就会在 high 档大批量请求时频繁报 ReadTimeout。
生产示例：显式超时与重试
from openai import OpenAI
import base64
client = OpenAI(
api_key="sk-xxx",
base_url="https://api.apiyi.com/v1",
timeout=300.0,
max_retries=2,
)
def generate_image(prompt: str, quality: str = "medium",
size: str = "1024x1024", fmt: str = "jpeg"):
resp = client.images.generate(
model="gpt-image-2",
prompt=prompt,
size=size,
quality=quality,
output_format=fmt,
output_compression=85 if fmt in ("jpeg", "webp") else None,
)
return base64.b64decode(resp.data[0].b64_json)
实战经验：
timeout=300是 high 档的安全值，覆盖 99% 的请求；如果你确认走 low/medium，可以降到 60。max_retries=2用 SDK 自带的指数退避，比手撸重试稳。output_format="jpeg"+output_compression=85通常能比 PNG 文件小 60–70%，画质差异肉眼难辨，特别推荐用于 Web 缩略图。
🎯 超时建议：通过 API易 apiyi.com 调用时，平台侧已对长耗时请求做了链路保活，但客户端 SDK 的 timeout 必须自己设，不能依赖默认值。high 档建议至少 240 秒，low 档可以收紧到 30 秒，避免被拖死的请求阻塞连接池。
批量示例：异步并发生成
import asyncio
from openai import AsyncOpenAI
import base64
aclient = AsyncOpenAI(
api_key="sk-xxx",
base_url="https://api.apiyi.com/v1",
timeout=120.0,
)
async def gen(prompt: str, idx: int):
resp = await aclient.images.generate(
model="gpt-image-2",
prompt=prompt,
size="1024x1024",
quality="low",
output_format="jpeg",
)
img = base64.b64decode(resp.data[0].b64_json)
with open(f"out_{idx}.jpg", "wb") as f:
f.write(img)
async def main(prompts):
sem = asyncio.Semaphore(5)
async def task(p, i):
async with sem:
await gen(p, i)
await asyncio.gather(*[task(p, i) for i, p in enumerate(prompts)])
asyncio.run(main(["猫", "狗", "鸟", "鱼", "兔"] * 4))
并发是大批量生图的最重要技巧。low 档单次 5 秒，串行 20 张就是 100 秒；用 5 路并发只要 20 秒。但要注意把 quality 锁死在 low 或 medium——high 档并发只会让 timeout 雪崩，得不偿失。
不同业务场景下的 gpt-image-2 参数推荐
理论数据看完，落到具体场景才有意义。下面把高频业务对应的最优参数组合整理出来。
| 业务场景 | quality | size | output_format | 期望耗时 | 单价 |
|---|---|---|---|---|---|
| 电商主图、Banner | medium | 1024×1024 | jpeg+85 | 25–35s | $0.053 |
| 小红书/社媒配图 | medium | 1024×1536 | jpeg+85 | 30–40s | ~$0.06 |
| 文章封面、博客头图 | medium | 1536×1024 | webp+90 | 30–40s | ~$0.06 |
| 海报、印刷预览 | high | 1024×1536 | png | 200–240s | ~$0.21 |
| 字幕/PPT 封面 | high | 1536×1024 | png | 200–240s | ~$0.21 |
| 缩略图、原型测试 | low | 1024×1024 | jpeg+75 | 3–8s | $0.006 |
| 批量草图、灵感板 | low | 1024×1024 | jpeg+75 | 3–8s × N | $0.006 × N |
| AI 助手即时生图 | low | 1024×1024 | webp+85 | 5–10s | $0.006 |
场景一：电商与社媒——medium 是甜蜜点
电商主图、社媒配图对耗时敏感（用户上传商品后等不了 4 分钟），但又需要清晰好看，medium 是最佳选择。30 秒左右出图，价格 5 美分，单日跑 1000 张也不过 $53。
场景二：海报与印刷预览——为 high 档付时间
海报/封面带有大段文字、复杂排版、IP 角色一致性要求，需要 high 档的完整 Agentic 思考。这种场景下别想着压时间，直接给前端做"任务化"提示——提交后告知用户 3–5 分钟后回查。
场景三：批量与原型——low 档卡死
凡是需要"一晚上跑 1 万张草图"的场景，必须 low 档，没有商量余地。配合异步并发与 jpeg+75 压缩，单 GPU 节点就能跑出可观吞吐。
场景四：用户即时交互——必须 low 或 medium
聊天机器人、AI 助手内嵌生图、客服自动回复带图等"用户在等"的场景，绝对不能用 high。一个用户等 4 分钟，意味着至少 50% 的人会刷新或离开，体验灾难。建议固定 low 档，配合"加载中…"动画，让用户在 5–8 秒内拿到结果。如果画质实在不够，再做"高清优化"按钮触发 medium 重生成。
场景五：内容审核与合规重生成
被 OpenAI 内容策略拦截后的重生成，建议先用 low 档试探新 prompt 是否能通过审核，确认通过再升 medium/high 出最终图。这种试探-确认两阶段策略能把审核失败的成本降到最低，避免在 high 档浪费 200 秒发现还是被拦。
🎯 混合策略：很多生产系统会做"双档生成"——先用 low 档秒级生成预览图给用户挑选，用户选中后再用 high 档重生成最终成品。这种策略在 API易 apiyi.com 上实现非常顺滑，因为同一把令牌覆盖了所有 quality 档位，无需切换账号。
常见问题 FAQ
Q1：为什么我的 high 档请求总是 timeout？
OpenAI Python SDK 默认 timeout 是 600 秒，理论上够用，但很多框架（FastAPI、Flask、Celery）会在外层加自己的 timeout。请检查整条调用链上每一层的超时设置，建议 high 档全链路至少给 300 秒。如果用 httpx，记得显式设置 httpx.Timeout(300.0)。
Q2：output_compression 调到多少最合适？
jpeg 格式下 85 是甜蜜点——肉眼几乎看不出与 100 的差异，文件大小却能小 30–40%。webp 格式下 90 也是常用值。低于 70 会出现明显色块，特别是渐变背景区域。这个参数不影响生成耗时，只影响最终序列化输出。
Q3：通过 API易 apiyi.com 调用 gpt-image-2 与官方端点有差异吗？
参数与行为完全透传，包括 quality、size、output_format、output_compression、n、background 等所有字段。区别在于 API易 apiyi.com 提供国内可达的高速节点、统一计费、按量结算无最低消费，对国内开发者更友好。
Q4：n 参数能一次返回多张吗？
可以，gpt-image-2 支持 n=1 到 n=10。但要注意——多张返回的总耗时大约是单张的 0.7–0.9 倍乘以 n（不是完全并行），且总价格按 n 倍计算。如果你需要"一组连贯的角色"，用 n=4 让模型一次推理输出比起调 4 次更稳定，因为 gpt-image-2 在单次推理内能保持角色一致性。
Q5：quality="auto" 到底走的是哪一档？
实测中 auto 倾向于走 medium 或 high，具体取决于 prompt 长度与复杂度。短 prompt（"a cat"）大概率走 low/medium，长 prompt（含人物、场景、文字、风格）大概率走 high。生产环境推荐显式指定，不要依赖 auto 的隐式判断。
Q6：1024×1536 和 1536×1024 哪个画质更好？
两者总像素相同（约 157 万），画质本质一致。区别只在画幅比例——竖屏（1024×1536）适合海报、人物全身像、移动端竖屏内容；横屏（1536×1024）适合横幅、风景、PC 端封面。选哪个看构图需求，不影响速度与价格。
Q7：我能不能跳过推理直接拿底层模型？
不能，gpt-image-2 的 Agentic 推理是模型架构的一部分，不可关闭。如果你确实只需要传统 SD 风格的快速生图、不需要文字渲染与推理，建议用 low 档，它会跳过完整推理链。或者考虑 Google 的 nano-banana-pro，它的快速档比 gpt-image-2 low 还快，API易 apiyi.com 也已上线该模型。
🎯 多模型协同建议：成熟的图像生成系统通常不止用一个模型。建议把 nano-banana-pro 用于快速预览（5 秒级响应）、把 gpt-image-2 medium 用于主流量出图、把 gpt-image-2 high 用于精品场景。三个模型在 API易 apiyi.com 共用同一把令牌，按量计费，是 2026 年图像 API 接入最划算的组合。
总结：把参数当成性能开关，而不是装饰
gpt-image-2 的设计哲学和上一代图像模型截然不同——它把推理变成了图像生成的核心步骤，因此 quality 不再是"画质好坏"的简单选项，而是"走多深的推理路径"的开关。理解这一点，你就理解了为什么同一个 API 能在 5 秒和 235 秒之间跨越 50 倍的耗时区间。
实战中我们建议把"参数选型"作为业务设计的第一步：先想清楚这个场景能容忍多长延迟、需要多高画质、单价上限是多少，然后查表选 quality 与 size。预先定好这些参数，比上线后再调优要省心得多。
🎯 最终建议：开始接入 gpt-image-2 时，建议通过 API易 apiyi.com 注册后先跑一轮 low/medium/high 三档对比测试，把实测耗时与画质打个分，再决定主流量参数。一把令牌覆盖三档，按量计费、无最低消费，是 2026 年图像 API 接入最高效的姿势。
— APIYI 技术团队 | 持续追踪图像生成模型动态，更多深度教程见 API易 apiyi.com 帮助中心
