04 提示缓存三断点策略与成本数学


文档摘要

04 提示缓存三断点策略与成本数学 本节摘要:前面三节讲了怎么调、怎么解析。这一节讲一个省钱的关键优化——提示缓存(Prompt Caching)。OpenCode 默认开启提示缓存,用「三断点策略」把稳定前缀缓存起来,让长会话的重复读取成本降到十分之一。本节讲清三断点放在哪、为什么放在那、以及用「1.25× 写入、0.1× 读取」的成本数学论证为什么这笔账非常划算。 一、问题:长会话的重复读取成本 考虑一次长会话:你问了 20 轮,每轮都要把「系统提示 + 历史 + 工具描述」发给模型。其中系统提示和工具描述几乎不变,历史是单调增长。这意味着大量内容被反复发送、反复被模型读取。 如果不缓存,每轮都按全价付读取成本。

04 提示缓存三断点策略与成本数学

本节摘要:前面三节讲了怎么调、怎么解析。这一节讲一个省钱的关键优化——提示缓存(Prompt Caching)。OpenCode 默认开启提示缓存,用「三断点策略」把稳定前缀缓存起来,让长会话的重复读取成本降到十分之一。本节讲清三断点放在哪、为什么放在那、以及用「1.25× 写入、0.1× 读取」的成本数学论证为什么这笔账非常划算。

一、问题:长会话的重复读取成本

考虑一次长会话:你问了 20 轮,每轮都要把「系统提示 + 历史 + 工具描述」发给模型。其中系统提示和工具描述几乎不变,历史是单调增长。这意味着大量内容被反复发送、反复被模型读取

如果不缓存,每轮都按全价付读取成本。长会话的 token 账单会非常惊人——大部分钱花在「反复读同一坨稳定内容」上。

二、提示缓存:稳定前缀只算一次写入,后续读取极便宜

提示缓存的原理是:把稳定的前缀缓存起来,写入时付一点溢价,但后续每次读取只付极低费用

第 1 轮:写入缓存(付溢价) ──► 后续前缀被缓存 第 2 轮:读取缓存(极便宜) + 写入新增部分 第 3 轮:读取缓存(极便宜) + 写入新增部分 ...

这里的成本数学(以某厂商典型定价为例):

操作 相对成本
普通读取(不缓存)
缓存写入(首次) 约 1.25×
缓存读取(命中) 约 0.1×

也就是说:缓存写入比普通读取贵 25%(1.25×),但缓存命中后读取只要十分之一(0.1×)。只要同一份前缀被读取超过一两次,缓存就开始净赚

三、OpenCode 的三断点策略

知道了缓存划算,问题是「缓存什么」。不能什么都缓存(缓存有上限、有成本),得挑稳定且会被反复读的前缀。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 章的呼应

本节和第 8 章 System Context 是一对好朋友:

  • 第 8 章 Epoch 保证「基准(System Context)」在纪元内冻结 → 前缀稳定
  • 本节提示缓存 利用这个稳定前缀 → 缓存命中,省钱

没有 Epoch 的冻结,缓存会频繁失效,三断点策略就白搭。没有提示缓存,Epoch 的冻结就只是「正确但不省钱」。两者协作,才让长会话既正确又经济。

本节要点回顾

  1. 问题:长会话里大量稳定内容被反复读取,不缓存会很贵。
  2. 提示缓存:稳定前缀付一次写入溢价(1.25×),后续读取极便宜(0.1×)。
  3. 三断点策略:放在「最后工具定义后」「最后系统消息后」「最新用户消息前」——都是稳定前缀边界。
  4. 成本数学:10 轮对话示例,缓存省约 78%;会话越长省越多。
  5. 厂商实现各异:Anthropic 用 cache_control、Bedrock 用 cachePoint、OpenAI/Gemini 隐式。
  6. 与 Epoch 协作:Epoch 冻结基准保稳定,缓存利用稳定省钱——缺一不可。

缓存讲完了,但抽象总有覆盖不到的厂商特性。下一节讲「三档逃生口」——当抽象不够用时怎么兜底。


发布者: 作者: 灏天文库 转发
评论区 (0)
U