提示缓存（Prompt Caching）是一种技术：模型把 prompt 中重复出现的那部分已经算过的工作保存下来，下次直接复用这份保存的结果，而不必从头再算一遍。
本文我们来讲清楚提示缓存是怎么工作的。我们还会看到为什么需要它、它在大语言模型内部究竟如何运转，以及它在 AI 助手和智能体这类真实系统中用在哪些地方。
我们将覆盖以下内容：
- 什么是 prompt？
- 快速回顾：LLM 是如何读 prompt 的
- 什么是提示缓存？
- 为什么我们需要提示缓存
- 提示缓存的核心思路
- 精确前缀规则
- 缓存写入与缓存读取，以及 TTL
- 我们应该把什么放进缓存
- 提示缓存带来的好处
- 真实世界中的提示缓存
什么是 prompt？
在讲提示缓存之前，我们必须先搞明白 prompt 是什么。
prompt 就是我们发给大语言模型的那段文本。
大语言模型（large language model，简称 LLM）是 ChatGPT、Claude 这类工具背后的技术。我们给它一些文本，它还我们一些文本。
简单说，prompt 就是我们敲进去的所有内容。模型读了我们的 prompt，然后写出回复。
假设我们在做一个客服助手。发给模型的文本通常包含几个部分：
- 一组指令，告诉模型该怎么表现，比如「你是一家鞋店的礼貌客服」。
- 可能还有一份很长的文档，写着我们全部的鞋子退货政策。
- 用户真正提的问题，比如「鞋子买了 40 天还能退吗？」
这些文本合在一起，就是 prompt。
现在有一点很值得注意：指令和那份政策文档，对每个用户都是不变的。只有用户的问题在变。我们很快会回到这一点，因为它是提示缓存的核心。
快速回顾：LLM 是如何读 prompt 的
要理解提示缓存，我们必须先理解 LLM 读 prompt 时的一件事。
我们发出 prompt 时，模型并不是按整词来读的。它先把文本切成小块，这些小块叫 token。token 是一小段文本，大致是一个词或词的一部分。比如support这样的短词通常是一个 token，而returning这样的长词往往会被切成两个 token（这套切分方式叫字节对编码，Byte Pair Encoding，BPE）。
于是，prompt 变成了一串 token。
接着，模型逐个处理这些 token，为每个 token 建立起内部理解。这第一步——模型读完整段 prompt、把每个 token 都处理一遍，之后才开始写回复的第一个词——叫做预填充（prefill）步骤。
简单说，预填充就是模型把我们的整段 prompt 读进去、消化掉。
在预填充过程中，对每一个 token，模型都会算出一些内部数值并保存起来。这些被保存的数值放在所谓的 KV 缓存（KV Cache）里。
用大白话说说 KV 缓存。模型读每个 token 时，会为这个 token 生成一份小摘要——相当于一条笔记，记下这个 token 在它前面所有内容的语境里意味着什么。KV 缓存就是这一堆笔记的集合，每个 token 对应一组笔记。模型写回复需要这些笔记，并且在生成每一个新词时也会复用它们。
这里有一个关键点要记住：
为一段很长的 prompt 构建 KV 缓存是要花真功夫的。模型必须逐个 token 做大量计算。
所以，如果我们的 prompt 有 5,000 个 token，模型就要在写下任何东西之前，为这 5,000 个 token 全部做完这些工作。prompt 越长，预填充这一步花的时间和钱就越多。
这就是我们需要的铺垫。现在可以来理解问题了。
什么是提示缓存？
既然知道了模型如何读 prompt，我们来看看提示缓存。
提示缓存是一种技术：模型把 prompt 中重复出现的那部分已经算过的工作保存下来，下次直接复用这份保存的结果，而不必从头再算一遍。
简单说，提示缓存就是：难的活只干一次，然后反复复用。
「缓存（cache）」这个词的意思很简单——一个存放东西的地方，方便我们之后快速取用，而不必从零再做一遍。
把它和我们刚学的连起来看：模型干的「难活」就是在预填充阶段构建 KV 缓存。提示缓存所做的，就是把 prompt 中重复那部分的 KV 缓存保存下来。下次我们发来的 prompt 开头是同一段重复内容时，模型就载入保存好的 KV 缓存，跳过重复计算。
所以，提示缓存的核心是复用 prompt 重复开头部分的内部计算结果。
这和语义缓存（semantic caching）不同：语义缓存是在新问题和旧问题意思相同（哪怕用词不同）时，直接复用最终答案。
那么问题来了，我们到底为什么需要它？接着看。
为什么我们需要提示缓存
回到我们的鞋店客服助手。
每个用户都会发来一个问题。但别忘了，每来一个问题，我们同时还会带上同样的指令和同样那份很长的退货政策文档。用户的问题很短，指令和文档却很长。
于是，模型为每个用户、每条消息，一遍又一遍地读同样的长指令和同样的长文档。
为了便于理解，我们给点数字。假设：
- 指令和政策文档共 5,000 个 token。
- 用户的问题有 50 个 token。
用户每问一次，模型就要对 5,050 个 token 做预填充。其中 5,000 个 token 和上一次完全一样，只有 50 个是新内容。
这是浪费。模型在 5,000 个根本没变的 token 上做着大量计算。
这带来两个真实的问题：
- 慢。把 5,000 个 token 一遍遍重新处理，会在用户看到回复之前不断增加延迟。
- 贵。我们是按模型处理了多少 token 来付钱的。每次都重新处理同样的 5,000 个 token，等于为同一份工作一遍遍付费。
在真实应用里，这个问题会大得多。想想那些长系统指令、大文档、以及我们每次请求都要带上的大量示例。我们反复发送同一个大文本块，模型就在反复重做同样的工作。
于是，提示缓存登场救场。
提示缓存的核心思路
我们一步步理解这个核心思路。
我们已经知道，预填充期间模型会构建 KV 缓存，也就是每个 token 对应的那组内部笔记。提示缓存做了一件简单却很有力的事。
思路是：把 prompt 中固定且重复的那部分的 KV 缓存保存下来。下一次请求的开头还是同一段内容时，模型载入保存好的 KV 缓存，从那里接着往下做，跳过重算。
我们用刚才的例子走一遍。
第 1 步：一个用户发来第一个问题。prompt 是 5,000 个 token 的指令加文档，后面跟着 50 个 token 的问题。模型对这 5,050 个 token 做预填充并构建 KV 缓存。在这个过程中，它把前 5,000 个 token 的 KV 缓存保存了下来，因为那部分被我们标记为要缓存。
第 2 步：另一个用户发来一个不同的问题。prompt 还是同样的 5,000 个 token 指令加文档，后面跟着新的 50 个 token 问题。此时，模型不再重做前 5,000 个 token 的工作，而是直接载入它们保存好的 KV 缓存。只有那 50 个 token 的新问题需要做新计算。
就这样，模型直接跳到了缓存部分结束的位置，并从那里继续。它没有在已经理解过的 5,000 个 token 上浪费时间。
下面这张简图把这件事说清楚。
不开提示缓存时（每一次请求）： [ 5,000 个 token：指令 + 文档 ] + [ 50 个 token：问题 ] 全部重新处理一遍 只处理这部分 （慢、贵、重复计算） （真正的新工作） 开启提示缓存后（从第二次请求起）： [ 5,000 个 token：指令 + 文档 ] + [ 50 个 token：问题 ] 从缓存读取（快、便宜） 只处理这部分 跳过这部分的重计算 （真正的新工作）问题解决了。重复那部分的难活，模型现在只干一次。
精确前缀规则
这里有一条非常重要的规则必须理解，因为大多数坑都踩在这儿。
提示缓存是基于前缀匹配的。被缓存的部分必须是 prompt 的开头，而且必须逐字符完全一致。
先说「前缀」这个词。前缀就是某个东西的开头那段。在我们的场景里，被缓存的部分是 prompt 的开头，也就是用户问题之前的那段内容。
只要新 prompt 的开头与已缓存 prompt 的开头完全一致，模型就可以复用缓存。一旦文本出现差异，从那个位置往后的缓存就失效了。
可以这样画出来：
已缓存的 prompt：你是一名礼貌的客服。退货窗口为 30 天。 新的 prompt： 你是一名礼貌的客服。退货窗口为 45 天。 |---------------- 完全一致 ----------------| 从缓存读取 ^ 从这里开始不一致，这一段必须重算这里可以看出，两段 prompt 在某个点之前是一样的，前面这段一致的部分就从缓存读取。而从第一个不一样的 token 起，前缀就不再匹配，后面所有内容模型都必须重算。
有一点我们必须格外小心：
只要 prompt 靠前的位置变了一个字符，那个位置之后的所有缓存全部失效。
举个例子说明。假设我们在指令的最顶部加了一行「今天是 2026-06-07」。这行每天都在变。因为它待在 prompt 的最开头，前缀就每天都不同。于是昨天建好的缓存今天用不了，模型只能把全部工作重做一遍。
这是非常常见的一个错误。我们不小心把会变的东西——比如当前日期、一个随机 ID、或者用户名——放在了 prompt 靠前的位置。就这一个小的变动，悄无声息地把整个缓存毁掉了。
所以要记住的规则很简单：
把稳定的部分放前面，把变化的部分放最后。
prompt 的开头不变，缓存就一直有效。开头一直在变，缓存就毫无用处。别担心，稍后我们会具体看清哪些部分该保持稳定、该放在哪里。
缓存写入与缓存读取，以及 TTL
接下来理解两个简单术语：缓存写入（cache write）和缓存读取（cache read）。
缓存写入发生在第一次。这时模型处理重复的那部分内容，并把它的 KV 缓存保存下来。我们是在第一次把结果写进缓存。
缓存读取发生在其后。这时后续请求复用保存好的 KV 缓存，而不是重新计算。我们是在从缓存里读。
把它和成本连起来看，这才是有意思的地方。
缓存写入比普通处理略贵一点，因为模型既要完成计算，又要把结果存下来。粗略地说，这部分的缓存写入成本大约是正常价格的 1.25 倍。
但缓存读取非常便宜。从缓存读取的成本只有正常价格的大约十分之一。也就是说，重复的那部分能省下差不多 90%。
所以，第一次请求多付一点写入成本，之后每一次请求都因为读缓存而便宜很多。复用次数越多，省得越多。
整个流程大致如下：
请求 1 --> 处理稳定部分 --> 保存下来（缓存写入，约 1.25 倍成本） | v +-------------+ | 缓存 | +-------------+ ^ ^ ^ 请求 2 ---+ | | （缓存读取，约 0.1 倍成本） 请求 3 ---------+ | （缓存读取，约 0.1 倍成本） 请求 4 ---------------+ （缓存读取，约 0.1 倍成本）这里可以看到，只有第一个请求做了重活并把结果写进缓存。之后每一个开头相同的请求，都直接从缓存读取，所以每一次都比从头重做便宜得多。
那么下一个问题：缓存会永久保留吗？答案是不会。
缓存有 TTL，全称 time to live，即存活时间。简单说，TTL 就是缓存能活多久，过了这个时间它就过期并被清除。
常见的默认 TTL 是 5 分钟。也可以选择更长的 TTL，比如 1 小时。TTL 在实际中的含义是：
- 如果 TTL 窗口内又来了一个前缀相同的新请求，它可以读缓存。
- 如果 TTL 窗口内没有请求进来，缓存过期。下一个请求必须重新做一次缓存写入。
所以，当大量请求共享同一个开头、且时间上挨得比较近时，提示缓存的效果最好。
注意：更长的 TTL 能让缓存活得更久，在请求比较分散时有用，但长 TTL 的缓存写入成本会略高一些。所以 TTL 要根据具体场景来选。
我们应该把什么放进缓存
现在我们知道，缓存作用于 prompt 中稳定的开头部分。那么自然要问：究竟该往那里放什么？
答案很简单。把在大量请求中保持不变的部分放前面，把会变的部分放最后。
以下这些非常适合缓存，因为它们通常不变：
- 系统指令。它们描述模型应该如何表现，比如「你是一名礼貌的客服」。这些对每个用户都一样。
- 大文档。比如我们完整的退货政策、产品手册、或知识库中的一篇文章。它们又长又会被重复带上，缓存它们能省很多。
- 工具定义。当我们允许模型使用工具时，需要把每个工具描述给它。这些描述通常是固定的。
- 少样本示例（few-shot examples）。这些是我们给模型的示例问答，让它学会我们想要的风格。「few-shot」的意思就是给模型几个例子作为引导。这些示例每次都一样。
而会变、必须放在最后的那部分是：
- 用户真正的问题或消息。它每次请求都不同，所以放在最末尾，在所有被缓存的部分之后。
用一个简图看看这个顺序。
一个设计良好的 prompt 的顺序 最前 -> 工具定义 | 系统指令 | 稳定部分：缓存它 大文档 | 少样本示例 | 最后 -> 用户的问题 变化部分：不要缓存这个顺序就是全部的诀窍。稳定的块待在最前面并被缓存，变化的问题待在最后，不会破坏缓存。
到这儿，我们就明确知道了该缓存什么、该放在哪儿。
决定 prompt 里放什么、以什么顺序放，本身就是一门学问（即上下文工程，Context Engineering）。
提示缓存带来的好处
我们把好处快速汇总一下，因为它们才是我们用这项技术的理由。
- 更低的延迟。延迟就是用户拿到回复之前的等待时间。既然模型跳过了重复部分的重算，它就能更快开始回复。
- 更低的成本。缓存命中的 token 以便宜得多的价格计费，大约只有正常价格的十分之一。当我们反复发送同一个大文本块时，这笔节省会累积成很大的数目。
简单说，提示缓存在不改变答案质量的前提下，让我们的应用同时变得更快、更便宜。模型依然看到完整的 prompt，它只是避免了重做已经做过的工作。
这就是提示缓存的美妙之处。
真实世界中的提示缓存
接下来看看提示缓存用在哪些真实系统里。
主流 AI 服务商都把提示缓存做成了内置能力。比如 Claude 背后的 Anthropic、GPT 系列模型背后的 OpenAI，都支持提示缓存。我们只需把 prompt 中稳定的那部分标记为可缓存，服务商就会替我们完成保存与复用。我们还可以检查响应，看看有多少 token 被写入了缓存、有多少从缓存读取，这样随时能确认缓存确实生效了。
提示缓存在两类系统里尤其强大。
第一类是 RAG。RAG 是检索增强生成（Retrieval-Augmented Generation）的缩写。简单说，这类系统会先取回一些相关文档，再把它们连同用户的问题一起发给模型。这些取回的文档和固定指令往往很长，而且在多次请求间重复。缓存稳定的指令，以及任何我们会重复发送的文本，能同时降低成本和延迟。同样的技巧让上下文检索（Contextual Retrieval）变得负担得起——那种做法需要为文档的每个分块都把整篇文档发给模型一次，用来给该分块写一段简短的上下文注记。在同一流程更靠前的环节，文档的 embedding 也可以缓存起来，从而避免每次查询都重新计算。
第二类是智能体系统。智能体（agent）是一个 AI 程序，它一步步完成一项任务，过程中经常调用工具、来回多轮才能做完一件事。在智能体系统里，同一大块指令、工具定义和先前的文本，在每一步都会被发送。步骤可能很多，同一个开头会被复用极多次。这正是提示缓存大放异彩的场景，因为被缓存的 prefix 被一遍又一遍地读取。
在大规模场景下服务这些重复前缀，是推理引擎的职责。vLLM 在请求之间共享相同的前缀；另一个推理引擎 SGLang 用基数树（radix tree）更精确地匹配共享前缀；NVIDIA 的 TensorRT-LLM 也做同样的事，名字叫前缀复用（prefix reuse）。
所以，只要我们一直在发送同一个很大的 prompt 开头，提示缓存就能帮上大忙。
提示缓存就是这样工作的：我们把模型对 prompt 中固定且重复开头的内部计算结果保存下来，让这个开头保持完全一致并放在最前面，然后一遍又一遍地复用它，从而拿到更快、更便宜的响应。
常见问题
提示缓存和语义缓存有什么区别？
提示缓存复用模型对 prompt 重复开头的内部计算结果，也就是 KV 缓存。模型仍然要读新内容，并写出一份全新的回复。语义缓存则是在新问题与旧问题意思相同时（哪怕用词不同）直接复用最终答案。
提示缓存会改变答案质量吗？
不会。提示缓存在不改变答案质量的前提下，让应用变得更快、更便宜。模型仍然看到完整的 prompt，它只是避免重做那几个重复部分已经做过的工作。
为什么我们的提示缓存一直不命中？
最常见的原因是 prompt 顶部附近有会变的东西，比如当前日期、随机 ID 或用户名。被缓存的部分必须逐字符完全一致，所以哪怕靠前的位置只变了一处，后面所有缓存都会失效。我们应该把稳定部分放在前面，把变化部分放在最后。
提示缓存总是更便宜吗？
对第一次请求不是。缓存写入比普通处理略贵，大约是正常价格的 1.25 倍。省钱来自后续的缓存读取，大约是正常价格的十分之一。所以，当大量请求共享同一个开头、且都落在 TTL 窗口内时，缓存才是划算的。
我们怎么知道提示缓存真的生效了？
可以检查服务商返回的响应。它会显示有多少 token 被写入缓存、有多少从缓存读取。如果后续请求显示有 token 从缓存读取，就说明缓存生效了。
