Gemini Flash API 价格对比：哪个 Flash 模型真正最省钱？

先说结论：如果只看当前文本 Token 单价，gemini-2.5-flash-lite 最低；如果新项目更在意新一代稳定低成本路线，先测 gemini-3.1-flash-lite。这两种“最省”不是同一个答案，最终还要看输入/输出比例和任务是否一次通过。

按 2026 年 7 月 14 日核对的 Google 官方价格，2.5 Flash-Lite 的 Standard 价格为输入 $0.10、输出 $0.40；3.1 Flash-Lite 为输入 $0.25、输出 $1.50，单位均为每 100 万 Token。同样处理 100 万输入和 25 万输出时，前者是 $0.20，后者是 $0.625。

先用符合功能要求的稳定 Lite 模型跑一组真实任务。只有当失败、重试、人工修复或漏掉要求造成的成本超过模型价差时，才升级到 Flash；只有任务能等待或重复上下文足够多时，才分别计算 Batch、Flex 或缓存能否省钱。

文本 API 成本需要和 Gemini API 免费额度、更宽的 Gemini 3 Pro 与 Flash 能力选择，以及 Gemini 3.1 Flash-Lite Image 图像价格 分开判断。名字相近，不代表计费对象、输出类型或读者任务相同。

先算每次调用和每月费用

不要只抄输入价格。Gemini 文本调用至少有两只独立的计价表：

月成本 = 月输入 Token × 输入单价 / 1,000,000 + 月输出 Token × 输出单价 / 1,000,000

输入侧不只是用户最后一句话。系统提示、对话历史、检索到的文档、工具结果再次送回模型、图片或其他多模态上下文，以及失败后的重试，都可能增加输入量。输出侧要统计完整响应；如果官方价格行说明输出包含 thinking tokens，就不能只按最终可见文字估算。

开头的 100 万输入加 25 万输出，是为了让五个模型在同一工作量上比较。它只计算列表中的 Token 费用，不包含 Grounding、付费工具、显式缓存存储、税费、失败重试和第三方渠道加价。生产预算最好把这些项目单列，否则一个看似精确的“模型成本”其实把不少费用藏掉了。

再看一个更接近日常服务的例子：每月 100,000 次调用，每次平均 800 输入、200 输出。月总量是 8,000 万输入 Token 和 2,000 万输出 Token。

2.5 Flash-Lite 的 $16 来自 80 × $0.10 + 20 × $0.40；3.1 Flash-Lite 的 $50 来自 80 × $0.25 + 20 × $1.50。这里的 80 和 20 都以“百万 Token”为单位。单次成本只是月成本除以 100,000，并没有引入新的价格假设。

上线前不要只取几次短提示的平均值。至少记录输入、输出的中位数和高分位数，把异常长对话、检索上下文、结构化输出失败和重试分开。一个客服助手的平均输出可能很短，但少数长解释仍会主导成本；一个抽取任务平均很稳，但 JSON 修复重试也可能把输入再次发送一遍。

输出量尤其容易被低估。核对日的 3.1 Flash-Lite 和 3.5 Flash，输出单价都是输入单价的 6 倍。限制最大输出 Token 可以控费，但上限过紧会造成截断、缺字段和重试。合理目标不是“让回答尽量短”，而是“用能稳定完成任务的最短输出”。

预算表还应给流量增长留余量。可以分别做当前月、两倍调用量和高分位输出上升三种情景，不要把一次试跑的最低值直接当生产上限。这样才能看出，真正需要优化的是模型价格、上下文长度、输出设计、重试率，还是执行方式。

2.5 Flash-Lite、3.1 Flash-Lite 和 Flash 怎么选

先把已经失效的选项删掉：Gemini 2.0 Flash 和 Gemini 2.0 Flash-Lite 已在 2026 年 6 月 1 日停用。继续围绕旧 ID 讨论“便宜不便宜”没有执行意义。Google 停用时间表 给出了迁移方向，当前模型目录 才负责可用 ID 与生命周期状态。

只追求当前最低 Token 单价，先测 Gemini 2.5 Flash-Lite。 分类、抽取、路由、改写、短摘要和结构化转换通常适合从 Lite 开始，但“通常适合”不是质量保证。语言、长上下文、严格 schema、复杂判断和安全边界都要用自己的任务验证。

新项目希望从更新的稳定低成本模型起步，先测 Gemini 3.1 Flash-Lite。 Google 的 3.1 Flash-Lite 模型页 在核对日列出 1,048,576 Token 输入上限和 65,536 Token 输出上限，可接收多模态输入、返回文本。它不是负责图片生成的 Flash-Lite Image，这一差别在做产品选型时比名字更重要。

Lite 验收不通过，再测 Gemini 2.5 Flash。 它是稳定的 Flash 升级选择，输入单价与 3.1 Flash-Lite 接近，但输出价格更高。选择依据应当是任务通过率、重试和修复下降，而不是“Flash 听起来更强”。

Gemini 3 Flash Preview 只放在预览实验通道。 预览模型的生命周期、可用性和行为变化风险更高。只有团队接受这一风险、能回退到稳定模型，并且确实需要验证新一代能力时，才把它加入测试；不要让它悄悄成为生产默认。

Gemini 3.5 Flash 是更高价的能力升级通道。 在 100,000 次调用示例中，3.5 Flash 的 Standard Token 月成本是 $300，远高于两个 Lite 选项。它是否值得，必须由更高任务通过率、更少人工返工或明确能力需求来解释；价格表本身证明不了质量收益。

可以把初选压缩成三句话：极度敏感于 Token 单价，先测 2.5 Flash-Lite；新项目想采用更新的稳定低成本路线，先测 3.1 Flash-Lite；两者都过不了预先定义的任务门槛，再加入稳定 Flash 做对照。不要一开始就把最贵模型、预览模型和多个折扣通道混在一起，否则很难知道改进来自哪里。

免费额度、付费层级与单价不是一回事

“有 Free Tier 价格行”不等于“每个项目都有同一个免费额度”。可用请求量会受模型、项目、账户层级和区域影响，而且可能变化。Google 的 速率限制说明 使用 RPM、TPM、RPD 等维度，并把限制施加在项目而不是单个 API Key 上。精确数字应在 Google AI Studio 的当前项目中查看。

这也解释了为什么给同一个项目再建几个 Key 通常不会把项目配额成倍增加。生产环境应明确记录流量属于哪个项目，同时监控请求数和 Token 数。遇到 429 时，先判断是哪个限制维度、是否需要退避或升级层级，不要先轮换 Key。

单价、免费资格和付费激活是三个问题。免费层可以用来验证请求形状和早期任务，但是否能承载持续流量取决于实时配额。付费层则需要预算上限、账单所有者、异常用量告警和停机策略，不能只把“绑定支付”理解成更多请求。

Google 的 Gemini API 计费说明 在核对日说明了预付、后付、支出上限和积分有效期等规则。部分新用户可能需要至少预付 $10；预付积分 12 个月后到期，通常不可退款。这些条件会变化，充值前应在实际计费账户中再确认，而不是照搬旧截图。

失败请求也要分“是否收费”和“是否占容量”。Google 当前说明中，400 与 500 类失败请求不收 Token 费用，但仍可能计入配额。重试风暴因此可能没有明显账单增长，却把项目的请求或 Token 容量耗尽。监控面板需要同时看花了多少钱和消耗了多少可用容量。

数据使用又是独立边界。当前 Gemini API 附加条款 对未付费服务与付费服务给出不同处理：未付费服务中的内容可能用于改进 Google 产品，并可能被审核，因此不应提交敏感、机密或个人数据；付费服务适用不同的数据使用说明。真实客户数据上线前，还应核对组织政策、数据处理协议和项目设置。

如果主要问题是“我的项目到底能免费调用多少、何时必须付费”，应转到 Gemini API 免费额度说明。把动态项目配额硬塞进模型价格表，往往会同时造成价格页过时和免费额度页重复。

什么时候用 Standard、Batch、Flex 或缓存

结果必须在用户请求链路里立即返回时，先用 Standard。它最适合建立可解释的延迟、错误、Token 和任务通过率基线。没有这条基线，就很难判断后续成本下降来自 Batch、Flex、缓存，还是模型与提示本身变化。

Google 的 Batch API 文档 把目标完成时间设为 24 小时内，适合夜间分类、离线补全、评测和数据回填。需要在页面内即时回答、同步审核或立刻触发下游工作的请求，不应仅为半价而改成 Batch。

Flex 也不是“打开就半价”的通用开关。先检查准确模型、区域与当前支持状态，再确认业务能接受相应执行特性。若用户体验依赖稳定的同步链路，就保持 Standard 基线，只迁移真正允许弹性的流量。

上下文缓存适合重复发送长前缀，例如同一份手册、代码库快照、政策语料或多模态背景。Google 的 缓存概览 区分隐式与显式缓存，显式缓存指南 说明 TTL 与存储。一次缓存命中并不会让整次请求免费：仍有缓存读取、存储时长、未缓存输入和输出费用。

计算缓存前，先估算“前缀大小 × 复用次数 × TTL”。如果前缀只复用几次，或每次都发生大幅变化，缓存管理和存储可能不值。如果几千次请求重复同一大段上下文，缓存才有机会显著降低输入成本。不要把某个缓存读取折扣直接写成“总账单节省百分比”。

最容易审计的顺序是：先测 Standard；再把可等待任务移到支持的 Batch 或 Flex；再对高复用前缀单独算缓存；最后才根据任务失败决定是否升级模型。一次改四件事，账单虽然可能下降，却很难知道哪一项带来收益，也很难定位质量或延迟问题。

真正该比较的是“合格结果成本”

便宜模型只要频繁失败，就可能不再便宜。Token 费用可以直接从日志和价格表计算；失败成本要由业务定义，可能包括再次调用、回退到另一个模型、修复 JSON、人工审核、客服处理，甚至撤销错误下游动作。

先准备一组代表性任务，再选择生产默认。任务集应包含普通请求、长或脏输入、多语言、严格 JSON/schema、边界安全场景和真实最长输出。运行之前就写清通过条件，避免一两个惊艳答案掩盖稳定性问题。

回到 100,000 次调用示例，2.5 Flash-Lite 相比 3.1 Flash-Lite 每月少 $34。如果低价模型额外造成 500 次人工修复，每次只花 1 分钟，Token 节省很可能已经不重要。反过来，如果两者在确定性抽取任务上通过率相同，支付更高价格也没有可测价值。

可以为升级设一条明确规则：Lite 达到预定通过率，并且重试、修复和延迟在预算内，就继续使用；只有稳定 Flash 降低的失败总成本超过新增 API 费用时，才升级。模型更新、提示变化、schema 变化或流量结构大幅改变后，重新运行同一任务集。

不要把一次 A/B 结果当永久结论。模型、价格和业务数据都会变化，代表性任务也会老化。保留任务样本、判定标准、模型 ID、运行日期和 Token 统计，才能在下一次价格或模型更新时复算，而不是从头争论“哪个模型更好”。

旧版 Gemini 2.0 预算必须迁移

2026 年 6 月 1 日停用后，Gemini 2.0 的价格已经不能代表一个可运行的生产选项。旧表格仍可能显示它很便宜，但请求指向的是退休 ID。迁移时要同时改请求路径和预算假设。

1. 在代码、环境变量、代理配置、评测夹具、回退列表和监控面板中搜索 Gemini 2.0 Flash 与 Flash-Lite ID。
2. 把原 Flash-Lite 流量映射到当前 3.1 Flash-Lite 候选，把原 Flash 流量映射到当前稳定 Flash 候选，并在模型目录核对精确 ID。
3. 重新确认输入和输出模态。gemini-3.1-flash-lite 返回文本；图像生成必须使用独立图像模型与价格。
4. 用代表性任务重新验收，不要假设替代型号保持完全相同的输出行为。
5. 在有限流量试跑中记录输入、输出、重试、错误、延迟和实际执行方式。
6. 用当前价格行重建预算，不要在退休模型金额上直接加一个百分比。

回退配置尤其容易漏改。主路径升级成功，但故障时仍回退到退休模型，会让一次局部问题变成连续失败。旧的 RPM、TPM 或每日额度表也应一起删除，否则当前项目可能被误判为异常。

迁移完成的标准不是“新模型能返回一次结果”，而是生产和回退都使用当前 ID，任务集通过，日志能解释 Token 与错误，预算使用当前价格，容量告警读取当前项目。任何一项仍依赖 Gemini 2.0，都只能算部分迁移。

用四步小规模测试定预算

第一步，记录真实工作量。 至少收集月调用次数、输入与输出的中位数和高分位数、重复前缀大小、延迟截止时间，以及能等待的任务比例。不要用一条短提示代表整个产品。

第二步，算 Standard 基线。 同时计算 2.5 Flash-Lite 和 3.1 Flash-Lite，把工具、Grounding、缓存存储、重试和税费单独列出。另一个工程师应该能仅凭日志和官方价格页复算出相同结果。

第三步，跑同一组任务验收。 记录通过率、重试、修复、输出量和延迟。Lite 都达不到门槛时，再加入一个稳定 Flash 候选；不要因为价格更高就默认它一定解决问题。

第四步，按运行条件分流。 请求链路使用 Standard，可等待工作使用支持的 Batch 或 Flex，高复用前缀评估显式缓存，只有可测失败才触发模型升级。提高试跑预算上限前，再检查一次模型状态和价格。

这个流程的输出不只是“选了哪个模型”，还应包括每种流量走哪条执行方式、何时停止折扣优化、何时升级、谁负责查看账单和配额，以及价格变化后如何复算。这样成本控制才是可执行的系统，而不是一次性的排行榜。

常见问题

当前最便宜的 Gemini Flash API 文本模型是哪一个？

截至 2026 年 7 月 14 日，gemini-2.5-flash-lite 在这里比较的 Flash-family 文本模型中拥有最低 Standard Token 价格：每 100 万输入 $0.10、输出 $0.40。它是当前价格最低行，不代表所有任务都应选它。

新项目该用 2.5 Flash-Lite 还是 3.1 Flash-Lite？

成本敏感时把两者放进同一任务集测试。2.5 Flash-Lite 单价更低；3.1 Flash-Lite 是更新的稳定低成本候选。选择能满足相同任务、输出和延迟要求的最低成本型号。

Gemini Flash 每次调用多少钱？

先用平均输入 Token 乘输入单价，再用平均输出 Token 乘输出单价，分别除以 100 万后相加。月成本再乘月调用次数。重试、工具、Grounding、缓存存储、税费和第三方加价要另算。

Batch 是否永远是 Standard 的一半价格？

核对日的支持价格行为 Standard 的 50%，但 Batch 只适合合格的非紧急异步任务，目标在 24 小时内完成。模型支持和业务延迟要求都满足时才使用。

Flex 和 Batch 是同一种东西吗？

不是。两者都可能在支持场景中显示折扣，但执行条件和可用性不同。要核对具体模型、区域和当前服务状态；需要正常交互链路的流量仍以 Standard 为基线。

上下文缓存会让整个账单都打折吗？

不会。显式缓存能降低被重复读取的合格输入成本，但缓存读取、存储时长、未缓存输入和输出仍收费。复用次数足够高，且存储没有吃掉节省时才划算。

Gemini API 免费额度具体是多少？

没有一个适用于所有项目的固定数字。模型、项目、层级、区域和当前政策都会影响可用额度。请在 Google AI Studio 查看实时值，并用 Gemini API 免费额度说明 处理账户层级问题。

Gemini 3 Flash Preview 适合作为生产默认吗？

默认不建议。Preview 意味着生命周期和行为变化风险更高。确实需要测试新一代能力时可以试用，但要有稳定回退，并且不能仅凭价格判断生产适用性。

Gemini 2.0 Flash 和 Flash-Lite 还能调用吗？

不能。Google 已将二者列为 2026 年 6 月 1 日停用。需要同时迁移请求路径、评测、回退 ID 和预算，不能只改主模型字符串。

3.1 Flash-Lite 和 Flash-Lite Image 是同一个模型吗？

不是。gemini-3.1-flash-lite 可以接收多模态输入，但输出文本。图像生成属于不同模型和价格合同，请查看 Gemini 3.1 Flash-Lite Image 成本说明。