Gemini Omni Flash API 路由：Google 的对话式视频模型现在是运营决策

当 Google 本季度发布 Gemini 3.5 Flash 和 Gemini Enterprise Agent Platform 时，多模态路由拼图中仍有一块明显缺失：视频生成还停留在专用工具链阶段，没有一条与文本路由体验对齐的原生 Google API 路径。Gemini Omni Flash 于 2026 年 6 月 30 日进入 API 公测，填补了这一空缺。

对 AI 工程团队而言，真正的变化不只是 Google 终于有了视频生成模型，而是这个模型使用了 Interactions API —— 一种以会话为单位、支持多轮编辑的协议，每次修改都在上一轮输出的基础上迭代。这种模式与文本或图像生成 API 的无状态请求/响应模式有本质区别，并由此产生了大多数团队尚未规划过的路由决策。

发生了什么

Google DeepMind 于 2026 年 6 月 30 日将 Gemini Omni Flash 上线至 Google AI Studio 和 Gemini API，这是 Gemini Omni 系列 的首款模型，专为从文本、图像、视频（以及即将支持的音频）组合输入中进行对话式视频生成与编辑而设计。

关键技术参数：

• API 模型 ID：gemini-omni-flash-preview
• API：Gemini Interactions API（基于 session 的多轮协议，区别于标准 Responses/Chat 端点）
• 定价：约 $0.10/秒视频输出；输入 $1.50/百万 token，视频输出 $17.50/百万 token；720p 视频输出约 5,792 token/秒
• 当前公测限制：每轮最长生成 10 秒视频
• 输入模态：文本、图像、视频参考；音频参考已公告但尚未完全上线
• 安全机制：输出内嵌 SynthID 水印和 C2PA Content Credentials
• 可用入口：Google AI Studio、Gemini API、Gemini Enterprise Agent Platform、Gemini App、Google Flow

Interactions API 与无状态生成的核心区别在于：每轮的上下文（已有视频状态、编辑历史和场景连贯性）由服务端在 session 内维护。客户端只需发送新指令——"调暗灯光并添加飘雪效果"——模型便在已有视频状态基础上应用修改，而非从头生成。

对 AI 工程团队意味着什么

这不是文本转视频的即插即用替代方案。 已通过 DashScope 集成 wan2.7 或通过 Vertex AI 使用 Veo 处理异步视频任务的团队会发现，Gemini Omni Flash 遵循完全不同的 session 生命周期：

第一，session 粘性。 与可路由到任意 provider 副本的无状态生成请求不同，Omni Flash 的 session 持有可变状态。路由层必须在整个编辑循环内将 session 固定到同一端点——否则需要在每轮重新上传完整视频状态，这不仅增加延迟，还会推高成本。

第二，计费颗粒度。 视频输出按秒计费，约 $0.10/秒，意味着一个生成 5 轮、每轮 10 秒的编辑 session，仅输出 token 就需约 $0.50，输入 token 另计。这与 wan2.7（DashScope）等异步视频 API 的固定按任务计费模式完全不同，需要在成本预算模型上做相应调整。

第三，公测预算规划。 公测阶段 Google 可能设置比 GA 更低的 rate limit。基于 gemini-omni-flash-preview 构建的团队应提前规划 GA 模型 ID 重命名的应对方案——这与 6 月 gemini-3.1-flash-image-preview 弃用时给团队带来的冲击如出一辙。preview ID 只应用于非关键路径，并持续关注 GA 重命名动态。

第四，SynthID + C2PA 溯源。 生成的视频在生成时即自动内嵌溯源水印，这对企业治理是利好（AI 生成内容可审计），同时也意味着即使在下游平台，Google 也认为 Omni Flash 的输出应被声明为 AI 生成内容。受监管媒体或广告技术领域的 operator 应验证内嵌凭证是否在其发布流水线中完整保留。

Router/Operator 视角

Gemini Omni Flash 为媒体生成工作负载的路由引入了一个全新的类别决策：

无状态异步 vs. 有状态 session 式视频生成。 当前主流视频 API（wan2.7 DashScope、Veo、Kling、Seedance）均接受单次 prompt/参考输入并返回可轮询完成的 job ID。Omni Flash 的 Interactions API 则从设计上就是有状态的——编辑在多轮之间在服务端累积。这意味着 fallback 策略必须考虑 session 丢失的场景：如果 provider 错误中断了多轮 session，不能简单地在不同端点重试，而必须重新开始整个编辑循环。

模型 ID 版本管理规范。 gemini-omni-flash-preview 最终将被重命名或替代。直接固定 preview ID 而没有 alias 层的路由配置，会在 Google 弃用时悄然中断。可参考 2026 年 6 月 Gemini 图像 API 弃用模式作为模板：preview ID 可能在 GA 发布后数周内即告失效。

成本模型对比。 以约 $0.10/秒（$6.00/分钟）的视频输出定价，Gemini Omni Flash 高于同等时长的 DashScope 异步视频任务，但低于高端实时视频合成服务。路由创意或生成媒体工作负载的团队现在可以将 Google 视为对话式视频编辑的主力 provider，将 DashScope/Wan2.7 作为无状态批量生成的 fallback。两套 API 并非即插即用的替代关系——需要根据工作负载是有状态（编辑 session）还是无状态（批量生成）路由到不同的处理器。

治理层面。 SynthID + C2PA 在生成时即内嵌，而非在交付时添加。如果路由层对 HTTP 头进行剥离或检查，需确保 C2PA 内容凭证（可能以 manifest 内嵌形式存在）在流水线中完整传递。

TheRouter 用户应关注什么

TheRouter 异步媒体端点目前处理的是无状态生成请求的路由。Gemini Omni Flash 的 Interactions API 基于 session——这是完全不同的 job 生命周期。在原生 Interactions API session 路由支持上线之前，推荐做法如下：

• 需要 session 连贯性的多轮编辑任务，直接通过 Gemini API 使用 Gemini Omni Flash。
• 无状态视频生成任务（wan2.7、Veo、Kling 等），继续通过异步媒体端点路由。
• 在应用层构建路由判别器：有状态多轮编辑循环路由至 Gemini Omni Flash；单次生成路由至标准异步媒体路径。

持续关注 Gemini Omni Flash GA 版本——届时模型 ID 将趋于稳定，定价可能调整，每次生成时长限制也可能突破当前的 10 秒上限。届时，GA 的 rate limit 和地区可用性策略也值得提前排查，以避免重蹈 Gemini 2.0 Flash 于 2026 年 6 月 1 日关停时波及团队的覆辙。