Gemini Omni 1.1 Flash

E2X 上的 Gemini Omni 1.1 Flash Reference-to-Video API

一场 campaign 从来不只有一段片子。它是一份镜头表——11 行，每一行里都是同一个快递包，而预算里没有留出「第六行开始那个包变灰了」的那个下午。Reference-to-video 让那个包一直是那个包。我们把它运行为 google/omni-1.1-flash/reference-to-video，并按 720p 输出的每一秒收 $0.09，所以默认的 8 秒片段是 $0.72，含音频。

真正干活的字段是 image_urls——一个数组，我们的 schema 里写着 minItems: 1 和 maxItems: 7。这个上限就是本页存在的理由。7 个位置能从足够多的角度呈现一个主体，让模型不再去发明那些您没给的角度。

素材不同，进的门也不同：只有一张静帧，去 Omni 1.1 Flash image-to-video；镜头的首尾两端已定、中间留空，去 start-end-frame-to-video；一份完全没有素材的 brief，去 Omni 1.1 Flash text-to-video，完整的价格表在那一页。

我们的费率，2026年8月28日从实时目录上读到：

标价是每秒 $0.15；一个常年 40% 的折扣把它带到 $0.09。分辨率在此基础上缩放——360p $0.0297，4K $0.18，所以一段 10 秒的 4K 成片是 $1.80。接下来这个数字决定您怎么搭流程：挂 1 张参考图还是 7 张，上面的价格纹丝不动。duration 和 resolution 就是全部公式。参考图不占重量。

价格与产品条款可能随时间变化；在做出采购决定前，请核对各家提供商的当前价格。Google 的 Batch 或 Flex 价格在调度、可用容量和处理条件上均有所不同，因此与标准的按需 API request 并不直接等价，已从本对比中排除。这是一次限定范围的对比，并非声称 E2X 在任何配置下都是全球最便宜的选择。

7 个位置，而且这个数字写在 schema 里

API 会去取数组里的每一个 URL，所以它们必须放在我们的 worker 能通过普通 HTTPS 够到的地方——一个公开存储桶，一个还没过期的签名链接，不能是需要登录才能打开的东西。

7 是一个被校验的最大值，不是文档页上的一句话。发第八张，request 在碰到 GPU 之前就被拒了。这听上去像个限制；请把它当成一份预算。一组用满 7 张的参考图应该是这样：四分之三侧、正侧、背面、一处承载品牌的细节、一张按片子将来取景的距离拍的、一张在中性光下拍的。重复的主视觉角度是在浪费一个位置。您省下不给的角度，会被猜出来。

这正是相对上一代的变化。我们的 Gemini Omni Flash reference-to-video endpoint 做的是同一件事，每秒 $0.075，但完全没有任何有据可查的上限——Google 从未公布过，所以我们也不愿印一个自己站不住的数字。便宜两成的是那一边，而且原因看得见：没有经过验证的七个槽位上限，也没有 360p 档可以在花钱之前先把一套参考图排练一遍。Google 将在 2026年9月30日下线那个模型。如果某条 pipeline 还指着那边，迁移就是换一个 slug，每秒贵五分之一，然后它就落到这里。

一组参考图，多条 prompt

数组只搭一次。把那 7 个 URL 跟您的镜头表放在一起，每一个 job 都原样发这同一个数组。这组图是固定项，prompt 才是变量。

这个反转就是整套工作流。因为主体由参考图承载，每一条 prompt 就不再描述那个东西长什么样，而开始描述它身上发生了什么——摄影机、什么在动、光线、声音。prompt 变短了，片子却更一致了，这跟人们预期的取舍正好相反。比较一个镜头的两种写法时，请把 seed 钉住，这样您才分得清是改写起了作用，还是骰子起了作用。

每个 job 请按 240 秒预留，然后把整份镜头表并发地铺出去。之后请靠 Google 模型卡自己承认的这句话保持校准：

「在编辑全程保持完全一致、生成包含复杂运动的场景，或渲染完全准确的文字，仍然是一项挑战。」

7 张参考图能把漂移收窄。它们消灭不了漂移。

把数组发出去

有两个字段必填：prompt 和 image_urls。把 key 留在服务端，然后提交 job。

curl -X POST https://api.e2x.ai/v1/jobs/submit \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "google/omni-1.1-flash/reference-to-video",
    "input": {
      "prompt": "图 1 是折叠自行车，图 2 是转轴，图 3 是骑车的人。日出时分的石板庭院。他把车展开，再把车架扣紧。固定机位全景。鸟鸣，远处一辆有轨电车。",
      "image_urls": [
        "https://example.com/bike-folded.jpg",
        "https://example.com/bike-hinge.jpg",
        "https://example.com/rider.jpg"
      ],
      "duration": "8",
      "aspect_ratio": "16:9"
    }
  }'

回来的是 data.jobId。渲染要花上几分钟，所以请慢一点 poll——或者传一个 webhookUrl，把轮询整个跳过。

const headers = {
  Authorization: `Bearer ${process.env.E2X_API_KEY}`,
  "Content-Type": "application/json",
};

// 一个数组，被每一条 prompt 复用。
const image_urls = [
  "https://example.com/fox-puppet-front.jpg",
  "https://example.com/fox-puppet-muzzle.jpg",
  "https://example.com/fox-puppet-profile.jpg",
];

const submitted = await fetch("https://api.e2x.ai/v1/jobs/submit", {
  method: "POST",
  headers,
  body: JSON.stringify({
    model: "google/omni-1.1-flash/reference-to-video",
    input: {
      prompt:
        "图 1 是那只狐狸手偶。它从画面左侧探进来并歪了歪头。缓慢推近。纸张的窸窣声，柔和的房间底噪。",
      image_urls,
      duration: "10",
      aspect_ratio: "9:16",
      resolution: "1080p",
      seed: 70413,
    },
  }),
}).then((r) => r.json());

const { jobId } = submitted.data;

while (true) {
  const job = await fetch(`https://api.e2x.ai/v1/jobs/${jobId}`, { headers })
    .then((r) => r.json());

  if (job.data.status === "completed") { console.log(job.data.outputs[0].url); break; }
  if (job.data.status === "failed") throw new Error(job.data.error?.message);
  await new Promise((r) => setTimeout(r, 5000));
}

状态依次是 pending → processing → completed，或者落在 failed / cancelled 上。有一个坑：duration 和 resolution 是字符串。要写 "10"，绝不是 10。schema 和价格都在机器可读规格里。

那个「贵九倍」的问题，我们拿自己的利润来回答

Veo 3.1 Fast reference-to-video 在同一个平台上每秒 $0.01。便宜九倍。那边 8 秒是 $0.08，这里是 $0.72，我们不会把它埋在某张表格底下。

所以默认答案是 Veo。一份镜头表只需要 3 张参考图、8 秒、720p，那么调用别的任何东西都是在为空气花钱。

有四件事能把这个结论翻过来。您需要的参考图比 Veo 收得多，它停在 3 张，我们是 7 张——这是「覆盖一个主体」和「采样一个主体」的区别。您需要 10 秒，而 Veo 不给。您需要 4K。或者您想要 360p 那一档，在那里 20 次草稿比一段成片还便宜，而胜出的那条再用同一个数组和同一个 seed 重渲一遍。除了这四件事，就去选便宜的。更多内容在 reference-to-video 分类里，其余的在模型目录里。

镜头表签字之前，先把这些事定下来

您的参考图是真实事物的上传件，有时候还是真实的人。 对英国、瑞士和欧洲经济区的用户，Google 会拦截含有未成年人或某些可辨识个人的图像上传。在这里，这是一条选角约束，不是一行脚注。请把它写进 brief，而不是留给凌晨两点那个失败的 job。

每一帧都带 SynthID。 Google 那个隐形 watermark 会出现在所有输出上，没有任何提供商能把它关掉，我们也一样。如果某份合同禁止带标签的 AI 素材，请在集成之前把它谈定。

声音来自文字。 音频与画面一同生成，并由同一条 prompt 指挥——没有 has_sound 开关，也不能上传音频参考。

结果 URL 会过期。 请在读取 outputs[0].url 的那个 handler 里，就把每一份输出复制到您自己的存储上。一场要重渲的 campaign，就是一场您付了两次钱的 campaign。

英语是唯一得到完整支持的 prompt 语言，而且这个模型挂在 Gemini Enterprise Agent Platform 上，那是 Google 在 2026 年 4 月用来接替 Vertex AI 的平台。背景在我们的发布记录里。

在 prompt 里给参考图编号

挂上 7 张图，告诉模型的是「有哪些东西」。它没说哪一张是主角。这件事得由您用文字来做：图 1 是水壶，图 2 是搪瓷壶盖，图 3 是厨房。编号，写在第一行，放在任何指令之前。

然后就别再描述主体了。一条 prompt 如果重新指定了您已经附上的东西的颜色和形状，那它是在跟您自己的参考图吵架，而模型会各让一半。把字数花在数组装不下的东西上：摄影机、一个运动、光线、环境音。每条 prompt 只写一个连续镜头——要它演一段三场戏的叙事，您拿到的就是一团糊。我们的 Gemini Omni prompt 指南在镜头词汇上讲得更深。

常见问题

Gemini Omni 1.1 Flash 接受多少张参考图像？

7 张，而且这个上限是公布出来的，不是猜的：image_urls 按 minItems: 1 和 maxItems: 7 校验，所以第八项在提交时就会失败。上一代没有任何有据可查的上限。这是最大的实际差别。

多挂几张参考图会让片子更贵吗？

不会。我们按成片视频的每一秒计费，再按分辨率缩放；参考图数量不在这个计算里。1 张也好 7 张也罢，一段 8 秒的 720p 片子就是 $0.72。长度和分辨率是仅有的两个杠杆。

我怎么告诉模型哪一张参考图是主体？

在 prompt 里给它们编号——哪张是产品，哪张是细节，哪张是环境——然后再描述动作。在您的文字给它们分配角色之前，image_urls 只是一份光秃秃的列表。

一整份镜头表能复用同一组参考图吗？

这正是它被设计成的样子。数组存一次，每条 prompt 都原样发出去，只变化那些指令。钉住一个 seed 能让光线稳到足以让这些片子剪在一起。

什么时候 Veo 3.1 Fast 是更好的选择？

几乎总是，每秒 $0.01——同样的 request，Veo 3.1 Fast 便宜九倍。当 3 张参考图覆盖不够、当剪辑需要 10 秒、当交付物是 4K，或者需要 360p 那轮草稿时，再挪到这里来。

我可以要哪些分辨率和时长？

360p、720p、1080p 或 4K，16:9 或 9:16，4、6、8 或 10 秒，始终是 24 fps。最高的那两档分辨率是放大出来的，不是原生渲染，所以请拿您自己的素材去判断锐度。

2026年9月30日之后，我那套 Gemini Omni Flash 集成会怎样？

Google 会在那一天弃用 gemini-omni-flash-preview，而所有跑着那批权重的提供商都在同一天停掉。请把 job 指到这里来：request 形状一样，参考图上限还有据可查。旧的 reference-to-video 页面会继续留着，作为迁移参考。