别的账都算过了，就「上下文缓存」这块钱我一直漏算

我算账算得挺细的。订阅退了、按量付费用上了、贵模型只在需要时才开、每月账单拉出来逐项过——这些我都做过，也写过。

直到上个月翻服务商的计费文档，看到一行小字：「命中缓存的输入 token 按标准价的 10%–20% 计费。」

我愣了一下：这个，我好像一直没用上。

一、我的场景：一个每天问 40 次的「私人助理」

我自己写了一个小工具，挂在电脑上，日常用来：

• 把我随手记的想法整理成待办；

• 帮我回工作消息，按我的口吻；

• 查我自己的笔记库。

这个工具每次请求都会带一段很长的系统提示：我的写作风格说明、常用术语表、几十条「别这样回」的反例、待办的格式要求。一共 4,800 token。

而我每次真正的提问，平均只有 300 token。

也就是说，每次请求里 94% 的输入，都是同一段一字不改的话。

二、九月的账单长这样

项目数量每天请求约 40 次每次输入5,100 token（4,800 系统提示 + 300 提问）每次输出约 400 token月输入总量约 612 万 token月输出总量约 48 万 token九月费用输入 24.5 元 + 输出 3.8 元 = 28.3 元

28 块一个月，单看不算多。但我拆开一看：输入那 24.5 元里，系统提示占了 23 元。

我每个月花 23 块，让模型把同一段话读了 1,200 遍。

三、缓存是怎么省钱的

简单说：如果你连续多次请求的开头部分完全一样，服务商可以把这部分的计算结果存起来，下次直接复用，于是这部分按很低的价格收费。

几个要点（各家规则不同，以文档为准）：

1. 必须是开头部分一样。系统提示放最前面，提问放后面。顺序反了就命中不了。

2. 一个字都不能改。我原来的系统提示里有一行「今天是 X 月 X 日」，每天变一次，每天第一次请求都命中不了。后来把日期挪到了提问部分。

3. 有过期时间。一般是几分钟到一小时不等，长时间不用会失效。我的请求比较分散，命中率不是 100%。

4. 有的要手动开，有的自动。我用的模型是自动的，只要格式对就生效。

图 1　九月 vs 十月：月账单构成

四、改完之后的十月账单

我只做了两件事：把日期从系统提示挪到提问里；确认系统提示放在 messages 的第一条。

项目九月十月请求次数约 1,200约 1,240系统提示缓存命中率0%78%输入费用24.5 元9.6 元输出费用3.8 元3.9 元合计28.3 元13.5 元

同样的用法，账单从 28.3 降到 13.5，少了 52%。

命中率只有 78% 是因为我经常隔一两个小时才用一次，缓存过期了。如果是高频场景，比如客服、批量处理，命中率会高得多。

五、哪些人最该去查一下

系统提示很长的。写了大段「人设」「规则」「示例」的，基本都适合。

固定资料反复问的。比如把一份产品手册、一份合同放在前面，然后问很多个问题。资料越长，省得越多。

多步任务、Agent 类工具。每一步都要把工具定义和前面的上下文重新带一遍，那一大段前缀非常适合缓存。

反过来，不太适合的：每次请求内容都不一样的、提示很短的、一天只用几次的。省不了几个钱，不值得折腾。

六、怎么确认自己有没有用上

最简单的办法：看接口返回的 usage 字段。支持缓存的模型，一般会多一个类似 cached_tokens 的字段，告诉你这次有多少 token 命中了缓存。

我是在用的 API 平台后台看的，那里每次请求的明细都有这一列（我用的是词元云，https://tokenfreeai.com，换别家一样能在明细里找到，字段名可能不同）。九月那一列全是 0，我才意识到这事。

七、写在最后

这一项省的钱不多，一个月 15 块。但它让我意识到一件事：我之前所有的省钱思路，都在「少用」和「用便宜的」上，从来没想过「同样的东西别重复付钱」。

你的账单里可能也有这么一块。花五分钟看看 usage 里的那个字段，是不是一直是 0。