LMCache

1. 调研缘由

长上下文、RAG 和多轮代理会反复计算相同输入的 KV cache。LMCache 试图把这部分结果从推理进程里的临时状态，变成可持久化、共享和观测的基础设施，以减少重复 prefill。[S1]

2. 简介与产品工作流

LMCache 是大模型推理的 KV cache 管理层。请求到达 serving engine 后，系统查找可复用缓存，把命中内容从 CPU、磁盘或远端后端取回；未命中的新内容再计算并写回。官方重点指标是 TTFT 与吞吐，而不是模型答案本身。[S1]

3. 团队与时间背景

官方文档的更新列表覆盖 2025 和 2026 年，当前快速入门也持续维护 vLLM 连接方式，说明项目在本次近三年观察口径内仍然活跃。本文不写融资和商业规模。[S1][S2]

4. 技术基础与生态位

LMCache 支持把缓存放在 CPU 内存、本地存储和远端后端，并提供非前缀复用、缓存观测以及 prefill/decode 分离相关能力。它位于模型和推理引擎之间，不替代 vLLM 等 serving engine。[S1]

5. 集成与部署路径

官方快速入门给出 vLLM 集成：可把 LMCache 作为独立服务，通过 LMCacheMPConnector 连接多个推理实例；也可在进程内运行，方便单机试验。独立模式更利于共享、管理与故障隔离，但多一个服务也增加配置和运维面。[S2]

6. 公开评价与主要分歧

**正面评价：**对于共享长前缀、重复文档和多轮会话，缓存复用有明确工程价值。[S1] **主要分歧：**收益依赖真实命中率、传输开销和存储层速度；官方示例与性能描述不能替代团队自己的压测。

7. 同类对比

与推理引擎内置的简单前缀缓存相比，LMCache 更强调跨实例、分层存储和独立生命周期；与模型路由或请求级结果缓存相比，它复用的是中间 KV 状态，因此对模型版本、tokenizer 与配置一致性更敏感。[S1][S2]

8. 适用场景与验收

适合高重复长上下文、RAG 文档、多轮对话和分离式推理。验收应同时记录无缓存基线与启用后的 TTFT、吞吐、GPU 利用率、命中率、尾延迟和答案一致性，并模拟缓存服务重启及容量淘汰。[S1]

9. 归纳洞察 ★

LMCache 把“少算一次”变成独立基础设施问题。它最适合重复计算占比高且 serving 栈可控的团队；若请求几乎不重复，缓存查找、传输和维护成本可能抵消收益，先测负载比照搬宣传数字更重要。

10. 来源与更新时间

• 信息截至(as_of): 2026-08-13