KV缓存成了独立设备 卸载开始算两笔账

2026年9月30日 · 观天下

今天几条线索合起来是同一件事：KV缓存正在从"计算节点的私产"，变成一件可以被单独采购、单独计价的东西。第一条是华为——昇腾 950 智算集群今天（9 月 30 日）起正式对外提供服务，同时全球首个昇腾 950DT 液冷 1024 超节点落户上海青浦云湖智算中心，官方口径是 256TB 全局统一内存编址。第二条是中科曙光——分布式存储 ParaStor 成为业界首家接入 Mooncake 社区的商用分布式存储，KV Cache 卸载实测 16 倍吞吐提升、达到 DRAM 池吞吐值的 80%。第三条是一家新加坡公司 TuringData——发布专用 KV缓存设备 ContextCube，在 GPU HBM、DRAM、本地 NVMe 之外，明确加出一个共享的 Layer 3.5。补一条：壁仞科技把 PD分离 适配提交进 llm-d 社区主干，成为昨天那条"中报战略"的落地注脚。论文侧今天两篇都在算卸载之外的两笔账：一篇算 时间账（TempoKV，什么时候才该占住快层），一篇算 容量账（EfficientAgent，池子该开多大由工作集决定）；顺带一篇把 AF分离 落到了两种 PIM 介质上。

一、行业动态

1. 昇腾 950 智算集群今天启用，超节点把"交付单位"换成了集群

在华为全联接大会 2026 上，华为董事、华为云 CEO 周跃峰宣布：昇腾 950 智算集群将于 9 月 30 日起面向中国客户提供服务，11 月 30 日起面向海外市场全面提供服务；全新昇腾 950 智算集群的推理效能相比上一代提升至少 20%；基于该超节点打造的 Atlas 950 SuperCluster 集群可扩展至 50 万卡。公开资料显示，昇腾 384 超节点已商用落地 750 多套、累计部署超 1000 套。

紧接着，9 月 29 日，中国电信上海公司宣布 全球首个昇腾 950DT 液冷 1024 超节点正式落户上海青浦云湖智算中心——该超节点可实现 256TB 全局统一内存编址、TB 级超高互联带宽，配合高效液冷架构，是目前业界最大规模可商用超节点。同一天，长三角 AI+ 联合创新中心首批企业签约入驻，Token 产业运营平台正式启动：由中国电信建设运营，以青浦云湖数据中心为核心承载，是全市首个向区级延伸的 Token 超市平台，后续将纳管长三角首批部署的昇腾 950DT 芯片；平台依托"息壤"与 TokenHub 两大能力，采用"前店后厂"运营模式。上海鲲鹏生态创新中心同步揭牌。

为什么值得关注：本系列跟进超节点，一直是按"参数"记的——多少卡、多少 TB、多少 PFLOPS。今天这条把它按"单位"记了一遍：可购买的是一套能直接跑训练与推理的集群，而不是一批卡。这一步对 内存池化 的意义全在定语上——256TB"全局统一内存编址"，意味着这一层的边界由地址空间划定，而不是由服务器边界划定。它同时也是 AF分离 与 PD分离 能落到同一套系统里的前提：如果远端显存不能像本地一样寻址，把 Attention 和 FFN 拆到不同介质、把 Prefill 和 Decode 拆到不同池，都只是"两个集群"而已。

2. 曙光 ParaStor 首家接入 Mooncake：商用分布式存储第一次进入推理核心链路

9 月 29 日，据快科技报道：中科曙光分布式存储 ParaStor 成为业界首家接入 Mooncake 社区的商用分布式存储，首次完成商用分布式存储后端的生产环境落地，相关技术能力已全部合入 Mooncake 社区主干。曙光团队对 Mooncake 的 DFS 存储分配逻辑做了模块化改造，围绕标准化接入、动态扩容与 IO 链路持续优化。

生产环境的实测数字是这样的：曙光联合 SGLang，基于国产加速卡与 ParaStor F9000 搭建端到端测试环境，在 64K 上下文、单卡 7 并发下，KV Cache 卸载实现 16 倍吞吐提升，达到 DRAM 池吞吐值的 80%；平均首 Token 延迟和 P90 首 Token 延迟均保持在 10 秒以内。接口层面，曙光完成了 Mooncake 接口的标准化改造，无需修改上层程序，满足通用文件访问即可快速适配；改造后的 DFS 接口支持缓存空间随业务负载按需扩容，以完整存储段为单元完成冷数据回收，系统重启后缓存数据仍可恢复使用。

为什么值得关注：这一条的分量不在 16 倍，而在"接口"两个字。KV卸载此前最大的阻力是每换一种后端就要动上层程序——池子能接多深，取决于接入要改多少代码。曙光这次把改动收敛到"满足通用文件访问即可适配"，并且把缓存空间做成随负载扩容、重启可恢复，等于把 KV 从易失的中间结果，变成了有生命周期的数据资产。当卸载不再需要改应用，"KV缓存该放哪一层"才会从架构评审题变成一道采购题。

3. TuringData ContextCube：KV缓存第一次被做成一台独立的设备

9 月 29 日，在新加坡 Tech Week Singapore 2026 上，新加坡公司 TuringData 发布 ContextCube——一台专用 KV缓存设备（KV cache appliance），给 AI 推理集群一个共享、持久的上下文池。参与节点通过 RDMA 取回匹配的已缓存 KV，而不是反复重算或各自本地存储。它的设计基于英伟达 CMX 推理—存储参考架构，在 GPU HBM、DRAM 与本地 NVMe 之外，明确加出一个共享的 Layer 3.5。

规格层面上：数百 TB 的共享 KV缓存，保留期从数小时到数周（取决于配置、负载与缓存策略）；单台设备 120 GB/s 的 KV 带宽；用四颗 NVIDIA BlueField-3 DPU 承担数据搬运；26 块 U.2 NVMe 盘、每颗 DPU 两个 200 Gb/s 端口。软件侧兼容 vLLM、SGLang 等推理引擎，以及 TuringData Cache Fabric、LMCache、Mooncake 等 KV缓存软件，可从单台设备起步。CEO Jenvik Li 的原话是：上下文在每个服务器上被一遍遍重算，这台设备给整个集群一个地方去保存这些工作。

为什么值得关注：本系列跟了很久的"层号之争"——华为与腾讯写 L3.5、阿里与英特尔写 G3.5——今天第一次出现一个把这一层直接做成可下单硬件的厂商，而且它明确选了 L3.5 这个名字。更值得注意的是搬运的承担者：不是 CPU，是四颗 DPU。从 内存池化 的角度看，这一步把池子从"软件里的一块地址空间"，变成了"一台有取回接口的设备"。这基本在确认此前的判断——KV卸载的胜负手不在介质，而在"谁来搬"。DPU 接管数据面，等于把 KV 的搬运从主机 CPU 的关键路径上摘出来。当一层存储有了型号、有了带宽数字、有了加速器配置，它就不再是架构图上的一个方框，而是一项有采购单价的组件。

4. 壁仞科技把 PD分离 适配提交进 llm-d 社区主干

9 月 28 日前后的一份技术分享显示：壁仞科技向社区提交了以 Qwen2.5-72B 为对象的 PD分离 适配方案，采用"1 Prefill + 1 Decode"部署方式，两个实例分别部署在不同节点，每个实例通过四张壁砺 166M GPGPU 做张量并行（TP=4）。方案复用了 llm-d 的 routing sidecar 协调请求处理，并通过 vLLM NixlConnector 完成 KV Cache 传输——Prefill 实例负责输入计算并生成 KV Cache，Decode 实例接收缓存后继续生成输出，构成跨节点协同推理链路；通信侧通过 UCX 使用 InfiniBand RDMA，并采用 CPU 缓冲区承接 KV 数据传输。同一批提交里，壁仞还把 RLinf、slime、verl 三个强化学习框架的适配集成进社区主线。

为什么值得关注：这是昨天那条（壁仞中报把 PD分离 与 AF分离 并列写进公司战略）的落地注脚。把 PD分离 做进 llm-d 社区主干，意味着它对国产芯片不再是"某家方案里的一项优化"，而是一段可以合入通用调度框架的标准配置。顺带那句"用 CPU 缓冲区承接 KV 数据传输"也值得记：在 RDMA 直通显存已是选项的今天，仍有大量部署走 CPU 中转路径——这也正解释了为什么"谁来搬"会成为这一层的主战场（呼应上一条的 DPU）。

二、论文分析

论文一：TempoKV——池子的"时间账"：知道会复用，不等于现在就该占住快层

论文：TempoKV: Timely Staging of LLM KV Caches for Memory-Semantic Flash（arXiv:2609.35065，9 月 28 日提交，Jay H. Park / Hyungjun Kim / Dong Kim）。

问题设定很干净：可复用的前缀 KV缓存会超出 GPU 显存；而内存语义闪存这类层级提供"SSD 的容量 + 一个有限的快层"。但论文指出一个被忽略的断层——逻辑上的 KV 命中，不等于它已经准备好给 GPU 取用。按需 staging（等要用了再搬）会把 SSD 的延迟直接暴露在关键路径上；立即 staging（一命中就搬）又会在取用开始前很久，就长期占住快层容量。

TempoKV 的做法是一个"时点感知的资源承诺层"：把"提前知道会复用"和"获取 staging 资源"两件事拆开。缓存命中先只记成 metadata-only claim（只有元数据、不占资源）；当运行时估计的"距离取用还剩多少时间"降到"存储侧估计的、把 KV 变成常驻并受保护所需的时间"时，才请求正式承诺（commitment），而承诺仍受可用保护容量约束。两个估计都随运行时进度与 staging 状态自适应。

结果：在 vLLM 与 LMCache 上、接一块 SSD-backed 的 CXL 内存设备实现（不改请求调度），两个模型、三种前缀缓存比例下，每请求受保护快层的 byte-time 减少 63%–91%，同时保留大部分提前 staging 的服务收益；快层容量从 100GiB 一路降到 25GiB，输出吞吐与 p95 首 Token 时延几乎不变；相比未改的 LMCache Device-DAX L1 配置，p95 TTFT 最多降 48.0%、输出吞吐最多升 27.8%。

为什么值得关注：本系列记录过的 内存池化 手段，几乎都是"往哪放"（HBM→DRAM→SSD→远端）。TempoKV 把问题换成了"什么时候占"，答案是一个对偶式——提前知道几乎免费，占住资源很贵，所以把两者拆开、按时间差择时兑现。这对 超节点 尤其重要：统一内存编址把"搬"的成本压下去之后，剩下的瓶颈就是这一层里"优先级与保护容量"的分配。文中那句"逻辑命中不等于已就绪"也适用于所有分层方案——命中率是容量指标，就绪时间才是性能指标。

论文二：EfficientAgent——池子的"容量账"：该开多大由工作集定，不由配置定

论文：EfficientAgent: What Makes KV Cache Offloading Work for Concurrent Agents?（arXiv:2609.33762，9 月 27 日提交，Kunming Shao / Jierun Chen / Jiangnan Yu / Xiao-Hui Li / Chaofan Tao / Yanli Wang / Huanxin Lin / Kwang-Ting Cheng / Chi Ying Tsui / Haoli Bai，代码已开源）。

它从一个反常识的现象切入：对 Agent 来说，卸载的效果前后不一致——同一个 coding-agent 负载，在一个部署上加速、在另一个上变慢、在第三个上完全没变化，哪怕把 token 从 host 取回比重新计算便宜好几倍。

原因是结构性的：缓存状态必须"活到被再次使用"。一个 Agent 在等工具返回时，服务器正在跑其他 Agent 的上下文，所以这个 Agent 的前缀只有在 host 层装得下整个 Agent 池的可复用上下文时才会被复用——论文把这一整块叫作 reuse working set。层太小，就只是在不断写入"还没人读就被驱逐"的状态。做法上，论文用 stack-distance 模型从 agent 历史估计 working set 来定 host 层大小；层太小时，运行时策略停止写入被驱逐上下文的大块 refill，转而继续扩展仍被缓存的前缀；层足够大时则全写。

结果：在 SWE-bench Verified 的 coding agent 上，按估计 working set 配置的 host 层，重算 prompt token 减少 93%、端到端时间降 39%；小固定层下该策略减少 35% 重算；大层下则避免了"总是过滤写入"带来的 4.3 倍劣化。跨三种 GPU、两个模型的一致结论是：卸载划算的条件 = GPU 每字节 host 带宽的算力低，且 host 层装得下工作集。

为什么值得关注：这一篇把 内存池化 的容量问题从"配置"改成了"工作量"。池子该开多大不是拍脑袋定的，而是由并发 Agent 池的可复用上下文总量决定的；小于工作集，卸载就只是在浪费带宽。它对国内智算中心的直接含义是：KV卸载的 ROI 不能用"单请求命中率"来衡量，要用"整池能不能装下工作集"来衡量——这也正好解释了曙光那条（本文条 2）为什么强调"缓存空间随业务负载按需扩容"。论文一算的是"什么时候占"，论文二算的是"整体该留多大"，两篇合起来才是一份完整的池化预算表。

顺带一篇：SPIMOE——AF分离 被切到了两种 PIM 介质上

论文：SPIMOE: Exploiting Hybrid Sparsity for Reasoning MoE Inference on Heterogeneous PIM Architectures（arXiv:2609.34612，9 月 28 日提交，Rubing Yang / Cenlin Duan / Yingjie Qi / Xiaolin He / Xiao Ma / Jianlei Yang）。

它指出长推理 MoE 的两个耦合瓶颈：KV缓存膨胀把关键路径推向注意力，而专家激活稀疏又导致负载不均、硬件利用率低。现有 PIM 加速器通常只单独优化注意力或 FFN。SPIMOE 的协同设计把注意力与 FFN 分别卸载到 SRAM-PIM 与 HBM-PIM 两类异构存算一体介质上，再叠加自适应专家路由、块稀疏注意力与物理 KV缓存驱逐，并用静态专家映射与动态子批次调度平衡负载、重叠两条路径。结果：端到端最高 8.35 倍于 A100，MoE FFN 执行最高 3.33 倍于 PIMoE，推理精度与全注意力基线相当。

为什么值得关注：这是 AF分离 落到了"介质"这一层——Attention 与 FFN 不只是被拆到不同芯片，而是被拆到两类物理特性不同的存算一体介质上。它把本系列一直追的两条线合到了一起：AF分离 在切算子类型，而 PIM 在切"计算离数据多近"。两者叠加之后，切分的第一性问题变成了：哪一段更适合放进哪一种介质里。

三、结语：三个判断

判断一：卸载正在从"往哪搬"变成"谁来搬、什么时候搬"。条 3 的四颗 DPU、条 4 的 CPU 缓冲区、论文一的择时承诺，是同一件事的三个不同侧面。介质问题（HBM/DRAM/SSD/CXL）在过去一年已经被讨论得足够多，而数据显示，真正决定收益的是搬运的执行者和占用的时机。

判断二：池子的大小与占用时机，正在取代"池化的层数"成为新的胜负手。论文一算时间、论文二算容量；两篇合起来给出一个可复用的判据——卸载划算的前提是池子装得下工作集，并且只在快层真正需要它的那段时间里占用。对 超节点 这类把存储与计算编进同一套地址空间的系统，这条判据比"分了几层"更有决策价值。

判断三：KV缓存正在变成一种"资产"，而资产的三要素现在都有了对应手段。生成成本、复用价值、生命周期——曙光把它做成可扩容、可恢复、可标准化接入（条 2）；TuringData 把它做成有型号、有带宽、有 DPU 配置的设备（条 3）；华为把它写进 256TB 的统一地址空间（条 1）。当 KV缓存 有了生命周期，"KV卸载"这个词本身就开始不准确了——它更像是在给一类数据安排长期存储位置，而不是在做一次临时的搬家。

四、观察清单

1. 昇腾 950 智算集群的首批使用记录。9 月 30 日启用后，值得跟踪的是真实训练任务的规模、长时间运行成功率与单位算力成本——这些比参数更能说明"集群作为交付单位"是否成立。

2. Mooncake 社区主干会不会因商用品类接入而分区。曙光作为首家商用分布式存储接入方，其"标准化接口"是否会成为其他存储厂商的对齐基线，决定这一生态是收敛还是一分为二。

3. Layer 3.5 会不会成为通用编号。此前是华为与腾讯用 L3.5、阿里与英特尔用 G3.5；TuringData 这台北美参考架构设备直接选了 L3.5。当独立设备厂商开始按层号命名产品时，这一层的标准答案可能比想象中更快出现。

4. DPU 会不会成为 KV缓存层的标配。ContextCube 用四颗 BlueField-3 做数据搬运，而壁仞的适配方案仍走 CPU 缓冲区。这两条路径的成本差，会直接反映在单位 Token 成本上。

5. TempoKV 的"承诺"机制会不会被写进 KV缓存层软件。它把"命中"与"占用"拆开，逻辑上更接近缓存替换策略之外的一层资源管理器。若被 LMCache、Mooncake 这类软件采纳，池化的 KPI 会多出一栏——受保护容量的时间占用效率。

6. "reuse working set"会不会成为容量规划的标准词。EfficientAgent 给出的判据是"装不下工作集，卸载就是浪费"，这意味着采购 KV缓存层时要先回答"并发 Agent 池到底多大"，而不是先问"能扩到多少 TB"。

7. AF分离 会不会从"分到不同芯片"走到"分到不同介质"。SPIMOE 把 Attention 放到 SRAM-PIM、FFN 放到 HBM-PIM。这条路线一旦被硬件厂商接住，AF分离 的讨论重心会从"要不要拆"变成"哪一段更配哪种介质"。

免责声明：本文所涉信息均来自公开渠道，仅代表作者个人观点，不构成任何投资建议。市场有风险，决策需谨慎。