GPT Image 2 支持尺寸：有效 size、自定义规则、4K 边界与 API 验证

用 GPT Image 2 生成图片时，先把 size 当成接口契约。当前常用示例包括 1024x1024、1536x1024、1024x1536、2048x2048、2048x1152、3840x2160、2160x3840 和 auto。如果要自定义宽高，还必须同时满足长边不超过 3840px、宽高都是 16 的倍数、长短边比例不超过 3:1、总像素在 655,360 到 8,294,400 之间。

所以，“支持所有尺寸”不能理解成任意尺寸都能写。3840x2160 和 2160x3840 是横向、竖向 4K 的直接示例，4096x2160 这种常见 4K 说法反而会因为长边超过 3840 而不适合作为 GPT Image 2 的直接 size。随后要保存模型返回的 base64 图像数据，并用图片库读取真实宽高。只要保存后的文件不是请求的像素，或者调用因为尺寸、账号权限、质量档位而失败，就不要把它当作已经完成的生产素材。

这件事还要分清路线。Image API 适合一次性生成或编辑，Responses API 适合把图像生成放进对话、代理或多工具流程。两条路线都要遵守相同的尺寸边界，并且在输出大于 2560x1440 时把结果当作需要验证的实验性输出。

不要只在 prompt 里写“高清”或“4K”。真正控制像素的是 API 请求里的 size，真正确认交付的是你把返回结果保存成文件以后读取到的宽高。

支持尺寸速查：示例尺寸和自定义规则

如果只是探索构图，1024x1024、1536x1024、1024x1536 和 auto 更适合做第一轮尝试。它们能让你先判断 prompt、主体、构图和文字是否靠谱，不必一开始就承担 4K 输出的延迟和成本。

如果已经进入高分辨率交付，2048x2048 适合方形母版，2048x1152 适合 16:9 高分辨率网页图，3840x2160 和 2160x3840 才是原生 4K 测试。注意这些只是常用示例，不是唯一可用比例；真正的边界是长边、16 倍数、比例和总像素四项规则。

先把高清目标写进 size，不要只写进提示词

提示词可以描述画面内容、风格、文字和构图，但不能可靠地指定最终像素。你可以写“generate a 4K poster”，模型可能理解为清晰、细节多或适合大屏，却不等于返回的 PNG 就是 3840 像素宽。生产请求必须把分辨率写进 size。

最稳的第一轮测试是横向 3840x2160 和竖向 2160x3840。它们的长边等于 3840，短边也在合理范围内，便于你在保存后直接比较宽高。自定义尺寸可以用，但要先检查长边、16 的倍数、长短边比例和总像素。

把 size 当成接口契约以后，团队沟通也会更清楚。设计同事拿到的是目标画布，工程同事拿到的是可验证参数，内容同事不会用“高清”“4K感”这类词代替像素要求。

实际交付里的“高清图片”经常混合了清晰度、尺寸、压缩率和展示入口四件事。发布流程要先把它收束成可执行目标：请求尺寸是多少、保存后的原始文件是多少、网页或 CDN 有没有再压缩。只有这三项同时可查，高清输出才不是一句营销描述。

这也让排错更直接：日志里先看实际发送的 size、quality 和保存后的宽高，再判断问题来自提示词、账号访问还是下游压缩。

hljs js复制
const result = await client.images.generate({
  model: "gpt-image-2",
  prompt: "A clean product hero image with precise Chinese headline text.",
  size: "3840x2160",
  quality: "high"
});

哪些 4K 和自定义尺寸可以通过

GPT Image 2 的自定义尺寸不是“想写多少就写多少”。关键边界有四个：任一边不能超过 3840 像素，宽和高都应该是 16 的倍数，长边与短边的比例不能超过 3:1，总像素还要落在允许区间内。

3840x2160 和 2160x3840 是最容易解释的 4K 形态。4096x2160 虽然也常被市场称作 4K，但长边超过 3840，不适合作为 GPT Image 2 的直接 size。3840x1200 看似合理，也要确认比例和总像素。

发布系统最好在调用前做本地校验。这样无效请求不会进入队列，也不会在批量任务里把错误放大。校验失败时给出具体原因，而不是只把 API 错误转发给编辑或设计同事。

hljs js复制
function isValidImageSize(width, height) {
  const pixels = width * height;
  const longEdge = Math.max(width, height);
  const shortEdge = Math.min(width, height);
  return longEdge <= 3840 &&
    width % 16 === 0 &&
    height % 16 === 0 &&
    longEdge / shortEdge <= 3 &&
    pixels >= 655360 &&
    pixels <= 8294400;
}

Image API：最短的直接生成路线

如果任务只是“给一个提示词，拿到一张 4K 图”，Image API 是最短路线。请求里放 model、prompt、size、quality，返回后把 base64 写成文件，再读取宽高。这个流程容易封装，也容易做失败重试。

直接生成路线的优势是边界清楚：失败通常发生在尺寸、账号访问、内容安全、超时或成本预算上。你可以在调用前校验尺寸，在调用后校验文件，在任务层记录 prompt、size、quality、输出格式和真实像素。

不要在第一版里同时打开太多变量。先用一个稳定 prompt、一个合法 4K 尺寸和一个质量档位跑通。确认保存、预览、压缩和上传都工作以后，再加入参考图、编辑、批量任务或不同格式。

hljs js复制
import fs from "node:fs";

const image = result.data[0];
fs.writeFileSync("gpt-image-2-4k.png", Buffer.from(image.b64_json, "base64"));

Responses API：把生图放进多步工作流

当图像生成只是应用的一步，Responses API 更合适。比如用户先描述商品，模型整理卖点，再生成海报图，最后给出文案和投放建议。图像工具在这个流程里不是独立脚本，而是多工具回答的一部分。

多步路线仍然要显式设置图像工具的尺寸。不要让上游文本模型用自然语言“请求 4K”后就结束。工具调用本身必须带上合法 size，并且输出仍然要保存、读取和验证。

这条路线的主要风险是责任不清：到底是文本步骤失败、图像工具失败、文件保存失败，还是前端展示缩放失败。日志里要分别记录工具参数、工具返回、保存路径、文件像素和用户可见 URL。

hljs js复制
const response = await client.responses.create({
  model: "gpt-5.4",
  input: "Create a launch poster and explain the production notes.",
  tools: [{ type: "image_generation", model: "gpt-image-2", size: "3840x2160" }]
});

质量、格式和透明背景的边界

quality 可以用 low、medium、high 或 auto。4K 并不自动等于最高质量，最高质量也不保证每个细节都适合发布。低质量适合快速探索构图，高质量适合最后输出，但成本和延迟都要重新评估。

output_format 和压缩适合放在交付环节考虑。PNG 更适合需要少压缩或后处理的图，JPEG 或 WebP 更适合网页加载。无论哪种格式，都不要在压缩后忘记再次检查文件大小和视觉细节。

GPT Image 2 不支持透明背景。如果工作流需要透明 PNG，应该把这件事拆到后处理：先生成主体清晰的图，再用抠图、蒙版或设计软件处理透明层。不要把“transparent background”当成模型参数承诺。

费用也不能只按分辨率一句话概括。图像输入、图像输出、文本输入、质量档位、编辑流程和批量方式都会影响成本。涉及价格的内容要以当次官方价格页或供应商账单为准。

什么时候用原生 4K，什么时候先做 2K 母版

原生 4K 适合尺寸本身就是交付条件的任务，例如横幅、展板、海报预览或需要直接给设计系统下游消费的素材。它的好处是流程简单，坏处是每次失败都更贵，等待时间也可能更长。

2K 母版加放大适合创意还没有锁定、画面里有文字、人物手部或复杂 UI 的任务。你可以先用较低成本跑多个版本，选中构图和文字最稳定的一张，再用受控的放大工具做最终尺寸。

判断标准不是哪条路线听起来更高级，而是你最怕失去什么。如果最怕像素不足，直接 4K。最怕文字变形和构图反复，就先做 2K 母版。最怕账单不可控，就把探索和最终输出拆成两个预算。

保存以后必须验证文件

API 返回成功只说明模型给了结果，不等于你的发布资产已经合格。保存后至少读取三件事：文件是否存在、宽高是否等于请求值、格式是否是预期格式。如果网页还会二次压缩，还要检查压缩后的展示版本。

验证可以放进 CI 或后台任务。生成完成后读取文件元数据，写入数据库或 flomo 证据，再让编辑预览。这样后面做本地化图片、社交封面或 CDN 转换时，能知道哪一步改变了尺寸。

如果尺寸不对，先看请求参数而不是重写 prompt。常见原因包括 size 拼写错误、使用了不支持的尺寸、长边超过 3840、组织没有模型访问权限、或者前端展示时用了裁切版本。

排查尺寸不对或请求失败

第一类问题是请求没有发出合法尺寸。日志里应记录原始 width、height、校验结果和发送给 API 的字符串。只记录“4K failed”没有调试价值，因为它无法区分尺寸无效、权限问题和模型暂时失败。

第二类问题是结果生成了，但下游改坏了文件。常见位置包括图片压缩、CMS 上传、Open Graph 裁切、移动端 srcset 和设计工具导出。你要同时测原始文件和最终展示文件，不能只看浏览器里缩放后的预览。

第三类问题是质量不够。尺寸正确但文字糊、边缘脏或构图不稳定时，不要盲目提高尺寸。先收紧 prompt、减少画面里的文字量、固定排版，再决定是否用 high 或 2K 母版加放大。

FAQ

GPT Image 2 生成 4K 图像只需要在 prompt 里写 4K 吗？

不够。prompt 可以描述意图，但像素要由 API 的 size 控制。请求后还要保存文件并验证宽高。

3840x2160 和 2160x3840 都能用吗？

可以把它们作为横向和竖向 4K 的首选测试尺寸。自定义尺寸仍要满足长边、16 倍数、比例和总像素规则。

为什么 4096x2160 不适合直接写？

GPT Image 2 的尺寸规则要求任一边不超过 3840。4096 的长边超过这个边界，更适合先生成有效尺寸再放大。

Image API 和 Responses API 选哪个？

单次生成或编辑先用 Image API。对话、代理、多工具应用里再用 Responses API 的图像工具。

GPT Image 2 可以直接输出透明背景吗？

不可以。需要透明背景时，把主体生成和透明处理拆开，用后处理或设计工具完成。

原生 4K 失败时应该怎么办？

先确认 size 是否合法、账号是否有权限、文件保存是否正确。仍不稳定时，先生成高质量 2K 母版，再做受控放大。