大模型服务的缓存体系：前缀缓存与语义缓存

两种「缓存」，别混为一谈

LLM 推理又贵又慢：每个请求都要对提示词的每个 token（词元，模型处理文本的最小单位）做一遍计算，而生产环境的请求高度重复——同样的系统提示、同样的 few-shot 示例（在提示词里给模型看的输入输出范例）、相似的用户问题。缓存因此是成本优化的第一杠杆。但社区里说的「LLM 缓存」其实是两种完全不同的东西：前缀缓存工作在推理引擎内部，语义缓存工作在应用层。机制、收益、风险都不同，用错场合会出事故。

前缀缓存：KV Cache 的复用

先补一个背景：LLM 处理提示词时，会为每个 token 计算一组中间结果（Key/Value 向量），合称 KV Cache（键值缓存）。自回归生成的每一步都要用到这些中间结果，所以正常流程是每个请求都把完整提示词算一遍——推理里从读入提示词到产出第一个 token 的阶段叫预填充（prefill），这部分开销与提示词长度成正比。

前缀缓存利用了一个事实：如果两个请求的开头完全相同——例如都带着同一段两千 token 的系统提示——那么这段开头的 KV Cache 是一样的，可以直接复用，不必重算。命中后，首 token 延迟与提示词部分的预填充成本都会大幅下降。主流推理框架（vLLM 等）都内置了这类机制。

工程要点由此而来：

稳定内容放开头，动态内容放结尾。 系统提示、few-shot 示例、长文档固定在前，用户问题与时间戳这类每次不同的内容放最后。前缀中间插一句不一样的话，后面全部缓存作废。
多请求会话亲和。 同一用户的连续请求若被负载均衡分到不同实例，缓存就白搭了。让会话尽量落在同一实例（亲和调度）能显著提高命中率，这是网关层的能力，见本站网关一文。
提示词模板化时注意变量外提，把变化的部分集中到尾部，别散落在前缀各处。

前缀缓存几乎无风险——复用的只是确定性的计算结果，输出与不缓存完全一致，属于「开了就赚」的优化。

语义缓存：按「意思」命中

另一种思路工作在应用层：问题进来，先向量化，与历史问题算相似度；超过阈值（相似度门限）就直接返回当时的答案，一次模型调用都不发生。想命中的情形是同义改写——换个说法问同一件事；想避开的情形是形似神异——问法很像、答案不同。而相似度算法区分这两者的能力有限，这正是风险根源。

「ATM 机取不出现金怎么办」与「ATM 吞卡了怎么办」相似度不低、答案却完全不同。语义缓存错误命中时返回的，是一条语气笃定的错误答案——这比多花钱严重得多。

两者对比

维度	前缀缓存	语义缓存
所在层级	推理层（引擎内部）	应用层（模型调用之前）
命中条件	提示词前缀逐字相同	语义相似度超过阈值
命中收益	首 token 延迟与预填充计算大降	完全省掉一次模型调用
失效风险	几乎没有（确定性复用）	相似但不同义的问题被错答
适用场景	几乎所有生产服务	高频重复的事实型问答

语义缓存的正确姿势

如果评估后仍要用，几条纪律：

只缓存事实型问答（「营业时间是几点」），不缓存开放生成类（「写一段文案」）。
缓存条目带引用与时效标记，如「答案基于 2026 年 6 月的价格」，过期主动失效。
阈值从严，宁可命中率低也不能错答——错答的代价是信任，信任比 token 贵。
高频 FAQ 场景收益最大：客服系统里头部问题往往覆盖大部分流量，这种分布对语义缓存最友好。

一笔定性的成本账

缓存收益大致可以这么估：节省的成本 ≈ 命中率 × 被命中请求的成本。前缀缓存的命中率取决于提示词的重复程度——固定系统提示越长、会话越连续，命中率越高，长系统提示的对话服务收益尤其明显。语义缓存的命中率取决于问题的集中度。两层叠加时注意先后：语义缓存命中在前，直接短路整个调用；未命中的请求再享受前缀缓存——两层是相乘的关系，不是二选一。

小结

先做前缀缓存：调整提示词结构（稳定前缀加动态尾部）、配上网关会话亲和，零风险拿确定收益。语义缓存按场景评估：只在高频事实型问答上、用严格阈值、带时效标记地做，拿不准就不做。缓存优化的顺序，应该是从「绝对安全」到「需要权衡」逐级推进。