LMCACHE：面向企业级大语言模型推理的高效KV Cache层

作者：Yihua Cheng 、Yuhan Liu 、 Jiayi Yao * 、Yuwei An、Xiaokun Chen、Shaoting Feng 、 Yuyang Huang、Samuel Shen、Kuntai Du、Junchen Jiang

单位：TensorMesh&芝加哥大学

摘要

如今的大语言模型（LLM）推理系统为简化设计，将各个推理引擎和请求独立处理，这导致了严重的资源效率低下问题。尽管已有相关方案提出通过跨请求复用KV Cache来避免冗余计算，并通过将单个请求拆分到不同推理引擎来提高 GPU 利用率，但这些方案的实现离不开 跨推理引擎与请求之间的高效KV Cache卸载和传输。本文提出 LMCACHE，首个且目前最高效的开源 KV Cache缓存解决方案。它能够提取并存储主流 LLM 推理引擎（vLLM 和 SGLang）生成的 KV Cache，并支持跨引擎、跨请求共享。LMCACHE 在 LLM 引擎接口中暴露 KV Cache缓存功能，有效将 LLM 引擎从独立的token处理器转变为以 KV Cache缓存作为存储和通信介质的引擎集合。具体而言，它既支持缓存卸载（跨请求的前缀复用），也支持预PD分离架构（跨引擎缓存传输）。LMCACHE 的高性能和广泛应用源于三大核心贡献：（1）高度优化的 KV Cache数据传输机制，包括批量数据传输操作、计算与 I/O 流水线等性能优化；（2）模块化的 KV Cache连接器组件，使 LMCACHE 与快速迭代的推理引擎解耦；（3）完备的控制 API（如缓存固定、查找、清理、迁移和压缩），支持在 GPU、CPU、存储设备和网络层之间灵活编排缓存。评估结果显示，LMCACHE 与 vLLM 结合使用时，在多轮问答、文档分析等工作负载中吞吐量最高可提升 15 倍。随着社区不断发展，LMCACHE 已被大量企业推理系统采用，为未来 KV Cache缓存解决方案提供了宝贵实践经验。源代码地址：https://github.com/LMCache/LMCache。

1. 引言

如今，大语言模型推理的增长速度已超过训练。LLM 推理支撑着众多应用场景，从交互式客户支持、代码生成，到基于检索的文档分析和智能体工作流。然而，LLM 推理系统的发展却相对滞后——延迟（包括响应延迟和生成速度）和成本已成为当前的主要瓶颈。

当前 LLM 推理系统的核心局限在于，每个用户请求由单个推理引擎实例独立处理，请求之间、推理引擎之间无法复用任何数据。这意味着 LLM 请求的生命周期（包括计算和 I/O 操作）仅发生在单个推理引擎的 GPU 和 GPU 内存中。每个请求接收一个token序列作为输入，输出另一个token序列，请求完成后，推理过程中生成的所有输出结果或中间状态都会被丢弃。

这种设计虽简单直观，但导致了冗余计算和资源利用率不足。业界已提出两项代表性方案以解决这些问题（图一所示）

---

跨请求缓存：避免冗余计算：由于每个请求被独立处理，每当相同的上下文（前缀）被使用时，LLM 都必须重新执行Prefill操作。重复的Prefill计算开销巨大且会导致响应缓慢 —— 用户必须等待预填充完成才能看到第一个生成token。然而，若能将Prefill后 LLM 内部生成的前缀 KV Cache持久化保存（突破单个请求的生命周期限制），后续复用该前缀的请求（如使用相同提示模板或检索到的文档片段）便可直接复用该 KV Cache，从而避免冗余计算。通过这种跨请求上下文（前缀）缓存机制，可显著降低Prefill阶段的首token生成时间（TTFT）和整体 GPU 资源消耗。

PD分离：提高资源利用率：将Prefill阶段（计算密集型、吞吐量导向）和decode阶段（内存密集型、延迟敏感型）部署在同一推理引擎中，会导致资源利用率不足。为保证decode延迟稳定且不受prefill操作干扰，GPU 必须过度配置。对此，业界提出将吞吐量导向的prefill处理与延迟敏感的decode处理解耦的方案。这种PD分离架构将所有请求的prefill阶段集中在一组推理节点上执行，再将生成的 KV Cache传输到另一组专门执行decode阶段的推理节点，从而在高并发场景下降低decode尾部延迟。

要使这些方案落地，LLM 推理系统必须增加新的 KV Cache缓存语义支持：推理引擎需提供新接口，支持从常规推理调用中提取 KV Cache，并按需将 KV Cache重新加载到后续请求中；系统需支持将提取的 KV Cache持久化存储，并在分布式推理引擎之间传输；最重要的是，KV 缓存的提取、重新加载、存储和传输必须高效，且新接口需与快速迭代的推理引擎（如 vLLM 和 SGLang）保持兼容。

本文引入 LMCACHE—— 首个开源库，提供了这些新 KV Cache缓存语义的高性能实现。借助 LMCACHE，KV Cache缓存可高效地从推理引擎中提取并重新加载回推理引擎，存储在多层存储设备（CPU 内存、本地磁盘、远程磁盘和 Redis）中，并通过不同网络（以太网、RDMA、NVLink）传输。

LMCACHE 的三大核心贡献如下：

1. 高度优化的性能：集成一系列性能优化手段，使 KV Cache的存储和加载在实际部署中高效可行。例如，批量处理操作以实现 KV Cache存储和加载的流水线化，以及 GPU 计算与数据加载 / 存储的流水线化（如在执行当前层计算时加载下一层的 KV Cache）；采用远大于推理引擎原生小页面尺寸的可配置块大小存储 / 加载 KV 缓存，充分利用存储设备与 GPU 内存之间的带宽；通过零拷贝操作，最大限度减少 KV Cache在不同存储层级间移动时的数据拷贝。
2. 推理引擎的标准化接口：定义标准化连接器接口，与快速迭代的推理引擎后端保持兼容。2025 年平均每周有 15-20 个新的开源权重模型发布，为充分利用新硬件支持新模型，现代 LLM 推理引擎必须快速迭代，这可能会改变 GPU 内存中的 KV 缓存布局，进而影响 LMCACHE 接口。为此，LMCACHE 设计并实现了模块化 KV 缓存连接器接口，使 LMCACHE 与推理引擎后端解耦，能够轻松适配推理引擎不断演进的 API。
3. 灵活的 KV Cache管理接口：LMCACHE 引入的接口扩展将 KV Cache（LLM 推理中的一种新数据结构）暴露出来，提供了定位、迁移、固定甚至压缩从推理引擎中提取的 KV Cache的 API。这些原生 API 使请求调度器或路由器等高层应用能够做出更优决策（如基于 KV Cache的请求路由）。

评估结果表明，LMCACHE 在多种场景（包括本地前缀缓存、分布式前缀复用和 PD 分离）中，性能持续优于开源推理框架的内置 KV Cache缓存机制和商业推理 API，吞吐量最高提升15 倍，延迟至少降低 2 倍。除量化性能提升外，LMCACHE 已被多家企业和开源项目采用，为生产级 KV 缓存驱动的优化提供了实践经验。

本文其余部分将详细介绍研究动机（第 2 章）、LMCACHE 架构与核心设计决策（第 3-6 章）、实验评估（第 8 章）和部署经验（第 9 章）。

2. 动机

2.1 推理成本与延迟成为瓶颈

过去两年，LLM 在各类企业应用中的部署呈爆发式增长。随着基于 LLM 的应用用户规模和请求量不断扩大，推理阶段的成本和延迟（而非训练阶段）已成为阻碍 LLM 服务规模化部署的主要瓶颈。

推理成本：除用户请求量增加外，输入长度和输出长度的不断增长也推高了推理成本 —— 每个输入token和输出token都需要额外的计算开销。导致输入输出长度增长的四大趋势如下：

1. 用户与 LLM 的交互增多，形成更长的用户历史，这些历史会作为上下文附加到后续 LLM 输入中；
2. LLM 越来越多地支持多模态输入（如图像、视频），这些输入通常需转换为长token序列后再输入 LLM；
3. 新一代 LLM 支持更长的上下文窗口，使上下文 / 提示工程师能够在输入中嵌入更多token；
4. 推理型模型会生成异常长的输出，这些输出可能在后续工作流中作为输入传递给其他请求。

推理延迟：在交互式应用中，尾部延迟（如 95 分位 / 99 分位延迟）与中位数延迟同等重要。最坏情况下的缓慢响应（通常由资源竞争或长上下文处理导致）会直接降低用户体验，甚至导致用户流失，这与视频流卡顿对观众体验的影响类似。

行业报告和学术研究的实证观察表明：

• 对于长上下文输入（尤其是上下文长度超过 8-16K token时），首token生成时间（TTFT）主要由prefill阶段决定；
• 单流解码器的token间延迟（ITL）较低，但当多个并发会话共享 GPU 计算资源时，token间延迟会急剧上升；
• 需重新计算大型提示或重新分配内存密集型资源的场景，会对尾部延迟产生显著影响。

2.2 KV Cache缓存：跨场景优化核心

KV Cache缓存最初被引入是为了加速单个推理请求 —— 将输入token和已生成token的注意力状态以 K 和 V 张量的形式直接存储在 GPU 内存中。KV Cache有效存储了该请求中已处理token对之间的注意力信息，本质上是 LLM 原生的知识表示形式。

在所有主流 Transformer 架构中，这些缓存仅在单个请求的生命周期内使用，请求结束后即被丢弃。然而，KV Cache可扩展支持生产级服务中的两项关键性能优化：

1. 上下文缓存（跨请求 KV Cache缓存复用）：持久化存储某个请求的 KV 缓存片段，供后续复用相同前缀的请求使用。例如，文档分析中多个请求复用同一文档（片段），或多轮对话中使用固定系统提示或长前置说明。前缀缓存减少了prefill阶段的冗余计算，直接降低了 TTFT 和每个请求的 GPU 使用时长。
2. PD分离场景（跨引擎 KV Cache传输）：将推理过程拆分为prefill阶段（处理整个输入提示）和decode阶段（自回归token生成），分别在不同 GPU 或节点上执行。这种方式通过最大限度提高解码速度（避免prefill阶段干扰），降低了尾部延迟。

KV Cache的核心作用

这两项优化均高度依赖 KV Cache片段在 GPU 内存、CPU 内存、DRAM、NVMe 存储设备之间或通过网络高效移动的能力：

• 上下文复用需将上下文的 KV Cache存储至其不再被复用为止，因此需要 KV Cache的分层存储机制和跨多个服务引擎实例的高效共享；
• PD 分离需在 GPU 之间快速传输 KV CaCHE（通常通过 PCIe、NVLink 或 RDMA），以最小化跨prefill节点和decode节点的请求端到端延迟。

2.3 高效 KV 缓存的挑战

尽管潜力巨大，但前缀缓存和 PD 分离的实际应用仍受限于三大相互关联的系统挑战：

挑战 1：分页内存下的 I/O 低效

传统 KV Cache的存储和传输依赖 PyTorch 序列化（torch.save/torch.load）或原始张量拷贝，典型传输速度仅为每秒不足 1GB。这些方法会带来显著的延迟开销（尤其是处理 KV 缓存这类大型数据结构时），且不支持与各类存储设备（本地或远程）的零拷贝操作，导致额外的 CPU-GPU 数据拷贝。

近期的高吞吐量推理引擎（如 vLLM 和 SGLang）采用分页注意力内存机制，将注意力缓冲区划分为固定大小的小页面（通常为 16-64KB），进一步加剧了 KV Cache存储和传输的挑战。例如，vLLM 在 Llama3.1-8B-Instruct 模型中使用 62.5KB 的页面。分页内存架构虽能提高批处理效率和内存利用率，但由于 KV Cache的页面并非始终连续，会导致持久化或传输 KV Cache时需要执行大量小尺寸 I/O 操作。这类小数据块传输会导致网络带宽利用率不足，降低吞吐量。已有研究表明，在通过 8 个博通 Thor-2 400Gbps 网卡连接的两个 AMD GPU 节点环境中，传输数据量需达到至少 16MB 才能饱和可用网络带宽；此外，仅当传输数据量达到兆字节级（如 1-2MB）时，才能达到 PCIe 5.0 理论带宽的 75-80%。

消息大小	传输吞吐量
64KB	4GBps
256KB	13GBps
1MB	30GBps
10MB	46GBps
16MB	49GBps
100MB	49GBps

表 1：使用 RCCL 传输库的消息大小与传输吞吐量关系

挑战 2：适配快速迭代的推理引擎

随着 AI 的广泛应用，新的 LLM 和硬件加速器层出不穷。2025 年，平均每 4 天就有一款主流 LLM 发布。为适配这些新模型或硬件，推理引擎必须快速迭代，而每次更新往往会改变 GPU 内存分配方式，进而修改 KV Cache缓存的接口。例如，当 vLLM 采用新的注意力内核导致 KV Cache缓存维度变化时，KV Cache缓存库必须同步更新，以将新内核输出的 KV Cache缓存格式转换为兼容格式。面对推理引擎的快速迭代，持续适配这些频繁变化需要巨大的开发成本。

挑战 3：缺乏统一的管理 API

随着 KV 缓存成为 LLM 推理后端的核心组件，除 LLM 推理引擎外，各类组件及机器学习运维团队都需要基于 KV Cache状态做出决策。然而，若缺乏统一的管理接口来定位、淘汰、固定或压缩缓存，这些上层模块无法做出合理的缓存放置或淘汰决策，导致缓存利用率低下、存储冗余和淘汰策略不可预测。例如，推理请求路由器需了解 KV Cache的位置，才能将请求路由到已在本地（如 CPU 内存）持有匹配前缀token KV Cache的实例。

此外，应用场景也对 KV 缓存管理接口提出了需求。例如，2025 年初，一家与 LMCACHE 合作部署生产环境的金融公司要求提供接口，支持用户将频繁访问的金融文档显式固定在 KV Cache系统中，以实现热门上下文的高效访问；另一家智能体公司则需要一系列 API，用于识别特定内容的 KV Cache、压缩 KV Cache并跨节点传输压缩后的 KV Cache。

2.4 相关工作与现有解决方案

目前已有多种 KV 缓存处理机制，但均无法完全解决上述挑战：

推理框架

自 2025 年 1 月 vLLM 生产栈发布以来，出现了多款开源分布式推理栈，包括 NVIDIA 的 Dynamo、AIBrix、llm-d、SGLang OME 和 KServe。这些框架专注于简化推理引擎在 Kubernetes 上的部署，技术上支持基于负载或前缀缓存感知的请求路由，且均支持 KV 缓存功能（vLLM 生产栈、Dynamo、llm-d 和 KServe 已集成 LMCACHE）。

推理引擎原生 KV 缓存

vLLM 和 SGLang 等开源推理引擎提供原生的 GPU-to-CPU KV 缓存传输功能，但该功能专为单节点推理设计，缺乏跨节点传输优化和 KV Cache的分层存储支持。后续将在第 7 章评估其性能并与 LMCACHE 对比。

KV Cache存储层

Mooncake、Redis、InfiniStore 和 3FS 提供分布式对象存储或缓存功能，但缺乏在推理引擎与存储设备之间高效移动小张量的 “粘合层”，或与特定推理框架紧耦合。

专有实现

Fireworks AI、Together AI 等专有推理 API 在内部实现了前缀缓存，但这些功能与闭源服务栈绑定，无法供部署自有基础设施的运维人员使用。

研究原型代码

多项研究方案开源了 KV Cache优化原型，包括前缀缓存、PD 分离和 KV 缓存压缩相关工作。但这些原型通常基于 HuggingFace Transformers 等研究导向的推理框架构建，未完全达到企业级应用要求，或无法适配 SGLang 和 vLLM 等快速迭代的推理引擎生态。

3. LMCACHE 概述

LMCACHE 通过统一的高性能 KV Cache缓存层，解决了上述挑战，能够为分页内存推理引擎提供 KV Cache的高效存储、移动和显式管理功能，使前缀缓存和 PD 分离在企业级规模下切实可行。

作为 KV Cache缓存层，LMCACHE 部署在 LLM 推理引擎与异构存储 / 网络设备之间（图 2）。其目标是提供标准化、高性能的 KV 缓存移动和管理基础架构，同时与 vLLM 和 SGLang 等快速迭代的推理框架保持兼容。

图2 中展示了 LMCACHE 在推理引擎与存储后端之间的中间层角色

3.1 架构

从高层设计来看，LMCACHE 连接推理引擎，实现 KV 缓存在 GPU 内存与存储后端之间的移动。图 3 展示了端到端系统架构，以下通过 KV 缓存的存储和检索两个示例工作流进行说明：

存储流程

当新请求到达时，首先经过 KV 连接器，准备token化输入提示和相关页面的 GPU 内存地址等元数据；随后请求被传递至token处理器，确定后端中尚未存储且需要存储的新token数量；最后，存储管理器通过传输通道（负责数据传输逻辑）将这些新token的 KV Cache保存到后端。

检索流程

当请求需要从后端加载 KV Cache时，同样先通过 KV 连接器准备元数据；token处理器识别后端中已存在的前缀匹配token数量；事件管理器检查该请求 ID 是否已被处理过 —— 若是，则直接返回已跟踪的缓存内存地址至 GPU 连接器，由 GPU 连接器将 KV Cache重新加载到 GPU 内存，同时事件管理器启动第 4.2 节所述的异步分层加载事件；若为新请求 ID，则转发至存储管理器请求已存储 KV Cache的 CPU 内存地址。

查找流程

当请求需要检查特定token的 KV Cache是否存在于后端时，路由器等高层组件会请求缓存控制器。缓存控制器维护一个token池，记录当前存储在 KV Cache后端的所有token。每当 LMCACHE 实例存储或淘汰 KV 缓存时，实例内的 LMCACHE 工作线程会更新token池状态，确保token池始终反映后端的最新token存储情况。

3.2 核心组件

LMCACHE 由高性能数据平面和灵活的控制平面组成：

LMCACHE 工作器（数据平面）

每个推理引擎都配备一个 LMCACHE 工作器，负责 KV Cache在 GPU 内存与其他存储层级或其他工作线程之间的移动，支持 KV 卸载（至 CPU 或磁盘）和 PD 分离（GPU-GPU 传输）。为最大化吞吐量，工作器采用内核优化的 GPU 缓冲区、异步分块 I/O 和分层流水线等技术，即使处理 vLLM 和 SGLang 中常见的小分页内存对象（16-64KB），也能维持接近 GPU 本地的带宽性能。

LMCACHE 控制器（控制平面）

控制器向系统运维人员和高层调度器暴露可编程 API，提供缓存生命周期管理原语，如固定 KV 片段、压缩和解压缩缓存张量、在设备间迁移缓存以及淘汰低优先级缓存条目。控制器还维护虚拟化命名空间，支持异构设备间缓存的统一寻址。

LMCACHE 工作线程和控制器共同构成模块化系统，可无缝集成到企业级服务流水线中 —— 工作线程确保数据的快速移动，控制器提供高效资源利用所需的高层控制语义。

图中展示了 LMCACHE 的核心组件及数据流转路径

4. 性能优化

LMCACHE 的核心优势之一是提升 KV 缓存在设备间的移动效率。在企业级 LLM 推理场景中，LMCACHE 主要解决三大关键挑战：

1. 现代 LLM 推理引擎以页面为粒度管理 KV 缓存，主流模型（如 Llama、Qwen、GPT-OSS 等）的页面大小通常为 20KB-63KB。这类小尺寸单元传输效率低下，无法充分利用带宽；

2. KV 缓存传输通常需与 LLM 推理计算并发执行，带来两方面开销：一是若传输与计算在同一 CUDA 流中执行，数据移动会阻塞推理；二是启动内存拷贝 CUDA 函数会消耗 CPU 资源，当存在多个层和页面时，这种开销会非常显著；

3. LLM 推理过程中，大量请求会生成海量 KV 缓存，在任何存储设备上重复存储都会浪费空间并增加拷贝开销，拖慢推理速度。

这些挑战均来自开源和企业部署中的实践经验，本节将详细说明这些挑战，并阐述 LMCACHE 的设计决策。

4.1 批量操作

为解决小尺寸 KV 缓存单元导致的 I/O 低效问题，LMCACHE 引入了一系列优化手段：

可配置块大小

LMCACHE 不按页面粒度传输 KV 缓存，而是将多个层的多个页面组合为更大的块（默认每块 256 个token）。这一过程通过中间 GPU 缓冲区实现：存储时，首先将多个页面（默认 16 个）从 GPU 内存拷贝到缓冲区，再以块为粒度批量卸载到低层存储（如 CPU 内存）；加载时，先将块从存储层检索到 GPU 缓冲区，再分割为页面并放入服务引擎的内部 GPU 内存。LMCACHE 通过定制 CUDA 内核加速内存拷贝过程。

批量存储 / 加载操作

LMCACHE 支持跨多个存储设备（包括本地 CPU 内存、本地磁盘和远程磁盘）存储和加载 KV Cache。实际场景中，KV Cache常需并行传输至不同设备（例如，将热门上下文的 KV 缓存存储在 CPU 内存中，同时将冷上下文卸载到本地磁盘）。若采用顺序存储这两类 KV Cache的简单方案，会导致带宽利用率不足（如传输至 CPU 内存时磁盘带宽处于空闲状态）。为此，LMCACHE 对不同层级的存储和加载请求进行批量处理，聚合操作以充分利用 GPU 与多个存储层级之间的带宽。

延迟解码 KV 缓存存储

LMCACHE 支持在decode过程中保存新生成的 KV cache。简单设计中，每个新生成的页面会立即卸载到低层存储，导致频繁的小写入操作。而 LMCACHE 会聚合多个页面，以块为单位批量存储，提升 I/O 效率。

4.2 计算与I/O 重叠

LMCACHE 的数据移动通常与 LLM 推理计算并行执行（例如，decode过程中，KV Cache一边被计算一边被存储到存储设备）。简单的数据移动操作会阻塞 LLM 推理计算，反之亦然。LMCACHE 通过多项优化实现 LLM 推理计算与 I/O 的重叠执行：

分层流水线

LMCACHE 通过分层流水线实现 KV 缓存传输与推理计算的重叠。具体而言，为每个层的推理计算和数据移动分配独立的 CUDA 流：例如，在执行第一层推理前，先将其 KV 缓存加载到 GPU 缓冲区并转换为页面；在第一层执行推理时，异步获取第二层的 KV 缓存并转换为页面（注意：第二层 KV 缓存加载需在第一层 KV 缓存放入正确的分页内存后执行）。这种设计仅需单个层 KV 缓存大小的固定 GPU 缓冲区，即可实现数据传输与计算的重叠。

异步计算与预取

许多场景中，推理调度器接收请求到请求的 KV Cache实际用于推理之间存在时间间隔。例如，100 个请求同时到达，但推理引擎仅能并行处理 50 个，剩余 50 个需在队列中等待。LMCACHE 利用这段空闲时间，将排队请求的 KV 缓存从慢速存储层级预取到快速存储层级（如从远程磁盘到本地 CPU 内存）。这样，当推理计算实际开始时，所需 KV 缓存可直接从快速存储层级加载，显著降低加载延迟。用户可根据自身延迟服务等级协议（SLO）和资源约束，配置预取的目标存储层级。

进程分离

若将 LMCACHE 的数据移动与推理引擎部署在同一进程中，会因 CPU 资源竞争导致 5%-10% 的延迟开销。为消除这一开销，LMCACHE 将数据移动解耦为独立进程，与推理计算进程隔离。此外，进程分离还支持多个推理引擎实例之间的内存共享：当数据移动与计算共进程时，每个推理实例维护自己的 CPU 内存池，实例间需通过进程间通信才能访问彼此的 KV 缓存；而独立的数据移动进程管理统一的 CPU 内存池，多个推理实例可共享该内存池存储和加载 KV 缓存，提高效率并减少冗余。

4.3最小数据拷贝

简单的 KV Cache移动实现会在每个传输步骤中创建额外的数据拷贝（尤其是处理异构存储类型时），导致冗余内存占用和不必要的开销。LMCACHE 通过仅维护必要的拷贝来避免这一问题：

零拷贝操作

当将 KV 缓存传输到远程存储或其他 GPU 实例（如分离式预填充场景）时，LMCACHE 通过引用计数器最大限度减少数据重复。具体而言，当 KV 缓存需写入多个目的地（如本地 CPU 内存、本地磁盘、远程磁盘）时，LMCACHE 为共享数据递增引用计数器，而非创建新拷贝；每个写入操作完成后计数器递减，计数器为零时释放数据。这种设计确保并发写入操作共享数据而无需冗余复制，降低内存压力并提高效率（类似操作系统中的 PCB 计数器机制）。

动态卸载

vLLM 等现代推理引擎在 GPU 内存中维护空闲页面池（即当前未被活跃请求使用的页面）。LMCACHE 并非将所有空闲页面复制到 CPU 内存，而是仅复制一部分，这一机制通过三个指针实现：

• 起始指针（Start pointer）：GPU 内存中空闲页面区域的起始地址；

• 当前指针（Current pointer）：已卸载到 CPU 内存的空闲页面索引；

• 结束指针（End pointer）：计划卸载的空闲页面区域的结束地址。

如图 4 所示，动态卸载包含四种状态：

1. 初始化状态（State #1）：起始指针与当前指针重合，起始 / 当前指针与结束指针之间的区域为待复制页面；
2. 进行中状态（State #2）：当前指针向结束指针移动，起始指针与当前指针之间的页面已卸载到 CPU 内存；
3. 请求到达状态（State #3）：新请求占用部分空闲页面时，结束指针向前移动已分配页面数量，确保为未来活跃请求预留足够 GPU 内存；
4. 稳定状态（State #4）：当前指针与结束指针重合，表明所有计划页面已完成复制。

需注意，若请求尝试分配当前指针之外的页面，分配操作必须阻塞，直到当前指针移动到覆盖所需页面的位置。因此，该设计的核心权衡在于 GPU 与 CPU 内存之间的复制页面数量（即结束指针与起始指针定义的区域）：复制窗口越小，复制比例越低，但分配阻塞的可能性越高（例如，仅复制 1 个页面而推理请求需要 3 个页面时，请求必须等待当前指针和结束指针再推进 2 个页面）；反之，复制窗口越大，请求可立即执行但复制比例越高。

图中展示了动态卸载的四种核心状态及指针移动逻辑

5. 连接 KV Cache缓存层与推理引擎的标准化接口

vLLM 和 SGLang 等现代 LLM 推理引擎需快速迭代以支持新发布的多样化架构模型。例如，2025 年平均每周有 15-20 个新模型发布，支持这些新架构往往需要对推理引擎进行大量修改（如添加滑动窗口注意力或多头潜在注意力支持）。这些代码变更常会改变 KV 缓存的内部管理方式，导致 LMCACHE 难以通过临时适配满足需求。

为解决这一挑战，LMCACHE 引入标准化 KV 缓存连接器接口，使 KV 缓存管理与推理引擎后端解耦，确保无论底层推理引擎如何演进，LMCACHE 都能保持兼容。

具体而言，在 vLLM 中，LMCACHE 通过两个关键接口集成：

1. 调度器：预填充token数量直接影响调度决策，且会被 LMCACHE 修改（例如，若 LMCACHE 命中缓存，需新预填充的token数量会变化）；

2. 模型运行器：推理计算在此执行，KV 缓存的加载和存储必须在执行前后进行。

表 2 列出了所有接口，后续将讨论核心 API 的设计，并追踪请求与这些接口的端到端交互流程。

函数名称	描述
get_num_new_matched_tokens(query) → matched_tokens	返回 LMCACHE 后端中命中缓存的token数量
update_state_after_alloc(query, blocks, num_external_blocks)	更新请求是否需要从 LMCACHE 后端传输 KV 缓存
build_connector_meta(scheduler_output) → kv_connector_metadata	构建 KV 缓存在 LMCACHE 后端与 GPU 内存之间传输的元数据（包括 KV 缓存页面的 GPU 内存地址）
start_load_kv(kv_pointers)	LLM 推理开始前，启动从低层存储向 GPU 内存加载 KV 缓存
wait_load_kv(kv_pointers, layer_id)	同步 KV 缓存加载过程，确保计算时数据已就绪
start_store_kv(kv_pointer)	计算完成后，启动 KV 缓存向低层存储的卸载
wait_store_kv(kv_pointer, layer_id)	同步 KV 缓存存储过程，确保当前层的 KV 缓存已完成卸载

表 2 中的接口构成了 LMCACHE 在低层存储间加载和存储 KV 缓存的基础。其中，前三个接口在 vLLM 调度器中实现，基于 LMCACHE KV 缓存后端的匹配token数量准备必要的元数据；其余四个接口位于模型运行器中，负责执行推理引擎与 LMCACHE KV 缓存后端之间的实际 KV 缓存传输。

请求的完整交互流程如下：

1. 请求到达时，调度器首先调用get_num_new_matched_tokens，请求 LMCACHE 后端的缓存命中token数量；

2. update_state_after_alloc函数根据 LMCACHE 返回的匹配token信息，决定 vLLM 中的每个页面是否需要从外部存储后端加载；

3. 若缓存命中token数大于 0，调用build_connector_meta函数准备从存储设备加载或存储 KV 缓存所需的元数据；

4. 请求到达模型运行器后，在分层流水线场景下：

• 调用start_load_kv启动第一层 KV 缓存向 GPU 内存的加载；

• 每层 LLM 推理计算开始前，调用wait_load_kv同步该层的 KV 缓存加载，并启动下一层的 KV 缓存加载

• 每层推理计算完成后，调用wait_store_kv等待前一层 KV 缓存存储完成，再调用start_store_kv启动当前层新生成 KV 缓存的存储；

在非分层流水线场景下：

• 第一层 LLM 推理开始前，调用start_load_kv以阻塞方式将整个 KV 缓存加载到 GPU 内存，推理计算在 KV 缓存放入正确的 GPU 分页内存后执行；

• 当前调度迭代的 LLM 推理完成后，调用start_store_kv将生成的 KV 缓存同步存储到低层存储。

6. 控制器接口

许多场景中，高层应用需要了解 KV 缓存的位置并对其进行操作（例如，请求路由可基于前缀缓存命中token数量最多的实例进行决策）。为支持这类需求，LMCACHE 暴露了请求和操作 KV 缓存的 API（表 3），如定位缓存条目或跨实例迁移缓存。

LMCACHE 的 KV 缓存控制器由两部分组成：集中式管理器和实例级工作器。控制器请求由集中式管理器处理，管理器将相应操作分发到每个 LMCACHE 实例中的工作线程。以下通过几个示例应用说明控制器接口的使用方式：

基于 KV Cache缓存的路由

高层请求路由器需将请求路由到前缀缓存命中最多的实例：

1. 路由器调用lookup(tokens)，集中式管理器将查找请求分发到各个 LMCACHE 实例，识别包含匹配前缀token的实例；

2. 调用query_ip(instance_ids)将实例 ID 映射为 IP 地址；

3. 将请求转发到命中token数量最多的 IP 地址。

KV 缓存迁移

当持有 KV 缓存的实例故障或需要负载均衡时，需跨实例迁移 KV 缓存：通过move(source, destination, tokens)接口将指定token对应的 KV 缓存从源实例迁移到目标实例。

KV 缓存清理

切换模型或回收内存时，应用可能需要清理缓存：通过clear(tokens, instance, location)函数删除指定实例中特定存储位置（如 GPU 内存、CPU 内存）的目标token KV 缓存。

GPU 内存中固定 KV 缓存

某些上下文（如聊天机器人应用中的系统提示）需常驻 GPU 内存以实现快速访问：通过pin(instance, location, tokens)函数将指定实例中目标token的 KV 缓存固定在选定的存储层级（GPU 内存）。

此外，用户还可调用更高级的接口操作 KV 缓存，例如compress(tokens, instance, location, compression_method)函数，使用指定压缩算法压缩特定实例中特定存储位置的 KV 缓存，以减少存储占用。用户可根据自身应用需求，灵活调用这些接口显式管理 KV 缓存。

接口	描述
lookup(tokens) → {instance_id: hit_tokens}	返回包含与指定token列表前缀匹配的 KV 缓存的实例名称及命中token数
query_ip(instance_ids) → IP	返回对应实例 ID 的 IP 地址
move(source, destination, tokens)	将指定token的 KV 缓存从源实例迁移到目标实例
clear(tokens, instance_id, storage_device)	从指定实例的特定存储设备中删除目标token的 KV 缓存
pin(tokens, instance, storage_device)	将指定token的 KV 缓存固定在指定实例的特定存储设备中
compress(tokens, instance, storage_device, compression_method)	使用指定压缩算法压缩指定实例中特定存储设备的目标token KV 缓存，并存储在该设备中

表 3：LMCACHE 控制器中的核心接口

7 评估

7.1 实验设置

本节在三种不同场景下评估 LMCACHE（表 4），这些场景均为 LMCACHE 用户的典型部署配置：

模型

对比 LMCACHE 与基准方案在业界广泛采用的开源模型上的性能：meta-llama/Llama-3.1-8B-Instruct、meta-llama/Llama-3.1-70B-Instruct、Qwen/Qwen2.5-Coder-32B-Instruct、Qwen/Qwen3-Coder-480B-A35B-Instruct-FP8、Qwen/Qwen2.5-72B-Instruct。

数据集

评估数据集包括：模拟多轮问答数据集、LongBench 中的长上下文问答数据集，以及 vLLM 官方基准测试脚本中的随机数据集。

硬件

• 单节点评估：使用 GMI Cloud 提供的 8×H100 服务器，根据每个模型的部署需求分配最少数量的 H100 GPU；

• 多节点评估：采用与单节点相同的 GPU 数量，配置基于 CPU 内存存储 KV 缓存的远程存储后端；

• PD 分离评估：预填充节点和解码节点均采用与单节点相同的 GPU 数量，通过 NVLink 连接。

评估指标

• 首token生成时间（TTFT）：预填充延迟；

• token间延迟（ITL）：连续两个输出token生成的平均延迟；

• 组件级分析：单独报告 CPU 卸载或 PD 分离等组件的延迟。

基准方案

• vLLM（带前缀缓存）：仅在 GPU 内存中保留有限 KV 缓存；

• 商业方案 1、2、3：提供专用端点服务，为用户预留 GPU 运行自定义模型。

场景	单节点 / 多节点	网络介质	实际应用示例
CPU 卸载	单节点	–	单节点 CPU 卸载场景
集中式存储	单节点	以太网	存储服务器集中式部署
PD 分离	单节点	NVLink	PD分离部署

表 4：评估场景配置

7.2 单节点 CPU 卸载

在 CPU 卸载场景下（表 4），使用模拟聊天机器人文档分析场景的多轮问答工作负载进行评估。默认每个 LLM 请求包含 10K token（由 12 页 PDF 对应的文档上下文和一个独立短问题组成）。Llama-3.1-8B-Instruct 模型接收 20K token输入（小型模型通常能处理更多更长的请求），LLM 输出最多 100 个token的短答案。聊天会话初始有 40 个用户，后续用户按指定到达率（QPS）加入。限制 LMCACHE 可卸载 KV 缓存的最大 CPU 内存为 500GB。

如图 5 所示，LMCACHE 在 TTFT 和 ITL 指标上均持续优于所有对比方案。例如，在低 QPS（如 QPS=1）下，LMCACHE 在五个评估模型上的请求处理速率（吞吐量）比性能最强的基准方案高 2.3-14 倍，且保持相同 TTFT；在 ITL 方面，LMCACHE 同样优于基准方案 —— 基准方案需等待首token生成，导致后续token生成排队，延迟较高。此外，商业方案 1 和 2 不支持部署 Qwen3-Coder-480B 模型。

图5：对比了 LMCACHE 与基准方案在不同模型上的 TTFT、ITL 和 QPS 指标

LMCACHE 性能优势原因

• 与仅在 GPU 内存中缓存有限 KV 数据的 vLLM 原生前缀缓存相比，LMCACHE 利用 CPU 卸载扩展了 KV 缓存存储容量，实现更高的缓存命中率，且通过高效的 CPU-GPU 加载机制快速获取缓存数据，加速推理；

• 商业方案 1 可能缺乏 KV 缓存卸载到二级存储的机制，而商业方案 2 虽支持该功能，但性能仍不及 LMCACHE（由于其内部实现未公开，仅基于端到端结果推测）。

7.3 集中式存储服务器

在集中式存储场景下（表 4），评估 LMCACHE 通过 15Gbps 带宽连接 GPU 实例与集中式远程服务器的性能。使用 LongBench 中的 TriviaQA 数据集（长上下文评估的主流基准），遵循 vLLM 官方基准测试脚本，按泊松分布生成指定 QPS 的推理请求。

如图 7 所示，LMCACHE 在不同 QPS 水平下均持续优于所有基准方案，推理吞吐量提升 1.3-3 倍。性能提升的核心原因是远程后端能存储比 CPU 内存更多的 KV 缓存，实现更高的缓存命中率。

需注意的是，从远程后端加载 KV 缓存的延迟高于从 CPU 内存加载（远程后端带宽更低）。因此，当输入上下文较短或模型较小时（预填充速度快），加载延迟可能超过预填充延迟（后续第 7.7 节将详细说明）。

图7：对比了 LMCACHE 与基准方案在远程存储场景下的 TTFT、ITL 和 QPS 指标

7.4 PD 分离

在 PD 分离场景下，使用随机输入输出工作负载的官方基准测试脚本，对比 LMCACHE 与 vLLM 原生 PD 分离的性能（输入 8K token，输出 200 token）。如图 8 所示，LMCACHE 的 95 分位 TTFT 显著优于 vLLM 原生 PD 分离；在平均 TTFT 方面，LMCACHE 同样表现出色 —— 在四个模型上平均 TTFT 降低 1.53-1.84 倍，平均 ITL 降低 1.12-1.66 倍。

图8：展示了不同模型在 LMCACHE 与 vLLM 原生 PD 分离方案下的延迟分布

LMCACHE 性能优势原因

LMCACHE 针对 PD 分离场景设计了更高效的架构：预填充实例将分块预填充生成的每个 KV 缓存块拷贝到 GPU 缓冲区，再传输到解码实例的对应缓冲区，接收后将 KV 缓存拷贝到解码实例的分页内存中。

相比之下，vLLM 原生 PD 分离直接使用 NIXL 的内存拷贝函数，将预填充器生成的分页 KV 缓存发送到解码器。该函数接收预填充器侧 KV 缓存页面的内存地址，并拷贝到解码器侧的目标地址。但当 KV 缓存的分页内存分散在预填充器的 GPU 内存中时，传输需按页面逐一执行，导致带宽利用率不足（第 4 节已讨论）。

图 11 展示了 LLM 推理的延迟分解（包括预填充和解码计算，以及预填充器与解码器之间的 KV 缓存传输）。LMCACHE 与 vLLM 原生 PD 分离的预填充和解码计算时间相同，但 LMCACHE 采用更高效的 KV 缓存传输机制，显著加快传输速度，降低 PD 分离场景下的端到端延迟。

图11：对比了 LMCACHE 与 vLLM 原生 PD 分离在预填充、解码和传输阶段的延迟

7.5 真实轨迹驱动评估

使用某企业提供的真实生产轨迹评估 LMCACHE（轨迹包含请求到达时间戳和实际多轮聊天输入）。同一用户会话的后续轮次通常复用前期对话历史，存在前缀复用场景，轨迹中的输入平均长度约为 4K token。

由于无法获取该企业的专有模型，使用 Sao10K/L3-8B-Lunaris-v1 模型重放轨迹。为简化实验，对持续数天的原始轨迹进行拉伸和随机采样，使工作负载在 1 小时内完成。

如图 6 所示，在不同 QPS 下，LMCACHE 在真实轨迹上的性能均优于原生 vLLM，同时降低 TTFT 和 ITL，验证了其在实际场景中的有效性。例如，QPS 为 2-5 时，LMCACHE 性能比原生 vLLM 提升 25%；QPS 为 6 时，性能提升达 49%。

图6：对比了 LMCACHE 与原生 vLLM 在真实轨迹上的 TTFT、ITL 和 QPS 指标

7.6 组件级评估

为进一步理解 LMCACHE 的性能增益，对端到端系统的各组件延迟进行分解分析：

CPU 卸载

表 5 对比了 LMCACHE 与 vLLM 原生 CPU 卸载从 CPU 加载 KV 缓存的实际带宽。LMCACHE 的传输带宽显著高于 vLLM 原生方案，核心原因是传输粒度差异：vLLM 原生 CPU 卸载按页面逐一移动数据，而 LMCACHE 按块传输。每次传输操作都会触发 CUDA 内存拷贝，需提前准备元数据并在后续发送完成信号，这些操作会为每个内存拷贝内核增加开销。LMCACHE 通过每次拷贝传输更大的数据块，减少了整体开销，实现更高的有效带宽。

方法	实际带宽
LMCACHE	400 Gbps
vLLM 原生 CPU 卸载	88 Gbps

表 5：LMCACHE 与 vLLM 原生 CPU 卸载的加载带宽对比

异步计算

图 10 展示了 LMCACHE 异步计算在降低端到端延迟方面的优势（图中为长运行过程中间段的时序示例）。无请求异步时，预填充 / 解码计算与加载操作顺序执行；启用请求异步后，预填充 / 解码计算可与 KV 缓存加载重叠执行，端到端延迟降低 1.46 倍。

图10：展示了 LMCACHE 异步 I/O 如何重叠 KV 缓存加载与推理计算

7.7 敏感性分析

通过敏感性评估，分析不同上下文长度和远程后端类型对 LMCACHE 延迟的影响：

上下文长度的影响

图 12 展示了 B200 机器上的预填充延迟，以及不同网络带宽下的加载延迟。当网络带宽较低（32 Gbps）时，仅当输入上下文长度超过 256K token，LMCACHE 的 KV 缓存加载才优于原生预填充；当带宽较高（64 或 128 Gbps）时，LMCACHE 的加载延迟在所有上下文长度下均低于原生预填充。这些结果表明，LMCACHE 的 KV 缓存加载应具备自适应性：低带宽场景下，仅当上下文长度超过加载比预填充更快的临界点时才启用加载。

图12：展示了不同网络带宽下，上下文长度与预填充 / 加载延迟的关系

7.8 SGLang 集成结果

尽管主要评估基于 vLLM，本节仍展示 LMCACHE 与 SGLang 的集成性能。图 9 报告了在两个 H100 GPU 上部署 Qwen3-32B 模型（TP=2）并启用 LMCACHE CPU 卸载的结果：与未启用 CPU 卸载的 SGLang 相比，LMCACHE 实现了更高的吞吐量和更低的平均 TTFT 及端到端延迟；与 SGLang 原生 CPU 卸载相比，LMCACHE 性能相当。这些结果验证了 LMCACHE 在另一主流推理引擎上的有效性。需注意，SGLang 原生 CPU 卸载虽在性能上与 LMCACHE 相当，但缺乏支持跨分层存储设备（如本地磁盘和远程 CPU / 磁盘资源）高效卸载数据的分布式存储后端。

图9：对比了不同请求率下，LMCACHE 与 SGLang 不同配置的吞吐量、平均 TTFT 和平均延迟

8. 实际部署经验与教训

8.1 KV 缓存存储与卸载的规模化

LMCACHE 在生产系统中的应用呈现明显趋势：需要存储的 KV 缓存数量不断增加，远超 GPU 内存的承载能力。早期部署将所有 KV 缓存存储在 GPU 内存中，但长上下文和多用户工作负载会快速耗尽 GPU 内存。因此，许多企业现在需要将 KV 数据卸载到 CPU 内存、CPU 内存池，甚至在必要时卸载到磁盘。这一做法避免了有用缓存条目的淘汰 —— 若不进行卸载，后续请求需对相同的长上下文执行完整预填充，大幅延长 TTFT。

值得注意的是，包括某企业在内的部分团队已尝试使用远程存储设备。尽管远程数据获取的速度比 GPU 内存访问慢一个数量级，但实际测试表明，借助 LMCACHE 的 KV 缓存加载优化（第 4 节），从网络检索已计算的 KV 缓存仍比在负载较高的 GPU 上重新计算更快，且能节省成本。虽然从远程加载 KV 缓存的开销较大，但可与推理计算（如对未命中缓存token的预填充或解码计算）进行流水线处理。这些经验表明，即使是慢速且廉价的存储设备，也可有效用于 KV 缓存的存储和加载。

生产环境中另一种常用技术是结合 CPU 卸载和 PD 分离。某企业在预填充器侧，不仅将 KV 缓存发送到解码器侧，还将其卸载到预填充器实例的 CPU 内存中，同时获得 CPU 卸载和 PD 分离的双重优势。

8.2 新兴应用场景与意外成果

虽然聊天机器人是 KV 缓存复用的早期典型场景，但新的应用场景正快速涌现。近期，多家企业的大规模推荐系统已采用 LLM 作为推荐模型，成为 KV 缓存复用的重要应用场景。这些系统中，LLM 作为嵌入模型预填充上下文（不生成token），且同一用户的不同请求频繁复用这些上下文，同时上下文通常较长。缓存这些 KV 缓存可直接省去开销巨大的预填充阶段，是 LMCACHE 的理想应用场景。

尽管多轮聊天长期以来是 KV 缓存复用的标准场景，但实际部署揭示了多项重要见解：许多系统最初采用滑动上下文窗口，以在有限 GPU 内存中容纳更多token，但这种方法会丢弃有用的历史信息，降低生成质量，同时由于截断后的上下文不再是完整前缀，会降低前缀缓存命中率。多家企业的部署经验表明，保留完整对话历史并将 KV 缓存卸载到更大容量的存储层级，是更有效的实践。通过避免截断，系统可实现更高的共享前缀缓存命中率，减少每个请求的 GPU 内存占用。此外，企业在生产环境中观察到，前缀缓存命中率远高于预期。

某企业的应用经验表明，行业用户愿意接受有损优化（如 KV 缓存压缩）以换取更好的系统性能。尤其是在开放式聊天机器人应用中（无唯一 “正确” 答案），使用压缩 KV 缓存（如量化 KV 缓存）可能不会影响用户体验，但能显著减少内存占用和 I/O 时间。即使在金融行业，团队发现若能提升整体系统吞吐量，使用压缩 KV 缓存带来的微小差异是可接受的。

8.3 集成与部署挑战

在生产级 LLM 推理系统中部署缓存层面临独特的实际挑战，以下是 LMCACHE 应用过程中的关键经验：

容器化部署偏好

许多企业在将缓存层部署到生产环境时，倾向于使用 Docker 镜像等容器化环境，因为他们通常不愿修改 LMCACHE 的源代码。

容错性与透明性

由于缓存层部署在推理引擎之下，对终端用户应保持透明，因此鲁棒性至关重要。多家企业强调，若缓存系统故障或性能不佳，不应导致模型服务中断。例如，LMCACHE 集成了容错 KV 缓存检索机制：若检索过程中发生错误，LMCACHE 会报告成功读取的 KV 缓存部分，确保推理引擎不会因 KV 缓存读取失败而崩溃，同时保证生成结果的正确性。

推理引擎与缓存引擎的解耦需求

企业对推理引擎与缓存引擎的清晰分离需求日益增长。多家存储企业明确要求将 KV 缓存管理与核心推理代码解耦，因为他们希望尽量减少对核心推理逻辑的修改。尽管 LMCACHE 目前尚未完全解决这一问题，但趋势已很明确：LLM 推理引擎正与各类外部 KV 缓存管理服务配对使用。

与新兴推理框架的兼容性

LMCACHE 与新兴推理框架的兼容性超出预期。LMCACHE 最初基于 vLLM 设计开发，但与 SGLang 等其他框架的集成也非常简便，只要这些框架采用分页注意力机制。展望未来，LMCACHE 有望同样轻松地与其他基于分页注意力的推理框架集成。

8.4 应用情况、经验教训与未来展望

LMCACHE 的发展始于 2024 年夏季的学术原型，当时 KV 缓存仍是少数研究论文中讨论的小众概念。但到 2025 年春季，情况发生了巨大变化 ——KV 缓存已成为行业内提升 LLM 推理效率的关键技术。2025 年初，LMCACHE 的应用呈爆发式增长，众多企业开始合作并采用该方案。

有趣的是，尽管 LMCACHE 最初是学术原型，但行业用户数量远多于学术界用户。可能的原因之一是缺乏易用的可编程接口。例如，大量研究文献探索通过丢弃 KV 缓存中的token将其压缩为更小的张量，但在 LMCACHE 中实现token丢弃并非易事 ——LMCACHE 要求输入和输出的token数量保持一致，且注意力模块的所有中间状态对 LMCACHE 均不可见，因此需要访问或修改注意力状态的研究工作难以基于 LMCACHE 实现。

最后，我们发现高性能编程语言并非构建 LLM 推理基础设施的最佳选择。早期，部分企业认为 KV 缓存管理必须使用 Rust 或 C++ 以实现高效能，但我们选择使用 Python 开发 LMCACHE，事实证明这是更有效的决策。Python 不仅简化了与现有推理框架的集成，还降低了社区贡献的门槛，支持快速的功能开发和迭代。当然，LMCACHE 中部分高性能数据加载模块仍需基于 CUDA 实现。

---

9. 结论与展望

本文提出 LMCACHE—— 首个开源且应用最广泛的企业级 LLM 推理 KV 缓存层。通过将 KV 缓存视为一等数据结构（而非推理的内部副产品），LMCACHE 将 LLM 引擎从孤立的token处理器转变为分布式计算和存储生态系统。在多样化工作负载和模型上的评估表明，LMCACHE 的吞吐量和延迟性能持续优于开源基准方案和商业推理 API。除性能优势外，LMCACHE 已在生产环境中快速部署，企业借助其 CPU 卸载、分层存储和 PD 分离功能，在万亿token规模部署中保持低延迟并降低成本。实际部署还揭示了新的应用机会（如推荐系统中的 KV 缓存复用、开放式聊天机器人中的有损压缩），彰显了 LMCACHE 在不同应用领域的通用性。

展望未来，LMCACHE 预示着一个更广泛的转变：KV 缓存等 AI 原生数据将日益成为 LLM 推理和智能体工作流规模化的基础。通过建立 KV 缓存作为标准化存储和通信介质，LMCACHE 为未来系统奠定了基础 —— 这类系统不再将推理视为孤立会话，而是将其作为持久化、缓存感知的计算架构。我们希望本文提出的设计、优化和部署经验，能为下一代 LLM 基础设施提供参考，使 KV 缓存等 AI 原生数据不再仅仅是优化手段，而是高效、可靠、可扩展推理的核心原语。

LMCACHE 源代码地址：https://github.com/LMCACHE/LMCACHE。

---

10. 致谢

感谢 LMCACHE 社区的宝贵支持和贡献，包括Baolong Mao and Chunxiao Zheng（负责远程连接器开发）、Martin Hickey（负责 GitHub 基础设施）、Huaizheng Zhang、Siddhant Ray、Gu Zhuohan、Hanchen Li（负责文档编写与维护）、Rui Zhang （负责 LMCACHE 部署）、Qizheng Zhang、Hussain Mohammad（提供深刻反馈）。

参考文献

1. Best 44 large language models (LLMs) in 2025. https://explodingtopics.com/blog/list-of-llms, 2025.

2. Bai Y, Lv X, Zhang J, et al. Longbench: A bilingual, multitask benchmark for long context understanding, 2024. https://arxiv.org/abs/2308.14508.

3. ByteDance. InfiniStore: Kv cache store for distributed llm inference. https://github.com/bytedance/InfiniStore, 2025.

4. Caylent. Prompt caching: Saving time and money in llm applications. https://caylent.com/blog/prompt-caching-saving-time-and-money-in-llm-applications, 2024.

5. Chen S, Jiang R, Yu D, et al. Kvdirect: Distributed disaggregated llm inference, 2024. https://arxiv.org/abs/2501.14743.

6. Chen W, He S, Qu H, et al. IMPRESS: An Importance-Informed Multi-Tier prefix KV storage system for large language model inference. In: 23rd USENIX Conference on File and Storage Technologies (FAST 25), Santa Clara, CA, 2025: 187-201.

7. DeepSeek AI Contributors. deepseek-ai/3fs: A high-performance distributed file system for ai training and inference workloads. https://github.com/deepseek-ai/3FS, 2025a.

8. KServe Contributors. kserve/kserve: Standardized distributed generative and predictive ai inference platform for scalable, multi-framework deployment on kubernetes. https://github.com/kserve/kserve, 2025b.

9. Databricks Research. How long should you train your language model? https://www.databricks.com/blog/how-long-should-you-train-your-language-model, 2024.

10. Du D, Cao S, Cheng J, et al. Bitdecoding: Unlocking tensor cores for long-context llms with low-bit kv cache, 2025. https://arxiv.org/abs/2503.18773

11. Gao B, He Z, Sharma P, et al. Cost-efficient large language model serving for multi-turn conversations with cached-attention, 2024. https://arxiv.org/abs/2403.19708.

12. Ge S, Zhang Y, Liu L, et al. Model tells you what to discard: Adaptive kv cache compression for llms, 2024. https://arxiv.org/abs/2310.01801.

13. Gim I, Chen G, Lee S S, et al. Prompt cache: Modular attention reuse for low-latency inference. In: Proceedings of the Seventh Annual Conference on Machine Learning and Systems (MLSys 2024), Santa Clara, CA, 2024.

14. GMI Cloud. Gmi cloud: Gpu cloud solutions for scalable ai & inference. https://www.gmicloud.ai/, 2025.

15. Jegou S, Jeblick M, Devoto A, et al. Kvpress: Efficient kv cache compression for long-context llms, 2024. https://github.com/NVIDIA/kvpress.

16. Jin C, Zhang Z, Jiang X, et al. Ragcache: Efficient knowledge caching for retrieval-augmented generation, 2024. https://arxiv.org/abs/2404.12457.

17. Jin S, Liu X, Zhang Q, et al. Compute or load KV cache? why not both? In: Forty-second International Conference on Machine Learning, 2025a.

18. Jin S, Liu X, Zhang Q, et al. Compute or load KV cache? why not both? In: Forty-second International Conference on Machine Learning, 2025b.

19. Kwon W, et al. Demystifying nccl: An in-depth analysis of gpu-based collective communication. arXiv preprint arXiv:2507.04786, 2025.

20. Kwon W, Li Z, Zhuang S, et al. Efficient memory management for large language model serving with paged-attention. In: Proceedings of the 29th Symposium on Operating Systems Principles (SOSP ’23), New York, NY, 2023a: 611-626.

21. Kwon W, Li Z, Zhuang S, et al. Efficient memory management for large language model serving with paged-attention, 2023b. https://arxiv.org/abs/2309.06180.

22. Kwon W, Li Z, Zhuang S, et al. Efficient memory management for large language model serving with paged-attention. In: Proceedings of the ACM SIGOPS 29th Symposium on Operating Systems Principles, 2023c.

23. Lee W, Lee J, Seo J, et al. InfiniGen: Efficient generative inference of large language models with dynamic KV cache management. In: 18th USENIX Symposium on Operating Systems Design and Implementation (OSDI 24), Santa Clara, CA, 2024: 155-172.

24. Li J, Zhang Y, Hassan M Y, et al. Commvq: Commutative vector quantization for kv cache compression, 2025. https://arxiv.org/abs/2506.18879.

25. Li Y, Huang Y, Yang B, et al. Snapkv: Llm knows what you are looking for before generation, 2024. https://arxiv.org/abs/2404.14469.

26. Liu J, Chung J W, Wu Z, et al. Andes: Defining and enhancing quality-of-experience in llm-based text streaming services, 2024a. https://arxiv.org/abs/2404.16283.

27. Liu Y, Li H, Cheng Y, et al. Cachegen: Kv cache compression and streaming for fast large language model serving, 2024b. https://arxiv.org/abs/2310.07240.

28. Liu Z, Yuan J, Jin H, et al. Kivi: A tuning-free asymmetric 2bit quantization for kv cache. arXiv preprint arXiv:2402.02750, 2024c.

29. llm-d Project. llm-d: A kubernetes-native high-performance distributed llm inference framework. https://github.com/llm-d/llm-d, 2025.

30. Meta Engineering. Roce networks for distributed ai training at scale. https://engineering.fb.com/2024/08/05/data-center-engineering/roce-network-distributed-ai-training-at-scale/, 2024.

31. Nie C, Fonseca R, Liu Z. Aladdin: Joint placement and scaling for slo-aware llm serving, 2024. https://arxiv.org/abs/2405.06856.

32. NVIDIA Corporation. Nvidia dynamo: A datacenter-scale distributed inference serving framework. https://github.com/ai-dynamo/dynamo, 2025.

33. NVIDIA Developer Forums. Why is the transfer throughput low when transferring small size data (gpu host/device transfers). https://forums.developer.nvidia.com/t/why-is-the-transfer-throughput-low-when-transferring-small-size-data-from-host-to-device-or-device-to-host/153962, 2020.

34. Patel P, Choukse E, Zhang C, et al. Splitwise: Efficient generative llm inference using phase splitting, 2024. https://arxiv.org/abs/2311.18677.

35. Qin R, Li Z, He W, et al. Mooncake: Trading more storage for less computation – a KVCache-centric architecture for serving LLM chatbot. In: 23rd USENIX Conference on File and Storage Technologies (FAST 25), Santa Clara, CA, 2025a: 155-170.

36. Qin R, Li Z, He W, et al. Mooncake: A kvcache-centric disaggregated architecture for llm serving, 2025b. https://arxiv.org/abs/2407.00079.

37. Qin Z, Cao Y, Lin M, et al. Cake: Cascading and adaptive kv cache eviction with layer preferences, 2025c. https://arxiv.org/abs/2503.12491.

38. Redis. Redis enterprise software reference – redis documentation. https://redis.io/docs/latest/operate/rs/references/, 2025

39. Ren Z, Doekemeijer K, De Matteis T, et al. An i/o characterizing study of offloading llm models and kv caches to nvme ssd. In: Proceedings of the 5th Workshop on Challenges and Opportunities of Efficient and Performant Storage Systems (CHEOPS ’25), New York, NY, 2025: 23-33.

40. Shi X, Cai C, Du J, et al. Nexus: proactive intra-gpu disaggregation of prefill and decode in llm serving, 2025. https://arxiv.org/abs/2507.06608.

41. Strecker W D. Vax-11/780: A virtual address extension to the dec pdp-11 family. In: Proceedings of the National Computer Conference, Montvale, NJ, 1978: 967-980.

42. Tang J, Zhao Y, Zhu K, et al. Quest: Query-aware sparsity for efficient long-context llm inference, 2024. https://arxiv.org/abs/2406.10774.

43. The AIBrix Team, Shan J, Gupta V, et al. Aibrix: Towards scalable, cost-effective large language model inference infrastructure, 2025. https://arxiv.org/abs/2504.03648.

44. The SGLang Team. Ome: Revolutionizing llm infrastructure with model-driven architecture. https://lmsys.org/blog/2025-07-08-ome/, 2025.

45. UCCL Team. Everything you want to know about kv cache transfer engine. https://uccl-project.github.io/posts/kv-transfer-engine/, 2025.

46. vLLM project. vllm production stack: Reference system for k8s-native cluster-wide deployment with community-driven performance optimization. https://github.com/vllm-project/production-stack, 2025.

47. Xiao G, Tang J, Zuo J, et al. Duoattention: Efficient long-context llm inference with retrieval and streaming heads, 2024a. https://arxiv.org/abs/2410.10819.

48. Xiao G, Tian Y, Chen B, et al. Efficient streaming language models with attention sinks, 2024b. https://arxiv.org/abs/2309.17453.

49. Xie Z, Xu Z, Zhao M, et al. Strata: Hierarchical context caching for long context language model serving, 2025. https://arxiv.org/abs/2508.18572.

50. Yang H, Zhang R, Huang M, et al. Kvshare: An llm service system with efficient and effective multi-tenant kv cache reuse, 2025. https://arxiv.org/abs/2503.16525.

51. Ye L, Tao Z, Huang Y, et al. ChunkAttention: Efficient self-attention with prefix-aware KV cache and two-phase partition. In: Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), Bangkok, Thailand, 2024: 11608-11620.

52. Yu L, Lin J, Li J. Stateful large language model serving with pensieve. In: Proceedings of the Twentieth European Conference on Computer Systems (EuroSys ’25), New York, NY, 2025: 144-158.

53. Zhang H, Ji X, Chen Y, et al. Pqcache: Product quantization-based kvcache for long context llm inference, 2025. https://arxiv.org/abs/2407.12820.

54. Zhang Y, Li F, Tang Y, et al. Optimizing llm queries in relational workloads. arXiv preprint arXiv:2403.05821, 2024.

55. Zhao Y, Yang S, Zhu K, et al. Blendserve: Optimizing offline inference for auto-regressive large models with resource-aware batching, 2024. https://arxiv.org/abs/2411.16102.

56. Zheng L, Yin L, Xie Z, et al. Sglang: Efficient execution of structured language model programs, 2024. https://arxiv.org/abs/2312.07104.

57. Zhong Y, Liu S, Chen J, et al. Distserve: Disaggregating prefill and decoding for goodput-optimized large language model serving, 2024. https://arxiv.org/abs/2401.09670.

58. Zhou Y, Chen Z, Mao Z, et al. An extensible software transport layer for gpu networking. arXiv preprint arXiv:2504.17307, 2025.