
目录
-
- 本文你会看懂什么
- 先用一句话解释
- 先看报告里的技术边界
- 一、先区分两条路径:数据路径和控制路径
- [二、DMA、RDMA、Load/Store 的边界](#二、DMA、RDMA、Load/Store 的边界)
- 三、统一地址空间的核心组件
- [四、CXL 在这里承担什么角色](#四、CXL 在这里承担什么角色)
- [五、Fabric 化之后,内存变成资源池](#五、Fabric 化之后,内存变成资源池)
- 六、操作系统和运行时必须参与
- 七、统一内存能力的指标化
- 八、工程判断清单
- 九、总结
- 核心术语表
本文基于以下三份报告进行汇总、解释和二次整理:
- 华为《超节点发展报告
- 中兴《超节点技术白皮书
- H3C《超节点技术白皮书》
本文你会看懂什么
- 超节点为什么要把问题从"高速通信"推进到"统一地址空间"和"内存访问语义"。
RDMA、DMA、Load/Store不是谁替代谁,而是分别位于不同的数据访问层次。CXL、MMU、IOMMU、Linux 内核和资源池化,如何影响未来超节点的软件栈设计。
上一篇讨论了 Scale-Up 和 HBD,重点是把高频通信留在更高带宽、更低时延的域内 。这一篇继续往下拆:当设备已经连得足够近,下一步要解决的是"数据如何被访问"。
先用一句话解释
统一内存编址 的意思是:系统给多张 GPU/NPU、CPU 内存、扩展内存等资源建立一套统一的地址视图 ,让设备访问数据时,可以先用"地址"描述目标数据,再由硬件、协议、驱动和运行时去判断这块数据到底在哪个设备、哪层内存、应该走哪条访问路径。
它要解决的不是"所有内存真的变成同一块物理内存",而是解决一个更底层的问题:在多设备系统里,数据不能只靠"你发给我、我再拷贝一份"来协作,系统需要有能力让远端内存也变成可寻址、可管理、可访问的资源。
可以先用一个小例子理解。
| 场景 | 传统分布式访问 | 统一内存编址后的目标 |
|---|---|---|
| GPU 0 想用 GPU 1 上的一段数据 | GPU 0 不能直接理解 GPU 1 的本地地址,通常要通过通信库发起传输,把数据拷贝或拉取过来 | GPU 0 可以通过统一地址模型描述要访问的数据,底层负责把这个地址翻译到 GPU 1 的目标内存 |
| 地址的含义 | 每张卡有自己的"地址本",同一个地址值在不同卡上可能指向不同地方 | 多设备共享一套更高层的地址解释规则,地址可以被翻译成"哪个设备 + 哪块内存 + 哪条路径" |
| 编程模型 | 开发者更关心发送、接收、拷贝、同步 | 开发者更希望按访问内存的方式组织部分数据协作 |
这里有一个很重要的边界:统一内存编址不等于访问远端内存就和访问本地 HBM 一样快,也不等于所有缓存一致性问题自动消失。它只是把多设备协作从"显式搬数据"往"按地址访问数据"推进了一步。
所以,统一内存编址可以简单理解为:先统一地址,再讨论访问;没有统一地址,远端数据就很难从系统资源变成可编程资源。
从工程角度看,超节点里的统一内存编址也不是一句"显存共享"。它至少包含三层问题:
| 层次 | 关键问题 | 典型技术对象 |
|---|---|---|
| 地址层 | 远端内存如何被寻址 | 全局地址、MMU、IOMMU、地址翻译 |
| 访问层 | 设备如何读写远端数据 | DMA、RDMA、Load/Store、CXL.mem |
| 管理层 | 内存资源如何分配、隔离和回收 | OS、驱动、运行时、资源池、调度器 |
所以,统一内存编址真正讨论的是一个系统问题:在多 GPU/NPU、多内存层级、多互联协议并存时,如何把"数据在哪里"和"如何访问它"抽象成可管理、可调度、可观测的基础能力。
先看报告里的技术边界
华为报告第 15 页把超节点的基础特征概括为超大带宽、超低时延互联和内存统一编址。
报告以昇腾 384 为例,给出一个很有参考价值的量级
相比传统服务器架构,通信带宽提升 15 倍,单跳通信时延从 2 微秒降到 200 纳秒;域内 AI 芯片支持内存统一编址,AI 芯片可以用内存语义直接访问其他 AI 芯片内存。
中兴报告第 10 页进一步把统一内存编址和访问方式讲得更明确:
统一地址是区别普通分布式集群的重要前提;GPGPU 倾向使用
Load/Store内存语义,DSA GPU 则更多使用 DMA 消息语义。
换句话说,统一内存并不等于只有一种访问方式,而是要在一个地址模型下同时容纳内存语义和消息语义。
把两份报告放在一起看,统一内存编址至少要满足三个条件:
| 条件 | 工程含义 |
|---|---|
| 带宽和时延足够接近本地访问 | 否则远端内存只能做冷数据,无法进入关键路径 |
| 地址空间可以统一解释 | 否则上层仍要显式维护远端地址和拷贝关系 |
| 访问语义能被软件栈承接 | 否则硬件支持不会自然转化为框架能力 |
一、先区分两条路径:数据路径和控制路径
讨论远端内存访问时,最容易混在一起的是数据路径和控制路径。
数据路径关心数据怎么走。
- 从哪块内存读?
- 经过 PCIe、RDMA、CXL 还是 Scale-Up 互联?
- 是否经过 CPU?
- 是否经过交换芯片?
- 带宽、时延、重传和一致性开销是多少?
控制路径关心访问怎么被允许和管理。
- 内存是否已经注册?
- 地址如何映射?
- 权限如何检查?
- 哪个进程、容器、租户可以访问?
- 故障后映射如何恢复?
- 调度器是否知道这块内存的拓扑位置?
传统 RDMA 优化了数据路径,特别是减少 CPU 参与和内存拷贝。但统一内存编址要进一步处理控制路径:地址空间、权限、隔离、一致性、迁移和资源回收。
H3C 报告中的 GPU Direct RDMA 架构图可以作为传统高速访问路径的参照。

图源:H3C《超节点技术白皮书》第 247 页,图 164。
GPU Direct RDMA 的价值在于让网卡直接和 GPU 显存交互,减少 CPU staging copy 。但它仍然需要内存注册、访问权限、队列、完成通知等机制,编程和运行时模型仍然是显式通信。
统一内存编址要解决的是:能不能把更多远端资源纳入统一地址和统一调度模型,让上层框架不必把每一次跨设备访问都显式组织成通信流程。
二、DMA、RDMA、Load/Store 的边界
这几个词经常一起出现,但它们不是同一个维度。
| 模型 | 核心动作 | 典型控制对象 | 适合场景 | 技术风险 |
|---|---|---|---|---|
DMA |
设备按描述符搬运一段内存 | 源地址、目的地址、长度、完成状态 | 本机设备间大块搬运 | 需要显式编排,粒度偏粗 |
RDMA |
通过网络直接读写远端内存 | MR、QP、CQ、rkey、队列深度 | 跨节点高速通信 | 内存注册和访问控制复杂 |
Load/Store |
以读写地址方式访问目标内存 | 地址转换、权限、一致性、缓存 | 紧耦合设备协同 | 对协议、MMU、OS 要求更高 |
一个更工程化的判断是:
- 如果你在写通信库,
RDMA是你显式发起的通信操作。 - 如果你在看加速卡互联,
DMA是数据搬运的基础机制之一。 - 如果你在设计超节点编程模型,
Load/Store是希望暴露给上层的访问语义。
H3C 报告提到
AI 工作负载会推动系统从传统
Read/Write或DMA模型走向统一Load/Store内存访问。
这里的重点不是 RDMA 失效,而是 AI 负载的访问粒度和协同复杂度在提高,显式通信模型会不断把复杂度推给框架和运行时。
三、统一地址空间的核心组件
一个设备想访问另一个设备的内存,最少要经过几类组件。
| 组件 | 作用 |
|---|---|
| 请求端设备 | 发起读写请求,例如 GPU/NPU |
| 地址转换单元 | 把虚拟地址或全局地址转换为目标设备可识别地址 |
| 权限检查 | 确认请求方是否允许访问目标内存 |
| 路由/交换结构 | 把请求送到目标设备或内存池 |
| 目标内存 | HBM、DDR、CXL 内存、远端内存池 |
| 完成/异常处理 | 返回数据、确认写入或报告错误 |
H3C 报告中的 UALink 地址转换图很适合看这条路径。

- 交换机访问对端内存,使用 GVA(Guest Virtual Address)地址发起访问。
- GVA 地址经本地 MMU 转为为网络物理地址(NPA,NetWork PhysicalAddress)
- NPA 地址在对端 MMU 转换为本地系统物理地址(SPA,System Physical Address)
图源:H3C《超节点技术白皮书》第 89 页,图 67。
从这张图可以抽出一个技术要点:统一内存编址的关键不是"所有设备共用一个大数组",而是请求端、地址转换、互联协议和目标端都要接受同一套地址与权限模型。
如果缺少这个模型,所谓远端访问仍然会退化成显式拷贝。
四、CXL 在这里承担什么角色
CXL 的重要性在于,它把设备互联、内存扩展和一致性语义放进一个更标准化的框架里讨论。
H3C 报告展示了 CXL 数据读取过程。

CXL 的数据读取过程,需进行多次 Snoop 报文(红圈)交互来确认数据一致性(过程解读详见 CXL 章节)
图源:H3C《超节点技术白皮书》第 90 页,图 68。
从技术分享角度,CXL 至少可以拆成三个关注点:
| 关注点 | 技术意义 |
|---|---|
| 设备枚举和配置 | 复用 PCIe 生态,让设备可以被系统识别和管理 |
| 内存访问语义 | 让主机和设备之间形成更清晰的内存访问关系 |
| Fabric/池化 | 让内存资源从单机附属设备走向可组合资源 |
H3C 报告中的 CXL 资源池化图,说明 CXL 不只是单设备连接,而是面向资源池化。
下图是使用 CXL 技术实现的计算资源池化

图源:H3C《超节点技术白皮书》第 102 页,图 73。
在超节点语境下,CXL 的价值不一定是替代 GPU 间 Scale-Up 互联,而是补齐内存层级:
- 本地 HBM 承载最热数据。
- 本地 DDR 承载较大容量数据。
- CXL 内存承载可扩展和可池化内存。
- 远端内存池承载更大范围资源调配。
这对推理尤其重要,因为 KV Cache 会持续挤压 HBM 容量。
五、Fabric 化之后,内存变成资源池
单个 CXL 设备解决的是扩展问题,CXL Fabric 解决的是组织问题。

当多个 Host 和 Device 通过 CXL Switch 组成 Fabric 时,整个 Fabric 的管理需要一个专属的管理组件 FM(Fabric Manager)进行管理。如上图,Fabric 由一个或多个互联的 CXL Switch 组成。Switch 端口可连接至 CXL 主机(Host)端口或 CXL 设备(Dev)。
Fabric 管理器(FM)在 CXL 网络(Fabric)中不可或缺,但角色可以被其他具备类似管理功能的组件替代。
FM 可通过带外对 Switch 网络进行管理。FM 组件也被其他 Scale up 协议借鉴,如 UB 的 UBFM。
FM 的主要功能:
- 负责 fabric 初始化、组件发现,构建拓扑视图,完成链路与参数协商。
- 管控端口绑定、路由配置,协调带宽与内存资源,支撑全局地址映射。
- 监控 fabric 内组件与链路状态,处理异常事件(包括热插拔),保障传输可靠性。
- 提供安全管控与标准化 API,实现多组件协同。
图源:H3C《超节点技术白皮书》第 108 页,图 79。
Fabric 化以后,系统要处理的不是"这台机器插了多少内存",而是:
- 哪些计算节点能访问哪些内存池?
- 访问路径经过几跳?
- 访问延迟是否可预测?
- 是否支持动态分配和回收?
- 是否支持租户隔离?
- 是否能在故障后重新映射?
这和云计算里的资源池化很像,但难度更高,因为内存访问比存储访问更敏感。带宽、延迟、NUMA 距离、缓存一致性、故障恢复都会直接影响训练或推理性能。
六、操作系统和运行时必须参与
统一内存编址不能只靠硬件宣称支持。
H3C 报告中提到 Linux 内核对 CXL 的支持,说明这类能力最终必须进入 OS、驱动和资源管理层。

图源:H3C《超节点技术白皮书》第 257 页,图 168。
从系统软件看,至少有四类工作要做:
| 层级 | 需要处理的内容 |
|---|---|
| 内核/驱动 | 设备发现、地址映射、错误处理、热插拔、NUMA 暴露 |
| 运行时 | 内存分配策略、冷热数据迁移、缓存管理 |
| 调度器 | 根据拓扑和内存位置放置任务 |
| 框架 | 感知远端内存代价,避免把热路径放到慢内存 |
如果只有底层硬件能力,而上层框架不可见,统一内存就很难产生实际收益。
比如一个推理任务的 KV Cache 被放到远端内存,但调度器不知道访问路径,Decode 阶段可能每步都走慢路径,首 token 延迟和吞吐都会受影响。
七、统一内存能力的指标化
技术分享里不能只说"支持统一内存",还要问它怎么度量。
| 指标 | 为什么重要 |
|---|---|
| 本地 HBM 带宽和时延 | 热数据访问上限 |
| 同域远端访问时延 | 判断 HBD 内远端访问是否可用 |
| 跨域远端访问时延 | 判断是否适合放冷数据 |
| 地址翻译开销 | 影响细粒度访问性能 |
| 映射更新耗时 | 影响动态迁移和资源回收 |
| 一致性开销 | 影响共享数据访问模型 |
| 错误恢复时间 | 影响长任务稳定性 |
| 多租户隔离能力 | 影响云化和资源池化落地 |
这类指标比"支持 CXL"或"支持统一地址"更有工程价值。
八、工程判断清单
如果要评估一个超节点统一内存方案,可以按下面的问题追问。
| 判断项 | 关键问题 |
|---|---|
| 地址模型 | 是全局地址、虚拟地址映射,还是只做远端 DMA? |
| 访问语义 | 支持消息语义、内存语义,还是完整 Load/Store? |
| 地址转换 | MMU/IOMMU 在哪里,映射缓存如何失效? |
| 一致性范围 | 是否需要缓存一致性,一致性边界多大? |
| 软件暴露 | Linux、驱动、运行时、调度器是否可见? |
| 分层策略 | HBM、DDR、CXL、远端内存如何分层? |
| 故障模型 | 链路、内存池、映射异常后如何恢复? |
| 性能基线 | 是否有本地、同域、跨域访问时延和带宽数据? |
这也是区别"技术概念"和"工程能力"的地方。
只要不能回答地址模型、访问语义、软件暴露和性能基线,统一内存编址就还停留在宣传层。
九、总结
超节点里的统一内存编址,本质上是把 AI 基础设施从"显式通信系统"推进到"可寻址资源系统"。
RDMA 让跨节点通信更快,DMA 是设备搬运数据的基础机制,Load/Store 则代表更紧耦合设备协同下的访问语义。它们不是简单替代关系,而是叠在不同层次上。
真正可用的统一内存能力,需要硬件、协议、OS、驱动、运行时和调度器共同完成:
- 硬件负责链路、地址转换和访问路径。
- 协议负责语义、路由和一致性边界。
- OS 和驱动负责资源发现、映射和错误处理。
- 运行时和调度器负责冷热数据放置和任务拓扑映射。
下一篇我们从训练侧看大模型并行通信,重点不是解释 DP/TP/PP/EP/CP 是什么,而是拆它们在网络里对应什么通信原语和拓扑约束。
核心术语表
| 术语 | 含义 |
|---|---|
DMA |
设备直接搬运内存数据的机制,适合大块显式数据传输。 |
RDMA |
跨节点直接读写远端内存的机制,减少 CPU 参与和拷贝。 |
Load/Store |
更接近普通内存读写的访问语义,需要地址转换、权限和一致性支持。 |
MMU |
负责地址转换和访问权限控制的硬件单元。 |
CXL |
面向设备、内存扩展和资源池化的互联协议体系。 |
CXL Fabric |
将多个主机、设备和内存资源组织为可组合资源池的互联结构。 |
IOMMU |
面向设备 IO 的内存管理和地址转换机制,用于隔离和安全访问。 |