A
成本 / COST
以更低的成本读取相同输入。
代表性示例：缓存命中输入单价为普通输入的 10%
FIELD GUIDE · 2026.08
REQUEST / 0042LIVE
01工具定义固定
02系统指令固定
03参考文档固定
CACHE BOUNDARY
04本次问题变更
05最新结果变更
开头保持不变，只在后面添加新信息。
缓存读取单价代表性示例 90%↓*
研究中的 TTFT 最大改善31%↓†
核心原则前缀固定，尾部变化
* GPT-5.6、Claude 和 Gemini 官方价格中的代表性示例 · † 500 个智能体会话 arXiv 研究的最大值；部分策略没有改善，甚至更慢
01
原理 / THE MECHANISM
AI 并不是记住答案，
而是复用相同前缀的计算结果。
提示词与上下文缓存并不是记住答案本身。在模型回答前的预填充阶段，供应商会复用匹配前缀的计算结果。缓存有效时，只需读取新添加的尾部。
01预填充
读取完整输入并生成内部计算结果。
02缓存复用
跳过相同前缀的重复计算。
03解码
逐个 token 生成回答。
关键
缓存主要减少输入预填充。输出 token 成本与生成速度是另一回事。
INTERACTIVE LAB 01
亲自试着打破缓存。
改动位置不同，可复用的区间也不同。
SIMULATION理想流程: 3/5
01工具定义HIT
02系统指令HIT
03参考文档HIT
04本次问题NEW
05最新结果NEW
前面的 3 个区块会原样复用。
在典型的前缀缓存中，改动位置之后可复用的范围会缩小。
02
效果 / WHY IT MATTERS
成本、速度、吞吐量。一次缓存命中会同时改变这三项。
缓存条件和收益因供应商及模型而异。下方的 90% 是代表性输入价格，并不表示整个请求的成本降幅。
90%↓
B
速度 / SPEED
跳过冗长预填充，更快获得首个 token。
效果会因前缀长度和基础设施而异
C
吞吐量 / THROUGHPUT
用相同预算和时间完成更多工作。
Claude API 在多数模型中不将缓存读取 token 计入 ITPM
INTERACTIVE LAB 02
只看命中率，只看到了问题的一半。
此简化模型将缓存读取单价设为普通输入的 10%。不包含写入、存储（TTL）和输出成本。
RESULT / PER TURN
56K
按全价 token 折算的每轮有效输入负担
输入成本指数28 / 100
近似节省率72%
98% HIT900K × 0.118 = 106.2K
VS
70% HIT50K × 0.37 = 18.5K
即使命中率更高，如果上下文过大，有效负担仍约重 5.7 倍。
CASE
我们的 Orca 使用记录
ORCA HQ · 2026.07.20—07.27 · LOCAL USAGE LOG
我们从自己的使用记录中找到了让缓存生效的模式。
我们分析了 Orca 本地汇总的 207 个可直接确认路径的 HQ 会话。下方 token 数为供应商响应中 usage 字段的合计；没有账单记录，因此未估算成本。
- 观测周期日志测量
- 8 天 7 月 20—27 日
- Orca 会话日志测量
- 207 直接确认 HQ 路径
- 已记录响应日志测量
- 12,554 含 usage 数据
- 使用模型日志测量
- 8 Claude、GLM、DeepSeek
WHAT THE LOG SHOWS
缓存读取在全部输入相关 token 中所占的比例
总计 22.01 亿 token 中，21.61 亿为 cache read，3,882 万为 cache write，79.9 万为新输入。
日志测量cache read ÷ (read + write + fresh input)
缓存读取日志测量
21.61亿98.20%缓存写入日志测量
3,882万1.76%新输入日志测量
79.9万0.04%每轮平均17.2 万 cache-read tokens
复用率高，但绝对上下文仍很大
THREE REAL RUNS
约一小时的集中运行中，数百个响应都记录到了缓存读取。
三次均为使用 Claude Opus 5 的 Orca 基准测试，日志合计经过四舍五入。
01 · 运营文档审查OPSREV3
615轮
- 运行时间
- 57 分钟
- 缓存读取
- 1.371亿
- 缓存写入
- 29.8万
- 读取比例
- 99.78%
观察：读取量约为写入量的 460 倍。
02 · 场景审查SCENAREV
486轮
- 运行时间
- 49 分钟
- 缓存读取
- 1.102亿
- 缓存写入
- 29.2万
- 读取比例
- 99.73%
观察：大多数输入相关 token 得到了复用。
03 · 长篇摘要审查LONGSUM4
425轮
- 运行时间
- 48 分钟
- 缓存读取
- 1.005亿
- 缓存写入
- 26.4万
- 读取比例
- 99.74%
观察：长篇任务也显示出很高的复用比例。
我们确认的关键点
三次运行都在短时间内于同一会话中连续处理目标相同的任务。
注意：这是强相关性模式，并未直接分类每次缓存写入的原因。03
实践 / THE PLAYBOOK
冻结开头，只改变尾部。
缓存优化关乎你如何开始、延续和整理会话。
开始前先确定固定内容。
- 整理长期规则和参考资料
- 确定模型、MCP 和工具配置
- 每个线程只处理一项任务
进行中只添加变更内容。
- 将本次问题和最新结果放在后面
- 将大图片和日志外置为文件
- 尽可能连续执行同一任务
上下文变重时果断整理。
- 同一任务压缩上下文
- 任务变化时新建线程
- 同时检查命中率和绝对 token 数
通用聊天机器人 / PRESCRIPTION
每个主题单独建线程，资料只提供一次
- 01
开始时一次性整理项目说明和资料。
- 02
同一任务在同一线程中继续。
- 03
长文档只说明改动。
CACHE & CONTEXT HABITS
这些习惯会损害复用效果和上下文效率。
- ×在系统指令中加入动态值
- ×频繁更改工具列表或顺序
- ×反复修改并重新粘贴同一文档
- ×不断堆积图片和原始日志
- ×在同一线程中混合不同任务
WHAT TO MEASURE
同时关注比例和绝对量。
01缓存读取 / 写入
是否真的发生了命中？
02每轮总输入
会话是否过重？
03每项任务成本
获得一个结果要花多少？
04TTFT
首个 token 是否更快到达？
你自己工作负载的基线和趋势比通用理想命中率更重要。
04
GPT 观点 / A MODEL'S TAKE
缓存优化不是提示词技巧，而是信息架构设计。
命中率是有用指标，但 100% 并不是目标。稳定复用不变的事实，只读取当下需要的新信息。
OPTIMIZE IN THIS ORDER
- 01移除不必要的上下文
- 02固定稳定信息
- 03按任务拆分线程
- 04测量命中率
如果缓存与时效性或准确性冲突，应优先选择准确性。
05
会话前 30 秒检查
YOUR NEXT SESSION
开始前，只需确认六件事。
0 / 6
每完成一项检查，会话就更轻量。
ONE LINE TO REMEMBER
良好的缓存使用 =
前缀稳定性 × 上下文规模管理 × 工作节奏
这些数值和公式如何计算？
近似节省率 = 命中率 ×（1 − 缓存读取单价 / 普通输入单价）。读取单价为 10%、命中率为 80% 时，输入成本约降低 72%。
缓存在所有 AI 中都一样吗？
不一样。TTL、最小长度、折扣率和 usage 字段因供应商及模型而异。
一直使用同一个聊天就一定会命中吗？
不能保证。结果受供应商政策、TTL 和内部上下文管理影响。
用于事实核查的一手来源
我们对照核查了截至 2026 年 8 月 13 日的官方文档和原始研究，并重新汇总了本地 Orca usage 日志。