Google 已弃用两个 Gemini Flash API slug，并自动将流量从每个旧名称路由到较新的替代名称，从而创建看似较小的模型目录更改，但会对网关、分析和客户报告产生较大影响。

根据 Google 于 2026 年 10 月 8 日发布的 Gemini API 发行说明，gemini-3.7-flash 已弃用并由 gemini-3.8-flash 取代。发送到已弃用的 3.7 Flash slug 的请求将自动路由到 3.8 Flash。 Google 还弃用了 gemini-3.5-flash，将其替换为 gemini-3.6-flash 和相同的自动重新路由行为。

该公司还弃用了deep-research-pro-preview-12-2025，并表示 Deep Research 代理将于 2026 年 10 月 23 日关闭，并提供迁移到新的 Deep Research 代理的路径。这让团队可以在很短的时间内识别生产用途、更改固定 ID 并在旧预览端点消失之前验证输出行为。

Gemini API

发生了什么变化

立即进行的操作更改很简单：请求可以命名一个模型，而 Google 提供另一个模型。这与开发人员故意将应用程序从 gemini-3.7-flash 编辑为 gemini-3.8-flash 不同。这是提供方替代。

对于简单的应用程序，如果响应仍然可以接受，则差异可能是不可见的。对于运行评估、面向客户的分析、规范的工作流程或成本归因的团队来说，这很重要。仅记录所请求模型的日志条目可能会使已弃用的模型看起来仍在处理流量。仅记录所服务模型的仪表板可以隐藏客户仍在调用旧模型的事实。两个视图都不完整。

这就是 AI 模型别名 不仅仅为开发者带来便利的地方。网关需要区分至少三种情况：平台创建的稳定客户别名、有意浮动的提供商别名，以及默默地将旧公共模型 ID 映射到新公共模型 ID 的提供商弃用路线。将所有三个视为同一字段会导致分析不明确。

为什么自动重新路由有用但有风险

自动重新路由可减少直接中断。如果客户硬编码了 gemini-3.7-flash，Google 的替换路由可以在团队更新配置时保持请求运行。这是一种实用的服务连续性选择，特别是对于模型 ID 分布在脚本、合作伙伴集成、提示或客户设置之间的应用程序。

代价是失去明确的控制。即使 API 调用仍然成功，模型替换也可能会改变延迟、输出样式、安全行为、工具使用模式或边缘情况可靠性。开发者可能不会注意到这一变化，直到评估出现偏差、提示行为不同或客户询问为什么报告的使用情况不再与文档相符。

对于通过团队多模型API网关公开Google模型的平台来说，风险更高。这些产品位于提供商和最终用户之间，因此他们必须决定提供商的路由行为有多少要公开。网关只转发旧的 slug 并对生成的调用照常计费可能会保留兼容性，但它会给支持和财务团队留下薄弱的审计跟踪。

网关和转销商平台应记录哪些内容

最简洁的模式是存储请求的模型、已解析的提供程序模型以及导致解析的别名规则。对于 Gemini Flash 更改，这意味着使用记录应该能够显示客户请求的 gemini-3.7-flash、Google 服务了 gemini-3.8-flash，原因是 Google 的弃用重新路由，而不是客户定义的后备规则。

这种区别会影响结算支持、迁移规划和产品信任。如果客户询问他们的应用程序是否仍在使用已弃用的模型，答案不应需要手动日志考古。如果经销商需要通知下游帐户，它应该能够按请求的遗留段进行细分。如果内部评估套件开始失败，工程师应该能够比较服务模型更改之前和之后的结果，而无需猜测流量何时移动。

对于Model Gate风格的产品，实际工作是使用情况分析和客户报告。 使用情况分析仪表板应避免将请求和提供的模型折叠到一个标签中。它还应该使已弃用的 ID 足够可见，以便帐户所有者能够在提供程序支持结束之前推送迁移。

Deep Research 代理关闭增加了第二种期限。与 Flash 重新路由不同，Google 表示 deep-research-pro-preview-12-2025 将于 2026 年 10 月 23 日关闭。使用该预览代理的团队需要迁移，而不是依赖不确定的兼容性路由。由于深度研究工作流程可能嵌入到运行时间较长的研究或自动化管道中，因此迁移检查应包括提示、工具假设、输出格式和任何存储的模型白名单。

尚不确定的事情

Google 的发行说明指出了已弃用的 slugs、替换和重新路由行为，但它们并没有解决下游平台的所有操作问题。这些注释没有提供所引用的变更日志条目中旧版和替换版 Flash 模型之间的广泛行为比较。他们也没有像 Deep Research 预览代理那样规定已弃用的 Flash slug 的关闭日期。

这给团队留下了一个熟悉的API管理问题：兼容性目前可能会继续，但稳定状态仍然是迁移。开发者应更新显式模型选择，针对替换 ID 重新运行关键评估，并确保日志保留足够的详细信息来解释转换期间发生的情况。

更广泛的教训是型号 ID 不再是简单的产品名称。它们可以是稳定版本、移动别名、兼容性垫片或弃用陷阱。想要为客户提供可靠控制的网关需要一个可以直接表示这些差异的数据模型。