Gemini grounding 成本怎么算

Grounding 的成本单位是搜索查询而不是请求：Gemini 3 及更新模型每条模型执行的查询都计费，每月 5,000 条免费，之后每千条 $14。（核验 2026-11-05，F89、F36）

一、Gemini grounding 成本怎么算：按请求估，问题在差出一个倍数

Grounding（也就是常说的联网搜索）做预算时，最常见的算法是：每天多少请求，乘以每次多少钱。这套算法在接地这里会失效，因为计费单位不是请求，是查询。

官方的口径写得很明确：Gemini 3 及更新模型按模型实际执行的每条搜索查询计费，一次提示里搜了两条，就算两次；空查询不计入（F89）。而 Gemini 2.5 及更早的模型是按每个提示计费——同一个产品换一次模型，成本模型就从「请求数」变成了「查询数」。

这个差别有多大？取决于模型想问几次。查一个简单事实可能一条查询就够；查「某公司上季度营收与同比变化」这种复合问题，它可能先搜公司名、再搜财报、再搜行业对比。同一批请求，查询数可能翻几倍。按请求估成本，会系统性低估。

二、联网搜索的成本估算：最小可运行示例

下面这段把三个常量摊开：每次请求平均几条查询、每月免费多少条、超出后每千条多少钱。

## EXPECT: 计费法则：月查询数 - 5,000 = 超出条数；超出条数 ÷ 1,000 × $14 = 账单 | 每条请求 3 条查询：按请求估会少算 3 倍
QUERIES_PER_REQUEST = 3      # 平均值，来自你自己的日志，不是拍脑袋
FREE_PER_MONTH = 5000
PRICE_PER_K = 14
DAYS = 30

def usage(requests_per_day):
    return requests_per_day * DAYS * QUERIES_PER_REQUEST

def overage(requests_per_day):
    return max(0, usage(requests_per_day) - FREE_PER_MONTH)

assert overage(10) == 0 and overage(100) > 0
print(f"计费法则：月查询数 - {FREE_PER_MONTH:,} = 超出条数；"
      f"超出条数 ÷ 1,000 × ${PRICE_PER_K} = 账单 | "
      f"每条请求 {QUERIES_PER_REQUEST} 条查询：按请求估会少算 {QUERIES_PER_REQUEST} 倍")

这段代码里最重要的不是那两个 overage() 调用，而是 QUERIES_PER_REQUEST 这个常量。它不能猜——去你的日志里数一下「一次交互触发了 google_search_call 里的几条 queries」，取一个真实均值（F90 的响应结构里就能数）。这个数字每变一次，你的预算表就要重算一次。真实均值怎么来？遍历响应里的 steps，把每次 google_search_call 的查询条数加起来：

for step in interaction.steps:
    if step.type == "google_search_call":
        print(step.arguments["queries"])

跑一天的样本，把每条请求的查询条数取平均，就是 QUERIES_PER_REQUEST。

有了这条法则，手算就够了。举两个例子：月搜索六千条，超出免费额度一千条，账单是十四美元；月搜索一万二千条，超出七千条，账单是九十八美元。注意这两个数都按「查询」算，如果你的产品每月有一万次请求、每次查询三条，那么月查询量就是三万条——超出的两万五千条对应三百五十美元。先算查询量，再套法则，顺序反过来就会算少。

三、解释与边界：四个容易算错的地方

第一，单位是查询。 一次提示多条查询算多次（F89）。这也是为什么「请求量没涨，账单涨了」会发生在换了更愿意搜索的模型之后——不是请求变多，是每条请求搜得更勤。

第二，免费额度是共享的。 每月 5,000 条免费搜索请求，由所有 Gemini 3 及更新模型共享，不是每个模型给一份（F36）。多模型混跑时，别按模型分别扣额度。额度按自然月重置，跨月那批请求算哪个月，以账单页的口径为准；预估时按最坏情况（两边都占）算，误差方向才是安全的。

第三，限流可能比预算先到。 付费层默认每天 1,500 条搜索请求的上限（F24），超出要单独申请提额。一个每天几万次调用的产品，先撞的往往是这个日限，而不是账单。所以预算表里要同时列两行：月成本、日查询数占日限的比例。

第四，File Search 是另一套账。 私有库不按查询计费：建索引时按 embedding 收费，存储免费，查询时的 embedding 也免费，真正花钱的是检索到并送进上下文的文档 token——按普通上下文 token 计价（F100）。所以「我把搜索换成私有库是不是更便宜」这个问题没有统一答案，得按你的文档量与检索命中量分别算。

降查询数比降请求数有效。 既然钱花在查询上，优化目标就该是「让模型少搜几次」：把问题写具体（少一次消歧搜索）、给定时效边界（少一次「最新」的搜索）、能用 URL Context 就给它确切地址（那部分不进搜索计费）、对高频重复问题做结果缓存。这四条做法里前两条改提示词，后两条改架构，都不必换模型；收益按周就能在账单上看到。

预算按分位数算，别按均值。 同一批请求在不同日期搜得不一样多——大新闻发生那天，模型更倾向多搜几轮。按月定额时用近三个月查询数的高分位而不是平均值：均值看起来省钱，撞上高峰就超。这条是工程经验，不是官方口径，但它解释了为什么「上个月够用」的预算这个月会破。

边界。 本节只算「搜一次花多少」。单请求的 token 账单（输入、输出、思考）见 10.1；免费层与付费层的分层门槛见 10.2；推理档位（Batch／Flex）的折扣见 10.3。价格本身会变，本节给的是算法，不是报价。

四、预期输出与异常分支

真跑输出：

计费法则：月查询数 - 5,000 = 超出条数；超出条数 ÷ 1,000 × $14 = 账单 | 每条请求 3 条查询：按请求估会少算 3 倍

六类分支。按请求数估成本：系统性低估，低估倍数就等于平均查询数。忽略空查询不计：这会让你把「模型决定不搜」的那些请求也算成钱，方向反了（F89）。忽略 1,500 RPD：预算够但限流先到，表现为整点前后大量失败（F24）。按模型分别扣免费额度：实际是共享的，会重复计算余量（F36）。把 File Search 的账套进搜索公式：口径完全不同，会把私有库算贵或算便宜一个量级（F100）。换模型后没重算：2.5 及更早按提示计费，迁到 Gemini 3 之后计费单位变了（F89），旧预算表直接失效。多个功能共用项目额度：搜索额度按项目算，A 功能的突发会把 B 功能的余量吃光；重要链路要么单独拆项目，要么在监控上分开统计。缓存了答案没缓存查询数：命中缓存不再触发搜索，成本下来了；但如果缓存键设计得粗，把不同时效的问题混在一起，省下的钱会以「答错」的形式还回来。

五、判据卡：什么时候该关掉 grounding

该这么做	不该这么做
从日志统计每条请求的真实查询数	用「一次请求一次搜索」估预算
先查日限 1,500 再谈账单	认为预算够就不会失败
私有库按 embedding 与上下文 token 单算	把 File Search 套进搜索公式
换模型后重算计费单位	沿用 2.5 时代的按提示算法

六、来源与核验

https://aistudio.google.com/docs/google-search.md（核验 2026-11-05，F89、F90）
https://aistudio.google.com/docs/pricing.md（核验 2026-11-05，F36）
https://aistudio.google.com/docs/rate-limits.md（核验 2026-11-05，F24）
https://aistudio.google.com/docs/file-search.md（核验 2026-11-05，F100）

计费单位与免费额度属于「价格」档事实，复核周期一个月，见 1.3。下个月 1 日前后价格页可能有切换，本节的两个常量（5,000 与 $14）要逐字对一遍原文再引用。

七、动手试

把 QUERIES_PER_REQUEST 从 3 改成 1，重跑。预期 小流量落在免费额度内 仍为 True；验收标准是你算出「这个假设会让预算低估几倍」，并说明倍数从哪来。
给你自己的项目估一次：抓一天的真实请求数，再从响应里数 google_search_call 的 queries 条数，算出平均查询数。验收标准：给出这个均值与它的样本量；没有样本量就说明你在猜。
打开价格页，逐字确认「5,000」「$14」两个数字今天是否还成立。验收标准：写下你核对的时间与页面标题；写不出来，说明你引用的是二手转述。