导言
我看到 Mooncake 为 Ascend 提供了三个编译开关：USE_ASCEND、USE_ASCEND_DIRECT 和 USE_UBSHMEM。最直接的问题是：它们是不是三套并列的通信 engine？特别是后两个名字里已经有 Direct 和 SHMEM，是否意味着数据传输已经由 AIV 直驱？
沿着合入 PR 和源码调用链看下去，答案逐渐清楚：这不是三套同层方案，而是 Mooncake 先后解决“能传”“通用地传”和“把远端内存映射后再传”三个问题留下的三条路径。更重要的是，按当前可见源码，三者都不能直接称为 AIV 直驱。
导言
理解“AIV 直驱缩短了通信控制路径”之后，下一步不是立即抄一个 AllGather，而是先闭合一条最小链路：Host 建立资源并分配对称内存，启动一个 AIV Kernel；Kernel 把数据写到对端并发布 signal；接收端等待 signal，最后 Host 确认完成并按依赖顺序销毁资源。
本文基于 cann/shmem@382afa08efa801d7bca6c2645fd17e155111efcc 和 CANN 9.0.X / 9.0.0-beta.2 官方文档。代码是绑定该 revision 的教学归一化代码，不是承诺可在任意 CANN 版本直接编译的通用样例。
导言
TileXR 的 README 提到：若 UDMA 不可用，通信会平稳降级为 IPC/MTE。这个说法容易让人误以为 UDMA、IPC 和 MTE 是三个可以直接互换的传输引擎，或者一次 UDMA 调用会在失败后自动改写成 MTE 调用。
更准确的理解是：IPC/MTE 是一条组合路径。IPC 负责让本进程看见其他 Rank 的 NPU 内存，MTE 负责真正搬运数据；UDMA 则是另一套带队列、远端内存注册和完成通知的数据搬运后端。TileXR 所谓“自动降级”主要发生在初始化与能力选择阶段，而不是单次传输内部。
导言
TileXR 和 cann/shmem 都涉及昇腾设备间通信，但它们封装的不是同一层对象。TileXR 面向通信器、共享窗口和融合算子；cann/shmem 面向 PE、对称堆与单边通信原语。把二者简单画成一条“TileXR 调 SHMEM”的直线，会掩盖 TileXR 三个实际 MC2 算子的不同通信路径，也会忽略其固定 SHMEM fork 与 cann/shmem main 之间尚未闭合的 ABI。
本文只依据三个固定源码状态：TileXR 46c58f3d、它的 SHMEM gitlink b79bda38、cann/shmem main 382afa08。没有 Ascend 硬件与完整 CANN 构建验证，因此“源码存在”“设计意图”和“可编译运行”会严格分开。
导言
PagedAttention 是 vLLM 高吞吐推理的核心内存管理机制。它没有改变 Attention 的数学公式，也没有消灭 KV Cache，而是把每条请求持续增长的 KV Cache 切成固定大小的 Block，通过 Block Table 将逻辑连续的 Token 映射到不连续的 GPU 物理块。
它解决的核心矛盾是：LLM 服务需要保留大量、长度未知且生命周期不同的 KV Cache，但 GPU 显存有限，传统连续分配容易产生预留浪费和碎片。 更高的显存利用率允许 vLLM 同时容纳更多请求，进而扩大 Batch、提高吞吐并降低高负载下的排队延迟。
导言
MoE 的 All-to-All 不是一次整齐的等长集合通信，而是由路由结果决定长度的 pack、跨 rank 搬运、完成通知、expert 计算、反向搬运与 combine。固定源码表明：TileXR 主仓已经预留 sendCountMatrix、UDMA flag 与设备指针，却没有落地可追踪的 MoE dispatch/combine kernel；真正实现分别位于它固定的 SHMEM fork 和 cann/shmem。本文只描述源码能证明的部分，所有缺少完整实验条件的性能数字均标为未公开或不可归因。
导言
Mooncake 接入 vLLM 并不是把一个传输库直接塞进 attention：vLLM KVConnector 管请求和生命周期，Mooncake Transfer Engine 或 Store 管数据，vllm-ascend 再补上 NPU 地址、事件与后端适配。本文从固定 revision 的真实调用点穿刺这条链路，并专门核验一个容易混淆的问题：支持 Ascend、HCCL/RDMA 或名为 UBSHMEM 的 transport，是否等于使用 AIV Kernel 直驱？公开源码给出的答案是：不能等同，且当前没有找到 Mooncake KV 传输由 AIV Kernel 直驱的证据。
导言
Agentic LLM 的每轮新增输入很短，累计上下文却很长。高 KV Cache 命中率把重复计算变成了外部存储读取，但传统 P/D 分离系统只让 Prefill 节点承担读取，结果往往不是 GPU 算力不足，而是 Prefill 侧 Storage NIC 先堵住。DualPath 的核心不是压缩 KV，也不是换一种 Attention，而是把 Decode 侧闲置的存储入口和计算网络一起纳入 KV 加载路径，再用 QoS 与两级调度防止新路径干扰推理。本文进一步判断：昇腾 AIV 直驱可以成为其中一段细粒度 RDMA 控制路径的候选优化，但不能直接替代 DualPath 系统。
导言
Mooncake Store 的 KV Cache 管理很像 PagedAttention：两者都采用 切块、间接寻址、按块复用与淘汰。但它们解决的不是同一层问题。PagedAttention 管理单个推理实例内的 GPU KV Block；Mooncake Store 管理跨请求、跨实例、跨节点的 DRAM 与 SSD 副本。
理解二者关系的关键，是先区分 页表 与 KV 数据页：页表记录当前请求的逻辑块对应哪个 GPU 物理块，真正跨显存、内存和 SSD 分层迁移的是 K/V 张量数据，而不是页表本身。
但只理解“Master 管元数据、Client 传数据”仍然不够。本文沿 Mooncake 固定版本 bfca1ce2af8419c50dc8d464820a95d97d43c930 追到 store_c.cpp、real_client.cpp、client_service.cpp、master_service.cpp 与 transfer_task.cpp，解释每个设计判断究竟由哪段代码实现。
导言
长上下文把 KV cache 从一块 GPU 临时张量，逐步推成了跨 GPU、CPU、SSD、NIC 和远程内存流动的分布式状态。表面上，近几年的论文分别在做分页、卸载、压缩、P/D 解耦、远程复用或直通访问；从更抽象的角度看，它们其实都在回答同一个问题：如何分布式地管理一批有依赖、可重算、持续增长且必须按时到达的数据？
本文以放置、组织、传输为主轴，把命名、依赖、正确性、调度与故障恢复作为支撑平面，纵向回看 2022—2026 年的演化，横向比较七类设计范式，并推演下一阶段可能出现的三条路径。研究截止日期为 2026-08-24。