GPT Image 2 报 1024x576 invalid size：原因与修复方法

gpt-image-2 请求中的 size: "1024x576" 不符合官方尺寸要求：它只有 589,824 总像素，低于 655,360 的下限。宽和高都能被 16 整除、宽高比也是 16:9，这两项通过仍然不够。

如果最终交付必须是 1024×576，直接采用这条流程：用 1280x720 生成，再等比缩小为 1024×576。1280×720 符合文档中的尺寸规则，而且是满足这些规则的最小严格 16:9 尺寸。这里的“最小”指像素尺寸，不代表已经验证它最便宜或最快。

下文按截至 2026 年 9 月 8 日的 OpenAI 图像生成文档 解释规则；代码用于直接调用 OpenAI 的 Images API，未进行付费 API 实测。通过第三方平台或桌面客户端调用时，还需要核对它们自己的参数格式。

为什么 1024×576 无效，1280×720 却可以？

GPT Image 2 的自定义尺寸要同时满足以下条件：

官方还把超过 3,686,400 总像素的尺寸标为实验性。修复这次错误不需要升到这么大的图片。尺寸约束来源

这里的总像素就是“宽 × 高”，与 PNG 或 WebP 文件占多少 KB 不同。压缩文件、改 JPEG 质量或修改 DPI 都不会让 1024×576 越过这个像素下限。

同样，不要把所有报错都归为“边长不是 16 的倍数”。1920×1080 的问题在于 1080 不能被 16 整除；1024×576 的问题在于面积太小。1280×720 的高是 720，而 720÷16=45，因此它没有这个整除问题。

为什么最小严格 16:9 是 1280×720？

严格 16:9 的整数尺寸可写成宽 16n、高 9n。如果高也必须能被 16 整除，n 就必须是 16 的倍数，所以尺寸进一步写成 256k × 144k。

k=4 时是 1024×576，总像素不够；k=5 时是 1280×720，总像素达到 921,600，其他规则也满足。这说明不能靠给 1024×576 的某一边随意加 16，既修复错误又保持原来的比例。

根据最终用途选尺寸

下面的“有效”仅表示符合 OpenAI 文档中的数值限制，不保证每个转发平台都接受该值。

如果不希望裁掉画面，就从有效的 16:9 尺寸开始生成。1280×720 缩到 1024×576 时，两条边都乘以 0.8，不会拉长人物或压扁图形。

1024×640 也能满足生成尺寸限制，但后续处理不同：直接改成 1024×576 会改变比例；保持宽度裁剪则需要去掉 64 行像素，居中裁剪时上下各去掉 32 行。对于靠近边缘的字幕、按钮或人物，这可能切掉重要内容。只有接受这种取舍时，才选这条路径。

请求有效尺寸，再输出 1024×576 文件

下面示例把“生成尺寸”和“最终文件尺寸”分开处理。需要已设置好 OPENAI_API_KEY 环境变量、可用的 curl 和 Python 3。完整接入背景可参考站内 GPT Image 2 API 指南。

1. 在请求中明确使用 1280x720

OpenAI Images API 使用 POST /v1/images/generations。注意 size 是带英文小写 x 的字符串；不要在 JSON 里写排版用的乘号 ×。官方接口使用示例

bash
curl --fail-with-body -sS https://api.openai.com/v1/images/generations \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-image-2",
    "prompt": "一张用于科技文章的横版封面：干净的书桌、显示器与柔和的自然光，不需要文字。",
    "size": "1280x720",
    "output_format": "png"
  }' \
  -o response.json

如果命令返回错误，先打开 response.json 查看错误对象，不要继续执行图片解码。提示词负责描述画面，在提示词末尾加“1024×576”不能替代请求里的 size 校验，也不能保证文件像素尺寸。

2. 解码图片并等比缩小

安装本地处理库：

bash
python3 -m pip install Pillow

把以下代码保存为 resize_image.py。它会检查接口是否返回了图片，以及图片是否为预期的 16:9，避免客户端改写尺寸后仍然直接拉伸。

python
import base64
import io
import json
from pathlib import Path
from PIL import Image

response = json.loads(Path("response.json").read_text(encoding="utf-8"))
if response.get("error"):
    raise RuntimeError(response["error"])

encoded = response["data"][0]["b64_json"]
with Image.open(io.BytesIO(base64.b64decode(encoded))) as source:
    source.load()
    width, height = source.size
    if width * 9 != height * 16:
        raise ValueError(f"返回图片不是 16:9：{width}x{height}，请检查实际请求")
    if width < 1024 or height < 576:
        raise ValueError(f"返回图片小于目标尺寸：{width}x{height}")
    result = source.resize((1024, 576), Image.Resampling.LANCZOS)
    result.save("thumbnail-1024x576.png")

with Image.open("thumbnail-1024x576.png") as output:
    assert output.size == (1024, 576)
    print("已保存：", output.size)

执行 python3 resize_image.py 后，得到 thumbnail-1024x576.png。这一步只在本地缩放已生成的图片；如果已有合适的 16:9 原图，也可以直接用图片编辑器等比缩小，不必重新生成。

改成有效尺寸后还报错，检查实际发出去的请求

设置页面显示 1280×720，不一定意味着请求体真的用了这个值。先保留完整错误信息，再按下面顺序定位：

1. 核对地址与模型。上面的参数用于 OpenAI 的 /v1/images/generations 和 gpt-image-2。如果实际请求发到了其他平台，应按该平台的接口文档判断字段。
2. 检查最终请求体。查看客户端日志或浏览器开发者工具中的网络请求，确认 size 真的是 "1280x720"，而不是旧值 "1024x576"、默认正方形尺寸或 "16:9"。分享日志前移除 API Key 和其他凭据。
3. 判断平台是否支持自定义像素。某些平台用宽高比和分辨率档位组合，例如 APIMart 的对应接口使用 size: "16:9" 搭配 resolution。这套写法不能直接复制到上面的 OpenAI 请求中；同样，也不能假定它接受 1280x720。APIMart 参数文档
4. 按新的错误内容继续处理。如果错误已经变为身份验证、额度或模型权限问题，就转向相应原因。重复提交相同的无效尺寸或反复修改提示词，不会修正数值约束。

只有客户端可控时，才修改它的参数构造逻辑。如果工具只提供固定选项，先选它支持的横版尺寸，再确认返回文件的宽高比；不是 16:9 时，需要明确选择裁剪或留边，不能假装等比缩放就能得到任意比例。

常见补充问题

把 size 改成 auto 能直接得到 1024×576 吗？

不要把自动尺寸当作准确交付尺寸的承诺。如果业务要求文件必须为 1024×576，应在收到图片后读取实际宽高，并执行缩放或裁剪。已确定需要完整 16:9 画面的情况下，使用符合规则的明确尺寸更容易控制后续处理。

缩小后还需要检查什么？

确认实际文件是 1024×576，再检查上传端要求的格式与文件体积。生成接口的总像素限制、成品尺寸和上传端的 KB/MB 限额是三项不同条件；前两项正确后，文件过大应通过合适的格式或压缩参数处理。