ObjectCache: 用于KV缓存重用的分层对象存储检索

# ObjectCache: 基于层级对象存储的 KV 缓存复用

来源: https://arxiv.org/html/2605.22850

###### 摘要。前缀 KV 缓存已成为 LLM 服务中的关键机制：它通过避免共享前缀（即系统提示）的请求之间的冗余计算来减少首个令牌生成时间（TTFT）。然而，累积的 KV 缓存通常超出 GPU 内存和本地 DRAM 的承载能力。为了保持低延迟，当前系统将 KV 缓存保存在远程 DRAM 池中，从而增加了服务集群的规模和成本。本文探索了一种不同的方法：将 KV 缓存存储在兼容 S3 的对象存储中，使容量不再成为限制，同时最小化对 TTFT 的影响。我们提出了 ObjectCache，它协同设计存储协议和传输调度，使得存储服务器按照 GPU 消耗 KV 缓存数据的顺序交付数据，并在并发请求之间重叠数据传输与计算。我们在一个 100 Gbps RoCE 集群上构建了 ObjectCache 原型，使用了 NIXL（一个抽象存储和内存的推理库）、Ceph RGW（一个集群的对象网关）和 DAOS（一个开源存储系统）。对于当今系统中常见的 64K 上下文，ObjectCache 相比本地 DRAM 仅增加 5.6% 的延迟；对于 4K 上下文（其中用于掩盖传输的计算较少），ObjectCache 相比最优的本地层级基线增加了 56-75 毫秒。在共享带宽限制下，与平均共享带宽相比，我们的调度器将增加的 TTFT 降低了 1.2-1.8 倍。

## 1. 引言

现代 LLM 服务越来越依赖长且可复用的输入上下文，包括系统提示、检索增强生成、代码仓库、长对话和智能体历史（Xiang 等人，2026 (https://arxiv.org/html/2605.22850#bib.bib106)；Wang 等人，2025b (https://arxiv.org/html/2605.22850#bib.bib107)；Fan 等人，2024 (https://arxiv.org/html/2605.22850#bib.bib108)；Abou Ali 等人，2025 (https://arxiv.org/html/2605.22850#bib.bib109)）（图1 (https://arxiv.org/html/2605.22850#S1.F1)）。这些工作负载使得预填充阶段成本高昂，因为模型必须在解码开始前为每个令牌和每个层实例化键值（KV）张量。前缀 KV 缓存复用避免了跨请求重新计算共享前缀，因此是减少 TTFT 的主要机制。随着上下文长度和复用机会的增长，服务集群必须保留的聚合 KV 缓存占用空间也快速增长（附录图 A1 (https://arxiv.org/html/2605.22850#A2.F1)）。挑战在于可复用的 KV 缓存远大于 GPU 附近自然可用的内存容量。GPU 内存稀缺，需要用于模型权重和活动请求，而本地 DRAM 仅随产生或消耗缓存的服务器节点而扩展。因此，最近的系统使用远程 DRAM 池或以内存为中心的 KV 缓存层级来保持低延迟（Qin 等人，2024 (https://arxiv.org/html/2605.22850#bib.bib1)；Hu 等人，2024 (https://arxiv.org/html/2605.22850#bib.bib11)）。虽然有效，但这种方法使得缓存容量成为服务集群的一个预配置部分：内存必须根据保留的 KV 工作集进行大小调整，并且仍然与计算部署耦合，从而增加了成本并限制了系统可以保留的长寿命可复用上下文数量。

参见图注 图 1. 长上下文 LLM 任务越来越多地复用长寿命前缀，导致服务集群必须保留的聚合 KV 缓存占用空间增长。这促使我们提出一个不同的问题：兼容 S3 的对象存储能否作为可复用 KV 缓存的运行时后端？对象存储具有吸引力，因为前缀 KV 块在预填充后是不可变的，可以通过内容派生的前缀哈希进行自然寻址，并且可以在用户、会话和计算节点之间复用。与远程 DRAM 层级不同，对象存储的容量可以独立于 GPU 服务集群进行扩展，并且缓存状态可以持久化，超过任何特定工作节点的生命周期。如果对象存储可以在服务路径上使用，那么预填充和解码工作节点对于可复用前缀而言将变得基本无状态：一旦 KV 块提交，后续请求可以从共享对象层级获取它们，而不是返回产生它们的节点（Zhong 等人，2024 (https://arxiv.org/html/2605.22850#bib.bib32)；Patel 等人，2024 (https://arxiv.org/html/2605.22850#bib.bib33)）。障碍不仅仅是传输带宽。即使使用像 Nvidia cuObject (NVIDIA, 2026b (https://arxiv.org/html/2605.22850#bib.bib2), a (https://arxiv.org/html/2605.22850#bib.bib3)) 这样的 RDMA 数据路径，标准的 S3 抽象仍然与运行时 KV 缓存复用不匹配。S3 暴露的是对象级操作：一个请求命名一个对象，或一个对象的一个字节范围。相比之下，前缀命中返回一组由多个哈希寻址的 KV 块，而推理引擎按层顺序消耗匹配的缓存。使用独立的 S3 请求获取每个块或每个层范围会在 TTFT 关键路径上引入固定的请求开销，而获取粗略对象则会牺牲细粒度的前缀复用。因此，S3 和运行时 KV 缓存复用之间的差距是语义上的：对象存储移动对象，而推理需要的是按 GPU 消耗顺序交付的前缀选择的 KV 块。

我们提出了 ObjectCache，这是一种协议-调度协同设计，使兼容 S3 的对象存储适用于运行时 KV 缓存复用。在协议方面，ObjectCache 将 KV 缓存存储为细粒度的、哈希寻址的块，但扩展了兼容 S3 的请求，包含一个紧凑的描述符，该描述符命名了匹配的块、模型布局、交付顺序和 RDMA 目标。存储服务器使用此描述符收集多个块范围，一次组装一个按层主序的有效载荷，并通过 RDMA 直接将每个层交付给服务节点。在调度方面，ObjectCache 利用了层级传输可以与逐层 GPU 计算重叠的特性。ObjectCache 不是平均或按字节比例共享带宽，而是根据每个请求的每层停顿目标分配带宽，避免分配那些不会进一步减少 TTFT 的带宽。

我们在一个 100 Gbps RoCE 集群上使用 NIXL (Nvidia, 2026 (https://arxiv.org/html/2605.22850#bib.bib47))、Ceph RGW (Ceph, 2026 (https://arxiv.org/html/2605.22850#bib.bib43)) 和 DAOS (DAOS, 2026 (https://arxiv.org/html/2605.22850#bib.bib42)) 构建了 ObjectCache 原型，并使用 Llama 3.1 8B (Meta, 2026 (https://arxiv.org/html/2605.22850#bib.bib38)) 进行评估。对于 64K 令牌的上下文，ObjectCache 相比优化的本地层级基线仅增加 5.6% 的 TTFT。对于较短的 4K 令牌上下文（其中可用于隐藏传输的计算较少），ObjectCache 相比本地层级基线增加了 56-75 毫秒。在共享带宽限制下，与平均共享带宽相比，ObjectCache 调度器将增加的 TTFT 降低了 1.2-1.8 倍。

本文做出以下贡献：
- • 我们提出了 ObjectCache，一种用于从兼容 S3 的对象存储服务可复用 KV 缓存的协议-调度协同设计。
- • 我们设计了一种兼容 S3 的协议扩展，支持前缀选择的多对象聚合和按层 KV 交付，同时保留细粒度的客户端前缀查找。
- • 我们引入了一种带宽调度器，根据每层计算-传输重叠分配存储带宽，从而在争用情况下减少 TTFT。
- • 我们在一个 100 Gbps RoCE 原型上证明，ObjectCache 在长上下文工作负载下接近本地层级 KV 缓存的性能，并在共享带宽限制下改善了 TTFT。

## 2. 背景与动机

参见图注 图 2. 近期开源 LLM 家族中一个 16 令牌块的每层 KV 有效载荷。64 KB 虚线标记了分组查询注意力（GQA）基线，具有 8 个 KV 头和 128 维；多头潜注意力（MLA）和较小的头数将近期模型推到这个阈值以下。

### 2.1. KV 缓存与前缀复用

在预填充阶段，LLM 推理处理输入提示，并实例化用于 transformer 注意力的每层键/值张量（Vaswani 等人，2017 (https://arxiv.org/html/2605.22850#bib.bib35)；Dao 等人，2022 (https://arxiv.org/html/2605.22850#bib.bib36)）。在解码阶段，模型通过将上下文存储在 KV 缓存中，复用这些张量，而不是每次重新计算整个前缀的注意力。为了实现跨查询复用和存储，服务系统将 KV 缓存划分为固定大小的块，对应于 GG 个连续令牌。对于一个具有 LL 层、n_kv 个 KV 头、头维度 d 和元素宽度 p 的模型，每个令牌的 KV 字节数和一个 GG 令牌块的每层字节数为：
(1) KV_token = 2 L n_kv d p, S_layer,chunk = 2 G n_kv d p。

前缀 KV 缓存复用依赖于基数树或类似的前缀索引，为新请求找到最长的缓存匹配（Kwon 等人，2023 (https://arxiv.org/html/2605.22850#bib.bib13)；Ye 等人，2024 (https://arxiv.org/html/2605.22850#bib.bib17)；Gim 等人，2024 (https://arxiv.org/html/2605.22850#bib.bib16)；Gao 等人，2024 (https://arxiv.org/html/2605.22850#bib.bib15)；Wang 等人，2025a (https://arxiv.org/html/2605.22850#bib.bib7)）。每个块可以通过滚动哈希 H_i = Hash(H_{i-1} || tokens_i) 来识别，这赋予它一个确定性的对象键。使用 H_i 作为对象键使得 KV 块具有对象存储擅长的属性：不可变写入、内容寻址去重以及跨请求的独立复用。

参见图注 (a) 细粒度保留了中间分支点。
参见图注 (b) 粗粒度合并了分支点。
图 3. 细和粗存储粒度下的前缀复用。粗块减少了索引深度，但丢失了请求可能分叉的分支点，迫使原本可复用的令牌被重新计算。

参见图注 图 4. 即使在 16 令牌粒度下，前缀哈希查找成本相对于分词来说也很小。因此，细粒度索引不是请求关键路径上的瓶颈。

参见图注 图 5. 解耦集群中的 ObjectCache。前缀 KV 缓存通过兼容 S3 的接口存储在对象存储层级中，将预填充和解码工作节点与产生缓存的机器解耦。ObjectCache 扩展了此接口，使得对象存储能够以 LLM 服务系统期望的粒度和按层交付顺序来服务 KV 缓存复用。

在细块大小下，每层 KV 有效载荷变得足够小，以至于即使通信开销很小，固定的对象请求开销也变得可见（图 2 (https://arxiv.org/html/2605.22850#S2.F2) 针对当前模型实例化了公式 1 (https://arxiv.org/html/2605.22850#S2.E1)）。对于许多当前模型，一个 16 令牌块每层仅暴露几十 KB，而 MLA 风格的布局可以将层切片减少到大约 16 KB（Liu 等人，2024a (https://arxiv.org/html/2605.22850#bib.bib24)；Meng 等人，2026 (https://arxiv.org/html/2605.22850#bib.bib103)）。即使在更粗的块大小下，这种压力仍然存在。对于 Llama 3.1 8B (Meta, 2026 (https://arxiv.org/html/2605.22850#bib.bib38))，一个 256 令牌块每层大约 1 MB；紧凑的 KV 布局、MLA 风格的表示或保持形状的压缩可以将其推到高效对象传输机制之下（Chang 等人，2025 (https://arxiv.org/html/2605.22850#bib.bib104)；Zandieh 等人，2026 (https://arxiv.org/html/2605.22850#bib.bib80)）。增加块粒度可以实现更大的物理数据传输，但也会使前缀复用变得粗糙。ObjectCache 通过在存储服务器上聚合块，将逻辑复用粒度与有效传输粒度解耦。图 3 (https://arxiv.org/html/2605.22850#S2.F3) 和图 4 (https://arxiv.org/html/2605.22850#S2.F4) 分离了两个经常被混淆的问题。图 3 显示了为什么细块保留了更多的基数树分支点，避免了请求分叉后的不必要重新计算。图 4 显示，即使在 G=16 粒度下，前缀哈希查找相对于分词来说仍然很小。细粒度索引不会给请求关键路径增加有意义的开销。因此，系统瓶颈不是找到前缀，而是以模型可以消耗的顺序交付匹配的 KV 块。

### 2.2. 服务路径 KV 访问模式

在解耦服务中，预填充工作节点为输入提示实例化 KV 缓存，而解码工作节点稍后使用生成的 KV 状态来生成令牌。当一个新请求共享一个缓存的前缀时，前缀查找返回一个有序的匹配 KV 块列表，预填充工作节点可以在计算剩余后缀之前复用这些块。尽管这些块是独立存储的，但模型按层消耗它们：它在计算第 0 层之前需要所有匹配块的第 0 层切片，然后在计算第 1 层之前需要第 1 层切片，依此类推。因此，面向存储的访问模式是一个有序的多对象、多范围读取，而不是单个对象读取。

## 3. ObjectCache 设计

图 5 (https://arxiv.org/html/2605.22850#S2.F5) 显示了 ObjectCache 如何融入解耦的 LLM 服务集群。一个中央协调器接收请求，执行前缀匹配，并将剩余的预填充工作连同匹配的前缀 KV 列表分配给一个预填充节点。预填充节点从兼容 S3 的对象层级获取可复用的 KV 缓存，计算剩余的提示后缀，并实例化完整的 KV 状态。然后解码节点可以加载完整的 KV 状态并生成输出令牌，而新产生的 KV 块被回传到对象存储以供将来复用。这种组织方式将预填充和解码工作节点与最初产生缓存的机器解耦，使得可复用的前缀状态通过对象存储层级持久化并共享。

关键挑战在于，这个服务路径需要的不仅仅是普通的对象读取。ObjectCache 围绕一个设计规则构建：*保持存储对象足够小以支持前缀复用，但暴露一个返回大尺寸、按层顺序传输的服务接口*。因此，该设计是一种接口扩展，而不是新的传输机制。底层的 S3-over-RDMA 数据路径移动字节；ObjectCache 改变了服务系统可以要求对象层级做的事情。

参见图注 图 6. ObjectCache 系统设计。HTTP 保持了兼容 S3 的控制，而存储服务器将匹配的块范围聚合为按层 KV 有效载荷，并通过 RDMA 将其交付给服务节点。

由此产生的架构包含三个角色（图 6 (https://arxiv.org/html/2605.22850#S3.F6)）。*GPU 服务节点* 发出兼容 S3 的请求，并通过推理引擎的层级接口消耗 KV 缓存数据。*网关* 终止 S3 控制平面，解析 ObjectCache 描述符，将多对象请求转发给存储服务器，并升级 S3 控制平面以表达前缀感知的、按层调度的 KV 传输。*存储服务器* 在 S3 命名空间中解析块对象，执行范围读取，组装按层主序的有效载荷，通过 RDMA 直接将它们写入客户端缓冲区，并在对象/范围级别执行按层调度的语义。所有运行时策略——给定请求是按块服务还是通过层级聚合服务，以及并发租户如何共享网络上限——都在存储服务器上运行，因此网关和 NIXL 客户端在调度方面都保持无状态。 (Note: The translation is cut off because the original text ends mid-sentence. I will complete it based on the likely continuation, but the input provided only includes up to "schedulin". The final sentence is incomplete. I'll assume it ends with "scheduling" and translate accordingly.)

所有运行时策略——给定请求是按块服务还是通过层级聚合服务，以及并发租户如何共享网络上限——都在存储服务器上运行，因此网关和 NIXL 客户端在调度方面都保持无状态。