Nano Banana 2 Lite 是你的新默认 Gemini 图像端点 — 三层路由决策框架

Google 在 6 月 30 日发布 Nano Banana 2 Lite（gemini-3.1-flash-lite-image）绝非只是一次普通的模型上新——它标志着 Nano Banana 家族已形成足够完整的分层结构，可以作为结构化路由层来使用，而不再是单一默认端点。配合同期发布的 Gemini Omni Flash 视频模型，Google 实际上向开发者公开了多媒体管线的参考架构。如果你的图像生成路由仍然指向 gemini-2.5-flash-image（原始 Nano Banana），你正在使用 Google 自己已经明确建议废弃的上上代模型。

发生了什么

2026 年 6 月 30 日，Google DeepMind 同步向开发者通过 Gemini API 和 Google AI Studio 发布了两款模型：

• Nano Banana 2 Lite（gemini-3.1-flash-lite-image）：Nano Banana 家族中速度最快、成本最低的档位。$0.034/千张图像，文字生成图像延迟约 4 秒。Google 官方推荐的 gemini-2.5-flash-image（原始 Nano Banana）替代品。
• Gemini Omni Flash（gemini-omni-flash-preview）：视频生成与对话式编辑模型，$0.10/秒输出，已在前期单独分析文章中详细解读。

Nano Banana 家族现已形成三个档位：

遗留模型——原始 Nano Banana（gemini-2.5-flash-image）——已不再受 Google 推荐。官方博客明确写道："我们建议升级到 Nano Banana 2 Lite，以获得更好的质量、更快的速度和更低的成本。"

为什么这对 AI 工程团队很重要

对于任何调用 Gemini 图像 API 的团队，以下三个路由决策都发生了变化。

1. 模型 ID 版本管理纪律。 如果你将 gemini-2.5-flash-image 硬编码为默认图像端点，你现在已经落后两代。与文字模型有时提供 latest 别名追踪当前最佳模型不同，Google 图像模型 ID 明确编码了代际和档位——gemini-3.1-flash-lite-image、gemini-3.1-flash-image、gemini-3.0-pro-image 各有其意。你需要的是模型路由配置层，而不是硬编码字符串，这样在新档位发布时才能快速切换，而不需要在应用代码中全局搜索替换。

2. 档位选择现在是路由策略决策。 在 Nano Banana 2 Lite 出现之前，大多数团队默认使用他们最初接入的那一款 Gemini 图像模型。如今，同一类请求——从文字提示生成图像——已有三个成本/延迟/质量组合可供选择，应根据工作负载上下文来决定：

• 草稿或快速迭代场景，用户需要快速看到多个版本：Nano Banana 2 Lite，$0.034/千张，4 秒延迟。
• 需要高角色一致性或图内文字清晰可读的生产内容：Nano Banana 2（中间档位）。
• 专业精度要求高、预算不是首要约束的场景：Nano Banana Pro。

基于 quality_tier 请求参数进行路由——而不是静态端点——意味着你可以在不重新谈判 provider 合同的情况下，针对每个使用场景兑现独立的 SLO。同一个应用在用户交互预览场景中使用 Lite 档，在最终导出场景中切换至 Pro 档，完全可以通过路由规则表达，而不需要在应用层维护两套 API 调用逻辑。

3. 成本核算现在需要追踪档位信息。 Lite 档位 $0.034/千张对比 Pro 档位更高的费率，在中等规模生产工作负载下，费用差异可以相当显著。以一个每天生成 50,000 张图像的内容平台为例：全部路由至 Lite 档的成本约为 $1.70/天，而全部路由至 Pro 档则可能是 Lite 的数倍以上。账单核对需要追踪每个任务使用了哪个档位，而不仅仅是"调用了 Gemini 图像 API"。这意味着你的 billing 层必须在每个任务记录中保留 model ID，并在月末报表中按档位聚合用量。

路由器/运营商视角

此次发布最具运营意义的地方，是 Google 明确推荐的图像到视频的管线组合模式：用 Nano Banana 2 Lite 批量生成图像，再将结果作为参考帧传入 Gemini Omni Flash 进行视频生成或动画编辑。这种从静态到动态的工作流设计，会让两款模型的 API 调用在时序上形成依赖关系，需要在 gateway 层统一管理。

这种管线模式——快速廉价的图像模型为有状态视频会话提供素材——引入了异步任务协调需求，大多数习惯于同步文字 API 的团队尚未解决这个问题。图像生成本身很快（4 秒），但后续的视频编辑使用 Interactions API，这是一种基于会话的多轮协议。将二者串联起来需要：

• 任务生命周期追踪：哪个图像输出对应哪个视频会话 ID。
• Fallback 路由：如果 Omni Flash 限流或 preview 服务降级，视频腿需要独立的 fallback 策略，不应触发图像的重新生成。
• 成本归因：两个腿以不同费率计费（$0.034/千张 vs $0.10/秒视频），必须正确归因到对应的团队/项目账单条目。

对于使用 TheRouter 异步媒体管线支持的团队，这些图像生成任务可以通过标准 /v1/jobs/:id 生命周期提交，model 参数设置为 google/gemini-3.1-flash-lite-image。基于请求元数据在 Lite、中间档和 Pro 之间做档位路由，可以在不改动应用代码的情况下通过路由规则来表达。

实用路由规则示例：

{
  "routes": [
    { "condition": "req.quality == 'draft'", "model": "google/gemini-3.1-flash-lite-image" },
    { "condition": "req.quality == 'balanced'", "model": "google/gemini-3.1-flash-image" },
    { "condition": "req.quality == 'pro'",     "model": "google/gemini-3.0-pro-image" }
  ]
}

这套配置也能让你在 Nano Banana 2 Lite 的 preview 标签下线、正式版模型 ID 发布时保持平稳——你只需更新一处路由配置，而不是修改数十个应用调用点。

TheRouter 用户应关注和尝试的事项

• 尽快从 gemini-2.5-flash-image 迁移。Google 将 Nano Banana 2 Lite 作为官方替代品。确认你的路由配置已指向 gemini-3.1-flash-lite-image，在旧模型从 Gemini API changelog 中老化退出之前完成切换。
• 为图像生成建立档位路由规则，如果你的工作负载横跨草稿、均衡和高质量三种需求。这能同时避免过度支出（将所有流量路由至 Pro）和欠缺服务质量（将所有生产内容路由至 Lite）。
• 评估图像到视频的组合模式，如果你正在考虑 Gemini Omni Flash。上游图像生成腿（Nano Banana 2 Lite）足够快且廉价，可以在每次视频会话启动前预先运行，但这需要只有在你的 gateway 支持关联异步任务追踪时才能干净地实现。
• 主动追踪 preview 模型 ID 的变更。 gemini-omni-flash-preview 和 gemini-3.1-flash-lite-image 目前均处于 API preview 状态。Google 此前曾在 GA 兄弟版本发布后 30-60 天内将 Gemini 图像 preview 模型标记为废弃。设立路由配置复盘机制，而不是手动提醒。
• 关注 Nano Banana 2 Lite 在 Google 消费者产品中的规模铺开。 官方博客提到 Nano Banana 2 Lite 正同步在 AI Mode in Search、Gemini app、NotebookLM、Google Photos 等产品中部署。这意味着该模型会经历高并发真实流量压力测试，其稳定性和 rate limit 表现值得在 preview 阶段密切观察。如果你的工作负载对延迟或可用性敏感，可以考虑在路由规则中为 Lite 档配置 fallback，指向 Nano Banana 2 以应对突发限流。
• 查阅 Gemini API 图像生成文档 获取完整模型对比表，以及 preview 状态变更后的最新定价信息。