Nano Banana 2.1 和 Nano Banana 2 对比:同一张海报,连续编辑两次

Nano Banana 2.1 比 2 更值得换吗?用相同提示词生成海报、改标题和改颜色,展示六张真实结果、耗时与返回用量,说明小样本能支持哪些迁移判断。

浅色卡纸上的指南针黑色线稿、几何点缀和 Nano Banana 2.1 标题。

测试日期:2026 年 10 月 13 日。 我们通过 Ofox 的原生 Gemini API 路由,分别向 Nano Banana 2.1 和 Nano Banana 2 发送了相同的三个提示词。每个模型都生成了一张活动海报、修改了标题,然后更改了碗的颜色。也就是说,每个模型各完成一条三步链路,并非三次独立试验,也不是对任一模型整体质量的基准测试。

本文由 Ofox 发布,测试所用的网关也由 Ofox 运营。本文初稿借助 AI 完成;我们使用工具核验了 API 请求和输出文件,并在发布前另行进行了 AI 审核。下方六张生成图片——而非公开模型页面上的界面——是本文视觉对比的依据。你可以在可下载的复现资料包中查看文件和请求材料。

六张输出图

步骤Nano Banana 2.1Nano Banana 2
生成海报Nano Banana 2.1 海报,文字为 ORCHARD MARKET 和 SATURDAY 10 AM,蓝色碗中有三个苹果Nano Banana 2 海报,文字为 ORCHARD MARKET 和 SATURDAY 10 AM,蓝色碗中有三个苹果
修改标题Nano Banana 2.1 海报,标题已改为 ORCHARD FAIRNano Banana 2 海报,标题已改为 ORCHARD FAIR
修改碗的颜色Nano Banana 2.1 海报,碗已改为深绿色Nano Banana 2 海报,碗已改为深绿色

在这次测试中,两个模型都完成了要求的语义层面的编辑流程。它们生成的第一张海报都正确拼写了 ORCHARD MARKET 和 SATURDAY 10 AM,并画出了蓝色碗里的三个红苹果。两者修改标题后都显示 ORCHARD FAIR,并保留了较小字号的那行文字、苹果和蓝色碗。第三轮的输出都把碗改成了深绿色,同时保留了指定文字和版面。

两者也有一个共同的遗漏:尽管第一条提示词要求“无边框”(“no border”),两个模型都把设计呈现成了带外侧留白或阴影的纸张。如果“无边框”指图案必须铺到图片边缘,那么两张首轮输出都不符合这一要求。这些结果可用于构思海报,但不能证明任何一个模型都能精确遵循所有版式指令。

我们发送了什么,以及这组对比能说明什么

我们按顺序发送了以下提示词:

  1. Create a square minimalist event poster on warm cream paper. Large exact headline: ORCHARD MARKET. Smaller exact line: SATURDAY 10 AM. Draw three red apples in a blue ceramic bowl below the text. No other text, no logos, no border.
  2. Change only the headline from ORCHARD MARKET to ORCHARD FAIR. Keep SATURDAY 10 AM exactly unchanged. Preserve the three red apples, blue bowl, cream background, composition and all other pixels as closely as possible.
  3. Now change only the bowl from blue to dark green. Preserve ORCHARD FAIR, SATURDAY 10 AM, the three red apples and the layout.

对每个模型来说,第二轮都包含该模型自己生成的海报;第三轮则包含该模型此前的对话和标题编辑结果。我们将上一轮完整的 candidates[0].content 作为 assistant 回合发回,而不是根据显示用的 PNG 重新拼接内容。这一点很重要,因为返回的内容可能包含继续对话所需的部分。

本次测试使用的 Ofox 路由为 POST https://api.ofox.io/gemini/v1beta/models/{model}:generateContent,通过 x-goog-api-key 进行认证。模型 ID 分别是 google/gemini-nano-banana-2.1 和较早版本的 google/gemini-3.1-flash-image。两条链路都请求了 responseModalities: ["TEXT", "IMAGE"]、1:1 宽高比和 1K 图像尺寸。我们没有设置 seed,也没有明确指定 thinking level。因此,模型可能使用了不同的默认值;提示词和请求的图像设置相同,并不意味着它们的内部配置完全一致。

六次调用均返回 HTTP 200、STOP 结束原因,以及一张 1024 × 1024 的 PNG。我们没有进行重复测试,也没有测试其他语言、其他宽高比或生产环境工作负载。上文的视觉评估仅针对这六个文件。尤其需要注意,“尽可能保留其他所有像素”是一条指令,并不保证模型能进行像素级编辑或提供可编辑图层。即便标题编辑中看起来稳定的下半部分,也包含许多 RGB 像素变化。逐像素统计不一致数量时,细微纹理和颜色差异也会计为变化;它不是感知层面的损伤评分。若需要更严格地控制产品区域,可参阅关于使用遮罩保留产品区域和使用单张或多张场景参考图的单独讨论。

耗时与返回的用量:观察结果,不代表速度排名

以下是六次请求的耗时和返回的用量字段。“未报告”表示响应中缺少该字段,不表示思考 token 数量为零,也不表示没有相关费用。

模型与轮次耗时(秒)输入 token报告的文本输出 token图像输出 token思考 token
2.1 — 海报15.4654801,120639
2.1 — 标题编辑17.481,167未报告1,120358
2.1 — 碗的颜色编辑18.442,272未报告1,120未报告
2 — 海报10.0854未报告1,120未报告
2 — 标题编辑13.991,167未报告1,120未报告
2 — 碗的颜色编辑13.062,272未报告1,120未报告

第一条 2.1 响应报告了 80 个 TEXT 输出 token,但其中没有可见的文本部分。表格列出的是元数据类别,而不是可见文字的数量。

在这三组配对轮次中,Nano Banana 2 的返回时间都更短。但六次串行请求既没有重复测试,也没有在受控负载条件下进行,因此不能据此认定它通常更快。同样,这两款模型在本次测试中都完成了主要的文字和编辑任务,也不能证明它们在不同提示词下的可靠性相同。输入 token 数量逐轮增加,是 API 对多轮请求的报告结果;单凭这一点,无法准确说明提交的历史记录是如何计费的。下面的迁移步骤会把这些范围有限的观察结果转化为你可以针对自身工作负载开展的检查。

复现这两条三步链路

资料包包含测试材料和输出图片。若要重新发起请求,请安装 requests,设置 Ofox API key,然后运行以下脚本。脚本使用上文的原始提示词,保存每一个返回的内嵌图片部分,并保留每次响应中的完整候选内容供下一轮使用。重新生成的结果不一定与已发布的六张 PNG 完全一致。

python -m pip install requests
export OFOX_API_KEY="your-key"
python compare_posters.py
# compare_posters.py
import base64
import json
import os
import time
from pathlib import Path

import requests

KEY = os.environ["OFOX_API_KEY"]
OUT = Path("poster-comparison")
OUT.mkdir(exist_ok=True)

PROMPTS = [
    "Create a square minimalist event poster on warm cream paper. Large exact headline: ORCHARD MARKET. Smaller exact line: SATURDAY 10 AM. Draw three red apples in a blue ceramic bowl below the text. No other text, no logos, no border.",
    "Change only the headline from ORCHARD MARKET to ORCHARD FAIR. Keep SATURDAY 10 AM exactly unchanged. Preserve the three red apples, blue bowl, cream background, composition and all other pixels as closely as possible.",
    "Now change only the bowl from blue to dark green. Preserve ORCHARD FAIR, SATURDAY 10 AM, the three red apples and the layout.",
]

MODELS = {
    "21": "google/gemini-nano-banana-2.1",
    "2": "google/gemini-3.1-flash-image",
}
STAGES = ("poster", "edit", "turn3")

for label, model in MODELS.items():
    history = []
    url = f"https://api.ofox.io/gemini/v1beta/models/{model}:generateContent"

    for stage, prompt in zip(STAGES, PROMPTS):
        user_turn = {"role": "user", "parts": [{"text": prompt}]}
        payload = {
            "contents": history + [user_turn],
            "generationConfig": {
                "responseModalities": ["TEXT", "IMAGE"],
                "imageConfig": {"aspectRatio": "1:1", "imageSize": "1K"},
            },
        }

        started = time.monotonic()
        response = requests.post(
            url,
            headers={"x-goog-api-key": KEY},
            json=payload,
            timeout=180,
        )
        elapsed = time.monotonic() - started
        response.raise_for_status()
        body = response.json()

        candidates = body.get("candidates") or []
        if not candidates:
            raise RuntimeError(f"{label}/{stage}: no candidate: {body}")
        candidate = candidates[0]
        if candidate.get("finishReason") != "STOP":
            raise RuntimeError(
                f"{label}/{stage}: finishReason={candidate.get('finishReason')}"
            )

        content = candidate["content"]  # Keep all returned parts intact.
        saved = []
        for index, part in enumerate(content.get("parts", [])):
            inline = part.get("inlineData")
            if not inline:
                continue
            mime = inline.get("mimeType", "")
            if not mime.startswith("image/"):
                continue
            extension = ".png" if mime == "image/png" else ".img"
            path = OUT / f"{stage}-{label}-{index}{extension}"
            path.write_bytes(base64.b64decode(inline["data"]))
            saved.append(str(path))

        if not saved:
            raise RuntimeError(f"{label}/{stage}: STOP but no inline image")
        print(json.dumps({
            "model": model, "stage": stage, "seconds": round(elapsed, 2),
            "images": saved, "usageMetadata": body.get("usageMetadata"),
        }))

        history += [user_turn, content]

代码会将文本部分按文本处理,而不是当作图片。即使 HTTP 响应成功,如果没有候选内容、结束原因不是 STOP,或没有内嵌图片,代码也会明确报错。这些情况值得在将图像生成接入工作流之前妥善处理。Ofox 的公开 2.1 模型页面列出了模型和协议,但页面内嵌的 Playground 需要登录;模型页面的截图只能证明公开界面的存在,不能证明这些图片是在那里生成的。我们没有进行经过身份验证的 Agent 模型选择测试,因此本文不会声称 Agent 会自动选择 2.1。有关响应处理失败的更多信息,请参阅无图片错误指南和 Google 的 API 故障排查文档。

这些 token 能说明什么,不能说明什么

图像 token、输入 token、报告的文本输出和报告的思考 token 是不同的用量组成部分。在 Ofox 于 2026 年 10 月 13 日留存的运行时目录快照中,2.1 列出的费率为:每百万输入 token 1.50 美元、每百万文本输出 token 7.50 美元、每百万图像输出 token 30 美元。较早模型对应的快照列出的费率为:每百万分别 0.50 美元、3 美元和 60 美元。2.1 的快照还列出了每次搜索请求 0.014 美元;本次海报测试没有使用搜索。提供方价格字段为空,并不能确认提供方有折扣。Ofox 的目录端点是动态的,并非网站 Git 仓库中的静态价格表;基于快照计算的金额也不是经核实的账单。制定预算前,请查看最新的定价指南和你的账单记录。

以第一条 2.1 海报请求为例,按上述快照费率计算,图像部分为 1,120 × $30 / 1,000,000 = $0.0336,输入部分为 54 × $1.50 / 1,000,000 = $0.000081,报告的文本输出部分为 80 × $7.50 / 1,000,000 = $0.0006。如果这 639 个报告的思考 token 按相同的文本输出费率收费,则会增加估算金额 $0.0047925,示例合计为 $0.0390735。这一条件性计算不是账单。不要把较早模型缺失的思考字段直接当成零费用。

按快照中的图像费率,仅生成 100 张 1K 的 2.1 图片,就会产生 $3.36 的图像部分费用;若要获得 100 张验收通过的图片,共生成 125 张——即假设验收率为 80%——则这一图像部分费用为 $4.20。输入、文本、可能计费的思考过程、重试和其他适用费用都不包含在这些仅计算图像部分的数字中。按较早模型列出的图像费率,1,120 token 的输出对应 $0.0672 的图像部分费用;但这些数字无法证明切换模型会降低某个特定工作负载的总账单或每张验收通过设计的成本。

Google 的 Gemini 定价页面也列出了 2.1 的文本加思考费率和图像费率,并说明 1K 图像对应 1,120 个图像 token。Google 发布的 4K 数字在不同来源中并不完全一致:图像生成定价表列出 2,520 个 token,而 Vertex 文档列出 3,780 个。本次测试没有请求 4K;不应把任一数字当作本次测试中 Ofox 4K 请求的精确账单金额。

现有工作流要不要切换模型 ID?

只有当你已经验证过这个模型的行为或可用能力确实能解决问题时,才考虑切换——不要因为这六张图片就认定它在所有情况下都更胜一筹。Google 的文档介绍了 Nano Banana 2.1 的模型能力和图像生成工作流,其中包括更高分辨率选项和参考图工作流。文档中记载某项能力,并不等于已验证该选项能通过此 Ofox 路由正常使用:本次对比只用了 1K 图像,没有外部参考图,提示词也只有英文。我们也没有对比 Pro 或 Lite;文档对它们的定位可以作为针对不同需求进行评估的理由,但本次测试并未测出它们更优秀。

谨慎升级可以分成四步:

  1. 固定模型 ID。 在测试配置中将 google/gemini-3.1-flash-image 改为 google/gemini-nano-banana-2.1,不要悄悄更改所有生产请求。
  2. 明确记录配置和对话历史。 记录请求的分辨率、宽高比、模态、提示词,以及轮次间传递的完整 assistant 内容。不要把未经验证的 seed、temperature 或 top-p 调参方案,当成能让这些输出可复现的做法来发布。
  3. 用真实交付要求检查输出限制。 用你自己的材料测试文字准确性、不需要的留白、必要时的参考图处理、缺少图片的响应、验收率、延迟分布和总计费量。针对这类任务的限制,可参阅聚焦于海报编辑的指南;集成方式可参阅 API 指南。
  4. 保留回滚路径。 在新模型通过检查前,保留旧 ID 和路由配置。本次测试无法证明较早的模型 ID 已经停用。

最后,一张好看的生成海报并不意味着已经获得权利许可,也不等于符合安全数据政策。用于商业用途或敏感数据处理前,请核查所提供输入的相关权利以及适用的 Gemini API 条款。阅读 SynthID 文档时,不应将其理解为对可见水印、独占所有权或不侵权的承诺。本次测试能够支持的结论更有限:在一条提示词相同、包含三轮的英文海报链路中,两个模型都完成了指定的文字和碗颜色编辑,也都没有遵守无边框要求。