昇腾超节点与灵衢互联：Scale-Up、UnifiedBus、Full Mesh、Clos、UBoE

超节点的核心并不是“把很多服务器连起来”，而是把更多加速器纳入一个更紧耦合、低时延、高带宽的 Scale-Up 计算域，使模型能够像使用一台更大的计算机一样使用更多计算、内存与通信资源。

整理日期：2026-09-10。本文将通用网络原理与昇腾公开方案分开描述；具体链路带宽、卡数和拓扑随产品代际与 SKU 变化，应以对应版本产品文档为准。

1. 为什么大模型开始需要“超节点”

单颗 NPU 的能力受三个基本边界约束：

• 计算吞吐：Tensor/Vector 单元每秒能完成多少计算；
• HBM 容量与带宽：模型权重、KV Cache、激活和临时数据能否容纳并快速搬运；
• 片间互联：模型被切到多颗 NPU 后，数据交换是否足够快。

当模型规模超过单卡容量，或者希望通过 Tensor Parallel、Pipeline Parallel、Expert Parallel 等方式提升吞吐时，通信会直接进入关键路径。

一个简化的端到端时间模型是：

$$T \approx T_{compute}+T_{memory}+T_{communication}+T_{synchronization}+T_{scheduler}$$

如果计算单元越来越快，而跨卡通信没有同步提升，那么系统就会遇到所谓 Communication Wall（通信墙）。

超节点的本质就是尽可能缩小“远端 NPU”与“本地 NPU”之间的性能鸿沟。

2. Scale-Up 与 Scale-Out：不要只按“机器数量”理解

Scale-Up

Scale-Up 的目标是扩大一个紧耦合计算域。

它强调：

• 更高片间带宽；
• 更低通信时延；
• 更强的一致资源视图；
• 更高效的细粒度并行；
• 尽可能让跨 NPU 通信接近本机内部互联体验。

GPU/NPU 领域常见的 Scale-Up 技术包括 NVLink/NVSwitch、UALink、UnifiedBus 等。

Scale-Out

Scale-Out 的目标是把多个节点或多个超节点连接成更大的集群。

它通常更强调：

• 可扩展性；
• 路由与网络管理；
• 成本；
• 容错；
• 大规模部署。

传统 HPC/AI 集群常使用 InfiniBand、Ethernet + RoCE 等网络完成 Scale-Out。

一个重要趋势：Scale-Up 和 Scale-Out 的边界正在变模糊。 当 Scale-Up 域从 8 卡扩展到几百乃至上千颗加速器时，它已经具备传统集群规模，但在系统语义上仍试图维持“一个更大的逻辑计算机”。

3. 集群与超节点的区别

可以用一句简化的话记忆：

集群强调“多台计算机协同工作”；超节点强调“让多台物理设备在逻辑上更像一台计算机”。

但“像一台计算机”并不意味着所有资源访问延迟完全相同，也不意味着物理 NUMA 特征消失。

维度	普通 Scale-Out 集群	超节点 / SuperPoD
系统目标	大量节点协作	构建更大的紧耦合计算域
互联	网络级	更接近总线级/Scale-Up 互联
带宽	通常相对低	显著更高
时延	通常更高	强调超低时延
资源语义	节点边界明显	强调统一资源视图和统一编址
适合并行	数据并行、粗粒度任务	TP、EP、MoE、细粒度模型并行

4. 灵衢 UnifiedBus（UB）是什么

华为将 UnifiedBus（灵衢） 定位为面向超节点的统一互联系统。

不要把它只理解成“一根更快的网线”。它覆盖的是从协议、交换、拓扑、内存访问到系统软件协同的一套 Scale-Up 互联体系。

公开资料中强调的方向包括：

• 协议归一：尽量减少不同互联层级之间的协议碎片；
• 统一内存/资源编址：为更大的逻辑计算域提供一致资源视图；
• 大规模组网：从少量 NPU 扩展到数百、上千颗；
• 高带宽、低时延：降低模型并行通信成本；
• 高可靠：Scale-Up 域扩大后，链路和设备故障必须能够被系统处理。

因此，超节点不是纯网络工程，而是：

NPU
+ HBM / Memory Semantics
+ UnifiedBus Link
+ Switch / Topology
+ HCCL / Collective Algorithms
+ Runtime
+ Compiler / Framework
+ Reliability / O&M
= SuperPoD System

5. Full Mesh 是什么

Full Mesh（全互联）的理想形式是每个节点都和其他节点存在直接链路。

若有 $N$ 个节点，完全无向全互联需要的点到点连接数量为：

$$L=\frac{N(N-1)}{2}$$

因此它的优点和缺点都非常明显。

优点：

• 两点间可以直接通信；
• 跳数少；
• 延迟低；
• 路径容易理解。

缺点：

• 链路数量约按 $O(N^2)$ 增长；
• 交换端口、布线、功耗和成本迅速膨胀；
• 很难无限扩大规模。

所以 Full Mesh 非常适合较小规模的紧耦合域，但规模进一步扩大后通常需要分层或交换结构。

6. Clos 是什么

Clos Network 是一种多级交换网络。核心思想不是让每个端点直接连接所有其他端点，而是通过多个交换级构造大量并行路径。

一个典型抽象是：

NPU / Server
↓
Leaf Switch
↓
Spine Switch
↓
Leaf Switch
↓
NPU / Server

Clos 的优势在于：

• 端口数随规模增长更加可控；
• 可以通过增加交换级/交换芯片扩展规模；
• 多路径能够提升双截面带宽；
• 更适合大型集群与超节点。

代价是：

• 通信可能经过更多跳；
• 交换、路由与拥塞控制更复杂；
• 如果存在 Oversubscription，实际带宽可能低于理想值。

7. 为什么会出现 Full Mesh + Clos 混合结构

工程上不存在“Full Mesh 一定优于 Clos”或相反的结论。

一种自然做法是：

小范围：Full Mesh / 高直接性互联
↓
更大范围：Clos / 多级交换

这样可以同时获得：

• 小域内低时延；
• 大规模可扩展；
• 可接受的交换芯片和链路数量。

因此看到“Full Mesh + Clos”时，应把它理解为局部直接互联 + 全局分层交换的组合思想，而不是两个互斥拓扑被机械拼在一起。

8. RoCEv2 到底是什么

RoCE = RDMA over Converged Ethernet。

RoCEv2 将 RDMA 流量封装在 UDP/IP 之上，因此可以跨三层 IP 网络路由。它的价值是：在以太网生态上获得接近 RDMA 的低 CPU 占用、低时延和高吞吐数据传输能力。

更准确的说法是：

RoCEv2 是以太网上的 RDMA 传输协议体系，不宜简单称为“魔改以太网”。

AI 集群使用 RoCE 时还需要处理：

• 拥塞控制；
• PFC/ECN 等无损或准无损网络机制；
• 流量工程；
• 多路径；
• 拓扑感知集合通信。

所以 RoCE 性能不是“网卡带宽是多少”一个数字能够决定的。

9. UBoE 与 RoCE 的关系

UBoE 可理解为 UnifiedBus over Ethernet：把 UnifiedBus 的能力延伸到以太网承载环境。

这类技术的战略意义在于：

SuperPoD 内：极致 Scale-Up
↓
SuperPoD 间：借助 Ethernet 继续扩展

它试图减少传统 Scale-Up 与 Scale-Out 之间的“协议墙”，让更大规模的集群保持更统一的通信语义。

不过具体 UBoE、RoCE 和 UnifiedBus 的协议栈边界、可共享硬件能力及不同产品版本的支持范围，应以对应产品文档为准，不宜把它们写成完全等价协议。

10. HCCL 位于哪一层

HCCL 是 Huawei Collective Communication Library，负责把模型所需的通信语义映射到实际互联网络。

上层框架通常关心：

AllReduce
AllGather
ReduceScatter
AllToAll
Broadcast
Send / Recv

HCCL 则需要进一步决定：

• 哪些 NPU 参与；
• 走什么拓扑；
• 如何切分数据；
• Ring / Tree / Mesh / Hierarchical 等算法如何选择；
• 通信与计算怎样重叠；
• 故障如何处理。

因此可以把整个链路理解成：

PyTorch / MindSpeed / verl
↓
Distributed Parallel Strategy
↓
HCCL Collective
↓
UnifiedBus / HCCS / RoCE / Ethernet
↓
Physical Link

11. AI 基础设施的三个核心要求

你课堂笔记中的总结很有价值，但需要稍微精确化。

11.1 大算力下的高有效利用率

训练中常用 MFU（Model FLOPs Utilization）：

$$MFU=\frac{模型理论所需 FLOPs / 实际时间}{硬件峰值 FLOPs}$$

它反映训练任务能把多少峰值计算能力真正转化成模型计算。

但在 LLM 推理，尤其 Decode 阶段，经常受 HBM 带宽、KV Cache、Batch Size、调度、通信限制，因此不能只用 MFU 衡量系统。

推理更常关注：

• TTFT；
• TPOT / ITL；
• Tokens/s；
• Requests/s；
• P50/P95/P99 Latency；
• HBM/Network Utilization；
• 单位功耗/成本吞吐。

11.2 大并发下的低时延

推理系统需要同时处理：

• Prefill 与 Decode 混部；
• Continuous Batching；
• KV Cache 分配；
• 请求排队；
• 多租户资源竞争。

因此“大并发低时延”本质是 Scheduler + Memory + Kernel + Communication 的联合优化问题。

11.3 大规模下的高可靠

当系统从 8 卡扩大到 1024 卡时，即使单卡故障率很低，系统层面的故障出现频率也会上升。

所以超节点必须考虑：

• 链路冗余；
• 故障检测；
• 通信重路由；
• Checkpoint / Recovery；
• Device 隔离；
• 任务迁移；
• 可观测性。

规模越大，可靠性越不是附加功能，而是性能的一部分。

12. 对 LLM Inference 最重要的理解

对推理来说，是否需要跨多个超节点，并不由“推理天然组网要求低”决定，而取决于模型、KV Cache、并发、并行策略和业务 SLO。

例如：

• 中小模型可以完全放在一个超节点内，优先避免跨节点通信；
• 超大 MoE、超长上下文、海量并发 KV Cache 可能需要多个超节点；
• Prefill/Decode 分离后，节点之间会产生 KV 或中间状态传输；
• 多副本 Serving 更偏 Scale-Out，而单个超大模型实例更依赖 Scale-Up。

因此真正的问题不是“推理需不需要多超节点”，而是：

应该把哪些并行维度留在高速 Scale-Up 域内，哪些维度可以放到 Scale-Out 域？

这正是现代 LLM Serving 系统设计的核心问题之一。

13. 关联阅读

AI Infra 为什么必须懂硬件体系结构：从 MFU 到 Full Mesh 与 Clos 超节点网络

昇腾 950 与 Atlas SuperPoD：从计算架构、存储互联到大模型推理优化

参考资料

• Huawei SuperPoD / UnifiedBus, MWC 2026
• Huawei Atlas 950 SuperPoD, WAIC 2026
• Ascend Atlas 950 SuperPoD 产品页
• HCCL 开源仓库

2026-09-16 补录：910C 单机通信、SDMA 与 RDMA

来源：9 月 15 日关于“单机八卡是否靠灵衢”“HCCS 与灵衢关系”“SDMA/RDMA”的提问。没有取得服务器完整拓扑，以下为分层理解。

HCCL 是通信软件库；HCCS、PCIe、RoCE 等描述具体互连链路；SDMA/RDMA 描述数据移动方式，不能直接把这些词放在同一层比较。官方通信分析文档将 SDMA 链路分为 HCCS 与 PCIe，并分别统计通信、同步和等待时间。官方通信分析说明

SDMA 在这里可理解为通过相关硬件路径执行直接内存搬运；RDMA 是远程直接内存访问，常见网络承载包括 RoCE。RDMA 不意味着建立连接、注册内存、提交操作和同步全部不需要软件参与，也不能保证任意设备缓冲区零拷贝可达。

当前官方 profiler 数据定义把 SIO、HCCS_SW、UB、UBoE 等列为不同链路类型，并另列 transport type，说明拓扑路径与传输方式是两个维度。官方 profiler 字段定义

灵衢是体系级互连概念，不能仅凭“910C”就断言所有卡间流量走某一种链路。单模组 Die 间、模组间、节点间是不同路径；应核对实际 SKU、拓扑输出与通信 trace。若输出显示 HCCS_SW 或 SIO，就按对应设备对分析，不以服务器营销名称替代事实。

建议先保存 npu-smi 设备映射和该版本支持的拓扑查询输出，再与 HCCL rank 映射、profiling 的 src/dst rank、linkType、transportType 对照。跨节点可达的管理网也不自动证明设备数据网通信可用。

关联：性能分析实践。

2026-09-17 增量：NPO、Hi-ONE 与光交换的边界

问题起点：你读到昇腾 960 超节点发布，追问 NPO、Hi-ONE，以及光是否只适合一对一连接。资料核查于 2026-09-18。

华为 9 月 17 日公告将 Hi-ONE 定义为 NPO（Near-Packaged Optics）形态的光互联产品，标称单引擎 7.2T 传输容量，并介绍基于灵衢与 Hi-ONE 的昇腾 960 超节点。这些是厂商发布信息，不是本次实测；传输容量也不是单卡模型推理吞吐。华为官方公告

放近光引擎解决什么

NPO 的理解重点是封装附近的光电互连布局：缩短高速电连接距离，同时处理密度、功耗、散热和可维护性。不能仅凭“光”推断网络时延为零，也不能把 NPO、CPO 和前面板可插拔光模块当成同一封装方式。

链路与交换是两个维度

点到点光链路可以连接电子交换机，电子侧完成逐包转发、排队和调度；光路交换也可以连接不同端点，但粒度和重配置特性与逐包电子交换不同。因此“光只适合一对一”混淆了单条链路与网络拓扑，“全光组网”也不自动表示所有缓存和控制逻辑都变成纯光实现。

上述为分层解释，不是对 Hi-ONE 内部全部电路的反向工程。评价对推理的收益仍需看通信消息大小、并行组、拥塞和真实拓扑，不能从光引擎容量直接推出某模型 TPOT 改善。

2026-09-18 增量：比较昇腾与NVIDIA超节点时统一尺度

用户追问960系列与NVIDIA方案，并质疑“NVIDIA多卡互联较弱”的笼统说法。这个质疑成立：不能从单一超节点总设备数推导一家厂商的多卡能力强弱。

分别比较：单芯片算力与内存、单设备通信注入带宽、低时延scale-up域规模、跨域scale-out拓扑、故障隔离、软件通信效率、整机功耗和相同模型负载下的有效吞吐。每个数字都要标注单向/双向、聚合/单端、稀疏/稠密及数据类型。

华为960超节点公告与NVIDIA GB200 NVL72产品页是厂商资料入口（核查2026-09-20）。后者提供NVLink机架系统，已足以说明“NVIDIA仅能靠弱跨机网络拼卡”不是准确描述。GB200不是Rubin，不能拿GB200指标冒充Rubin；此次不补写未核实的960DT/Rubin规格和交付时间。

真正适合你的比较是固定模型、量化、输入输出长度、并行布局及服务SLO后，看Attention/EP/KV传输分别被什么限制，再判断硬件拓扑是否适配。发布规模不是已经交付的实验规模。