Gemini API 价格说明：Flash 到 Ultra 各档成本解读
Google Gemini 系列以超长上下文窗口著称，最高支持百万级 token 输入，是处理超长文档的有力选项。但超大上下文是把双刃剑——用不好反而会让成本大幅膨胀。
声明：以下价格描述均为截至 2026-06 的定性比较，仅供参考，以 Google 官方 AI Studio / Vertex AI 定价页面为准。
Gemini 模型档次
Google 的 Gemini 系列面向 API 的主要型号如下：
| 档次 | 代表模型 | 定位 |
|---|---|---|
| 轻量快速 | Gemini Flash | 价格极低，速度快，适合批量任务 |
| 主力旗舰 | Gemini Pro | 通用旗舰，平衡能力与成本 |
| 实验/顶级 | Gemini Ultra | 最强能力，定价最高，部分版本通过 Vertex AI 提供 |
其中 Gemini Flash 是定价最积极的一档，面向大量轻量任务设计，在同等能力级别中常被认为是性价比较高的选择。
计费结构与超长上下文定价差异
Gemini 同样采用输入 + 输出分开计费：
| 计费项 | 说明 |
|---|---|
| 短上下文输入（≤128K） | 标准价格 |
| 长上下文输入（>128K） | 部分模型会有额外计费或更高单价 |
| 输出 token | 单价高于输入 |
| 图像/视频输入（多模态） | 按帧/图片数量额外计算 |
长上下文的陷阱：Gemini 支持百万 token 上下文是技术优势，但超过某个阈值后，输入单价可能提高。实际使用前务必确认长上下文的具体计费段落，避免”用了百万上下文，账单翻几倍”的情况。
分段计价怎么算，别用一个单价乘到底
这里有个很多人踩过的坑：以为长上下文只是”单价整体上浮”，于是拿总 token 数直接乘一个价格估算，结果实际账单比预估高出一截。真实情况是分段计价——阈值以内按低价算，超出阈值的那一部分才按高价算，两段分别算完再相加。
用变量写清楚这个公式，你套自己账号看到的实际单价进去就行：
总成本 = min(输入tokens, 阈值) × 阈值内单价
+ max(0, 输入tokens - 阈值) × 阈值外单价
+ 输出tokens × 输出单价
举个例子帮你建立直觉（数字是假设值，只是为了说明分段逻辑，不代表真实定价）：假设阈值是 128K，阈值内单价是阈值外单价的一半。你这次调用喂进去 300K token 的文档，正确算法是前 128K 按低价、剩下 172K 按高价分别算，而不是把 300K 全按高价算，也不是全按低价算。差距可能是两三倍，量大的时候这个误差足够让你月底对不上账。
自查动作：调用前先用官方提供的 token 计数接口（一般叫 countTokens 之类的方法）实际数一遍这次请求会占多少 token，不要靠字符数拍脑袋估算——中文场景下字符数和 token 数的换算比例经常和你想的不一样，尤其是掺了代码、表格、多语言混排的文档，用估算公式很容易偏差 30% 以上。数完之后再套上面的分段公式，你会发现实际成本和”感觉上”差不少。
上下文缓存：把重复的大段输入价格打下来
如果你的业务场景是”同一份长文档，被反复问不同的问题”（比如一份产品手册，用户轮流问不同的问题；或者一段系统 Prompt + 长背景资料，每次对话都要带上），Gemini 提供了上下文缓存的能力，值得你认真评估要不要用。
思路很直接：把不常变的那部分内容（长背景资料、固定的系统指令、示例文档）预先注册成一份缓存内容，后续请求引用这份缓存而不是每次都把全文重新塞进 Prompt。命中缓存的那部分 token，计费单价通常明显低于按标准输入价格重新计算，具体折扣倍数以官方定价页当前公布的数值为准（这个数字会调整，不建议你写死在代码里的成本估算逻辑里，改成读配置或者定期核对）。
什么时候值得上缓存，什么时候不值得，你可以按这个判断：
| 场景 | 建议 |
|---|---|
| 同一份长文档/长 Prompt 被高频复用（一天几十上百次调用） | 上缓存，收益明显 |
| 长文档只会被问一两次就换掉 | 不建议上缓存，创建缓存本身也有成本和有效期管理的复杂度，得不偿失 |
| 缓存内容会频繁变化（比如每次都带最新的实时数据） | 不适合，缓存命中率低反而增加维护成本 |
| 团队内多个应用共享同一份背景资料 | 上缓存，尤其适合做统一封装 |
还有个容易漏掉的点：缓存是有过期时间的（一般以分钟到小时为单位，具体时长你可以在创建缓存时指定），过期后如果还要用得重新创建，这个创建动作本身也要计入你的成本模型，不是”设置一次就永久生效”。压测阶段建议你实际跑一遍完整生命周期，把创建、命中、过期重建这三种情况下的账单都记录下来对比，而不是只看官方文档里的理论折扣数字。
Google AI Studio vs Vertex AI
| 访问渠道 | 特点 | 适合谁 |
|---|---|---|
| Google AI Studio | 有免费额度，开发者入门首选 | 测试阶段、轻量应用 |
| Vertex AI | 企业级 SLA，支持私有网络、合规要求 | 生产环境、企业客户 |
| Gemini API（直接） | 统一 API，灵活接入 | 标准调用场景 |
生产环境的计费以所使用的渠道为准，两个渠道的定价可能有差异，需分别查阅官方文档。
Gemini vs GPT vs Claude：定性对比
| 对比维度 | Gemini Flash | Gemini Pro | GPT-4o | Claude Sonnet |
|---|---|---|---|---|
| 相对价格 | 很低 | 中 | 中高 | 中 |
| 上下文窗口 | 超长 | 超长（1M+） | 长（128K） | 长（200K） |
| 多模态能力 | 强 | 强 | 强 | 中等 |
| 中文能力 | 中等 | 中等偏强 | 中等偏强 | 中等偏强 |
Gemini Flash 在价格和多模态组合上有独特竞争力，适合图文混合处理的批量任务。
真实踩过的报错，对照排查
价格算得再准，接入过程中报错处理不当照样烧钱——重试策略写错了，一个 429 能在短时间内把你的调用量放大好几倍。下面这几种是接入 Gemini API 时最常遇到的报错，按现象对照着排查：
报错现象一：返回 429，响应体里带 RESOURCE_EXHAUSTED 这是触发了限流或者配额上限，不是你的账号被封。先看是”每分钟请求数”限流还是”每分钟 token 数”限流——两者触发条件不一样，前者是并发请求太密集，后者是单次请求或者短时间内总输入量太大。排查顺序：先降并发数看是否还报错，如果降到很低还报，大概率是 token 配额而不是请求数配额，需要去后台申请提额或者换更高的服务层级。
报错现象二：返回 400，INVALID_ARGUMENT，提示 token 超限 说明这次请求的输入（加上历史上下文、加上系统 Prompt）超过了模型支持的上下文窗口上限。这种情况不要靠”减少一点点内容试试”这种拍脑袋方式排查，老老实实调用一次 countTokens 接口把这次请求的精确 token 数打出来，跟模型上限对比，差多少一目了然，然后按你的业务优先级砍掉不重要的历史轮次或者做摘要压缩。
报错现象三：返回 401/403，PERMISSION_DENIED 或者提示 API key 无效 八成是这三个原因之一：key 复制粘贴带了多余的空格或换行符；对应的项目没有开通 Gemini API 或者没绑定计费账号；key 有 IP/域名白名单限制而你换了部署环境。排查时把 key 单独拎出来，用最简单的一条 curl 命令直接测试认证是否通过，不要在业务代码里连着一堆逻辑一起排查，容易把认证问题和业务逻辑问题混在一起浪费时间。
重试策略怎么写才不会火上浇油：遇到 429 直接立刻重试是最差的做法，等于给本来就吃紧的配额又加了一次请求，很容易越重试越失败。正确做法是指数退避加上随机抖动——第一次等 1 秒左右重试，失败了再等 2 秒左右，再失败等 4 秒左右，每次等待时间在这个基础上加一点随机浮动，避免多个并发请求在同一时刻扎堆重试。同时给重试次数设个上限（比如 3-5 次），到了上限就该报警而不是无限重试，不然遇到真正的服务异常会一直空转烧调用次数。
并发调用的一个隐藏成本：如果你的场景是批量处理大量文档（比如批量摘要、批量打标签），别一次性把并发拉满去跑，先用一个较低的并发数（比如 3-5）测试一轮，观察有没有 429，再逐步往上加。批量任务优先看官方是否提供了专门的批处理接口，通常批处理模式的单价会比逐条同步调用更划算，这个在预算紧张的项目里差别不小。
使用建议
- Gemini Flash 优先：价格最低，先评估是否满足任务质量要求
- 谨慎使用超长上下文：超过 128K 时确认是否触发更高计费区间，套上面的分段公式实算一遍再上线
- 多模态任务：图片/视频理解场景下 Gemini 有原生优势，但要提前用小样本摸清换算系数
- AI Studio 免费额度：开发测试阶段充分利用，上线前再切换到 Vertex AI
- 高频复用的长文档，评估上下文缓存：判断依据看上面那张场景表，别默认所有长文档都要缓存
- 重试策略走指数退避：不要用固定间隔重试，尤其是批量任务，抖动参数一定要加
多模态成本怎么估，别等账单出来才知道
图片和视频输入的计费方式和纯文本不一样——它们会被折算成”等效 token”再计入总量，而不是按文件大小或者张数直接算钱。这里有个实操建议：上线前先拿 5-10 张典型图片（或者一段典型时长的视频片段）单独跑一次，把返回结果里带的 usage 信息（输入 token 数、输出 token 数）记下来，反推出你这批素材大概会折算成多少 token。这一步花不了几分钟，但能让你在正式跑批量任务之前就摸清楚成本量级，而不是等几千张图片跑完之后被账单吓一跳。
几个会实际影响换算结果的因素，测试时留意：图片分辨率越高，折算的 token 数通常越多，所以如果你的任务对分辨率要求不高，先压缩一版再传进去，能实打实省钱；视频按时长和帧率折算，同样时长的视频，抽帧密度不同换算出来的 token 量差异也不小，能用低帧率满足任务的就别用默认最高帧率。
实时价格对比见：价格对比表
常见问题
Gemini 的免费额度怎么用？
Google AI Studio 提供按量免费配额，适合测试。具体免费额度数量和限制以官方最新说明为准，各家免费额度汇总见：各家免费额度盘点
在国内能访问 Gemini API 吗？
Gemini API 对中国大陆有访问限制，需要通过合规的 API 网关或中转层接入。详见：海外模型接入合规指南
Gemini 的多模态输入怎么计费？
图片通常按张数折算为等效 token，视频按帧率和时长折算，具体换算系数以官方文档为准。建议先用小批量测试确认单次成本。
为什么我自己数的字符数和 countTokens 返回的 token 数对不上？
中文场景下这是常态，token 切分不是按字符一对一映射，一个汉字未必等于一个 token，也可能几个字合并成一个 token，具体取决于分词器的实现。不要用”字符数除以某个固定比例”去估算账单，尤其是长文本、代码、多语言混排的内容偏差会更大。养成习惯：正式跑批量任务之前，先用真实素材调一次 countTokens，把这次的真实 token 数记录下来当基准，后续同类型任务按这个基准估算，比套统一换算比例靠谱得多。
遇到 429 是不是说明我的用量太大了，要不要马上升级付费档？
不一定。先分清楚是”短时间并发太密集”还是”总配额确实到顶”——前者通过调整并发数和加重试退避就能解决，不用花钱；后者才是真的需要申请提额或者升级服务层级。直接看响应体里配额相关的字段，能分辨出具体是哪种限流类型触发的，比瞎猜靠谱。
批量处理大量文档时，怎么把成本压到最低？
三个方向同时用：一是长文档如果会被重复问不同问题，走上下文缓存把重复的大段输入价格打下来；二是能用 Flash 完成的任务不要上 Pro，先用小样本验证 Flash 的质量能不能满足要求；三是如果官方提供批处理专用接口，优先用批处理而不是逐条同步调用，批处理模式通常单价更划算，尤其是不要求实时返回结果的离线任务。
延伸阅读：
- 计费原理全解：大模型 token 计费完全指南
- GPT API 价格：GPT API 价格说明
- Claude API 价格：Claude API 价格说明
- 海外模型对比：海外 vs 国产模型选型
- 实时价格查询：价格对比表工具
- 成本话题 Hub：token 成本专题