Gemini 2.0 Flash 已于 2026 年 6 月关停（EOL）：替代方案与现在该做什么

如果你的路由策略使用 gemini-2.0-flash 或 gemini-2.0-flash-lite 作为成本优化目标——无论是主路由还是 fallback——你面临一个硬截止日期：2026 年 6 月 1 日。Google 官方 Gemini API 定价页面已显示醒目警告：这两个模型已弃用，将在 7 天内关停。6 月 1 日之后，对这些 endpoint 的所有调用将失败。

这不是软弃用。自 2026 年 3 月 6 日起，这两个模型已限制新客户访问；6 月 1 日是完全关停。受影响的团队现在就需要审计配置中的模型 ID，不能等到下一个迭代。

哪些模型将被关停

以下模型 ID 将于 2026 年 6 月 1 日不可用：

• gemini-2.0-flash — 正式发布版 Flash 模型。定价为每百万 input/output tokens $0.10/$0.40
• gemini-2.0-flash-lite — Lite 变体，定价 $0.08/$0.30 每百万 tokens
• gemini-2.0-flash-001 与 gemini-2.0-flash-lite-001 — 固定版本。自 3 月 6 日起已仅限现有客户访问

注意：gemini-3.1-flash-lite-preview 已于**今天（5 月 25 日）**单独关停。如果你使用了该预览模型，它现在已经不可用。

迁移成本现实

"迁移"这个词让人以为只是换个模型 ID。成本现实更为复杂。Gemini 2.0 Flash 是 Gemini 产品线中定价最低的选项之一，所有可用替代方案的成本都更高：

价格最接近的选项 gemini-2.5-flash-lite（$0.10/$0.40）是上一代模型，Google 迟早也会弃用它。当前最便宜的 Gemini 3 代替代品是 gemini-3.1-flash-lite，每百万 tokens $0.25/$1.50。对于以 Gemini 2.0 Flash 承载主要成本的高吞吐量工作负载，这 2.5–3.75 倍的涨幅非常显著。

成本抵消在很大程度上取决于你能否启用上下文缓存（context caching）。Google Cloud Gemini Enterprise Agent Platform 现在默认开启隐式缓存，可为已缓存的 input tokens 提供 90% 折扣。对于系统提示词或文档在请求间重复使用的工作负载——代码审查、文档问答、带共用指令的分类——上下文缓存可以充分抵消基础模型价格的上涨。

为何对 AI 工程团队影响重大

模型 ID 很可能分散在多处配置中。 Gemini 2.0 Flash 自 2025 年初起便已可用，作为 Gemini 生态中最具性价比的选项已使用超过一年。它可能出现在路由配置、fallback 链、成本分层规则、限流绕过规则，以及跨多个服务的直接 SDK 调用中。仅审计主配置远远不够——你需要搜索所有代码仓库、环境变量和基础设施即代码文件中的 gemini-2.0-flash 和 gemini-2.0-flash-lite。

Fallback 链是隐蔽的风险。 主模型配置通常有据可查，fallback 链则未必如此。如果你的路由层在主模型不可用或过载时回退到 gemini-2.0-flash，那么 6 月 1 日之后 fallback 就会变成故障路径，而不是可靠性保障。弃用不仅影响主流量——它从所有引用该模型的 fallback 链中移除了整整一个层级。

Gemini 3 代定价跃升改变工作负载经济性。 专门基于 $0.10/$0.40 定价点构建生产工作负载的团队，迁移到 gemini-3.1-flash-lite（$0.25/$1.50）将改变单位经济模型。每月 10 亿 tokens 的工作负载（以 input 为主，使用 2.0 Flash）大约从 $300 涨至 $750。这是需要向财务披露的预算项目，不仅仅是工程配置变更。

Gemini CLI 弃用使截止压力加倍。 Google 还宣布现有 Gemini CLI 将于 2026 年 6 月 18 日硬性关停，并推动用户迁移到新的 Antigravity CLI。使用 Gemini CLI 进行脚本编写、本地开发或 CI 管道的团队，将在三周内面临两个连续截止日期：6 月 1 日（模型 ID）和 6 月 18 日（CLI 工具）。

路由运营迁移执行手册

将此视为两阶段操作：

第一阶段：审计（今天执行）

1. 搜索所有配置文件、环境变量、SDK 初始化代码和路由规则中的 gemini-2.0-flash 与 gemini-2.0-flash-lite。包含固定版本（-001、-exp、任何日期快照）。
2. 识别每处使用是主路由还是 fallback。两者都要记录。
3. 对每处使用，确定工作负载类型：延迟敏感的实时任务、成本敏感的批处理、代码生成、分类、长上下文文档处理，或多模态。

第二阶段：用正确的模型替换，而不是随便换一个

替换选择不能一刀切：

• 成本敏感、简单任务、批处理工作负载：先用 gemini-2.5-flash-lite（价格相同，上一代）进行评估，再决定是否切换到 gemini-3.1-flash-lite。如果质量足够，这是迁移摩擦最小的选项。
• 成本敏感且需要 Gemini 3 质量：gemini-3.1-flash-lite（$0.25/$1.50）。若有重复的大输入，开启上下文缓存——90% 的缓存 token 折扣将显著缩小与原来的实际成本差距。
• 使用共用提示词的大规模分类或提取任务：带隐式缓存的 gemini-3.1-flash-lite。有效缓存 input 费率为 $0.025/M，在缓存命中率合理的情况下，规模化后甚至比 Gemini 2.0 Flash 更便宜。
• 代码生成或复杂推理原本使用 2.0 Flash 作为低成本路径：根据质量需求迁移到 gemini-3-flash-preview（$0.50/$3）或 gemini-3.5-flash（$1.50/$9）。这些不是所有 prompt 的等效替代——在路由生产流量前先测试。

上下文缓存作为成本杠杆： 如果从 Gemini 2.0 Flash 迁移到 gemini-3.1-flash-lite，且你的工作负载有重复使用的大型系统提示词（>10K tokens），缓存该提示词段落可以将有效 input 成本降至 $0.025/M——远低于 Gemini 2.0 Flash 在这些缓存 tokens 上 $0.10/M 的定价。如果你的架构支持缓存，3.1-flash-lite 迁移后的总成本最终可能低于今天。

更新 Fallback 链： 替换主模型 ID 之后，要显式更新 fallback 链。不要在任何 fallback 位置保留 gemini-2.0-flash 或 gemini-2.0-flash-lite。停用的模型在 fallback 链中会静默失败，直到 fallback 在负载高峰时被触发——届时失败才会以服务中断的形式暴露，而不是配置告警。

TheRouter 用户需要关注和执行的事项

• 现在就审计 Gemini 2.0 Flash 引用。 如果你通过 TheRouter 路由到 Gemini API，搜索你的 provider 和路由规则配置中的 gemini-2.0-flash。用明确的当前模型 ID 替换，而不是依赖自动别名——6 月 1 日的截止日期是硬性的。
• 在切换 fallback 之前测试成本影响。 2.5 倍到 15 倍的成本区间意味着盲目换成"最近似等价"的模型可能显著改变你的月度账单。在切换生产路由之前，使用你实际的 prompt 分布测试目标模型。
• 启用上下文缓存（如尚未启用）。 如果你的 Gemini 工作负载使用大型重复系统提示词或文档，隐式缓存（90% 缓存 token 折扣）可以抵消大部分 Gemini 3.x 的价格涨幅。此功能可通过 Google Cloud 上的 Gemini Enterprise Agent Platform 获得。
• 同时为 Gemini CLI 截止日期设置提醒。 6 月 18 日是 Gemini CLI 关停日期。如果你有任何脚本、CI 管道或本地工具使用旧版 CLI，这是三周内需要处理的第二个截止日期。