导读大模型推理中的 KV Cache 常被解释为“用存储换计算”。这句话在单机上成立但到了大规模云环境中问题会继续向前移动一旦重复的 Prefill 计算被缓存命中替代系统就必须快速搬运规模很大的 KV 张量此时瓶颈可能从 GPU 计算转向数据读取从 HBM 容量转向跨节点带宽、远端容量与云资源成本。PolarKV 不只是内存加云盘的两级缓存。它把云上资源的计费与性能耦合纳入系统设计云内存的可用带宽受 VM 网卡限制云盘带宽又与预配置容量绑定。因此优化目标不再是单一的容量或命中率而是带宽、容量、成本和网络路径的综合关系。针对这些约束PolarKV 将内存作为带宽层、云盘作为容量层并通过本地配对分片支持跨节点 KV 共享。介绍这一系统的论文发表于 VLDB 2026PolarKV 已作为独立 KV Cache 服务部署在阿里云生产环境可通过轻量客户端接入 vLLM 与 SGLang。受控微基准中TTFT 最高降低 80%公开长上下文负载和真实生产部署也显示出明显的时延收益。KV 复用后的新瓶颈1.1 KV Cache 与 Prefix Cache自回归大模型推理通常分为 Prefill 和 Decode 两个阶段。Prefill 一次性处理输入上下文为各层注意力计算 Key 和 ValueDecode 再逐 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_kvKV 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 配置相对于不使用外部缓存的原生 vLLMTTFT 最高均降低 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 与 SCBenchPolarKV 的 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 正在成为一种重要的推理基础设施。点此下载论文原文PolarKV: Tier Locally, Serve Globally-A KV Cache over Cloud Memory and Storage | Proceedings of the VLDB Endowment
附下载｜PolarKV 论文解析：本地分层、全局共享的云原生 KV Cache
导读大模型推理中的 KV Cache 常被解释为“用存储换计算”。这句话在单机上成立但到了大规模云环境中问题会继续向前移动一旦重复的 Prefill 计算被缓存命中替代系统就必须快速搬运规模很大的 KV 张量此时瓶颈可能从 GPU 计算转向数据读取从 HBM 容量转向跨节点带宽、远端容量与云资源成本。PolarKV 不只是内存加云盘的两级缓存。它把云上资源的计费与性能耦合纳入系统设计云内存的可用带宽受 VM 网卡限制云盘带宽又与预配置容量绑定。因此优化目标不再是单一的容量或命中率而是带宽、容量、成本和网络路径的综合关系。针对这些约束PolarKV 将内存作为带宽层、云盘作为容量层并通过本地配对分片支持跨节点 KV 共享。介绍这一系统的论文发表于 VLDB 2026PolarKV 已作为独立 KV Cache 服务部署在阿里云生产环境可通过轻量客户端接入 vLLM 与 SGLang。受控微基准中TTFT 最高降低 80%公开长上下文负载和真实生产部署也显示出明显的时延收益。KV 复用后的新瓶颈1.1 KV Cache 与 Prefix Cache自回归大模型推理通常分为 Prefill 和 Decode 两个阶段。Prefill 一次性处理输入上下文为各层注意力计算 Key 和 ValueDecode 再逐 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_kvKV 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 配置相对于不使用外部缓存的原生 vLLMTTFT 最高均降低 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 与 SCBenchPolarKV 的 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 正在成为一种重要的推理基础设施。点此下载论文原文PolarKV: Tier Locally, Serve Globally-A KV Cache over Cloud Memory and Storage | Proceedings of the VLDB Endowment
