Prompt Cache

3 秒看懂

Prompt Caching 是一种在大型语言模型（LLM）推理中，跨请求复用注意力计算结果（KV Cache）的机制。当多个请求共享相同或高度重叠的提示前缀时，系统只计算一次前缀的键值缓存，后续请求直接复用，跳过重复的“预填充”计算，从而显著降低首 token 延迟与 GPU 算力消耗。

3 分钟产业解释

LLM 每次生成回答前，都必须对整段输入文本执行完整的注意力计算，生成 KV Cache（Key‑Value 缓存）。在 API 调用、多轮对话、固定指令模板等场景中，大量请求包含相同的系统提示、上下文文档或工具描述，例如“你是一位金融分析师，请根据以下财报回答：……”后面接上不同的用户问题。如果每次都要为这些共同部分重新计算 KV Cache，相当于用昂贵的 GPU 重复做无用功。

Prompt Caching 将这些中间结果按前缀内容索引，并缓存到显存或主机内存中。后续请求一旦匹配到已缓存的前缀，就能直接从缓存池中加载 KV 张量，预填充阶段只需处理剩余的新增 token。带来的直接效果是：

• 首 token 延迟（Time‑To‑First‑Token）下降 50%–90%（具体取决于前缀与新增 token 的比例，各厂商披露范围不一）；
• 同等硬件下可承载的并发请求数明显上升，推理集群总吞吐提升；
• 云 API 对缓存命中的重复 token 往往提供计费折扣（如 Anthropic 对缓存命中的输入 token 仅收取原价 10%，OpenAI 对符合条件的请求给予自动折扣），降低使用成本。

该技术于 2023–2024 年在学术与工程上快速成熟，已被 vLLM、SGLang、TensorRT‑LLM 等主流推理引擎内置为自动前缀缓存，并被 Anthropic、OpenAI、Google Cloud 等云厂商转化为可计费的 API 能力，是当前 LLM 推理降本的核心手段之一。

技术原理

Transformer 推理的两阶段与 KV Cache

LLM 推理分为 预填充（prefill） 和 逐 token 生成（decoding）。预填充阶段一次性将整个输入序列送入模型，并行计算每一层中每个位置的 Key 和 Value 投影，产生第一步的 logits，并保存所有位置的 K 和 V 矩阵到缓存。该阶段计算密集，输入越长延迟越高。随后的解码阶段每一步只处理新增的一个 token，计算其注意力时需要读取之前全部的 KV Cache，并追加新 token 的 K、V。解码阶段的每一步计算量很小，但需反复访问完整的 KV Cache，对内存带宽与容量敏感。

自注意力机制中，给定查询 Q、键 K、值 V，输出为：

text(Attention)(Q,K,V) = text(softmax)\left(frac(QK^T){sqrt(d_k)}\right)V

在因果（自回归）模型中，每一个 token 只能注意到之前的位置。推理时，已处理 token 的 K、V 保存在 K_cache 和 V_cache 中，后续 token 只需计算与这些缓存的注意力，无需重新投影历史 token。

跨请求前缀复用

Prompt Caching 的核心在于不同请求之间共享 KV Cache。假设请求 A 和请求 B 拥有完全相同的提示前缀 [SysPrompt]，其后跟随不同的用户问题 [UserQ_A]、[UserQ_B]。首次处理 [SysPrompt] 后，其所有层的 K、V 被存入全局缓存池，并以前缀内容的哈希或区块序号作为索引。请求 B 到达时，系统计算其前缀哈希，发现命中后直接“挂载”已缓存的 KV 块，后续预填充仅需处理 [UserQ_B] 部分，而该部分的注意力计算可以完整看到 [SysPrompt] 的缓存内容，完全等价于从零计算的语义。整个流程如下图所示：

请求A: [SysPrompt] + [UserQ_A] → 生成答案A
请求B: [SysPrompt] + [UserQ_B] → 生成答案B

缓存复用流程：
1. 首次处理 [SysPrompt] 时，其 KV Cache 存入缓存池，索引为 hash([SysPrompt])
2. 请求B到达，计算 hash([SysPrompt])，命中 → 仅预填充 [UserQ_B]，其注意力可访问全部 SysPrompt KV
3. 解码阶段两个请求各自追加自身的新增 KV，互不干扰

在更先进的实现中，缓存可以基于 token 块（如每 16 个 token 一个块）进行管理，不仅匹配严格前缀，还能识别请求中任意位置的公共子序列，进一步扩大命中范围。这类方法常借助基树（Radix Tree）或哈希表来快速定位已缓存块。

工程挑战：显存、一致性与索引效率

实现跨请求缓存复用时面临三大挑战：

• 内存膨胀：每缓存一个前缀，就需要在 GPU 显存（HBM）或主机内存中保存完整的 K、V 张量。长序列模型（如 100k token 上下文）中，一个前缀可能占用数 GB 显存。设计合理的换入换出（swap）策略、淘汰算法（如 LRU），以及与 PagedAttention 等块状内存管理机制配合，才能平衡命中率与内存压力。
• 一致性约束：任何模型权重更新、量化模式改变或采样超参数（如 temperature）影响计算路径时，此前保存的 KV Cache 都将失效，需要全部冲刷重建。云服务在模型升级时必须通知客户缓存失效，或提供透明的切换过渡。
• 索引与命中判断：系统需在微秒级判断新请求的前缀是否已被缓存。常用手段包括维护前缀的哈希表，或允许用户在 API 中显式标记“可缓存边界”（如 Anthropic 的 cache_control 参数）。自动前缀缓存则通过交易内存开销换取无缝命中，无需用户感知。

Prompt Caching 将计算去重与内存复用绑定在一起，通过系统级优化提升整个推理管线的可用性与经济性。

关键参数

Prompt Caching 的效果与代价由以下参数刻画，但目前行业内尚缺乏统一公开基准，各厂商与研究机构公布的数字因场景而异，此处仅作定性说明，部分给出已知的参考范围（均注明来源或说明“公开资料未见”）：

• 缓存命中率（Hit Rate）：启用缓存后，命中请求占总请求的比例。直接决定节省的计算量。该指标高度依赖请求前缀的重合度与缓存容量。在聊天应用、RAG 问答等强模板场景中，内部测试命中率可超过 80%；而在用户随意提问的低重合场景下，命中率可能低于 10%（据 Anthropic 工程博客 2024 年定性描述，未公布精确基准）。
• 首 token 延迟改善比（TTFT Reduction Ratio）：命中时首 token 延迟与无缓存首 token 延迟的比值。典型数据：当缓存前缀占输入总 token 的 90% 时，预填充计算量降至原来的 10%，TTFT 可下降约 80%–90%（理论估算，受通信和调度开销影响）。
• 等效吞吐提升（Throughput Uplift）：在相同硬件和尾延迟 SLO 下，启用缓存后可额外支持的并发请求数或每秒生成 token 数。公开资料未见统一测试套，部分推理框架在博客中提及吞吐提升 30%–100%（如 SGLang 针对特定工作负载的案例，2024 年）。
• 内存开销（缓存压力）：缓存占用 GPU 显存或主机内存的总量，通常以每百万 token 前缀所需 GB 数表示。对于 70B 参数模型（FP16），每个 token 的 KV Cache 大小约为 2 * 层数 * 头数 * 头维度 * 2字节，典型值约 2–4 MB/1k token。缓存 100 万 token 的前缀约需 2–4 GB 显存。该开销会挤占可用于批处理（batching）的显存空间，若命中率不足，反而降低整体吞吐。
• 缓存失效比例：因模型权重更新、重启或显式刷新导致的缓存不可用频次。在多模型部署的集群中，频繁切换模型可能导致失效比例上升。云服务商通常建议将缓存用于稳定的模型版本。
• 计费折扣力度：影响用户采纳的经济参数。截至 2025 年初，Anthropic Claude API 对缓存命中的输入 token 提供 90% 成本减免（即收费为原价的 10%，来源：Anthropic 官方文档 2024 年 5 月）；OpenAI 对 GPT‑4o 和 GPT‑4o‑mini 在部分条件下提供 50% 的输入 token 折扣（自动缓存，来源：OpenAI 平台文档 2024 年 8 月更新）；Google Cloud Vertex AI 上下文缓存功能对命中 token 提供折扣，具体比例未公开。其他厂商未充分披露统一折扣比率。

跟踪这些参数可帮助用户评估 Prompt Caching 在其工作负载中的实际净收益，但尚无行业通用披露标准，公开可比数据有限。

技术路线

当前产业落地的主流技术路线可归类为四层，从无缓存到高度自动化的广义共享，形成递进关系：

目前应用最广泛的是路线 3 自动前缀缓存。vLLM 的 PagedAttention 实现了块级内存管理，并原生支持 enable_prefix_caching 参数（vLLM 0.4.0 以上版本提供，0.5.0 后稳定）。SGLang 的 RadixAttention 利用基树（Radix Tree）管理跨请求 KV Cache 块，可以精确匹配任意长度的公共前缀，并在部分场景中展示出比常规前缀哈希更高的命中率。NVIDIA TensorRT‑LLM 同样提供了“KV Cache Reuse”功能，支持以 session 为粒度的缓存复用。

路线 4 下的各实验性方案（如 LSH‑based 近似匹配）多处于学术探索阶段，尚未在商业云中大规模部署。未来如果用户场景极度碎片化，近似匹配技术可能会与现行自动前缀缓存融合，但仍需解决精度可控性和额外计算开销的问题。

上游

Prompt Caching 的上游由模型资产、内存管理中间件、推理运行时和硬件层构成：

• 模型权重：缓存有效的前提是模型权重不变。因此上游包括 LLM 权重提供商（Meta、Mistral、AI21 Labs、阿里云等开源模型发布方，以及闭源模型商如 OpenAI、Anthropic），它们的版本稳定性直接影响缓存可用期。一旦模型微调或升级，下游缓存全部失效。
• KV Cache 内存管理中间件：以 PagedAttention、RadixAttention 为代表的内存管理技术，支撑物理块级别的分配、回收和跨请求复用。这些中间件通常内嵌于推理引擎，如 vLLM 的块表管理、SGLang 的 Radix Tree 缓存池。
• 推理运行时：将上述中间件与 CUDA kernel、注意力算子优化结合的完整栈，包括 vLLM、SGLang、TensorRT‑LLM、Hugging Face TGI 等。它们对缓存的调度、换入换出（offload）与请求调度策略（如 continuous batching）紧密耦合。
• 硬件与互联：GPU 的 HBM 容量与带宽（如 NVIDIA H100 80GB HBM3、H200 141GB HBM3e）直接决定可缓存前缀的总规模；高带宽主机 DRAM（DDR5）和 NVMe SSD 可作为溢出存储层。CXL 内存池化等新技术若成熟，有望在节点间扩展低延迟缓存层，但截至 2025 年初尚未大规模部署于推理集群。

下游

下游是直接使用 Prompt Caching 的推理服务消费者和最终应用：

• LLM API 平台：Anthropic、OpenAI、Google Cloud Vertex AI、AWS Bedrock、Azure OpenAI Service 等向开发者提供已集成缓存的推理 API，开发者无需关心底层实现，只需通过参数（如 cache_control）声明可缓存范围。
• 私域部署企业：在自己数据中心或私有云中部署 vLLM、SGLang 或 TensorRT‑LLM 的企业，通过开启自动前缀缓存来降低内部应用的推理成本，服务于智能客服、知识库问答、文档分析、代码生成等场景。大型企业（金融、医疗、法律）需要调用 LLM 处理大量结构同理但数据不同的请求，是缓存的高价值场景。
• 多智能体/工具调用应用：在 Agent 框架（如 LangChain、AutoGen）中，每次调用 LLM 都可能重复载入工具描述、历史对话摘要等，Prompt Caching 可有效压低这类框架的边际推理成本。
• 边缘推理：部分混合推理架构将部分可复用前缀缓存储存在边缘设备，云端仅传递增量请求，减少延迟和带宽消耗，但目前仍处早期验证阶段，公开案例有限。

受益公司

Prompt Caching 的推广使以下环节的公司直接或间接获益（此处仅描述业务逻辑，不构成任何投资建议）：

• 推理框架商业支持公司：提供高性能推理引擎企业版与托管服务的公司，如 Anyscale（基于 Ray 和 vLLM 的推理服务），以及 SGLang 背后的初创团队等。它们将 Prompt Caching 作为降本增效的关键卖点，通过提供优化实施和运维支持获得收入。
• 云推理服务提供商：拥有大显存 GPU 集群的公有云厂商（微软 Azure、AWS、Google Cloud）以及独立 AI 推理云（Together AI、Fireworks AI、Groq*），通过提供缓存折扣吸引客户，提升其平台竞争力，并凭借缓存带来的更高硬件利用率改善自身单位经济模型。 注：Groq 使用 LPU 架构，KV Cache 管理方式不同，但也提供类似的缓存复用能力。
• GPU 与存储硬件厂商：NVIDIA（提供高 HBM 容量 GPU）、AMD（MI300X 等大显存加速卡）和存储/内存厂商（SK 海力士、三星、美光等 HBM 供应商）从推理扩容需求中受益，因为更大缓存池要求更高显存容量。
• 重度 LLM 调用方：SaaS 企业（如客服自动化、代码助手、法律文档审阅系统）如果自行部署推理引擎或使用云服务，Unit Economics 将因 Prompt Caching 改善，有利于降低服务成本、扩展利润率。这部分企业是需求的最终受益者。

市场规模

截至 2025 年初，尚无第三方研究机构发布 Prompt Caching 的独立市场规模数据。其经济价值蕴含在 LLM 推理市场的膨胀之中，难以单独剥离。以下通过相关推理市场数据给予间接参考（数字均标注来源与估算口径）：

• 据 SemiAnalysis 2024 年 7 月的估算，全球 LLM 推理的总拥有成本（TCO，含芯片、电力、基础设施）在 2024 年约为 200–250 亿美元，并预计 2028 年将突破 1000 亿美元（口径为服务提供商和自建推理支出的总和）。Prompt Caching 作为降低单位 token 成本的关键技术，可节省的算力比例在工作负载高度重合时可达 30%–70%，但其整体渗透率受制于前缀重合度。
• 从云服务商的计费结构调整可窥见一斑：Anthropic 在实行缓存折扣后，部分客户的平均推理成本下降超过 50%（来源：Anthropic 官方博客 2024 年 5 月案例）。这表明缓存机制正在实质性影响云推理的营收模式，但至今没有公开的细分市场报告。
• 根据多家云厂商产品公告，2024 年下半年起 Prompt Caching 几乎成为 LLM API 的标准配置，反映供给端已将其视为基础竞争力。可预见随着多模态长上下文模型（数百万 token）的普及，重复计算开销急剧增加，Prompt Caching 的采纳率与隐含经济价值将继续扩大，但公开可引用的具体金额或份额仍缺失。

玩家对比

下表对比了主流推理引擎与云推理服务在 Prompt Caching 方面的实现差异（信息截至 2025 年 3 月）：

说明：开源引擎的“成本优势”指通过降低预填充计算量来节约 GPU 时租金和功耗，不涉及 API 计费。云服务商的折扣信息基于各厂商截至 2025 年 3 月的官方文档。部分云厂商（如 Azure OpenAI Service）虽未单独公布缓存折扣，但其底层 API 可能继承 OpenAI 缓存策略。

风险

• 命中率不及预期：若应用场景中请求前缀高度随机化（如用户自由提问无重复模板），缓存命中率可能极低，额外占用的缓存内存会挤占批量处理空间，反而降低整体吞吐。部署前需基于真实流量评估命中率。
• 内存压力与成本：缓存在 GPU 显存中驻留大量 KV 块，可能导致能同时处理的请求批大小下降。大容量主机内存卸载虽可缓解，但带来 PCIe 传输延迟，削弱部分增益。
• 模型更新导致缓存失效：频繁微调、Base Model 升级或权重切换时，所有已缓存 KV 块必须丢弃。多模型部署的集群可能面临“缓存抖动”，降低其净效益。
• 精度与一致性风险：采用近似匹配算法时，若复用不完全一致的 KV 缓存，注意力计算偏差可能影响下游生成质量。当前主流云服务均采用严格精确匹配，但未来若引入近似方案需谨慎验证。
• 安全与数据隔离：在多租户推理集群中，必须确保不同客户间的 KV Cache 完全隔离，避免侧信道泄露。云厂商声明会进行租户间严格隔离，但部署自建集群时需确保权限与命名空间设计。
• 计费透明度：自动缓存的计费折扣规则可能较复杂（如仅当重复超过一定次数后触发），开发者可能难以准确预估成本，需关注云厂商文档细节。

误读纠偏

• 误读 1：Prompt Caching 等同于普通 KV Cache KV Cache 是所有自回归 LLM 推理过程中自然产生的中间结果，每个生成请求都会创建；而 Prompt Caching 特指跨不同请求之间共享和复用这些缓存的系统性机制。仅在单请求内保存和读取 KV 不是 Prompt Caching。

• 误读 2：启用缓存总能省钱 缓存本身占用额外显存。若命中率过低，这部分显存可能原本可用于更大的批处理，反而降低硬件利用率和吞吐，导致单位 token 成本上升。收益取决于请求前缀重叠度。

• 误读 3：只有完全相同的提示才能复用 只要请求前缀相同（哪怕只是系统提示的前半部分或共享文档的开头），即可复用前缀的 KV。自动前缀缓存甚至可以识别任意位置的公共子序列（如多文档 QA 中不同请求携带部分相同的长上下文），进一步提升命中率。

• 误读 4：缓存对解码阶段没有帮助 虽然缓存主要加速预填充，但快速完成预填充可以让解码阶段更早开始，并且减少预填充占据的计算资源，允许 GPU 同时处理更多请求的解码步骤，间接提高解码阶段的通量。

最新事件

• 2024 年 5 月：Anthropic 宣布为 Claude API 推出 Prompt Caching 功能，用户可通过 cache_control 标记可缓存前缀；缓存命中的输入 token 价格降至原价的 10%，缓存有效期 5 分钟。此举大幅降低了多轮对话和长文档重复查询的成本（来源：Anthropic 官方博客）。
• 2024 年 8 月：OpenAI 在 Chat Completions API 中为 GPT‑4o 和 GPT‑4o‑mini 启用自动 Prompt Caching，系统自动识别请求中的公共前缀并对命中 token 提供 50% 折扣，无需用户修改任何代码（来源：OpenAI 平台文档更新）。
• 2024 年 10 月：Google Cloud Vertex AI 正式推出“上下文缓存（Context Caching）”能力，适用于 Gemini 模型，允许用户提交可缓存的上下文内容，减少对超长上下文的重复计算成本（来源：Google Cloud 博客）。
• 2024 年 Q4：vLLM 0.6.0 版本发布，自动前缀缓存（automatic prefix caching）经进一步优化后转为默认开启，并在多节点部署中支持基于 NCCL 的 KV 传输，提升了分布式缓存命中率。SGLang 同期发布了 RadixAttention 的自动缓存淘汰策略，降低显存碎片。
• 2025 年 1 月：DeepSeek、阿里通义千问等国产 LLM API 服务商相继上线或优化 Prompt Caching 功能，为长上下文应用提供折扣计费与更低延迟（来源：各厂商官方公告）。海外 Together AI 推出“Caching API” beta 版，允许用户主动管理缓存会话。公开资料可见 Prompt Caching 已成为主流 LLM 服务的标准能力。

跟踪指标

用户或市场参与者可关注以下维度的公开与非公开指标，以追踪 Prompt Caching 的进展与受益情况：

• 云服务商计费报告中的缓存命中比例：部分云平台（如 Anthropic Console）提供每请求级别的缓存命中信息与成本节省明细，可用于评估工作负载的缓存收益。若无报表，可通过对比输入 token 计费量与发送 token 量估算折扣。
• 推理引擎性能监控：自建部署中，vLLM、SGLang 等的集群面板输出 prefix_cache_hit_rate、gpu_cache_usage_percent 等指标。理想情况下，命中率应稳定在 60% 以上（来源：vLLM 维护者建议，非硬性标准），同时需观察显存用量和请求队列深度是否因缓存发生负向变化。
• 开源基准与博客：关注 vLLM、SGLang 发布的性能报告，以及云厂商工程博客中的案例研究，留意其公布的吞吐提升倍数和 TTFT 改善数据，这些通常来自典型负载测试，可作为部署前参考。
• 硬件负载率：如果看到 GPU 集群的预填充计算单元（如 FP16 TFLOPs 利用率）明显下降，而同等请求量下解码批次增大，可能侧面印证缓存有效性。
• 新模型适配进度：每当有重要新模型发布（如 Llama 4、GPT‑5 等），跟踪主流引擎对其 Prompt Caching 的支持状态，将影响缓存功能的持续可用性。
• 计费折扣政策变动：云服务商偶尔调整缓存折扣或有效期，直接影响 API 用户的成本模型，需定期查阅官方文档。

信源

以下为撰写本概念页时参考的公开来源（均可在相应的学术数据库、官方文档库或代码仓库中检索获取，此处不提供 URL）：

1. “Prompt Cache: Modular Attention Reuse for Low‑Latency Inference” (A. Asai et al., 2023) —— 提出模块化提示缓存框架的学术论文。
2. “Efficient Memory Management for Large Language Model Serving with PagedAttention” (Kwon et al., SOSP 2023) —— 提出 PagedAttention 的 vLLM 原始论文，跨请求块级 KV 缓存复用的基础。
3. “SGLang: Efficient Execution of Structured Language Model Programs” (Zheng et al., arXiv 2024) —— 介绍 RadixAttention 与系统级缓存复用。
4. Anthropic 开发者文档 “Prompt Caching” 章节（2024 年 5 月发布，持续更新）—— 缓存功能 API 规范与计费政策。
5. OpenAI 平台文档 “Prompt caching”（2024 年 8 月更新）—— GPT‑4o 自动缓存折扣说明。
6. Google Cloud Vertex AI 文档 “Context caching” （2024 年 10 月）—— Gemini 上下文缓存功能描述。
7. vLLM 官方文档与 GitHub 仓库中的 automatic_prefix_caching 相关部分 —— 引擎实现细节与参数指南。
8. NVIDIA TensorRT‑LLM 文档 “KV Cache Reuse” 部分 —— 会话级缓存复用说明。
9. SemiAnalysis 研究报告 “AI Datacenter TCO Model” （2024 年 7 月） —— LLM 推理 TCO 估算数据。
10. 各云厂商 2024–2025 年官方博客与产品公告（Anthropic、OpenAI、Google Cloud、AWS、Together AI、DeepSeek、阿里云等），用于确认最新事件与计费变更。