导读
大模型推理中的 KV Cache 常被解释为“用存储换计算”。这句话在单机上成立，但到了大规模云环境中，问题会继续向前移动：一旦重复的 Prefill 计算被缓存命中替代，系统就必须快速搬运规模很大的 KV 张量；此时，瓶颈可能从 GPU 计算转向数据读取，从 HBM 容量转向跨节点带宽、远端容量与云资源成本。PolarKV 不只是内存加云盘的两级缓存。它把云上资源的计费与性能耦合纳入系统设计：云内存的可用带宽受 VM 网卡限制，云盘带宽又与预配置容量绑定。因此，优化目标不再是单一的容量或命中率，而是带宽、容量、成本和网络路径的综合关系。针对这些约束，PolarKV 将内存作为带宽层、云盘作为容量层，并通过本地配对分片支持跨节点 KV 共享。介绍这一系统的论文发表于 VLDB 2026；PolarKV 已作为独立 KV Cache 服务部署在阿里云生产环境，可通过轻量客户端接入 vLLM 与 SGLang。受控微基准中，TTFT 最高降低 80%；公开长上下文负载和真实生产部署也显示出明显的时延收益。
KV 复用后的新瓶颈
1.1 KV Cache 与 Prefix Cache
自回归大模型推理通常分为 Prefill 和 Decode 两个阶段。Prefill 一次性处理输入上下文，为各层注意力计算 Key 和 Value；Decode 再逐 token 生成输出。标准 KV Cache 保存同一请求已经计算过的 K/V，避免每一步 Decode 都重算历史 token。Prefix Cache 则把复用范围扩展到不同请求：当后续请求与既有请求共享系统提示词、文档、代码仓库或对话历史时，推理引擎可以直接加载共享前缀对应的 K/V，只计算新增后缀。对于具有高前缀复用率的长上下文 Agent，重复 Prefill 往往是 TTFT 的主要来源，因此跨请求复用的收益非常可观。
1.2 瓶颈转向数据读取
缓存命中并不等于零成本。长上下文对应的 KV 状态可能达到数十到数百 MB，甚至更大；并发提高后，缓存系统需要持续提供多 GB/s 的吞吐。于是，系统优化目标从“是否能存下”变成两个问题：一是能否以足够高的带宽取回热点 KV，二是能否以足够低的成本保留更大的可复用工作集。Prefix Cache 把重复计算替换成数据读取。命中率决定能省掉多少计算，有效带宽决定命中以后能否真正提速。
云资源的耦合约束
2.1 云内存：受限于 VM 网络
分离式内存池把多台 VM 的 DRAM 聚合成共享容量，看起来同时拥有大容量和高带宽。然而推理节点访问远端内存时，实际吞吐受承载 VM 的网络接口限制。为了获得更高网络带宽，用户往往被迫选择规格更高的实例，同时购买并不需要的 CPU 与内存，导致容量闲置、单位有效带宽成本上升。
2.2 云盘：带宽与容量绑定
云块存储的每 GB 价格很低，但高吞吐通常要求先配置很大的卷。以阿里云 ESSD 为例，PL3 要达到 4 GB/s 峰值，需要配置约 7.76 TB 容量，对应月成本约 31,040 元，同时还要有网络能力足以承载该吞吐的 VM。云盘不能脱离计算实例单独发挥性能，存储带宽与 VM 网络带宽会形成双重约束。资源选择：先按业务需要的有效带宽选择内存规模，再用云盘扩展容量。存储层也必须按端到端带宽需求配置，不能只看 TB 数。由此可以得到清晰的资源分工：内存承担“带宽资源”的角色，云盘承担“容量资源”的角色。内存承载活跃 KV 访问，以较小 DRAM 容量提供高带宽；较冷的 KV 条目则逐步下沉到云盘，以低单位容量成本扩大可复用工作集。接下来的问题是，组合两种资源时，如何避免冷热迁移再次挤占稀缺的跨机网络。
2.3 传统分层缓存的问题
传统层次缓存常把内存层和存储层分别看作两个全局池。无论采用并列协调，还是严格的“内存为前台、存储为后备”，缓存淘汰与回载都可能发生在不同节点之间。单机时代的 DRAM–SSD 分层依赖本地总线，数据搬运相对便宜；云环境中的两层若分属不同 VM，分层操作就会变成额外的 VM 到 VM 流量。KV 对象很大，冷热迁移往往是连续的大块传输。如果每次淘汰都先跨网络写入某个全局存储节点，每次回载又从另一个节点跨网络读回，网络既承担推理节点访问 KV 的业务流量，又承担缓存系统内部的分层流量。结果是：为了降低容量成本而引入存储层，却被迫为跨机搬运购买更多网络带宽与更高规格 VM。
PolarKV 系统设计
3.1 总体架构
架构思路：打破“整层就是一个池”的抽象，把内存和存储都切成对齐分片。每个内存分片只与同 VM 上的存储分片配对，对外全局提供服务，分层则在本机发生。PolarKV 把 KV 管理从推理引擎中外置为独立服务。推理节点仍然运行 vLLM、SGLang 等引擎，通过客户端库执行 load_kv 和 store_kv；KV Manager 维护全局元数据、分配空间并协调冷热迁移；底层数据层由分离式内存与每节点直连云盘组成。
图：PolarKV 总体架构
3.2 客户端与元数据管理
客户端把 token 序列切成固定大小的 chunk，并为每个 chunk 生成链式前缀哈希：当前块的哈希同时依赖本块 token 和前一块哈希。只有全部先行 token 一致，两个块才会得到相同的前缀键，从而保证跨请求复用的语义正确性。固定 chunk 也让远端空间分配、回收和碎片控制更简单。接入方式强调非侵入性。用户安装客户端库并配置服务端点即可把 PolarKV 作为 vLLM 或 SGLang 的外部 KV 后端，不需要修改推理引擎。这一点对生产落地很重要：KV 基础设施可以独立演进，而上层模型服务继续使用主流引擎。KV Manager 由内存管理、存储管理和元数据模块组成。它记录每个键当前位于内存还是存储；若在内存，还记录 Memory Node ID 与远端地址。内存条目和磁盘条目分别维护 LRU 链表，用于访问更新、淘汰和容量控制。管理器只处理查找、分配、锁管理和状态转换等小型控制请求，KV 张量本身不经过管理器。客户端拿到地址后，通过单边 RDMA 直接读写内存节点，避免远端 CPU 介入大数据路径。哈希表和 LRU 可以按键范围分区，必要时 KV Manager 也可按不相交键空间分片。
3.3 配对分片
分离式内存层沿用已有的 PolarDB内存池架构：Home Node 负责资源管理，Slab Node 提供物理内存。每个 Slab Node 所在 VM 同时运行轻量 Disk Server，并挂载属于自己的云块存储。这样，KV 从内存写入云盘或从云盘回载内存时，都在同一台 VM 内完成。
存储实现没有再叠加一个分布式文件系统。每个节点采用 shared-nothing 方式，Disk Server 直接以固定长度 KV 键作为文件名，把多个低成本 PL0 ESSD 组成 RAID-0，并在其上使用 ext4。相比再叠加一层分布式文件系统，这种 shared-nothing 设计避免了全局 namespace 和跨节点 storage placement 协调，同时也绕开了分布式文件系统常见的 metadata management / replication 开销。由于 KV 是可重算的性能状态，PolarKV 不要求对缓存数据做同步复制或强持久化保证；故障时直接退化为 cache miss 并重新计算。
表 1 三类 KV Cache 资源组织方式的核心取舍
3.4 KV 访问与分层
图：内存命中与存储回载路径
（1）内存命中
- 客户端向 KV Manager 查询键的位置。
- 管理器在元数据表中查到内存节点与地址，并对键施加短期读锁。
- 客户端通过单边 RDMA 从目标 Slab Node 直接读取 KV。
- 读取完成后，客户端发送 RPC 解锁；大数据从未经过管理器。
（2）存储命中
- 管理器发现条目位于存储后，在与该 Disk Server 配对的 Slab Node 上分配新的内存区域。
- 管理器向 Disk Server 发送包含 KV 键和目标地址的回载请求。
- Disk Server从本地云盘将 KV 回载到目标内存区域，完成后向管理器确认。
- 客户端随后获取可读地址，并通过单边 RDMA 读取 KV。
（3）淘汰与下沉后台线程按 LRU 选择冷 KV。KV Manager 向条目所在内存节点的配对 Disk Server 发出 offload 请求；Disk Server 直接读取对应的内存节点的内存数据，异步写入本机挂载的 ESSD，完成后通知管理器更新位置状态。整个过程不需要额外的 VM 到 VM 数据传输。
3.5 并发与恢复
（1）键级并发控制写入时，管理器先分配内存并对键加写锁；只有客户端完成 RDMA 写入并发送 write-finish RPC 后，条目才对读者可见。并发写同一键时，仅第一个写者继续，后续写者收到重复或进行中状态并跳过。由于同一模型、同一前缀产生的 KV 是确定性的，这既避免重复分配，也避免重复网络流量。
（2）失败降级与恢复PolarKV 把 KV Cache 明确视为性能状态，而非正确性状态。管理器、网络或数据节点暂时不可用时，客户端返回 cache miss，推理引擎重新计算。单个内存节点故障只使该节点上的条目失效，不影响其他节点；管理器元数据则异步持久化到外部云数据库，重启后可恢复映射。缓存层主要用于提升性能，但推理正确性不能依赖缓存持续可用。失败时降级为重计算，使复制、一致性和恢复机制可以保持简单。
实验结果
4.1 微基准
微基准使用 DeepSeek-R1 与 vLLM，输入长度为 10K、20K 和 30K token。每个 session 先用长 prompt 预热，再提交共享相同前缀、仅增加短后缀的请求，并生成 200 token。并发控制在 4 以内，以减少推理引擎排队对 TTFT 的影响，因此结果反映的是高前缀复用条件下的性能上界。默认 PolarKV 由 480 GB 内存和 36 TB 云盘组成。对照的 PolarKV-memory 使用 3 TB 分离式内存，不启用存储层。结果显示，两种 PolarKV 配置相对于不使用外部缓存的原生 vLLM，TTFT 最高均降低 80%，混合层次与纯内存版本几乎持平。例如，加载 20K token 的 KV 约需 0.5 秒，重新计算约需 3 秒。当存储层的聚合带宽足以饱和 GPU 主机网络后，存储介质本身已不再是主要瓶颈，因此继续用 DRAM 替换云盘不会明显降低 KV 加载时延。
图：微基准中的 TTFT 对比
4.2. 与 Mooncake 和 3FS 对比
公开负载使用 SGLang 与 Qwen3-235B-A22B，评测 LooGLE 和 SCBench；其中 SCBench 只选取代表性任务。无外部缓存的 SGLang 基线仍保留由剩余 GPU HBM 和每张 GPU 50 GB 主机内存构成的本地 Prefix Cache。对比将 3FS、Mooncake 与 PolarKV 的外部 KV Cache 池云资源预算控制在约 1.84 万元/月，不包含推理 GPU，并让三者提供至少约 12 GB/s 的聚合带宽。PolarKV 与 3FS 都拥有约 21.4 TB 存储容量，但 PolarKV 额外保留 156 GB 内存带宽层；Mooncake 拥有 928 GB 内存，没有存储层。在 KV 工作集较小的 shortdep_qa 上，Mooncake 的容量可以容纳大部分条目，PolarKV 的 TTFT 仅低约 11%。随着工作集扩大，Mooncake 的容量限制开始显现。综合 LooGLE 与 SCBench，PolarKV 的 TTFT 相对 3FS 降低 47%–58%，相对 Mooncake 降低 3%–58%。
图：公开负载中的 TTFT 对比
4.3 在生产系统上的性能
生产案例来自阿里云上一项自动驾驶领域客户的 Coding Agent 服务。系统使用 SGLang 与 GLM-4.7，单请求 prompt 长度为 192–160K token，平均输入约 71K token，平均输出 423 token。会话会持续积累代码、上下文和工具结果，后续请求高度复用此前前缀，因此非常适合全局 KV 共享。
（1）灰度阶段原集群使用 256 张 H20 GPU，以剩余 GPU HBM 作为一级 KV Cache，每张 GPU 再配置 40 GB 节点本地主机内存，后者合计约 10 TB。由于主机内存缓存只能在节点内使用，请求被调度到其他节点时无法复用原节点上的 KV。灰度阶段把 50% 流量导入 40 张 H20 GPU 加 6 TB PolarKV 存储容量的小集群，剩余 50% 继续由 216 张 H20 GPU 的基线集群处理。在非饱和条件下，同样承担一半流量的 PolarKV 小集群把 P50 查询时延从 13.88 秒降到 6.81 秒，把 P90 从 49.73 秒降到 24.91 秒，平均时延从 21.42 秒降到 12.34 秒，降幅约 42%。更大的共享容量与跨节点复用使有效命中率从约 30% 提升到约 85%，这是时延改善的主要原因。
图：灰度阶段的部署配置与查询时延对比
（2）全量迁移完成全量迁移后，集群从 256 张 H20 缩减为 160 张 H20，并使用 20 TB PolarKV；同期全天服务 token 从 19 亿增长到 32 亿，增幅约 68%。在资源减少、流量增加的同时，全天平均 TTFT 降低 55%，平均端到端查询时延降低 45%；四小时峰值窗口内，两项指标分别下降 61% 和 53%。 （注：这组数据反映真实业务条件下性能数据。两组集群均保留容量余量，并未运行在饱和点，因此不能把对比直接解释为严格的最大吞吐基准。）
图：全量迁移前后的平均时延对比
结语
PolarKV 提供了一种很“云原生”的系统思路：不假设内存天然能够低成本地提供带宽，也不假设云盘天然能够低成本地提供高性能，而是从实际计费模型、资源耦合关系和网络拓扑出发重新组织缓存层次。它用内存承接活跃 KV 的高带宽访问，用云盘保存更大的长尾工作集，再通过配对分片把内存与存储之间的冷热迁移留在本机。“Tier Locally, Serve Globally”概括了整个设计：本地分层避免了 tiering 产生的额外跨机数据搬运，而全局服务仍支持跨节点 KV 共享。受控实验中，混合层次的性能已接近纯内存配置；真实生产部署则表明，PolarKV 能以更少的 GPU 资源支撑更高负载，同时显著改善 TTFT 和端到端业务时延。对于长上下文、高前缀复用的 Agent 工作负载，外置共享 KV Cache 正在成为一种重要的推理基础设施。
