高频请求扛不住？多级缓存架构+Redis集群为大模型续上性能

兄弟们，晚上好。

最近这段时间，我们团队在搞大模型服务化，被一个指标折磨得不轻——TTFT（Time To First Token），也就是“首字延迟”。在高并发场景下，这个TTFT简直成了我们服务的性能噩梦。

你想想这个画面：用户发来一个请求，后台几百个请求并发，我们的GPU风扇狂转，显存告急，但用户在那边看到的，却是光标一直在闪，第一个字迟迟吐不出来。这体验，砸招牌啊。

我们深挖了一下，发现病根出在KV Cache上。这玩意儿是Transformer架构里提升生成速度的关键，但它也成了性能的罪魁祸首。每次推理，模型都得从头计算和缓存上下文的Key-Value对，导致GPU的显存和计算资源被大量重复消耗。

这带来了几个致命的痛点：

• 重复计算：大量请求的前缀（比如系统提示词）其实是一样的，但每次都得算一遍。
• 显存爆炸：上下文越长，KV Cache越大，几个长文本请求就能把显存干满。
• 资源浪费：GPU吭哧吭哧地在做重复劳动，真正的利用率极低。

面对这种窘境，我们意识到，不能再让模型“傻算”了。得给它装个“外挂大脑”——一套高效的多级缓存体系，我们称之为LMCache。

LMCache的核心设计：按“热度”分层，按“远近”读取

在聊具体实现前，我想先说说LMCache的设计哲学，就一句话：“按访问频率分级存储，按延迟需求就近读取”。

这思想，咱们搞后端的再熟悉不过了。它就像CPU的多级缓存一样：最常用的数据放L1，贴着CPU核心；次常用的放L2、L3；再不常用的就去内存、硬盘里找。每一层，都是用容量和成本换速度。

LMCache也是这个思路。它创新性地将KV Cache的使用与生成过程解耦，构建了一套GPU显存 → 本地高速硬盘 → 分布式集群的三级缓存体系，从根本上提升了推理效率。

庖丁解牛：LMCache的三级缓存体系

L1 缓存: Worker内核里的“VIP专座” (纳秒级响应)

• 定位：极致的低延迟，零竞争，专门服务于单个Worker内部的局部高频请求。
• 实现：这一层缓存直接部署在每个推理Worker的GPU显存里，采用高效的LRU（Least Recently Used）淘汰策略。它缓存的是当前对话或上下文中最活跃、最滚烫的那部分KV Cache片段。

它的工作流程是这样的：

1. 当vLLM生成一个新Token时，内部的StorageManager会提取当前输入序列的哈希值（比如用SHA-256）。
2. 拿着这个哈希值，去本地L1缓存里“闪电般”地查一下。
3. 如果命中，那太棒了！预先计算好的KV Cache会直接灌入Attention层，省去了大量的计算，TTFT瞬间降低。
4. 如果没命中，别慌，请求会穿透到下一级缓存查询。

对了，我们还给它加了个“特权”功能。像“system prompt”这种每个请求都会用到的高频数据，我们会给它打上hot_cache的标记，把它“钉”在L1里，确保它永不被淘汰。

L2 缓存: 节点内的“共享书房” (微秒级响应)

• 定位：跨Worker共享，避免在同一台物理机上的重复计算，减少网络开销。
• 实现：L2缓存位于单个物理节点的本地高速存储设备上，比如NVMe SSD。它作为这台机器上所有Worker实例的二级缓存池。

L2的价值在于，如果一台机器上部署了多个推理服务实例，它们就可以共享这个“书房”。比如，用户A的请求落在了Worker-1上，计算并缓存了一个长文本的KV Cache；紧接着，用户B的类似请求落在了Worker-2上，Worker-2在自己的L1里没找到，但它可以在L2这个共享书房里找到Worker-1留下的“笔记”，直接加载，避免了又一次漫长的计算。利用SSD的大容量特性，这一层可以缓存数百万级的KV片段。

L3 缓存: 集群的“中央图书馆” (毫秒级响应)

• 定位：跨节点协同，是整个缓存体系的“底座”，具备PB级的扩展能力。
• 实现：L3是我们后端工程师最熟悉的“老朋友”——Redis集群。我们基于Redis Cluster构建了一个高性能的分布式缓存池，作为整个服务集群全局共享的KV Cache中心。

当L1和L2都查询未命中时，请求就会来到L3这个“中央图书馆”。虽然它的响应是毫秒级的，比前两级慢，但它的作用是协同整个集群，避免在不同机器之间发生重复计算。它是我们整个缓存架构的最终防线和容量的无限延伸。

不只是分层：LMCache的另外两大突破

除了精巧的三级架构，LMCache还有两个值得一说的技术点：

• 请求级KV复用：传统的缓存方案大多只能复用前缀（Prefix Caching）。而LMCache做得更彻底，它能实现任意位置的KV片段的提取与重用，这让缓存的命中率和灵活性大大提升。
• 分布式共享缓存：通过引入Redis集群，我们让成百上千个vLLM推理实例不再是信息孤岛，而是能够协同作战。一个实例计算的结果，可以被整个集群共享，这才是真正的“分布式力量”。

写在最后

从“傻算”到“智取”，LMCache这套多级缓存架构，本质上是在昂贵的计算资源和相对廉价的存储资源之间做了一次优雅的平衡。

它通过空间换时间的经典策略，把最高频的计算结果固化下来，用纳秒到毫秒级的存储访问，替代了动辄数百毫秒甚至秒级的GPU计算。这样一来，不仅用户的TTFT体验得到了质的飞跃，我们后台的GPU资源利用率也大大提高，真正做到了用更少的资源，扛住更高的并发。

有时候，解决问题的钥匙，就藏在这些看似“传统”的架构思想里。