一个上下文 30K Tokens的多轮代码分析任务，在引入一项优化技术后，任务的缓存命中率可以维持在80%以上，其首个Token响应速度相较于重计算也可以提升约5到10倍。这一数据并非理论推演，而是英博数科在英博云平台上的实测结果。

在大模型深入应用于各行业的今天，尤其在多轮对话、RAG、智能体（Agent）等需要长上下文的复杂场景下，模型能否迅速响应以获得丝滑体验，极大地受到了推理效率的制约。今天，我们将为您详细介绍这项关键的推理效率加速技术—— 多层级 KV-Cache。接下来，您将看到它是如何在vLLM、SGLang 等主流框架中发挥威力，并为您的AI 应用带来实实在在的性能红利。

引言

随着大模型在各个领域的广泛应用，应用形态也从最初的对话式 ChatBot，逐步演进到 RAG、Agent 乃至多 Agent 协作。在这一过程中，推理效率与成本优化逐渐成为业界关注的核心问题，尤其是在超长上下文的支持场景下，如何在有限算力资源下实现高效推理，已成为当前大模型实践中的关键挑战。

本文旨在通过梳理 Attention机制与KV-Cache的关系，阐述KV-Cache的必要性、多层级KV-Cache的作用，并结合vLLM、LMCache与SGLangHiCache的示例，帮助读者建立对多层级KV-Cache的直观理解。

KV-Cache 的必要性

在当前百花齐放的大模型生态中，基于 Transformer 的模型架构被模型开发者们广泛采用。而 Attention 机制作为其核心部分，可以让模型在处理输入序列时“有选择地”关注重要信息，因此可以大大提高模型理解复杂语言和逻辑关系的能力。

Attention 机制在处理输入序列时，预测出的下一个Token是基于之前输入的Tokens的K、V向量并结合当前Token的Q、K、V向量经过一系列计算得出的。那么在处理或生成一个很长的序列时，每一次Token的生成过程都会存在大量针对之前Tokens的K、V向量的重复计算。针对这些大量的重复计算，很自然的一个优化思路就是对Tokens的K、V向量计算结果进行缓存，消除重复计算，也就是KV-Cache。

多层级KV-Cache 的作用

通过利用“以存换算”的KV-Cache，Attention机制的自回归计算效率可以得到显著提高，从而可以大大降低模型推理时的TTFT，提升用户体验。但随着大模型在各个领域应用愈加广泛，以大语言模型的实际应用为例，从最开始的ChatBot，到RAG再到现在的Agent甚至多Agents协作，其上下文长度也得到了跨越几个数量级的增长。以最大上下文长度为128KTokens的Llama3.1-70B为例，FP16格式下每个Token的KV-Cache大小约为320KiB，最大上下文长度下的KV-Cache总大小约为39GiB，由于GPU显存的容量限制，在GPU中同时容纳模型权重、中间计算结果等并缓存所有Tokens的KV-Cache并不现实。尽管在vLLM/SGLang等推理引擎中都提供了对GPU中的KV-Cache做诸如驱逐、释放等管理操作，但仅依靠此类机制已经不足以有效解决逐渐膨胀的KV-Cache大小与有限的显存容量之间的矛盾，KV-Cache的丢弃与重计算无法避免。

那我们是否可以使用额外的存储来“扩展”有限的GPU显存呢？实际上我们发现在进行算力集群建设时，除了给集群配备IB/RoCE高速网络资源，服务器内通常还配备了3:1配比以上的内存资源与显存资源，高速的PCIe5.0总线 ( 16通道带宽为63GB/s），SSD/NVMe本地存储甚至高性能的网络存储。而业界的探索也聚焦于利用这些资源实现将KV-Cache存储到内存甚至本地/网络存储中，扩展显存中的“以存换算”，从而构建一个多层级的异构KV-Cache系统。

开源社区中的多层级 KV-Cache 方案以 LMCache 为代表，随后也涌现了如 NVIDIA Dynamo、SGLang HiCache 等各种优秀方案。

实验

我们将分别使用 vLLM + LMCache、SGLang HiCache 来完成一个简单地使用多层级 KV-Cache 进行具体 Python 代码分析的示例，帮助大家建立对多层级 KV-Cache 的直观理解。

实验方式

本次实验我们使用的硬件为单卡 A800 80G，模型使用 Qwen/Qwen3-14B，推理引擎分别使用 v0.10.1.1 版本的 vLLM 以及 v0.5.3rc1 版本的 SGLang。

在实验用例设置上，我们使用 x1xhlol/system-prompts-and-models-of-ai-tools项目中的Devin AI 提示词作为系统提示词，选用AutoGenv0.2.40版本中两个有逻辑关联关系的Python文件conversable_agent.py以及agent.py作为两轮对话的代码分析语料，其中conversable_agent.py作为第一轮对话的代码分析语料，agent.py结合第一轮对话的上下文作为第二轮对话的代码分析语料。它们的Tokens数目分别为7407，29201，979，总Tokens数目为37587，在不超过Qwen/Qwen3-14B最大支持的40960上下文长度的同时，可以尽可能模拟超长上下文的使用场景。

vLLM + LMCache

LMCache 作为推理引擎的扩展中间件，用于在推理引擎的KV-Cache操作过程中提取和注入KV-Cache。推理引擎对输入文本进行Prefill计算出KV-Cache后，LMCache对其进行存储，在后续请求中推理引擎通过LMCache对相同输入文本块的KV-Cache进行复用，从而实现减少显存使用、降低TTFT的效果。LMCache通过实现vLLM的kv_connector机制，为vLLM提供了LMCacheConnector。此外LMCache还设计了一组抽象的存储后端接口，允许开发者灵活地为KV-Cache接入不同的存储介质。

我们将使用 vLLM + LMCache 测试对比三组不同配置下的推理性能表现，测试结果如下。

1.基准测试

Prefix Caching 是vLLM 提供的一种基于前缀匹配的KV-Cache 优化方式。开启该特性后vLLM 在处理请求时会按固定大小对输入Tokens 划分多个Blocks，并通过前缀匹配的方式来匹配已计算KV Cache 的Blocks，对这些KV-Cache 进行复用。关闭该特性则vLLM 在每次处理请求时都会重新进行计算。

 通过基准测试可以看到 vLLM 的 Prefix Caching 可以大大降低 TTFT。

2.CPU RAM 作为 KV-Cache 的存储后端，配置使用 50 GiB 的内存空间

通过对比本组测试和基准测试的结果，我们可以得到：

• 在未开启 vLLM 的 Prefix Caching 时，使用内存作为 KV-Cache 的存储后端也可以带来 TTFT 的降低，但是相比在显存中进行 KV-Cache 存储，其降低 TTFT 的效果会相对较差一些
  

• 同时启用LMCache和PrefixCaching和仅启用PrefixCaching两种情况下复用的KV-Cache均位于GPU显存中，TTFT上的差别主要是体现在LMCache这一层的Overhead上

此外如果我们在实验开始前后查看系统的内存占用会发现，在启用 CPU RAM 作为 KV-Cache 存储后端时，LMCache 会按照配置进行内存的分配与释放。

结合 vLLM 的日志，我们可以获得推理过程中 LMCache 的相关指标，如 KV-Cache Size、写入耗时、KV-Cache 命中的 Tokens 数目等。以下分别为第一轮和第二轮请求对应的 vLLM 日志。

值得注意的是在第二轮请求对应的日志信息中，可以看到通过LMCache 对38400 Tokens 中的36608 Tokens 进行了复用。

此外，为了模拟典型的多用户多轮对话场景，我们在进行两轮对话后，使用不同的长上下文再进行约 15 轮的对话，然后再次使用我们的代码语料进行两轮对话。

在仅开启 Prefix Caching 时，我们可以观察到后两轮代码分析对话的TTFT 分别为6.9937s 和0.4635s。这说明最开始的两轮代码分析对话的KV-Cache 在后续对话的处理过程中被丢弃，因此后两轮代码分析对话中的第一轮请求仅复用了少量 KV-Cache 并进行了大部分的重计算。

在仅开启 LMCache 时，我们可以观察到后两轮代码分析对话的TTFT 分别为0.4001s 和0.7179s。这说明我们通过LMCache 可以更加持久地维持KV-Cache 并达到“扩展”显存的效果。以下为后两轮对话中的第一轮对话对应的日志信息，可以看到LMCache 对37731 Tokens 中的36608 Tokens 进行了复用，在多用户多轮对话场景下仍能保持很高的缓存命中率。

3.LocalStorage + CPU RAM 作为 KV-Cache 的存储后端，配置使用 50 GiB 的本地存储和内存

由于我们配置了充足的内存可以完全容纳实验的 KV-Cache，因此本组测试结果与上一组只使用 CPU RAM 的结果接近。不同之处在于 LMCache 在进行 KV-Cache 的存储时，还会在配置指定的目录下写入对应的文件。

此外，如果我们调整配置文件将使用的内存大小从 50 GiB 调整为更小的 2 GiB，那么在进行 KV-Cache 的写入和读取时会经过本地存储，因此 TTFT 的降低效果没有从 CPU RAM 中读取 KV-Cache 时明显。 

SGLang HiCache

SGLang HiCache是SGLang团队提出的多层级KV-Cache方案。HiCache通过扩展SGLang的RadixAttention，实现高效地对位于本地GPU、CPURAM内的KV-Cache进行检索，并通过CacheController对多层级KV-Cache进行管理，使得SGLang可以从本地GPU、CPURAM以及远程存储中加载和使用KV-Cache。此外，SGLangHiCache提供了一组简洁的接口允许开发者快速地集成自定义的KV-Cache存储后端。

我们将使用 SGLang HiCache 测试三种不同配置下的推理性能表现，测试结果如下。

1.基准测试

Prefix Caching 是SGLang 提供的一种基于RadixTree 进行前缀匹配的KV-Cache 优化方式。开启该特性后SGLang 同样可以实现对请求中的输入按照前缀匹配进行KV-Cache 复用，并且得益于RadixTree 的组织方式，SGLang 在多轮对话等场景下的缓存命中率会更高。

通过基准测试可以看到 SGLang 的 Radix Prefix Caching 可以大大降低 TTFT。

2.MooncakeStore 作为存储后端

由于目前 SGLang的HiCache实现要求RadixPrefixCaching功能的开启，因此我们仅在基准测试之外添加了一组使用MooncakeStore作为KV-Cache存储后端的测试。为了降低实验复现的资源门槛，我们使用了TCP作为MooncakeStore的传输协议，而没有选择使用RDMA。

如果我们查看 Mooncake Master 服务的日志，我们可以观察到存储使用量、Keys 数目等指标的增长。

以上实验均基于英博云（ebcloud.com）平台完成，实验方法参见如下项目：https://github.com/ebtech-ebcloud/job-template/tree/main/paper/2509-hierarchy-kvcache

在项目README 中，我们提供了复现实验的操作步骤说明，包括配置使用英博云（ebcloud.com）平台上的4090、A800、H800 等多种算力资源，使用vLLM、SGLang 进行实验，以及实验环境的清理。用户也可直接使用README 中提及的镜像启动开发机进行更细致的实验。

项目中还整理了实验相关的Python 脚本、LMCache 配置文件、Mooncake Store 配置文件、代码语料以及Dockerfile 等内容，用户可以按需使用和调整。

总结与展望

我们实践了在 vLLM、SGLang 推理引擎上使用 CPU RAM、LocalStorage、Mooncake Store 三种不同的 KV-Cache 存储后端，可以确认通过使用这些较大容量的扩展存储，我们的推理服务可以对更多 Tokens 的 KV-Cache 进行存储，并可以获得不同程度的 TTFT 降低效果。

除了 vLLM + LMCache、SGLangHicache两种方案，NVIDIA提出的高吞吐、低延迟的分布式推理框架Dynamo也是值得注意的一种多层级KV-Cache方案。Dynamo作为一个推理引擎无关的框架，围绕KV-Cache建设了NIXL、KVBlockManager等通用组件，可以灵活地对推理服务进行编排和部署。

但在进行多层级 KV-Cache 的生产落地之前，我们需要回归到一个基本问题：我们的推理系统是否真的需要多层级 KV-Cache 系统？如果 KV-Cache 重计算的效率要远远高于 KV-Cache 传输，是否可以不需要对 KV-Cache 进行缓存，这些取舍都需要结合推理系统的实际运行情况来考虑。此外在使用多层级 KV-Cache 时，数据通常会在存储/内存、PCIe、GPU、网卡等路径间流转，我们需要对资源争抢等情况做控制。并且由于引入了一层额外的缓存系统，这会给现有的推理系统带来可观测性、健壮性、容灾等方面的挑战。在用户数据的隐私安全方面，我们也需要考虑保证多租户之间的 KV-Cache 隔离性。

明确上述问题之后，我们在选用开源社区的多层级 KV-Cache 方案时仍需要了解以下现状：

1.目前社区中的KV-Cache传输方案彼此并非正交。vLLM通过kv_connector机制集成了LMCache、NIXL等传输方式，LMCache也提供了NIXL、Mooncake等多种KV-Cache传输后端；NVIDIANIXL可以提供Mooncake、GDS、UCX等作为传输后端；SGLang的HiCache也分别提供了NIXL、Mooncake的传输实现。因此在选型时需要结合不同技术在整合时的功能完备性、性能开销，仔细考量使用哪些组合。

2.对不同推理引擎的兼容性。目前 LMCache 对 vLLM 的兼容性要优于 SGLang；而 Dynamo 的基于其 KVBM 组件提供的多层级 KV-Cache 能力目前仅支持 vLLM + LMCache 的组合。

除此之外，多层级 KV-Cache 还有一些值得探索的方向，感兴趣的读者可以关注社区在相关功能上的迭代与演进。

1.与推理系统中的 Router 整合。通过多层级 KV-Cache Aware 的调度策略将请求转发给最优的推理实例，以获得最好推理性能。

2.KV-Cache 的优先级和 KV-Cache 在不同层级间的移动。根据 KV-Cache 使用频次等指标划分优先级并动态将 KV-Cache 在不同层级存储中移动，从而实现最热/最重要的KV-Cache 能最快被读取到，次要 KV-Cache 及时从高速存储中 Offload。

3.与 PD 分离部署架构的结合。多层级 KV-Cache 可以作为每个推理实例上的扩展 KV-Cache，减少单个实例上的 KV-Cache 重计算和跨实例的 KV-Cache 传输，也可以作为整个推理系统的共享 KV-Cache Pool 被每个推理实例使用，减少推理系统内的 KV-Cache 重计算。

从 ChatBot 到多 Agent 系统，从短文本到超长上下文，大模型的应用边界正不断拓展，而推理效率与成本控制，是每一家AI 驱动型企业必须面对的课题。

多层级 KV-Cache 正是业界在“算力有限、场景无限”的现实条件下，找到的一条务实路径。它不仅是技术的演进，更是工程思维与系统能力的体现。

英博数科作为鸿博股份（002229）旗下全资子公司，始终以“高效益、多样化”为核心方向，致力于成为全球领先的AGI 服务商，持续关注并推动推理优化技术在实际业务中的落地。未来，我们也将围绕多层级 KV-Cache 与调度系统、PD 分离架构等方向展开更深度的探索，助力客户在AI浪潮中跑得更快、更稳。

如果你对 KV-Cache 技术或 AI 推理优化有更多兴趣，欢迎持续关注，获取更多技术实战与行业洞察。

本文实验基于英博云（ebcloud.com）平台完成，项目源码与复现方法已开源：https://github.com/ebtech-ebcloud/job-template/tree/main/paper/2509-hierarchy-kvcache

参考资料

·https://arxiv.org/pdf/1706.03762

·https://github.com/LMCache/LMCache

·https://lmcache.ai/kv_cache_calculator.html

·https://blog.lmcache.ai/2025-04-22-tencent/

·https://github.com/kvcache-ai/Mooncake

·https://github.com/ai-dynamo/nixl

·https://github.com/ai-dynamo/dynamo

·https://github.com/sgl-project/sglang

·https://github.com/sgl-project/sglang/blob/main/sgl-kernel/csrc/kvcacheio/transfer.cu

·https://lmsys.org/blog/2025-09-10-sglang-hicache/

·https://docs.nvidia.com/dynamo/latest/architecture/kvbm_architecture.html

·https://docs.nvidia.com/dynamo/latest/components/backends/vllm/README.html

·https://docs.nvidia.com/dynamo/latest/components/backends/sglang/README.html

·https://github.com/microsoft/autogen/blob/v0.2.40/autogen/agentchat/conversable_agent.py

·https://github.com/microsoft/autogen/blob/v0.2.40/autogen/agentchat/agent.py

·https://github.com/x1xhlol/system-prompts-and-models-of-ai-tools/blob/037c0dc161e81c8318f65f7c876f10e55e771edb/Devin%20AI/Prompt.txt