04 提示缓存三断点策略与成本数学 本节摘要:前面三节讲了怎么调、怎么解析。这一节讲一个省钱的关键优化——提示缓存(Prompt Caching)。OpenCode 默认开启提示缓存,用「三断点策略」把稳定前缀缓存起来,让长会话的重复读取成本降到十分之一。本节讲清三断点放在哪、为什么放在那、以及用「1.25× 写入、0.1× 读取」的成本数学论证为什么这笔账非常划算。 一、问题:长会话的重复读取成本 考虑一次长会话:你问了 20 轮,每轮都要把「系统提示 + 历史 + 工具描述」发给模型。其中系统提示和工具描述几乎不变,历史是单调增长。这意味着大量内容被反复发送、反复被模型读取。 如果不缓存,每轮都按全价付读取成本。
本节摘要:前面三节讲了怎么调、怎么解析。这一节讲一个省钱的关键优化——提示缓存(Prompt Caching)。OpenCode 默认开启提示缓存,用「三断点策略」把稳定前缀缓存起来,让长会话的重复读取成本降到十分之一。本节讲清三断点放在哪、为什么放在那、以及用「1.25× 写入、0.1× 读取」的成本数学论证为什么这笔账非常划算。
考虑一次长会话:你问了 20 轮,每轮都要把「系统提示 + 历史 + 工具描述」发给模型。其中系统提示和工具描述几乎不变,历史是单调增长。这意味着大量内容被反复发送、反复被模型读取。
如果不缓存,每轮都按全价付读取成本。长会话的 token 账单会非常惊人——大部分钱花在「反复读同一坨稳定内容」上。
提示缓存的原理是:把稳定的前缀缓存起来,写入时付一点溢价,但后续每次读取只付极低费用。
第 1 轮:写入缓存(付溢价) ──► 后续前缀被缓存 第 2 轮:读取缓存(极便宜) + 写入新增部分 第 3 轮:读取缓存(极便宜) + 写入新增部分 ...
这里的成本数学(以某厂商典型定价为例):
| 操作 | 相对成本 |
|---|---|
| 普通读取(不缓存) | 1× |
| 缓存写入(首次) | 约 1.25× |
| 缓存读取(命中) | 约 0.1× |
也就是说:缓存写入比普通读取贵 25%(1.25×),但缓存命中后读取只要十分之一(0.1×)。只要同一份前缀被读取超过一两次,缓存就开始净赚。
知道了缓存划算,问题是「缓存什么」。不能什么都缓存(缓存有上限、有成本),得挑稳定且会被反复读的前缀。OpenCode 的策略是放三个断点:
[系统提示 + 工具描述] ──断点1──► [历史的一部分] ──断点2──► [更多历史] ──断点3──► [最新用户消息]
三个断点大致放在:
| 断点 | 位置 | 为什么放这 |
|---|---|---|
| 断点 1 | 最后一个工具定义之后 | 工具描述稳定,之后的系统部分会被反复读 |
| 断点 2 | 最后一条系统消息 | 系统消息稳定,历史从这之后增长 |
| 断点 3 | 最新用户消息之前 | 已有历史稳定,只有新消息在变 |
💡 为什么是这三个位置:它们都是「稳定前缀的边界」——边界之前的内容在多轮对话里基本不变,所以值得缓存;边界之后的内容会变(新消息、新工具结果),缓存了也会立刻失效,不划算。
走一遍具体账本,感受这笔交易有多划算。假设系统提示 + 工具描述 = 10000 token,你在一次会话里问了 10 轮:
不缓存(每轮全价读):
10 轮 × 10000 token × 1× = 100000 单位成本
缓存(第 1 轮写入,后 9 轮命中):
第 1 轮:10000 × 1.25× = 12500(写入) 第 2~10 轮:9 × 10000 × 0.1× = 9000(命中读取) 合计:21500 单位成本
节省:100000 → 21500,省了约 78%。而且会话越长、稳定前缀越大,省得越多。这就是为什么 OpenCode 默认开启提示缓存——这是一笔几乎稳赚的账。
提示缓存是「抽象层定义策略,各厂商各自实现」的典型例子。OpenCode 的三断点策略是抽象的,落到不同厂商有不同的物理实现:
| 厂商类型 | 物理实现 |
|---|---|
| Anthropic | 在消息里加 cache_control 标记 |
| Bedrock | 用 cachePoint |
| OpenAI / Gemini | 隐式缓存(厂商自动识别稳定前缀) |
注意 OpenAI 和 Gemini 是「隐式」的——你不显式标记,厂商自动缓存。OpenCode 的三断点策略对它们来说「自动命中」,对 Anthropic 和 Bedrock 则通过显式标记精确控制。
⚠️ 缓存命中的前提:前缀必须逐字稳定。这就是为什么第 8 章的「基准(System Context baseline)」强调纪元内冻结——基准变了,缓存就失效。提示缓存和 Context Epoch 是紧密配合的:Epoch 保证基准稳定,缓存才能命中。
本节和第 8 章 System Context 是一对好朋友:
没有 Epoch 的冻结,缓存会频繁失效,三断点策略就白搭。没有提示缓存,Epoch 的冻结就只是「正确但不省钱」。两者协作,才让长会话既正确又经济。
缓存讲完了,但抽象总有覆盖不到的厂商特性。下一节讲「三档逃生口」——当抽象不够用时怎么兜底。