巧用上下文缓存，大模型调用成本最高省九成

一、账单为什么越滚越贵：被忽视的“重复计费”

大模型 API 通常按输入、输出 Token 分别计费。不少开发者把优化精力全放在压缩输出上，却忽略了一个更隐蔽的成本黑洞——输入侧的重复计费。

典型的成本浪费场景包括：

• 长系统提示词：角色设定、格式约束、Few-shot 示例动辄数千 Token，而每次请求都要为它原价买单一次；
• 多轮对话：历史消息随轮次线性膨胀，第 N 轮请求要为前 N−1 轮的完整历史再付一遍输入费；
• RAG 应用：检索到的长文档片段被塞进提示词，同一批文档在多次提问中被反复计费；
• Agent 应用：工具定义（函数签名与参数描述）往往比用户输入还长，且在会话内完全不变。

举个直观的例子：一个携带 8000 Token 系统提示与工具定义的 Agent，单次问答新增输入仅 500 Token，但每次请求都要为那 8000 Token 付全价。调用 100 次，重复支付的输入费占比超过九成——这才是账单失控的真正原因。

二、上下文缓存：让重复 Token 只付一次全价

上下文缓存（也常被称作前缀缓存、Prompt Caching）的思路并不复杂：服务端把请求前缀的中间计算状态（KV Cache）保留一段时间，后续请求若前缀完全一致，就直接复用，无需重新计算。

理解这项技术有三个关键点：

1. 缓存以“前缀”为单位：要求两次请求的开头部分逐字一致，一旦前缀中某个字符变化，后面的内容就无法命中；
2. 折扣来自省掉的推理计算：命中后服务端跳过大量预填充计算，因此有底气给出极低的命中单价；
3. 它是服务端能力，客户端只需“组织好提示词”：不需要复杂的接入改造，成本主要在设计层面的调整。

目前国内外主流大模型服务平台——包括百度智能云在内——普遍已提供此类上下文缓存能力，虽然命名和细节各异，但核心机制大同小异。

三、看懂账单：响应里的缓存计量字段

开启缓存后，接口返回的用量信息中会多出两个关键计量字段（不同平台命名略有差异，以官方文档为准）：

{
  "usage": {
    "input_tokens": 12500,
    "output_tokens": 380,
    "cache_write_tokens": 10000,
    "cache_read_tokens": 8600
  }
}

• cache_write_tokens：本次新写入缓存的 Token 数，按“原价 + 写入费”结算；
• cache_read_tokens：本次从缓存读取（命中）的 Token 数，按折扣价结算；
• 实际输入 Token = 命中部分 + 新写入部分 + 完全未参与缓存的剩余部分。

这两个字段的价值在于信息透明：你可以精确核算每次调用的真实成本，而不是只看到一个笼统的总价。更重要的是，它们构成了缓存优化的核心观测指标——如果长期 cache_read_tokens 为 0，说明提示词结构有问题，缓存形同虚设。

四、计费三要素：写入费、命中折扣、有效期

以业内折扣力度较大的典型计费方案为例，缓存费用由三个参数决定：

1. 命中折扣：缓存命中的部分按原价的约 10% 计费，属于目前业内最激进的一档折扣；
2. 写入费：首次创建缓存需额外支付约 25% 的费用，本质是为服务端保存计算状态支付的“存储与载入”成本；
3. 有效期：缓存通常只保留约 5 分钟，过期即失效，下次调用需重新支付写入费。命中后是否自动续期、能否主动刷新，各平台策略不同，设计任务前务必查证。

三者的经济学含义可以概括为：

• 写入费是一次性摊销成本：同一前缀的调用次数越多，25% 的溢价被摊得越薄；
• 5 分钟有效期决定了“时间窗口”：只有高频、密集的调用才能真正吃到折扣；
• 折扣幅度决定了收益上限：命中价为一折，意味着长前缀场景下的理论节省空间接近九成。

五、成本测算：什么时候真的能省到九成

设缓存前缀 Token 数为 C，每次新增 Token 数为 D，窗口内调用 N 次，命中单价 r=0.1，写入系数 w=1.25，则：

• 无缓存成本 = N × (C + D)
• 有缓存成本 = C × w + D + (N−1) × (C × r + D)

案例一（高收益）：C=50000，D=500，N=100：

• 无缓存：100 × 50500 = 5,050,000 Token 等效费用
• 有缓存：62500 + 500 + 99 × 5500 = 607,500 Token 等效费用
• 节省约 88%，接近“省九成”的量级。

案例二（反例）：若每次调用间隔都超过有效期，缓存反复失效重建，成本变为 N × (C × 1.25 + D)。此时每轮都在白付 25% 的写入费，比完全不用缓存还贵。

结论很清晰：前缀越长、新增越少、调用越密集，缓存收益越高；反之，短前缀加低频调用是缓存的最差适用区。

六、最适合开启缓存的四类场景

1. 多轮对话：历史消息天然构成逐轮增长的前缀。把历史按原始顺序放在提示词前部、新输入追加在末尾，命中率随轮次自然提升；
2. 长系统提示词：角色设定、输出格式要求、示例代码等在多轮内保持不变，是性价比最高的缓存对象；
3. RAG 与知识库问答：同一批检索文档被多次追问时，将其作为固定前缀，命中部分几乎不再产生有效成本；
4. Agent 与批量任务：工具定义在会话内稳定不变；批量处理同一份长文档的不同问题时，更是缓存的“教科书场景”。

七、这些情况下缓存反而不划算

• 调用频率低：间隔超过有效期，写入费反复打水漂；
• 前缀每次都变：在前缀中拼接时间戳、随机 ID、用户个性化信息，哪怕一个字符的差异都会导致未命中；
• 上下文很短：节省的绝对金额太小，引入结构约束得不偿失；
• 提示词高频迭代：调试阶段改一版全部重建，写入费远超收益。

八、工程实践：把命中率变成可度量的指标

[静态前缀 · 可被缓存]
系统角色设定……
工具定义……
知识库文档……
[动态后缀 · 每次变化]
当前用户输入……

具体建议：

1. 提示词分层设计：静态层（系统提示、工具定义、文档）→ 半静态层（会话历史）→ 动态层（当前输入），严格保证静态层在前且逐字节稳定；
2. 易变内容一律后置：时间、随机数、个性化数据放到提示词末尾；
3. 建立监控看板：跟踪缓存命中率（cache_read_tokens / input_tokens）与实际平均输入单价，用数据验证优化效果；
4. 调用侧时间聚合：把共享同一前缀的请求在时间上凑近执行（如批量任务并发跑），让它们落在同一个有效期内；
5. 组合其他降本手段：小模型分流、控制输出长度、批处理接口等，与缓存叠加使用效果更佳。

九、结语

上下文缓存本质上是一场“用确定性的提示词结构，换取数量级的成本下降”的工程交易。它不改变模型能力，不增加接口复杂度，只需要开发者重新审视提示词的组织方式：把不变的放前面，把变化的放后面，把调用凑进时间窗口，再用用量字段持续校准。对于长上下文、高频调用的应用而言，这是当前投入产出比最高的降本手段之一——读懂那两个缓存计量字段，你的账单大概率会有一次肉眼可见的跳水。