google 搜索 api 价格

做联网检索时，模型本身的调用只是账单的一半，检索这一侧往往被漏算：搜索接口按什么单位收费、免费额度怎么算、超出后单次成本怎么叠加，直接决定你的产品能不能跑得起来。这篇不背具体数字，只给判断口径和可以照着做的核算步骤，数字一律去站内对应页面按当时的价格核对。

做联网检索的产品，账单通常有两块：模型侧和检索侧。模型侧大家算得比较勤，检索侧经常被漏掉，等到上线才发现查询量是预估的好几倍。这篇不讲具体数字，只讲 Google 搜索 API 这类接口的计费口径怎么区分，以及你自己怎么把成本估出来。所有价格、档位、免费额度的真实数值，都到站内价格页按你查看当时的数字核对。

先说明适用范围：这里讨论的是调用外部搜索接口来拿实时网页结果。如果你的检索完全走本地知识库向量召回，不碰外部搜索 API，那这套口径对你没用，该去看嵌入模型那一侧的计费方式。下面按计费单位、免费额度过渡、自己估算、上线后控费四块讲。

先分清计的是哪一种「次」

搜索类接口常见的计费单位不止一种，混淆了后面全错。有的按请求次数计，你发一次查询就算一次；有的按返回结果条数分档，要得多就贵；还有的是包月套餐，里面含一定查询量，超出再按单价补。这三种在低频和高频场景下的总价排序完全不同，所以第一步永远是确认你签的是哪种口径。

按请求计费

每发一次查询算一次，和返回几条结果无关，适合返回条数固定的场景

按结果条数计费

返回越多越贵，适合只取前几条、且能自己控制条数的场景

套餐包月

先买一个查询量包，超出部分另算，适合用量稳定的长期产品

最容易被忽略的是「用户提问次数」和「后端检索请求数」不是一回事。一轮多轮对话里，用户可能追问三次，每次追问你的后端都去检索一遍；再加上失败重试、翻页取更多结果、A/B 两套策略同时跑，后端请求数往往是用户提问数的好几倍。做用量预估时，一定按后端请求数算，不要按用户提问数算。

• 确认计费单位是请求数、结果条数还是套餐，三者不要混算
• 数清楚一次用户提问平均触发几次后端检索，把这个倍数记下来
• 确认失败重试是否也计费，计费的话把重试率纳入预估
• 本地向量召回为主的场景不适用这套口径，去看嵌入模型计费

免费额度怎么过渡到付费

免费阶段的限制方式决定了你的开发排期。如果免费额度是每日上限，那适合做功能验证，每天跑一点、第二天重置；如果是每月上限，更适合小流量上线试水，但一旦月中用完，后面就得等或者直接付费。先看清楚是哪种，再决定把压测放到哪一天做。

核对用量时有个实用原则：如果调用次数面板和出账金额对不上，优先信调用次数。金额受单价调整、阶梯、税费影响，次数是最原始的记录。发现对不上就去站内价格页看当时的档位说明，再回头看是不是跨了阶梯。

给自己的场景估一遍钱：四步

估算不需要精确到分，但必须把倍数关系理清楚，否则误差会有数量级。下面四步按顺序做，每步的输出都是下一步的输入。

1. 算单用户日请求量统计每人每天平均提问次数，乘以每次提问触发的后端检索请求数（含重试和翻页），得到单用户每天大概发多少次检索请求
2. 放大到全量用户用单用户日请求量乘以目标用户数，再乘三十得到月度请求量上限，拿这个数去站内价格页对照当时的档位
3. 加上模型侧的二次消费搜索返回的网页内容要再喂给模型，这段 token 也是钱，检索成本往往只是小头，别只算一边
4. 留余量在总数上再加两到三成，给缓存未命中、调试重放、灰度流量留空间，预估太满上线就超

估算时还要注意档位的非线性。很多套餐在低档位单价高、高档位单价低，所以不是请求量翻倍、成本就翻倍。反过来，如果你的量刚好卡在两档之间，稍微优化一下缓存就能掉进便宜的那一档，值得专门算一次。

上线后怎么把这块压住

上线之后成本是动态的，靠事前估算不够，得有几个可盯的指标。最直接的是缓存命中率：搜索类请求的重复率通常不低，相似查询、热门查询、同一次会话里的连续追问都会重复，把这些挡住，请求数立刻就下来了。

• 对相同或近似查询做结果缓存，命中率是第一个要盯的省钱指标
• 限制单次返回条数和摘要长度，很多场景只要前几条，多要的既贵又没用
• 给检索调用单独设预算告警线，和模型调用分开埋点，涨了能一眼看出是哪边
• 定期回看误触发和空结果的请求，这类请求花了钱但没产出

关于不适用的情形：如果你的产品对实时性要求极高、查询几乎不重复，缓存收益会很有限，这时候该考虑的是限制单次检索的深度，而不是指望缓存。另外，如果检索频次本身就很低，投入工程做缓存可能不划算，直接按量付费更省事。

检索成本不是一次算准的，是上线之后靠缓存命中率和告警线一点点压下来的。