Imagen 4 停用后怎么迁移？Nano Banana 2.1 与 Pro 选择指南

现有 Imagen 4 接入应迁出旧模型。直接使用 Gemini Developer API 时，先评估 Nano Banana 2.1；已有 Firebase AI Logic 应先从它明确列出的 Pro 或 Lite 中选候选，并确认所用 SDK 和提供方的支持。 2.1 的正式模型 ID 是 gemini-nano-banana-2.1。Imagen 4 的三个模型已于 2026 年 8 月 17 日在 Gemini API 停用，Google 模型弃用表把它们的替代模型指向 2.1。

截至 2026 年 10 月 8 日，过去常用的 Nano Banana 2（gemini-3.1-flash-image）在 Gemini API 上已标为弃用，但没有公布关闭日期；2.1 发布当天弃用表里曾短暂出现过 10 月 29 日，随后已撤下。Google 在 Vertex AI 上为它保留的支持期是“2027 年 5 月 28 日或更晚”。所以 NB2 目前没有硬性下线期限，不必为某个日期紧急切换，但它也不适合作为新的长期默认：Google 的图像指南已建议所有新项目使用 2.1。

选择 2.1 的理由是它覆盖 1K、2K、4K、参考图编辑，以及文本、图片、视频和 PDF 输入，适合承接多种旧图像任务；选择 Pro 的理由应是它在你的文字、构图、主体一致性和成品验收中能减少返工。规格覆盖不等于风格完全相同，模型名字也不能证明交付效果。下面的流程会分别解决停用日期、替代选择、请求和响应改动、费用及切流后的恢复。

先按接入方式确认 Imagen 4 的停用边界

截至 2026 年 10 月 8 日，相关文档给出的 Imagen 停用日期都已经过去。把旧 Imagen 留在配置里，不应再视为可靠的备用方案；文档日期也不等于我们实际探测过某个账号或端点。

上述差异可直接核对 Developer API 弃用表、Firebase Imagen 迁移说明和 Firebase 模型支持表。Firebase 两处日期为何不同，目前没有足以解释的依据，不能拼成一个统一日期。不过这不妨碍行动：今天的迁移和回滚都不应依赖旧 Imagen 端点。

需要从配置和日志里找出的旧 ID 是 imagen-4.0-generate-001、imagen-4.0-ultra-generate-001、imagen-4.0-fast-generate-001。同时记录调用方法、提供方和最后一次成功记录，才能判断究竟是旧模型停止服务、客户端方法发生变化，还是请求配置出了问题。

另一个容易混淆的日期是 2026 年 6 月 24 日。它对应旧 Vertex AI SDK 生成式模块的移除安排，不是 Imagen 4 的统一关闭日：该日之后的新 SDK 版本移除相关模块，固定在旧版本的包并不会自动消失。Python 的相关生成式功能迁往 google-genai，JavaScript 则从 @google-cloud/vertexai 迁往 @google/genai；具体范围见 Vertex AI SDK 迁移说明。

Nano Banana 2.1、Lite、Pro 分别适合接什么流量？

直接 Developer API 和当前 Cloud 图像文档都已列出 2.1，可把它作为一般生成和编辑任务的第一候选。Lite 适合只需 1K、无搜索需求的简单任务；Pro 则应进入难例对照，是否承担正式流量由验收结果决定。4K、参考图或文字任务本身，并不自动意味着必须用 Pro。

能力依据是 Google 图像生成指南、2.1 模型说明和 Cloud 图像生成文档。2.1 接受视频输入，但输出仍是图片和文本，并不生成视频；它不支持 512px，不能把旧 3.1 的尺寸配置原样沿用。

参考图数量也要按具体模型处理。2.1 最多 14 张参考图有分类限制：最多 10 个物体参考和 4 个角色参考；Pro 的限制不同，物体和角色分别最多 6 个、5 个。数量上限不保证每个细节都被保留。涉及品牌包装、角色、字体和固定版式时，最终仍要检查实际交付要求。官方图像指南列出了这些参考限制。

图中文字是 2.1 和 Pro 较容易拉开差距的地方。在 2026 年 10 月 8 日的 9 组同题测试里（1K，每题生成一次），Pro 保留了要求的文字，2.1 在 3 个文字任务中改动了措辞；两者都把中文“单”写成了日文字形“単”。样本很小，不能当作通过率，但足以说明：旧 Imagen 任务里有精确标语、价格或说明文字的，应把 Pro 放进对照组。测试设置和全部样张见 Nano Banana 2.1 vs Pro vs GPT Image 2.5 对比：9 组同题实测。

Firebase 项目先选文档列出的模型

截至此次核对，Firebase 模型页列出 Pro、3.1 Flash Image 和 Lite，却没有列出 gemini-nano-banana-2.1。这意味着不能只凭底层 API 支持就宣称 Firebase SDK 也已支持 2.1，也不能反过来断言某个具体 SDK 一定会拒绝它。

需要继续沿用 Firebase 时，可把 1K 简单任务交给 Lite 候选，将 2K、4K 和复杂任务交给 Pro 候选；3.1 已在 Developer API 弃用，只适合作为过渡，并要写好退出计划。若业务必须使用 2.1 的 PDF 输入或其他能力，就要单独评估 Developer API / Cloud 后端接入的工作量，不是只改客户端字符串。Firebase 图像生成要求启用计费的 Blaze 方案，且其 SDK 不提供底层模型全部功能，例如图片搜索增强。Firebase 支持说明

各平台对同一模型的生命周期写法并不一致。Firebase 表把 3.1 和 Pro 写为“不早于 2027 年 5 月 28 日”，Vertex AI 也写“2027 年 5 月 28 日或更晚”；Developer API 则把 3.1 列为已弃用、未公布关闭日期。gemini-2.5-flash-image 更乱：Firebase 模型表和 Gemini API 定价页写 2026 年 10 月 2 日，Developer API 弃用表和 Vertex AI 写 2027 年 3 月 15 日。不要据此认定 Firebase 会延长底层模型寿命，也不要把 2.5 当作免费的长期后备。“未公布关闭日期”也不等于可以无限期保留：已弃用的模型随时可能补上日期，3.1 的迁移排期应以 2.1 或 Firebase 列出的候选为终点。Developer 弃用表；Firebase 模型表；Vertex AI 模型版本与生命周期

迁移请求：不只替换 model 字符串

旧 Imagen 的生成调用与 Gemini 的多模态生成合同不同。迁移要同时处理模型、输入和生成配置、响应解析。沿用旧 generate_images 方法，再把 Imagen ID 换成 Gemini ID，不能让已经停用的 Imagen 调用恢复工作。

已有 generateContent 客户端可以继续使用该接口，Google 仍然支持它；新接入则可评估已正式发布的 Interactions。两者的字段不混用：

下面给出 Developer API Interactions 的请求体示例，用于明确字段变化。发送目标为 POST https://generativelanguage.googleapis.com/v1beta/interactions，认证使用该 Google 项目的 x-goog-api-key。Cloud 凭据和第三方网关的 Bearer Key 不能直接替代它。此处未进行真实 API 调用，示例也不代表你账号、地区和额度已验证可用。

{
  "model": "gemini-nano-banana-2.1",
  "input": "生成一张横向商品宣传图：白色陶瓷咖啡杯置于浅木桌面，右侧留出后期排版空间，不在图中加入文字。",
  "response_format": {
    "type": "image",
    "mime_type": "image/png",
    "aspect_ratio": "16:9",
    "image_size": "2K"
  },
  "store": false
}

2K 的 K 要大写。需要参考图片时，input 改成文本和图片内容的数组，图片项使用 type: "image"、原始 Base64 的 data 和 mime_type，而不是把旧 Imagen 参数或其他服务商的顶层 images 数组搬过来。请求和输出结构见 官方图像生成指南。

走 Vertex AI 的项目还要清理采样参数：2.1 在 Vertex 上只在 global 区域提供，收到 seed、topK、logprobs、temperature 或 topP 会直接返回 API 错误。旧 Imagen 配置里用 seed 追求可复现，迁到 2.1 后不能再靠它，要改为保存提示词、参考图版本和最终成品。Vertex AI 的 Nano Banana 2.1 模型页

这里选择 store: false 是为了让示例不依赖服务端存储历史。它不能用于后台执行，也不能通过返回的 ID 续接已保存的服务端历史，不等于零数据保留承诺。如果业务需要多轮编辑，要按所选方式携带历史；使用 previous_interaction_id 时，工具、系统指令和生成配置不会自动随历史继承，应再次发送当前选项。Interactions 生命周期说明

Firebase 旧配置怎么改？

Firebase 的改动不止类名。ImagenModel 改为 GenerativeModel，ImagenGenerationConfig 改为 GenerationConfig 加 ImageConfig，安全设置由 ImagenSafetySettings 改为 SafetySetting。ImageConfig 适用于 2026 年 5 月之后相关 SDK 发布版本，升级前应对照实际平台和版本。Firebase 配置迁移表

把“多张图片”改成多个任务，还要同步修改前端进度、任务超时和部分成功的展示：原来一个任务返回四张，现在可能是四个任务各返回一张。保留业务任务 ID 及每个子任务的结果，才能恢复已完成部分，避免一次失败就重新生成全部图片。上述单张及 PNG 限制是 Firebase SDK 的合同，不应套用到所有 Gemini 协议。

迁移响应：拿到图片后才算生成成功

HTTP 200 不足以证明用户拿到了可用图片。响应可能只有文本，或者包含多个步骤和多段内容。Interactions 的 SDK output_image 便捷属性只返回最后一张图片；如果要保留本次响应中的所有输出图，应遍历相应 model_output 内容，不能再同时保存便捷属性而重复写入同一张图。图像输出说明

下面是一个离线图片提取脚本：将代码保存为 extract_images.py，把已经收到的 Interactions JSON 保存为 response.json，然后执行 python3 extract_images.py response.json output-images。它不发请求，只按内容类型解析并保存图片；也不做图片质量或可交付性判断。

import base64
import json
import sys
from pathlib import Path

extensions = {
    "image/png": ".png",
    "image/jpeg": ".jpg",
    "image/webp": ".webp",
}
response = json.loads(Path(sys.argv[1]).read_text(encoding="utf-8"))
images = []
for step in response.get("steps", []):
    if step.get("type") != "model_output":
        continue
    for block in step.get("content", []):
        if block.get("type") != "image":
            continue
        mime = block.get("mime_type")
        if mime not in extensions:
            raise ValueError(f"未处理的图片格式：{mime}")
        data = block.get("data")
        if not isinstance(data, str) or not data:
            raise ValueError("图片内容缺少非空 Base64 data")
        raw = base64.b64decode(data, validate=True)
        if not raw:
            raise ValueError("解码后的图片内容为空")
        images.append((extensions[mime], raw))

if not images:
    raise ValueError("响应没有图片，不能登记为生成成功")

directory = Path(sys.argv[2])
directory.mkdir(parents=True, exist_ok=True)
for index, (extension, raw) in enumerate(images, start=1):
    target = directory / f"image-{index}{extension}"
    target.write_bytes(raw)
    print(target)

这个脚本先检查图片块，再写文件；它跳过文本和非 model_output 步骤，不假设第一块就是图片。PNG、JPEG、WebP 的扩展名跟随响应 MIME，未知格式明确停止。脚本的语法及多步骤、文本在前、无图、异常 Base64 等分支经过合成响应的离线检查；这不证明后端已经接受上述请求，也不证明字节内容一定是有效图片。

进入正式应用前，还应使用图片解码器核对文件确实可打开、尺寸符合请求、文件没有损坏，再让验收逻辑判断内容。Firebase 的固定 PNG 响应可使用对应处理；generateContent 则应遍历它自己的 candidates[].content.parts[]。不同协议不能共用一个只读 parts[0] 或固定写 .png 的旧解析器。

成本比较要算到“可交付的一张图”

截至 2026 年 10 月 8 日，以下为 Gemini Developer API、美元、Standard 计费的图片输出部分，不包含输入、文字或思考输出、搜索及其他费用。它不是完整单次账单，也不适用于第三方报价；Vertex AI 上这几项图片输出单价与此相同，但账号和其他费用另算。Gemini API 定价表

以 2.1 的 2K 为例，1,680 个图片输出 token 乘以每百万 token 30 美元，得到 1,680 ÷ 1,000,000 × 30 = 0.0504 美元。它的 Standard 输入费率为每百万 token 1.5 美元，文字及思考输出为 7.5 美元；因此带很多参考图、文档或思考输出时，不能只拿 0.0504 美元做预算。Lite 和 2.1 的 1K 图片输出价格相同，也不意味着总费用或能力相同。费率及 token 说明

2.1 的 4K 按 3,780 个图片 token 计费，3,780 ÷ 1,000,000 × 30 ≈ 0.113 美元。发布最初两天定价页曾写 0.0756 美元，按旧数字做的 4K 预算需要上调约 50%。所以 2.1 在 1K、2K 上约为 NB2 的一半，4K 只比 NB2 的 0.1512 美元低约 25%。各档价格和入口的完整对照见 Nano Banana 2.1 价格与入口：1K/2K 比 NB2 便宜一半，4K 只省 25%；仍在用 NB2 的项目可对照 Nano Banana 2 API 价格：每张 $0.045–$0.151，已弃用，2.1 更便宜。

2.1 的 Batch 图片输出费率为每百万 token 15 美元，按相同图片 token 数计算，1K、2K、4K 分别是 0.0168、0.0252、0.0567 美元。模型支持 Batch，不代表可以猜出一个 /interactions/batch 端点；要按已公布的 Batch 接入方式另行确认。2.1 不支持 Flex/Priority，不能把其他模型的价格列当成它可用的选项。2.1 模型能力

使用搜索增强时还要计入实际搜索次数。当前定价列出每月 5,000 次免费查询额度，与 Gemini 3.x 的相关额度共享，之后为每 1,000 次实际查询 14 美元；一次生成可能触发多次查询。这个搜索额度不等于免费生图额度。当前 2.1 定价行没有免费 API 层，AI Studio 的试用界面也不保证你的生产 API 请求免费。搜索与图像费用

按次计费的第三方接口是另一种口径。例如老张API 的 Nano Banana 2.1 文档列出 2.1 每次调用 0.045 美元，不分尺寸和思考档位，2026 年 10 月 8 日的实际调用也按此扣费；传入 512 会得到 1K 图片并照常计费。和官方 Standard 图片输出部分相比，它在 4K 上更低（0.113 美元），在 1K、2K 上更高。它不是 Google 的接入方式，迁移时要按它自己的文档确认模型 ID、限额和失败计费。

说明：laozhang.ai 是我们自己的服务，其价格是平台报价，不是独立比较的结论。

迁移评估更有用的分母是验收通过、能够交付的图片数量：

每张可交付图的 API 成本 = 本组实际 API 总费用 ÷ 本组验收通过的图片数
每张可交付图的完整成本 =（API 总费用 + 人工修补与审核费用）÷ 验收通过的图片数

假设 2.1 生成 100 张 1K 图片，只有 70 张通过验收，单算图片输出就是 100 × 0.0336 ÷ 70 = 0.048 美元/张。假设 Pro 同样生成 100 张、90 张通过，则是 100 × 0.1344 ÷ 90 ≈ 0.1493 美元/张。这组假设中 Pro 虽然通过率更高，图片输出成本仍更高。 只有再加上真实的输入、思考、重试和人工费用，才能判断它是否更划算。这是可复算的例子，不是模型通过率实测或实际账单。

保住 Imagen 的交付要求，再逐步切流

迁移时应保留旧提示词、已合法保存的 Imagen 成品和原验收要求，作为历史基线。旧模型已经进入停用边界，今天不应安排靠旧 Imagen 在线生成的“双跑”；可以比较已存旧产物与新候选，或在两条仍受支持的新路线之间对照。

测试集应覆盖实际业务中会改变路由决定的任务，不需要照搬固定数量。商品图重点检查物体、材质和品牌细节；文字图检查字词和版式；角色编辑检查身份及未要求修改的细节；客户交付还要核对尺寸、裁切、安全要求和审核结果。旧样张中的偶然好图不能代替整组基线。

输出文件能打开后，再做内容验收，避免把接口成功率和交付通过率混为一谈。每组记录候选模型、尺寸、提示词及参考版本、生成次数、验收结果、修补时间和费用；只有这样才能知道该改提示词、换模型，还是修复解析器。

切流可以先从已经通过验收、失败影响较小的任务开始，再扩到其余任务。每一步保留可恢复的配置版本，记录业务任务对应的模型和最终产物；停止条件应由业务承受能力决定，例如图片丢失、格式不符、审核退回或成本超出预算，而不是机械套用某个固定灰度比例。

出问题能回滚到哪里？

回滚应指向此前在同一接入方式下验证过、现在仍受支持的候选模型和配置。可以切回另一条 Gemini 图像路线，或暂缓生成、使用有权复用的现存素材、转人工处理。某条备用路线只有名字写在配置里，却未核对支持和验收，就不能算恢复方案。

先按症状决定恢复动作：

• 404 / 找不到模型： 核对精确 ID、提供方、接口和停用表；退役 ID 不靠反复重试恢复。
• 400 配置错误、402 付款问题或 403 权限错误： 分别处理参数、计费或权限，不能把所有失败归为模型退役。不要自动更改账户或安全设置。
• 429 / 配额不足： 按项目配额处理排队和有界重试；增加 API Key 不会增大同一个项目的额度。
• 503、504 或网络超时： 先检查任务和已知结果，再决定是否重试。超时可能处于结果未知状态，重发有重复生成及计费风险。
• 有响应但没有图片、安全拦截或内容不合格： 不登记为交付成功；分别检查响应、安全要求和提示词，不通过降低安全阈值解决。

错误处理依据见 Google API 错误说明和 项目级限额说明。重试、模型切换、是否收费是不同问题，不能从某个错误码推断失败一定免费。

常见问题

Imagen 4 现在应该换成 Nano Banana 2 还是 2.1？

直接使用 Gemini Developer API，先评估 gemini-nano-banana-2.1。旧 Nano Banana 2 的 gemini-3.1-flash-image 在 Gemini API 上已弃用，目前没有公布关闭日期，Google 建议新项目使用 2.1；已经在用它的项目可以有计划地迁移，不宜再做新的长期默认。Firebase 项目需单独确认 SDK 支持，当前模型页明确列出的是 Pro、3.1 和 Lite。Developer 弃用表；Firebase 模型表

我原来用 Imagen 4 Ultra，必须改用 Pro 吗？

不必只按旧型号名称决定。Firebase 迁移页保留 Ultra 到 Pro 的映射，可作为候选起点；直接 API 的当前 Imagen 替代建议已经是 2.1。对照你原来的高风险成品要求，比较参考保留、文字、版式、修补时间和可交付图成本，再决定是否采用 Pro。Firebase 迁移说明；Google 当前替代建议

只是换模型，也必须迁到 Interactions 吗？

不必须。已有 Gemini generateContent 接口仍受支持，但要检查所选模型的配置和图片响应解析。旧 Imagen 的调用方法与 Gemini 生成接口不同，不能仅替换 ID。Interactions 请求使用 input、response_format，响应使用 steps，不要与 contents、candidates 混用。Interactions 概览

2.1 和 Lite 的 1K 价格一样，为什么不全部用 Lite？

相同的是当前 Developer API Standard 的 1K 图片输出部分，均为 0.0336 美元；输入及文字费用不同。Lite 只支持 1K、没有搜索增强，2.1 还提供 2K、4K 及更多输入能力。先看任务是否需要这些能力，再比较实际可交付图成本。官方价格；图像能力对照

还能把旧 Imagen 4 或免费 2.5 留作备用吗？

不要依赖旧 Imagen 回滚，已公布的停用边界都已过去。2.5 的关闭日期在 Google 自己的页面之间也冲突（2026 年 10 月 2 日与 2027 年 3 月 15 日并存），也没有足以把它称为免费生产替代路线的依据。备用方案应是你已确认支持并通过验收的当前模型、任务排队或人工处理，而不是另一个未经确认的旧 ID。Developer 弃用表；Firebase 模型表