GPT Image 2.6 GIF API 教程：生成动图的参数、帧数上限和成本

截至 2026 年 11 月 5 日，用 API 让 GPT Image 2.6 生成 GIF 动图，只要在 POST /v1/images/generations 的请求里把 output_format 设为 "gif"，模型选 gpt-image-2.6-flare 或 gpt-image-2.6-sunburst，再用 frame_count（帧数）和 frame_duration_ms（每帧毫秒数）控制节奏。返回的 b64_json 解码后直接存成 .gif，就是一个无限循环播放的动图。按 OpenAI 的图片生成指南，编辑接口 /v1/images/edits 不输出 GIF，动图应从文字提示词生成。

帧数先控制在 16 以内：OpenAI 的图片生成指南写 frame_count 可取 2–64，API 参考却写 2–16，16 是两份文档都允许的上限。每个 GIF 花多少取决于计费方式：直连 OpenAI 按输出 token 计费，一个 512×512、9 帧、medium 的 GIF 约 $0.062；老张 API 的 gpt-image-2.6-web 每次固定 $0.03，但每帧至少 816×816；带 -vip 后缀的 2.6 模型不出 GIF。

2026 年 11 月 5 日通过 gpt-image-2.6-web 生成的 4 个 1024×1024 GIF，帧数和每帧时长都与请求一致，单个耗时 43–52 秒、体积 2–8 MB。其中按 OpenAI 建议写了"回到起始姿势"的 9 帧动图，回到第一帧时仍明显跳了一下，所以发布前值得用后文的脚本把首尾接缝检查一遍。

发出第一个 GIF 请求，把 b64_json 存成 .gif

最短的路径是直连 OpenAI 发一个 512×512、9 帧、每帧 200 毫秒的请求，播放一遍 1.8 秒。这个尺寸和帧数在 OpenAI 自己的示例和老张 API 文档团队 11 月 5 日的直连测试里都能出图，适合先确认账号和代码是通的。下面的命令需要 curl、jq 和 base64，Windows 上没有这几个命令时直接用后面的 Python 版本。

1. 设置 OpenAI 的 API key：export OPENAI_API_KEY="你的 key"。
2. 发送生成请求，把响应存成 gif.json。提示词按 OpenAI 的建议写明起始姿势、动作和"回到起始姿势"，并说明镜头不动：

curl --fail-with-body https://api.openai.com/v1/images/generations \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-image-2.6-flare",
    "prompt": "一只橘猫坐在窗台上，抬起右前爪向镜头招手，然后放下前爪回到起始姿势。镜头固定不动，扁平插画风格，浅蓝色纯色背景，动作循环流畅。",
    "output_format": "gif",
    "size": "512x512",
    "quality": "medium",
    "frame_count": 9,
    "frame_duration_ms": 200
  }' -o gif.json

3. 取出 data[0].b64_json，按 base64 解码写成文件：

jq -r '.data[0].b64_json' gif.json | base64 --decode > cat.gif

4. 用浏览器打开 cat.gif 看动作，再用后文"首尾接缝"一节的脚本核对帧数、每帧时长、循环标志和接缝比。

走老张 API 时，请求体不用改，只换地址和 key：把 https://api.openai.com/v1 换成 https://api.laozhang.ai/v1，key 用 OpenAI Official 分组的令牌，计费和 OpenAI 一样按 token。改用按次计费的 gpt-image-2.6-web 时，用 default 分组的令牌，model 改成 gpt-image-2.6-web，size 改成 1024x1024，文档示例里不传 quality；这条线路生成一次要半分钟以上，curl 加上 --max-time 300 比较稳妥。

说明：laozhang.ai 是我们自己的服务，其价格是平台报价，不是独立比较的结论。

Python SDK 不认 frame_count 时放进 extra_body

用 openai-python 时，frame_count 和 frame_duration_ms 已写进 API 参考，但你装的 SDK 版本未必已经认识它们；不认识时 Python 会报 unexpected keyword argument。SDK 跟进新参数有滞后，例如 SVG 用的 svg 参数到 3.46.0 才加入（见 OpenAI 开发者社区里关于 GPT Image 2.6 生成 SVG 的讨论帖）。最省事的办法是把两个 GIF 字段放进 extra_body，SDK 会原样附在请求体里，新旧版本都能用：

import base64
from openai import OpenAI

# 走老张 API 时加 base_url="https://api.laozhang.ai/v1"，并换成对应分组的 key
client = OpenAI(timeout=300)

result = client.images.generate(
    model="gpt-image-2.6-flare",
    prompt="一只橘猫坐在窗台上，抬起右前爪向镜头招手，然后放下前爪回到起始姿势。"
           "镜头固定不动，扁平插画风格，浅蓝色纯色背景，动作循环流畅。",
    size="512x512",
    quality="medium",
    output_format="gif",
    extra_body={"frame_count": 9, "frame_duration_ms": 200},
)

with open("cat.gif", "wb") as f:
    f.write(base64.b64decode(result.data[0].b64_json))
print(result.usage)  # 按 token 计费时，用 output_tokens 估算这一个 GIF 的成本

frame_count、frame_duration_ms、size 和 n 的取值范围

决定一个 GIF 的是四个字段：frame_count 管帧数，frame_duration_ms 管每帧停留多久，size 是每一帧的尺寸而不是整张动图的尺寸，n 是一次要几个动图。这四个数共用一份像素预算：OpenAI 指南写明帧数、帧尺寸和动图个数必须同时落在模型的尺寸上限和请求总像素预算之内，超了就减帧数、缩尺寸或减 n。下表按截至 2026 年 11 月 5 日的 OpenAI 图片生成指南、Images API 参考和老张 API 文档整理：

帧数、时长和尺寸之间的取舍很直接。所有帧是拼在一张大图上一起生成的，所以帧数越多，每帧能分到的像素越少：老张 API 文档写 1024×1024 下 64 帧约 2 分钟、约 18 MB，单帧会略糊。帧太小同样不行，老张 API 文档团队直连 OpenAI 时，256×256 只要 2 帧也报了 No supported sheet fits。播放一遍的时长等于帧数乘每帧时长，同样 1.8 秒，可以是 9 帧 × 200 毫秒，也可以是 18 帧 × 100 毫秒；后者更顺，但文件更大、生成更慢，直连 OpenAI 还会超出 API 参考的 16 帧。

ChatGPT 里动图的速度菜单（0.25×–2×）只是给已经画好的帧重新计时，不是 API 参数；API 的节奏在生成时就由 frame_duration_ms 定下，想换速度就重新请求。不写代码、直接在 ChatGPT 里做动图，见 ChatGPT 生成 GIF 动图怎么做：帧越多画面越小，调速度不会重画。

最多 16 帧还是 64 帧：OpenAI 指南和 API 参考不一致

直连 OpenAI 或走官方转发时，按 16 帧写代码最稳。截至 2026 年 11 月 5 日，OpenAI 图片生成指南的 GIF 一节写 frame_count 为 2–64，而 images.generate 的 API 参考写"Accepts integers from 2 through 16"，并标注 maximum: 16。两份都是 OpenAI 的第一方文档，16 帧以内在两份里都合法。

老张 API 文档团队 11 月 5 日的直连测试最多只用到 9 帧，16 帧以上在 OpenAI 接口上会不会被拒，目前没有可引用的结果。确实需要 17 帧以上时，把它当成实验功能，先用一个 512×512 的小请求试，并给 400 写好回退（例如自动降到 16 帧重发）。frame_duration_ms 也一样，指南写最长 2000 毫秒，API 参考只写了编码上限每帧 655,350 毫秒，保持在 2000 以内两边都不违规。

gpt-image-2.6-web 的规则另算。老张 API 文档写 2–64 帧，2026 年 11 月 5 日的测试里 65 帧返回 400，16 帧正常出图，17–64 帧这一段没有测，按文档 64 帧也能出图，只是更慢、更糊。

选哪条线路：直连 OpenAI、官方转发、gpt-image-2.6-web 还是 VIP

选线路先看两件事：每帧要多小，以及按 token 还是按次付费。要 512×512 这类小 GIF，只能用按 token 计费的 gpt-image-2.6-flare / gpt-image-2.6-sunburst（直连 OpenAI 或老张 API 官方转发）；帧够大（1024×1024 这一档）、想让每个 GIF 价格固定，用 gpt-image-2.6-web；带 -vip 后缀的 2.6 模型不出 GIF，请求会直接返回 400。下表截至 2026 年 11 月 5 日：

直连 OpenAI 时多一个门槛：API 参考在 frame_count 的说明里写了"Requires access to the GIF preview for the selected model"，也就是 GIF 目前可能要单独开通预览权限，哪些账号默认就有，公开文档没写。所以上线前先用上一节那个 512×512 的请求确认自己的账号能出 GIF，别等批量任务跑起来才发现。

官方转发的请求体、参数和返回与 OpenAI 完全相同，只换 base_url 和 key，适合已经按 OpenAI 写好代码、又需要小尺寸 GIF 的场景。gpt-image-2.6-web 则是固定价格换来几条限制：一定要传 size（不传时返回的 GIF 又小又不规则，例如 439×390）、n 只能为 1、高峰期大尺寸或多帧的请求可能返回 429。各线路的分组设置和完整示例见老张 API 的 GPT Image 2.6 接入文档。同一组官方模型还能直接输出 SVG 和做 markup 标注编辑，分别见 GPT Image 2.6 用 API 输出 SVG 和 GPT Image 2.6 的 markup 标注编辑 API。

说明：laozhang.ai 是我们自己的服务，其价格是平台报价，不是独立比较的结论。

一个 GIF 多少钱：按 token 约 $0.062，按次 $0.03

按 token 计费时，GIF 和静态图用同一个单价：截至 2026 年 11 月 5 日，OpenAI API 价格页上 GPT Image 2.6 的图片输出每 100 万 token $30，文本输入 $5。老张 API 文档团队 11 月 5 日直连 OpenAI 用 gpt-image-2.6-flare 生成 512×512、medium、9 帧的 GIF，用了 2,073 个输出 token，算下来 2,073 × $30 ÷ 1,000,000 ≈ $0.062；low、4 帧用了 1,172 个，约 $0.035。提示词的文字输入只有几十个 token，加起来不到 $0.001。

这两个数都是 512×512 的单次结果，换成更大的帧、更高的 quality 或更多帧，输出 token 会变，成本跟着变。作为参照，同一批测试里一张 1024×1024 medium 的静态图是 1,449 个 token、约 $0.043，也就是说一个 512×512 的 9 帧 GIF 比一张 1024 静态图还贵。上线前用自己的提示词跑一次，拿响应里的 usage.output_tokens 乘单价核对；走官方转发的 OpenAI Official Enterprise 分组再乘 1.2，同一个 9 帧 GIF 约 $0.075。

gpt-image-2.6-web 每次固定 $0.03，帧数、尺寸都不改变单价，2026 年 11 月 5 日的 4 次 GIF 测试也是按每次 $0.03 的标价计费。所以如果你本来就要 1024×1024 这类大帧，或者要十几帧，按次计费的价格更好预估；只有要比它的像素下限更小的 GIF 时，才必须走按 token 计费。GPT Image 2.6 各质量档比 2.5 贵多少、要不要换代，见 GPT Image 2.6 和 2.5 区别：low/medium 贵 3–4 倍，high 档起同价。

2026 年 11 月 5 日实测：帧数、文件体积和耗时

2026 年 11 月 5 日晚（北京时间 23 点后），用 default 分组的 key 通过 gpt-image-2.6-web 生成了 4 个 1024×1024 的 GIF，每种设置 1 次。4 个结果的帧数、每帧时长都与请求完全一致，每帧都是 1024×1024，循环标志都是 0（无限循环）。表中最后一行是 OpenAI 指南里公开的 Sunburst 示例 GIF，用于对照文件体积：

文件体积基本跟帧数成正比，1024×1024 下每帧约 0.5 MB（2.02 ÷ 4、4.53 ÷ 9、8.20 ÷ 16 都在 0.50–0.51 之间）。要做表情包、聊天贴纸这类对体积敏感的用途，最有效的是少帧或缩小帧尺寸：OpenAI 的 512×512 九帧示例只有 1.28 MB，而 web 线路的帧有像素下限，体积下限也就更高。帧尺寸放大同样会让文件变大，老张 API 文档给出的 2048×2048 九帧约 11 MB。

耗时随负载浮动，不要当成承诺。这次 16 帧和 9 帧一样是 49.3 秒，而老张 API 文档写 1024×1024 下 4–9 帧约 35–42 秒、16 帧约 100 秒。客户端超时至少设 300 秒；按 token 计费的直连 OpenAI 要快得多，512×512 九帧是 11–12 秒。

请求报错怎么办：400、No supported sheet fits、429 和超时

GIF 请求失败多数是参数越界，看返回的 param 和 code 就能定位。gpt-image-2.6-web 的 400 报错 message 只说请求未被上游接受，原因要看 param 和 code；2026 年 11 月 5 日实测的三种越界都在 1–2 秒内返回，不扣费。下表把实测、OpenAI 文档和老张 API 文档里的情况放在一起：

GIF 首尾跳一下：用脚本检查循环接缝

GIF 的"循环"其实有两层。第一层是文件里的循环标志，loop=0 表示无限重播，上面 4 个测试 GIF 和 OpenAI 的示例都是 0，这一层不用操心。第二层是最后一帧能不能自然接回第一帧，这取决于模型画的动作。OpenAI 的图片提示词指南给的办法是让主体有一个起始姿势并回到原位，同时说明镜头动不动，但这只是建议，不保证首尾无缝。

2026 年 11 月 5 日用 OpenAI 指南里的原文提示词（小猴子举起灯笼、抬头眨眼、再放回起始姿势、镜头不动、循环流畅）在 gpt-image-2.6-web 上生成 9 帧，播放到第一帧时灯笼位置和姿势明显跳了一下。为了把"跳不跳"变成一个数，下面的脚本计算接缝比：最后一帧到第一帧的平均像素差，除以相邻两帧之间的平均像素差。接缝比不超过 1，说明首尾那一下不比正常的一步大；明显大于 1，就值得打开首尾两帧看一眼。脚本需要 Pillow（pip install pillow），同时会打印帧数、每帧时长和循环标志，顺便核对请求是否生效：

"""检查 GIF 的帧数、每帧时长、循环标志和首尾接缝。
用法：python3 check_gif.py a.gif [b.gif ...]"""
import sys
from PIL import Image, ImageChops, ImageStat


def diff(a, b):
    # 两帧的平均像素差，按满幅 255 换算成百分比
    d = ImageChops.difference(a, b)
    return sum(ImageStat.Stat(d).mean) / 3 / 255 * 100


for path in sys.argv[1:]:
    im = Image.open(path)
    loop = im.info.get("loop")  # 0 表示无限循环，None 表示只播一遍
    frames, durations = [], []
    try:
        while True:
            frames.append(im.convert("RGB"))
            durations.append(im.info.get("duration"))
            im.seek(im.tell() + 1)
    except EOFError:
        pass
    if len(frames) < 2:
        print(f"{path}: 只有 1 帧")
        continue
    steps = [diff(frames[i], frames[i + 1]) for i in range(len(frames) - 1)]
    seam = diff(frames[-1], frames[0]) / (sum(steps) / len(steps))
    w, h = frames[0].size
    print(f"{path}: {w}×{h}，{len(frames)} 帧，每帧 {sorted(set(durations))} ms，"
          f"loop={loop}，接缝比 {seam:.2f}")

用这个脚本量 2026 年 11 月 5 日的测试结果：OpenAI 循环提示词的 9 帧版本接缝比 1.38，就是肉眼能看出跳动的那个；同样设置换成一句话的模糊提示词（"A cute monkey with a lantern in the snow, animated."）是 1.08；循环提示词的 4 帧版本 0.72，16 帧版本 0.93。作为对照，OpenAI 指南公开的 Sunburst 示例是 0.72，老张 API 文档里的 Flare 猫咪示例是 0.68。

每种提示词只生成了一次，所以这组数只能说明"回到起始姿势"的写法不保证首尾接得上，不能说明模糊提示词更好，也不能说明哪个帧数更容易闭合。实际做法是每次生成后跑一遍脚本，接缝比明显大于 1 就重新生成；在按次计费的线路上，重来一次的成本和第一次相同。循环动图提示词的其他写法，见 GPT Image 2.6 提示词写法指南。

已有图片能用 API 变成 GIF 吗：按指南只走生成接口

截至 2026 年 11 月 5 日，OpenAI 自己的两份文档在这一点上说法不同。图片生成指南写明 GIF 输出只用于生成接口，/v1/images/edits 不支持 GIF；而编辑接口的 API 参考在 output_format 里列了 "gif"，也列了 frame_count（2–16）和 frame_duration_ms。gpt-image-2.6-web 的编辑接口请求 GIF 则明确返回 400 invalid_image_request。稳妥的做法是按指南来：把原图的主体、配色和构图尽量写进生成请求的提示词，让模型重新画一个相近的动图，但和原图不会完全一致。

编辑出 GIF 并非完全不可能：老张 API 文档团队 11 月 5 日在官方转发上见过一次编辑接口返回了 GIF。但指南明说不支持，这次也只是单次观察，行为随时可能变，不适合写进生产代码；需要稳定结果时，仍按上面的做法从生成接口出图，再用接缝脚本挑出首尾接得上的那一个。