用 GPT Image 2 生成 4K 图像时,第一步不是把“4K”写进提示词,而是在请求里设置合法的 size,例如 3840x2160 或 2160x3840。这两个尺寸分别覆盖常见横向和竖向 4K 输出,适合先做可重复的 API 测试。
随后要保存模型返回的 base64 图像数据,并用图片库读取真实宽高。只要保存后的文件不是请求的像素,或者调用因为尺寸、账号权限、质量档位而失败,就不要把它当作已经完成的 4K 工作流。
这件事还要分清路线。Image API 适合一次性生成或编辑,Responses API 适合把图像生成放进对话、代理或多工具流程。两条路线都要遵守相同的尺寸边界,并且在输出大于 2560x1440 时把结果当作需要验证的实验性输出。
| 目标 | 应该先做什么 | 为什么 | 停机条件 |
|---|---|---|---|
| 横向 4K 图 | size: "3840x2160" | 这是官方示例中的 16:9 4K 形态 | 保存后不是 3840x2160 就不要发布 |
| 竖向 4K 图 | size: "2160x3840" | 适合海报、移动端和长图 | 下游裁切会破坏信息时改尺寸 |
| 应用内多步生成 | 用 Responses API 的 image 工具 | 可以把图像生成放进对话、工具链或代理流程 | 拿不到可测量文件就先停 |
| 质量优先的大图 | 先做 2K 母版再评估放大 | 文字、构图和细节更容易先锁定 | 放大后文字变形就重生成 |
不要只在 prompt 里写“4K”。真正控制像素的是 API 请求里的 size,真正确认交付的是你把返回结果保存成文件以后读取到的宽高。
先把 4K 写进 size,不要只写进提示词
提示词可以描述画面内容、风格、文字和构图,但不能可靠地指定最终像素。你可以写“generate a 4K poster”,模型可能理解为清晰、细节多或适合大屏,却不等于返回的 PNG 就是 3840 像素宽。生产请求必须把分辨率写进 size。
最稳的第一轮测试是横向 3840x2160 和竖向 2160x3840。它们的长边等于 3840,短边也在合理范围内,便于你在保存后直接比较宽高。自定义尺寸可以用,但要先检查长边、16 的倍数、长短边比例和总像素。
把 size 当成接口契约以后,团队沟通也会更清楚。设计同事拿到的是目标画布,工程同事拿到的是可验证参数,内容同事不会用“高清”“4K感”这类词代替像素要求。
hljs jsconst 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 jsfunction 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;
}
| Case | Use it? | Why | Check |
|---|---|---|---|
| 3840x2160 | yes | standard landscape 4K | verify decoded width and height |
| 2160x3840 | yes | portrait 4K within the same edge limit | confirm downstream crop rules |
| 4096x2160 | no | the long edge exceeds 3840 | use a valid 3840-edge size or upscale |
| 3840x1200 | depends | must satisfy aspect and total-pixel rules | check 3:1 ratio and pixel floor |
Image API:最短的直接生成路线
如果任务只是“给一个提示词,拿到一张 4K 图”,Image API 是最短路线。请求里放 model、prompt、size、quality,返回后把 base64 写成文件,再读取宽高。这个流程容易封装,也容易做失败重试。
直接生成路线的优势是边界清楚:失败通常发生在尺寸、账号访问、内容安全、超时或成本预算上。你可以在调用前校验尺寸,在调用后校验文件,在任务层记录 prompt、size、quality、输出格式和真实像素。
不要在第一版里同时打开太多变量。先用一个稳定 prompt、一个合法 4K 尺寸和一个质量档位跑通。确认保存、预览、压缩和上传都工作以后,再加入参考图、编辑、批量任务或不同格式。
hljs jsimport 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 jsconst 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 母版。最怕账单不可控,就把探索和最终输出拆成两个预算。
| Production need | First route | Reason | Stop rule |
|---|---|---|---|
| Direct 4K file from one request | Image API | one generation call controls size directly | stop if decoded file is not requested size |
| Agent or multi-step app | Responses API image tool | image generation can sit beside text and tools | stop if tool result is not saved and measured |
| Large format from best-looking draft | 2K master plus upscale | often more controllable for text and fine detail | stop if upscaler changes text or layout |
| Unclear access or billing | small smoke test | org verification and cost vary by account | stop before batch spending |
保存以后必须验证文件
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 母版,再做受控放大。



