一句话定义：缓存读写计价（Cache Read/Write Pricing）是指在使用提示缓存（prompt caching）时，服务商把“把内容写进缓存”和“从缓存里读出来”拆成两个独立的计费项，各按各的单价收费，只有命中缓存的部分才享受折扣。
先打个比方。写字楼下的智能寄存柜：第一次把一箱资料存进去，要付一次“存件费”；之后每次来取，只付一笔很便宜的“取件费”。但柜子有租期（TTL，time to live），到期自动清空，下次要用得重新存、重新交存件费。提示缓存就是这个柜子，写入（cache write）对应存件，读取（cache read）对应取件，没命中就是老老实实按普通输入价付钱。
为什么容易算错？因为直觉上“缓存=省钱”，但实际账单里同时出现三个科目：
| 计费项 | 什么时候产生 | 相对单价 | 备注 |
|---|---|---|---|
| 普通输入（input） | 每次请求中未被缓存覆盖的部分 | 基准 | 未命中即按此计 |
| 缓存写入（cache write） | 首次发送长提示词、或缓存过期后重建 | 通常不低于普通输入，部分服务商会加价 | 只发生一次或每次过期后 |
| 缓存读取（cache read） | 后续请求命中相同前缀 | 通常明显低于普通输入 | 折扣一般只作用于输入侧 |
（具体倍率和有效期以各家官方定价页面为准，差异不小。）
三个常见误区：一是“只调用一次”的任务也开缓存，写了一次却永远读不到，白交写入费；二是调用间隔比缓存有效期还长，每次都重建，等于只有写没有读；三是只盯着“命中率”看，忽略了写入成本可能更高。另外要记住，缓存通常只作用于输入，输出侧不参与。还有一个技术细节：只有前缀完全一致才命中，AI 词典：系统提示词">系统提示词前面多改一个字、多插一个空格，就可能全盘落空。
给从业者的实用算法很简单：总成本 ≈ 写入次数 × 写价 + 命中次数 × 读价 + 未命中 token × 普通输入价。别问“命中一次省多少”，要问“写进去之后被读了几次”——这个比值低于 2 左右，基本就没占到便宜。所以缓存最适合的场景是长系统提示词、固定的大段参考资料、连续多轮对话这类“前缀稳定、调用密集”的活；短提示、一次性任务、隔很久才调一次的，老老实实不开缓存反而更省。上线后盯住两个数：写入 token 量和读取 token 量，比例不对劲就说明缓存策略该调了。