Gemini API 费用拆解：区分输入类型、检查缓存条件、汇总完整费用

操作速览

1. 先记录输入是文字、图片、音频还是视频，再看同一模型和处理方式的计价行。

2. 把缓存存储、检索或其他工具费用单列；免费层与付费层规则不能混成一个费率。

3. 用原始 usage 和对应价格表复算一组请求，保存模型版本与核对日期，再估算整月费用。

Gemini Developer API 价格页按模型列出输入、输出、Context Caching、存储和 Batch 等项目；多模态模型还可能按文本、音频、图片或视频使用不同单位。比较前必须锁定 model、tier、modality 和 region。

账本不要只留 total_tokens。建议将 text_input、audio_input、cached_content、output、thinking、storage_token_hours 和 tool_usage 分列，再由费率快照计算；这样模型或模态变化不会污染历史趋势。

Gemini 文档将缓存分为隐式和显式两种。隐式缓存对支持的模型自动启用，但不保证命中；显式缓存由应用创建 cached content 资源并在后续请求引用，适合稳定的大型前缀和可控复用周期。

显式缓存总成本由缓存内容读取费、缓存存储费、未缓存输入费和输出费组成。存储项可表示为 cached_tokens×实际存储小时数×每百万 token 每小时价格；实际存储时长取创建到删除或到期的区间。

Gemini Batch API 支持把较小请求列表直接内联，也支持通过 JSONL 文件提交较大任务。官方文档截至 2026-08-29 将 Inline 描述为适合总请求体低于 20 MB 的小批次，较大请求则推荐文件方式。

Gemini 官方最佳实践明确提醒，重复发送相同创建请求会生成两个独立 Batch Job。网络超时后直接重试 create 可能造成重复执行与重复计费，因此调用前要写入本地 submission_intent，并在不确定状态下先查询已知作业。

请求前使用 count_tokens 做上下文检查和成本预算，请求后读取 usage_metadata 的 prompt、cached、candidates 与 thoughts 等字段。两者职责不同，估计值不应覆盖结算值。

规则核验于 2026-08-29。价格页更新后，应保留旧费率版本并只对新请求应用新快照；重算历史报表时根据请求时间选择费率，避免把涨跌幅错误归因于业务 token 变化。

价格、规则和产品状态可能变化，可通过这些原始页面确认当前信息。

Gemini 显式缓存只需要算命中 token 吗？

还要加入缓存内容的存储 token-hours，并计算未缓存输入、输出和可能的工具费用；TTL 过长会增加闲置成本。

Gemini Batch 创建超时后可以直接重试吗？

官方文档提示创建作业不是幂等操作。应先查本地作业登记和服务端状态，再决定是否补交，避免重复计费。