Google Gemini API Pricing 需要按工作流估算
Google Gemini API pricing 不能只看模型名称。你需要知道输入 token、输出 token、文件输入、上下文长度、缓存假设、请求量，以及产品到底用 Gemini 做文本、图片、音频还是视频理解。
先核对 Google AI pricing 官方页面，再把选定 Gemini 模型放进自己的工作流。本站的 AI API 价格表 适合比较价格行，文本 token 成本计算器 则适合把真实功能转成月度预算场景。
拆开文本、多模态和长上下文
很多人选择 Gemini，是因为它不只适合普通聊天。这种灵活性很有价值，但也会隐藏成本驱动因素。
| 工作流 | 需要建模的成本变量 |
|---|---|
| 短聊天或分类 | 每次请求的输入和输出 token |
| 带文档的 RAG 回答 | 检索上下文大小和重复指令 |
| 图片分析 | 文件数量、prompt 大小和回答长度 |
| 音频或视频理解 | 媒体时长、采样方式和后处理 |
| Agent 工作流 | 多轮模型调用加工具结果 |
如果你的应用同时用 Gemini 做文本聊天和文件分析，应拆成两行预算。便宜的文本工作流，一旦每次请求都带长上下文或媒体文件，成本结构就会完全变化。
不要忽略输出 token
很多团队只关注输入成本，却忘了输出长度。报告、摘要、JSON 抽取和多步解释，可能产生比预期更多的输出。如果用户可以要求无限细节，预算风险会从 prompt 大小转移到响应长度。
产品限制应提前设计：最大回答长度、摘要风格、抽取字段数量，以及是否展示冗长推理。然后用真实样例跑计算器，不要只用一个平均 token 猜测。
谨慎使用缓存和批处理假设
Google 文档可能会根据模型和平台提供缓存、批处理或上下文复用能力。这些能力可以降低成本或延迟，但只有在工作流真的重复稳定内容时才成立。
不要默认每次请求都有折扣。预算里应拆开冷请求、可缓存重复请求和离线批处理任务。上线后，再用日志里的 token 使用量对照假设并更新预算。
Gemini 预算模板
一张实用 Gemini 预算表应包含：
- 模型名称和价格来源检查日期
- 每次请求平均输入 token
- 每次请求平均输出 token
- 每次请求的媒体文件或长上下文规模
- 月请求量
- 重试和失败率
- 可用时的缓存命中或批处理占比
- 后续存储、审核或监控成本
这样模型选择才可复核。Google 调整价格行或你切换模型版本时，只需要更新变量，不必重做整个商业模型。
FAQ
Gemini API pricing 只按 token 计费吗？
文本使用通常按输入和输出 token 建模，但多模态工作流还需要考虑文件、时长或上下文大小。
为什么上下文长度影响这么大？
长 prompt、检索文档和重复指令都会增加可计费输入。大上下文很有用，但不能当成免费记忆。
应该先选最便宜的 Gemini 模型吗？
先选能通过质量测试的最低成本模型，再比较成本、延迟、失败率和人工审核负担。
SaaS 产品怎么预算 Gemini 成本？
按完成一次用户动作估算，而不是只看单次请求。要包含重试、输出长度、文件输入和后处理。