Prompt缓存全解析：AI Agent省钱的关键技术

一个被误解的省钱利器

假设你正在使用一个编程Agent，对话已经累积了5万个token的上下文。这时你再发送1千token的新问题，总上下文就变成了51,000 token。问题来了：你会为这51,000个token支付全价吗？

答案是——如果你的Agent框架（agent harness）设计得当，大概率不会；但如果设计有问题，你就得为整个上下文支付全价，费用会非常惊人。

这就是**Prompt Caching（提示缓存）**发挥作用的地方。它是一项能在使用大模型时帮你节省大量成本的技术，但前提是你要正确理解并实现它。本文将拆解它的工作原理与最佳实践。

Prompt Caching的核心原理：缓存的是输入而非输出

如果你有软件开发背景，可能会用数据库缓存的思路来理解Prompt Caching。传统缓存的逻辑是：应用向数据库发起查询，数据库将结果存入缓存，下次相同查询直接从缓存返回结果，无需重复处理。

很多人误以为Prompt Caching也是这样——把用户的prompt发给LLM，LLM返回响应存入缓存，下次相同prompt直接返回缓存的响应。这是完全错误的。

缓存LLM的输出几乎没有意义。真正被缓存的是输入。理解这一点是掌握Prompt Caching的关键。

为什么缓存输入而非输出：KV Cache的底层逻辑

Prompt Caching的底层实现依赖于Transformer架构中的KV Cache（Key-Value Cache）机制。在Transformer的自注意力层中，每个token都会生成对应的Key和Value向量，这些向量用于计算注意力权重。当模型处理一段已见过的前缀文本时，无需重新计算这些KV对，而是直接从缓存中加载，大幅减少了GPU的计算量。这就是为什么缓存必须从前缀开始严格匹配——一旦中间某个token发生变化，其后所有token的注意力计算都会改变，已缓存的KV对随之失效。服务商在GPU显存或高速存储中维护这些KV Cache，并设置TTL（Time To Live）来管理缓存生命周期，到期后自动释放显存资源。

更具体地说，在Transformer架构中，自注意力机制是核心计算模块。对于输入序列中的每个token，模型通过三个线性变换分别生成Query(Q)、Key(K)和Value(V)向量。注意力权重通过Q与所有K的点积计算得出，再用这些权重对V进行加权求和，得到该token的上下文表示。在自回归生成过程中（即逐token生成输出时），每生成一个新token都需要与之前所有token的K和V进行注意力计算。如果每次都重新计算所有历史token的K和V，计算复杂度为O(n²)。KV Cache的核心思想是：将已计算过的K和V向量缓存在GPU显存中，新token生成时只需计算自身的Q、K、V，然后与缓存的历史KV拼接即可。Prompt Caching将这一思想从单次请求内部扩展到了跨请求层面——如果两次API调用的前缀相同，第二次调用可以直接复用第一次已计算并缓存的KV对，跳过前缀部分的前向传播计算，这就是为什么缓存输入能带来如此显著的延迟降低和成本节省。

Agent为什么会重复发送相同token

想象你和Agent的对话已经进行到5万token，里面包含了各种消息、工具调用、返回结果等。当你再问一个新问题（比如1千token），为了让Agent完整理解上下文，你必须把全部51,000个token发给LLM。LLM可能再回复3千token。接着你再问一个问题，这次就要发送全部55,000个token。

可以看到，我们在一遍又一遍地把相同的token发给LLM，每次只在末尾追加一点新内容——这正是Agent的工作方式：追加对话的下一部分，然后重新发送整个记录。

现代Agent框架（如LangChain、AutoGen、Claude Code等）在与LLM交互时，本质上维护着一个不断增长的消息列表。每次调用LLM时，框架会将完整的消息历史——包括系统提示词、用户消息、助手回复、工具调用及其结果——序列化后一并发送。这种"无状态"设计意味着LLM本身不保存会话状态，所有上下文记忆都由客户端负责管理和传输。

这种无状态设计有其深刻的工程原因。HTTP协议本身是无状态的，LLM推理服务作为HTTP API自然继承了这一特性。更重要的是，无状态设计使得推理服务可以水平扩展——请求可以被路由到任何可用的GPU节点，无需维护会话亲和性（session affinity）。这种设计也简化了容错机制：如果某个节点宕机，客户端只需将完整上下文重新发送到另一个节点即可恢复会话。代价就是每次请求都必须携带完整的对话历史，导致了token重复传输问题。一些服务商尝试通过有状态推理（stateful inference）来缓解这一问题，例如保持长连接并在服务端维护KV Cache，但这增加了基础设施的复杂度和成本。

即便是像OpenAI的Responses API这样的接口，看起来LLM「记住」了之前说过的话，但背后其实仍在重新处理整个上下文，只是把这个过程隐藏了起来。这也解释了为什么在编程会话中维持超大上下文并不明智——成本会迅速失控。

不使用Prompt缓存时成本会指数级增长

一个所谓「5万token」的会话，实际消耗的token远不止5万。真实的token消耗是：50k + 51k + 54k + 55k……如此累加，很快就会指数级膨胀。

Token计费的基础知识

LLM API的计费模型基于token——文本被分词器（tokenizer）切分成的最小处理单元。不同模型使用不同的分词策略：GPT系列使用BPE（Byte Pair Encoding）算法，一个英文单词通常对应1-3个token，而中文字符通常每个字占1-2个token。API按输入token和输出token分别计费，输出token通常比输入token贵3-4倍，因为生成过程需要逐token自回归解码，计算密度更高。因此，Prompt Caching主要针对的是输入侧的成本优化。

BPE（Byte Pair Encoding）是当前主流大模型使用的分词算法，理解它有助于更准确地估算成本。其核心思想是从字符级别开始，通过统计训练语料中最频繁出现的相邻字符对并将其合并为新符号，迭代进行直到达到预设的词表大小（如GPT-4使用约10万个token的词表）。这意味着常见词汇（如'the'、'function'）会被编码为单个token，而罕见词或新词会被拆分为多个子词token。中文由于字符多样性高且缺乏空格分隔，通常每个汉字占1-2个token。理解分词机制对成本估算至关重要——同样含义的内容，用不同语言或不同表述方式，token数量可能差异很大。这也是为什么一些开发者会优化prompt的措辞以减少token消耗。

如果你在OpenAI这类较贵的API上，输入价格约为每百万token 4美元，那么这种重复发送将极其昂贵。

以一个仅20万token的Agent会话为例，在Claude Opus、GPT-5、Gemini、Kimi、Grok和DeepSeek上的成本差异巨大。不使用缓存时，在Opus和GPT上仅仅20万token的短会话就要花费约41美元。而一旦启用缓存，成本急剧下降。其中DeepSeek更是「便宜到离谱」，几乎接近免费。

Prompt缓存的计费规则与前缀匹配机制

如今几乎所有LLM API都采用差异化定价：LLM第一次「看到」某个token时收全价，而第二次、第三次以及后续每次看到完全相同的内容时，价格会大幅降低——通常只收全价的10%。

这里的关键在于前缀匹配：只有从第一个token开始完全一致的连续序列才能命中缓存。这意味着如果你的请求是[系统提示词 + 历史对话 + 新问题]，那么系统提示词和历史对话部分（前缀）可以命中缓存，而新追加的问题部分则按全价计费。不同服务商对最小缓存粒度有不同要求：Anthropic要求至少1024个token的前缀才会触发缓存，OpenAI的阈值为128个token。这也解释了为什么"仅追加"模式对缓存如此友好——每次请求的前缀都与上次高度重叠。

从成本曲线看：不使用缓存时，会话成本随上下文增长呈指数上升；启用缓存后，曲线基本保持线性增长。你的目标就是尽可能多地命中那个10%的折扣价。

实测效果：1090万token只花了6美分

在TAL（Py的Python移植版）中，为几乎所有可用的推理服务商都启用了Prompt Caching。使用DeepSeek v4 Flash（通过Hugging Face推理服务商）进行测试的结果如下：

数据显示：整个会话与LLM交换了1090万个token，而上下文窗口只有12.6万。由于每一轮都在来回传输，累计token量高达1090万——最终花费仅6美分。

在TAL导出的会话报告中，蓝线代表缓存命中，红线代表全价写入。会话开始时全部按全价计费；随着对话增长，相同token被反复读取，缓存命中率逐渐提高。

你可能没注意到缓存会过期：图中两次费用「回升」的节点——分别是午饭和晚饭时段，缓存因超时失效，重新读取时又付了全价。不同服务商的过期时间不同：OpenAI约1小时，Anthropic默认5分钟（通过Claude Code认证则为1小时）。缓存过期本质上是服务商在GPU显存压力与用户体验之间的权衡——显存是稀缺资源，长期维持大量用户的KV Cache会占用宝贵的推理容量。

Agent设计中的Prompt缓存最佳实践

要让Agent最大化利用Prompt Caching，需要注意以下几点。

关注缓存过期时间

第一件要确认的事就是你所用推理服务商的缓存过期时间。在Hugging Face推理服务商上，TAL会将所有请求路由到同一个服务商，从而命中「温热」缓存，几乎不会漏掉任何缓存。

这种路由策略在分布式推理场景中尤为重要——如果请求被负载均衡到不同的GPU节点，每个节点的KV Cache相互独立，缓存命中率会大幅下降。在大规模推理部署中，服务商通常运行数百甚至数千个GPU节点来处理并发请求。解决方案包括：基于请求前缀哈希的一致性路由（将相似前缀的请求路由到同一节点组）、分布式KV Cache共享存储（通过高速网络在节点间传输缓存数据）、以及分层缓存架构（热数据在GPU显存，温数据在CPU内存或NVMe SSD）。vLLM等开源推理框架实现了PagedAttention技术，将KV Cache以页为单位管理，类似操作系统的虚拟内存机制，大幅提高了显存利用率和缓存命中率。

确认服务商是否自动启用缓存

有些服务商会自动缓存输入（如OpenAI和Hugging Face推理服务商），但另一些（如Anthropic或Gemini）不会自动缓存，你需要在API调用中手动启用。以Anthropic为例，你需要在消息中添加cache_control字段来标记缓存断点（cache breakpoint），告诉API哪些内容应该被缓存。这种显式标记虽然增加了开发复杂度，但也给了开发者更精细的控制粒度——你可以精确指定缓存的边界位置。

避免使用动态系统提示词

这一点极其重要。

假设你的系统提示词有1万token，会话增长到20万token。每次请求这些token本可被缓存。但如果你的系统提示词里包含时间戳、当前工作目录这类会变化的内容，一旦它改变，就会让其后的整个缓存全部失效。

这背后的原理与前缀匹配直接相关：系统提示词位于整个请求的最前端，是前缀的第一部分。一旦前缀中的任何一个token发生变化，从该位置往后的所有KV Cache都将失效，即使后续的对话历史完全没有改变。这就像多米诺骨牌——推倒第一块，后面全部倒塌。

因此，切勿在系统提示词中加入任何动态内容，包括时间戳、可能中途改变的工作目录、动态更新的工具列表等，否则会话成本会飙升。正确的做法是将动态信息放在消息序列的末尾（如最新的用户消息中），或使用独立的系统消息在对话末尾补充时间等上下文信息。

理解对话压缩会重置缓存

当你对长对话进行压缩、将其总结成一段简短摘要时，也会使缓存失效。这是压缩机制的正常表现，并非问题，但要意识到它会重置缓存。

对话压缩是上下文窗口管理的常见策略：当对话长度逼近模型的上下文窗口限制（如128K token）时，框架会将早期对话总结为一段精简摘要，替换掉原始的详细消息。虽然这能有效控制单次请求的token数量，但由于压缩后的文本与原始前缀完全不同，已缓存的KV对会全部失效。权衡策略包括：尽量延迟压缩时机以最大化缓存利用率、使用滑动窗口保留最近N轮原始对话、或在压缩后通过连续请求主动预热新缓存。

总结

Prompt Caching是构建成本可控的Agent系统时不可忽视的一环。核心原则可以概括为：

• 系统提示词和历史记录不应在对话过程中动态变化
• 对话历史应保持「仅追加」，避免小失误导致缓存失效
• 关注缓存过期时间，如果剩余时间充足，可考虑为特定服务商延长缓存有效期
• 使用支持缓存命中率监控的Agent框架（如Py或TAL），以便实时观察缓存命中率

对于每天与编程Agent打交道的开发者而言，正确实现Prompt Caching不仅能把账单从几十美元降到几美分，更是构建可持续Agent系统的基础能力。随着Agent系统向更长会话、更复杂工具链演进，对缓存机制的理解和优化将成为区分「能用」和「能用得起」的关键分水岭。