Nano Banana 2.1：Google 图像基准测试揭示了什么
Google 于 2026 年 10 月 6 日发布 Nano Banana 2.1。本文分析日期为 10 月 14 日，将其视为此次发布后的跟进分析，而非今天的新产品发布。
已公布的结果为 Nano Banana 2.1 在多项图像生成与编辑任务上优于 Nano Banana 2 提供了可信依据。报告中最显著的优势似乎体现在信息图设计、多角色一致性、基于蒙版的编辑以及多参考图工作上。启用 Thinking 通常能获得最高分，但其价值会因任务而异。
这些发现需要明确边界。大多数分数是基于偏好的 Elo 评级，而非正确图像的百分比。Google 为 Elo 结果提供了误差范围，却未定义其置信水平。其未在模型卡表格中披露样本量、基准提示词、图像分辨率、重试预算、详细的 Thinking 设置或等量计算条件。事实性结果来自自动评分器，而非人工准确性测量。
因此，这些基准测试可作为 Google 评估条件下相对性能的有用证据，但无法证明生产可靠性、延迟或投资回报。考虑迁移的团队仍需以受控输入、失败标准和完整请求成本，开展针对特定工作负载的测试。
Google 在 10 月 6 日实际发布了什么
Nano Banana 2.1 是 Google 更新后的 Flash 级图像生成与对话式编辑模型。稳定版 Gemini API 模型代码为 gemini-nano-banana-2.1。Google 将其描述为 Gemini 3.1 Flash Image（亦称 Nano Banana 2）的更新版本，同时也是 Gemini 3 Pro Image（通常称为 Nano Banana Pro）效率更高的对应产品。Gemini API 更新日志记录了它于 2026 年 10 月 6 日正式可用。
根据 Nano Banana 2.1 模型卡，该模型基于 Gemini 3.6 Flash，接受文本和图像输入，并返回图像和文本。Google 将其定位于可控图像创作、编辑、文字密集型图形、本地化渲染及迭代式工作流。其评估结合了针对生成与编辑的并排人工偏好判断，以及单侧自动化事实性评估。
模型卡还列出了具体限制：较小或较长的文本可能模糊或失真；身份特征可能漂移；蒙版编辑可能保留笔迹或仅部分遵循指令；姿势可能意外保留；左右等空间关系可能被混淆；世界知识、3D 推理和事实性仍不完善。文档也承认偶尔会出现缓慢响应与超时。这些不是脚注里的小问题，而是运营风险：部署前，每一项都需要验收测试与后备策略。
Google 的 API 模型文档补充了实现细节。输出默认是 1K，最高可请求至 4K。Thinking 提供 minimal、medium——默认选项——和 high。该模型支持搜索 grounding，但不支持函数调用、代码执行或结构化输出。
模型卡列出的上下文最高可达一百万个令牌，文本输出最高可达 64K；而已部署的 Gemini API 页面列出 131,072 个输入令牌和 32,768 个输出令牌。公开文档未解释这些不同限制之间的关系。部署者应遵循其调用的特定端点所记录的限制，而不应假定更大的模型卡数值可通过该 API 使用。
生成 Elo 显示领先，而非准确率
Google 报告了两项经人工评估的文生图对比：总体偏好与信息图设计。在两项测试中，启用 Thinking 的 Nano Banana 2.1 均排名第一，其后依次为未启用 Thinking 的 Nano Banana 2.1、Nano Banana 2 Thinking 和 Nano Banana Pro。
根据 Google DeepMind 于 2026 年 10 月发布的 Nano Banana 2.1 模型卡数值数据制作的编辑图表。更高的 Elo 代表在 Google 对比中更强的相对人工偏好；误差线展示了已公布的 ± 范围，其置信定义尚未说明。这不是 Google 原始图像，Elo 也不是百分比准确率。
在总体偏好方面，Nano Banana 2.1 Thinking 得分为 1050 ±14，而未启用 Thinking 为 1015 ±13，Nano Banana 2 Thinking 为 990 ±7，Pro 为 935 ±8。信息图设计的相应结果为 1048 ±17、1001 ±17、961 ±12 和 912 ±12。
排名顺序保持一致，且部分差距大于展示的范围。尤其是在信息图设计中，即使考虑其公布区间，Nano Banana 2.1 的两种模式均高于 Nano Banana 2。这是在该评估内存在偏好优势的有意义证据。但这并不能证明 2.1 会在每条提示词上获胜、产出正确的信息图，或在生产环境中需要更少重试。
Thinking 在此处看来有益。它相较 No Thinking 的总体偏好领先 35 分，展示区间并不重叠：1036–1064 对比 1002–1028。信息图设计的区间在 1031 处接触，因此图表支持其存在优势，但不能支持一个精确且普适的效应量。Google 对基准配置也仅标注为 “Thinking”。它没有披露运行使用的是 minimal、medium、high、自适应策略，还是其他内部设置。
这一缺失限制了关于成本与延迟的结论。若不衡量每种可用设置对具体工作流的影响，就不能将更高的 Thinking 分数转化为“始终启用 high Thinking”。基准表不包含延迟测量，本文也不应杜撰相关数据。
更准确的实用信号是：用户会评判构图、视觉质感或信息图布局的团队，应将 Nano Banana 2.1 Thinking 作为重要候选方案。生成低风险装饰性资产的团队或许会发现 No Thinking 已足够，但这一决定应基于使用自身提示词与验收阈值进行的受控测试。
一致性有所提升，但单角色结果很接近
在重复角色、活动变体、故事板、产品讲解和多轮编辑中，一致性往往比单纯的吸引力更有价值。Google 将单角色与多角色一致性分开评估，而两项结果传达的信息不同。
基于 Google DeepMind 2026 年 10 月 模型卡数据制作的单角色和多角色一致性编辑图表。更高的 Elo 意味着更高的相对人工偏好；已展示 ± 范围，但未说明置信定义。Nano Banana 2.1 Thinking 与 No Thinking 在单角色一致性上的区间几乎重叠，这一点很重要。这不是 Google 原始图像。
在单角色一致性方面，Nano Banana 2.1 Thinking 达到 1028 ±14，No Thinking 达到 1021 ±14。其展示区间从 1014 至 1035，存在显著重叠。因此，将这 7 分差异描述为已确立的实际优势并不合理。两种 2.1 配置的得分均高于 Nano Banana 2 Thinking 的 981 ±10 和 Pro 的 991 ±9，但该基准并未显示失败是否涉及面部、服装、身体比例、配饰或风格漂移。
多角色结果的区分度更高。Thinking 得分为 1106 ±14，No Thinking 为 1068 ±14，Pro 为 1011 ±10，Nano Banana 2 Thinking 为 978 ±10。2.1 Thinking 与 No Thinking 的区间并不重叠。这表明，当场景要求系统追踪多个身份及其关系时，额外推理可能更有帮助。
即便如此，“支持最多四个角色”并不等同于“可靠地保留四个身份”。API 文档称，多图融合最多接受 14 张参考图，其中最多包含四个角色和十个物体。这些是输入上限，而非保真度保证。它们并未揭示当参考图在视觉上相似、相互矛盾、裁切、低分辨率或光照不均时，性能将如何变化。
生产评估应分别对每个主体评分。实用的失败标签包括面部漂移、服装转移、角色间属性泄漏、主体缺失、非预期重复、年龄变化和相对身高不一致。如果图像其余部分看起来很吸引人，一次总体偏好投票可能掩盖严重的身份缺陷。
对于单角色工作流，图表几乎没有证据表明每次请求都必须使用 Thinking。对于包含多个重复人物的场景，其更大的报告领先幅度使其更具潜力——但仍须接受成本、延迟和身份失败率的测量。
编辑结果倾向于 2.1，但不同任务的风险不同
编辑基准尤其重要，因为一个看似合理的输出如果改变了受保护区域、丢失产品细节或错误混合参考图，仍然可能无法使用。Google 报告了通用编辑、一致性、基于蒙版或笔迹的编辑、产品一致性、风格化和多参考图编辑的 Elo 分数。
根据 Google DeepMind 于 2026 年 10 月发布的 Nano Banana 2.1 模型卡经核实的数值结果制作的编辑图表。更高的 Elo 代表针对蒙版/笔迹、产品一致性和多参考图编辑的更强相对人工偏好；展示了已公布的 ± 范围，但未说明置信定义。这不是 Google 原始图像，也不衡量精确的编辑遵循程度。
基于蒙版或笔迹的编辑，是 2.1 具有共同优势、但尚未展示 Thinking 优势的最清晰例子。Thinking 得分为 1049 ±15，No Thinking 为 1042 ±16；其区间高度重叠。两者均高于 Nano Banana 2 Thinking 的 965 ±12 和 Pro 的 927 ±12。如果蒙版编辑在某个工作负载中占主导地位，测试时应同等关注 No Thinking，而不应将其视为天然较差的模式。
然而，Google 自身列出的限制对此结果作出了限定。模型可能仅部分遵循蒙版编辑指令、保留涂鸦或笔迹，或保留源主体的姿势。偏好 Elo 无法证明允许区域以外的像素保持不变。对于目录和受监管工作流，单独的保留度指标至关重要。
产品一致性显示，在 2.1 No Thinking 与旧模型之间的对比不那么明确。使用 Thinking 的得分为 1024 ±18，未使用时为 981 ±18，Nano Banana 2 Thinking 为 955 ±22，Pro 为 965 ±14。No Thinking 的区间与两种旧模型的区间均重叠。因此，已公布的图表支持 Thinking 是该评估中最强的配置，但并不支持声称每种 2.1 配置都能明显提升产品保真度。
多参考图编辑讲述了一个更有力的 2.1 故事：启用 Thinking 时为 1066 ±22，未启用时为 1041 ±20，而 Nano Banana 2 Thinking 为 988 ±13，Pro 为 989 ±12。不过，两个 2.1 区间存在重叠，因此不应夸大其中心分数之间 25 分的差距。
这些任务还需要不同的验收规则。创意合成图或许可以容忍轻微的几何变化，但如果 logo、端口、按钮、材质或包装数量发生变化，电商图片就可能不合格。因此，迁移决策应按编辑类别作出，而不是依据“编辑效果更好”这一笼统结论。
事实准确性前景可观，但仍是最薄弱的主张
Google 报告的事实性信息图评分为：Nano Banana 2.1 Thinking 为 0.521，不使用 Thinking 时为 0.328，Nano Banana Pro 为 0.265，Nano Banana 2 Thinking 为 0.179。
根据 Google DeepMind 的 Nano Banana 2.1 model card 中 2026 年 10 月 AutoRater 事实准确性数据制作的编辑图表。分数越高越好，但这一单边自动评测器分数并非人工准确率百分比。Google 未在此公布不确定性区间。这不是 Google 的原始图片。
该结果支持一个有限结论：在 Google 的自动评估下，Thinking 显著提升了 Nano Banana 2.1 的事实准确性评分，且最终得分高于列出的对比对象。这并不意味着 52.1% 的信息图在事实上正确。模型卡并未将该分数定义为百分比，也未公布其不确定性、提示词数量，或提供足以在此计算错误率的详细信息。
这一差异很重要，因为事实性图形存在多种失效面。一张图表可能文字表述正确，却绘制了错误的数值；它可能引用真实来源，却错配了日期。地图可能互换地区；时间线可能颠倒事件；标签可能被分配给错误对象。自动评分或许能捕捉其中部分错误，但该表未充分披露其覆盖范围，无法将其视为发布门槛。
搜索 grounding 可以提供更新的信息，但检索并不能保证视觉转录的忠实性。模型卡还描述了 Gemini 3.6 Flash 的知识截止日期为 2026 年 3 月，其中部分领域可能仅覆盖至 2025 年 1 月，而另一些领域则可获得更新信息。对于时效性图形，应明确提供或检索源材料，再根据渲染图像进行核查。
一种可辩护的工作流应将源事实与呈现方式分开。维护一份经过批准的事实表，其中包含数值、单位、日期、标签和引用；依据该简报生成视觉内容；然后将每项渲染出的主张与经批准的事实进行比对。这也是 为视觉内容维护可追溯的源事实与简报 有助于让审查立足于底层证据、而非图像表面自信感的地方。
该基准使 Thinking 成为显而易见的事实准确性候选方案，而非自主发布系统。对于医疗、金融、法律、历史、科学和时事图形，人工或确定性验证仍然必要。
每种分辨率的输出都更便宜，但请求未必如此
按照 Standard 付费 API 费率，Google 将 Nano Banana 2.1 的图像输出定价为每百万输出图像 token 30 美元。Nano Banana 2 为每百万 60 美元。这一标题看似普遍降低 50%，但 4K 时不同的 token 分配以及更高的非图像费率会使总成本变得复杂。
根据 Google 的 Gemini API pricing 于 2026 年 10 月进行的编辑计算。仅图像输出成本越低越好：Nano Banana 2.1 在 1K 和 2K 下低 50%，在 4K 下低 25%。成本不包括输入、文本或 Thinking 输出、grounding、重试、税费及可能的 Batch 折扣。这不是 Google 的原始图片。
透明的计算方式是费率乘以输出图像 token：
在 1K 下，1,120 个图像 token 对 Nano Banana 2.1 的成本为 0.0336 美元，对 Nano Banana 2 为 0.0672 美元。在 2K 下，1,680 个 token 的成本分别为 0.0504 美元和 0.1008 美元。在 4K 下，模型使用不同的 token 分配：3,780 × 每百万 30 美元，2.1 的成本为 0.1134 美元；而 2,520 × 每百万 60 美元，Nano Banana 2 的成本为 0.1512 美元。
因此，“半价”仅适用于 1K 和 2K 的图像输出 token。在 4K 下，Nano Banana 2.1 使用更多列出的图像 token，使仅输出部分的节省降至 25%。
其他组成部分可能朝相反方向变化。Nano Banana 2.1 的 Standard 输入定价为每百万文本、图像或视频 token 1.50 美元，而 Nano Banana 2 的文本或图像 token 定价为每百万 0.50 美元。2.1 的文本和 Thinking 输出为每百万 token 7.50 美元，Nano Banana 2 则为 3 美元。因此，完整估算必须纳入实际输入 token、文本输出、Thinking 消耗、适用情况下的 grounding 费用、重试、税费以及任何 Batch 折扣。
如果不假设提示词长度、参考图像 token 化方式、Thinking 使用情况、分辨率和重试率，就无法负责任地计算任何“典型请求”的总成本。一张更便宜的成功图像仍可能来自成本更高的请求，而更高的首轮验收率则可能抵消更高的推理费用。应衡量每个验收资产的成本，而不只是每张生成图像的价格。
迁移的建议评估计划
以下为建议的测试设计，并非本文已执行测试的描述。
从真实工作中抽取分层提示词集作为起点。将文生图、单角色、多角色、产品编辑、蒙版编辑、多参考图合成、文本密集型版式和事实性图形分开。保留提示词、参考文件、宽高比、分辨率和安全设置，以便每个模型都接收相同任务。
将最低、中等和高 Thinking 的 Nano Banana 2.1 与 Nano Banana 2 Thinking 进行比较。仅当 Pro 确实是部署选项时才纳入；由于基准图未说明 Pro 的设置，不应假设其计算或推理配置与其他模型一致。在内部测试中，为每个条件分配相同的重试预算，尽管 Google 未披露其基准是否如此执行。
在查看输出前定义验收规则：
对于文本渲染，转录每个必需词语，并记录缺失、替换、模糊或格式异常的文本。
对于身份一致性，分别评估每个角色，并记录属性泄漏、重复、遗漏以及面部或服装漂移。
对于产品工作，对比形状、logo、控件、数量、颜色、材质和包装文字等受保护特征。
对于蒙版编辑，同时衡量请求区域的成功率以及蒙版外的非预期改动。
对于空间提示词，测试左/右、前景/背景、包含关系、顺序和相对大小。
对于事实性图形，依据锁定的源事实表验证每个数字、单位、日期、标签、引用和视觉编码。
对于运营，记录超时、端到端延迟、重试次数、token 使用量、grounding 费用以及每个验收结果的成本。
对主观质量采用盲法人工评审，并在可实现精确性的地方使用确定性检查。报告不确定性并保留配对结果，因为同一提示词在各模型中的运行结果比无关平均值更具参考意义。如果失败会带来不同的业务后果，就不要把所有任务合并为一个分数。
除图像质量外，还应测试端点行为。依据当前 API 文档确认 131,072 输入和 32,768 输出限制，验证默认 1K 分辨率，并明确测试 2K 和 4K。仅在需要时测试 14 参考图输入，同时记住四角色和十对象限制并不承诺保留效果。由于不支持 function calling、代码执行和结构化输出，编排和验证必须在模型之外完成。
最后，在切换生产流量前运行影子阶段。记录拒绝原因，并比较每个验收资产的成本。这能揭示基准收益是否会转化为更少的修改，而不只是更好看的第一印象。
谁应迁移——谁应等待
当工作流依赖信息图设计、多角色场景、多参考图合成、基于蒙版的编辑或更低的图像输出费用时，Nano Banana 2.1 是更强的候选方案。对于事实性图形和复杂多主体任务，Thinking 应获得优先考虑。对于较简单的生成和编辑任务，尤其是在其已发布区间与 Thinking 重叠或推理成本重要的场景下，未启用 Thinking 仍值得测试。
当精确的小文本、长篇文字、严格身份保留、受保护区域编辑、空间精度或经过验证的事实不可妥协，且组织缺少外部验证步骤时，应暂缓迁移。现有自动化依赖不受支持的 function calling、代码执行或结构化输出时，同样如此。
应保守处理文档差异：遵循所选端点的当前限制，并衡量观察到的行为，而不是从更广泛的模型架构中推断容量。同样，当前的 deprecations table 将 Gemini 3.1 Flash Image 列为已弃用，但未宣布关闭日期。没有经过验证的 10 月 29 日退役截止日期来迫使仓促切换。
因此，决策是具体的。如果 Nano Banana 2.1 达到任务特定的保真度门槛、降低每张验收图像的成本，并满足实测的延迟和超时要求，就应迁移。仅在 Thinking 带来的验收率提升足以证明其额外输出成本合理时才使用它。在 2.1 通过影子测试之前，保留 Nano Banana 2 或其他后备方案。对于事实性、身份敏感或需要精确编辑的资产，无论哪种模型在基准中领先，都应要求验证。
