一、前缀缓存：Token 序列的精确匹配

1. 前缀匹配的原理

前缀缓存（Prefix Caching）基于一个朴素事实：推理请求的开头部分高度重复。系统提示词（System Prompt）是每个对话的开场——"你是一个专业的编程助手""你是一位精通法律的顾问"——在成千上万次调用中完全相同。

前缀缓存的机制是：将请求的 Token 序列从第一个 Token 开始逐一与已缓存的序列做前缀匹配。匹配到的最长公共前缀对应的 KV Cache 可以直接复用，模型仅需计算从匹配结束点到请求末尾的增量部分。

举例来说，一条 1024 Token 的系统提示词被缓存后，所有以该提示词开头的请求都节省了 1024 个 Token 的 prompt 处理开销——对于一个 7B 参数的模型，这相当于节省了约 0.5 秒到 2 秒的首 Token 延迟。

2. 前缀缓存的存储结构

前缀缓存的数据结构选择直接影响匹配效率和内存占用。常见的实现方式是 Trie 树（前缀树）与哈希表的组合：

• Trie 树将 Token 序列组织为树形结构，每个节点代表一个 Token，从根到叶子节点的路径就是一条完整的 Token 序列。前缀匹配在 Trie 树上沿着路径逐 Token 深入，时间复杂度为 O(前缀长度)，非常高效。

• 哈希表存储从"Token 序列哈希值"到"KV Cache 位置"的映射。当 Trie 树遍历到某个节点时，用该节点的序列哈希值查询哈希表，获取对应的 KV Cache 数据指针。

Trie 树本身的节点数量随缓存的 Token 总量线性增长。对于一个缓存了百万级请求的服务（每个请求约 2000 Token），Trie 树约有 20 亿个节点——内存占用在 GB 级别。为了控制内存开销，可以在 Trie 树的较深节点上做剪枝：对访问频次低于阈值的深层节点不保留缓存，仅缓存访问热门的浅层前缀。

3. 命中率与缓存策略

前缀缓存的命中率取决于用户请求的前缀共性。在典型的企业应用场景中（客服、代码助手、文档问答），系统提示词固定不变，前缀缓存的命中率可以达到 70% 以上。在开放域对话场景中，前缀差异较大，命中率显著降低。

缓存淘汰策略的选择也影响命中率。LRU 策略淘汰最久未使用的前缀节点，适合访问模式相对集中的场景。LFU 策略淘汰访问频次最低的节点，适合长尾请求较多但核心前缀较为固定的场景。实践中可结合两者——对浅层节点（前缀长度小于 128 Token）使用 LFU 保留高频基础前缀，对深层节点使用 LRU 响应近期的访问热点。

二、语义缓存：超越精确匹配的近似复用

1. 语义相似度匹配

前缀缓存的局限在于它只做精确匹配——Token 序列必须逐 Token 一致才能命中。"今天天气怎么样"和"今天天气好吗"尽管语义一致，但 Token 序列不同，前缀缓存无法匹配。语义缓存通过将查询文本映射到向量空间做相似度检索，弥补了精确匹配的这一盲区。

语义缓存的工作流程分为缓存写入和缓存查询两路：

写入路径：当推理服务产生一个输出后，将输入文本的嵌入向量与输出文本一同写入语义缓存库。向量作为查询键，输出文本作为缓存值。

查询路径：新请求到达时，先计算输入文本的嵌入向量，在缓存库中检索余弦相似度超过阈值（如 0.95）的最近邻条目。命中后直接返回缓存的输出文本，跳过模型推理。

2. 相似度阈值的工程调优

相似度阈值是语义缓存的核心参数。阈值设定过低（如 0.85），命中率高但可能返回语义不够匹配的缓存结果——用户问"苹果股价"，返回了关于"苹果公司历史"的缓存回答。阈值设定过高（如 0.98），命中率太低，缓存的收益有限。

一个实用的策略是分层阈值：在安全敏感的场景（如医疗、法律咨询）中使用较高阈值（0.97+），在容错性较高的场景（如闲聊、创意写作）中使用适中阈值（0.90-0.95）。此外，缓存条目可以携带"缓存输出是否经过人工确认"的标记——经确认的高质量缓存可以容忍略低的相似度阈值。

3. 语义缓存与生成式推理的组合

语义缓存的理想场景是"请求与已缓存请求高度相似但又不完全一致"。缓存命中后，不一定要直接返回缓存输出——可以将缓存输出作为"初始草稿"，模型仅做少量修改和校准，推理的 Token 生成量从数百 Token 减少到数十 Token。这种"缓存辅助生成"模式在保持回答质量的同时，仍能节省绝大部分推理成本。

三、KV Cache 的跨请求复用

1. KV Cache 复用的粒度

KV Cache 是 Transformer 解码过程中保存的每层每个位置的 Key 和 Value 矩阵，是前缀缓存在显存层面的具体实现。跨请求复用 KV Cache 的粒度决定了复用的效率：

• 完整复用：两个请求的前缀完全相同，KV Cache 从第一个 Token 到匹配结束点全部复用；

• 局部复用：两个请求共享部分位置（如多轮对话中共享历史消息），复用对应的 KV Cache 片段；

• 跨请求共享池：多个并发请求共享同一套系统提示词的 KV Cache——一份 KV Cache 数据，多个请求共同引用，而非各自复制。

2. 引用计数与生命周期管理

跨请求共享 KV Cache 需要解决的核心问题是生命周期管理——当引用某份 KV Cache 的所有请求都完成时，该份 KV Cache 应当被释放。引用计数是解决这一问题的经典机制：

每份共享的 KV Cache 维护一个引用计数器。新请求引用时加一，请求完成时减一。计数器归零时，显存被回收。引用计数在并发环境下的原子性操作是工程上需要小心处理的地方——加减操作需要保证线程安全，计数器的读写需要使用原子指令或锁机制。

3. 缓存预热的调度协同

KV Cache 的命中不仅取决于缓存本身的设计，也与请求的路由策略密切相关。如果将同一个用户的多轮对话请求路由到不同的 GPU 节点上，每次都需要重新构建 KV Cache。如果将同一用户或同一对话会话的请求通过一致性哈希路由到固定节点，KV Cache 的命中率可以大幅提升。

缓存预热是更深层的协同：在流量低谷期，将高频系统提示词对应的 KV Cache 提前构建到各 GPU 节点的显存中。请求到达时，KV Cache 已经就绪，首 Token 延迟中的 prompt 处理时间为零。

推理服务的缓存层级设计是一个从"精确到近似、从单请求到跨请求"的递进体系。前缀缓存覆盖了精确匹配下的最大复用空间，语义缓存将复用边界拓展到近似语义，KV Cache 的跨请求复用在显存层面将一份缓存数据服务于多个请求。三个层级自上而下，在不同粒度上压缩重复计算，最终实现推理服务算力成本和用户体验的双重优化。