Gemini Omni Flash 1.2 对比 Gemini Omni 1.1 Flash：两个排行榜说“是”，一个说“还不是”

2026 年 12 月 3 日，所有发送至 G​emini Omni 1.1 Flash的请求都将改为落到G​emini Omni Flash 1.2上，按新费率计费，而你的请求负载无需任何更改。G​oogle 在 11 月 5 日让 1.2 正式可用的同一篇变更日志条目中公布了这个路由日期。因此，版本问题不在于你是否迁移，而在于你是否会在切换落到你头上之前完成测量；而支持这样做的独立证据，比降价所暗示的更为复杂不一。

同一周的投票实际上揭示了什么

Artificial Analysis 在其全部三个视频榜单上分别运行了两个版本，并在相隔几天内先后发布了这一对结果。这是一种罕见的情况：版本对比无需由两个不同时间进行的两次不同测量活动拼凑而成。

在 AA-Video-I2V v2.1 上，此事已有定论。G​emini Omni Flash 1.2 以 1,086 分位列，95% 区间为 1,071 至 1,101；G​emini Omni 1.1 Flash 为 1,044 分，区间为 1,030 至 1,058。相差 42 分，区间无重叠，第 14 名对第 18 名。无论新模型还有哪些其他不确定之处，其图生视频输出都比前代在可测量意义上更受偏好，且这一优势幅度得到了样本支持。

在 AA-Video-T2V v2.1 上，情况仍未确定。26 分的差距——1,154 对 1,128——对应的区间分别为 1,140 至 1,168 和 1,115 至 1,141。它们仅共享一个点。在 AA-Video-Editing v1.1 上，差距为 18 分，1,164 对 1,146，且区间重叠了四个点。两个榜单都将 1.2 排在 1.1 之上。两者都无法将它们区分开。

这种模式比任何单一数字都更有价值。一个新的检查点在一项任务上明显胜出，可能在第二项任务上胜出，在第三项任务上仅略有优势，这正是点版本发布的常见形态。它不是 15 秒片段和翻倍的速率限制所可能暗示的那种代际跃升的形态。

价格是那个没有误差棒的部分。

视频输出价格从每百万 token 17.50 美元降至 12.00 美元，降幅 30%，这是该发布中唯一无需置信区间的说法。Google 按每秒视频素材的固定 token 费率计费，因此算术不是偏好问题：在 720p、每秒 5,792 个 token 下，成本从每秒约 0.10 美元降至约 0.07 美元。在 1080p 并启用上采样时，约为每秒 0.104 美元；在 4K 时约为 0.209 美元。Artificial Analysis 将两个版本折算为每 1080p 分钟 9.12 美元和 6.26 美元，这正是从同一计费标尺另一端看到的同一个 30%。

文本、图像和视频的输入仍为每百万个 token 1.50 美元，文本输出仍为 9.00 美元。batch、flex 或 priority 列均无变化，因为 1.2 没有这些列——只有标准层级，且两个版本都没有免费层级。

在路由日期之前而不是之后进行片段计算。在 1.2 上以 720p 生成十五秒的输出 token 成本约为 $1.05。同样的十五秒无法在 1.1 上通过单次调用生成，因为 1.1 最长只有十秒；更诚实的比较是十秒约 $1.00。降价是真实的，但其中很大一部分花在了多出的五秒上，而一个从不需要更长片段的团队看到的账单变化会比百分比所暗示的更小。

十五秒不再免费之处

时长的增加也带来了一些边界情况，这些情况在文档中已有说明，而不是需要自行发现；其中三项会改变请求允许包含的内容。

• 插值 — 首帧与末帧控制在两个版本上均支持三到十秒；在 1.2 上，使用两个参考帧请求十一秒或更长时间会返回无效参数错误。

• 参考视频——3 到 10 秒的输出接受三段参考视频，每段最长 3 秒；而 11 到 15 秒的输出只接受一段。延长镜头可能会悄无声息地让原本用三段参考视频就能通过的请求失效。

• 扩展 — 扩展每轮运行三到十秒，带有十秒的回看，总时长上限为 30 秒，且仅在片段末尾进行。在 1.1 中，编辑和扩展的上限为十秒的输入。

• 参考图像——每次请求最多六张，覆盖全部三种模式；这也是 Google 在发布宣传中围绕角色与主体一致性所重点强调的变化。

• 地区——在欧洲经济区、瑞士和英国，无法编辑和延长上传的视频，指南中也载明了这一限制。如果你的用户位于这些市场，那么对话式编辑的卖点对他们完全不适用。

• 未改变的限制——没有系统指令、没有 temperature、没有 top_p、没有负面提示词、没有预配吞吐量、没有 YouTube 来源、没有多视频推理。每个输出都带有 SynthID 水印。

一个看似“Text”、实际含义与字面不符的输出行

模型卡把 1.2 的输出列为“带原生音频的视频、文本”，而 1.1 只是“视频”，这一差异被解读为新增了一条文本通道。事实并非如此。Omni 指南没有说明 1.2 存在文本输出模式；文本是渲染在画面之内的——标签、标牌、坐标轴——而请求形态仍然是视频响应。REST 响应包含一个 steps 数组，其中的“thought”条目是推理轨迹，不是答案。如果流水线需要 API 返回一段字幕字符串，两个版本都不会返回；那一行的差异描述的是模型画出了什么，而不是它给了你什么。

音频这一项确实是真正的变化，但这是质量上的变化，而不是性质上的变化。两个版本都会生成原生同步音频。Google 在发布时宣称对话更流畅、唇形同步更清晰，并具备独特的多说话人条件控制；它还表示参考内容可以携带音频线索和一秒长的语音样本——这些参考路径在 Google Cloud 上已列入允许列表，而在此版本中模型本身不支持音频输入，参考视频中的音频会被忽略，语音编辑也不可用。你可以通过提示词指定一种声音；但之后无法编辑它。上述质量方面的说法都没有独立测试作为支撑，而且上文的三个排行榜衡量的是视觉偏好，而不是台词是否与口型匹配。

破坏下游的是迁移，而不是请求

由于载荷不会改变，故障面就是请求所传入的一切。12月3日之前要检查四个地方，按它们通常出故障的顺序排列：

关于默认时长。省略 duration 的请求过去会被限制在十秒，现在也仍默认为十秒，因此未做改动的调用行为完全一致。真正会被破坏的是那些把十秒当作最大值的校验逻辑。

帧对条件控制。现在，任何将插值与超过十的时长配对的代码路径都会报错，而不是静默截断——行为更好，失败更响亮。

成本模型。在 720p 下，每一个由 1.1 费率推导出的每秒常数都高出了 30%。如果你在内部按每次渲染计费，那么趁旧价格仍然正确的时候，这一行就是需要修改的地方，因为切换之后，这个数字的错误方向会恰好美化你的利润率。

过滤行为。编辑看板中 1.2 的行上有一条备注，指出模型通过版权和安全过滤器拒绝处理了部分测试集，而已发布的分数反映的是通过筛选后保留下来的提示。原本假设每个请求都会返回文件的生产流水线，现在需要专门为新版本增加拒绝路径。该备注仅出现在 1.2 的行上，而不在 1.1 的行上。

两种切换方式，以及哪一种更适合你

如果你的内容已被测量，并且你喜欢输出结果，那就尽早迁移，用这三周时间在你自己的素材上重新测量。降价和时长提升都值得拥有，图生视频的差距是真实存在的，而另一种选择是在12月3日被迁移，届时两边都没有数据。

如果你的内容量很大，而且自上次变更后就没再审视过它，那么有用的做法是同时运行两者。在 1.1 仍可单独寻址时，把它保留在生产路径上，将一定比例的流量以影子方式导向 1.2，并在榜单不衡量的维度上比较——片段存活到交付的频率，而不是它在成对投票中获胜的频率。这属于路由问题，而不是模型问题，而路由正是我们所处的层面。目前两个 Omni 端点都不在 OrcaRouter 的目录中，所以这并不是在推销由我们来提供它们；这正是版本升级对那种只有一条路径、无法在旁边再跑第二条的流水线伤害最大的原因。我们真正能赢得这个位置的，是周边的文本工作：为渲染提供输入的提示词扩展和镜头清单调用，可以通过一个端点、按提供商目录价，针对多个模型进行组合，并在某个模型降级时自动故障转移，而且路由规则可以将一部分请求发送到另一个模型，而无需部署。

唯一不要做的，就是把 1.1 固定到 12 月 3 日之后，然后从一张发票上才发现变更。无论你的配置怎么说，端点都会进行路由。

版本比较，以版本比较的形式陈述

1.2 每秒成本更低，单段视频更长，在图像转视频方面更胜一筹，且领先幅度足以经受其自身误差条的检验；有证据表明它在文本转视频和编辑方面可能也更优，但这些证据尚不足以将它与 1.1 区分开来。它带有一个安全过滤器，会移除某项编辑基准测试的一部分，也会移除你编辑工作负载的一部分；并且它会在 Google 已经公布的日期承接 1.1 的流量。

会被引用的比较，将是排名变化，因为从十二到六听起来像一次跃升，而四十二 Elo 听起来只是一个数字。能预测下个季度走势的比较，是带有区间的那一个，而它说明：一个明确的胜出、两个可能的胜出，以及三者之下一个更便宜的计量表。