LMCache 分布式 KV Cache 存储引擎：分层架构与显存优化实践

大模型推理中的 KV Cache 管理正成为性能优化的核心战场。当 Llama 3.1 70B 处理 128K token 的系统提示时，单次 prefill 可能耗时 11 秒 —— 如果 1000 个用户请求包含相同的前缀，传统架构会重复计算 1000 次。LMCache 作为 vLLM 的分布式 KV Cache 扩展层，通过分层存储架构与跨实例共享机制，将这一场景下的首 token 延迟（TTFT）压缩至 1.5 秒，并在高并发场景实现最高 15 倍的吞吐提升。

四层分级架构：延迟与容量的权衡

LMCache 将 KV Cache 存储划分为四个层级，形成明确的延迟梯度与容量互补关系。这种设计借鉴了传统存储系统的多级缓存思想，但针对 LLM 推理的访问模式进行了专门优化。

Tier 0（GPU HBM） 承载活跃工作集，访问延迟低于 1 微秒，带宽可达 3.35 TB/s。这一层与 vLLM 的 PagedAttention 内存管理直接协作，存储当前正在参与计算的热前缀。容量受限于显存大小（H100 SXM5 为 80GB），LMCache 在此层与 vLLM 的内存管理器协同工作，自动处理活跃页的置换。

Tier 1（CPU DRAM） 作为温缓存层，采用 pinned memory（锁页内存）实现高效的 GPU-CPU 零拷贝传输。访问延迟约 5-50 微秒，带宽受限于 PCIe 通道（约 32 GB/s）。典型配置为每节点 256-512 GB，用于承接从 GPU 溢出的近期使用块，避免直接落盘带来的延迟抖动。

Tier 2（本地 NVMe） 提供大容量冷存储，延迟 100-500 微秒，顺序读写带宽 6-12 GB/s。该层适合存储长文档的 KV 表示或历史会话的完整上下文。需要注意的是，SATA SSD（约 500 MB/s）无法满足此层带宽需求，必须使用 NVMe 设备。

Tier 3（远程共享存储） 通过 Redis、Mooncake 或 InfiniStore 实现跨节点共享。在 25GbE 网络下带宽约 3 GB/s，RDMA/RoCEv2 可达 20 GB/s。这一层是 LMCache 实现多节点 KV Cache 共享的关键，使得任意 worker 都能读取其他节点计算过的前缀。

跨实例共享：从单节点优化到集群协同

vLLM 原生的 Prefix Caching 仅能在单个 worker 内生效 —— 当请求被负载均衡到不同副本时，已计算的 KV 无法复用。LMCache 通过 Connector 架构解决了这一限制。

Connector 作为 LMCache 与推理引擎的集成模块，嵌入 vLLM 的 paged KV 内存管理器。当处理 prompt 时，Connector 首先查询 Cache Index（基于 token 序列哈希的索引结构）判断是否存在可复用的 KV 块。若命中，直接从相应存储层级加载；若未命中，则正常计算并将结果异步写入多层缓存。

Cache Index 采用默认 256 token 的 chunk 粒度进行分块与哈希，支持跨请求和跨实例的查找。对于超长序列（超过 128K），建议将 chunk_size 调整为 512 以减少索引碎片化。

远程连接层通过插件化设计支持多种后端。Redis 是最常用的共享存储方案，所有 worker 通过统一的 remote_url 读写同一实例。第一个计算某前缀的 worker 将结果写入 Redis，后续任意 worker 均可读取复用。LMCache Controller 提供集中式管理 API，支持查询、清理、压缩 / 解压、迁移及持久化标记等操作。

显存优化策略：异步卸载与零阻塞设计

LMCache 的 Storage Mode 专注于显存压力缓解与缓存持久化。当 GPU 内存紧张时，系统采用异步流水线将溢出 KV 块卸载至下层存储，确保推理线程零阻塞。

具体流程为：新生成的 KV chunk 首先复制到 CPU buffer，随后启动异步任务并行写入磁盘和远程存储。主推理线程无需等待 I/O 完成即可继续处理后续 token。这种设计使得冷数据可以落盘甚至跨会话持久化，而热数据保持在 GPU 内随时可用。

内存分配器针对 NUMA 架构进行优化，确保 CPU 侧内存分配与 GPU 数据传输的亲和性。LRU 作为默认淘汰策略，可通过配置调整为其他算法。对于需要常驻的热点前缀，Controller 提供 Pin 操作防止其被意外淘汰。

Transport Mode 则面向 prefill-decode 解耦场景，支持实时 P2P KV 传输。通过 NIXL 等通信库，prefill 节点计算的 KV 可直接流式传输至 decode 节点，避免重复计算。这一模式与 vLLM Production Stack 集成，适用于 Kubernetes 环境下的分布式推理部署。

可落地参数清单

基于生产环境验证，以下是关键配置参数与硬件选型建议：

存储层级配置（lmcache.yaml）

local_cpu: true              # 启用 CPU DRAM 温缓存
local_disk: "/mnt/nvme/lmcache"  # NVMe 挂载路径
max_local_disk_size: "2TB"    # 本地磁盘配额
remote_url: "redis://10.0.0.1:6379"  # 跨节点共享后端
chunk_size: 256              # 分块粒度（长上下文建议 512）

vLLM 启动参数

--kv-transfer-config kv_connector=LMCacheConnector  # 启用 LMCache 连接器
--kv-cache-dtype fp8  # 或 fp16，集群内所有节点必须一致

硬件选型 Checklist

• GPU：H100/H200 SXM5（80GB+ HBM）
• CPU 内存：每节点 ≥256 GB（推荐 512 GB）
• NVMe：顺序读 ≥6 GB/s，容量 ≥2 TB（使用 fio 验证带宽）
• 网络：跨节点场景需 25GbE 或 RDMA/RoCEv2
• Redis：独立部署，避免与推理节点资源竞争

关键约束

• 集群内所有 worker 必须使用相同的 --kv-cache-dtype，混用 fp8/fp16 会导致缓存失效
• NVMe 层必须验证顺序带宽，高 IOPS 低带宽的 SATA SSD 无法胜任
• 超长上下文（>128K）建议增大 chunk_size 以减少索引开销

总结

LMCache 通过四层分级架构将 KV Cache 管理从单节点显存优化扩展至分布式集群协同。其核心收益体现在两方面：一是通过 GPU-CPU-NVMe 的分层卸载缓解显存压力，支持更长上下文；二是通过远程共享存储打破 worker 边界，实现前缀级别的跨实例复用。对于需要处理长系统提示或多轮对话的推理服务，该方案可将 TTFT 从秒级降至亚秒级，同时显著降低 GPU 计算冗余。

资料来源

• LMCache 官方文档架构页（docs.lmcache.ai）
• Spheron GPU Cloud 部署指南与性能基准测试

ai-systems