Nano Banana 2.1、2 Lite、Pro 怎么选？从交付任务而不是版本号开始

做一张带文字的品牌图、连续修改同一个人物，和批量生成一百张低分辨率素材，不该只凭“Nano Banana 版本越新越好”来选同一个模型。 Google 当前的图像生成选型文档把 Nano Banana 2.1 放在高效率通用起点，把 2 Lite 放在低延时、高量级的 1K 任务——它的输入 token 单价较低，但 1K 图像输出与 2.1 同价——把 Pro 放在复杂视觉交付；旧 2 仍有 Stable API ID，却不再是官方给新项目推荐的起点。以下是文档定位、规格和 Google 直连 API 价目的选型地图，不是本站同题画质排名。

本文是截至 2026 年 11 月 11 日的官方资料介绍，不是 2.1 当天新品报道，也不是本站实测。四款都可以在官方型号页找到 Stable ID；“Stable”是文档里的版本标识，不保证任何一个付费项目在所有地区、组织权限和配额下已经可调用，更不能推出本站对外供应或本站价格。

先决定要交付哪种图，再看 Nano Banana 的型号名

假设一个团队要出三种内容。第一种是带中英文说明、品牌色和图表的一张主视觉：如果文字出错，设计师必须回到稿件逐项校对。第二种是同一角色与产品贯穿五张社媒图，客户会逐轮说“换标题，不要换脸”。第三种是大量简单背景或贴纸，单张的创造性不如延时与单位成本重要。这三个是假设任务，用来区分验收条件，而非本站客户案例。

Google 的图像生成文档「Model selection」给了清楚但容易被名字掩盖的四层关系：2.1 是从 Nano Banana 2 更新而来的高效工作模型，重点写多轮编辑、文字、视觉质量与搜索辅助；2 Lite 是追求速度与规模的效率档，官方也说它没有针对多参考输入或多轮连续编辑做优化；Pro 是利用更深推理处理复杂视觉任务的高阶档；Nano Banana 2 成了上一代高效工作模型，Google 建议新项目使用 2.1。这里的“建议”和“优化”都是 Google 的产品定位，尚不是我们能替你的素材品类下的质量结论。

别把一个系列名字当成 API 代码。Google 还列着更早的 Nano Banana，对应 gemini-2.5-flash-image；本文说的旧 2是 gemini-3.1-flash-image，不是这一款原版。讨论迁移时，“旧”只表示官方给新项目的推荐起点发生变化，不等于原有 ID 已停用、已有作品必须重做。账单、接口和审核策略都应以实际调用的型号为准。

四个 Stable API ID：同是图像生成，规格不能互换

按 2026 年 11 月 11 日归档的四张官方型号页，四个 ID 都标记 Stable。下表是 Google 开发者文档的型号对应与用途摘要，不是本站平台的可购目录；详情要回各自模型页核对。

2.1 型号页写的是 gemini-nano-banana-2.1，并注明默认输出 1K；2 Lite 型号页明说其 image_size 支持 1024px，2K 与 4K 不支持；旧 2 型号页列出 0.5K、2K、4K 等选项；Pro 型号页则把复杂图形设计、产品视觉和文字渲染列为目标。模型页所列的支持模态也不同：Pro 输入是图像和文本，2.1、2 Lite 与 2 的页面列出文本、图像、视频、PDF 输入；不能因为都叫图像模型，就给所有版本照抄同一套调用参数和参考材料。

分辨率还要和交付场景核对。一个最终必须输出 4K 的商业视觉，不能让只列 1K 的 Lite 直接承担 4K 交付；一个只在手机上看的低价贴纸，也不该因为有 4K 按钮就无条件升到高档。相反，0.5K 不是低质量的同义词：旧 2 在官方表里保留这一档，是否适合作内部预览要看你的验收宽高与清晰度，不能在没有成图时替所有项目宣布“够用”。

带字品牌图：为什么先试 2.1，再考虑 Pro？

若要交付一张跨语言的产品介绍图，模型是否会拼写、能否把标题、数字和图例放在指定位置，比“画得有氛围”更难验。Google 将 2.1 定位为通用高效工作模型，并在2.1 型号页称它改进了文字渲染、信息图排版、人物多轮一致性和视觉真实感。这是一条值得从 2.1 起步的厂商选型建议；文字准确与版式仍须看实际成图。

官方图像生成文档示范了一张讲光合作用的英文信息图，并接着展示改成西班牙语的版本。这个例子适合说明连续编辑可能要维护什么：保住结构关系，替换文案，同时检查原图和改图的文字是否准确。它只证明官方文档展示了怎样的单模型示例；两张图不是四款模型对同一题的评审样本，也不能由其中一张推导所有语种准确率。

再看官方后续的西班牙语版本：它适合提醒编辑者检查翻译后的标签与图中关系是否仍对应，而不是拿两张小图评出四款模型的文字准确率。

2.1 的参考图能力也容易被“最多 14 张”这个上限误导。Google 文档的参考图说明写 2.1 与旧 2 可组合最多 14 张参考图，其中至多 10 张用于物体、至多 4 张用于角色一致性；Pro 的分配则不同，最多 6 张物体、5 张角色、3 张风格参考。它不是说把 14 张随机图塞入请求就必然得到一致品牌：参考图可能互相矛盾，输入长度和费用也可能增加。正式用在品牌项目之前，最好把“保持哪几个对象不变、哪些文字需要逐字正确、允许变动哪一项”写进验收单，并由人逐项检查成图。

Pro 是另一条值得保留的路径。Pro 型号页将它描述为面向复杂图形设计、忠实产品样机、带准确文本的事实性数据可视化；Google 的选型文档也用高阶复杂视觉任务定位它。当 2.1 产物需要反复人工修标题、数据表或品牌细节时，可以让 Pro 试相同材料和验收规则：如果它减少退稿，较高图像单价可能值得；如果 2.1 已经合格，单凭“Pro”名字没有升级理由。没有同题盲评与人工改稿时长，就不能在文章里写哪一款画质全面更好。

一百张小图：2 Lite 可能省下的是工作流，不只是图片价格

Lite 的型号页写“面向极低延时、性价比高的生成和编辑”，列出低于两秒的目标场景、局部多轮修改以及 1K 输出；文档选型段落称它是该家族最快、最便宜的效率档，同时指出并未针对多参考输入和多轮连续编辑优化。两个表述并不矛盾：支持做轻量修改，不等于复杂人物连续五轮的质量与稳定性是其强项。所谓“低于两秒”属于官方型号页的能力定位，本文没有测网络、队列、首图或整个交付链路的实际耗时。

例如一批一百张分类贴纸，约束是颜色、形状与单张 1K 规格；若没过关可以自动重试或由编辑抽检，这类任务适合让 Lite 进入第一轮试点。但如果是同一代言角色持续修五张画面，某一次编辑换掉了角色面貌，后面的产物就会一起返工。此时真正的成本单位不是一张生成图，而是一张审核通过并可发布的图。2.1 更强调连续编辑一致性，是否能抵消其输入和返工成本，必须拿同一份素材与相同审核规则来比较。

一项批量流程还可能先用低成本档做草稿、再把少数难图交给更复杂的型号。这是编辑建议，不是 Google 公布的自动路由产品，也不是本站已有的产品能力。工程上需要把每张图的模型 ID、参考图数量、请求尺寸、重试次数和最终是否采用记在同一账单；没有采纳率，单张输出价再漂亮也不足以预算整批素材。

旧 2 还在 Stable 表里，为什么 Google 建议新项目改从 2.1 开始？

Google 选型文档称 Nano Banana 2 为上一代高效工作模型，并建议所有新项目用 2.1。这个句子既不是一则下线通知，也不是过去客户项目可以无痛改 ID 的证据。旧 2 的型号页仍列 Stable gemini-3.1-flash-image、4K 和 0.5K 输出、搜索辅助与高吞吐定位。它与 2.1 同属官方文档当前可列模型，但支持档位、图像价格和实际效果不能只从代数推断相同。

如果现有工作流已经绑定旧 2 的比例、特定输出尺寸或多参考图写法，第一步不是“查到 2.1 更新了就字符串替换”。应保存旧版输入、预期输出和审核样本，在隔离试点里换 ID 后比对文字、构图、参考物体保真以及是否触发了不同的工具/思考用量。旧 2 的 0.5K 价目选项尤其值得先核：如果这档用于快速候选图，2.1 的当前 Standard 表没有对应 0.5K 单张示例价，不要把“1K 更便宜”直接折算成相同尺寸的替代。

这样做的重点不是为旧版辩护，而是避免把迁移当改名。文档中的推荐解决的是新项目从哪里开始；既有项目是否要迁，取决于同一批合格结果有没有改善，以及迁移后提示词、图片尺寸和预算纪律能否保持。若账号在某地区看不到新 ID，或者请求尺寸不被接受，要先把这些记成试点失败原因，不要用旧版成图冒充新版验收。

1K、2K、4K 价格怎么读：图像输出不是完整账单

以下数字来自 Google Gemini Developer API 的 Standard 价目页，2026 年 11 月 11 日归档，单位是美元/一张该档输出图像的官方等价价，不含请求的其他计费部分。1K 指约 1024 像素级的输出档位，不是 1000 个 token，也不表示任何宽高比都恰好为 1024×1024 像素；2K/4K 同理是分辨率档位。表中“—”仅表示价目页未列该档示例价，不能据此推断该型号支持或不支持，也不是免费；Lite 的 2K/4K “不支持”另有其型号页明确说明。本表不是本站零售价或最终项目账单；Batch、缓存等其他模式不在这里，是否支持、是否适用及其价格须逐型号核当前官方表，不能从 Standard 输出价推算。

拿 2.1 做一个只算图像输出部分的假设：若恰好发出 100 次请求，每次都成功生成一张 1K 图，按 Standard 等价价，100 × $0.0336 = $3.36。这不是总账或实测，不含输入、文本与 thinking 输出、可能的工具费用、失败重试和人工审核。只要有改图或退稿，实际要为“100 张合格图”发出的请求就可能超过 100 次。

这张表最容易被误读的是 2.1 和 2 Lite 同为 $0.0336/1K。这只是 Standard 档输出一张 1K 图的等价价相同，不是两模型输入价一样，也不是同一任务的审核通过率、总请求数和总成本相同。Google 页中 2.1 的文本/图像/视频输入价为 $1.50/100 万 token，Lite 为 $0.25/100 万 token；旧 2 的文本/图像输入价是 $0.50/100 万 token。Pro 则列文本/图像输入 $2.00/100 万 token。输入支持范围以各型号页为准，价目列名不能代替能力表，也不能因为某个模态没有单列价格就推导它免费。

尤其不能把“上传一张参考图”的费用混进生成图单价。Google 在Pro Standard 价目脚注直接列一张输入图像计 560 token、约 $0.0011；另三款则在价目里列输入 token 单价，不能从 Pro 的固定参考图数字推导它们每张图也都收 $0.0011。参考图多一张、尺寸变一档、提示词或编辑历史变长，都可能改变输入量；若没拿到请求实际用量，只能把这些记为需要测的费用项，不能报一个凭空的固定“每张参考图”账单。

输出端也不止图像：2.1、Lite、旧 2 与 Pro 的 Standard 表分别列有文本与 thinking 输出单价，与图像输出 token 费不同。一次编辑可能带文本、思考、参考图输入，还可能调用搜索辅助；Google 的搜索条目及计数规则应按实际所选模型和请求另算，不能假设全家共享同一免费额。多轮改图若把以前作品重新作为输入，重试出图若后来被丢弃，它们也是发生过的请求。成本/可用素材 = 生成和编辑全部计费支出 ÷ 审核合格且真的采用的图数，而不是表格里的一张输出价。没有真实调用记录，就不要给客户许诺“2.1 和 Lite 总价相同”或“Pro 一定更贵”。

先在自己的付费项目里小样本验收，再谈换默认模型

写试点任务时，先确定失败后会发生什么。带字促销图若售价、日期或产品名错一个字，就该整张退回；有连续角色的五张图，第二张变了面貌，后面四张即使构图漂亮也未必能用；批量背景图则可以允许抽检，只要未采纳的失败件不会流进发布库。三个任务的“合格”定义不同，所以用一张价格表排出统一优胜者没有意义。尤其不能把官方光合作用例图当质量基准，它没有给四款模型相同的输入、参考图和审稿规则。

对照实验最好同时保留首轮出图和最后采用的版本。只存满意的成图，会让编辑轮数、第一次文字错误和多次失败请求在复盘中消失。给每个样本记下输出分辨率、参考图张数、是否用搜索辅助、逐次修改指令以及人工校对的项目。输出图被放弃也照实计入成本；达到质量标准却超过交付时限的，单列为时间失败，而非悄悄计作成功。这样才能在固定预算和交付期限下，知道选择某档模型改变的是画质、编辑成本，还是产能。

对新项目，先按官方任务定位选择一个起点：多轮带字图用 2.1、简单 1K 批量用 Lite、明确要复杂高保真图文才把 Pro 加进试点。对旧 2 项目，把现有成图、提示词和账单留作基线，而不是先迁全量。随后在同一组真实 brief 上，控制参考图、目标尺寸、审核规则和交付时间；每款至少记录逐次生成、修改、失败重跑及被采用的结果。如果要人工评质量，要求评价者只看输出和预先写好的检查表，不凭型号名给分。本文提出的是试点方案，不是已经执行的同题横评。

验收先判“不该出现”的问题：品牌名或数据是否拼错，人物与商品在下一轮有没有被换掉，长宽比和分辨率是否满足交付，局部改动是否伤了原有结构。再记从第一次请求到最终采用的耗时、模型费与人工修正成本。若 Lite 交出足够多合格小图，不必因为 2.1 名字更新就换它；若 2.1 降低连续编辑返工，不必因为两者 1K 输出单价一样就认为 Lite 已经够用；若 Pro 减少复杂品牌图退稿，高一档单价也可能符合预算。这些都是待实验验证的条件句，不是我们对四款质量的实测结论。

最后核账号和入口：在你自己的 Google 付费项目里确认模型 ID、地区、组织政策、权限、配额与当前价目，检查请求实际返回的用量及图像尺寸。四个型号页的 Stable 标记告诉你该查哪个 API ID，不告诉你某个团队今天一定能调用，更不告诉你另一家平台的零售计费方式。对 Nano Banana 家族，最省时间的下一步不是押一个“冠军”，而是拿一份真实品牌图或一批小图，按交付结果先测一轮，再把可用率和账单写进选型表。