迁移 Veo 集成前，先确认模型 ID 与下线时间

为什么只看"Veo"三个字会踩坑

一份迁移公告通常绑定的是一串精确到版本乃至部署路径的模型 ID。产品页面上只写着"Veo"，并不意味着你知道它对应的是哪条下线通知、哪条 API 路线。

据开发者平台 dev.to 上的一份生产笔记（源自 FableBridge 的日文原始记录），他们发现在 Google 官方通知中，Gemini API 路线的 Veo 3.1 预览模型与 gemini-omni-flash-preview 有过一个较早的下线日期，并被 gemini-omni-1.1-flash 列为替代型号；而 Vertex AI 生产路线的 -001 模型则有一份独立的退役通知，时间窗口不同。

这个差异意味着一件事：同一款"Veo"，因为 API 路线不同，迁移截止时间和替代方案可能完全不一样。

rss source: Check the Model ID Before Migrating a Veo Integration

Gemini API 与 Vertex AI 是 Google 旗下两条独立的模型服务入口，面向不同使用场景。 Gemini API（原名 Generative Language API）主要面向开发者与应用集成，通过 AI Studio 等渠道调用，更新节奏偏快，预览版模型常较早停止服务；Vertex AI 则是 Google Cloud 上的企业级机器学习平台，模型以带 -001、-002 等后缀的稳定版本形式发布，配有独立的版本生命周期与退役公告。由于两条路线各自的模型目录、发布节奏与下线通知彼此独立，同一个产品名（如 Veo）在其下可能指向完全不同的模型 ID、时间表和替代型号。因此，迁移工作的第一步不是识别产品，而是定位自己实际调用的是哪条路线下的哪个具体 ID。

从模型 ID 开始，而不是从产品名开始

原作者反复强调的起点很简单：模型迁移始于一个精确的标识符。

一个只有"Veo"标签的产品界面，无法回答"哪份退役通知适用于我"。因此在动手改生产工作流之前，至少要记录下这些字段：

提供方（Google / 具体云平台）
完整的模型 ID
走的 API 路线（Gemini API 还是 Vertex AI）
请求参数与预期输出

作者把这一步定义为"让工作流可复核"的前提。换句话说，如果连当前用的是哪个 ID 都写不下来，后面的迁移决策就没有可追溯的基准。

用一个小测试验证输出契约

切换模型之前，先跑一次小规模测试，把"契约"确认清楚。作者建议核对的具体项包括：分辨率、时长、音频、下载处理方式、预估成本。

这里有一个容易被忽略的坑。在他们的 Omni 测试中，音频是随视频一起生成的。如果原有工作流是单独制作配乐的，就必须在剪辑阶段把这段自带音轨静音或替换掉——否则两套音频会打架。

这类问题不会在 API 返回成功时暴露，只有在检查最终导出产物时才会浮现。作者因此提醒：自动化任务的"成功"提示，并不等于内容已经过审。

输出契约（output contract）指的是调用方模型输出在格式与规格上的预期约定，包括分辨率、时长、是否自带音频、文件如何下载以及成本上限等。一旦模型 ID 或版本发生替换，即使接口调用仍然返回成功，这些规格也可能发生静默变化——例如分辨率默认值调整、时长上限改变，或原本独立的音频轨道变为随视频一并输出。由于这类差异通常不体现在 API 响应状态码中，只会在下游的剪辑、合成或计费环节暴露出来，因此在正式迁移前用一段最小样片逐项比对输出契约，是把风险前移、避免生产事故的常规做法。

保留一份可复现的小对比

为了做决策，作者用同一张输入图片和同一段运动提示词，分别跑了两版 Veo 输出和两版 Gemini Omni 输出。总共四段素材。

需要明确的是，这四段视频是一次生产测试的记录，不是通用基准。在当时的记录条件下：

Omni 的两次尝试分别耗时约 42 秒和 36 秒
预检估算成本分别约为 1.03 美元和 0.83 美元

作者特别标注：这些是观测值与估算值，不构成对后续任务的承诺。任何真实项目都应基于当时的定价和条件重新测算。

把 API 路线拆开看

这是整份笔记中最具操作价值的部分。作者在核对官方通知后发现，不同路线的时间表并不同步：

路线	涉及模型	下线时间观察	替代型号
Gemini API	Veo 3.1 预览模型、`gemini-omni-flash-preview`	存在一个较早的下线日期	`gemini-omni-1.1-flash`
Vertex AI	生产 `-001` 模型	独立的退役通知，时间较晚	需查对应通知

结论很直白：在改动生产工作流之前，先查当前生效的通知，并确认精确的模型 ID。产品名不承担这个责任。

退役通知（deprecation notice）是模型提供方针对某个具体模型 ID 发布的正式公告，通常包含下线日期、替代型号以及迁移建议。一条退役通知往往只覆盖某一条 API 路线下的特定模型 ID，而不覆盖同名产品在其他路线下的所有版本。这意味着开发者不能依据产品名笼统判断，而应逐条比对当前生效的通知，确认自己的模型 ID 是否在其中。此外，预览版模型的退役节奏通常早于稳定版（如 -001 后缀的正式版本），两条路线的时间窗口不一致正是这一机制的直接体现，也解释了为何某些 Veo 相关模型的下线日期会出现明显先后差异。

可以带进下一个项目的检查清单

作者最后提炼了一份很短的清单，值得直接抄进团队的迁移流程：

记录精确的模型 ID 和 API 路线
核对当前生效的退役通知
在推进项目其余部分之前，先用一个小输出测试获得确认

除此之外，还要保留可复现的配置记录，并人工检查最终导出的产物。

这套方法适用于更广的模型迁移场景

虽然这份笔记围绕 Veo 与 Gemini Omni 展开，但它的逻辑对任何依赖托管模型 API 的项目都成立。

托管模型的版本节奏越来越快，产品名与真实模型 ID 之间的脱节是常态。把"确认 ID—核对通知—小样验证"固化成迁移前的固定动作，比事到临头翻文档要可靠得多。

需要说明的是，上述规格、估算、价格与时间表均为来源记录日的快照，不构成对新项目的保证。原文包含更多条件与参考信息，可直接查阅 FableBridge 的原始生产笔记。