GPT Image 2 生成图片太慢？试试调整画质和尺寸

GPT Image 2 生成慢时，先检查 quality 和 size，再排查整个请求过程。 2026 年 9 月 7 日的 Ofox 1024×1024 测试中，high 耗时 117.1–132.1 秒，low 为 16.6–19.6 秒。质量档位值得优先测试，但不能把每次慢请求都归因于 high。

本文面向选择生图档位和排查 API 延迟的开发者。我们于 9 月 8 日复核了六条保存的响应和原始客户端耗时日志，没有新增付费测试。

GPT Image 2 不同 quality 的耗时与输出费用

原实验通过 Ofox /v1/images/generations 调用 openai/gpt-image-2，使用相同提示词、固定 1024×1024，每档请求两次。

六张 PNG 均重新解码确认为 1024×1024，同档两次图片 token 相同。费用按当时目录的图片输出 $30/M 计算，不含输入；每条响应另记录了 14 个文本输入 token。

OpenAI 官方表格给出的三个方图档位约为 $0.006、$0.053、$0.211，与上表四舍五入后吻合。供应商当前信息可查看 Ofox GPT Image 2 模型页。

high/low 的 token 比值约为 35.84 倍，平均客户端耗时比值约为 6.88 倍。两者并不支持原文所称的近似线性关系。每档两次测量也不能代表延迟分布或服务承诺；客户端总耗时包含网络、供应商等待和生成处理。

省略参数的那次请求返回了什么

同时省略 quality 和 size 的留存响应包含：

{"quality":"low","size":"1322x1190","usage":{"output_tokens":201,"output_tokens_details":{"image_tokens":201}}}

PNG 实际尺寸同样为 1322×1190。这直接证明该次响应标记为 low，但它与 1024×1024 对照组的尺寸不同，不能仅因 201 接近 196，就推导所有提示词、供应商或未来请求的默认档位。

需要可复现行为时，应显式设置两个参数，并检查返回值。

如何降低延迟

草稿可从以下 Ofox 请求开始：

curl -X POST https://api.ofox.ai/v1/images/generations \
  -H "Authorization: Bearer $OFOX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"openai/gpt-image-2","prompt":"A single red apple on a white table","size":"1024x1024","quality":"low"}'

如果 low 的结果够用，可用于低成本迭代；medium、high 则应按实际素材需求评估。这是工作流建议，不是图像质量排名，原测试没有对画面可用性或偏好打分。

仍然慢时，依次记录供应商、模型、提示词、尺寸、档位、耗时及状态；先确认成功、超时还是明确错误，再决定重试。重试可能新增一次付费生成。用多个条件相同的成功请求作比较，并把失败请求单独记录。

OpenAI 文档指出复杂提示词可能延长处理时间。因此还应检查提示词复杂度、网络和供应商状态，不能据本次固定提示词实验断言它们影响很小。

产品无法让用户长时间等待时，可由自己的后台任务执行生图，并提供应用自身的任务状态接口。这不意味着 Ofox images 端点已经支持原生异步任务 ID 或轮询。

与 Nano Banana 2 如何比较

Nano Banana 2 计费复核记录了 1K 图片的 1,120 token，按当时费率图片部分为 $0.0672，位于本例 GPT Image 2 medium 与 high 之间。

这只是指定设置下的费用比较，不能证明同等画质或相对速度。不同模型的 token 不是统一的时间单位，Nano Banana 2 也支持 thinking，不能描述为所有计算与费用恒定。调用前查看其模型页，不要直接套用 GPT 参数。

选择生产路由时，应同时比较自己的素材可用率、完整扣费与请求耗时。

相关阅读

• 英文版 GPT Image 2 生图失败排查
• 英文版 GPT Image 2 功能指南

本文依据 9 月 8 日更正后的英文版本地化：补充省略参数请求的真实尺寸，删除普遍默认 low、线性延迟机制和跨模型速度排名。保留的耗时仅为 9 月 7 日单一路由的历史观察，价格仅计图片输出。