KV缓存共享到万卡 卸载瓶颈不在介质在语义

2026年9月27日 · 观天下

今天三条线索，拼起来是两句话：池子的边界正在改由"地址空间"划定，而 KV卸载 的胜负手正在从"介质"转向"计划"。第一条来自云栖的收尾——阿里云磐久 AL144 在分论坛上亮相，把 ScaleUp 域从百卡级推到 10368 卡，官方口径里第一次出现"长上下文推理的 KV缓存 可以在万卡级共享"这样的表述。第二条来自苏州——英特尔在这轮拆解稿里补上了开放 Agent 整机柜平台规范：44U 机柜、32U CPU 区、基于 CXL 做内存扩展，把整个机柜组成一个可统一调度的内存池。第三条是落地侧的口径，鲲鹏超节点把上百 TB 的 KV缓存池接进生成式广告推荐，并在京东 618 大促里跑过一次。论文侧今天两篇都带反常识：一篇测出原厂 CXL-SSD 并不比一块 NVMe SSD 更快、还比本地 DRAM 慢约 3 倍；一篇用两家公司的生产 trace 证明那些精巧的 KV 驱逐策略，打不过最朴素的 LRU。

一、行业动态

1. 云栖之后，阿里云把 ScaleUp 域从百卡级推到万卡级

9 月 22 日，阿里云在 2026 云栖大会发布磐久 AL64 分布式 SNPO 光互连超节点，官方称这是全球首款实现 SNPO（ScaleUp 专用近封装光学）落地的超节点服务器。两天后的分论坛上，更进一步的 AL144 亮相。

AL144 的关键规格是这样的：单柜 ScaleUp 域最大 144 颗 GPU，相对 AL128 在"单柜 ScaleUp 域规模、单柜功耗、最大支持单 GPU 功耗"三个维度分别实现 2 倍、1.86 倍、1.75 倍的跃升；跨柜时通过基于 SNPO 光互连的 ALink Switch 组成二级 ScaleUp 域，无收敛扩展至 288 卡、1024 卡乃至 10368 卡；单柜功耗 650kW，最大支持单 GPU 功耗 3500W，单柜 ScaleUp 带宽达到 Pb/s 级。供电与散热上引入 800V PDB in Server 与 800V Cap Shelf 垂直供电架构，配合 UAM 通用加速器模组、垂直喷射微通道冷板、浮动接头 UQD 与新型流变稳定型液态金属，全液冷原生设计。路线选择上，AL144 的 ScaleUp 互连对齐 UALink 开放协议与 SNPO 光互连开放规范，产业链伙伴可以基于开放接口参与定义。

它带来的能力变化，官方描述里有三句很值得记：MoE 万亿参数模型的 Expert Parallel 可以放进同一个 ScaleUp 域内；长上下文推理的 KV缓存 可以在万卡级共享；Agentic AI 的多智能体协同可以直接以内存语义互访，而不再被迫走慢一个数量级的 ScaleOut 网络。文章给这组能力的定位是："单一 ScaleUp 域从数百卡到万卡，是超节点从'更大整机'迈向'更大计算机'的关键一跃。"

9 月 27 日，机构研报与财经媒体把这条线索接到了产业侧：研报把它定性为国产 AI 基础设施进入规模化落地新阶段的标志，并认为超节点架构会直接拉动交换芯片、光模块、液冷、IDC 等环节的订单，相关标的处于"技术验证向批量交付转化的关键窗口"。同期的另一组口径是：阿里云宣布未来 12 个月新增 3 个海外云节点、扩建 7 地数据中心，目标 2032 年全球算力规模超过 20GW。

值得关注的原因：这是"共享"这个词第一次被放进 KV缓存 的语境里，而且共享的尺度是万卡。此前本系列记录的池化尺度，要么按容量计（华为鲲鹏超节点 256TB 统一内存池），要么按层级计（阿里 G3.5、华为 L3.5）；今天第一次出现"万卡级 KV缓存 共享"这种以加速器数量计的表述。尺度单位从"容量"换成"卡数"，说明共享的对象正在从"存下来的状态"扩展到"正在参与计算的状态"——这两件事对一致性和带宽的要求完全不是一个量级。对超节点这个方向本身来说，Expert Parallel 能进同一域，也等于把 AF分离 最好用的那块地基又垫高了一层：FFN 侧要独立扩缩容，前提正是它所在的域足够大、寻址足够统一。

另外要做一个"事实之问"：AL144 现在至少出现在三个位置上。一是 9 月 22 日的 AL64（64 卡、ScaleUp 扩至 1024 卡，称全球首款 SNPO 落地）；二是 9 月 24 日分论坛上的 AL144 亮相（144 卡、扩至 10368 卡）；三是第三方整理的云栖路线图，把 AL144 列为 2028 年的"终极形态"。同一型号同时出现在"已亮相"与"2028 路线图"两个位置上，说明产品名与代际编号在传播中已经被混用。看这类数字时，先确认定语是"已发布""已亮相"还是"路线图"，比记住卡数更要紧。

2. 英特尔把池化对象从 KV缓存 扩到整个机柜的内存

2026 英特尔技术创新与产业生态大会（9 月 22 日至 23 日，苏州）的中文拆解稿在这两天继续扩散，其中最值得补记的不是 KV加速套件本身（本系列 9 月 25 日已写过四件套），而是同一场会上发布的另一件东西：英特尔联合产业伙伴发布的开放 Agent 整机柜平台规范。

这套规范的硬件口径是：44U 机柜、其中 32U 为 CPU 区，每个节点支持 4 颗或 6 颗单路 CPU，支持基于 CXL 的内存扩展，把整个机柜组成一个可统一调度的内存池，兼容至强 6、至强 6+ 以及下一代平台。官方对外的说法是"任何厂商都可以照着这套开放标准，打造自己的智能体整机柜"。

KV加速侧则补上了一组此前没有的实测口径。分层逻辑仍是四层：极热数据常驻 L1 层（GPU HBM 显存）保障低延迟；热数据卸载至 L2 层（DDR 内存），通过大容量缓存池扩容降本；温冷数据下沉至 L3 / L4 层（本地 SSD 或远端分布式存储），实现持久化复用。其中 KV Shrink 的三条实测账更具体了：压缩环节由至强内置的 QAT 完成，通过重排 KV缓存 的数据存储格式，压缩率从原来的 10%+ 提升到 20%–30%，500TB 规模下可节省约 150TB 存储空间；数据搬运交给 DSA 加速器，KV缓存 传输速率最高提升 9.66 倍；在 80% 缓存命中率的典型场景下，KV Shrink 相比原生 vLLM 基线 TTFT 最高提升约 5 倍，CodingAgent 场景实测单路 TTFT 仅 114.13 毫秒。在 GPU 服务器一侧，至强内置的 AMX 加速器让向量化与重排序性能分别达到对比基准的 2 倍和 4 倍。

还有三个此前没被讲到的机制细节，值得单独记一笔：QAT 把数据压缩与加解密整体硬件卸载，把更多核心留给智能体业务；RDT 为每个沙箱分配独立的缓存与带宽通道，防止单个失控的沙箱抢占整机资源；TDX 为涉及企业数据与代码资产的高敏感任务创建硬件级信任隔离域。

值得关注的原因：这一条和上一条，是同一个动作的两个尺度。上一条把超节点的 ScaleUp 域推到万卡，是集群级池化；这一条把整个 44U 机柜的 CPU 内存编成一个可统一调度的池，是机柜级池化。两者共同点是——池里最活跃的租户都是 KV缓存，但池的边界都不再由"用什么介质"划定，而由"能不能被编进同一套地址空间"划定。这与 WAIC 2026 那份 38 家单位联合白皮书对超节点的定义（跨物理节点统一内存编址）是同一句话在不同尺度上的复述。

另外还有一处细节值得圈出来：QAT 的压缩率提升靠的是"重排 KV缓存 的数据存储格式"，而不是换一个更强的压缩算法。这又是一个"瓶颈在数据布局、不在硬件能力"的例子——它正好与下面论文一的核心结论对上。

3. 鲲鹏超节点把"内存池化"带进了大促现场

第三条来自落地侧。围绕华为鲲鹏超节点的一批复盘稿给出了一个此前少见的场景——生成式广告推荐。

这类系统的时延敏感度是可以直接折算成钱的：每优化 10 毫秒，对应 0.5% 到 1.5% 的收入增长。但传统架构下推荐系统的 RPC 通信占了端到端时延的大头，而四级缓存架构中远端的 KV缓存 访问又慢又不准。鲲鹏超节点的解法是两招叠加：用灵衢互联把 RPC 通信提速，再用内存池化把上百 TB 的 KV缓存 全部拉到"身边"，让远端变近端。结果是在线推荐端到端时延降低 15%，并且这套方案已经在京东 618 大促中跑过实战。

LLM 推理侧的数字此前本系列已记录过一部分，这里补上语境：在 Prefill 阶段，超大缓存池把 KV缓存 命中率从传统方案的不到 80% 拉到 99%，硬件压缩引擎再省下 25% 的存储空间；到了 Decode 阶段，当上下文拉到 256K 甚至百万 Token 级，一张卡需要的内存就超过 300GB，单机内存条根本装不下，而接进上百 TB 的内存池后生成速度翻了 2 到 3 倍，且上下文越长、提速越猛。Agent 沙箱侧是第三块：用强化学习训练 Agent 时动辄要同时拉起 10 万个沙箱做并行试错，传统服务器方案启动要 5 分钟，鲲鹏超节点用镜像预加载与 RemoteFork 技术把它压到了 10 秒。

值得关注的原因：这是内存池化 第一次出现在大促流量现场，而不是实验室或发布会。前两个条目的池化尺度都在讲容量与带宽，这一条讲的是收益最终落在了哪个业务指标上——推荐时延、收入百分比、大促可用性。它印证了本系列 9 月 21 日记录过的那个判断的最初形态：池化的价值最终要能被写成业务账，而不是架构图。对 PD分离 也有一层含义：Prefill 侧能省下多少算力，最终取决于池里留住了多少可复用的前缀——池化在这里不是 PD分离 之外的另一件事，而是它的前置条件。同时它也给出了一个边界提示：短请求、一次性问答这类场景的收益有限——池化吃的是"上下文的复用率"，没有复用就没有池。

二、论文分析

论文一：LM-CXD——KV卸载 的瓶颈不在 NAND，而在数据路径的语义

（arXiv:2609.26828，9 月 20 日提交、9 月 24 日公告，作者 Hyunsun Chung、Taewan Noh、Minji Kim、Joo-Young Hwang、Hong-Yeon Kim、Youngjae Kim）

这篇论文的出发点很直接：NAND 提供了扩展前缀缓存所需要的容量，但它的块 I/O 路径除了 NAND 延迟之外，还额外引入了两笔开销——CPU 缓存争用与主机 DRAM 暂存。

第一个反常识在这里：作者的表征显示，这两笔接口开销在把存储介质换成 DRAM 时依然存在。换句话说，问题的根源不是 NAND 慢，而是这条路径的语义不对——数据要为了一次访问而穿过层层不适合它的抽象。这个结论自然地指向一种解法：既然瓶颈在块接口，那就把 NAND 变成字节可寻址，也就是 CXL-SSD。

第二个反常识紧跟其后：实测发现，原厂 CXL-SSD 依然比本地 DRAM 慢约 3 倍，而且并不比一块 NVMe SSD 更快，通用预取也几乎不起作用。换接口这件事，在原厂形态下并没有兑现它承诺的收益。

LM-CXD 的解法不是换硬件，而是补上设备与引擎之间的语义缺口。作者的原话是：服务引擎知道接下来要消费哪些 KV chunk，设备控制着这些 chunk 的放置与搬运，而在此之前，两边谁都没告诉谁。LM-CXD 做了四件事把它接上：把 KV chunk 变成设备可见的 I/O 单元；把 NAND 到 DRAM 的搬运进度暴露给服务引擎；把设备侧 DRAM 当作 GPU 可访问的缓冲区；再配合请求调度与窗口化预取，并把逐层的 KV 搬运与 GPU 计算做成流水线，用计算来遮挡 NAND 延迟。

在五个 LLM 模型上，相比原厂 CXL-SSD，compute-async 预取把平均 TTFT 降低最高 2.6 倍，采用逐层预取后最高 4.03 倍，平均落在本地 DRAM 的 1.5 倍以内。作者也说明了边界：这是一个需要定制 CXL-SSD 的设备级提案，不是开箱即用的替换件；"1.5 倍以内"是五个模型的平均值，且摘要里没有给出多并发命中场景下的吞吐。

值得关注的原因有两层。第一层是它对一个正在被大量厂商力推的品类的态度：CXL-SSD 目前被当作"把 NAND 纳入内存层级"的关键器件，而这篇论文把它的原厂性能摆上了台面，结论并不客气——3 倍于 DRAM 的差距、与 NVMe 持平、通用预取无效。这对正在做技术选型的人是直接有用的信息。

第二层是它给出的判据：KV卸载 的收益不在"介质换成什么"，而在"设备与引擎之间有没有一份共同的计划"。引擎知道要读哪些 chunk，设备知道它们在哪、搬了多久——把这两件事接上，才有了 4 倍量级的 TTFT 改善。这条判据可以回头解释本系列记录过的几个动作：华为把前缀查找、缓存校验与格式转化下沉进 KVU 模组（让设备参与这份计划），英特尔的 QAT 靠重排存储格式把压缩率从 10%+ 抬到 20%–30%（让引擎按设备友好的布局写入）。它们本质上都不是因为"硬件更快"，而是因为"能参与计划"。这一条对正在做超节点方案的人尤其重要：池化把 KV缓存 推得越远，设备与引擎之间那份计划的价值就越高。

论文二：When Fancy Eviction Fails——精巧的 KV 驱逐策略，打不过最朴素的 LRU

（arXiv:2609.28870，9 月 24 日提交，作者 Yiyu Liu、Minlan Yu、Juncheng Yang）

长跑的 LLM 应用会不断重复发送变长的上下文，前缀缓存因此成为降低 Prefill 成本的关键。但作者指出，Agent 负载下前缀缓存的行为仍缺少理解。他们拿到两家公司的生产 trace，在 HBM 受限与大内存池两种设置下评测了 14 种驱逐算法。

结论很硬：尽管距离 Belady 最优解仍有不小的差距，但那些为传统缓存精心设计的复杂策略，相比最简单的 LRU 几乎没有带来增益。原因是结构性的——前缀复用被活跃会话的规律节奏主导，这使得"最近性"异常具有预测力。

但前缀缓存也确实带来了传统缓存没有的挑战，作者点出两条：会话足迹呈重尾分布，以及未命中成本随序列长度增长而剧烈变化——因为一次未命中意味着要重算越来越长的注意力。为了量化这两件事，作者提出了"计算节省比"指标与两个离线 oracle。

最终的工程建议是一个"以 LRU 为骨架"的组合：保留最近性作为基础，再选择性地加三样东西——对"只被命中一次的前缀"做快速降级（quick demotion）、对高代价未命中做计算感知的部分驱逐、以及随容量变化的驱逐粒度。作者还表示会公开这批 trace 与模拟器。

值得关注的原因：这是本系列记录到的第四条同源证据。前三条分别是：随机注意力那篇发现选择信号几乎没用，均匀随机驱逐就能追平最强的打分器；InertiaKV 发现解码期 KV 驱逐的胜负手在时间聚合而非打分器；《KV Cache 该放在哪》那篇则发现预测复用策略与 recency 在字节级上几乎相同。今天这篇把原因说透了：不是打分器不够聪明，而是前缀复用的流量本身太规律——规律到"最近用过的"就已经足够好。

更重要的是它给出了池化时代的新变量。当本文在"大内存池"设置下评测时，问题的性质其实已经变了：池子变大之后，"驱逐谁"这个问题会分裂成"驱逐多少"与"以什么粒度驱逐"。这正是内存池化 把一个算法问题变成容量规划问题的过程。

顺带一提，同一周还有一篇 KVSET（arXiv:2609.27746，9 月 23 日提交），把"KV缓存 工作集"定义为达到目标命中率所需的最小缓存容量，并用 Mattson 栈算法一次性估计整个容量区间上的命中率，从而避免逐个容量配置去模拟。两篇合起来，正好构成池化管理的两端：一篇回答"该留多少"（容量），一篇回答"该换谁"（策略）。

三、结语：三个判断

判断一：池化的尺度在同时变大和变小，但两头的边界都由"地址空间"划定。万卡级 ScaleUp 域（条1）与 44U 机柜级内存池（条2）是同一个动作的两个尺度；共同点是池的边界不再由"用什么介质"划定，而由"能不能被编进同一套地址空间"划定。这也解释了为什么互连协议（UALink、SNPO、灵衢）会成为这轮超节点竞争的主战场——决定池子大小的，是寻址能力，不是容量标称值。

判断二：KV卸载 的判据从"介质"转向"计划"，而这一步比换硬件便宜得多。论文一给出的 CXL-SSD 原厂性能真相说明：介质换代本身并不解决问题，真正缺的是设备与引擎共享一份"接下来要读什么、什么时候能搬完"的计划。这条判据能串起本系列此前的两个动作：华为把前缀查找与格式转化下沉进 KVU 模组，是让设备参与计划；英特尔用 QAT 重排 KV缓存 的存储格式，是让引擎按设备友好的布局写入。对做系统的人来说，这条意味着一个好消息：在掏钱换介质之前，还有一段很长的路可以靠语义对接来换性能。

判断三：PD分离 的下一问是"配额"，AF分离 仍然是"互联带宽的函数"。条1 里 10368 卡的 ScaleUp 域把 MoE 的 Expert Parallel 放进同一域内，等于把 AF分离 的前提——充裕的 Scale-Up 带宽与统一寻址——又往前推了一格；但本系列跟踪显示，AF分离 目前仍主要在架构条款、异构系统与算子级研究里被提及，尚未出现当日级的独立产品方案。反倒是 PD分离 的讨论已经进入"边界怎么弹性化"的阶段（本系列 9 月 25 日记录的租约机制）。换句话说：AF分离 还在等路修好，PD分离 已经在讨论车道怎么分配了。而内存池化 这一环，今天同时拿到了"该多大"（KVSET）与"该换谁"（论文二）两个方向的答案，是四个方向里进展最完整的一个。

四、观察清单

1. AL144 的"已亮相"与"2028 路线图"两个位置会不会统一。同一型号同时出现在两个时间点上，说明产品名与代际编号在传播中已被混用。要盯的是官方规格书里"支持的 GPU 代际"与"最大 ScaleUp 规模"这两项的定语。

2. 万卡级 KV缓存 共享的具体语义。"可以在万卡级共享"目前是一句能力描述，缺的是可共享容量、跨卡一致性模型与带宽保证的口径。共享的到底是"存下来的 KV"还是"正在参与计算的 KV"，决定它属于 L3.5 那一层，还是真正意义上的显存池。

3. 英特尔开放 Agent 整机柜规范的落地厂商名单。规范是开放的，但"整机柜统一调度内存池"需要 CPU、BMC、操作系统与 CXL 控制器四方协同。要看的第二件事是：这套规范与 KV缓存智能加速套件之间，有没有定义标准接口。

4. LM-CXD 要求的"CXL-SSD 定制"什么时候变成 SKU。论文自述这是设备级提案而非开箱即用方案；而 SK 海力士已在内存路线图上列出"分层 KV缓存 管理"，这篇相当于给出了那个功能必须包含什么（chunk 感知 + 引擎可见进度）。盯"设备向引擎报告搬运进度"这条是否出现在正式的接口标准里。

5. KVSET 的"工作集"口径会不会被云厂采纳成采购参数。若"达到目标命中率所需的最小缓存容量"成为可报价的指标，KV缓存池的采购就会从"按 TB 买"转向"按命中率目标买"——这一步会直接改变池化方案的定价方式。

6. "计算节省比"能不能替代命中率。论文二提出这个指标，是因为未命中成本随序列长度剧烈变化，而命中率把每一次未命中都当成等价事件。如果它被社区采纳，KV缓存池的 KPI 会从"命中率"换成"省下的算力"。

7. "驱逐粒度随容量变化"这一条会不会进推理引擎。论文二的三条建议里，这一条最容易被忽略，但它恰恰是池化的直接产物——池子越大，逐 Token 驱逐越不划算。

8. 京东 618 的推荐时延收益能不能拿到第三方复现。目前是厂商口径。要问的是三级缓存各层的命中率占比，以及与"不做池化"的 A/B 对照。

9. 云栖成果被折成订单口径这一步，哪些环节最靠前。研报列出的受益环节是交换芯片、光模块、液冷、IDC。从本系列记录的工程顺序看，ScaleUp 光互连与液冷是与超节点架构强绑定的两环，最容易先行；而"有效 Token 产出"这类计价口径，目前还没有落到财报科目里。

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