OpenURMA Unified Bus

导言

一次 64 B 远端读取,数据在链路上只需要约 200 ns,端到端却可能超过 2 μs;当 1024 个本地发起上下文连接 1024 个远端端点时,按 Queue Pair(QP)组织的连接状态又会膨胀到约 537 MB。OpenURMA 认为这不是某个 RDMA Kernel 写得不够快,而是 QP over PCIe 这一抽象同时制造了状态乘积和外围设备往返。

OpenURMA 是 Unified Bus(UB)传输层与事务层的 clean-room 开放实现。它用 Jetty / TP Channel 拆开应用状态与可靠传输状态,把 UB Controller 放到片上总线,并为短同步操作提供绕过 Work Queue 的 Load/Store 路径。本文沿这条依赖链解释方案,同时把 500 ns / 2186 ns 放回论文的模拟条件:这组结果证明新抽象值得继续做成硅,不等于 Ascend 950 或任意商用 UB 产品已经交付同样数字。

Read more

Ascend Communication Runtime Evolution

导言

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

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

Read more

Ascend Data Movement Evolution

导言

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

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

Read more

Ascend Communication Stack

导言

华为昇腾通信资料最容易制造一种错觉:DMA、HCCS、HCCL、SHMEM、Fabric Memory 和 AIV 直驱仿佛是一摞可以从上到下整齐堆叠的软件层。实际并非如此。这些词分别回答“谁组织通信、谁建立地址、谁提交任务、谁搬数据、数据走哪条物理链路、对端是否参与”中的不同问题。有些是库,有些是协议或硬件,有些只是数据路径属性;把它们画在同一层,关系一定会错。

本文把历史纵轴和技术横轴合并:先建立一张总地图,再逐个概念给出小白版与专业版解释,最后核对公开仓库的首次可见提交、立项目的、硬件范围、迁移和待废弃状态。研究截止日为 2026 年 8 月 26 日

Read more

Memory Semantics vs RDMA

导言

MPI、RDMA 和内存语义都能搬运数据,但它们让应用表达的是不同对象:MPI Point-to-Point 表达 rank、tag 和消息,RDMA Verbs 表达 QP、WQE 和完成记录,内存语义则尽量让应用只表达 地址、长度、读写方向和数据依赖

后一种方式的收益不是“凭空消灭通信”,也不是“任何场景都比 RDMA 带宽高”。它真正改变的是通信契约:把外围队列事务下沉为更接近计算流水的地址访问与 tile 可见性,使 Scale-Up 域内的短操作、细粒度生产消费和异步流水更容易表达。

Read more

Memory-Semantic TransferQueue

导言

能否把 MOV A, B 的直觉扩展到跨 device、跨节点甚至跨超节点:应用只给出源地址和目标地址,系统自动选择 HCCS、RDMA 等路径,把大 tensor 直接搬到消费者附近?可以把它做成 verl TransferQueue 的可插拔数据面,但不应把这件事直接称为“MTE 跨超节点”。MTE 是 Ascend 内存层级和部分 HCCS 路径上的搬运引擎;真正向应用提供远端地址、单边 put/get、注册和完成语义的是 SHMEM、MemFabric 一类软件层;样本字段、ready、consumed、staleness 和恢复仍应由 TransferQueue 管理。

Read more