LMCache 报告共享 KV 缓存使平均 TTFT 降至原来的 1/13.7

一句话总结：LMCache 报告，在一个大型混合专家模型的多轮基准测试中，平均 time-to-first-token（TTFT）从 3.98 秒降至 0.29 秒，两者之比为 13.7。项目保持模型、八块 H100 GPU 和 400 GB 主机侧缓存总容量不变，把八个按 rank 隔离的池改成一个共享池。

这是一个有参考价值的架构结果，不是对所有工作负载都能提升 13.7 倍的承诺。工作负载、软件版本、请求路由、缓存命中和系统配置均由 LMCache 团队提供，Wavect 没有复现该测试。本文说明报告中的机制、结论边界，以及判断同一模式能否帮助你自己的 LLM 服务所需的证据。

基准测试中的问题：每个 rank 都有隔离缓存

在自回归推理中，KV 缓存保存已处理 token 的中间注意力键和值。如果后续请求包含可复用的完全相同前缀，且服务栈能访问兼容的缓存块，就可能避免重复一部分 prompt prefill。收益取决于提示词长度、模型、硬件、批处理、命中率、传输路径和并发等条件。

陷阱在这里。在该基准测试的拓扑中，vLLM 使用了八个数据并行 rank，并启用了自动专家并行：注意力层在各块 GPU 上复制，Mixture-of-Experts 层则被分片。每个 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 工作。

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

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

平均 TTFT 的 13.7 比值来自架构变化，而不是模型算法变化。在传统的进程内设置中，每个服务进程嵌入独立的缓存库，主机侧池彼此隔离。LMCache 的 Multi-Process 模式把缓存管理移到独立服务，并让注册的服务进程连接到同一个主机侧共享池。

这样，400 GB 总容量从八个进程本地的 50 GB 池变成一个共享层。出现兼容命中时，另一个注册进程可以取回可复用的 KV 块，而不必重复相应的 prefill。模型和 GPU 硬件保持不变，变化的是缓存架构及相关服务配置。

基准测试数字

这些数字来自 LMCache 发布的 Qwen3-235B-A22B-Instruct-2507-FP8 多轮对话基准测试，环境为八块 NVIDIA H100 80GB GPU、vLLM 0.18.1 和 LMCache 0.4.3-dev。测试以每秒两个请求运行 120 秒，对比进程内卸载与 Multi-Process 模式。这是项目作者在一个系统和工作负载上的结果，不是独立基准测试，也不是对你自己流量的保证。

要同时看结果形态和边界，而不只是标题数字。发布的工作负载专门产生多轮前缀复用，因此直接触发了碎片化问题。平均 TTFT 和 P99 TTFT 都在这次测试中改善。报告的解码速度也发生变化，但文章没有提供足够的独立重复、误差分析、原始跟踪数据或其他工作负载，不能据此推广这些比值。

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

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

如果可复用计算无法跨进程或节点访问，自托管推理也可能出现类似浪费。在购买更多 GPU 容量之前，应测量重复前缀、缓存命中、prefill 时间、GPU 利用率和路由。复用并非免费，它会增加内存、传输、查找、协调、隔离、正确性和运维成本。我们在 降低 LLM token 成本 指南和 本地模型对比 API 的盈亏平衡分析 中也采用完整成本口径。

如果复用优化已经做完，而且一个模型长期承担稳定、低延迟负载，下一步才是专用硬件。我们的 Taalas HC1 硬编码 LLM ASIC 评测解释了每秒 17,000 token 真正证明了什么，以及用模型灵活性换速度前必须验证哪些问题。

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

请求重叠会创造缓存复用机会，但不能单独决定结果。兼容前缀、路由、淘汰、传输成本、缓存容量、并发和基线实现都会影响实测收益。

独立缓存服务会增加进程间协调路径、一个需要保护和监控的组件、容量与淘汰决策，以及命中和未命中时的查找或传输工作。兼容复用较少或传输成本较高时，开销可能超过节省的 prefill。应把共享缓存视为取决于工作负载的选项，而不是所有对话式或长上下文服务的默认配置。

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

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

预计每月收益 = 避免的计算与容量成本 - 缓存基础设施、传输、工程、安全和运维成本

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

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

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

在采用它之前要问的问题

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

来源与结论边界

这个架构、400 GB 碎片化示例和基准数字来自 LMCache 的 Multi-Process 基准文章、项目的 GitHub 仓库和文档。延迟和吞吐数字属于项目作者及其测试系统，即一台运行 vLLM 0.18.1、LMCache 0.4.3-dev 和 Qwen3-235B-A22B 的 8x H100 服务器。Wavect 没有复现这些结果。相关事实于 2026 年 9 月 2 日再次复核。