Gemini 长上下文成本估算表：输入、输出、缓存怎么拆

做 Gemini 长上下文应用时，最容易出问题的不是第一版代码，而是成本模型。测试阶段只跑几十次请求，账单看起来很轻；上线后用户开始上传 PDF、合同、日志、代码仓库，输入 token 被放大，费用曲线马上变陡。

这篇按工程实现来拆：输入 token、输出 token、Context caching、Batch API、重试和国内调用限制分别怎么估算。

1. 成本拆分公式

先把一次请求拆开：

text 复制代码

request_cost =
input_tokens / 1_000_000 * input_price
+ output_tokens / 1_000_000 * output_price
+ cached_tokens / 1_000_000 * cache_read_price
+ cached_tokens / 1_000_000 * cache_storage_price_per_hour * cache_hours
+ extra_tool_cost

月成本：

text 复制代码

monthly_cost =
request_cost
* daily_requests
* 30
* retry_factor
* peak_buffer

建议一开始把 retry_factor 设为 1.05 ~ 1.2，国内链路不稳定、超时重试、限流重放都会让实际请求数高于业务请求数。peak_buffer 可以按 1.2 ~ 1.5 预留，防止促销、活动、批量导入时击穿预算。

2. 先统计 token，不要靠字符数猜

Gemini API 提供 token counting 能力，开发阶段就应该把 input_tokens、output_tokens、cached_tokens 写进日志。不要只记录调用次数。

一个最小日志字段可以这样设计：

json 复制代码

{
  "request_id": "req_20260521_001",
  "user_id": "u_10001",
  "model": "gemini-3.1-pro-preview",
  "input_tokens": 185320,
  "output_tokens": 4200,
  "cached_tokens": 160000,
  "cache_hit": true,
  "latency_ms": 18300,
  "retry_count": 0,
  "business_scene": "contract_review"
}

有了这组字段，后面才能按用户、场景、模型、文档类型做成本分析。

3. 输入 token：长上下文的主要成本来源

很多长文档应用的请求体结构是这样的：

text 复制代码

system_prompt
+ user_profile
+ document_text
+ retrieved_chunks
+ chat_history
+ current_question

其中真正大的通常是 document_text 和 chat_history。如果每轮追问都重新发送完整文档，成本会被线性放大。

优化建议：

文档只问一次：切块、摘要、结构化抽取优先。
文档反复追问：考虑 Context caching。
多轮对话：不要无脑携带全部历史，保留任务相关摘要。
代码库场景：不要把整个仓库塞进去，先做检索和文件级上下文选择。

Gemini CLI 的 GitHub issue 里也有类似讨论：如果工具每轮都重新发送系统提示、工具定义和完整历史，token 使用会快速膨胀。这类问题放到企业应用里，本质就是成本治理问题。

4. 输出 token：要限制格式

输出 token 往往被低估。比如合同审查场景，模型可能输出很长的解释、风险描述和建议条款。Gemini 3.1 Pro Preview 这类模型输出单价高于输入单价，长报告会明显影响账单。

可以在 prompt 里要求结构化输出：

text 复制代码

只输出 JSON，不要解释。
每个风险点字段包含：
- clause_id
- risk_level
- reason，最多 80 字
- suggestion，最多 120 字
最多返回 20 条。

如果面向用户要自然语言报告，可以先让模型输出结构化结果，再由便宜模型或模板层生成展示文本。跨模型横评时，内部文档可以按最新命名写 GPT-5.5、Claude 4.7、Gemini 3.1 Pro Preview，但最终上线仍要以供应商 API 列表里的实际可用 model id 为准。

5. Context caching：适合高复用，不适合所有场景

Gemini Context caching 的价值在于把重复上下文从"每次完整输入"变成"缓存读取"。适合场景：

同一份文档被连续问很多问题。
同一套知识库被大量用户复用。
同一段系统级说明或工具说明非常长。
需要在一段时间内反复引用相同媒体或文本。

不适合场景：

每份文档只处理一次。
上下文变化很快，缓存命中率低。
缓存粒度设计混乱，把当前问题也一起缓存。

缓存键建议按稳定内容生成：

text 复制代码

cache_key = sha256(model + document_version + normalized_document_text)

不要把用户问题、时间戳、随机 trace id 放进缓存内容，否则命中率会很差。

6. Batch API：离线任务优先考虑

Google 文档中 Batch API 适合异步批量任务，并且价格通常比标准同步请求低。它适合：

批量摘要历史客服记录。
夜间处理合同库。
批量生成标签和分类。
对日志、工单、知识库做离线清洗。

不适合：

用户在线等待的实时问答。
对时延敏感的 Agent。
需要连续多轮工具调用的交互任务。

架构上可以把任务分成两条链路：

text 复制代码

在线链路：同步 API + 小上下文 + 快速返回
离线链路：Batch API + 长上下文 + 队列 + 结果回写

7. 国内调用限制要写进工程方案

国内团队直接使用 Gemini API，会遇到几个现实问题。

首先是区域可用性。Google AI Studio 和 Gemini API 有官方支持区域列表，中国大陆开发者需要确认账号和服务条款，不要默认所有环境都能直接开通。

其次是网络链路。长上下文请求体大，超时概率更高。工程上要做：

text 复制代码

幂等 request_id
指数退避
最大重试次数
失败队列
超时后的成本标记

再次是结算。美元计价、海外支付、企业发票、预算审批都会影响落地速度。

最后是数据合规。合同、病历、金融资料、政企文档进入海外模型前，要先做数据分类、脱敏和审批。

8. 词元无忧 API 的工程位置

词元无忧 API（token5u API）更适合放在模型网关层。应用侧统一请求一个兼容接口，网关侧处理 Gemini、GPT-5.5、Claude 4.7 等模型的路由、限流、账单、重试和企业结算。

这样做的价值不是"换个 URL 就万事大吉"，而是把成本数据收敛到一个地方：

text 复制代码

业务服务 -> 统一模型网关 -> 词元无忧 API -> 多模型供应
                    |
               成本日志、限流、告警、降级

对国内团队来说，人民币结算、按实际用量计费、无预付和无隐性收费，比单纯比较美元 token 单价更贴近日常预算管理。

9. 最小可用估算表

场景	平均输入	平均输出	是否缓存	是否批处理	成本风险
单份合同审查	100k	5k	否	否	输出过长
年报多轮问答	180k	3k	是	否	缓存 TTL
客服记录批量摘要	20k	1k	否	是	批量峰值
代码库问答	50k	4k	部分	否	历史上下文膨胀

上线前至少跑一周影子流量，把 P50、P90、P99 的 token 使用量统计出来，再决定模型、缓存和批处理策略。