什么是多级缓存？从缓存到模型的阶梯

AI 应用里的多级缓存，指的是请求在到达模型之前，先经过一层层越来越贵的存储，能挡住的请求就不必麻烦模型。它像一段从便宜到贵的阶梯，大部分重复或相似的问题在下面几级就被接住了，走到模型那一层的是真正的新问题。

多级缓存是什么：一层层问过去，问到模型为止

一次提问进来，系统先查最快最便宜的那一层，比如浏览器本地或边缘节点；没命中就退到应用服务器的内存缓存；再没命中才查共享缓存服务；都落空了，才真的把请求发给模型去算。每一层容量更小、速度更快、离用户更近。

这样分级的好处是成本可控。缓存命中一次几乎不花钱，模型一次调用要实打实消耗算力，挡掉的请求越多，整体开销越稳，响应也越快。级数越多，能被挡在外面的流量比例通常越高。

生活类比：查资料先翻书架再问专家

可以把多级缓存想成查资料的顺序。先翻自己桌上的书，没有就去办公室共享书架找，还没有才去约一位专家当面请教。每一层等待时间变长、成本变高，但查到的内容更贴近你真正的问题。

多级缓存把这个顺序搬进了 AI 服务：本地记忆挡重复提问，共享缓存挡相似提问，模型只负责处理真正的新问题。专家的时间最贵，所以要把简单问题拦在专家之前。

类比失效的地方：缓存会答非所问

类比也有对不上的地方。书架上的书不会答错问题，缓存却可能给出过时的答案。缓存里存的是某个时间点的回答，问题稍一变化，命中就可能变成误导，用户拿着旧答案当新结论用。

所以缓存层通常都带有效期，也会按问题的相似程度决定要不要命中。语义缓存还会判断两个问题是不是在问同一件事，判断标准本身又是一门功夫，松了会答非所问，紧了命中率上不去。一个实用的自查办法是抽检：每天从命中记录里随机抽几十条，人工核对答案与最新事实是否一致，一致率下滑就收紧判定标准或缩短有效期。缓存不是设完就完的配置，它需要持续巡检，就像共享书架要定期清理过期的期刊。

带走一个判断：命中率与答案新鲜度要一起看

评价一套多级缓存，不能只看命中率。命中率高但答案陈旧，用户得到的是过期信息；答案永远最新但全部打到模型上，成本和延迟又吃不消。合理的做法是给不同级别的内容设不同的有效期，让更新快的热点内容早过期。

具体到操作层面，可以给缓存分三类管理：标准事实类内容有效期可以放长一些，比如产品说明里的固定参数；时效敏感的内容有效期要短，比如榜单、公告；个性化内容干脆不进共享层，只留在个人会话里。判断一个问题该不该命中缓存，先问一句：换了人提问，这个答案还成立吗？成立才值得缓存，不成立就该绕过去直接算。

三类内容的有效期和存放层，差别就在这一句判断上。

在腾讯元宝、Kimi 这类产品的服务端，类似的思路被广泛使用。想了解缓存与其他机制的配合，可以读什么是幂等重试、什么是服务降级和一次调用的完整计费项。

速查表：

• 请求先问谁？最快最便宜的那一层
• 什么时候动模型？下面几级全部落空
• 缓存的最大风险？答案过时、答非所问
• 该盯哪个指标？命中率与答案新鲜度一起看

关于多级缓存再多问三句

• 缓存是不是越多级越好？：不是，每加一级就多一层维护成本和答案过时的风险，级数要和内容更新频率匹配，不更新的内容才值得多级缓存。
• 用户重复提问为什么第二次更快？：多半是第一级或第二级缓存直接命中了，请求根本没走到模型那一层，这就是多级缓存最直观的好处。
• 缓存会泄露别人的回答吗？：正常实现会按用户或租户隔离缓存键，共享层只放公开可复用的内容，这是服务端设计时要考虑的基本项。