gemini api价格

想接 Gemini API 的开发者最常卡在两件事：免费额度和付费额度到底是不是同一套模型，以及不同档位模型的计费口径怎么对齐比价。这篇不报具体数字，只给一套判断顺序：先分清你在用哪个入口、再确认额度归属、最后去看当时的价格页。

想接 Gemini API 的开发者，最常卡在两件事上：免费额度和付费额度到底是不是同一套模型，以及不同档位模型的计费口径怎么对齐去比价。这两件事其实都不是靠记数字能解决的，因为价格和额度规则会调整，你记住的那个数未必是当下的。

这篇不报具体数字，只给一套判断顺序：先分清你在用哪个入口，再确认额度归谁管，最后去站内价格页看当时的数字。顺序对了，自己就能算清楚，不用到处问人。

先分清你从哪个入口调 Gemini

官方直连入口和云平台托管入口是两套账单。模型名字看着差不多，但计费口径、限速规则、可用区域都可能不一样，别拿一个入口的价去套另一个入口。很多「同款模型怎么两个价」的困惑，根子就在这里。

判断方法很简单：看你手上的 key 是在哪申请的，再看控制台的账单页把费用归到哪个账号名下。两个地方对不上，说明你混用了入口。

• 看 key 的申请来源：是官方开发者控制台，还是某个云平台的凭证体系。
• 看账单归属：费用出现在哪个账号、哪个项目下，这一栏基本就定性了。
• 看限速报错文案：不同入口的限速提示格式往往有区别，能反推你在走哪条路。
• 如果你已经开了某档订阅，先确认订阅额度覆盖的是网页端还是 API 调用，这两者通常不通用。

档位和模型名不是一回事

同一代模型里通常分了快而便宜、均衡、旗舰三档，计费差别主要落在输入和输出两个方向的单价上。有些档位输入便宜输出贵，有些反过来，所以只看一个方向的单价去比价会得出错误结论。

比价前先对齐口径：单位是每百万 token 还是每千 token，输入输出是否同价，多模态输入是否另算，长上下文是否触发更高单价档。这几项不对齐，表格里排出来的顺序就是假的。

不要按名字猜档位。名字里的字样不保证对应收费高低，最稳的是到站内模型清单页对照当时的模型列表，再到官方 API 价格页看对应那一行的数字。

一次调用里哪些部分会被计费

典型的计费项包括输入 token 和输出 token，多模态请求还会有图片、音频、视频折算出的等价单位。输出侧通常比输入侧贵，但具体倍数因档位而异，这一点决定了你的产品设计里哪些环节该省。

下面几项是经常被忽略、但对账单影响不小的，需要逐个去确认：系统提示词是不是每次调用都重算、超长上下文会不会触发更高单价档、批量接口有没有单独的价目。

1. 挑一条真实请求不要用测试用的 hello world，用你线上跑的一条典型请求，参数和真实场景一致。
2. 对上它的用量明细在账单或用量页找到这条请求，看它被拆成几行、每行是什么计费项。
3. 标出重复计费的部分如果系统提示词每次都出现，说明它每轮都在计费，这是优化点。
4. 反推单价用这一条的用量和产生的小时费用上去对，验证你对价格表的理解有没有偏差。

做完这四步，你对「一次调用到底花在哪」就有实感了，比读十遍价格表都管用。

免费额度的真实边界在哪

免费额度通常绑在特定入口和特定档位模型上。旗舰档往往不在免费范围内，或者给的额度极小，只够做连通性验证，不够跑业务。指望拿免费额度撑住一个真实产品，多半会撞墙。

限制项也不止 token 数。每分钟请求数、每天请求数、并发数都可能先撞上——很多时候你不是把额度用完了，而是被速率限制挡住了。这两种报错要区分开，解决方式完全不同。

总量限制

一段时间内可用的 token 或请求总数，用完就没了，看额度表。

速率限制

单位时间内的调用频率上限，跟剩余额度无关，看限速说明。

并发限制

同时在跑的请求数上限，超了会排队或直接拒绝。

额度归属

额度挂在哪个项目或 key 上，团队共用时会互相占用。

免费额度用超后的处理方式各家不同，可能是直接报错，也可能是自动转付费继续跑。动手前先去站内免费额度说明类的页面确认扣费顺序，别等收到账单才发现它自己转了。什么情况下不适用：如果你本来就走付费入口，免费额度那套规则跟你没关系，直接看价格页即可。

免费额度和付费额度混用时怎么算账

同一个项目里既走免费额度又走付费额度，成本分摊会失真——你没法从总账单里看出哪部分本该是免费的。建议按 key 或按环境分开：测试环境用免费 key，生产环境用付费 key，两边账目清清爽爽。

• 按 key 隔离：测试和线上各用一套凭证，避免额度互相占用。
• 按环境隔离：开发、预发、生产分开项目，账单能对上责任人。
• 用量日志至少留这几列：时间、模型名、入口、输入输出 token、是否命中缓存、走的哪种额度。
• 不要只记总量。总量对不上时，有明细才能定位是哪个环节跑飞了。

团队里做成本归集时，不要把免费额度算成零成本。否则预算模型到了付费阶段会整体偏低，到时候要么砍功能，要么临时申请预算，都很被动。保守做法是把免费额度当作缓冲，不当作基础。

缓存和批量对账单的影响

较长且重复的上下文用缓存，通常能明显压低输入侧开销。但命中条件比较挑：前缀要足够稳定、调用要足够密集，不然缓存还没生效就已经过期了，白折腾。

批量接口一般比实时调用便宜，代价是等待时间。适合离线跑评测、批处理文档、生成报表这类任务——这些场景本来就不要求秒回。把它用在用户等待的链路上，省的那点钱抵不上体验损失。

判断要不要上缓存，先看你的请求里重复前缀占比高不高。占比低就没必要折腾，接入成本收不回来。

估算自己一个月大概花多少：五步

1. 统计真实调用量每天多少次调用，平均输入和输出各多少 token，从线上日志取，不要拍脑袋。
2. 按档位分类任务哪些任务必须用旗舰档，哪些用便宜档就够。通常只有少数任务真的需要旗舰。
3. 代入当时价格算到站内模型成本计算工具页，按价格页当下的数字代进去算，别用记忆里的旧数。
4. 留出余量重试、长上下文突增、灰度放量都会推高用量，一般按估算值上浮一截再报预算。
5. 设预算告警在用量页设阈值提醒，别等月底才发现跑飞了。

这五步做完，你手上就有一份能拿去申请预算的估算，而不是一个模糊的「应该不贵吧」。到站内价格追踪页面看当时的数字，把工具算出来的结果和它对齐一遍。

什么情况下这套判断不适用

走云平台转售或第三方聚合入口的，价格和限速都不由官方直接决定，要看渠道自己的规则。同一个模型经不同渠道转发，账单口径可能完全不同，上面那套对齐方法要换成对着渠道文档做。

• 有企业协议价、承诺用量折扣的：公开价目表参考价值有限，以合同口径为准。
• 纯实验、用量极小的个人开发者：纠结单价意义不大，优先看额度和限速够不够用。
• 对延迟极度敏感的场景：省钱手段往往要牺牲响应速度，这时候成本不是第一优先级。
• 合规要求高的业务：渠道和数据路径的限制可能先于价格成为决定因素。

一句话，价格判断永远要结合你的入口、用量形态和业务约束一起看，单独拎出一个单价数字来比，意义有限。

先确认入口，再对齐口径，最后才看数字——顺序反了，看多少价格表都是白看。