title: "你的 LLM 每天在重复计算同一句话——10k 人决定让它只学一次" description: "LMCache把KV缓存从临时状态变成可持久化、可跨引擎复用的AI原生知识，TTFT降低3-10倍，吞吐提升15倍，但存储后端选型和缓存一致性是绕不过的工程代价" tags: ["LMCache", "KV缓存", "LLM推理", "vLLM", "开源"]
你的 LLM 推理服务，每天在重复计算同一句话。
一个 128K token 的系统提示，1000 个用户发来请求，集群就把这 128K token 的 KV 缓存重新算 1000 遍。每次 prefill 花掉 11 秒，1000 次就是 11000 秒的 GPU 时间——而其中 99% 是重复劳动。
这不是夸张。这是 Llama 3.1 70B 在真实生产环境里的日常。
然后 LMCache 说了一句话：每一段文本，模型只需读取一次。
GitHub 10.1k 星，1.5k Fork，Apache 2.0 协议。芝加哥大学出品，Google Cloud、Amazon AWS、NVIDIA、IBM、Oracle、AMD 在用。vLLM 和 SGLang 深度集成，NVIDIA Dynamo 官方推荐。
但"只学一次"这四个字，背后的工程代价远比你想的重。
KV 缓存不是缓存——它是一种新的数据对象
大多数人理解的 KV 缓存：Transformer 推理时临时存在 GPU 显存里的中间结果，请求结束就丢弃。
LMCache 的理解完全不同。他们写了一篇博客叫"Stop Calling It KV Cache: It's Something Much Bigger"——别再叫它 KV 缓存了，它比缓存大得多。
在 LMCache 的架构里，KV 缓存是一等公民数据对象：
- 可持久化：不随请求结束而消失，存到 CPU 内存、本地 SSD、Redis、S3
- 可跨引擎复用：vLLM 实例 A 算过的 KV 缓存，实例 B 可以直接用
- 可压缩：CacheGen 压缩后传输，带宽占用大幅降低
- 可搜索：非前缀位置的 KV 块也能命中（CacheBlend）
- 可观测：请求级、token 级的缓存命中率、生命周期、性能指标全链路追踪
这不是缓存，这是知识分发网络（Knowledge Delivery Network, KDN）——就像 CDN 分发网页内容，KDN 分发模型已经"学过"的知识。
分层存储：GPU → CPU → SSD → Redis → S3
LMCache 的核心架构是一个分层存储系统：
| 层级 | 存储 | 延迟 | 容量 | 成本 |
|---|---|---|---|---|
| L0 | GPU HBM | ~μs | 极小（GB级） | 极高 |
| L1 | CPU DRAM | ~ms | 中等（百GB级） | 中 |
| L2 | 本地 SSD/NVMe | ~ms | 大（TB级） | 低 |
| L3 | Redis/Valkey | ~ms | 大 | 中 |
| L4 | S3/对象存储 | ~100ms | 无限 | 极低 |
请求来了，先查 L0（GPU 显存），命中就直接用；没命中查 L1（CPU 内存），再查 L2（本地磁盘），再查 L3（Redis），最后查 L4（S3）。每一层都有淘汰策略（eviction），热数据留在高速层，冷数据下沉到低速层。
Redis 官方专门为 LMCache 做了吞吐优化，给出了一个关键 SLO：L2 后端需要 2 GB/s 的吞吐才能"跑赢" prefill——也就是说，从 Redis 加载 KV 缓存的速度必须比重新计算 prefill 更快，否则缓存就没有意义。
CacheBlend：打破前缀缓存的紧箍咒
传统 KV 缓存复用有一个致命限制：只能复用前缀。
系统提示 + 对话历史 + RAG 检索结果，如果 RAG 检索结果的顺序变了，即使内容完全一样，前缀缓存也全部失效——因为前缀必须从第一个 token 开始严格匹配。
在 Agent 场景下这个问题更严重。每一轮对话，Agent 会重新组装上下文：系统指令 + 历史对话 + 工具输出 + 检索文档。顺序经常变化，前缀缓存命中率可能只有 1/3。
CacheBlend 解决了这个问题。
它的原理是：不管 KV 缓存块出现在输入序列的哪个位置，都可以复用。但直接拼接非前缀的 KV 块会丢失跨块注意力（cross-attention）信息，导致生成质量下降。CacheBlend 的做法是选择性重计算——对拼接点附近的 token 重新计算 KV 值，恢复跨块注意力，其余 token 直接复用缓存。
实测数据：
| 方案 | TTFT | F1 Score |
|---|---|---|
| Full KV Recompute（基线） | 3x | 0.8+ |
| Caching Prefix Only | ~2x | 0.8+ |
| Full KV Reuse（无重计算） | ~1x | <0.2（质量崩塌） |
| CacheBlend（选择性重计算） | ~1x | 0.8+ |
CacheBlend 在 Llama 70B + 2WikiMQA 数据集上，TTFT 降低约 3 倍，吞吐提升 2.8-5 倍，F1 Score 不降。
PD 分离：Prefill 和 Decode 各干各的
LMCache 还支持 Prefill-Decode（PD）分离架构。
传统推理是 Prefill 和 Decode 在同一个 GPU 上串行执行。PD 分离把它们拆到不同的 worker：
- Prefill Worker：专门处理输入文本的 KV 缓存计算（计算密集型）
- Decode Worker：专门做 token 逐个生成（内存带宽密集型）
Prefill Worker 算完 KV 缓存后，通过 NVLink、RDMA 或 TCP 传输给 Decode Worker。LMCache 通过 NIXL（NVIDIA 的异构数据传输库）抽象了底层传输细节，支持 NVLink、RDMA、TCP/IP 等多种网络架构。
这样 Prefill Worker 可以用大显存 GPU 专门做 prefill，Decode Worker 用高带宽 GPU 专门做 decode，各取所长，资源利用率最大化。
四大方案横评：谁在解决什么问题
KV 缓存管理正在成为 LLM 推理的基础设施层，不止 LMCache 一家在做。
| 维度 | LMCache | NVIDIA Dynamo | Mooncake（月之暗面） | 华为 UCM |
|---|---|---|---|---|
| 出身 | 芝加哥大学 | NVIDIA | Kimi/月之暗面 | 华为 |
| 开源 | ✅ Apache 2.0 | ✅ | ✅ | ❌ |
| 引擎绑定 | 厂商中立（vLLM/SGLang/...） | NVIDIA 生态 | 自研 | 华为生态 |
| 非前缀复用 | ✅ CacheBlend | ❌ | ❌ | ❌ |
| KV 压缩 | ✅ CacheGen | ❌ | ❌ | ❌ |
| PD 分离 | ✅ NIXL/RDMA | ✅ 原生 | ✅ | ✅ |
| 存储后端 | CPU/SSD/Redis/S3/Mooncake/NIXL/GDS | 自研 | 自研 | 自研 |
| 可观测性 | ✅ 全链路 | ✅ | 有限 | 有限 |
| 生产部署 | 30+公司（Google/AWS/IBM/Oracle/AMD） | NVIDIA 客户 | Kimi | 华为客户 |
| MoE 优化 | ✅ 10x 加速 | 有限 | 有限 | 有限 |
LMCache 的核心差异化是厂商中立 + 非前缀复用 + KV 压缩。它不绑定任何特定引擎或存储，用户可以自由切换 vLLM、SGLang，自由选择 Redis、S3、Mooncake 作为后端。
NVIDIA Dynamo 的优势是与 NVIDIA 硬件生态深度绑定，NVLink + RDMA 传输性能最优。Mooncake 是 Kimi 的自研方案，为自身业务深度优化。华为 UCM 是华为 AI Factory 的组件，不开源。
代价清醒：缓存不是免费的午餐
1. 存储后端选型是第一道坎。
LMCache 支持 8 种存储后端，但每种都有适用场景：
- CPU DRAM：延迟最低，但容量有限，多节点无法共享
- 本地 SSD：容量大，但单节点绑定，节点挂了缓存就丢了
- Redis/Valkey：可分布式共享，但需要 2 GB/s 吞吐 SLO，不是所有 Redis 部署都能达到
- S3：容量无限，但延迟 100ms+，只适合冷数据
- NIXL/GDS：性能最优，但需要 NVIDIA 特定硬件
选错了后端，缓存加载比重新计算还慢，反而拖慢推理。
2. 缓存一致性是分布式系统的经典难题。
多个 vLLM 实例共享同一个 KV 缓存池，当一个实例更新了缓存，其他实例怎么知道？LMCache 目前通过 Controller 组件管理缓存元数据，但在高并发、大规模部署下，缓存失效和一致性的复杂度会指数级增长。
3. 非前缀复用有质量风险。
CacheBlend 的选择性重计算在大多数场景下能保持 F1 Score 不降，但在极端场景（高度依赖跨块注意力的任务）下，质量可能仍有微小损失。论文的评测数据集有限（2WikiMQA），生产环境的工作负载千差万别。
4. MoE 模型的 KV 缓存更复杂。
LMCache 声称 MoE 推理性能提升 10x，但 MoE 模型的 KV 缓存管理比 Dense 模型复杂得多——不同 expert 的 KV 缓存需要分别管理，缓存命中率的计算也更复杂。这部分还在快速迭代中。
5. 部署复杂度不低。
LMCache 的 MP 模式（推荐部署方式）需要独立运行 lmcache server 作为 sidecar，配置存储后端、传输层、淘汰策略、压缩参数。对于小团队来说，运维负担不小。pip install 只是一行命令，但生产部署是另一回事。
谁该用，谁不该用
该用的：
- 多轮对话、Agent 工作流等长上下文重复率高的场景
- RAG 应用，检索文档在不同请求间大量重复
- 大规模 vLLM 集群，多节点需要共享 KV 缓存
- TTFT 是核心 SLA 指标的在线服务
- 已有 Redis/S3 基础设施可以复用的团队
不该用的：
- 单次请求、无上下文复用的简单推理场景
- 没有分布式存储基础设施的小团队（先用 CPU offload 模式）
- 对生成质量有极致要求、不能容忍任何质量损失的场景
- 非 vLLM/SGLang 引擎且无意愿迁移的团队
KV 缓存正在成为 LLM 推理的操作系统
LMCache 的野心不只是做一个缓存工具。
它的博客里有一句话："KV cache was not discussed as a feature of an inference engine."——KV 缓存不应该被视为推理引擎的一个功能，而应该是一个独立的基础设施层。
就像操作系统把内存管理从应用程序中抽离出来，LMCache 把 KV 缓存管理从推理引擎中抽离出来。推理引擎只负责计算，LMCache 负责存储、传输、压缩、搜索、观测。
这个定位决定了它的价值：不是让单个请求更快，而是让整个集群更高效。
30+ 公司在生产环境使用，PyTorch 生态官方接纳，NVIDIA Dynamo 集成，vLLM 官方文档推荐——LMCache 正在从"一个开源项目"变成"一个事实标准"。
但事实标准的代价是：你需要为这个基础设施层投入运维资源。存储后端、网络传输、缓存一致性、淘汰策略——每一个都是分布式系统的经典难题。
LMCache 省的是 GPU 计算时间，不是工程复杂度。 在你决定装上这层"操作系统"之前，先确认你的场景真的有足够的 KV 缓存复用率来摊平这些复杂度。
相关链接：
- GitHub：https://github.com/LMCache/LMCache
- 官方文档：https://docs.lmcache.ai
- 官网：https://lmcache.ai
- 技术报告：arXiv 2510.09665
- CacheBlend 论文：arXiv 2405.16444
- Blog：https://blog.lmcache.ai
暂无评论。