1. 多轮对话越聊越慢重复 prefill 才是真正的成本黑洞做 LLM 推理服务的人应该都有这个体感单轮请求的时延很好控但一进入多轮对话会话越聊越长响应越来越慢显存也越来越紧张。用户反馈里最典型的一句话就是前面几轮还好聊到十几轮就开始转圈圈了。这个问题的根源不在模型本身而在推理服务对历史上下文的处理方式。大模型推理通常分成 prefill 和 decode 两个阶段prefill 阶段要把用户输入的所有 token 并行计算一遍生成每个 token 对应的 K、V 向量也就是 KV Cache并缓存下来decode 阶段则基于 KV Cache 逐个生成新 token。理论上只要服务端支持把历史轮次的 KV Cache 保留在显存里新一轮请求就不需要把整个会话从头再算一遍。但真实生产环境没有那么理想。很多业务场景的服务端并不做严格的逐轮 KV Cache 维护要么把完整对话历史重新拼接后整段传给模型要么因为部署架构的原因导致前缀缓存无法命中。这种情况下每一轮新请求都会把之前所有轮次的 token 重新做一遍 prefill。会话越长重复计算的量越大。1.1 KV Cache 的显存账本为什么长会话会拖垮资源先算一笔显存账。以一个 7B 规模、隐藏维度 4096、32 层、每层 32 个注意力头的模型为例在 FP16 精度下每个 token 的 KV Cache 大约占 512KB 显存32 层乘以 32 个头乘以 128 维再乘以 2 份 K/V 和 2 字节精度。这意味着上下文长度单会话 KV Cache 显存占用估算100 个并发会话512 token约 256MB约 25GB2048 token约 1GB约 100GB8192 token约 4GB约 400GB这个量级说明两个问题第一长会话的 KV Cache 本身就昂贵第二如果每一轮都重新 prefill 全部历史那不只是浪费显存而是在成倍地浪费算力。假设一个会话平均 2000 token用户每轮新输入只有 100 token那么模型实际有效计算量中的 95% 都花在历史 token 的重复计算上。我之前在内部做过一次简单的 trace 统计在一个模拟的助手型产品里大约有 23% 的请求在语义上和历史轮次高度近似——用户换了个措辞问同一个问题或者把之前的请求微调后重发甚至直接复制粘贴追问。这些请求本不该重新消耗一次完整推理。1.2 精确缓存为什么救不了多轮场景最直观的办法是做精确匹配把整个对话上下文的文本拼起来算一个哈希再存一个 KV Cache 索引。下一次请求如果哈希值完全一致就直接复用缓存。这个方案在单元测试里看起来很合理一上线就露馅。因为真实用户不会原封不动地重复一句话哪怕只是把谢谢改成非常感谢把标点从半角变成全角哈希值就完全变了。更不用说多轮对话里大量出现的指代和改写比如用户上一轮说帮我对比这三款手机下一轮补充顺便加上那个红色那款这里的那款需要结合历史上下文才能理解成某具体型号。字符串层面完全匹配是不可能的。精确前缀缓存则更脆弱它不仅要求当前轮文本一致还要求之前所有轮次逐字一致。只要用户在第三轮把问题改了一个字第四轮开始之前共享的上下文就无法复用了。这也是我决定做语义缓存这个方向的原因KV Cache 解决的是 token 级的重复计算但语言表达的多样性让 token 级复用永远存在盲区。真正想降低多轮推理的成本和时延需要在更抽象的语义层去做匹配。2. SmartCache 的缓存键设计从 token 哈希到分层语义指纹明确了目标之后第一个要解决的问题是缓存键到底应该是什么。在单轮语义缓存的常见做法里直接用当前用户问题文本的 embedding 做检索命中就返回缓存答案。这个思路搬到多轮对话上会立刻出问题——多轮请求的语义不在当前这一句话里而在系统提示词 历史对话 当前问题的组合中。2.1 为什么缓存键不能只包含当前问题举一个我在实测中遇到的真实案例。用户先问周末去杭州玩三天预算五千以内帮我排一个行程助手给出行程后用户追问那家酒店的早餐值不值得吃。单独对那家酒店的早餐值不值得吃做 embedding模型根本不知道那家酒店指哪个向量也会落在完全无关的空间里。如果把整个历史对话拼在一起做 embedding又会出现另一个问题历史越长语义越被稀释。前五轮都在聊旅行第六轮突然问明天的会议纪要帮我整理一下全量拼接后的 embedding 大概率会漂移到旅行主题附近检索结果完全不可用。我在 SmartCache 里采用的做法是分层语义指纹把多轮上下文拆成粗粒度的结构化标签和细粒度的向量两个层级分别承担范围过滤和语义近似的职责。2.2 粗粒度标签可解释的硬过滤条件粗粒度标签是从上下文中抽取的结构化信息通常是 JSON 形式包括几个核心字段意图域比如旅行规划代码生成文档总结售后咨询。任务骨架描述整个多轮会话在围绕什么主线进行例如用户要求推荐杭州市区酒店并对比价格。活跃实体集合当前会话中仍然生效的地名、人名、商品名、数字约束等。变更指令标志这一轮是否包含不要改成加上去掉这类会让旧答案失效的变更指令。话题切换标记判断当前问题和最近历史是否属于同一主题如果是突然切换旧缓存必须全部失效。标签的作用是做硬过滤。向量相似度再高如果意图域不同或者活跃实体集合冲突就不该命中。比如用户问帮我写一封请假邮件和帮我写一封投诉邮件两者的 embedding 距离很近但意图域和应用结果完全不同必须通过标签提前排除。2.3 细粒度向量裁剪后的上下文编码细粒度向量负责在同一个主题范围内做近似匹配。这里的关键不是对全部历史做 embedding而是构造一个上下文编码视图规则很简单系统提示词单独截断到最近 512 字符参与向量化避免模型指令的冗长描述干扰语义历史对话按轮次压缩每轮只保留说话人身份 核心要点发言人标记user/assistant会作为前缀拼进文本当前用户的原始输入全量参与并且在组合时抬高权重——我可以把当前问题在文本里重复一遍比如按当前问题 当前问题 截断历史的拼接方式让模型注意力天然偏向最新意图超过 embedding 模型最大长度时优先丢弃最老的、与当前主题标签无关的轮次而不是简单从头截断。2.4 embedding 模型的选型与归一化多轮对话场景对 embedding 模型的要求和通用检索不太一样。通用 embedding 擅长捕捉单句语义但对谁在什么时候说了什么这种带角色的结构不敏感。我在实践中的处理是不追求超大模型选一个百 MB 量级、支持较长输入序列的通用 encoder 就够关键是做好文本归一化。我用的归一化包括统一说话人分隔符、把系统消息里频繁变化的指令模板做脱敏、将数字和单位统一格式、对用户消息不做任何改写直接在原文两侧加user:标记。这套操作比换一个更大更贵的 embedding 模型带来的收益稳定得多。3. 命中判定与三层安全网整体相似度并不等于答案可复用语义缓存最大的风险不是缓存 miss而是错误命中——返回了一个看似相关但实质错误的旧答案。这个风险在单轮缓存里已经存在在多轮上下文下会被放大因为多轮请求可以因为一个微小的变化就要求完全不同的答案。所以 SmartCache 把命中判定拆成三层候选召回、变更指令检测、答案校验。3.1 第一层标签预筛与向量召回查询先走粗粒度标签过滤。标签不匹配的候选直接丢弃然后在剩余候选中用向量检索取 top-k。这里我使用的是一个基于 HNSW 图索引的向量检索组件单个节点就能支撑百万量级指纹的召回P99 查询时延在 10 毫秒左右。相似度分数采用余弦相似度但分数本身不会直接当作命中依据而是映射成三个区间区间行为分数高于接受阈值直接命中缓存返回缓存答案分数高于候选阈值但低于接受阈值进入变更指令检测判定为半命中分数低于候选阈值判定为 miss走完整模型推理阈值具体取多少不能拍脑袋我会在第五部分专门讲调参时踩的坑和离线回放评估方法。3.2 第二层变更指令检测这是多轮语义缓存和其他缓存的核心差异假设用户上一轮问帮我推荐一款适合编程的轻薄本预算八千以内助手给出了答案。下一轮用户说预算提高到一万重量再轻一点。此时上下文整体相似度可能高达 0.90如果直接命中缓存返回的老答案完全无效。SmartCache 的做法是当候选分数落在半命中区间时先对当前用户输入做一轮轻量级变更意图分析。检测逻辑包括是否出现不要、取消、去掉、排除等否定型指令是否出现加上、补充、还有等新增型指令是否出现新实体、新数字约束并且和历史参数冲突是否出现话题切换信号比如突然从旅行跳到会议。如果确认没有任何变更指令走直接命中如果检测到变更走半命中路径保留历史上下文的 token 级 KV Cache 复用让模型只对新增和变化的片段做增量 prefill 和 decode。这个路径仍然能省掉大量重复计算。我在实现里甚至把变更指令检测做成了一个小模型分类器输入当前用户消息和候选缓存的上下文摘要输出一个是否修改历史上下文的三分类结果。实测比纯规则引擎的准确率高出不少。3.3 第三层答案级校验即使相似度分数很高、也没有明显的变更指令我仍然不直接信任缓存。答案级校验会抽取缓存答案中的关键信息点数字、名单、日期、清单项和当前请求的约束做一一比对。校验逻辑是硬规则如果用户当前请求里明确提到预算八千但缓存答案中推荐的产品价格区间超出这个范围校验一定失败。校验失败时的策略是降级不返回缓存直接走模型推理并把这条缓存的权重下调。这个设计很关键它可以保证语义缓存作为一个优化层不会把错误扩散到用户侧。4. 落地实现从缓存写入到召回验证的完整链路理论设计讲完说说工程落地。我把 SmartCache 做成一个独立的语义缓存服务挂在 LLM 推理网关旁路对业务侧透明。4.1 核心组件与请求流程服务内部有四个模块上下文签名器、向量索引、缓存存储、答案校验器。请求进来后的完整链路是网关收到多轮请求把当前会话的完整上下文交给上下文签名器签名器生成粗粒度标签 细粒度向量查询向量索引按标签过滤、向量召回 top-k 候选对候选做相似度区间判断和变更指令检测命中则通过答案校验器做关键信息比对通过后直接返回缓存答案未命中或校验失败则进入模型推理推理完成后把新结果写入缓存。缓存写入也有讲究。我在设计中采用延迟写入机制模型推理完成后先写入一个 pending 状态此时该记录不参与召回只有当用户没有发起重新生成或对结果做负面反馈时才在下一个时间窗口把状态置为 ready。这么做的原因是很多产品里用户会反复点击重新生成第一个结果未必是最终采纳的答案如果急着写缓存后续就会把垃圾答案反复曝光。4.2 缓存记录结构每条缓存记录大概长这样{ cache_id: fc3a8b..., context_fingerprint: sha256(system_version coarse_tags), coarse_tags: { intent_domain: travel_planning, active_entities: [hangzhou, 3_days, budget_8000], task_branch: hotel_recommendation, context_switch: false }, dense_vector_id: vec_7781f2, answer: { text: ..., key_facts: {budget: 7500, check_in_date: 2025-06-20} }, meta: { system_prompt_version: v3.1.0, ttl: 3600, hit_count: 128, feedback_score: 0.93, state: ready } }这里 context_fingerprint 不是全文本哈希而是系统版本 粗粒度标签的稳定哈希用来在系统升级或会话主题切换时快速失效整批缓存。dense_vector_id 指向向量索引中的浮点向量。key_facts 是一个很关键的结构化字段它让答案校验不再依赖重新解析自然语言而是直接比对结构化的关键约束。4.3 淘汰与失效策略缓存一定会脏关键是脏得可控。我用的淘汰策略有三条LRU 淘汰按命中率加权的 LRU长期不被命中的冷门上下文优先踢出TTL 失效不同意图域设置不同的生命周期比如天气和政策类缓存 TTL 很短攻略类和代码模板类可以长一些版本号失效系统提示词模板一旦升级所有旧记录通过 context_fingerprint 前缀全部失效避免模型行为变更后旧答案继续污染线上。另外用户在会话中明确说重新开始忘了之前的吧时网关会发送一个会话重置信号语义缓存层直接把该会话相关的记录全量标记为 invalid。这个信号比任何相似度算法都可靠因为它是我能把握的用户真实意图。4.4 监控指标别只盯着命中率语义缓存上线后最容易犯的错误是整天盯着命中率。我后来把监控面板换成四个指标组合hit_rate请求命中缓存的比例precisionhit抽样评估命中结果是否真的被用户采纳后续是否继续追问、是否修改而不是只看离线标注saved_tokens因为命中而避免重复 prefill 的 token 总量这是成本收益的核心指标cache_pollution一段时间内出现缓存返回后被用户纠正的比例这个指标比 hit_rate 更能在早期反映阈值失控。只用 hit_rate 做绩效考核团队一定会为了指标好看把阈值无限调低最后换来一堆错误复用的事故。5. 实测效果与三个典型调参踩坑SmartCache 在模拟项目 X 的离线会话集上做了回放测试又在两个内部业务场景里跑了小流量 A/B。先说结果再说踩过的坑。5.1 基线对比数据测试集包含 4 类多轮会话旅行规划、售后咨询、代码问答、文档改写每类各约 5000 条完整会话链。三组对照组是无缓存、精确字符串前缀缓存、SmartCache 语义缓存。方案端到端 P50 时延端到端 P95 时延缓存命中率答案采纳率抽样无缓存1.85s4.2s0%基准精确前缀缓存1.74s4.0s8.2%接近基准SmartCache 语义缓存0.91s2.1s26.7%略低于基准但差异不显著时延降低主要来自两处直接命中时省掉了完整 prefill 和大部分 decode半命中时虽然仍要走模型但历史上下文只做增量计算。P95 的改善比 P50 更明显因为长会话原本是时延拖尾的重灾区而语义缓存恰好最容易在长会话中命中。5.2 踩坑一阈值拍脑袋换来看似合理但实际错误的高相似度命中第一个版本里我把接受阈值定在 0.85理由是看起来差不多。上线一天就出现了一次严重事故用户先问客服电话为什么打不通得到一段关于客服时间表的回答后紧接着问退款申请多久能到账系统直接命中了上一轮的缓存返回了客服时间表。事后分析发现这两个问题在通用 embedding 模型里的余弦相似度竟然高达 0.87。原因是客服和退款这两个词在训练语料里频繁共现模型把它们映射到了相近的语义区域。这给我两个教训第一阈值永远不能用感觉定要用离线回放数据分布来定第二向量相似度在自然语言层面有多义词和共现偏差粗粒度标签的硬过滤不是可选项而是必修课。后来我把接受阈值改成离线回放时误命中率低于万分之一来校准。不同业务场景的值差异很大代码生成类通常要 0.92 以上闲聊类可以放宽到 0.78。5.3 踩坑二全量历史做 embedding新意图被历史稀释这是多轮语义缓存最典型的问题。有一次测试里前五轮用户都在规划旅行第六轮突然问明天上午的会我不去了帮我写一封请假邮件。这个请求的正确答案应该是一封邮件但全量上下文 embedding 做出来的向量仍然离旅行规划主题非常近召回排在前面的全是酒店和行程相关记录。解决办法就是我在第二章节提到的上下文编码视图历史参与但必须压缩当前问题全量参与并提高权重同时用粗粒度标签里的 context_switch 信号强行切断旧缓存。我还会对话题切换加了一个额外保护当标签分类器认为当前问题和最近 3 轮历史不属于同一话题时直接跳过向量相似度评估把整条请求当作全新会话处理不给任何历史缓存机会。5.4 踩坑三embedding 模型长度限制下截断位置决定成败第一次实现里上下文超过 embedding 模型最大长度时简单地从开头截断。结果长会话缓存几乎全部失效因为在超过长度后最早的指令和目标约束是全被截掉的留下的只有最近几轮闲聊和用户的操作记录编码视图的语义完全变了。改成分块-加权-汇总之后好很多把长上下文按轮次切成块每个块单独编码再按离当前时间越近权重越高做加权平均。系统提示词里真正影响行为的关键段落单独编码并保留最高权重。这个方案规避了 embedding 模型长度限制而且对旧轮次偶尔被挤掉的情况更鲁棒。5.5 语义缓存适用的风险分级经过这几次踩坑我总结了一张调参参考表任务类型接受阈值参考是否允许直接命中半命中策略闲聊、生活建议0.78 - 0.82允许增量复用旅行攻略、产品推荐0.86 - 0.90允许但校验关键约束增量复用代码生成、合同审查0.92 以上或关闭缓存谨慎需人工确认只复用上下文不返回缓存答案这份表不是金科玉律但可以作为一个起步参考。核心原则是误判的后果越严重阈值就要越严甚至可以直接关掉缓存宁可让缓存命中率难看也不能牺牲正确率。6. 把两层缓存真正叠起来语义缓存与 Token 级 KV Cache 的协同语义缓存落地之后团队的注意力又回到了一个老问题语义缓存 miss 的时候多轮推理的性能依然会有长尾劣化。这两个层次的缓存不应该是对立关系而是接力关系。6.1 语义缓存的边界正好是 KV Cache 的主场语义缓存能直接返回答案但只有高度近似的场景才能命中。更多的情况是用户在同一个话题下改变一个条件比如预算从八千提到一万——这个请求在语义上不应该直接复用旧答案但它的历史上下文城市、景点、主要诉求对新请求仍然有用。这种场景正是 token 级 KV Cache 的用武之地。服务端如果能维护好会话级的 KV Cache并在每轮新请求时只对增量部分做 prefill模型推理的耗时可以从完整上下文 prefill降为增量 prefill 全部 decode整体时延收益也非常可观。6.2 前缀重建与半命中路径的配合我在上线 SmartCache 后把语义缓存的半命中路径和前缀缓存彻底打通。流程变成语义缓存层判定当前请求属于半命中也就是历史上下文基本成立但用户新增了变更条件把变更后的请求交给推理服务推理服务检查会话的 KV Cache 是否仍然有效如果 KV Cache 里的历史前缀与当前请求一致直接复用并增量 prefill模型只针对变更部分生成新的回答。这个组合链路带来的收益比我预想的大。旅行规划场景中完整上下文 1200 token用户每轮新增只有 80 token半命中路径下的模型 prefill 计算量大约只有原来的 6.7%。6.3 缓存预热和反馈闭环语义缓存有一个冷启动期新会话模板上线前头几天命中率都很低。我在离线侧做了一个预热管道把历史会话库里高频出现的多轮场景先批量打标、编码、写入缓存等线上流量进来时已经有一部分候选可用。反馈闭环也很重要。我会把用户对缓存答案的后续行为纳入权重如果用户紧接着追问不对我不是这个意思或者点击了重新生成这条缓存记录的 feedback_score 就会下调下调到一定程度后不再参与召回。这个机制比定期人工抽检及时得多能自动捕捉语义漂移和模型行为变化带来的缓存污染。6.4 一些没有绕过去的边界问题语义缓存不是万能的。我做的这个版本里依旧有几个场景完全不建议开启缓存强时效性内容实时行情、天气、库存数量任何带现在含义的请求都不该走缓存强正确性要求医疗建议、合同数字、法律条款这类场景除非有人工确认环节否则收益远小于风险个性化强烈的内容同样是旅游攻略用户 A 和用户 B 的偏好差异很大跨用户复用容易产生看似合理但不适合的错误答案。我的处理是给每个缓存记录加一个 scope 字段标识它是全局可复用还是仅限单会话复用。默认严格按会话维度隔离缓存只有那些被证明跨用户安全的系统级回答才允许进入全局池。做完整套 SmartCache我最深的体会是语义缓存本质上是在正确性可容忍的范围内用近似匹配换取延迟和算力。它不是存储组件而是一个语义路由决策层。上线之前先花时间统计自己业务里的语义重复请求占比如果不足 5%这个方向带来的收益会非常有限如果超过 20%那它大概率会是继 KV Cache 之后又一个值得投入的性价比高地。离线回放评估阈值这一步尤其不要省拿历史会话先跑一遍比上线后反复调参省力得多也安全得多。 多轮对话推理加速：语义缓存与KV Cache协同优化实战
1. 多轮对话越聊越慢重复 prefill 才是真正的成本黑洞做 LLM 推理服务的人应该都有这个体感单轮请求的时延很好控但一进入多轮对话会话越聊越长响应越来越慢显存也越来越紧张。用户反馈里最典型的一句话就是前面几轮还好聊到十几轮就开始转圈圈了。这个问题的根源不在模型本身而在推理服务对历史上下文的处理方式。大模型推理通常分成 prefill 和 decode 两个阶段prefill 阶段要把用户输入的所有 token 并行计算一遍生成每个 token 对应的 K、V 向量也就是 KV Cache并缓存下来decode 阶段则基于 KV Cache 逐个生成新 token。理论上只要服务端支持把历史轮次的 KV Cache 保留在显存里新一轮请求就不需要把整个会话从头再算一遍。但真实生产环境没有那么理想。很多业务场景的服务端并不做严格的逐轮 KV Cache 维护要么把完整对话历史重新拼接后整段传给模型要么因为部署架构的原因导致前缀缓存无法命中。这种情况下每一轮新请求都会把之前所有轮次的 token 重新做一遍 prefill。会话越长重复计算的量越大。1.1 KV Cache 的显存账本为什么长会话会拖垮资源先算一笔显存账。以一个 7B 规模、隐藏维度 4096、32 层、每层 32 个注意力头的模型为例在 FP16 精度下每个 token 的 KV Cache 大约占 512KB 显存32 层乘以 32 个头乘以 128 维再乘以 2 份 K/V 和 2 字节精度。这意味着上下文长度单会话 KV Cache 显存占用估算100 个并发会话512 token约 256MB约 25GB2048 token约 1GB约 100GB8192 token约 4GB约 400GB这个量级说明两个问题第一长会话的 KV Cache 本身就昂贵第二如果每一轮都重新 prefill 全部历史那不只是浪费显存而是在成倍地浪费算力。假设一个会话平均 2000 token用户每轮新输入只有 100 token那么模型实际有效计算量中的 95% 都花在历史 token 的重复计算上。我之前在内部做过一次简单的 trace 统计在一个模拟的助手型产品里大约有 23% 的请求在语义上和历史轮次高度近似——用户换了个措辞问同一个问题或者把之前的请求微调后重发甚至直接复制粘贴追问。这些请求本不该重新消耗一次完整推理。1.2 精确缓存为什么救不了多轮场景最直观的办法是做精确匹配把整个对话上下文的文本拼起来算一个哈希再存一个 KV Cache 索引。下一次请求如果哈希值完全一致就直接复用缓存。这个方案在单元测试里看起来很合理一上线就露馅。因为真实用户不会原封不动地重复一句话哪怕只是把谢谢改成非常感谢把标点从半角变成全角哈希值就完全变了。更不用说多轮对话里大量出现的指代和改写比如用户上一轮说帮我对比这三款手机下一轮补充顺便加上那个红色那款这里的那款需要结合历史上下文才能理解成某具体型号。字符串层面完全匹配是不可能的。精确前缀缓存则更脆弱它不仅要求当前轮文本一致还要求之前所有轮次逐字一致。只要用户在第三轮把问题改了一个字第四轮开始之前共享的上下文就无法复用了。这也是我决定做语义缓存这个方向的原因KV Cache 解决的是 token 级的重复计算但语言表达的多样性让 token 级复用永远存在盲区。真正想降低多轮推理的成本和时延需要在更抽象的语义层去做匹配。2. SmartCache 的缓存键设计从 token 哈希到分层语义指纹明确了目标之后第一个要解决的问题是缓存键到底应该是什么。在单轮语义缓存的常见做法里直接用当前用户问题文本的 embedding 做检索命中就返回缓存答案。这个思路搬到多轮对话上会立刻出问题——多轮请求的语义不在当前这一句话里而在系统提示词 历史对话 当前问题的组合中。2.1 为什么缓存键不能只包含当前问题举一个我在实测中遇到的真实案例。用户先问周末去杭州玩三天预算五千以内帮我排一个行程助手给出行程后用户追问那家酒店的早餐值不值得吃。单独对那家酒店的早餐值不值得吃做 embedding模型根本不知道那家酒店指哪个向量也会落在完全无关的空间里。如果把整个历史对话拼在一起做 embedding又会出现另一个问题历史越长语义越被稀释。前五轮都在聊旅行第六轮突然问明天的会议纪要帮我整理一下全量拼接后的 embedding 大概率会漂移到旅行主题附近检索结果完全不可用。我在 SmartCache 里采用的做法是分层语义指纹把多轮上下文拆成粗粒度的结构化标签和细粒度的向量两个层级分别承担范围过滤和语义近似的职责。2.2 粗粒度标签可解释的硬过滤条件粗粒度标签是从上下文中抽取的结构化信息通常是 JSON 形式包括几个核心字段意图域比如旅行规划代码生成文档总结售后咨询。任务骨架描述整个多轮会话在围绕什么主线进行例如用户要求推荐杭州市区酒店并对比价格。活跃实体集合当前会话中仍然生效的地名、人名、商品名、数字约束等。变更指令标志这一轮是否包含不要改成加上去掉这类会让旧答案失效的变更指令。话题切换标记判断当前问题和最近历史是否属于同一主题如果是突然切换旧缓存必须全部失效。标签的作用是做硬过滤。向量相似度再高如果意图域不同或者活跃实体集合冲突就不该命中。比如用户问帮我写一封请假邮件和帮我写一封投诉邮件两者的 embedding 距离很近但意图域和应用结果完全不同必须通过标签提前排除。2.3 细粒度向量裁剪后的上下文编码细粒度向量负责在同一个主题范围内做近似匹配。这里的关键不是对全部历史做 embedding而是构造一个上下文编码视图规则很简单系统提示词单独截断到最近 512 字符参与向量化避免模型指令的冗长描述干扰语义历史对话按轮次压缩每轮只保留说话人身份 核心要点发言人标记user/assistant会作为前缀拼进文本当前用户的原始输入全量参与并且在组合时抬高权重——我可以把当前问题在文本里重复一遍比如按当前问题 当前问题 截断历史的拼接方式让模型注意力天然偏向最新意图超过 embedding 模型最大长度时优先丢弃最老的、与当前主题标签无关的轮次而不是简单从头截断。2.4 embedding 模型的选型与归一化多轮对话场景对 embedding 模型的要求和通用检索不太一样。通用 embedding 擅长捕捉单句语义但对谁在什么时候说了什么这种带角色的结构不敏感。我在实践中的处理是不追求超大模型选一个百 MB 量级、支持较长输入序列的通用 encoder 就够关键是做好文本归一化。我用的归一化包括统一说话人分隔符、把系统消息里频繁变化的指令模板做脱敏、将数字和单位统一格式、对用户消息不做任何改写直接在原文两侧加user:标记。这套操作比换一个更大更贵的 embedding 模型带来的收益稳定得多。3. 命中判定与三层安全网整体相似度并不等于答案可复用语义缓存最大的风险不是缓存 miss而是错误命中——返回了一个看似相关但实质错误的旧答案。这个风险在单轮缓存里已经存在在多轮上下文下会被放大因为多轮请求可以因为一个微小的变化就要求完全不同的答案。所以 SmartCache 把命中判定拆成三层候选召回、变更指令检测、答案校验。3.1 第一层标签预筛与向量召回查询先走粗粒度标签过滤。标签不匹配的候选直接丢弃然后在剩余候选中用向量检索取 top-k。这里我使用的是一个基于 HNSW 图索引的向量检索组件单个节点就能支撑百万量级指纹的召回P99 查询时延在 10 毫秒左右。相似度分数采用余弦相似度但分数本身不会直接当作命中依据而是映射成三个区间区间行为分数高于接受阈值直接命中缓存返回缓存答案分数高于候选阈值但低于接受阈值进入变更指令检测判定为半命中分数低于候选阈值判定为 miss走完整模型推理阈值具体取多少不能拍脑袋我会在第五部分专门讲调参时踩的坑和离线回放评估方法。3.2 第二层变更指令检测这是多轮语义缓存和其他缓存的核心差异假设用户上一轮问帮我推荐一款适合编程的轻薄本预算八千以内助手给出了答案。下一轮用户说预算提高到一万重量再轻一点。此时上下文整体相似度可能高达 0.90如果直接命中缓存返回的老答案完全无效。SmartCache 的做法是当候选分数落在半命中区间时先对当前用户输入做一轮轻量级变更意图分析。检测逻辑包括是否出现不要、取消、去掉、排除等否定型指令是否出现加上、补充、还有等新增型指令是否出现新实体、新数字约束并且和历史参数冲突是否出现话题切换信号比如突然从旅行跳到会议。如果确认没有任何变更指令走直接命中如果检测到变更走半命中路径保留历史上下文的 token 级 KV Cache 复用让模型只对新增和变化的片段做增量 prefill 和 decode。这个路径仍然能省掉大量重复计算。我在实现里甚至把变更指令检测做成了一个小模型分类器输入当前用户消息和候选缓存的上下文摘要输出一个是否修改历史上下文的三分类结果。实测比纯规则引擎的准确率高出不少。3.3 第三层答案级校验即使相似度分数很高、也没有明显的变更指令我仍然不直接信任缓存。答案级校验会抽取缓存答案中的关键信息点数字、名单、日期、清单项和当前请求的约束做一一比对。校验逻辑是硬规则如果用户当前请求里明确提到预算八千但缓存答案中推荐的产品价格区间超出这个范围校验一定失败。校验失败时的策略是降级不返回缓存直接走模型推理并把这条缓存的权重下调。这个设计很关键它可以保证语义缓存作为一个优化层不会把错误扩散到用户侧。4. 落地实现从缓存写入到召回验证的完整链路理论设计讲完说说工程落地。我把 SmartCache 做成一个独立的语义缓存服务挂在 LLM 推理网关旁路对业务侧透明。4.1 核心组件与请求流程服务内部有四个模块上下文签名器、向量索引、缓存存储、答案校验器。请求进来后的完整链路是网关收到多轮请求把当前会话的完整上下文交给上下文签名器签名器生成粗粒度标签 细粒度向量查询向量索引按标签过滤、向量召回 top-k 候选对候选做相似度区间判断和变更指令检测命中则通过答案校验器做关键信息比对通过后直接返回缓存答案未命中或校验失败则进入模型推理推理完成后把新结果写入缓存。缓存写入也有讲究。我在设计中采用延迟写入机制模型推理完成后先写入一个 pending 状态此时该记录不参与召回只有当用户没有发起重新生成或对结果做负面反馈时才在下一个时间窗口把状态置为 ready。这么做的原因是很多产品里用户会反复点击重新生成第一个结果未必是最终采纳的答案如果急着写缓存后续就会把垃圾答案反复曝光。4.2 缓存记录结构每条缓存记录大概长这样{ cache_id: fc3a8b..., context_fingerprint: sha256(system_version coarse_tags), coarse_tags: { intent_domain: travel_planning, active_entities: [hangzhou, 3_days, budget_8000], task_branch: hotel_recommendation, context_switch: false }, dense_vector_id: vec_7781f2, answer: { text: ..., key_facts: {budget: 7500, check_in_date: 2025-06-20} }, meta: { system_prompt_version: v3.1.0, ttl: 3600, hit_count: 128, feedback_score: 0.93, state: ready } }这里 context_fingerprint 不是全文本哈希而是系统版本 粗粒度标签的稳定哈希用来在系统升级或会话主题切换时快速失效整批缓存。dense_vector_id 指向向量索引中的浮点向量。key_facts 是一个很关键的结构化字段它让答案校验不再依赖重新解析自然语言而是直接比对结构化的关键约束。4.3 淘汰与失效策略缓存一定会脏关键是脏得可控。我用的淘汰策略有三条LRU 淘汰按命中率加权的 LRU长期不被命中的冷门上下文优先踢出TTL 失效不同意图域设置不同的生命周期比如天气和政策类缓存 TTL 很短攻略类和代码模板类可以长一些版本号失效系统提示词模板一旦升级所有旧记录通过 context_fingerprint 前缀全部失效避免模型行为变更后旧答案继续污染线上。另外用户在会话中明确说重新开始忘了之前的吧时网关会发送一个会话重置信号语义缓存层直接把该会话相关的记录全量标记为 invalid。这个信号比任何相似度算法都可靠因为它是我能把握的用户真实意图。4.4 监控指标别只盯着命中率语义缓存上线后最容易犯的错误是整天盯着命中率。我后来把监控面板换成四个指标组合hit_rate请求命中缓存的比例precisionhit抽样评估命中结果是否真的被用户采纳后续是否继续追问、是否修改而不是只看离线标注saved_tokens因为命中而避免重复 prefill 的 token 总量这是成本收益的核心指标cache_pollution一段时间内出现缓存返回后被用户纠正的比例这个指标比 hit_rate 更能在早期反映阈值失控。只用 hit_rate 做绩效考核团队一定会为了指标好看把阈值无限调低最后换来一堆错误复用的事故。5. 实测效果与三个典型调参踩坑SmartCache 在模拟项目 X 的离线会话集上做了回放测试又在两个内部业务场景里跑了小流量 A/B。先说结果再说踩过的坑。5.1 基线对比数据测试集包含 4 类多轮会话旅行规划、售后咨询、代码问答、文档改写每类各约 5000 条完整会话链。三组对照组是无缓存、精确字符串前缀缓存、SmartCache 语义缓存。方案端到端 P50 时延端到端 P95 时延缓存命中率答案采纳率抽样无缓存1.85s4.2s0%基准精确前缀缓存1.74s4.0s8.2%接近基准SmartCache 语义缓存0.91s2.1s26.7%略低于基准但差异不显著时延降低主要来自两处直接命中时省掉了完整 prefill 和大部分 decode半命中时虽然仍要走模型但历史上下文只做增量计算。P95 的改善比 P50 更明显因为长会话原本是时延拖尾的重灾区而语义缓存恰好最容易在长会话中命中。5.2 踩坑一阈值拍脑袋换来看似合理但实际错误的高相似度命中第一个版本里我把接受阈值定在 0.85理由是看起来差不多。上线一天就出现了一次严重事故用户先问客服电话为什么打不通得到一段关于客服时间表的回答后紧接着问退款申请多久能到账系统直接命中了上一轮的缓存返回了客服时间表。事后分析发现这两个问题在通用 embedding 模型里的余弦相似度竟然高达 0.87。原因是客服和退款这两个词在训练语料里频繁共现模型把它们映射到了相近的语义区域。这给我两个教训第一阈值永远不能用感觉定要用离线回放数据分布来定第二向量相似度在自然语言层面有多义词和共现偏差粗粒度标签的硬过滤不是可选项而是必修课。后来我把接受阈值改成离线回放时误命中率低于万分之一来校准。不同业务场景的值差异很大代码生成类通常要 0.92 以上闲聊类可以放宽到 0.78。5.3 踩坑二全量历史做 embedding新意图被历史稀释这是多轮语义缓存最典型的问题。有一次测试里前五轮用户都在规划旅行第六轮突然问明天上午的会我不去了帮我写一封请假邮件。这个请求的正确答案应该是一封邮件但全量上下文 embedding 做出来的向量仍然离旅行规划主题非常近召回排在前面的全是酒店和行程相关记录。解决办法就是我在第二章节提到的上下文编码视图历史参与但必须压缩当前问题全量参与并提高权重同时用粗粒度标签里的 context_switch 信号强行切断旧缓存。我还会对话题切换加了一个额外保护当标签分类器认为当前问题和最近 3 轮历史不属于同一话题时直接跳过向量相似度评估把整条请求当作全新会话处理不给任何历史缓存机会。5.4 踩坑三embedding 模型长度限制下截断位置决定成败第一次实现里上下文超过 embedding 模型最大长度时简单地从开头截断。结果长会话缓存几乎全部失效因为在超过长度后最早的指令和目标约束是全被截掉的留下的只有最近几轮闲聊和用户的操作记录编码视图的语义完全变了。改成分块-加权-汇总之后好很多把长上下文按轮次切成块每个块单独编码再按离当前时间越近权重越高做加权平均。系统提示词里真正影响行为的关键段落单独编码并保留最高权重。这个方案规避了 embedding 模型长度限制而且对旧轮次偶尔被挤掉的情况更鲁棒。5.5 语义缓存适用的风险分级经过这几次踩坑我总结了一张调参参考表任务类型接受阈值参考是否允许直接命中半命中策略闲聊、生活建议0.78 - 0.82允许增量复用旅行攻略、产品推荐0.86 - 0.90允许但校验关键约束增量复用代码生成、合同审查0.92 以上或关闭缓存谨慎需人工确认只复用上下文不返回缓存答案这份表不是金科玉律但可以作为一个起步参考。核心原则是误判的后果越严重阈值就要越严甚至可以直接关掉缓存宁可让缓存命中率难看也不能牺牲正确率。6. 把两层缓存真正叠起来语义缓存与 Token 级 KV Cache 的协同语义缓存落地之后团队的注意力又回到了一个老问题语义缓存 miss 的时候多轮推理的性能依然会有长尾劣化。这两个层次的缓存不应该是对立关系而是接力关系。6.1 语义缓存的边界正好是 KV Cache 的主场语义缓存能直接返回答案但只有高度近似的场景才能命中。更多的情况是用户在同一个话题下改变一个条件比如预算从八千提到一万——这个请求在语义上不应该直接复用旧答案但它的历史上下文城市、景点、主要诉求对新请求仍然有用。这种场景正是 token 级 KV Cache 的用武之地。服务端如果能维护好会话级的 KV Cache并在每轮新请求时只对增量部分做 prefill模型推理的耗时可以从完整上下文 prefill降为增量 prefill 全部 decode整体时延收益也非常可观。6.2 前缀重建与半命中路径的配合我在上线 SmartCache 后把语义缓存的半命中路径和前缀缓存彻底打通。流程变成语义缓存层判定当前请求属于半命中也就是历史上下文基本成立但用户新增了变更条件把变更后的请求交给推理服务推理服务检查会话的 KV Cache 是否仍然有效如果 KV Cache 里的历史前缀与当前请求一致直接复用并增量 prefill模型只针对变更部分生成新的回答。这个组合链路带来的收益比我预想的大。旅行规划场景中完整上下文 1200 token用户每轮新增只有 80 token半命中路径下的模型 prefill 计算量大约只有原来的 6.7%。6.3 缓存预热和反馈闭环语义缓存有一个冷启动期新会话模板上线前头几天命中率都很低。我在离线侧做了一个预热管道把历史会话库里高频出现的多轮场景先批量打标、编码、写入缓存等线上流量进来时已经有一部分候选可用。反馈闭环也很重要。我会把用户对缓存答案的后续行为纳入权重如果用户紧接着追问不对我不是这个意思或者点击了重新生成这条缓存记录的 feedback_score 就会下调下调到一定程度后不再参与召回。这个机制比定期人工抽检及时得多能自动捕捉语义漂移和模型行为变化带来的缓存污染。6.4 一些没有绕过去的边界问题语义缓存不是万能的。我做的这个版本里依旧有几个场景完全不建议开启缓存强时效性内容实时行情、天气、库存数量任何带现在含义的请求都不该走缓存强正确性要求医疗建议、合同数字、法律条款这类场景除非有人工确认环节否则收益远小于风险个性化强烈的内容同样是旅游攻略用户 A 和用户 B 的偏好差异很大跨用户复用容易产生看似合理但不适合的错误答案。我的处理是给每个缓存记录加一个 scope 字段标识它是全局可复用还是仅限单会话复用。默认严格按会话维度隔离缓存只有那些被证明跨用户安全的系统级回答才允许进入全局池。做完整套 SmartCache我最深的体会是语义缓存本质上是在正确性可容忍的范围内用近似匹配换取延迟和算力。它不是存储组件而是一个语义路由决策层。上线之前先花时间统计自己业务里的语义重复请求占比如果不足 5%这个方向带来的收益会非常有限如果超过 20%那它大概率会是继 KV Cache 之后又一个值得投入的性价比高地。离线回放评估阈值这一步尤其不要省拿历史会话先跑一遍比上线后反复调参省力得多也安全得多。