讨论服务器通信和交换机优化时，我听到了“反压水线寄存器”。顺着这个词往下问：如果交换机有 512 个端口，需要多大的缓存、花多少钱？既然端口能通过硬件互通，为什么还会拥塞？本文从一个两路汇聚的例子出发，串起水线、缓存容量、SRAM/DRAM 和 Clos。读完后，可以分清它们各自解决的问题，也能判断一个容量或价格数字究竟在什么条件下成立。

一次 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 产品已经交付同样数字。

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

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

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

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

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

“AIV 直驱”是昇腾通信优化语境中的常见简称。最稳妥的理解是：让运行在 AIV（Vector Core）上的 Kernel 直接编排和提交通信工作，避免由 Host CPU 或 AICPU 为每一次细粒度传输继续充当中间调度者。它优化的是通信控制路径；真正搬运字节的仍是 HCCS、RoCE、RDMA 或 URMA 等通信机制与硬件。