cat README.md
LMCache
跑了三个月 GitHub AI 日报，我一直觉得 KV Cache 就是推理引擎内部的一个"临时缓存"——用完就扔的东西。直到我把 LMCache 拆开，才发现这东西根本不是缓存，它是 AI 推理的基础设施层，就像 CDN 不是缓存而是互联网的内容交付网络。
// 目录
// 概览
为什么我之前没把 KV Cache 当回事
说实话，我跑 LLM 推理也有一段时间了。用 vLLM 起 Qwen3，调几行参数，模型就能跑了。KV Cache？那不就是注意力机制里的中间结果吗，用完就丢的东西——我一直是这么想的。
直到我遇到一个真实场景：多轮 Agent 对话，上下文从 20k token 涨到 115k，每次对话开头那 12k 的系统提示和工具定义要重新算一遍。一个对话 60 分钟，96.9% 的 token 是可以被复用的，但 vLLM 的 HBM 前缀缓存装不下——HBM 就那么大，LRU 一淘汰，前功尽弃。下一次请求还得从头算 prefill，TTFT 直接飙到几分钟。
这不是"慢一点"的问题，是用户体验直接崩了。
然后我看到 LMCache 团队那篇博客的标题——"Stop Calling It KV Cache: It's Something Much Bigger"。一开始我觉得标题党，拆完发现人家说得对。KV Cache 已经不是推理引擎内部的一个临时数据结构了，它正在变成一个独立的基础设施层。就像 CDN 最早也只是"缓存"，后来变成了互联网的内容交付网络。LMCache 自己的定位更直接：Knowledge Delivery Network（知识交付网络）。
拆开看架构
LMCache 的核心设计决策只有一个：把 KV Cache 从推理引擎进程里拿出去，变成独立的服务。这个决策的后果是颠覆性的。
传统模式下，KV Cache 是 vLLM 进程内部的一块 GPU 内存，进程挂了缓存就没了，两个 vLLM 实例之间没法共享。LMCache 的多进程（MP）架构把这个限制打破了——KV Cache 变成了独立守护进程管理的资源，引擎崩了缓存还在，多个实例共享一个缓存池。
存储是分层的，跟 CPU 的 L1/L2/L3 一个思路：
光有分层存储还不够。LMCache 还做了几件让我觉得"这帮人是真在生产环境踩过坑"的事：
CacheBlend 非前缀复用。传统前缀缓存只能匹配开头相同的 prompt。RAG 场景下，用户问不同问题但引用了同一段文档，开头不一样，缓存全部失效。CacheBlend 可以在 prompt 任意位置匹配已缓存的 KV Block，只需要选择性地重算少量 token 恢复质量。这是他们 EuroSys 2025 论文的核心贡献。
PD 分离架构。Prefill（预填充）和 Decode（解码）对 GPU 的需求完全不同——Prefill 是计算密集型，Decode 是内存带宽密集型。LMCache 支持把 Prefill Worker 算好的 KV Cache 通过 NVLink/RDMA/TCP 传给 Decode Worker，各干各的，互不干扰。这在多节点部署里是个杀手锏。
可插拔存储后端。目前支持 20 种存储后端：CPU RAM、本地 SSD、Redis、Valkey、Mooncake、InfiniStore、S3、NIXL、GDS、3FS、Google Cloud Bigtable、Weka、HuggingFace Buckets……基本上你能想到的存储系统都能接。这种"我不做存储，我只做路由"的思路，跟 CDN 的定位一模一样。
生产级可观测性。Kubernetes 指标、KV Cache 特定指标（前缀缓存命中率、生命周期、性能），还有前端 Dashboard。这不是给研究者玩的玩具，是真的要在生产环境跑的东西。
数据说话
LMCache 官方有两组很硬的 benchmark，一组是 NVIDIA H100 上的 MoE 模型（Qwen3-235B），一组是 AMD MI300X 上的真实 Agent 负载。我把关键数据拎出来。
MoE 推理性能（8×H100 · Qwen3-235B-A22B FP8）
真实 Agent 负载（2×MI300X · MiniMax-M2.5 · 32用户/100k上下文）
第二组数据特别有意思。压力测试下（32 用户 / 100k 上下文），LMCache 对比纯 HBM 前缀缓存：TTFT 平均低 3.0×，P95 低 2.1×，完成请求数多 2.3×。注意，这是对比 vLLM 自己的前缀缓存，不是对比无缓存。HBM 满了，缓存一淘汰，前功尽弃；LMCache 有 CPU DRAM 做 L2，溢出的缓存还有救。
但有个细节很关键：轻负载下（8 用户 / 32k 上下文），HBM 前缀缓存完胜。工作集能装进 HBM 的时候，LMCache 的额外开销反而是负担。AMD 的测试里，合成 benchmark 低 10-17%，因为 16k 上下文才占 1.9GB KV Cache，2×MI300X 剩余 154GB HBM，根本不需要 L2。
所以 LMCache 不是银弹，它有一个明确的适用边界：
| 工作集规模 | 推荐策略 | 理由 |
|---|---|---|
| < 100k tokens | HBM 前缀缓存 | HBM 装得下，无需 L2 |
| 100k – 250k tokens | HBM 前缀缓存，监控淘汰 | 临界区间，看淘汰率决定 |
| 250k – 500k tokens | LMCache DRAM | HBM 溢出，L2 必须上 |
| > 500k tokens | LMCache DRAM + NVMe L3 | 连 CPU 内存都不够用了 |
// 上手体验
三行命令跑起来，这是我最喜欢 LMCache 的地方。不用改模型代码，不用重新训练，不用换推理引擎。
第一次请求，LMCache 会把 prompt 的 KV Cache 存进 CPU 内存。第二次请求如果有相同前缀，直接从 CPU 内存取，跳过 prefill。日志非常清晰：
如果用 SGLang，也是三行：
TensorRT-LLM 的集成还在进行中（依赖 NVIDIA/TensorRT-LLM PR #12626），但已经可用，只是要从源码编译。三种引擎，一个缓存层，这是"厂商中立"四个字的真正含义。
// 竞品对比
我把目前市场上跟 KV Cache 管理沾边的方案都拉出来对比一下，方便你判断 LMCache 在什么位置：
| 方案 | 定位 | 优点 | 缺点 |
|---|---|---|---|
| LMCache | 独立 KV Cache 管理层 | 跨引擎/跨实例共享 · 分层存储 · CacheBlend 非前缀复用 · PD 分离 · Apache 2.0 | 轻负载下额外开销 · 123 Issues/193 PRs 积压 · AMD 需源码编译 |
| vLLM 前缀缓存 | 引擎内置 | 零配置 · 轻负载下最快 | 仅限 HBM · 跨实例不共享 · LRU 淘汰不可恢复 |
| NVIDIA Dynamo | 商业推理平台 | 深度 GPU 优化 · 与 NVIDIA 硬件一体 | 闭源 · 绑定 NVIDIA 生态 · KV 管理非独立层 |
| Mooncake | KV Cache 传输层 | 高吞吐 RDMA 传输 · 开源 | 只做传输不做存储管理 · 无分层策略 |
| OpenAI Prompt Caching | API 服务 | 零运维 · 自动缓存 | 闭源 · 仅 OpenAI 模型 · 缓存不透明 |
| AWS SageMaker HyperPod | 云托管 | 全托管 · 与 LMCache 集成 | 锁定 AWS · 成本高 · 自建灵活性低 |
LMCache 的核心差异在于：它是唯一一个把 KV Cache 当作独立基础设施层来做的开源方案。vLLM 的前缀缓存是引擎内部优化，Mooncake 只做传输不做管理，OpenAI 是 API 黑盒，Dynamo 是闭源商业方案。LMCache 跟 CDN 的定位一模一样——不管你后面是什么源站（推理引擎），不管你前面是什么客户端（模型服务），我就是一个独立的缓存路由层。
// 踩坑与局限
说完好的，说说踩过的坑。LMCache 不是万能的，有些坑还挺深的。
PYTHONHASHSEED=0 是强制性的。这不是建议，是必须。缺了这个参数，跨 TP worker 的哈希不一致，即使 bit 级相同的 prompt 也会 0% 缓存命中。这种跨进程一致性的坑，不踩一遍根本想不到。
绝对不要设置 LMCACHE_SAVE_DECODE_CACHE=true。这会同步将每个解码步骤卸载到 CPU，序列化 GPU 流水线，导致 100-250 秒的严重停顿。这个配置项的存在本身就是个设计失误——应该默认关闭或者干脆去掉。
AMD 用户必须源码编译。pip install lmcache 的 PyPI wheel 只链接 CUDA，在 AMD 上会报 libcudart.so.12 错误。而且还要手动卸载 CUDA 依赖（nixl、cupy、cufile-python、cuda-pathfinder），否则 vLLM 的 quark 量化会触发 libcuda.so.1 ImportError。AMD 支持写了"有"，但体验远不如 NVIDIA 丝滑。
TP=2 + In-Process 模式可能死锁。持续负载下 shm_broadcast 死锁已复现，60 秒内找不到共享内存广播块。这是已知的 bug，还没修。
123 Issues / 193 PRs 积压。对于一个基础设施项目来说，这个积压量需要关注。好在社区活跃度不错，Onboarding 2026 Good First Issues 的 Issue 已经开了（#3372），有意识地在拉新贡献者。
KV Cache 只解决 prefill 端问题。在所有 AMD 测试中，输出吞吐量聚合仅 1-8 tok/s。系统是解码受限的，LMCache 不帮解码加速。如果要优化生产部署，还需要 FP8 KV Cache（2× 容量）+ 推测性解码（2-3× 解码加速）+ PD 分离架构（>2 节点规模）。LMCache 只是第一步。
// 跟我在做的事有什么关系
我每天跑 GitHub AI 日报自动化，本身就是一个典型的 Agentic 工作负载——长上下文、多轮对话、重复前缀（系统提示和工具定义）。我用的 AI Agent 每次启动都要重新加载几十 k 的上下文，如果 vLLM 的 HBM 缓存淘汰了之前的 KV Cache，光 prefill 就要等几十秒甚至几分钟。
LMCache 解决的就是我这种场景的痛点。而且它让我开始重新思考一个问题：在 AI Agent 的技术栈里，KV Cache 管理是不是会变成跟数据库连接池一样的基础设施标配？
我觉得答案是肯定的。理由很简单：Agent 越来越长上下文化，KV Cache 越来越大，HBM 越来越不够用。这不是一个会消失的问题，而是一个会越来越严重的问题。Jensen Huang 在 GTC 2026 主题演讲里多次提到 KV Cache 是推理瓶颈，这不是偶然。
另外，LMCache 的"Knowledge Delivery Network"定位，跟我在做的事情有个有趣的呼应——我做的日报自动化本质上也是"知识交付"，把 AI 领域的最新信息高效地送到读者面前。LMCache 做的是让 LLM 推理中的"知识"（KV Cache）高效地送到模型面前。底层逻辑一样：不要重复计算已经算过的东西。
// verdict
✅ 分层存储 + 20 种可插拔后端，真正的厂商中立
✅ CacheBlend 非前缀复用，RAG 场景杀手锏
✅ MoE 10× 性能提升，数据硬核可复现
✅ 三引擎覆盖（vLLM/SGLang/TRT-LLM），三硬件支持（NVIDIA/AMD/Ascend）
✅ PyTorch Foundation 项目 + GTC 主题演讲亮相，背书够硬
✅ Apache 2.0 可商用
❌ AMD 支持需源码编译，体验差
❌ 关键配置陷阱多（PYTHONHASHSEED、DECODE_CACHE 等）
❌ 123 Issues / 193 PRs 积压，Bus Factor 需关注
❌ 只解决 prefill 瓶颈，不帮解码加速
❌ 跨节点支持还在开发中
我的判断：KV Cache 管理会变成 LLM 推理的基础设施标配，就像 CDN 变成了 Web 的基础设施标配。LMCache 是这个赛道上最成熟的开源方案——PyTorch Foundation 项目、GTC 主题演讲亮相、Jensen Huang 亲自背书、AWS/CoreWeave/Cohere 落地案例、3 篇顶会论文支撑。它不是在做一个优化工具，它是在定义一个新的基础设施层。
如果你在做长上下文 Agent、多轮对话、RAG 等场景的 LLM 推理部署，工作集超过 250k tokens，LMCache 值得认真评估。如果你的工作集在 100k 以下，vLLM 自带的前缀缓存就够了，别过度工程化。
关注我的人知道，我每天跑 GitHub AI 日报快三个月了，不是追热点，是在追踪 AI 基础设施的真实演化方向。LMCache 这种"把临时状态变成一等公民"的设计思路，比任何一个炫酷的 Agent 框架都更值得你花时间理解。因为 Agent 会一代一代换，但推理基础设施的优化方向是单向的——只会越来越重视 KV Cache。
这是一个长期判断，我会在后续的评测中持续验证。