LMCache：推理缓存系统

在当前 AI 生态中，LLM 推理已成为核心基础设施。然而，随着上下文长度和请求复杂度的持续增长，推理成本与延迟压力急剧上升。LMCache 通过精准的 KV Cache 调度与跨请求共享机制，显著降低推理成本并优化响应延迟。

1. 核心思想：每段文本只需读取一次

LMCache 的核心理念是：每一段文本，模型只需读取一次。在真实应用中，大量数据被重复访问——热门文档、历史对话、检索片段等。根据帕累托法则，20% 的内容可能贡献 80% 的访问。LMCache 将所有可复用文本的 KV Cache 统一存储，当后续请求再次引用时直接复用，无需重新计算，无论这些内容出现在请求前缀还是中间位置。

该方案由芝加哥大学开发，已与 vLLM 等引擎集成。实测显示，在多轮问答、RAG 等场景中，TTFT 可提升 3–10 倍，同时有效节省 GPU 计算资源。

2. 三大关键特性

2.1 海量规模（Massive Scale）

LMCache 支持存储远超 GPU 显存容量的大规模 KV Cache 数据，通过解耦模型推理与上下文存储，使大模型可以应对更长上下文、更多用户并发。

2.2 极速加载（Blazing Speed）

LMCache 基于 CUDA 加速算子与流水线数据传输，可将命中的 KV Cache 以极低延迟加载到 GPU 显存，显著降低 TTFT。

2.3 插件式存储后端（Pluggable Storage）

LMCache 提供开放接口，可集成 MooncakeStore、Infinistore、Redis、分布式文件系统（DFS）等多种后端，适配不同企业部署需求。

借助上述能力，LMCache 扩展了 vLLM 分页内存机制的有效边界，使推理引擎可以跨请求复用历史上下文缓存，不再受限于单次会话的显存分配策略。

3. 工作原理

TTFT 受限于 Prefill 阶段，需要将输入上下文编码为 KV Cache 后才能开始生成。LMCache 将 Prefill 阶段计算得到的 KV Cache 缓存起来，下次遇到相同上下文时直接复用，从而大幅降低 TTFT。

LMCache 支持将 KV Cache 存储到内存、磁盘、Redis、GDS、NIXL 等多种后端，详情参阅 存储后端文档。

此外，LMCache 提供了 KV Cache 大小计算工具。以 4K 中文文本估算，2K Token 约需 106 MB 的 KV Cache，存储开销非常大。因此生产环境通常需要配合大容量存储后端（如 Redis、3FS、大容量磁盘）。

4. 快速上手：缓存到内存

4.1 环境变量配置

# 启用 LMCache V1 实验性功能
export LMCACHE_USE_EXPERIMENTAL=True
# 每个 KV Chunk 包含 256 个 Token
export LMCACHE_CHUNK_SIZE=256
# 启用 CPU 内存后端
export LMCACHE_LOCAL_CPU=True
# 分配 50 GB 固定 CPU 内存
export LMCACHE_MAX_LOCAL_CPU_SIZE=50

4.2 启动 vLLM 服务

export CUDA_VISIBLE_DEVICES=7
vllm serve /data/models/Qwen2.5-7B-Instruct \
    --no-enable-prefix-caching \
    --max-model-len 16384 \
    --kv-transfer-config \
    '{"kv_connector":"LMCacheConnectorV1", "kv_role":"kv_both"}'

5. 超越推理引擎：LLM 原生编排层

除缓存技术外，LMCache 团队还提出了面向 LLM 推理的原生编排层（LLM-Native Orchestration） 愿景。当前业界几乎将全部注意力集中在推理引擎内部优化（如 vLLM、SGLang、TensorRT-LLM），却忽视了引擎之上、跨引擎的系统级优化空间。

5.1 现状：以引擎为中心的扩展

当前大模型推理系统主要由两部分构成：

• 推理引擎：针对单个模型实例优化推理性能。
• 编排层：借助 Kubernetes 等工具水平复制引擎实例。

这种思维假定性能增益主要来自引擎内部，编排层只是无状态的“薄壳”。驱动该模型的开源系统包括：

• vLLM Production Stack
• llm-d 与 KServe
• NVIDIA Dynamo
• ByteDance AIBrix
• Modular
• SGLang OME

这些方案在横向扩展上表现良好，但难以实现更深层次的系统级优化。

5.2 新前沿：跨引擎的全局优化

真正的性能提升来自“跨引擎”的智能编排，例如：

• 动态 Prefill / Decode 分离
• 跨会话的 KV Cache 共享、传输与压缩
• 在线 KV Cache 更新（融合、编辑、翻译）
• 请求路径外的后台计算
• 查询迁移与跨 Agent 流水线

这些优化需要“有状态的协同”与“智能调度”，而原生 Kubernetes 方案很难直接提供。

5.3 Kubernetes 的局限性

Kubernetes 仍是现代基础设施的核心，但仅靠它做 LLM 推理编排会限制上限：

• 仅支持无状态副本：LLM 工作负载依赖共享的 KV Cache 与中间工具调用状态，而 Kubernetes 原生不支持请求与副本间的状态共享。
• 仅支持请求驱动执行：缓存压缩、后台预取、后台融合等优化需要在关键路径外运行，Kubernetes 的基于请求-响应的调度模型难以支撑。
• 不适合 LLM 特有逻辑：推理专用调度（如延迟敏感型任务优先）用 Go/Rust 实现的原型效率较低。
• 运维复杂度高：相比 OpenAI、Fireworks 等托管服务，基于 Kubernetes 的推理栈部署和运维难度更高。

5.4 LLM 原生编排器的需求

下一代推理编排器应具备：

• 面向张量的通信与状态共享能力（用于 KV Cache 复用、迁移与流水线）
• 可中断的后台任务（用于压缩、融合及非请求类计算）
• 感知延迟、资源占用与依赖关系的实时 / 后台任务调度
• 易于部署与运维，即使团队缺乏深厚基础设施经验

这不是取代 Kubernetes，而是对其补充：Kubernetes 负责容器生命周期、节点扩缩与集群管理，而 LLM 原生编排器负责理解 LLM 特有模式。

总结

LMCache 不仅在缓存算法上突破了前缀匹配限制、支持多级存储与跨引擎共享，还从系统架构层面提出了 LLM 原生编排的演进方向。对于希望降低长上下文推理成本、提升 TTFT 的团队，LMCache 是一个低成本高潜力的切入点。

参考

• LMCache GitHub
• LMCache 文档