万字深度解析 LMCache：当 KV Cache 遇见分布式存储革命——从常数级显存到千亿Token并发的完整技术指南（2026）

前言

大模型推理的战场，正在悄然转移。

当业界还在争论 MoE 和 Dense 架构谁更有未来，当 GPU 集群的规模一次次突破想象，有一个问题始终像暗礁一样横亘在每一个大模型团队的航道上：KV Cache 的显存瓶颈。

一个 70B 参数的模型，单次前向传播产生的 KV Cache 可以轻松吃掉数百 GB 显存。当你的应用需要同时服务 thousands of concurrent requests，当你的长上下文文档达到数十万 token，KV Cache 不是"性能优化"问题，而是"生死存亡"问题。

LMCache 就是在这个背景下诞生的。

它不是又一个"改进 attention 实现"的旁路工具，它是一个完整的 KV Cache 管理层：支持分布式存储、多后端灵活切换、P2P 共享、Disaggregated Prefill 架构，以及与 vLLM 的深度集成。截至 2026 年，它已经支持 S3、Redis/Valkey、NIXL、HF Bucket、Mooncake Store、Aerospike 等十余种存储后端，并支持 Kubernetes 原生部署。

这篇文章，我会从最底层的 KV Cache 原理出发，完整解析 LMCache 的架构设计、存储后端技术、高级特性（CacheBlend、Segmented Prefill、P2P 共享）、Kubernetes 部署实战，以及生产环境的最佳实践。读完它，你会理解为什么 LMCache 不是"又一个缓存库"，而是 LLM 推理基础设施的一次范式转移。

一、问题：从 Transformer 到 KV Cache 的三次性能危机

1.1 自回归推理的根本矛盾

理解 LMCache 为什么出现，首先需要理解 KV Cache 为什么会成为瓶颈。

Transformer 的自回归推理有一个内禀矛盾：每生成一个 token，都需要"回头看"所有已生成的 token。当你生成一段 2000 token 的回复时，模型在生成第 2000 个 token 的瞬间，实际上要处理 2000 个 token 的完整注意力计算。

标准的 Attention 计算：

Attention(Q, K, V) = softmax(Q × K^T / √d_k) × V

在推理时，Q 来自当前 token，而 K 和 V 来自所有历史 token。如果不缓存，每次生成新 token 都要重新计算所有历史 token 的 K 和 V——这叫 KV 重计算，是 LLM 推理中最昂贵的操作之一。

1.2 三次性能危机

危机一：上下文越长，显存越爆炸

以 LLaMA-70B 为例，每一层有 80 层注意力头。每个 token 在 FP16 精度下存储一对 KV 向量大约需要：

K（或V）大小 = num_layers × num_heads × head_dim × 2 bytes（FP16）
            = 80 × 8 × 128 × 2 = 163,840 bytes ≈ 160 KB/token

对于 4096 个上下文 token，KV Cache 需要：4096 × 160 KB ≈ 655 MB/请求

这还是单请求。生产环境里，同时 100 个请求就是 65 GB KV Cache。在 A100 80GB 的卡上，光 KV Cache 就能吃掉大部分显存，留给模型权重的空间所剩无几。

危机二：长上下文时代的"记忆墙"

2026 年的主流模型上下文窗口已经到了 1M token 甚至更长。超长上下文意味着 KV Cache 在显存中的驻留时间更长、更新频率更高。传统做法中，完整的 KV Cache 必须在 GPU 显存中管理——当上下文达到百万 token 时，单次请求的 KV Cache 可以达到数十 GB，这在物理上就是不可行的。

危机三：多请求共享与跨节点协作

在实际的推理服务中，多个请求之间存在大量可以共享的 KV Cache——尤其是使用相同底座模型、相同系统提示词的场景。但传统 vLLM 的 PagedAttention 只解决了单节点内的显存管理，跨 GPU、跨节点、跨集群的 KV Cache 共享是无解的。

LMCache 正是在这三次危机的交叉点上诞生的。它的核心思路是：把 KV Cache 的管理从 GPU 显存中解放出来，放到一个可扩展的、分布式的存储层中。

二、LMCache 是什么：KV Cache 管理层的设计哲学

2.1 架构定位

LMCache 的官方定位是：A KV Cache Management Layer for Scalable LLM Inference。

这句话里有几个关键词值得拆解：

• Layer（层）：LMCache 不是替代 vLLM，不是重新实现 attention，而是作为一个中间层插入到现有的推理管线中。它站在 vLLM 和存储后端之间，充当 KV Cache 的缓存网关。
• Scalable（可扩展）：从单卡推理到千卡集群，LMCache 的架构都适用。它的后端可以是本地内存、Redis 集群，也可以是 S3 对象存储或 Mooncake RDMA 网络。
• Management（管理）：LMCache 不仅做缓存，还做缓存策略、失效管理、多级存储分层、压缩、分布式协调。

2.2 整体架构

LMCache 的架构可以分为三层：

┌─────────────────────────────────────────────────────┐
│                    LLM 推理引擎                       │
│              (vLLM / LMDeploy / SGLang)              │
├─────────────────────────────────────────────────────┤
│               LMCache Client / SDK                   │
│    (缓存查找、写入策略、预取、Eviction 策略)            │
├─────────────────────────────────────────────────────┤
│                   存储后端层                          │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐│
│  │  内存     │ │  Redis   │ │   S3     │ │  NIXL    ││
│  │(L1 CPU)  │ │(L2 RAM)  │ │(L3 对象) │ │(RDMA网络)││
│  └──────────┘ └──────────┘ └──────────┘ └──────────┘│
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐│
│  │HF Bucket │ │Mooncake  │ │Aerospike │ │ Raw Block││
│  └──────────┘ └──────────┘ └──────────┘ └──────────┘│
└─────────────────────────────────────────────────────┘

三层存储分层：

• L1（GPU 显存）：最热的数据，vLLM PagedAttention 直接管理的部分
• L2（CPU 内存 / RDMA 网络）：温数据，支持 Redis/Valkey、NIXL、Mooncake 等高速后端
• L3（对象存储 / 分布式存储）：冷数据，支持 S3、HF Bucket、文件系统等大容量后端

这种分层设计使得 LMCache 可以根据数据的"热程度"决定放在哪里——最热的放显存，次热的放内存，最冷的放对象存储，最大化性价比。

2.3 与 vLLM 的集成模式

LMCache 支持两种与 vLLM 的集成模式：

模式一：动态连接器（Dynamic Connector）

LMCache 提供 DynamicConnector 接口，可以无缝接入 vLLM 的调度流程。当 vLLM 需要 KV Cache 时，通过 LMCache 查询；当 vLLM 需要写入 KV Cache 时，通过 LMCache 持久化。这种模式不需要修改 vLLM 核心代码，侵入性最小。

from lmcache.vllm import LMCacheDynamicConnector
from vllm import LLM, SamplingParams

# 初始化 LMCache 连接器
connector = LMCacheDynamicConnector(
    backend="redis",          # 使用 Redis 作为后端
    redis_url="redis://10.0.0.5:6379",
    device="cuda",            # 自动在 GPU/CPU 之间传输
)

# 挂载到 vLLM
llm = LLM(model="meta-llama/Llama-3-70b-instruct")
# 通过 connector 实现 KV Cache 的外部管理

模式二：外部服务（Server Mode）

LMCache 可以部署为独立的 KV Cache 服务，通过 HTTP/gRPC 接口对外提供 KV Cache 的读写服务。这种模式下，推理引擎和 KV Cache 服务完全解耦，适合多推理引擎共享同一份 KV Cache 的场景。

# 启动 LMCache 服务
lmcache server \
  --backend redis \
  --redis-url redis://10.0.0.5:6379 \
  --host 0.0.0.0 \
  --port 8080

三、核心架构：存储后端与技术实现

3.1 多后端架构设计

LMCache 最核心的设计哲学是后端无关（Backend Agnostic）。无论底层用的是 Redis 还是 S3，上层 API 都是统一的。这意味着你可以：

• 开发环境用本地文件系统，快速迭代
• 测试环境用 Redis，保证一致性
• 生产环境用 S3 + NIXL，优化成本和性能

LMCache 的后端接口抽象如下（简化版）：

class StorageBackend(ABC):
    @abstractmethod
    def get(self, key: str) -> bytes:
        """获取 KV Cache"""
        pass

    @abstractmethod
    def put(self, key: str, value: bytes) -> None:
        """写入 KV Cache"""
        pass

    @abstractmethod
    def delete(self, key: str) -> None:
        """删除 KV Cache"""
        pass

    @abstractmethod
    def batch_get(self, keys: list[str]) -> dict[str, bytes]:
        """批量获取"""
        pass

    @abstractmethod
    def batch_put(self, items: dict[str, bytes]) -> None:
        """批量写入"""
        pass

    @abstractmethod
    def exists(self, key: str) -> bool:
        """检查 key 是否存在"""
        pass

这种设计让每种存储后端可以针对自己的特性做极致优化：Redis 用 RESP 协议做低延迟原子操作，S3 用 multipart upload 处理大对象，NIXL 用 RDMA 零拷贝绕过 CPU。

3.2 支持的存储后端详解

3.2.1 Redis / Valkey（内存键值存储）

适用场景：低延迟（亚毫秒级）、高吞吐的 KV Cache 缓存层

Redis 是 LMCache 中最常用的高性能后端。KV Cache 的 key 通常是模型名 + 请求 ID 的组合，value 是序列化的 K/V 张量。

# lmcache_config.yaml
backend: redis
redis:
  url: redis://10.0.0.5:6379
  pool_size: 50
  max_connections: 200
  socket_timeout: 5
  connection_timeout: 10

Valkey 是 Redis 的开源兼容 fork，LMCache 同样支持，且在高并发场景下 Valkey 的多线程模型往往表现更好。

性能数据参考：在单节点 8×A100 环境下，使用 Redis 后端的 LMCache 可以支撑 ~500 QPS 的 KV Cache 读写，P99 延迟 < 5ms。

3.2.2 NIXL（RDMA 网络存储）

适用场景：多 GPU 节点间的高速 KV Cache 共享

NIXL 是 LMCache 支持的最特殊的后端之一。它基于 RDMA（Remote Direct Memory Access）技术，允许数据直接在内存之间传输，绕过操作系统内核协议栈。

这对于 Disaggregated Prefill 架构意义重大：在 Prefill-Decode 分离部署模式下，Prefill 节点产生的 KV Cache 需要高速传输给 Decode 节点。使用 NIXL 可以实现 100+Gbps 的 KV Cache 传输带宽，延迟比 TCP/IP 低 10 倍以上。

# NIXL 后端配置
backend_config = {
    "backend": "nixl",
    "nixl": {
        "interface": "mlx5_0",       # RDMA 网卡接口
        "transport": "rdma",
        "rdma_qp_size": 1024,
        "max_inline_data": 256,
    }
}

3.2.3 S3 / HF Bucket（对象存储）

适用场景：超大容量 KV Cache 存储、成本敏感的长尾请求

S3 和 HuggingFace Bucket 后端将 KV Cache 作为对象存储，适合存储那些"不常用但不能丢"的数据——比如超长文档的 KV Cache、历史会话的上下文快照。

但对象存储的延迟较高（通常 10-100ms），不适合热路径。LMCache 的典型用法是用 Redis 处理热请求，S3 作为兜底的冷存储。

# S3 后端配置
backend_config = {
    "backend": "s3",
    "s3": {
        "bucket": "lm-cache-prod",
        "region": "us-west-2",
        "endpoint_url": "http://s3.amazonaws.com",
        "aws_access_key_id": os.getenv("AWS_ACCESS_KEY_ID"),
        "aws_secret_access_key": os.getenv("AWS_SECRET_ACCESS_KEY"),
        "multipart_threshold": "8MB",
        "max_concurrency": 16,
    }
}

3.2.4 Mooncake Store（分布式 RDMA 存储）

适用场景：字节跳动自研的高性能分布式存储，适合超大规模推理集群

Mooncake 是字节跳动开源的分布式存储系统，专为 LLM 推理设计。它利用 RDMA 和 NVMe SSD 构建高吞吐、低延迟的存储集群，在字节内部的万卡推理集群中经过了充分验证。LMCache 通过 Mooncake Store 后端接入这一能力：

backend_config = {
    "backend": "mooncake_store",
    "mooncake": {
        "store_url": "disagg://10.0.0.100:8080",
        "pool_name": "kvcache_pool",
        "rdma_dev": "mlx5_0",
    }
}

3.3 KV Cache 的序列化与压缩

KV Cache 的存储有一个特殊挑战：张量数据非常大。一个 4096 上下文长度、FP16 精度的 KV Cache 可以达到 GB 级别。

LMCache 支持两种压缩策略：

策略一：CacheGen 压缩

CacheGen 是 LMCache 集成的 KV Cache 压缩算法，核心思想是将 KV Cache 分解为多个语义层，然后只保留最关键的部分：

from lmcache.vllm import LMCacheDynamicConnector

connector = LMCacheDynamicConnector(
    backend="redis",
    compression={
        "enabled": True,
        "method": "cachegen",
        "ratio": 0.25,          # 压缩到原始大小的 25%
        "quality_threshold": 0.9,
    }
)

策略二：序列化（SerDe）

LMCache 使用 PyTorch 的序列化机制将 KV 张量序列化为二进制数据进行存储和传输：

import torch
from lmcache.storage import LMCacheSerde

# 序列化
k_cache = torch.randn(32, 128, 4096, 64)  # (layers, heads, seq, head_dim)
serialized = LMCacheSerde.serialize(k_cache)
# serialized 是一个字节串，可以写入任何后端

# 反序列化
k_cache_restored = LMCacheSerde.deserialize(serialized, dtype=torch.float16)

四、高级特性：从单点缓存到分布式推理

4.1 Disaggregated Prefill：预填充与解码的彻底分离

在传统的 LLM 推理部署中，Prefill（首 token 生成）和 Decode（后续 token 生成）往往运行在同一个 GPU 上。但这两种操作的计算特性完全不同：

Disaggregated Prefill 架构将 Prefill 和 Decode 部署在不同的节点上：

[Prefill 集群] → 产生 KV Cache → [高速网络] → [Decode 集群]
  (H100, 高算力)    (NIXL RDMA)      (A100, 大显存)

这解决了两个问题：

1. 两种操作的最优硬件配置不同，分离后可以各自优化
2. Decode 集群的显存压力大幅降低（KV Cache 从 Prefill 节点流过来，按需传输）

LMCache 在这个架构中扮演核心角色：

• Prefill 端：LMCache 将产生的 KV Cache 通过 NIXL/Mooncake 后端直接推送到 Decode 节点
• Decode 端：LMCache 接收 KV Cache 数据，写入本地缓存供注意力计算使用

这种架构下，单个 Decode 节点的显存可以服务 3-5 倍的并发请求，因为 KV Cache 不再是"预加载"的，而是"流式到达"的。

4.2 CacheBlend：智能缓存混合

CacheBlend 是 LMCache 的一项高级缓存策略优化。当多个请求使用不同的提示词但共享部分语义内容时，CacheBlend 可以智能地"拼装"KV Cache——复用已有缓存的部分，只补全差异部分。

例如：

• 请求 A："解释量子计算的基本原理"
• 请求 B："解释量子计算的高级原理"

传统做法：两个请求完全独立计算，重复率很高
CacheBlend 做法：复用请求 A 的 KV Cache，只计算"高级"与"基本"的差异部分

from lmcache.experimental import CacheBlendManager

blend_manager = CacheBlendManager(
    similarity_threshold=0.7,   # 相似度阈值
    blend_ratio=0.6,            # 复用比例
)

# 当新请求到达时
cached_kv = blend_manager.get_blended_cache(request_prompt, model_id)
if cached_kv is not None:
    # 复用缓存，只补全差异
    partial_kv = compute_differential(new_prompt, cached_prompt)
    final_kv = blend_manager.merge(cached_kv, partial_kv)

4.3 Segmented Prefill：分段预填充

超长上下文请求（如 128K token）的 Prefill 阶段会消耗大量时间，导致 TTFT（Time To First Token）过长。Segmented Prefill 将超长请求拆分为多个段落，分批预填充，配合 KV Cache 实现增量计算：

1. 第一段（如 32K token）：完整 Prefill，结果存入 LMCache
2. 第二段（32K-64K）：从 LMCache 读取已有 KV Cache，只计算新增 32K
3. 第三段（64K-96K）：以此类推

# Segmented Prefill 配置
segment_config = {
    "enabled": True,
    "segment_size": 32768,         # 每段 32K token
    "overlap_tokens": 512,         # 重叠 512 token 保证连续性
    "cache_backend": "redis",
    "prefetch_ahead": 2,           # 预取接下来 2 段
}

4.4 P2P KV Cache 共享

在多推理节点集群中，相同模型处理的请求往往存在大量可以共享的 KV Cache——特别是系统提示词（System Prompt）的 KV Cache。

LMCache 的 P2P 共享机制允许节点之间互相读写对方的 KV Cache，类似于 CDN 的边缘节点回源逻辑：

节点 A 需要 System Prompt 的 KV Cache
  → 检查本地 LMCache（未命中）
  → 通过 P2P 网络向其他节点广播请求
  → 节点 B 响应（命中），通过 RDMA 传输 KV Cache
  → 节点 A 接收并缓存一份副本

这种机制在 100+ 节点的推理集群中可以显著降低系统提示词的 Prefill 开销——因为系统提示词的 KV Cache 只需要计算一次，之后所有请求都复用。

五、分布式协调：多节点一致性

5.1 LMCache Coordinator

在分布式场景下，多个 LMCache 实例之间需要协调：

• 缓存失效：当模型版本更新时，旧版本的 KV Cache 需要全局失效
• 容量管理：各节点的 LMCache 实例需要协调容量上限，避免单点 OOM
• 请求路由：哪些请求的 KV Cache 在哪个节点上，需要全局索引

LMCache Coordinator 是负责这一协调工作的组件：

lmcache coordinator \
  --host 10.0.0.1 \
  --port 8090 \
  --cluster_mode redis  # 或 etcd / consul

Coordinator 提供的 HTTP API：

# 注册节点
curl -X POST http://10.0.0.1:8090/nodes/register \
  -d '{"node_id": "node-a", "capacity_gb": 32, "backend": "redis"}'

# 查询 KV Cache 位置
curl "http://10.0.0.1:8090/cache/locate?model=llama-3-70b&request_id=req-123"

# 广播失效
curl -X POST http://10.0.0.1:8090/cache/invalidate \
  -d '{"model": "llama-3-70b", "version": "new"}'

5.2 分布式追踪与可观测性

生产环境中，KV Cache 的命中率直接影响推理成本和延迟。LMCache 提供完整的可观测性支持：

# 启用 metrics 收集
observability:
  metrics:
    enabled: true
    port: 9090
    export_interval: 10  # 每 10 秒导出一次

  tracing:
    enabled: true
    exporter: otlp
    endpoint: http://jaeger:4317
    service_name: lmcache-server

  logs:
    level: INFO
    format: json
    output: stdout

关键指标：

六、Kubernetes 部署：生产级实战

6.1 为什么需要 Kubernetes 原生支持

当推理服务规模超过 10 个节点时，手动管理 LMCache 的部署、扩缩容、滚动更新变得几乎不可能。Kubernetes 部署的核心价值：

1. 声明式配置：用 YAML 描述 LMCache 集群的期望状态，Kubernetes 自动收敛
2. 弹性扩缩容：根据负载自动扩缩 LMCache 节点
3. 滚动更新：模型版本升级时，逐节点替换，不中断服务
4. 资源隔离：不同租户的 KV Cache 可以用 Kubernetes Namespace 隔离

6.2 Operator 模式部署

LMCache 提供了 Kubernetes Operator，可以管理 LMCache 集群的完整生命周期：

# lmcache_cluster.yaml
apiVersion: lmcache.ai/v1
kind: LMCacheCluster
metadata:
  name: production-kvcache
  namespace: llm-inference
spec:
  replicas: 6
  backend: redis
  redis:
    url: redis://redis-cluster:6379
    pool_size: 100

  coordinator:
    replicas: 3
    image: lmcache/coordinator:v1.2.0

  storage:
    resources:
      requests:
        cpu: "4"
        memory: 16Gi
      limits:
        cpu: "8"
        memory: 32Gi

  nodeSelector:
    hardware-type: nvidia-a100

  tolerations:
    - key: "nvidia.com/gpu"
      operator: "Exists"
      effect: "NoSchedule"

部署命令：

kubectl apply -f lmcache_cluster.yaml
kubectl get lmcachecluster -n llm-inference

6.3 与 vLLM 的联合部署

# vllm_deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-llama3-70b
  namespace: llm-inference
spec:
  replicas: 8
  template:
    spec:
      containers:
        - name: vllm
          image: vllm/vllm-openai:v0.4.0
          env:
            - name: LMCACHE_BACKEND
              value: "redis"
            - name: LMCACHE_COORDINATOR_URL
              value: "http://production-kvcache-coordinator:8090"
            - name: LMCACHE_ENABLED
              value: "true"
          resources:
            requests:
              nvidia.com/gpu: 1
              memory: 64Gi
            limits:
              nvidia.com/gpu: 1
              memory: 80Gi

6.4 Helm Chart 快速部署

LMCache 提供了官方 Helm Chart，生产部署推荐使用：

# 添加 Helm 仓库
helm repo add lmcache https://charts.lmcache.ai
helm repo update

# 一键部署生产级集群
helm install production-kvcache lmcache/lmcache \
  --namespace llm-inference \
  --create-namespace \
  --values values.prod.yaml

# values.prod.yaml 关键配置
# replicas: 6
# backend: redis
# redis.cluster.enabled: true
# coordinator.replicas: 3
# observability.prometheus.enabled: true
# observability.jaeger.enabled: true

七、模型支持与集成 Recipes

LMCache 不是通用框架，它针对每个主流模型提供了专门的集成 Recipes，包括 KV Cache 格式、注意力掩码处理、批量推理策略等。

7.1 支持的模型

7.2 快速集成示例（Llama 3 70B）

from lmcache.vllm import LMCacheDynamicConnector
from lmcache.experimental.config import LMCacheConfig
import torch

# 初始化配置
config = LMCacheConfig.from_recipe("llama-3-70b-instruct")
config.backend = "redis"
config.redis_url = "redis://10.0.0.5:6379"
config.device = "cuda"

# 创建连接器
connector = LMCacheDynamicConnector(config)

# 使用 vLLM 加载模型（自动使用 LMCache 管理 KV Cache）
from vllm import LLM, SamplingParams

llm = LLM(
    model="meta-llama/Llama-3-70b-instruct",
    kv_cache_spec=config.to_vllm_kv_cache_spec(),
    tensor_parallel_size=4,
)

# 推理调用（KV Cache 自动通过 LMCache 管理和复用）
outputs = llm.generate(["什么是量子计算？"], SamplingParams(temperature=0.7))

八、性能基准测试

8.1 测试环境

8.2 基准测试结果

测试场景：LLaMA-3-70B，4096 上下文长度

测试场景：128K 超长上下文（DeepSeek-V4）

这些数字清晰地展示了 LMCache 的价值：在并发场景和长上下文场景下，KV Cache 管理层的引入可以将吞吐量提升 7-10 倍，同时将 GPU 显存占用减半。

九、总结与展望

9.1 LMCache 的核心价值

回顾全文，LMCache 解决了三个层面的问题：

基础设施层：将 KV Cache 从 GPU 显存的"附庸"变成独立管理的"资产"。这解放了 GPU 显存，让同等硬件可以服务更多并发请求。

工程化层：提供统一的 API 和多后端支持，让团队可以在开发、测试、生产环境使用不同存储方案而不改变业务代码。Kubernetes Operator 和 Helm Chart 让部署从"写文档"变成了"写 YAML"。

架构演进层：Disaggregated Prefill、CacheBlend、P2P 共享等特性，解锁了传统架构下不可能实现的推理优化。这些特性不是锦上添花，而是未来超大规模推理的必经之路。

9.2 谁应该使用 LMCache

• 日均请求量 > 10万 的推理服务：KV Cache 复用的收益直接体现在成本上
• 超长上下文应用（RAG、Agent、文档理解）：Segmented Prefill 将 TTFT 从分钟级降到秒级
• 多模型共享推理集群：Coordinator 实现跨模型的 KV Cache 隔离和管理
• Prefill-Decode 分离部署：NIXL/Mooncake 后端让 KV Cache 传输不再是瓶颈

9.3 未来方向

LMCache 的 Roadmap 显示了几个值得关注的方向：

1. SMoE（多模态 MoE）支持：随着 GPT-4V、Qwen-VL 等多模态模型普及，跨模态 KV Cache 管理将成为新战场
2. Edge 部署优化：更轻量的 Agent 端部署，在端侧推理中管理 KV Cache
3. MLIR 集成：在编译器层面做 KV Cache 的自动融合和优化
4. 跨云 KV Cache：Federated KV Cache 让不同云厂商的推理实例可以安全地共享缓存

参考资料

• LMCache GitHub: https://github.com/LMCache/LMCache
• LMCache 官方文档: https://docs.lmcache.ai/
• vLLM PagedAttention: https://docs.vllm.ai/
• CacheGen KV Compression: https://arxiv.org/abs/2312.15958
• Disaggregated Prefill: https://arxiv.org/abs/2401.09661
• NIXL RDMA Storage: https://github.com/NIXL-storage/NIXL