Prefix Caching：LLM 推理中的前缀缓存机制
Prefix Caching 是 LLM 推理中的前缀缓存方法。它通过 KV Cache 复用机制减少公共提示词重复计算，适合多轮对话、固定 System Prompt 与长上下文推理。
什么是 Prefix Caching？
Prefix Caching，也称前缀缓存，是 LLM 推理阶段的一种缓存优化方法。它缓存请求中公共前缀对应的 KV Cache 或 KV 缓存块；当后续请求共享相同前缀时，系统可以复用已有缓存，避免重复计算同一段提示词。
这里的“前缀”通常指请求开头稳定不变的内容，例如 System Prompt、工具定义、历史上下文或长文档片段。Prefix Caching 不是训练方法，也不是模型微调技术，而是围绕推理过程中的中间结果复用，来降低延迟和计算开销。
要点： Prefix Caching 缓存的不是最终回答文本，而是模型处理公共前缀时产生的 KV Cache。后续请求命中前缀后，仍需要继续计算新增输入并生成新的回答。
可以把它理解为：模型第一次“读完”一段公共材料后，系统保存了这段材料在推理中的中间状态；之后遇到同样开头的请求，就不必从头再处理这段公共材料，而是从已保存的状态继续向后推理。
为什么 LLM 推理需要前缀缓存？
许多 LLM 应用的请求并不是完全独立的。它们往往包含大量重复前缀，只是用户最后的问题或补充信息不同。如果每次请求都重新计算这些公共前缀，就会产生冗余的提示词计算。
常见的重复前缀包括：
- 固定的 System Prompt，例如角色设定、输出格式、回答规范；
- 工具调用场景中的 Tool Schema 或工具说明；
- 多轮对话中反复携带的历史上下文；
- 围绕同一篇长文档、同一份知识材料发起的多次提问。
Prefix Caching 的价值在于把这些公共部分的计算结果复用起来。当前缀命中缓存时，系统可以减少重复计算，从而有助于降低首 token 延迟，并减少推理阶段的计算开销。
| 问题 | 没有前缀缓存时 | 使用 Prefix Caching 后 |
|---|---|---|
| 公共前缀重复出现 | 每次请求都重新计算 | 命中后复用已有 KV Cache |
| 首 token 生成等待 | 需要先处理完整前缀 | 可跳过部分前缀计算 |
| 长上下文反复提问 | 重复处理相同文档内容 | 更适合复用相同文档前缀 |
| 推理计算开销 | 重复内容越长，冗余越明显 | 公共前缀越稳定，复用价值越高 |
KV Cache 复用机制如何工作？
Prefix Caching 的核心，是跨请求复用公共前缀对应的 KV Cache。KV Cache 是模型在推理过程中为已处理 token 保存的中间状态；如果多个请求拥有相同前缀，这部分中间状态就有机会被后续请求复用。
基本流程
首次请求计算公共前缀
当某个请求第一次进入系统时，模型会正常处理其中的前缀内容，并生成对应的 KV Cache 或 KV 缓存块。此时还没有可复用结果，系统需要完整计算这一段前缀。
系统缓存前缀对应的 KV Cache
前缀被处理后，系统会将其对应的 KV Cache 保存下来。缓存的粒度可能是完整前缀，也可能是按缓存块组织的前缀片段，具体取决于推理框架或服务实现。
后续请求检查是否共享相同前缀
当新请求到来时，系统会判断它是否与已有请求共享相同前缀。常见实现会通过前缀内容或缓存块标识来判断是否命中；部分实现资料中也提到过基于哈希的方法。
命中后复用缓存，只计算新增部分
如果新请求的前缀命中已有缓存，系统可以直接复用对应的 KV Cache，并从新增输入的位置继续推理。这样就避免了对公共前缀的重复计算。
自动前缀缓存 APC 的含义
Automatic Prefix Caching，简称 APC，通常指系统自动缓存现有查询的 KV Cache，并在新查询与已有查询共享相同前缀时自动复用。它强调的是缓存命中和复用过程由推理系统处理，应用侧不一定需要手动管理每一段前缀缓存。
需要注意的是，APC 的有效性仍然依赖前缀是否真的相同或稳定。如果请求开头频繁变化，即使启用了自动前缀缓存，也不一定能获得明显复用收益。
哪些请求更容易命中前缀缓存？
Prefix Caching 更适合公共前缀稳定、重复出现，且前缀较长的请求。下面是几类典型场景。
| 场景 | 用户需求 | 解决方式 | 可能效果 |
|---|---|---|---|
| 多轮对话 | 连续对话中需要携带历史上下文 | 缓存历史对话前缀对应的 KV Cache | 后续轮次更容易复用已有上下文计算结果 |
| 固定 System Prompt | 同一应用使用相同角色设定和回答规范 | 将稳定的系统指令作为公共前缀复用 | 减少固定指令的重复计算 |
| Tool Schema | 工具调用请求反复携带工具定义 | 复用工具定义或 Schema 的前缀缓存 | 降低工具说明部分的重复处理开销 |
| 长文档问答 | 围绕同一篇长文档发起多次提问 | 缓存文档上下文对应的 KV Cache | 多次提问时减少相同文档内容的重复计算 |
多轮对话
在多轮对话中，历史消息经常会作为上下文随新问题一起传入模型。如果多次请求中有相同的历史前缀，Prefix Caching 就可能复用这些历史上下文对应的 KV Cache。
固定 System Prompt
很多应用会在每次请求前放入相同的 System Prompt，例如限定语气、角色、任务范围或输出格式。这类内容稳定且位于请求前部，通常是较容易被前缀缓存利用的部分。
Tool Schema
在工具调用或 Agent 场景中，工具名称、参数说明、Schema 定义等内容可能被反复传入模型。如果这些内容作为公共前缀保持一致，就适合通过 Prefix Caching 减少重复处理。
长文档上下文
当用户围绕同一篇长文档连续提问时，文档内容可能在多个请求中重复出现。若文档片段位于请求前缀且保持一致，前缀缓存可以复用其 KV Cache，只让模型继续处理新的问题部分。
前缀缓存与普通缓存有什么区别？
Prefix Caching 容易被误解为普通的问答缓存，但两者的缓存对象和命中逻辑并不相同。
| 对比维度 | Prefix Caching | 普通结果缓存 |
|---|---|---|
| 缓存对象 | 公共前缀对应的 KV Cache 或缓存块 | 已生成的最终回答或接口返回结果 |
| 命中条件 | 新请求与已有请求共享相同前缀 | 请求或缓存键与历史记录匹配 |
| 命中后的行为 | 继续推理新增部分并生成回答 | 可能直接返回已有结果 |
| 主要价值 | 减少前缀部分的重复计算 | 避免重复执行完整任务 |
| 适用边界 | 对相同或稳定前缀更有效 | 对完全重复问题更有效 |
因此，Prefix Caching 不能简单理解为“相似问题就一定会命中”。它关注的是请求开头的公共前缀是否可复用，而不是两个问题在语义上是否相似。
例如，两个用户都在问同一类问题，但 System Prompt、上下文文档或工具定义不同，前缀缓存可能无法命中。反过来，如果两个请求共享很长的相同文档前缀，即使最后的问题不同，也可能通过复用 KV Cache 获得收益。
使用 Prefix Caching 时如何判断是否合适？
在工程实践中，是否应该重点使用 Prefix Caching，可以先从请求结构和业务目标判断。
适合优先考虑的情况
- 请求中存在稳定、重复的公共前缀；
- 应用经常使用固定 System Prompt 或工具 Schema；
- 用户会围绕同一段历史对话或同一篇长文档连续提问；
- 业务关注首 token 延迟；
- 推理成本中有较多来自重复前缀计算的开销。
收益可能有限的情况
- 每次请求的开头都不同，公共前缀很少；
- 重复内容不在前缀位置，难以作为前缀复用；
- 请求很短，重复计算本身占比不高；
- 应用更需要缓存最终答案，而不是复用推理中间状态。
落地前需要继续评估的问题
Prefix Caching 的基本机制比较清晰，但实际效果还取决于具体推理系统的实现。落地前应进一步评估以下工程问题：
- 缓存容量是否足够容纳常见公共前缀；
- 缓存失效策略如何设计；
- KV Cache 占用的内存是否可接受；
- 并发请求下缓存命中和复用是否稳定；
- 请求模板是否能保持公共前缀一致。
要点： Prefix Caching 是针对公共前缀复用的优化，不是通用加速开关。前缀越稳定、越重复、越长，越容易体现它在延迟和计算开销上的价值。