一个共享 KV 缓存如何在不新增 GPU 的情况下把 LLM 推理延迟降低 14x

一句话总结：一个名为 LMCache 的开源 KV 缓存层，在一个大型混合专家（MoE）模型上把平均 time-to-first-token 降低了大约 14x，而且它没有用上更快的 GPU、更小的模型或更多的内存。唯一改变的是缓存所在的位置。原本各自囤积私有缓存的八个服务进程，变成了八个共享同一份缓存的进程。

这就是全部要点，而它的意义超出了这一个库。大多数推理优化被包装成购买更快的硬件。你付出的很多延迟，其实是你自己的系统在重新计算一个它已经拥有的答案，只是那份缓存归属于错误的进程。本文解释了改变了什么、这些数字能证明和不能证明什么，以及如何判断同样的架构是否会对你自己的 LLM 服务有帮助。

昂贵的默认做法：每个 rank 都囤积自己的缓存

当一个模型服务一段对话时，它不会在每一轮都重新读一遍整个历史。它会存储自己已经见过的 token 的中间注意力状态。这份存储就是 KV 缓存（key-value cache），而复用它正是聊天第二轮比第一轮快得多的原因。重新计算它的过程叫做 prefill（预填充），而 prefill 正是回答一个长提示词中昂贵的那部分。

陷阱在这里。为了快速服务一个大模型，你会在一台服务器上并行运行它的多个副本，每个 GPU 一个，各自处于独立的进程中。在传统的设置里，这些数据并行的 rank 里每一个都保有自己的私有 KV 缓存。这些缓存之间从不通信。

LMCache 自己的基准测试把这个代价说得很具体。Qwen3-235B-A22B 跑在八块 H100 GPU 上。每个 rank 分到 50 GB 的 CPU 内存用于 KV 缓存卸载，因此这台服务器总共持有 400 GB。纸面上这是一份很大的缓存。但实际上它是八个各自隔离的 50 GB 缓存，而不是一份共享的 400 GB 缓存。

现在设想一段真实的多轮对话。第一轮被路由到 rank 3，它计算并缓存了上下文。同一段对话的第二轮被路由到了 rank 6。rank 6 看不到 rank 3 缓存的内容。它所需要的那个确切状态就躺在同一台物理服务器的主机内存里，但它归属于另一个进程，因此模型只能做它唯一能做的事：从头开始把整段对话重新 prefill 一遍。这段计算你已经付过一次费。每一轮落在不同 rank 上时，你都要再付一次。

LMCache 改变了什么：用一份缓存代替八份

LMCache 是一个开源的、采用 Apache-2.0 许可的 KV 缓存层，面向 vLLM 和 SGLang 这类推理引擎。它的职责是把 KV 缓存从稀缺的 GPU 内存中移出，放进一个由 CPU 内存、本地磁盘和远程存储构成的分层体系中，并让缓存能够跨请求、跨会话、跨引擎实例被复用。

产生 14x 这个数字的改变是架构层面的，而不是算法层面的。在传统的进程内设置里，每个服务进程内部都嵌入了一个独立的缓存库，这正是缓存彼此隔离的原因。LMCache 的 Multi-Process 模式（多进程模式）把缓存从各个进程中抽离出来，作为一个独立的服务来运行。节点上的每个服务进程都向它注册，并从同一个主机侧的池中读取。

于是同样的 400 GB 不再是八个被隔开的桶，而成为一个共享的层。当第二轮落在 rank 6 上时，rank 6 向共享缓存发起询问，找到 rank 3 已经计算好的状态，从而跳过 prefill。模型、硬件和总的缓存容量全都完全一样。只不过那份计算不再被丢弃。

基准测试数字

这些数字来自 LMCache 发布的、在 Qwen3-235B-A22B-Instruct-2507-FP8 上的多轮对话基准测试，运行环境为八块 NVIDIA H100 80GB GPU、vLLM 0.18.1 和 LMCache 0.4.3-dev。它们比较的是传统的进程内卸载与 Multi-Process 模式。这些是作者报告的结果，基于单一硬件和工作负载；请把它们当作一个有力的方向性信号，而不是对你自己流量的保证。

要看形状，而不只是看标题数字。收益最大的地方，正是隔离缓存伤害最深的地方：那些原本需要重新 prefill 一段长历史的冷启动轮次。平均 TTFT 从约四秒降到不到三分之一秒，是一个感觉迟钝的聊天和一个感觉即时的聊天之间的差别。对一个产品来说，P99 的改善甚至更重要，因为长尾才是你最慢的那批用户实际体验到的东西。

为什么即便你从不碰 LMCache 这件事也很重要

重点不是你应该去装某一个特定的库。重点是浪费藏在哪里。服务器已经做完了这份工作。它有内存来保留结果。它把结果丢掉了，只因为那份缓存是按进程划分的，而不是按节点共享的。

这种模式在自托管推理里到处都是：已经付过费的计算，只因为系统是怎样拼装起来的（而不是它有多少硬件）而被丢弃。在有人批准一笔更大的 GPU 采购之前，更便宜的问题是：现有的这些机器是不是在重新计算它们已经持有的答案。购买容量是解决一个问题的昂贵办法，而复用往往能免费解决这个问题。我们在关于 降低 LLM token 成本 的指南里对开销提出了同样的论点，也在 本地模型对比 API 的盈亏平衡分析 里对硬件提出了同样的论点。

共享 KV 缓存在哪里有帮助，在哪里没有

缓存复用带来的回报，与你的请求之间重叠程度成正比。它是一个杠杆，而不是一条定律，所以在期待 14x 之前，请对你自己的流量诚实一点。

共享一份缓存也并非免费。一个独立的缓存服务增加了一次网络跳转、一个需要运维和监控的活动部件，以及一次在未命中时会花费一点延迟的查找。当请求之间几乎不重叠时，这份开销可能会超过节省下来的 prefill。对于对话式和长上下文服务，这个架构是一个有力的默认选择，而不是一次普适的升级。

这真的能削减你的推理账单吗？

更快并不等于更便宜。一次延迟上的胜利，只有在它从账单上抹去了某项开销，或让你能用同一台机器服务更多流量时，才会变成一次成本上的胜利。用你实际运行的东西来给这个改变定价：

每月收益 = 不再花在重复 prefill 上的 GPU 小时 + 每块现有 GPU 更高的吞吐 + 推迟的硬件采购 - 缓存服务的开销与运维时间

被复用的 prefill 释放了 GPU 时间，而释放出来的 GPU 时间，要么意味着一个更小的集群，要么意味着在当前集群上服务更多流量。干净利落的胜利在于跨过一个阈值：一个你现在无需新增节点就能满足的延迟目标、一个同样的 GPU 现在能维持的并发水平，或者一次你可以推迟的既定硬件升级。如果你的请求很少重叠，诚实的答案是：节省很小，你的精力花在别处会更好。要看这件事所汇入的完整的自建对比租用全景，请通读 在欧盟自托管 LLM 到底要花多少钱。

在你重连服务架构之前的一次简短评估

1. 测量你的复用度。在动架构之前，记录请求共享前缀或延续同一段对话的频率有多高。重叠就是这份奖赏的全部大小；如果它很低，到此为止。
2. 为长尾建立基线，而不只是均值。在你真实的流量上记录 P50 和 P99 的 TTFT 与解码速度。基准测试最大的收益出现在长尾上，而长尾才是用户感受到的东西。
3. 确认拓扑是否匹配。这 14x 来自把一个节点上多个数据并行的 rank 统一起来。如果你今天是每块 GPU 一个进程，那你就有它所修复的这种碎片化；如果你跑的是单个进程，那你没有。
4. 在影子流量或一部分流量上试点。把一份副本或一部分流量路由到共享缓存的设置中，并在相同的硬件和工作负载上与基线作比较。
5. 给它定价，而不只是计时。把测得的延迟和吞吐变化换算成 GPU 小时、节点数量或推迟的采购，再减去运行缓存服务的成本。

在采用它之前要问的问题

• 我们的请求中，实际上有多大比例共享一个前缀或延续一段已有的对话？
• 我们是否在每个节点上运行多个数据并行的 rank，以至于隔离缓存对我们来说才算得上是个问题？
• 在生产流量上（而非基准测试上），我们当前的 P50 和 P99 的 TTFT 与解码数字是多少？
• 那个独立的缓存服务，在未命中时的延迟上、在运维面上、以及在故障模式上，各让我们付出什么代价？
• 延迟收益是否会转化为更少的 GPU、更高的吞吐或一次推迟的采购，又能转化多少？
• 这个缓存层的成熟度、许可证和维护状态如何，以及在必要时我们能否运维或 fork 它？

来源与结论边界

这个架构、400 GB 的碎片化示例以及所有基准测试数字，均来自 LMCache 的文章 "LMCache's New Architecture Boosts MoE Inference Performance by 10x"，以及该项目的 GitHub 仓库 和 文档。所报告的延迟和吞吐数字归属于其作者及其测试系统，即一台 8x H100 服务器，运行 vLLM 0.18.1 和 LMCache 0.4.3-dev，跑 Qwen3-235B-A22B；Wavect 没有复现它们。事实核对于 2026 年 7 月 23 日。