Prefix Cache 能解决哪些重复计算问题，实际部署时应该怎样考虑缓存命中率

大语言模型推理过程中，有一类计算非常容易被重复执行。用户向模型发送请求时，如果大量请求拥有完全相同的前缀，例如统一的系统提示词、固定的角色设定、企业知识库的公共上下文或者相同的长篇文档，那么模型每次处理这些请求时，都可能重新执行一遍这部分输入的 Prefill 计算。Prefix Cache 的作用，就是把已经完成的前缀计算结果保存下来，当后续请求使用相同前缀时直接复用，从而减少重复的 Prefill 计算。

理解 Prefix Cache，首先要把它和普通意义上的文本缓存区分开。大语言模型采用 Transformer 架构进行推理，输入 token 经过多层 Transformer 计算后，会形成供后续注意力计算使用的 Key 和 Value。对于已经完成 Prefill 的前缀，这些 KV 数据可以保存下来。后续请求只要从相同的 token 前缀继续生成，就可以复用对应位置已经计算好的 KV Cache，而不必重新处理整个前缀。

因此，Prefix Cache 更准确地说是对前缀对应 KV Cache 的复用机制，而不是简单地把“隐藏状态”序列化后放进一个普通缓存系统。不同推理框架在具体实现上会有所不同，例如可以按照固定大小的 token block 管理 KV Cache，也可以采用类似分页内存的方式组织缓存。工程实现通常会把前缀切分成若干可复用的块，并通过哈希、token 序列或者其他索引信息判断后续请求是否能够复用已有数据。

这种机制对于长上下文应用尤其有价值。假设一个企业客服系统每次请求都带有一份几千甚至上万个 token 的系统提示、产品知识和业务规则，而真正变化的只是用户最后提出的问题。如果每个请求都重新执行完整 Prefill，大量 GPU 计算实际上是在重复处理完全相同的内容。Prefix Cache 可以把公共前缀计算保留下来，让后续请求从已经计算完成的位置继续执行。

这里必须区分 Prefill 和 Decode。Prefill 主要负责处理用户已经输入的 prompt，在这一阶段模型需要一次性处理大量输入 token，并建立对应的 KV Cache。Decode 则是在已有上下文基础上逐步生成输出 token。Prefix Cache 最直接的收益来自减少重复 Prefill，而不是简单地让每一个 Decode token 都变得更快。

这也是为什么 Prefix Cache 对长 prompt、固定系统提示词、RAG 公共上下文、代码生成模板以及多轮对话中的重复上下文比较有价值。如果一个请求的大部分 prompt 都是全新的，而且不同用户之间没有稳定的公共前缀，那么缓存就很难产生明显收益。

Prefix Cache 能否发挥作用，关键指标之一是缓存命中率。不过工程上不能只看一个简单的“命中率百分比”。至少应该同时观察命中的 token 数量、每次命中的前缀长度、节省的 Prefill 时间以及由此减少的 GPU 计算量。一个系统即使拥有很高的请求命中率，如果每次命中的前缀只有几十个 token，而完整 prompt 有数万个 token，实际收益可能并不大。相反，一个命中率并不特别高的系统，如果每次命中都能够复用数千甚至数万个 token，也可能节省大量 GPU 时间。

因此，更有价值的指标是“命中了多少前缀 token”。例如，一个请求总共有 12,000 个输入 token，其中 10,000 个 token 可以从 Prefix Cache 中复用，那么它与一个只命中 500 个 token 的请求，即使都被统计为一次 cache hit，实际产生的性能收益完全不同。

Prefix Cache 的命中通常也不能简单理解为“语义相似就可以命中”。大多数实际系统需要的是 token 级别的前缀匹配。两个意思非常接近但 token 序列不同的 prompt，并不会因为语义相似就自动共享同一份 KV Cache。比如两个系统提示词只是修改了几个词，或者 JSON 字段顺序发生变化，都可能导致后续 token 序列不同，从而影响缓存复用。

这对应用层设计非常重要。如果系统提示词每次请求都动态插入时间、随机 ID、用户信息或者不断变化的字段，那么原本可以共享的公共前缀可能被人为切断。工程上通常会尽量把稳定内容放在前面，把变化内容放在后面，使多个请求拥有尽可能长的共同 token 前缀。对于 RAG 系统也是如此，如果检索结果每次都完全不同，缓存收益会受到限制；如果存在稳定的公共文档、固定指令和长期不变的知识上下文，则更容易形成可复用前缀。

缓存容量也是部署时必须解决的问题。KV Cache 并不是免费的数据。模型层数、KV head 数量、head dimension、数据类型以及前缀长度都会影响缓存所需要的显存容量。上下文越长、并发请求越多，KV Cache 的占用就越明显。Prefix Cache 如果长期保留大量前缀，就可能与正在运行的请求争夺 GPU 显存。

因此，缓存策略不能只追求“缓存越多越好”。缓存容量不足时，需要淘汰低价值条目；容量过大时，则可能挤占运行时 KV Cache 和其他 GPU 资源，甚至导致显存压力增加。工程系统通常会结合 LRU、访问频率、前缀长度、计算成本以及最近访问情况进行淘汰，而不是简单按照缓存条目数量管理。

还有一个容易被忽略的问题，就是缓存价值与前缀长度有关。一个只访问过一次、长度为几十个 token 的前缀，和一个每天被数万次访问、长度达到数千 token 的前缀，对系统的价值完全不同。后者占用更多缓存空间，但同时可以避免更多重复计算。因此成熟的缓存策略往往需要考虑“缓存占用多少空间”和“能够节省多少计算”之间的关系。

模型版本也是 Prefix Cache 的重要边界。只要产生 KV Cache 的模型计算环境发生影响结果的变化，原来的缓存就不能继续盲目复用。例如模型权重发生变化、LoRA 或其他 Adapter 发生变化、部分位置编码配置发生变化，或者影响 Transformer 计算结果的推理配置发生变化，都可能使旧缓存失效。因此，缓存键通常不能只包含 prompt 内容，还需要能够区分模型版本和相关运行配置。

这也是 Prefix Cache 与普通 Redis、Memcached 文本缓存存在明显区别的地方。普通缓存主要保存业务数据，而 Prefix Cache 保存的是与特定模型计算状态相关的数据。它必须知道这些数据属于哪个模型、哪个版本以及什么运行环境。否则一旦不同模型或者不同适配器错误共享 KV Cache，得到的结果就可能出现严重问题。

分布式部署又会带来另一个问题。假设一个推理集群拥有十几台 GPU 服务器，如果同一个用户的连续请求随机分配到不同节点，那么某个节点刚刚建立的 Prefix Cache 可能无法被另一个节点直接使用。此时有几种常见思路，包括请求路由保持一定的节点亲和性、每个节点维护本地 Prefix Cache，或者建立跨节点共享缓存。

但跨节点共享并不意味着一定要建立一个庞大的集中式缓存池。KV Cache 数据量可能非常大，而 GPU 内存、主机内存、PCIe、网络带宽和访问延迟都会影响实际收益。如果为了得到一次缓存命中，需要从远程节点传输大量 KV 数据，那么节省掉的 Prefill 计算可能被网络传输时间抵消。因此，分布式 Prefix Cache 的设计不能只看“缓存是否共享”，还要计算缓存传输成本。

在很多场景中，本地 GPU Cache 配合请求路由反而可能更加简单。系统可以尽量让拥有相同公共前缀的请求进入同一推理实例，让缓存随着工作负载自然形成。如果业务流量高度集中于少数固定 prompt，这种方式可能已经能够取得相当不错的收益。

Prefix Cache 还需要与 Continuous Batching 等调度机制一起考虑。在线推理系统不是简单地一个请求进来、一个请求处理完再处理下一个请求，而是会持续把不同阶段的请求组织到 GPU 上执行。此时 Prefix Cache、运行中的 KV Cache、最大并发序列数、最大 batch token 数以及 GPU 显存之间存在直接关系。

如果缓存占用了大量显存，新的请求可能因为 KV Cache 空间不足而降低并发能力。反过来，如果缓存容量太小，大量重复前缀无法保存，又会增加 Prefill 计算。最终需要优化的不是单独的 cache hit rate，而是整个推理服务的吞吐、TTFT、ITL、P50、P95 和 P99 延迟。

其中 TTFT，也就是 Time to First Token，对 Prefix Cache 特别敏感。对于拥有超长公共前缀的请求，Prefix Cache 可以显著减少首次生成 token 之前需要执行的 Prefill 工作，因此可能明显改善用户等待第一 token 的时间。Decode 阶段的每 token 延迟则主要受到模型计算、KV Cache 访问、显存带宽、批处理规模以及调度方式等因素影响，不能把 Prefix Cache 的收益简单等同于整体 token 生成速度提升。

量化也可以与 Prefix Cache 配合使用，但两者解决的问题不同。模型量化主要减少模型权重和部分计算资源的占用，而 KV Cache 的量化则涉及缓存本身的数据表示。是否适合量化 KV Cache，需要结合模型、推理框架、硬件以及精度要求测试，不能简单认为“量化以后缓存就一定更快”。

实际部署时，比较可靠的方式是先测量工作负载，再决定缓存策略。首先统计不同请求的 prompt 长度以及公共前缀长度，然后观察前缀重复程度，再测试不同缓存容量下的命中 token 数量、Prefill 时间、GPU 显存占用和端到端延迟。对于在线服务，还应该同时观察 P95 和 P99，而不能只看平均延迟。

如果测试发现大多数请求只有很短的公共前缀，那么投入大量 GPU 显存维护 Prefix Cache 的意义可能有限。如果大量请求都包含相同的长系统提示词或者公共知识上下文，那么 Prefix Cache 的价值就会明显提高。对于企业内部 AI 助手、代码生成、文档分析、客服系统和固定模板推理等业务，这类特征尤其常见。

Prefix Cache 还有一个重要的工程原则，就是不要为了提高命中率而牺牲应用设计的稳定性。为了让缓存命中而强行改变 prompt 结构、把大量动态数据塞到固定前缀区域，可能让系统变得难以维护。缓存应该适应业务请求模式，而不是让整个业务架构围绕缓存进行重构。

从成本角度看，Prefix Cache 的收益最终可以转化为更低的 GPU 计算需求、更高的有效吞吐或者更低的首 token 延迟。如果一台 GPU 服务器每天处理大量拥有相同长前缀的请求，那么重复 Prefill 本身就是一笔持续发生的计算成本。能够复用这些已经完成的计算，就等于把原本重复消耗的 GPU 资源转化为可以服务更多请求的容量。

但如果请求高度个性化、前缀几乎从不重复，或者缓存命中后还需要进行大量数据搬运，那么 Prefix Cache 的收益就可能非常有限。此时增加缓存容量甚至可能让系统变得更加复杂，却没有产生相应的性能收益。

Prefix Cache 的工程价值因此不能用一个固定的命中率数字判断。真正应该回答的是三个问题：业务请求到底有多少重复前缀，每次命中能够节省多少 Prefill 计算，以及保存这些缓存需要付出多少 GPU 显存和系统管理成本。只有把这几个因素放到同一个性能模型里，才能判断缓存究竟是在提高推理效率，还是仅仅增加了系统复杂度。

对于大模型推理服务而言，Prefix Cache 最适合被看成整个推理优化体系中的一个组件。它解决的是重复前缀导致的 Prefill 重算问题，而不是解决所有推理性能问题。模型量化、Continuous Batching、Paged KV Cache、请求调度、GPU 显存管理、并行策略和网络拓扑仍然需要根据实际工作负载分别优化。一个设计良好的推理系统，不会只追求更高的缓存命中率，而是通过测量公共前缀长度、命中 token 数、显存成本、Prefill 节省量以及端到端延迟，判断 Prefix Cache 是否真正改善了单位 GPU 资源能够承载的业务量。