Tutorial

GPT Image 2.6 实战：像素动画 GIF、SVG 矢量徽标与 mask_url 局部修改

三个可直接照抄的参数配置：GIF 帧数与 frame_size、SVG 输出与计价、mask_url 局部改图

Nov 6, 2026

Auf dieser Seite

先选线路：Flare 还是 Sunburst

同一套参数，两条线路。GPT Image 2.6 有四个模型 ID：gpt-image-2.6-flare/text-to-image、gpt-image-2.6-flare/image-to-image、gpt-image-2.6-sunburst/text-to-image、gpt-image-2.6-sunburst/image-to-image。

选型只看一件事：你这一轮要的是速度，还是细节一致性。

Flare：出图更快，适合快速迭代和批量出图。默认选它。
Sunburst：更重细节；在 medium 及以上质量做多轮编辑时，角色、产品、版式的一致性更好。

两条线路的参数、用法、价格完全相同。也就是说，下面三个场景里的每一行配置，换线路时一个字符都不用改。可以先用 Flare 把参数调到能跑通，再切到 Sunburst 出终稿。

模型页：

场景一：把像素小动画出成 GIF

GIF 只在文生图可用，output_format 传 gif。三个专属参数决定成片：frame_size、frame_count、frame_duration_ms。

一份可直接照抄的配置

{
  "model": "gpt-image-2.6-flare/text-to-image",
  "prompt": "pixel art loop, a small slime bouncing on grass tiles, 16-bit palette, plain light background",
  "quality": "high",
  "resolution": "1K",
  "output_format": "gif",
  "frame_size": "512x512",
  "frame_count": 8,
  "frame_duration_ms": 120
}

下面是 GPT Image 2.6 Flare 实际生成的一张 GIF：512×512，12 帧，每帧 120ms。

GPT Image 2.6 Flare 实际输出的 GIF，512×512，12 帧，每帧 120ms。

每个参数怎么理解

frame_size：每帧的像素宽x高，形如 512x512，两边必须是 16 的倍数，默认 512x512。它决定的是 GIF 的比例，不是 resolution。想改成 1:1 这类写法会被直接拒掉——这里要的是像素值，不是比例串。
frame_count：2–16，默认 9。像素小动画控制在 6–10 帧通常就够循环了；帧数越多，模型要在一个画布里排下的内容越多。
frame_duration_ms：每帧时长，≥20，默认 200，按 10ms 取整。像素动画常见的做法是 100–150ms，追求“逐帧感”就压到 80–120ms。

取帧思路

模型把 frame_count 帧拼成一张大图一次生成，再按 frame_size 切开。所以提示词要写的是“一组连续的动作序列”，而不是“一张图”。写清首尾如何衔接、主体在画面中位置是否固定，循环才不会有跳变。像素风再加一句限定调色板与描边风格，帧间一致性会更稳。

别忘了

生成 GIF 时 aspect_ratio 不传或传 auto。比例由 frame_size 决定，这里填别的只会制造冲突。

GIF 的边界：什么时候会被直接拒绝

GIF 的限制比普通出图多，且全部集中在提交阶段——超了不会被“勉强生成”，而是直接拒，全额退回、不扣费。所以放心试，但要清楚为什么被拒。

四条硬限制

帧数：2–16；但 768x768 最多 12 帧。
整张拼图每边：≤3840。
整张拼图总像素：≤8,294,400，大致等于 frame_size 的宽 × 高 × frame_count。
整张拼图长宽比：≤3:1。

第 3、4 条最容易被忽略，因为它们不在单个参数上，而是拼图后的结果。思路是：先算 宽 × 高 × 帧数，再检查拼图的长宽比有没有被拉过 3:1。

两个典型踩坑

512x512 出 16 帧没问题；同样 16 帧换成 768x768 就会被拒，768x768 最多 12 帧。
想要宽幅横幅动画，把 frame_size 设成很扁的比例，帧数再多几帧，拼图长宽比就越过 3:1。

提交前的自检

frame_size 两边是不是 16 的倍数？
有没有误传 1:1 这种比例写法？
aspect_ratio 是不是留空或 auto？
frame_duration_ms 是否 ≥20？（会自动按 10ms 取整）

这几条都过，GIF 就不会卡在提交环节。

场景二：让模型输出真正的 SVG 矢量徽标

svg 同样只在文生图可用，output_format 传 svg。输出是可缩放的矢量，放大到任意尺寸都不糊——这是徽标、图标、单色标记最需要的性质。

可照抄的配置

{
  "model": "gpt-image-2.6-flare/text-to-image",
  "prompt": "minimal geometric fox head logo, flat vector, two colors, thick even strokes, centered, plain white background, no text",
  "quality": "high",
  "resolution": "1K",
  "background": "opaque",
  "output_format": "svg"
}

下面是 GPT Image 2.6 Flare 用 low 档生成的一个 SVG 徽标，文件只有 3 KB，放大到任意尺寸都清晰：

GPT Image 2.6 Flare 实际输出的 SVG，quality=low，3,082 字节。

描述徽标的写法

矢量徽标要的是“可被矢量化”的形态，提示词就往这个方向压：

明确写 flat vector、thick even strokes，避免渐变、噪点、光晕、写实材质。
限定颜色数量，“two colors”比“colorful”更容易得到干净结果。
写 centered、留白要求，避免贴边。
需要纯标志时加 no text，让模型别塞字。

complexity 控制规划层级，与 quality 独立，默认 high。徽标这种结构简单的目标，quality 从 medium 或 high 起步就够；把预算花在反复重出上比一次拉满更划算。

贵多少

SVG 的价格是同档位 PNG 价加 0.030。例如 low、1K 档是 0.053，max、4K 档是 0.666。所以先用 medium + 1K 把构图定下来，确认后再用 high + 2K（或 4K）出终稿。

注意 background: transparent 需要 png 或 webp，SVG 配透明背景不在支持范围内，用 opaque 更稳。

场景三：用 mask_url 做局部修改

图生图支持 1–16 张源图（jpeg/png/webp），输出只有 png、jpeg、webp。局部修改有两条路：mask_url 和 markup_url，只能二选一。

路线 A：mask_url，精确指定改哪块

mask_url 是一张与第一张源图同尺寸的 RGBA PNG。透明像素代表要改的区域，不透明像素代表保留。

{
  "model": "gpt-image-2.6-flare/image-to-image",
  "prompt": "replace the background with a soft studio gradient, keep the product untouched",
  "image_urls": ["https://example.com/product.png"],
  "mask_url": "https://example.com/product-mask.png",
  "quality": "high",
  "resolution": "2K",
  "output_format": "png"
}

制作蒙版的关键三点：

尺寸必须与第一张源图完全一致，差一个像素都对不上。
必须是带 alpha 通道的 PNG，用透明表示“要改”。
蒙版边缘可以稍微外扩，避免新旧内容接缝生硬。

路线 B：markup_url，圈一下就行

markup_url 是一张透明 PNG 标注图，在上面圈出要改的位置即可。标注不会出现在结果里。它更适合“我知道哪里不对，但懒得做精确蒙版”的场景——比如圈出画面里某个人，说明“换这件外套”。

必须知道的一件事

用了蒙版，遮罩以外的区域也可能出现轻微变化。要完全保真的元素（logo、文字、人物脸部），别指望蒙版当保险；把“保持不变”写进提示词，并在出图后逐张比对。多轮编辑时，Sunburst 在 medium 及以上质量的细节一致性更好，这也是它在改图场景更值得切过去的原因。

选哪条

要改的形状边界清晰、必须精确 → mask_url。
只是指出位置、区域不规则、想省事 → markup_url。
两个都传 → 直接被拒，只会浪费一次提交。

三个场景一起算账：分档价格与常见误区

价格全部按张计。完整分档表见价格页，这里讲三条容易记错的规则。

规则一：GIF 只按质量计价，与分辨率无关

GIF 不看你传的是 1K 还是 4K，只看 quality。low、medium、high、xhigh、max 各对应一个固定价，从 0.070 到 0.598。所以给 GIF 加 resolution: "4K" 既不会更贵，也不会更清晰——清晰度由 frame_size 决定。

规则二：SVG 是同档 PNG 加 0.030

矢量输出是一项固定加价，叠加在同档位 PNG 的价上。例如 medium 1K 的 SVG 是 $0.071，high 2K 是 $0.120。想控成本，就用低档位多试几版，选定后再升档出终稿。

规则三：图生图每张参考图加 0.012

基础价与文生图相同，然后按参考图张数叠加，每张 0.012。以 high 2K 为例，传 2 张是 $0.114，传 16 张是 $0.282。只传真正需要的参考图。

提交被拒不计费

参数不合法、GIF 尺寸超限，都在提交阶段拦截，全额退回、不扣费。所以不要因为怕浪费而不敢调参，真正的成本来自“跑通了但结果不满意”的重出。

三个常见误区

以为 GIF 的分辨率越高越好：resolution 对 GIF 无意义，frame_size 才是像素来源。
以为用了蒙版就是像素级锁死：遮罩外仍可能轻微变化。
以为两条线路要两套配置：Flare 与 Sunburst 参数、价格完全相同，切线路不叫“迁移”，只是换个模型 ID。

上线前检查清单

提交前按下面的顺序过一遍，能挡掉绝大多数被拒和返工。

1. 先定 output_format

gif / svg → 只在文生图。做图生图？回到 png / jpeg / webp。
jpeg / webp → 可用 output_compression（0–100）。
background: transparent → 必须是 png 或 webp。

2. 按场景校验参数

GIF

frame_size 两边是 16 的倍数，没写成 1:1。
frame_count 在 2–16，768x768 时 ≤12。
宽 × 高 × 帧数 ≤ 8,294,400，拼图长宽比 ≤3:1。
frame_duration_ms ≥20（自动按 10ms 取整）。
aspect_ratio 留空或 auto。

SVG

提示词里有无渐变、噪点、写实材质等反矢量描述。
background 是否为 opaque（避免透明与 svg 冲突）。

mask_url / markup_url

两者只传了一个。
mask_url 与第一张源图尺寸一致、是 RGBA PNG。
提示词里写明了哪些区域要“保持不变”。

3. 再确认线路与档位

批量试错走 Flare，多轮编辑走 Sunburst（medium 及以上）。
quality、resolution、complexity 三者独立，别把 complexity 当成画质档。

4. 提交

全部通过再发。被拒不计费，但每一次重试都在消耗时间——清单的价值是减少往返，而不是省钱。

三个场景的配置都可以直接照抄，先跑通再调优，是上手 GPT Image 2.6 最快的路径。