Gemini 3.1 Flash Image 按分辨率定价（2026）：1K、2K、4K 怎么选，Batch 能省多少，4K 何时值得买

很多开发者口中的 Nano Banana 2，现在的官方名称是 Gemini 3.1 Flash Image(gemini-3.1-flash-image-preview)。真正值得关心的变化，不是名字，而是分辨率价格终于写清楚了。Google 在 2026 年 2 月 26 日发布了 Nano Banana 2 官方介绍。我在 2026 年 4 月 4 日复核 Gemini API 官方定价页 时，页面已经明确列出 1K 为 $0.067、2K 为 $0.101、4K 为 $0.151，对应的 Batch 价格分别是 $0.034、$0.050、$0.076。

真正的问题也随之变了。读者不再是在问“这到底是什么模型”，而是在问：生产环境默认该出 1K、2K 还是 4K？ 这个问题如果不先定下来，后面的账单、素材复用和产品默认配置都会跑偏。结论先说：大多数场景默认用 1K；确实需要裁切空间、高分屏素材或更耐用源图时升到 2K；4K 不该做成默认，而应该是有明确交付理由才开启的例外路径。

先看结论

还有三个事实必须先记住：

• gemini-3.1-flash-image-preview 没有免费层。
• 官方 图像生成文档 明确写了：如果你不显式设置，默认就是 1K。
• 参数值必须写成 1K、2K、4K 这种大写 K；1k、2k 会被拒绝。

Gemini 3.1 Flash Image 的官方分辨率价格到底是多少

这次 Google 的定价页有一个很实用的变化：它不只给出“每百万 token 多少钱”，还把不同输出尺寸折算成了开发者真正关心的 单张图价格。对 Gemini 3.1 Flash Image 来说，标准请求的图像输出价格是 每 100 万 output tokens 收费 $60，对应到不同尺寸后，得到下面这张真正能拿来做预算的表：

这里最值得读懂的不是具体数字本身，而是数字之间的关系。1K 到 2K 的涨幅是真实存在的，但还没有大到要你改掉整个产品路线。它更像是一个“我确实知道后面会反复裁切、复用、重排版”的升级选择。1K 到 4K 就不是这种性质了。4K 大约是 1K 的 2.25 倍成本。这不是细节优化，而是默认策略层面的决策。

这也是为什么很多早期的 “Nano Banana 2 pricing” 文章很快过时。因为它们写的时候，Google 还没把尺寸价格清清楚楚挂出来，很多页面只能用“差不多五美分”“大概十五美分”这种社区估值。现在官方价格合同已经稳定下来，再继续沿用旧估算，只会让团队的预算表和实际账单脱节。

账单到底是怎么拉开的

这类文章最容易让人误判的一点，是把账单变化想成“提示词写长了所以更贵”。对 Gemini 3.1 Flash Image 来说，大多数情况下真正把账单拉开的不是普通文本输入，而是 图像输出尺寸。

官方标准价里，文本和图像输入是 每 100 万 tokens 收费 $0.50，Batch 输入则是 $0.25。这个量级在常规图像生成请求里通常都很小。也就是说，如果你的提示词不是极端冗长，真正决定账单的是你选了 1K、2K 还是 4K，而不是提示词多写了十几个词。

所以做预算时，正确顺序应该反过来：先用尺寸梯度算主要成本，再去优化提示词输入。 后者当然也有价值，但它不是这里的主因。

还有一个边界条件要注意：如果你把 Google Search grounding 打开，那么基础图像价格就不再是全部账单。定价页写得很清楚：一次用户请求可能会触发一次或多次搜索查询，超过免费月额度后会按查询单独收费。换句话说，如果你做的是带 grounding 的图像生成，就不能只盯着单图价格；但如果你做的是常规的提示词出图，决定成本的核心仍然是分辨率。

该默认选 1K、2K 还是 4K？

对大多数产品来说，默认值应该是 1K。不是因为 1K 在所有场景里都“最好”，而是因为它通常是能撑住真实交付路径的最小尺寸。如果你的图片主要出现在网页、产品卡片、App 页面、博客头图或者常规社媒渠道里，1K 往往已经足够，同时不会把成本结构推高到没必要的程度。

当你已经知道图片会被多次裁切、重复复用、重新排版，或者需要作为更耐用的源图继续流转时，再把默认档提到 2K。这才是 2K 最合理的定位：它不是“豪华档”，而是一个实用升级档。它买来的不是面子，而是后续素材管理的灵活性。

4K 则应该被当成例外路径，而不是默认配置。只有当你明确知道这张图要承受更大尺寸输出、印刷附近使用、母版级复用，或者要在多个高要求场景之间反复流转时，4K 才值得。说得更直接一点：如果你说不出这张图为什么必须是 4K，那它大概率就不该是 4K。

至于 512，它当然是正式支持的，而且只在 Gemini 3.1 Flash Image 这里多了这档更小尺寸。但它更适合草稿、非常小的展示位或内部流程，不适合拿来当多数产品的常规默认值。

月度预算怎么从单张价格变成真实账单

单张价格看起来都不算可怕，但一旦进入月度规模，差距就会变得非常具体：

这张表最有价值的地方，不是让你做数学，而是逼你承认一个事实：默认用 4K 和默认用 1K，本质上是两套预算策略。 当月量来到 1,000 张时，标准价下 1K 和 4K 的差距已经是 $84/月。到 10,000 张时，这个差距变成 $840/月。如果图像生成只是你整个产品里多个付费模型调用中的一个环节，这种差距足够影响单位经济。

Batch 会改变答案，但不会推翻默认规则。对夜间批处理、计划任务、批量营销素材这类不追求实时性的流程，Batch 的确是非常有价值的省钱杠杆。它能把 4K 的单张价格压到 $0.076。但这并不意味着你应该把所有默认尺寸都调成 4K。Batch 只是让高分辨率没那么贵，不是让高分辨率自动变成合理默认值。

比较稳的做法通常是这样：先定一个实时默认档，再定一个高分辨率例外路径，把明显不赶时间的任务丢给 Batch。 这样你的账单是可预测的，调用方也知道什么时候应该升级尺寸，而不是大家各自凭感觉选。

什么时候该留在 Flash，什么时候该换模型

有时候真正的问题不是“1K 还是 4K”，而是 Gemini 3.1 Flash Image 这条模型路线本身对不对。

如果你的真实目标是 拿到最便宜的官方 Gemini 1K 图像路径，那更老的 Gemini 2.5 Flash Image 依然有意义。Google pricing 页给它的价格是标准 $0.039/张、Batch $0.0195/张。在 1K 这个点上，它确实比 Gemini 3.1 Flash Image 更便宜。代价也很直接：你失去了 512 到 4K 这条更完整的尺寸梯度，继续停留在旧的 1K-only 合同上。

如果你的目标是 用 Google 官方单一路线覆盖从草稿尺寸到 4K 成品的多个档位，那 Gemini 3.1 Flash Image 就是当前默认答案。它的价值不在于“比所有模型都便宜”，而在于它把原来分散的选择收束成了一条更清楚的路线：需要很小尺寸时用 512，正常默认用 1K，需要更耐用的源素材时用 2K，真的要扛住高要求交付时才上 4K。

如果你的真实需求是 更高质量、更高成本的生成流程，或者更重的参考图使用场景，那更好的答案可能是 Gemini 3 Pro Image。Google 官方价格是 1K-2K 为 $0.134/张，4K 为 $0.24/张，Batch 再减半。这和 Flash 是完全不同的成本结构，只有在你的流程真的需要更高价格档时才合理。如果你在评估这条路线，可以继续看我们的 Nano Banana Pro API 指南。

所以更实用的路由规则其实很简单：

• 当你最看重的是 最低 1K 成本，选 Gemini 2.5 Flash Image。
• 当你最看重的是 当前官方、覆盖多尺寸、默认最好用的一条 Google 图像路线，选 Gemini 3.1 Flash Image。
• 当你最看重的是 更高质量和更重的高成本流程，再去看 Gemini 3 Pro Image。

不显式设置 imageSize，你的预算判断就不算数

这类文章还有一个很容易掉进去的坑：明明在预算表里按 2K 算，实际请求却没显式指定尺寸，结果线上一直跑默认 1K，或者反过来让团队误以为自己在“控制成本”。Google 的 图像生成文档 写得很清楚：Gemini 3 系列图像模型默认输出 1K，有效取值是 512、1K、2K、4K。

所以如果你真的想让成本判断落地，参数必须写出来，而且大小写要对：

javascript
import { GoogleGenAI, Modality } from "@google/genai";

const ai = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY });

const response = await ai.models.generateContent({
  model: "gemini-3.1-flash-image-preview",
  contents: "Create a clean ecommerce hero image of a ceramic mug on a stone surface.",
  config: {
    responseModalities: [Modality.TEXT, Modality.IMAGE],
    imageConfig: {
      imageSize: "2K",
      aspectRatio: "1:1",
    },
  },
});

这里有两个细节最容易出错：

• 1K、2K、4K 必须是大写 K。
• 512 就写 512，不要加 K。

这看起来像小问题，但对生产环境不是小问题。如果团队的预算是按 2K 建模的，那你的 SDK 封装层、调用约定和实际请求也应该明确地要求 2K。否则文章里说的价格规则和线上真正发生的事情根本对不上。

最实用的默认结论

截至 2026 年 4 月 4 日，Gemini 3.1 Flash Image 的官方答案已经足够清楚，不需要再靠社区估值猜。它的价格是 1K $0.067、2K $0.101、4K $0.151，Batch 后分别是 $0.034、$0.050、$0.076。模型支持 512、1K、2K、4K，默认是 1K，而且 没有免费层。

因此生产环境里最稳的策略也很简单：默认用 1K，有明确复用或裁切理由时升到 2K，只有当交付要求真的足够高时才把 4K 作为例外路径打开。 如果你觉得这个结论太保守，可以再回去看一次月度预算表。多数时候，它不是保守，而是终于让价格合同和真实交付需求对齐了。