大模型自回归生成的逐token计算特性，天然存在大量重复计算冗余。缓存技术通过复用已完成的计算结果，是降低推理延迟、提升服务吞吐、控制算力成本的核心工程手段。
经过工业界近两年的快速迭代，大模型推理缓存已经从单一的KV Cache，演进为包含Prefix Cache、Prompt Cache、Semantic Cache在内的四层结构化体系。四类缓存分别对应不同的计算复用粒度与匹配逻辑，不存在替代关系，在不同层级解决推理效率问题，共同构成端到端的推理加速栈。
本文将逐一拆解四类缓存的技术本质、核心矛盾与工程落地方法，分析不同缓存之间的协同关系，最终给出分层缓存架构的设计原则与实践方法论。全文聚焦工程可落地的技术细节，不涉及过度理论化推导。
第一章 大模型推理缓存的底层逻辑
1.1 自回归推理的计算冗余根源
Transformer解码器的自注意力机制是大模型生成能力的核心，也是计算冗余的来源。自回归生成模式下，每输出一个新token，都需要将历史所有token与当前token共同输入注意力层，计算对应的查询、键、值向量，再通过注意力加权得到输出。
在原生实现中，每生成第n个token，都会重新计算前n-1个历史token的键值矩阵。这部分计算在每一步生成中完全重复，上下文长度越长，重复计算量越大。当上下文长度达到128K时，单步生成中99%以上的计算量都消耗在历史token的键值计算上。缓存技术的核心目标，就是消除这部分重复计算，让历史计算结果可以被后续步骤直接复用。
1.2 缓存技术的分类维度
大模型推理缓存可以从两个核心维度划分：复用粒度与匹配方式。
按复用粒度从细到粗，可分为四级：
- token级：单token对应的键值对，对应KV Cache
- 前缀级：一段连续前缀文本对应的全部计算结果，对应Prefix Cache
- 完整Prompt级：整个输入Prompt对应的前向计算结果，对应Prompt Cache
- 语义级：语义相近的一类Prompt对应的结果，对应Semantic Cache
按匹配方式，可分为精确匹配与语义匹配两类。前三者均属于字面精确匹配，只有文本完全一致才能命中；Semantic Cache属于语义匹配，基于向量相似度判断是否可复用。
1.3 缓存体系的根本矛盾
所有缓存技术都遵循同一个底层矛盾：复用粒度与命中率的反向关系。这一逻辑可以通过学生备考做题的场景直观对应：缓存粒度对应背诵内容的颗粒度，命中率对应考试中可复用的概率。
一方面，缓存粒度越细，单条缓存覆盖的计算量越小，但匹配条件越宽松，命中率越高，适用场景越广。就像学生背诵的是单步解题演算，单次只能省下一步计算的时间，但只要题目推进到对应步骤就能复用，几乎不会失效。
另一方面，缓存粒度越粗，单条缓存节省的计算量越大，但匹配条件越严格，命中率越低，仅适合特定场景。就像学生背诵的是一整套完整试卷的标准答案，单次可以直接完成全部作答、省下全部思考时间，但只有试卷原题一字不差出现时才能使用，题干稍有改动就完全失效。
四层缓存体系的设计逻辑，就是在这个矛盾轴上找到多个平衡点，通过层级组合覆盖不同场景，在整体上实现收益最大化。
第二章 KV Cache：最基础的计算复用单元
2.1 定义与本质
KV Cache是大模型推理的标配基础优化，没有任何一款推理框架会省略该功能。其核心逻辑是：将每一步注意力计算得到的键矩阵与值矩阵保存下来，后续生成新token时，直接读取历史KV，仅计算当前token的KV，再拼接完成注意力计算。
开启KV Cache后，每步生成的计算量不再随上下文长度线性增长，而是保持恒定。上下文越长，KV Cache带来的加速效果越明显。对于128K上下文的推理场景，KV Cache可以将单步计算量降低两个数量级以上。
这一机制就像学生做试卷时，每完成一步演算就记录结果，后续步骤直接读取，无需重复计算。
2.2 核心矛盾
KV Cache面临两个对立统一的核心矛盾。
第一个矛盾是显存占用线性增长与推理显存预算有限的矛盾。KV Cache的显存占用与上下文长度、模型层数、注意力头数、隐藏层维度正相关。以7B模型、FP16精度为例，每1K上下文的KV Cache占用约16MB显存，128K上下文就需要2GB显存。当单卡承载多并发请求时，KV Cache的总显存占用会远超模型参数本身，成为显存瓶颈。
第二个矛盾是精度压缩与生成质量稳定性的矛盾。为降低显存占用，工业界普遍对KV Cache做量化压缩。但量化会引入数值误差，随着上下文长度增加，误差会逐层累积，最终可能导致生成逻辑混乱、重复输出等质量问题。显存占用与生成质量构成了KV Cache的核心权衡点。
2.3 主流解决方法
针对显存占用矛盾，目前工业界有两类成熟方案。
第一类是架构层面的优化，通过减少KV头数压缩总量。典型代表是多查询注意力（MQA）与分组查询注意力（GQA）。MQA将所有注意力头共享同一组KV，GQA则将头分组，每组共享一组KV。GQA在精度损失极小的前提下，可将KV Cache总量降低到原有的1/4到1/8，是当前大模型的主流架构选择。
Meta发布的LLaMA 2系列模型（34B与70B版本）即采用GQA架构，将KV头数缩减为8组，在模型困惑度仅上升1.2%的前提下，获得了2.7倍的解码速度提升，成为工业界平衡精度与效率的标准参考方案。
第二类是工程层面的优化，核心是分页式注意力（PagedAttention）。其借鉴操作系统虚拟内存的思路，将KV Cache切分为固定大小的内存块，每个请求的KV Cache由多个物理不连续的块组成。该机制彻底解决了原生KV Cache的显存碎片问题，将显存利用率从通常的40%-60%提升到90%以上，同时支持请求间的灵活复用。
该算法由UC Berkeley提出并在vLLM推理框架中首次工程化实现，目前已成为几乎所有主流推理框架的标准KV Cache管理方案。
针对精度矛盾，主流方案是精细化量化策略。采用逐通道量化、分组量化等方式，降低量化误差；同时支持动态精度切换，短上下文场景使用INT4量化，长上下文场景自动切换为INT8或FP16，在显存与质量间取得动态平衡。测试数据显示，合格的INT4 KV Cache量化，可将显存占用降低50%，同时模型困惑度（PPL）上升控制在3%以内，业务层面无感知。
NVIDIA TensorRT-LLM推理引擎原生支持FP8与NVFP4两种精度的KV Cache量化，采用分组量化与逐通道缩放技术，在Blackwell架构GPU上可将KV Cache显存占用再降低50%，同时保持生成质量稳定。
2.4 工程落地细节
2.4.1 显存占用计算公式
KV Cache的显存占用可通过以下公式精确计算：
显存占用(字节) = 2 × 层数 × 上下文长度 × 头数 × 头维度 × 字节数
其中系数2对应K和V两个矩阵，字节数由精度决定，FP16为2，INT8为1，INT4为0.5。
以7B模型为例，32层，32头，头维度128，128K上下文，FP16精度下，KV Cache总占用为64GB。如果采用GQA架构，8组KV头，则总量变为原来的1/4，即16GB；若再采用INT4量化，则进一步降至4GB。
2.4.2 分页式管理的实现要点
分页式KV Cache的核心是块分配器。每个块的大小是关键参数，块太大容易造成内部碎片，块太小则管理开销上升。工业界常用的块大小为16或32个token。
块分配器需要维护空闲块链表，请求到达时按需分配，请求结束后回收。支持共享块机制，当多个请求共享前缀时，可指向同一个物理块，仅在写入新KV时触发写时复制。这也是Prefix Cache的底层实现基础。
2.4.3 量化的落地注意事项
KV Cache量化需要配合推理框架的算子实现，并非简单的数值转换。INT4量化通常采用分组量化，每128个元素共享一组缩放因子，保证精度的同时控制开销。
量化的精度损失在长文本生成、代码生成等对数值敏感的场景会更明显，需要针对具体业务做效果验证，不能盲目开启最高压缩比。
2.4.4 增量更新机制
KV Cache采用追加式更新，每生成一个token，只计算当前token的K和V，追加到缓存末尾，历史缓存不会被修改。这种特性决定了KV Cache天然支持流式生成，且更新开销极低。
2.5 本章要点
- KV Cache是所有大模型推理的基础优化，必须默认开启
- 显存占用与上下文长度线性相关，长上下文下是主要显存开销
- 分页式管理是当前最优的工程实现，可大幅提升显存利用率
- GQA架构+INT4量化是长上下文场景的标准组合，精度损失可控
- 量化策略需结合业务场景选型，对精度敏感的场景需提高位宽
第三章 Prefix Cache：前缀复用的结构化KV缓存
3.1 定义与本质
Prefix Cache是KV Cache的上层延伸，针对多个请求共享相同前缀文本的场景，将前缀对应的KV Cache整体缓存，所有匹配该前缀的请求直接复用这部分KV，无需重复计算。
与KV Cache的单请求内复用不同，Prefix Cache实现了跨请求的KV复用。其核心价值在于挖掘请求之间的公共部分，将单次计算的结果共享给多个请求使用。典型适用场景包括系统提示词、公共知识库前置内容、多轮对话的历史上下文等。
这就像学生记住了试卷前半段所有题目的解题过程，只要新试卷的开头题目完全一致，就可以直接从后半段开始作答。
3.2 核心矛盾
Prefix Cache的核心矛盾体现在两个层面。
第一个矛盾是前缀匹配的刚性与输入多样性的矛盾。原生Prefix Cache要求前缀字面完全一致才能命中，哪怕只差一个字符、一个空格，都无法复用。实际业务中的输入前缀往往存在细微差异，导致实际命中率远低于理论值。
第二个矛盾是缓存粒度与管理开销的矛盾。如果缓存完整的长前缀，大部分请求无法匹配，命中率低；如果拆分为过细的前缀块，缓存条目数量会指数级增长，索引查询与内存管理的开销大幅上升，甚至抵消缓存收益。
3.3 解决方法
针对匹配刚性问题，主流方案是最长前缀匹配与分块复用。不再要求完整前缀完全匹配，而是逐token比对，找到请求与缓存的最长公共前缀，复用对应长度的KV Cache，剩余部分单独计算。该机制可以最大化利用公共部分，提升缓存命中率。
vLLM推理框架的Automatic Prefix Caching（APC）功能即采用该方案，通过基于块的哈希映射实现最长前缀自动匹配，在长文档问答、多轮对话等场景可将前向计算耗时降低60%以上。
针对粒度与开销的矛盾，采用字典树（Trie）结构组织前缀缓存。每个树节点对应一个token的KV，从根节点到某一节点的路径对应一个前缀。所有公共前缀自动共享树节点，无需重复存储。该结构天然支持最长前缀匹配，查询复杂度与前缀长度线性相关，管理开销可控。
vLLM的前缀缓存实现采用分层哈希的类字典树结构，每个KV块通过前缀哈希值唯一标识，在支持并发写时复制的同时，将缓存查询开销控制在微秒级。
3.4 工程落地细节
3.4.1 字典树索引的实现
前缀缓存的字典树每个节点存储对应token的KV数据块指针，以及子节点映射。新请求到达后，从根节点出发，按token顺序遍历树，直到无法匹配为止，走过的路径就是可复用的最长前缀。
为降低内存占用，节点可以采用数组+哈希的混合结构，公共高频前缀用数组索引，低频后缀用哈希存储，平衡查询速度与内存开销。
3.4.2 写时复制机制
当共享前缀的请求生成新token时，不能直接修改公共节点，否则会影响其他请求。此时触发写时复制，复制需要修改的节点，生成新的分支，原有公共前缀保持不变。
该机制保证了多请求并发访问的安全性，同时最大化共享公共部分，是Prefix Cache支持并发的核心。
3.4.3 多轮对话场景的优化
多轮对话是Prefix Cache最典型的受益场景。每一轮对话的历史上下文都是下一轮请求的前缀，新的用户输入只是后缀。开启前缀缓存后，每一轮对话只需要计算新用户输入的KV，历史对话的KV全部复用，对话轮次越多，加速效果越明显。
实际落地中，需要注意对话历史的截断与更新，避免前缀无限增长导致显存溢出。通常会设置最大上下文窗口，超出部分自动截断。
3.4.4 与KV Cache的层级关系
Prefix Cache本质上是KV Cache的跨请求共享机制，底层存储的还是KV数据。一个请求的KV Cache由两部分组成：可复用的前缀KV（来自Prefix Cache）和动态生成的后缀KV（普通KV Cache）。两者逻辑上连续，物理上可以分属不同的内存块，通过分页式管理无缝拼接。
3.5 本章要点
- Prefix Cache实现跨请求的KV复用，适合存在大量公共前缀的场景
- 字典树结构+最长前缀匹配是当前最优的实现方案
- 多轮对话与系统提示词是两大核心受益场景
- 写时复制是并发安全的基础保障
- 命中率取决于请求间前缀的公共程度，需结合业务特征评估收益
第四章 Prompt Cache：完整Prompt的端到端计算缓存
4.1 定义与本质
Prompt Cache缓存的是整个输入Prompt经过模型前向传播后的完整计算结果，不仅包含KV Cache，还涵盖嵌入层输出、各层注意力输出、前馈网络中间结果等。当完全相同的Prompt再次请求时，直接读取缓存结果，跳过整个Prompt的前向计算，直接开始生成第一个token。
相比Prefix Cache的部分复用，Prompt Cache是全量复用，单条缓存的计算节省量更大。对于长度为10K的Prompt，命中Prompt Cache可以跳过全部10K token的前向计算，首token延迟可降低90%以上。
就像学生完整背下了一整套试卷的全部题目与标准答案，遇到完全相同的试卷时可以直接誊写答案，无需任何思考。
4.2 核心矛盾
Prompt Cache面临两个核心矛盾。
第一个矛盾是低命中率与高计算收益的矛盾。Prompt Cache要求完整Prompt字面完全一致才能命中，而实际业务中用户输入的重复率通常很低，导致命中率普遍不高。但一旦命中，就能节省全部Prompt的计算开销，单条收益远高于其他缓存。高收益与低命中率构成了Prompt Cache的核心权衡。
第二个矛盾是大容量缓存与存储成本的矛盾。完整Prompt的计算结果数据量远大于纯KV Cache，一个10K长度的Prompt，完整缓存可能达到数百MB。如果缓存大量Prompt，存储成本会快速上升，甚至超过节省的算力成本。
4.3 解决方法
针对命中率低的问题，核心手段是Prompt标准化预处理。对输入Prompt做归一化处理，包括去除首尾空格、统一换行符、标准化标点符号、排序无关参数等，将语义等价但格式不同的Prompt转化为完全相同的字面形式，提升匹配率。
对于模板化业务场景，采用模板与参数分离的方案。固定模板部分永久缓存，每次请求只传入动态参数，仅计算参数部分的前向传播，模板部分直接复用。该方案可以将模板类请求的命中率提升到接近100%。
Anthropic Claude API与OpenAI API均原生支持Prompt Caching功能，通过cache_control标记可缓存的前缀块，自动识别重复的系统提示词与模板内容。其中Anthropic对缓存命中的输入token仅收取10%的费用，OpenAI对缓存token提供50%-90%的价格折扣，在长上下文、多轮对话等场景可大幅降低调用成本。
针对存储成本问题，采用冷热分层存储。热数据放在显存中，命中可直接使用；冷数据放在内存或磁盘中，命中后再加载到显存。同时设置缓存淘汰策略，优先淘汰访问频率低、计算量小的缓存条目，控制总存储量。
vLLM推理引擎的BlockPool缓存管理器采用两级存储策略，热KV块常驻显存以保证命中速度，冷块根据LRU策略自动换出到主机内存，在保留90%以上命中性能的同时，将显存占用峰值降低40%以上。
4.4 工程落地细节
4.4.1 缓存键的生成
缓存键通常采用Prompt文本的哈希值，常用SHA-256算法。生成哈希前必须做标准化处理，否则格式差异会导致大量缓存失效。
标准化规则需要结合业务场景制定，比如代码场景需要保留缩进，而文本问答场景可以忽略多余空白。没有通用的标准化规则，适配业务才能最大化命中率。
4.4.2 缓存内容的裁剪
不需要缓存所有层的所有计算结果，只需要缓存生成第一个token所需的最小数据集，通常就是各层的KV Cache以及最后一层的隐藏状态。裁剪后缓存体积可降低60%以上，且不影响功能。
本质上，裁剪后的Prompt Cache就是完整Prompt对应的KV Cache，与Prefix Cache的区别仅在于粒度：一个是完整Prompt，一个是任意前缀。
4.4.3 淘汰策略选型
常用的淘汰策略包括LRU（最近最少使用）、LFU（最不经常使用）以及基于价值的淘汰。基于价值的淘汰综合考虑缓存的计算节省量、访问频率、存储大小，计算每条缓存的投入产出比，优先淘汰比值最低的条目，更适合大模型缓存场景。
4.4.4 与Prefix Cache的区别与联系
两者都属于KV级别的缓存复用，核心区别在于复用粒度与匹配逻辑：
- Prefix Cache是前缀匹配，支持部分复用，粒度灵活，命中率高，单条收益低
- Prompt Cache是完整匹配，必须全量复用，粒度固定，命中率低，单条收益高
实际系统中，两者通常共用底层KV存储，Prefix Cache覆盖前缀场景，Prompt Cache覆盖全量重复场景，互为补充。
4.5 本章要点
- Prompt Cache单条收益最高，但命中率受输入重复度限制
- Prompt标准化是提升命中率的核心手段，需结合业务定制规则
- 模板化业务场景收益最显著，可接近100%命中
- 冷热分层+价值淘汰是控制存储成本的标准方案
- 底层可与Prefix Cache共享KV存储，减少冗余
第五章 Semantic Cache：语义层面的泛化复用
5.1 定义与本质
Semantic Cache突破了字面匹配的限制，基于文本的语义相似度判断是否可以复用缓存结果。其将用户请求转换为语义向量，与缓存库中的向量做相似度比对，超过设定阈值则判定为命中，直接返回缓存的生成结果或中间计算状态。
这是四层缓存中泛化能力最强的一层，能够将语义相近的一类请求对应到同一份缓存，理论命中率远高于精确匹配类缓存。其本质是将计算复用的粒度从文本级别提升到了语义级别。
就像学生不背具体题目，而是掌握一类题型的通用解法，只要题目考点一致，哪怕题干表述不同，也可以直接套用解题思路。
5.2 核心矛盾
Semantic Cache的核心矛盾也体现在两个维度。
第一个矛盾是匹配精度与检索性能的矛盾。语义匹配的精度越高，需要的向量维度越高、检索算法越复杂，检索延迟就越大。如果检索延迟超过了缓存节省的计算时间，缓存就失去了意义。精度与性能构成了语义缓存的首要权衡点。
第二个矛盾是语义相似性与结果一致性的矛盾。语义相近的Prompt，对应的标准答案未必完全相同。直接复用缓存结果可能出现答非所问、信息偏差等问题，影响输出质量。泛化能力越强，结果不一致的风险就越高。
5.3 解决方法
针对精度与性能的矛盾，工业界普遍采用两阶段匹配方案。第一阶段用向量检索快速召回Top-K候选缓存，使用轻量级Embedding模型和向量索引，保证检索速度；第二阶段用更精准的交叉编码器或字面规则做精排，筛选出真正可复用的缓存条目。两阶段方案在保证精度的同时，将检索延迟控制在毫秒级。
Cloudflare AI Gateway的语义缓存功能即采用该架构，第一阶段通过托管Embedding模型生成向量并快速召回，第二阶段结合字面规则做精确校验，在全球边缘节点实现亚50毫秒的缓存命中延迟。
针对一致性矛盾，采用分层匹配与阈值控制。将Prompt拆分为意图部分和参数部分，只有意图完全匹配、参数语义等价时才判定命中；同时设置严格的相似度阈值，低于阈值的请求坚决不命中，宁可错过也不错误复用。对于高一致性要求的场景，还可以增加结果校验环节，命中后由轻量模型验证答案是否匹配当前请求。
Redis官方推出的语义缓存方案即采用该机制，基于Redis Stack的向量检索能力实现两阶段匹配，支持按业务场景配置相似度阈值与过期策略，同时兼容多种Embedding模型与向量索引，是工业界落地最广泛的开源语义缓存实现方案。
5.4 工程落地细节
5.4.1 向量模型选型
Embedding模型的选择直接决定语义匹配的效果。需要综合考虑精度、速度、向量维度三个因素。工业界常用的轻量级模型如bge-small-zh，向量维度384，中文语义效果优秀，推理速度快，适合作为召回阶段的向量模型。
不建议使用大维度的重型Embedding模型，检索与生成向量的开销会大幅抵消缓存收益。
5.4.2 相似度阈值设定
相似度阈值是语义缓存的核心参数，需要根据业务场景调优。阈值太高，命中率低，缓存收益小；阈值太低，错误命中率上升，影响业务质量。
通用场景下，余弦相似度阈值通常设置在0.85-0.9之间。高一致性要求的场景如客服问答、知识查询，可提升到0.92以上；创意生成、闲聊等低风险场景，可放宽到0.8。阈值调整需要配合灰度测试，逐步找到收益与质量的平衡点。
5.4.3 两种缓存内容形态
Semantic Cache有两种缓存内容模式，适用于不同场景：
- 结果缓存：缓存最终的生成文本，命中后直接返回给用户。适合问答、科普等答案相对固定的场景，收益最大，但一致性风险最高。
- 状态缓存：缓存Prompt对应的KV Cache等中间状态，命中后继续生成后续内容。适合需要个性化输出、上下文相关的场景，收益稍低，但一致性风险小。
实际落地中可根据业务类型选择合适的模式，也可以两种模式混合使用。
5.4.4 缓存质量的闭环治理
语义缓存不可避免会出现错误命中，需要建立质量闭环治理机制。定期抽检命中结果的质量，收集用户反馈，对低质量的缓存条目自动降级或淘汰；同时持续优化Embedding模型与匹配规则，不断提升匹配精度。
对于高风险场景，语义缓存建议仅作为辅助加速手段，不直接返回最终结果，而是复用中间计算状态，由模型继续生成，保障输出质量。
5.5 本章要点
- Semantic Cache基于语义匹配，泛化能力最强，是缓存技术的前沿方向
- 两阶段检索是精度与性能的平衡方案，召回+精排的组合最常用
- 相似度阈值需结合业务场景灰度调优，没有通用最优值
- 结果缓存收益高但风险大，状态缓存更稳妥，需按需选型
- 必须建立质量闭环机制，持续治理错误命中问题
第六章 四层缓存的协同架构与落地策略
6.1 分层缓存的整体架构
四类缓存并非孤立存在，而是构成自上而下的四层递进缓存体系。从上层到下层依次为：Semantic Cache、Prompt Cache、Prefix Cache、KV Cache。
越上层，复用粒度越粗，单条缓存的计算节省量越大，但匹配条件越严格，命中率越低；越下层，复用粒度越细，单条收益越小，但匹配条件越宽松，命中率越高。上层未命中的请求向下传递，由下层缓存继续兜底，最终所有请求都会落到KV Cache层。
这种层级结构兼顾了高收益与高覆盖，在整体上实现投入产出比最大化。
6.2 请求命中流转流程
一个请求到达推理服务后，缓存命中的完整流程如下：
- 语义匹配层：将请求转换为语义向量，查询Semantic Cache。命中则根据缓存模式直接返回结果或加载中间状态；未命中则进入下一层。
- 完整匹配层：对请求做标准化处理，计算哈希值，查询Prompt Cache。命中则加载完整Prompt的计算结果，直接开始生成；未命中则进入下一层。
- 前缀匹配层：逐token匹配Prefix Cache的字典树索引，找到最长公共前缀，复用对应KV；未匹配到任何前缀则全部重新计算。
- 基础缓存层：生成过程中动态维护KV Cache，每步追加新的KV，保障生成效率。
请求处理完成后，根据缓存策略，将符合条件的结果分别写入各层缓存，供后续请求复用。写入策略通常采用异步写入，避免阻塞当前请求。
6.3 典型场景的缓存组合
不同业务场景的请求特征不同，核心依赖的缓存层也不同，不存在通用的最优组合。
6.3.1 多轮对话场景
该场景的核心特征是上下文连续，每轮请求共享大量历史前缀。核心依赖Prefix Cache复用对话历史，KV Cache保障生成效率；Semantic Cache用于常见问题的快速回复，作为补充；Prompt Cache收益较低，因为完整重复的对话很少。
资源分配上，优先保障Prefix Cache的显存容量，预留足够的共享前缀空间。
6.3.2 开放API服务场景
该场景的核心特征是请求分散、类型多样，但存在大量重复的系统提示词和模板化请求。核心依赖Prompt Cache处理高频重复请求，Prefix Cache复用公共系统提示词，KV Cache作为基础。Semantic Cache可根据业务类型选择性开启，对于问答类API收益明显。
资源分配上，采用冷热分层，热Prompt缓存放显存，冷数据放内存，控制显存占用。
6.3.3 RAG问答场景
该场景的核心特征是查询语义趋同，且每个请求都会携带召回的文档作为前缀。核心依赖Semantic Cache匹配相似问题，Prefix Cache复用召回文档的公共部分，KV Cache保障生成。三层缓存协同，可大幅降低RAG场景的推理成本。
需要注意的是，RAG的文档内容会动态更新，Prefix Cache需要配合文档版本做失效处理，避免返回过期信息。
6.4 缓存体系的资源分配原则
缓存体系的资源分配需要遵循两个原则。
第一，投入产出比优先。优先将资源分配给命中率高、收益大的缓存层。对于大多数场景，KV Cache和Prefix Cache的收益最稳定，优先保障显存配额。
第二，动态调整。根据业务的请求特征变化，动态调整各层缓存的容量。比如业务高峰期请求重复率高，可扩大Prompt Cache容量；长上下文请求多，就扩大KV Cache的量化位宽，保障质量。
6.5 本章要点
- 四层缓存是递进互补关系，自上而下逐级兜底，整体收益最大化
- 请求流转遵循先粗粒度后细粒度、先高收益后低收益的原则
- 不同业务场景的核心缓存层不同，需针对性设计组合方案
- 资源分配以投入产出比为核心标准，优先保障高收益层
- 缓存写入采用异步方式，避免影响当前请求的延迟
第七章 缓存体系的评估方法与迭代方法论
7.1 核心评估指标
缓存体系的效果需要从效率、成本、质量三个维度量化评估。
效率指标包括：各层缓存命中率、首token延迟、平均生成速度、服务吞吐率。其中命中率是基础指标，但不能单独用命中率衡量效果，需要结合单条缓存的收益计算整体加速比。
成本指标包括：显存占用量、内存占用量、存储总成本、单位请求算力消耗。核心是单位请求的成本变化，缓存的最终目标是降低单位成本。
质量指标包括：生成结果与无缓存版本的相似度、模型困惑度变化、业务准确率、错误命中率。质量指标是底线，缓存优化不能以牺牲业务质量为代价。
7.2 效果量化方法
评估缓存效果最可靠的方法是AB对照测试。选取相同的流量，一组开启完整缓存体系，一组关闭缓存，对比两组的性能、成本、质量数据，计算缓存带来的净收益。
计算投入产出比时，需要综合考虑算力成本节省与存储成本增加。如果存储成本的增加超过了算力成本的节省，说明缓存体系过度设计，需要收缩。
还需要分长度段评估效果。短Prompt场景，缓存收益有限；长Prompt场景，缓存收益显著。分场景评估才能精准定位优化空间。
7.3 迭代优化路径
缓存体系的建设应该遵循从下到上、循序渐进的路径，不要一次性全部上线。
第一步，落地基础KV Cache，完成分页管理与量化优化，保障基础推理性能。这一步是所有缓存的基础，必须做扎实。
第二步，针对公共前缀场景上线Prefix Cache，优化字典树索引与最长前缀匹配，重点覆盖多轮对话、系统提示词等场景。
第三步，梳理业务中的高频重复请求与模板化请求，上线Prompt Cache，配套标准化预处理与淘汰策略。
第四步，针对语义趋同的查询场景，试点Semantic Cache，从小流量开始灰度，逐步调优相似度阈值与匹配规则，验证质量可控后再全量。
自下而上的迭代路径，每一步都有明确的收益，风险可控，避免盲目投入。
7.4 常见误区与避坑
第一个误区是盲目追求高命中率。命中率高不代表收益大。比如KV Cache命中率接近100%，但单条收益很小；Semantic Cache命中率可能只有10%，但单条收益是KV Cache的上百倍。评估缓存价值要看整体加速比与成本节约，而非单纯的命中率。
第二个误区是过度缓存导致成本倒挂。存储也是有成本的，如果缓存占用的显存、内存成本超过了节省的算力成本，缓存就失去了意义。需要定期核算投入产出比，及时淘汰低价值缓存。
第三个误区是忽略质量损失。量化误差、错误命中都会影响生成质量，尤其是长上下文与高一致性要求的场景。缓存优化必须以质量可控为前提，质量不达标，性能再高也没有业务价值。
7.5 本章要点
- 缓存效果需从效率、成本、质量三维度综合评估，不能只看命中率
- AB测试是量化收益的最可靠方法，需分场景细化评估
- 缓存建设遵循自下而上的迭代路径，先基础后高级，风险可控
- 避免陷入高命中率、过度缓存、忽略质量三大误区
- 定期核算投入产出比，动态调整缓存策略
结语
大模型推理的成本优化是一项系统工程，缓存技术是其中投入产出比最高的方向之一。从KV Cache的单请求内计算复用，到Prefix Cache的跨请求前缀复用，再到Prompt Cache的完整请求复用，最后到Semantic Cache的语义级泛化复用，四层缓存沿着复用粒度不断变粗的方向演进，本质是不断挖掘更深层次的计算冗余。
缓存技术的核心从来不是单纯的存储，而是对业务模式与请求特征的深度理解。没有任何一种缓存可以适配所有场景，只有结合业务特点，构建分层协同的缓存体系，持续迭代优化，才能在保障质量的前提下，最大化降低推理成本。
随着长上下文模型的普及与推理服务规模的扩大，缓存体系的价值会进一步凸显。未来的缓存技术会向更智能的语义复用方向发展，结合大模型自身的理解能力，实现更精准、更泛化的计算复用，持续推动大模型推理成本下探。
参考资料
1 vLLM官方博客：《vLLM:使用 PagedAttention 实现简单、快速且低成本的大模型服务》，https://blog.vllm.com.cn/2023/06/20/vllm.html
2 Meta官方论文：《Llama 2: Open Foundation and Fine-Tuned Chat Models》，https://arxiv.org/abs/2307.09288
3 vLLM官方文档：《Automatic Prefix Caching》，https://docs.vllm.ai/en/latest/features/automatic_prefix_caching/
4 Anthropic官方文档：《Prompt caching》，https://platform.claude.com/docs/en/build-with-claude/prompt-caching
5 OpenAI官方文档：《提示词缓存》，https://developers.openai.com/docs/guides/prompt-caching
6 NVIDIA官方文档：《Quantization in TensorRT LLM》，https://nvidia.github.io/TensorRT-LLM/latest/features/quantization.html
7 Cloudflare官方文档：《Control AI Search similarity cache freshness》，https://developers.cloudflare.com/changelog/post/2026-06-24-ai-search-similarity-cache-controls/
8 Redis官方文档：《Semantic Cache》，https://redis.io/docs/latest/develop/use-cases/semantic-cache/