google gemini api 免费额度

很多人接 Gemini API 是冲着「有免费层」去的，代码跑通之后就不管了，直到某天用量涨上来，账单跟预估对不上，才发现免费和付费根本没隔开。这篇按「先确认你的项目在哪个层 → 免费层哪些限制会先卡住你 → 超限之后钱从哪儿扣」的顺序走一遍，每步给你可落地的动作，具体数额到站内对应页面核对当时的数字。

不少人接 Gemini API 是冲着「有免费层」去的，代码跑通之后就不管了，直到某天用量涨上来，账单跟预估对不上，才发现免费和付费根本没隔开。这篇按「先确认你的项目在哪个层 → 免费层哪些限制会先卡住你 → 超限之后钱从哪儿扣」的顺序走一遍，每步给可落地的动作，具体数额到站内对应页面核对当时的数字。

先说一句结论性的判断：免费层适合实验，付费层才适合承载业务。中间那段「先免费用着，超了自然会转付费」的想法，在多数项目里都不成立，因为两层是两套账，超限最常见的结局是请求直接失败，而不是悄悄帮你升级。

先搞清楚你在哪一层：免费层和付费层是两套账

免费层走的是 AI Studio 侧的项目，付费层走的是绑卡后的结算账号，两者额度口径不通用；同一个 key 不会自动跨层。这句话听起来像废话，但实际踩坑的人多数是没把「我用的这个接口到底属于哪档」写清楚，凭印象记，换个人接手就全乱了。先做一件事：到站内的 google 官方 API 页面 和 官方 API 总览 对照当时的免费与付费口径，把结论写进自己项目的 README。

免费层

不绑结算账号，按项目走，额度和频率都受限制，适合本地实验和原型验证

付费层

绑定结算账号后按用量计费，额度和并发口径与免费层不同，适合对外提供服务的接口

混用风险

同一个项目里既有实验调用又有线上调用，用量混在一起，出账时对不到具体来源

判断标准很直接：如果你的调用有对外用户、有 SLA 要求、或者跑批任务，默认按付费层规划，免费层只当试用。不适用的情况是纯本地实验、一天几十次调用，那免费层足够，没必要为了「以后可能要做大」提前付钱。

免费层先卡住你的通常不是 token，而是频率和并发

免费层常见的三类限制是每分钟请求数、每分钟 token 数、每天请求上限，任意一项触顶都会直接报错，而不是降级返回更差的结果。很多人的第一反应是「是不是模型不稳定」，其实先去看返回的错误码，配额类错误和网络类错误长得不一样。

• 先用站内的测速工具量出你的延迟基线，再按业务节奏倒推需要多少并发，判断免费层够不够，不要等线上报错才发现
• 循环批处理、爬虫式回填、多用户同时在线这三类场景最容易撞频率上限，上线前先做一次压测式的小流量试跑
• 把配额相关错误码单独抓出来记日志，不要和超时混在一个重试逻辑里，否则会越重试越撞线
• 给批处理任务加一个固定的请求间隔和失败排队机制，宁可跑慢一点，也比中途断掉重头再来划算

不适用的情况也要说清楚：间歇性、人工触发的调用，几乎撞不到频率上限，这时候花时间做限流反而是过度设计。真正需要提前规划的是无人值守的自动任务。

超限之后钱从哪扣：三条路径要分清

第二条路径是大多数人真正关心的：已经进了付费层，超出免费部分怎么算。别猜，用站内的 token 价格计算器 和 模型成本计算器 把自己的输入输出量代进去算一遍，按当时的数字来。想做「先免费用，超了自动转付费」的，必须确认结算账号是否真的绑定成功，否则超限就是直接失败。先搞清扣费顺序这件事，可参考站内讲免费额度与超额扣费顺序的那篇逻辑说明。

把免费和付费隔开的四个动作

1. 按环境拆 key实验、测试、生产各一个独立 key 或独立项目，命名带环境前缀，出问题时能一眼定位到是哪套调用。
2. 错误码进日志代码里显式读取配额相关错误码，命中就记日志并告警，而不是默默重试，默默重试只会把额度烧得更快。
3. 每天拉用量记录字段至少包含时间、接口、输入输出量、是否报错，字段清单可以对照站内的用量日志字段那套来定。
4. 设自用上限提醒阈值按你上个月实际用量的倍数来定，不用抄别人的数字；查当时的用量与价格到站内的用量页和价格追踪页核对。

不适用的情况也要提一句：多人共用一个账号的团队，光靠 key 隔离不够，还得在业务侧记调用人，否则账单只能对到项目、对不到人，月底对账还是抓瞎。