gemini 3.7 flash价格

打算用 Gemini Flash 跑批处理、客服问答或者内容生成，最先卡住的往往不是能不能调通，而是「这个月大概要花多少」。同样一个模型，输入输出占比不同、上下文长短不同、有没有走缓存，账单能差出好几倍。这篇不谈模型好坏，只按用途把成本拆开算一遍，并给出对账和压价的具体动作。

打算用 Gemini Flash 跑批处理、客服问答或者内容生成，最先卡住的往往不是能不能调通，而是「这个月大概要花多少」。同样一个模型，输入输出占比不同、上下文长短不同、有没有走缓存，账单能差出好几倍。这篇不谈模型好坏，只按用途把成本拆开算一遍，并给出对账和压价的具体动作。

先把心态放平：单价本身只是算式里的一个乘数，真正决定你账单的是「单位任务消耗多少 token」乘「任务数量」。所以下面不会给你一个固定数字，而是教你怎么把自己的用量代进去，去站内页面核对当期口径。这样数字变了，方法还能用。

Flash 的单价由哪几块拼出来

Flash 这类模型的计价不是一口价，而是按输入、输出、缓存等口径拆开算的。你要做的第一件事，是把自己的任务对号入座：是「读得多写得少」，还是「写得比读得多」。前者成本压在输入侧，后者压在输出侧，两者优化方向完全相反。

输入价

你发过去的提示词、上下文、检索片段都算在内，长文档任务的大头往往在这里

输出价

模型生成的内容，通常比输入贵，写作、代码生成、长回答会明显放量

缓存命中价

前缀稳定时可复用的部分，命中与否单价不同，前提是你的提示词前缀不来回变

批处理价

允许异步、可等待的任务走的入口，和实时调用不是一个档次

还有一层容易被忽略的：同一模型从官方 API、云平台托管、中转站调用，单价和倍率未必一致，还可能叠上汇率与手续费。想比价不要凭记忆，直接到 /official-api 以及 /official-api/providers/google 看当期的官方口径和各家差异。

按用途把高频场景分成四类

不同团队用同一个模型，账单结构可以完全不同。把任务先归类，再决定优化重点，比一上来就换模型有效得多。下面这张表是四类场景的成本重心对照，你可以直接拿自己的业务往里套。

• 问答类：用户一句话，你塞进去一整篇手册，成本就是这么涨上去的；
• 生成类：单价再友好，架不住一次生成几千字、一天跑几百次；
• 批处理类：量大但可等，能不能走异步入口直接决定成本档次；
• Agent 类：看着每轮不贵，把历史一路带上后，实际消耗远高于单次估算。

从用量记录倒推每月花多少

估算月开销不要靠猜，靠一周真实日志就够。核心是三个数：请求数、平均输入 token、平均输出 token。把这三个数固定下来，剩下就是乘法，换月只换数字，方法不用重想。

1. 抓一周真实日志统计请求数、平均输入 token、平均输出 token 三项，注意区分实时调用和批处理，两者要分开记
2. 换算成钱用 /tools/token-price-calculator 或 /tools/model-cost-calculator 把 token 量代入当期单价，注意单位是按每百万 token 计
3. 乘增长系数按业务预期给一个增长倍数，算出的是一个区间而不是一个数，写预算时取上限用
4. 固化成模板把结果记进 /ai-cost-estimate-template，下个月只换数字，方法和字段沿用

得到的区间拿去和实际账单比，如果差得离谱，八成是某类请求没被算进去，比如重试、内部测试流量、或者多模态输入。别急着改预算，先把差异来源找出来。

同样调用量，为什么你的更贵

调用次数一样、账单却高出一截，通常不是单价问题，而是「每次调用里塞了什么」的问题。下面几条是最常见的放大器，逐条对照自己的代码看一遍，命中一条就够解释了。

• 上下文没裁剪：把整篇文档或整库检索结果塞进去，输入侧直接翻倍；
• 失败重试没去重：超时后原样重发，等于同一件事付了两次钱；
• 多轮历史不清：会话越聊越长，每轮都把完整历史再送一遍；
• 前缀不稳定：系统提示词里夹了时间戳或随机 ID，缓存基本命中不了。

缓存命中的判定规则、什么情况下会失效，本身不是三言两语能说清的，建议直接看 /context-cache-vs-prompt-cache，先把自己代码里的前缀结构改稳，再谈其他优化。

把花费压下来的动作顺序

优化顺序错了，容易白忙。正确做法是按「收益大、改动小」的原则从上往下做，前两步不做，后面再折腾效果也有限。下面四步建议严格按顺序执行，每步做完都看一次账单变化。

1. 先砍输入检索只带相关片段，别整库往里塞；能用摘要就不用全文，改完对比平均输入 token 是否下降
2. 再选入口量大且能等的任务走批处理，实时性要求高的才用常规调用，把两类任务在日志里区分开
3. 固定前缀把系统提示词、固定格式模板放在最前面且保持稳定，提高缓存复用，做法参考 /context-cache-vs-prompt-cache
4. 最后设闸配好单日预算告警，跑飞当晚就能发现而不是月底才知道，配置方法见 /budget-alert-setup-guide

如果四步都做了账单还是偏高，那就不是优化问题，而是模型选型该重新看了。这种情况下可以到 /rankings 看看同价位段的替代方案，或者去 /price-watch 追踪价格变动后再决定是否切换。

账单和预估对不上时怎么排查

对账最忌讳只看总额，总额只能告诉你「不对」，不能告诉你「哪里不对」。正确做法是按计价口径拆成几列分别核对，再去看时间分布，绝大多数异常都能定位到具体任务。

• 把日志按小时切片，异常尖峰通常集中在某个任务或某次批量重跑；
• 确认计价口径是否含税、是否因为按美元结算产生汇兑差；
• 检查是否有测试流量、内部灰度请求打进了生产账号；
• 差异定位到具体字段后，再决定是改代码还是改调用策略，别先改预算数字。

什么情况下这套算法不适用

上面这套按量计费的核算方法，前提是你真的按 token 付费、且模型入口口径统一。下面几种情况直接套用会得出错误结论，要么换算法，要么干脆别算，看实际扣费更靠谱。

• 你走的是订阅制或套餐制：额度口径和按量计费不是一回事，估出来的数没有意义；
• 调用里混合了图片、音视频等多模态输入：计价单位和纯文本不同，不能按 token 单价直接乘；
• 平台正在做促销或赠送额度：当期实付和标价对不上，应以实际扣费记录为准；
• 你用的是自建部署或私有化方案：成本结构变成算力与运维，和 API 单价是两套账。

单价决定上限，用量结构决定实际账单；先把每次调用里塞了什么搞清楚，再谈价格高低。