什么是 Prompt Cache？让大模型重复前缀不再重复计算

什么是 Prompt Cache？

Prompt Cache（提示词缓存）是大语言模型推理中的一种前缀复用技术：它把提示词中稳定前缀已经计算出的中间状态保存下来，后续请求遇到完全相同的前缀时直接复用，避免从头重复计算。

它解决的是一个很具体的问题：很多请求都带着相同的系统指令、工具定义、背景文档或对话历史，但模型每次仍然要重新处理这些 Token。如果重复内容很长，浪费的不只是几毫秒计算时间，还包括显存、吞吐和输入 Token 费用。

一句话定义：Prompt Cache 缓存的是提示词前缀对应的计算状态，不是原始文字；它依靠逐 Token 的前缀匹配来跳过已经完成的计算。

为什么大模型需要缓存重复前缀？

大模型每次生成回答前，都要先处理输入提示词。提示词可能包含系统设定、业务规范、示例、工具描述、检索文档和聊天历史，长度从几百 Token 到几十万 Token 不等。

假设一个客服机器人每次都收到下面这段开头：

你是某电商平台的售后客服。
请遵守退货、换货和退款规则，只引用给定业务规范回答。
输出必须包含“结论”“处理步骤”和“需要补充的信息”三个部分。
……（约 2,000 Token 的业务规范和示例）

每次请求只有最后一句用户问题不同，例如“我的订单能退吗？”或“换货要多久？”如果没有前缀缓存，模型会在每一次请求中重新读取前面约 2,000 Token 的内容。请求量越大，重复计算越明显。

Prompt Cache 的价值可以拆成三点：

1. 降低首字延迟：已命中的前缀不用再次完整计算，模型更快开始生成。
2. 提高吞吐：同一台推理服务可以把算力留给真正变化的用户问题。
3. 减少输入成本：部分云 API 会为缓存命中的输入 Token 提供更低价格，具体折扣和计费规则取决于服务商。

因此，Prompt Cache 不是让模型“记住了内容”，而是让推理服务少做一遍已经做过的工作。

模型到底在缓存什么？

Prompt Cache 缓存的是稳定前缀经过模型各层计算后产生的 Key-Value（键值）状态，也就是通常所说的 KV Cache。它不是把提示词原文存成一个字符串，也不是把答案存下来。

理解这件事，需要先看一次推理的简化流程：

1. 切分 Token：模型把中文、英文、代码和标点切分成 Token。
2. 计算前缀状态：每个 Token 经过 Transformer 层，产生后续注意力要使用的 Key 和 Value。
3. 生成新 Token：模型基于已有状态计算下一个 Token，并把新状态继续追加到 KV Cache。
4. 复用稳定部分：下一次请求如果从开头开始的 Token 完全一致，就可以读取这部分已有 KV 状态，只计算变化点之后的内容。

可以把 KV Cache 理解成模型阅读前文后留下的“可继续阅读的位置”。缓存保留的是模型内部的计算结果，所以服务端仍然需要按照自己的模型版本、硬件和缓存协议来管理它。

Prompt Cache 是如何命中的？

Prompt Cache 的命中条件是从提示词最开头开始的连续 Token 完全一致。它不是全文搜索，也不是根据语义判断“意思差不多”。

例如，下面两次请求的前缀相同：

[相同] 系统指令 + 工具定义 + 业务规范
[变化] 用户问题：我的订单能否退款？

[相同] 系统指令 + 工具定义 + 业务规范
[变化] 用户问题：如何修改收货地址？

前面的稳定部分可以命中缓存，后面的用户问题需要重新计算。相反，如果第二次请求把一个动态时间戳放到了最前面：

当前时间：2026-08-18 10:30:01
系统指令 + 工具定义 + 业务规范

即使后面的业务规范完全没有变化，时间戳这个 Token 的变化也会让后续前缀无法按原缓存继续匹配。

命中通常受以下因素共同影响：

• 前缀是否从第一个 Token 开始一致。
• 消息角色、字段顺序、空格、换行和序列化方式是否发生变化。
• 模型版本、Tokenizer、工具定义和推理参数是否符合服务商要求。
• 缓存是否仍在生命周期内，且服务端是否有可用容量。

结论是：“语义相同”不等于“缓存命中”，只有缓存协议认可的逐 Token 一致才算命中。

一次请求的缓存流程是什么？

一个支持 Prompt Cache 的服务，通常会把请求处理成“查找前缀、读取或写入状态、计算新增内容”三个阶段。

典型流程如下：

1. 查找：服务端根据模型、租户、请求前缀和缓存策略查找可复用的 KV 状态。
2. 读取命中部分：找到匹配前缀后，直接加载对应的 KV Cache。
3. 计算新增部分：从前缀结束的位置开始，处理新的用户消息或文档内容。
4. 写入新状态：如果配置允许，新的稳定片段会被追加或建立成下一次可复用的缓存。
5. 继续生成：模型使用“缓存前缀 + 新计算内容”生成回答。

第一次请求通常要付出完整的前缀计算和缓存写入成本，后续请求才获得读取收益。这也是为什么 Prompt Cache 更适合短时间内重复使用同一长前缀，而不适合只调用一次的短提示词。

多轮对话为什么特别适合 Prompt Cache？

多轮对话适合 Prompt Cache，因为每一轮请求都会携带一部分稳定历史。系统提示词、会话规则和已经确认的早期消息通常位于请求前部，后面只追加最新一轮用户问题与助手回答。

例如，一个编程助手的请求可能逐轮变成：

第 1 轮：系统规则 + 项目说明 + 用户问题 1
第 2 轮：系统规则 + 项目说明 + 用户问题 1 + 助手回答 1 + 用户问题 2
第 3 轮：系统规则 + 项目说明 + 用户问题 1 + 助手回答 1 + 用户问题 2 + 助手回答 2 + 用户问题 3

如果序列化格式和历史内容保持稳定，前面已经处理过的部分可以继续复用。对长对话来说，命中前缀的 Token 数会随着轮次增加，平均每轮的重复计算成本也更容易下降。

不过，多轮对话并不保证永远命中。截断旧历史、重新排序消息、修改系统提示词、插入动态时间或改变工具列表，都可能让缓存从变化点开始失效。

批量任务为什么能从缓存中获益？

批量任务的共同特点是“规则相同，输入对象不同”。同一份评估标准、分类说明或报告模板，可以作为稳定前缀复用给成百上千份输入。

例如，要用同一套标准评估 500 份学生作文：

没有缓存时，500 份作文都要重新处理那套评分规则；有缓存时，第一次请求建立状态，后续请求可以复用稳定部分。最终节省多少取决于前缀长度、命中率、批次间隔、缓存价格和服务商的具体实现。

长文档和 RAG 应该怎样配合？

Prompt Cache 与 RAG（检索增强生成）解决的问题不同，但可以组合使用。RAG 负责从知识库中找出相关片段，Prompt Cache 负责复用每次请求中稳定不变的那部分前缀。

一种常见的请求结构是：

[稳定前缀] 系统规则 + 工具定义 + 输出格式 + 固定业务说明
[动态内容] 本次检索到的文档片段
[动态内容] 用户问题

如果把每次检索结果放到最前面，文档变化会使后面的系统规则也无法复用。更合理的做法通常是先放稳定规则，再放动态检索上下文，最后放用户问题。需要注意，检索片段的排序和拼接必须稳定，否则即使内容集合相同，Token 顺序改变也可能影响命中。

这说明 Prompt Cache 不能代替 RAG：它减少的是重复计算，RAG 解决的是从大量资料里找什么。

Prompt Cache 和普通缓存、语义缓存有什么区别？

Prompt Cache、普通响应缓存和语义缓存都能减少重复工作，但缓存对象和正确性边界不同。

Prompt Cache 不会直接把上一次答案发给用户，因此它通常不会引入“旧答案被原样复用”的问题；但它依赖更严格的前缀和运行环境一致性。

如何设计提示词，才能提高缓存命中率？

提高命中率的基本原则是：稳定内容前置，变化内容后置；让前缀结构和序列化方式保持稳定。

可以按下面的顺序组织请求：

1. 系统角色、长期规则和安全边界。
2. 固定的工具定义、函数 Schema 和输出格式。
3. 长期不变的业务文档、评分标准或项目说明。
4. 本次请求的动态检索片段。
5. 最后放用户问题、时间戳、请求 ID 等变化字段。

同时检查这些容易破坏命中的细节：

• 不要把当前时间、随机数、请求 ID 放在稳定前缀的开头。
• 不要在每轮请求中无必要地改写系统提示词或工具顺序。
• 固定 JSON 字段顺序、空格、换行和文档拼接方式。
• 记录缓存命中 Token、未命中 Token、首字延迟和总成本，不要只看总请求数。

缓存优化不意味着提示词越长越好。只有被重复使用足够多次的稳定内容，才值得承担缓存写入和存储成本。

Prompt Cache 有哪些生命周期和成本限制？

Prompt Cache 通常是有时效的临时资源，不是永久记忆。服务商可能在几分钟到几小时后清理缓存，也可能在显存或高速存储紧张时提前淘汰它。

使用时需要关注以下限制：

不同平台的 API 名称、最小缓存长度、自动或显式写入方式、命中计费和保留时间都不一样。接入前应以对应平台当前文档为准，不要把某一家服务商的规则当成通用协议。

Prompt Cache 什么时候不值得用？

当提示词很短、请求只发生一次、前缀频繁变化，或者缓存写入和存储成本高于重复计算时，Prompt Cache 的收益可能很小。

可以用一个简单判断：

预期收益 ≈ 命中次数 × 每次节省的前缀计算成本
          - 缓存写入成本 - 存储成本 - 管理成本

这不是服务商计费的精确公式，但适合做方案评估。对一次性摘要、很短的聊天问题和每次都变化的实时提示词，直接计算往往更简单。对长系统提示、稳定工具定义、批量评估和高频会话，缓存才更可能带来明显收益。

如何验证 Prompt Cache 是否真的有效？

不要只凭“感觉变快了”判断缓存是否生效。应使用相同模型、相同前缀和相近负载做对照测试，并分别记录第一次请求与后续命中请求。

建议至少观察这些指标：

1. 缓存命中 Token 数：本次请求有多少输入 Token 直接复用。
2. 缓存未命中 Token 数：仍需完整计算的 Token 数量。
3. 首字延迟（TTFT）：从提交请求到生成第一个 Token 的时间。
4. 总输入费用：区分缓存写入、缓存命中和普通输入的价格。
5. 命中率与淘汰率：按模型、租户、前缀版本和时间窗口拆分统计。

测试时还要故意改变一个前缀 Token，确认命中会从变化点失效；再恢复原始前缀，确认缓存可以重新命中。这样才能排除“接口看起来支持缓存，但实际没有复用”的误判。

常见问题

Prompt Cache 缓存的是提示词文字吗？

不是。Prompt Cache 通常缓存的是提示词前缀经过模型计算后产生的 KV Cache，也就是供后续注意力计算复用的中间状态。原始文字仍可能需要由客户端或服务端保存，二者不是同一个对象。

Prompt Cache 和上下文窗口有什么关系？

上下文窗口决定一次请求最多能放多少 Token；Prompt Cache 决定其中一部分已经处理过的 Token 是否可以跳过重复计算。缓存不会扩大模型的上下文上限，也不会让窗口之外的历史自动恢复。

只要两次提示词意思一样，就一定能命中吗？

不一定。Prompt Cache 通常要求从开头开始逐 Token 一致，空格、换行、字段顺序、工具定义和动态时间戳的变化都可能影响命中。语义相似更接近语义缓存的判断方式。

Prompt Cache 能直接缓存模型的最终答案吗？

不能把两者混为一谈。Prompt Cache 复用前缀的计算状态，模型仍会根据新增问题继续生成；要复用完整答案，应使用响应缓存，但必须额外处理数据时效和答案适用范围。

多轮对话中的历史消息会一直被缓存吗？

不会保证一直缓存。只要历史被截断、重排、改写，或者缓存超过生命周期被清理，就可能从变化点重新计算。应监控命中 Token 和缓存过期策略，而不是假设会话永久命中。

本地部署的大模型默认支持 Prompt Cache 吗？

不一定。能力取决于推理框架是否支持跨请求 KV Cache、缓存索引和内存管理，以及部署者是否开启相关配置。云服务通常把缓存能力封装在 API 中，本地部署需要查看具体框架文档并自行评估显存占用。

总结：Prompt Cache 解决了什么问题？

Prompt Cache 解决的是大模型处理重复提示词前缀时反复计算的问题。它缓存稳定前缀对应的 KV 中间状态，通过严格的前缀匹配跳过已完成的计算，让后续请求只处理新增内容。

它最适合三类场景：带有长系统设定的多轮对话、使用同一套规则的批量任务，以及包含固定文档和工具定义的长提示词应用。要让它真正省钱省时，记住三件事：把不变内容放在前面，把变化内容放在后面，持续监控命中率与实际成本。

**Prompt Cache 不会让模型拥有永久记忆，但能让重复前缀不再重复计算。**这正是它在大模型推理系统中最直接、也最实用的价值。