在昇腾通信栈的第五轴中，PCIe、片内 NoC、HCCS、RoCE 与 UnifiedBus 被放在同一行。看到这些概念，一个很自然的疑问是：它们为什么没有统一？是不是每一种新互联，都是为了解决上一代的缺陷，并最终取代前者？

这个问题抓住了技术演进，却预设了一条并不存在的替换链。这些概念分别工作在芯片内部、服务器 I/O、节点内 Scale-Up 和集群 Scale-Out 等不同范围，提供的事务与内存语义也不相同。本文从无法绕开的物理约束出发，沿历史纵轴梳理它们出现的契机，再用同一组维度比较其设计取舍，最后说明：什么时候一种新思想只需要增加后端，什么时候它会形成新的编程契约和代码仓。

在昇腾通信栈的第二轴中，HCOMM、SHMEM Runtime、IPC、CANN VMM 与 Fabric Memory 被放在同一个“资源、地址与运行时”区域。它们都在帮助程序访问另一进程、另一设备甚至另一节点的内存，因此很容易被理解成五套重复方案：既然目标相同，为什么不统一成一套 API？

这个问题真正触及的是系统抽象如何演进。五个概念共享“让数据可达”的目标，却分别承诺资源组织、PGAS 编程、进程共享、虚拟内存管理和内存池化；它们不是五代同类技术，而是从五个不同矛盾长出的责任边界。本文从第一性原理拆出这些不可互换的契约，再沿时间纵轴和能力横轴梳理其提出契机、公开时机、新仓库形成条件与未来收敛方向。

《Ascend Communication Stack》把 HCCL、HiXL、CANN SHMEM 和 Mooncake UBShmem 放在第一轴。既然它们最终都在昇腾设备之间搬数据，也会复用相似的 Runtime、内存和硬件资源，一个很自然的问题是：为什么没有统一成一个库？

关键不在名字，也不在 payload 最后走 HCCS、RoCE 还是 UB，而在调用者究竟声明了什么契约。HCCL 声明 collective，HiXL 声明一批 buffer transfer，CANN SHMEM 声明 PE 对对称对象的 RMA/AMO，Mooncake UBShmem 则服务项目自己的映射型 KV 快路。本文沿公开时间线还原四条路线的提出契机与设计转折，再横向判断哪些差异必须保留、哪些历史包袱可以收敛。研究截止日为 2026 年 8 月 26 日。

在昇腾通信栈的第四轴里，ACL Copy、LD-ST、MTE、IPC、SDMA、RDMA 与 UDMA 被放在相邻位置。看到这么多搬运相关名词，一个很自然的判断是：它们大概是同一种能力的不同代际，后来者之所以出现，是因为前一代不够好。

这个判断抓住了技术演进的一部分，却把几类不同对象混在了一起。这些概念不是七代同类传输引擎，而是地址能力、操作表达和执行后端在不同距离、粒度与控制路径下的组合。本文从无法绕开的物理成本出发，再沿历史纵轴和技术横轴解释它们为何没有统一，以及什么时候一种新思想才真正值得形成新的代码仓。

昇腾通信栈总图从上到下列出了语义、资源、提交者、搬运引擎和互联五部分。看到五个编号，很自然会追问：它们是否正好对应 OSI 七层、互联网五层或 TCP/IP 四层？答案是否定的。经典网络模型按协议功能分层，这张图则按一次通信如何从程序意图落到字节搬运划分责任。本文把两套分类放到同一张坐标系中，说明哪些位置可以近似对应，哪些位置必须保留“无对应”的边界。

解释 Scratchpad 时，我们很快会遇到一个新问题：数据由 DMA 显式搬入片上 SRAM，但它从 HBM 到计算核心附近的 Scratchpad，究竟经过了什么？答案里反复出现的 NoC，又是什么概念？

这篇文章沿着一次数据搬运，把几个容易混在一起的对象摆回各自的位置：Scratchpad 负责本地存取，NoC 负责片上运输，DMA 负责执行显式搬运。

把 KV Cache 放进 SSD 并不难，难的是让它取回来仍比重新 Prefill 更划算。GPU Direct Storage 已经能让数据绕过 Host DRAM，但每个 I/O 仍由 CPU 发起；Paged KV Cache 又会把一次长前缀恢复拆成海量小而散的请求。SSD 的标称带宽于是还没有用满，GPU 已经先停下来等数据。

Tutti 的核心不是再加一级缓存，而是重写 HBM 与 NVMe 之间的运行时路径：CPU 保留前缀索引和对象映射，却退出逐块 I/O 的数据与控制关键路径；GPU 通过对象化批处理、gio_uring 和 slack-aware 调度直接驱动本地 SSD。读完本文，应该能判断这三部分分别消除了什么瓶颈，以及论文的“接近 DRAM”结论在哪些条件下成立。

一开始我只知道一件事：Mooncake 通过 TENT 接入了 NVIDIA GPUDirect Storage。真正沿代码往下追时，三个问题很快连在了一起：TENT 到底怎样调度一次传输，GDS 向上提供了哪些能力，以及新后端怎样实现同一套契约。

最关键的判断是：TENT 不是 GDS 的一层薄封装，而是负责 Segment、内存注册、后端选择、批次和状态推进的统一运行时；GdsTransport 才负责把 File Segment 请求翻译成 cuFile Batch I/O。 理清这条分工后，submitTransferTasks、cuFileBatchIOGetStatus 和新后端接口会自然落在同一张图里。

一场围绕 OpenAI Jalapeño 推理芯片的讨论提出了一个看似矛盾的问题：专用 AI 计算核心可能比顶级通用 CPU 更规则，为什么 AI 芯片仍然很难做？

两句话可以同时成立。矩阵乘加阵列的局部控制逻辑相对规则，但一款有竞争力的 AI 产品还要跨过微架构、RTL、验证、物理实现、先进封装、内存与互联、编译器、Kernel、运行时、模型适配和客户部署。真正的壁垒没有消失，而是从单个计算核心转移到了整条系统栈及其持续迭代能力。

手里已经有一套面向 NPU 的 NDS send/receive 接口，下一步是把它接入 Mooncake。乍看之下，这只是把 GDS 的 cuFile* 调用替换为 NDS API；但沿源码真正走一遍后，会遇到两个容易误判的事实：Mooncake 同时保留了新旧两代 GDS 路径，而 Mooncake Store 的磁盘副本读写目前又绕开了它们。

因此，接入点不应先选旧 NVMeoFTransport，也不能只新增一个 transport 就宣称 Store 已经获得 NPU 直读 SSD。更稳妥的路径是：先把 NDS 实现为 TENT 的 NdsTransport，复用其选择、批次、状态与回退机制；再单独改造 Store 的文件副本路径。