Prefix Caching（前缀缓存）
Prefix Caching相同 system prompt 只算一次
亦作、亦称：前缀缓存 · Prefix Caching · KV Cache Prefix Sharing · Automatic Prefix Caching · APC
Prefix Caching（前缀缓存） 是推理引擎层在多个请求间自动共享相同 token 前缀 KV Cache 的优化机制——与 API 层 Prompt Caching（计费折扣）不同，它发生在引擎内部，通过 Radix Tree 或 Hash 索引匹配前缀并复用已计算的 KV 向量。
机制：推理引擎层的前缀复用
Prefix Caching 的核心是在推理引擎内部对多个并发请求的 token 前缀做匹配和复用：
- 每个请求进入引擎后，引擎将 token 序列按前缀拆分（如 system prompt + few-shot examples + user query）
- 通过 Radix Tree（SGLang）或 Hash 索引（vLLM）检查该前缀是否已被其他请求计算过 KV Cache
- 命中时直接复用已计算的 KV 向量，仅对新增 token 做 prefill 计算
- 未命中时正常计算并将结果存入缓存供后续请求复用
命中场景：多个请求共享相同 system prompt、RAG 系统中相同的检索上下文前缀、Agent 系统中重复的工具调用上下文。vLLM 的 --enable-prefix-caching 和 SGLang 的 RadixAttention 默认启用此优化。
与 API 层 Prompt Caching 的区别
API 层 Prompt Caching（Anthropic / OpenAI）：
- 面向 API 用户的计费特性——缓存命中的 token 享受 50-90% 折扣
- 缓存管理由 Provider 内部完成，用户通过
cache_control标记或自动触发 - 本质是 Provider 内部 Prefix Caching 的商业化暴露
引擎层 Prefix Caching（vLLM / SGLang）：
- 面向自部署推理的性能优化——减少 GPU 计算量、降低 TTFT
- 用户通过
--enable-prefix-caching或框架配置启用 - 缓存粒度更细（token 级前缀匹配），支持跨请求、跨 batch 共享
两者底层机制相同（前缀匹配 + KV 复用），但暴露层不同：API 层关注成本，引擎层关注性能。
生产实现与选型
主流实现：
- vLLM：
--enable-prefix-caching启用自动前缀缓存，基于 Hash 匹配，支持跨请求共享 - SGLang RadixAttention：基于基数树（Radix Tree）索引，前缀匹配更精确，支持 LRU 驱逐策略，聊天机器人 / RAG 场景缓存命中率 75-95%
- LMCache：开源分布式前缀缓存，支持跨实例、跨节点共享 KV Cache，适合多副本部署
- TensorRT-LLM：支持 in-flight prefix caching，与 continuous batching 协同
选型要点：
- 自部署场景优先启用引擎层前缀缓存（零代码改动，仅配置）
- RAG / Agent / 共享 system prompt 场景收益最大（TTFT 降低 30-90%）
- 短请求、无共享前缀的场景收益有限
- 与 KV Cache 量化（FP8/INT8）协同可进一步降低缓存显存占用
常见误解
日常交流中容易听到的简化说法，未必准确，但能帮助理解误解从何而来。
- 「相同 system prompt 只算一次」
- 「推理引擎层的 KV Cache 前缀复用」
相关术语
和本术语关联紧密的其他词条，便于串联理解。
🎯 考点练习
含该术语的高频面试题，含标准答案与追问。
- 初级概念高频查看详解 →
什么是大语言模型（LLM）？它能做什么、不能做什么？
LLM 是基于 Transformer、在海量文本上预训练的自回归语言模型，擅长语言任务，但不擅长精确计算、实时信息，且会产生幻觉。
- 高级系统设计查看详解 →
当 LLM 上下文窗口达到 1M token 时，"Lost in the Middle" 效应对 RAG 系统设计有何影响？如何工程化缓解？
即使上下文窗口达到 1M token，"Lost in the Middle"（Liu et al. 2023）与 Context Rot（Chroma 2026）仍使模型对中间位置信息的利用率显著下降——标称容量不等于有效容量。RAG 系统不能把检索结果无脑堆叠进超长上下文，而须做检索重排（首尾优先）、分层上下文预算（工作记忆 vs 长尾知识）、分块聚合（map-reduce）与位置探针评测。本题考察候选人能否把位置偏置从论文概念转化为 RAG 工程约束。
- 高级系统设计查看详解 →
基准污染诊断：当 SWE-bench Verified 得分异常高但实际能力不匹配时，如何系统性诊断并调整评估策略？
OpenAI SWE-bench Verified 审计发现 59.4% 任务存在缺陷，前沿模型被检测到从训练数据中召回答案（adwaitx.com 2026-02 技术分析）。当模型在基准上得分异常高（如 80%+）但实际能力不匹配时，候选人需要展示三条独立诊断路径（n-gram overlap 精确重叠、embedding similarity 语义重叠、ablation study 因果归因）的交叉验证能力，以及污染确认后从「单一基准分数」转向「基准组合 + 私有评测 + 过程评估」的评估策略重构能力。本题区分「会跑 benchmark」与「理解 benchmark 为什么可信」的候选人。
- 高级概念查看详解 →
在 MoE 模型的大规模部署中，Expert Parallelism 面临哪些工程挑战？请从负载均衡、通信开销、故障恢复三个维度分析。
Expert Parallelism 把 MoE 专家分布到多 GPU 以突破单卡显存上限，但 Top-K 路由导致负载不均、All-to-All 通信跨节点成为瓶颈、Expert 级 checkpoint 与弹性恢复比 Dense 模型更复杂。
延伸阅读
从知识库精选 2 篇文章，帮助深入理解该术语。
- 1
KV Cache 管理：从 PagedAttention 到动态压缩的全栈技术
KV Cache 是 LLM 推理的核心瓶颈——它占用 60-80% 的 GPU 显存并随序列长度线性增长。本文从 Transformer 注意力机制的 KV Cache 原理出发，系统讲解 PagedAttention 的分页管理、KV Cache 量化（FP8/INT8）、动态驱逐与压缩、Prefix Caching、三级存储层次（GPU HBM → CPU DRAM → NVMe SSD），以及 vLLM/SGLang/TensorRT-LLM 三大引擎的工程实现对比。
- 2
Prompt Caching 工程决策：从 Provider 机制到生产部署的完整框架
任何生产 LLM 应用每月 API 账单超过 $500 的团队，都可以通过 prompt caching 系统性降低 50-90％ 的输入成本。本文从 Provider 层缓存机制出发，覆盖 Anthropic/OpenAI/Gemini 三大平台的实现差异、breakeven 分析、cache-friendly prompt 设计、生产监控，以及常见陷阱，给出可直接落地的工程决策框架。
外部参考
维基百科：查看「Prefix Caching」词条本页内容为本站原创撰写；维基百科链接仅作延伸参考。