1.3 LLM 缓存四层版图

1.3 LLM 缓存四层版图

本节摘要：上一节把浪费锁定在重复 Prefill，本节给出回收它的全景地图。按"缓存放在哪、由谁管理、活多久"三个标准，LLM 缓存可分为四层：显存层 KV Cache、框架层前缀复用、平台 API 层 context caching、应用层语义缓存。每层用"缓存键、缓存值、命中收益"三元组刻画，本节的对照表是后续章节的索引，末尾的命中判定规则则交给 1.4 节展开。

给缓存版图分层，复用机会才看得全

浪费的位置已经锁定——每轮重算不变的前缀。但"加个缓存"并不是单一动作：同一份前缀，可以在显存里、在推理框架里、在云平台 API 里、在应用代码里被复用，四处的键不同、值不同、省下的钱也不同。不分层地谈"LLM 缓存"，讨论很快会变成鸡同鸭讲；分层的目的是给每项技术一个明确的位置坐标，让"键是什么、值是什么、命中后免掉什么"有处安放。

分层依据是三问：缓存存放在哪一层基础设施？由谁管理它的生命周期？它能活多久？按这三问切下去，得到四层。

显存层 KV Cache。最内层，位于单次推理进程内部。模型对输入序列做 Prefill 时，每个 token 在每层注意力里产生的键向量和值向量都被留下来，供 Decode 阶段反复查询。严格说它是推理的中间结果而非狭义缓存——没有"查找键"这个动作，只有"随请求生灭"的工作集。它的收益是让 Decode 每步免于重算全部历史，没有它，自回归生成根本跑不起来。生命周期与请求绑定，请求结束即释放，默认不做跨请求复用。

框架层前缀复用。当推理框架接管显存管理，跨请求的复用才成为可能。vLLM 的 PagedAttention 借鉴操作系统分页机制，把 KV 切成固定大小的分页，使相同前缀的请求能指向同一批物理分页；SGLang 的 RadixAttention 更进一步，把 KV 组织成基数树，以 token 前缀为路径共享，命中即整段跳过 Prefill。这一层的键是按块对齐的 token 前缀，值是显存中的 KV 分页，失效来自前缀不匹配或显存压力下的淘汰。

平台 API 层 context caching。使用托管 API 而非自建推理时，前缀复用被平台封装成产品能力：各家大模型 API 的 context caching、prompt caching 都属此类。键要求是逐字一致的前缀并绑定模型版本，值是服务端保留的 KV 状态，命中后输入按折扣计价、首 token 提速。失效来自前缀改动、TTL 过期或模型版本变更。它的特殊之处在于：开发者看不到 KV，只能通过"把稳定内容放前面"来间接利用它。

应用层语义缓存。最外层，键换成了查询的嵌入向量，用相似度阈值判定命中，值是完整的生成结果，命中即跳过整次推理。它不再关心前缀——两个问题可以一字不差地不同却命中同一条缓存。收益最大，风险也最大：答案的时效性、个性化与模型更新都可能让旧答案变成错误答案。

四层三元组对照表

这张表藏着一条规律：越往下（靠近显存），命中越确定、收益越小、键越严格；越往上，收益越大、命中条件越苛刻、误命中风险越高。前三个精确匹配层的键都是"前缀"，差别只在对齐粒度与管理主体；应用层把精确匹配放宽为语义近似，换来的是收益最大的"免整次推理"，代价是必须单独兜底答案质量。四层不是互斥的选型，而是可以叠加的过滤网——请求先过应用层，再过平台层，再进框架层，最后落到显存层，任一层命中都能免掉下层的计算。

关于收益叠加，有一个容易算错的地方。四层同时命中时，收益取最大者而非累加：应用层命中直接返回答案，下层根本不会被问到，此时"免整次推理"已经包含了"免重复 Prefill"；反过来，应用层未命中而平台层命中，省的是重复 Prefill 的钱，输出照常计费。真正能叠加的是部分命中——平台层命中了系统提示词那 2500 token，框架层又命中了历史对话里的 8000 token，两者拼起来免掉的是 Prefill 的不同区段，互不重复。给每层估值时可以用同一个公式：一次命中的价值等于被免掉的输入 token 数乘以每 token 的 Prefill 成本，再加上被免掉的等待时间折算的体验收益；唯一例外是应用层，它额外免掉了输出侧的算力，价值要按整次调用计。这套算法会在第 6 章的成本模型里反复用到。

语义缓存会取代前缀缓存吗

不会，因为它们在赌不同的东西。前缀缓存赌的是"同一段上下文会被反复请求"——系统提示词、文档、历史对话，赌注几乎必赢，命中确定性极高；语义缓存赌的是"不同的问题需要同一个答案"——赌注命中率取决于问题的多样性与阈值的松紧，答错的风险永远存在。工程上的正确姿势是分层布防：前缀类缓存作为保底，吃掉所有结构性的重复；语义缓存作为加速层，只在高频、低风险、答案稳定的问题域开放，且必须带相似度阈值、时效字段和人工兜底通道。把语义缓存当成唯一的缓存方案，等于放弃了那些"键严格但必赢"的复用机会；把所有赌注都压在前缀缓存上，则放弃了问题层面的复用。两层的分工在 1.3 的对照表里已经写明，第 4 章会展开语义缓存的攻防细节。

一个请求在四层间的下沉路径

导读那张图是读者视角的学习路径，这张图换成了请求视角：一个请求进来，自上而下逐层检查，任一层命中即沿回收路径返回，全部未命中才回源到模型计算。

图 1-3：四层缓存版图分层架构图

沿这张图看请求的一生：先问应用层"这个问题最近是不是答过"；再问平台层"这段前缀在服务端还有没有热的 KV"；再问框架层"这批 token 前缀在显存里有没有现成分页"；最后落到显存层，请求内的 KV 供 Decode 逐步复用。每下探一层，命中的确定性变高、免掉的计算变少——应用层命中省一整次推理，显存层命中只省一次注意力的重复计算，但后者几乎是必然发生的。

案例复盘：RAG 问答系统的四层盘点

背景：某企业知识库问答系统，提示词由三段拼成——固定的系统规则（约 2500 token，含公司制度说明）、检索出的知识片段（每次不同，约 1500 token）、用户问题。日均 8000 次调用，输入侧月成本居高不下，团队想知道缓存还能从哪里抠出空间。
操作：按四层版图逐层盘点可复用资产。显存层：请求内 KV 由推理引擎自动管理，无需动作。框架层：自建推理服务开启前缀复用，并把提示词顺序调整为"系统规则、用户问题、检索片段"，让跨请求不变的部分落在最前面。平台层：若未来迁移到托管 API，2500 token 的固定规则段就是标准的前缀缓存标的。应用层：统计发现"年假怎么算""报销流程是什么"这类高频问题占约两成，适合加一层带阈值兜底的语义缓存。
结果：调整顺序后，框架层前缀命中使每请求约 2500 token 的 Prefill 被免除，首 token 延迟下降约四成；语义缓存上线后约 18% 的请求直接返回，整体输入成本下降约三成。
解读：显存、框架、平台三个精确匹配层的键都是"逐字前缀"，因此提示词的排列顺序直接决定命中率——稳定内容前置、易变内容靠后，是所有前缀类缓存通用的布局法则。应用层不受前缀约束，但它绕过了模型，答案质量风险要单独兜底：相似度阈值、答案有效期、敏感问题白名单缺一不可。
变式：把检索片段移回提示词前部——很多人本能地"先给材料再给问题"——框架层命中率立刻归零，因为每次检索结果不同，前缀从中间就断开了。这个变式预告了下一节的主题：LLM 缓存的键与 URL 那种无序字符串有本质区别，它对位置极度敏感；命中、未命中与失效的规则，也随之要重新推演。