缓存命中，到底省了什么

同一份长资料，发给模型三次

同一份很长的资料，第一次发给模型，要等 1081 毫秒，它才开口。原封不动再发一次，只要 42 毫秒。可是只把开头的时间改了一秒，又变回了 1069 毫秒。中间省下的这一大截，就是缓存。这期就来看看，它到底省了什么。

今天用本地小模型和云端的 Claude，实测缓存到底省了什么。

打个比方：读一份长合同，边读边记笔记

先打个比方。模型读你的输入，就像你读一份很长的合同，边读边记笔记。读到第十页时记的笔记，是带着前九页的理解记下的。读完了，笔记先留着；下次同一份合同再来，直接翻笔记，不用从头再读。模型也一样：它把读输入时算出来的中间结果存下来，这就叫提示词缓存，英文是 Prompt Caching。

规矩：每一页的笔记，都离不开前面所有的页

这份笔记有个规矩：每一页的笔记，都离不开前面所有的页。所以第一页哪怕只改一个字，从它开始，每一页的笔记都得作废重记。要是只改了最后一页，前面九页的笔记照样能用，只要重读这一页。所以缓存只认一样东西：从开头算起，完全相同的那一段，叫作前缀。

实验：一份差旅报销制度，加一个员工提问

来做个实验。资料是一份差旅报销制度，连同员工的问题，一共 1807 个 token。开头一行写着当前时间，中间是固定不变的报销规则和各城市标准，结尾是员工的问题。同样的资料，我们发四种请求：第一次发，原样再发，只换最后的问题，只改开头的时间。

本地实测：Qwen3 1.7B 的首字时间

先在笔记本上，用 Qwen3 1.7B 来测，看首字时间：从发出请求，到第一个字出来。第一次发，模型从头读完，要 1081 毫秒。原样再发，整段命中缓存，只要 42 毫秒。只换最后的问题，前面全部命中，56 毫秒。只把开头的时间改一秒，后面一个字没动，缓存却全部作废：1069 毫秒，又从头读了一遍。

云端实测：Claude Sonnet 5 的账单

本地看的是时间；换到云端的 Claude Sonnet 5，看的是账单。它每次回答，都会附上三个数：这次写进缓存多少 token，从缓存读了多少，还有多少没走缓存，按原价算。第一次发，时间和制度这一段，2465 个 token 写进了缓存；结尾问题这部分，26 个，按原价算。原样再发 5 次，5 次都从缓存读了 2465 个。只换最后的问题，照样读了 2465 个，新问题的 18 个按原价算。只改开头的时间，读到的是 0，2465 个又写了一遍。

缓存存的是笔记，不是答案

注意，缓存存的是读输入时的笔记，不是答案。刚才原样再发的 5 次，每次都命中了缓存，可回答都是重新写的，措辞各不一样。所以输出的 token，一个也省不了，照样按原价算。

能省多少钱：Claude Sonnet 5 的价格

能省多少钱？以 Claude Sonnet 5 为例，正常输入，每一百万个 token 2 美元；写缓存贵四分之一，2.5 美元；读缓存只要十分之一，0.2 美元。同样一段内容连发十次：不用缓存，就是十份原价；用缓存，第一次 1.25 份，后面九次各 0.1 份，加起来 2.15 份，不到原来的四分之一。所以只要命中一次，写缓存多付的那四分之一，就赚回来了。

还有两种情况，缓存也用不上

还有两种情况，缓存也用不上。第一种，换模型：同样的内容，发给 Claude Opus 5，读到 0，从头写了 2465 个。紧接着再发回 Sonnet 5，又读到了 2465 个。可见 Sonnet 的缓存还在，只是 Opus 用不了：不同模型算出的中间结果不一样，缓存不共用。第二种，隔太久：官方说缓存默认保存五分钟，每命中一次，重新计时。我们等了六分钟再发，读到 0，又从头写了一遍。

缓存命中，到底省了什么

总结一下，缓存命中，到底省了什么。省了时间：不用重读前缀，首字时间变短；省了钱：在 Sonnet 5 上，读缓存只按十分之一算；但输出没省：回答还是一个 token 一个 token 地生成，照原价算。

想让缓存多命中，记住四件事

想让缓存多命中，记住四件事。不变的内容放前面，会变的放后面；时间、随机编号这种每次都变的东西，别放在开头；同一段对话，别中途换模型；两次请求别隔太久，Claude 默认五分钟就过期。

今天我们看了缓存命中省了什么：省的是重读前缀的时间，和钱。下一期聊工具调用：模型自己，其实不执行工具。