针对菊厂创新的AI网络架构UB-Mesh的个人看法
最近，不少业内朋友问及我对菊厂创新的 AI 网络架构 UB-Mesh 的看法，现将个人思考梳理如下，供业界同仁探讨交流。一、设计初衷：将降低网络成本作为首要目标AI 基础设施的硬件成本结构看，GPU 支出在整体投入中占绝对主导地位，而网络设备投入占比通常低于 15%。这一成本构成决定了设计 AI 网络的核心要务 —— 必须为 GPU 构建高带宽通信链路，避免因数据交换时延过长导致昂贵的计算资源因等待数据而空闲。其实，DeepSeek 通过一系列软硬件协同设计与工程优化实现 “通信与计算重叠”，其底层逻辑正是围绕这一核心目标展开，即最大化 GPU 利用率、规避算力空转浪费。与业界主流方案不同，UB-Mesh 的设计核心聚焦于降低网络成本，主要通过减少交换机和光模块的用量，并尽可能采用交换容量较低的低成本交换机（即文中的 low-radix switches, LRS）来实现。虽然论文未明确提及，但为了达成这一目标，UB-Mesh 在其他设计目标上做出了妥协。二、拓扑结构：采用 nD-FullMesh 而非 CLOS结构当前业界普遍采用 CLOS 或胖树（Fat-Tree）拓扑结构来构建可扩展的Scale-out网络，甚至Scale-up网络。Scale-out网络采用CLOS结构已成业界广泛共识，自不必说。下面看看 NVIDIA 的Scale-up网络架构演进路线：
[*]GPU 服务器内部 GPU 互联，从DGX-2时代开始，已经从P2P Full-Mesh（点对点全连接升级为通过NVSwitch芯片互联；
[*]超节点方案比如GB200/GB300 NVL72进一步将计算托盘（Compute Tray）内以及跨计算托盘的 GPU 互联统一通过外部 NVSwitch 交换机实现。
通过交换芯片互联相对P2P Full-Mesh互联，核心优势在于：
[*]最大化 GPU 间可用带宽，而非平均分配给所有互联的 GPU；
[*]灵活适配多样化的通信模式（如All-Reduce、All-to-All、P2P等）。
正因如此，业界主流超节点 Scale-up 网络方案均放弃计算托盘内部点到点全连接架构，转而通过交换芯片互联 (注：菊厂当前的CloudMatrix384超节点的Scale-up网络亦是如此)。
UB-Mesh 论文明确承认：
“Traditional datacenters usually adopt the Clos architecture, which employs two or three tiers of switches to symmetrically connect NPUs/CPUs, offering high performance and adaptability to various traffic patterns.”
（传统数据中心通常采用 CLOS 架构，通过两层或三层交换机对称连接 NPU/CPU，提供高性能并适配多种流量模式。）但其因以降低网络成本为首要设计目标，所以选择在单板（也就是计算托盘）内沿用传统的P2P Full-mesh互联方式，并将该互联方式从单板内的第一维（1-D）全链接扩展至机柜间的第三维（3-D）全链接。
由此带来的直接挑战：对动态、复杂流量模型适应性较差，需预先根据拓扑设计流量访问关系。对此，该论文也明确承认：
“Although UB-Mesh’s hardware architecture design matches the traffic patterns of LLM training, running workloads on such a hierarchical AI cluster may suffer from low utilization if training tasks are not effectively distributed across computing resources.”（尽管 UB-Mesh 的硬件架构设计匹配大语言模型训练的流量模式，但在层次化的 AI 集群中运行工作负载时，若训练任务未有效分布于计算资源，可能导致利用率低下。）三、降本手段：以 GPU 资源消耗换交换机资源节约UB-Mesh 通过第一维（单板内）全连接、第二维（机柜内）全连接、第三维（跨机柜行列）全连接的嵌套全连接网络拓扑，减少交换机数量和光模块使用量，实现 AI 集群硬件成本优化。其核心逻辑在于：以消耗 GPU 的资源为代价，减少交换机硬件投入。该论文提到：
“Since each NPU is also a router, and the entire system contains a large number of NPUs, to conserve NPU hardware resources, the routing system must efficiently handle routing-table lookups and forwarding operations.”
（由于每个 NPU 同时作为路由器，且系统包含大量 NPU，为节省硬件资源，路由系统必须高效处理路由表查询和转发操作）。当然，这一策略也旨在解决传统点到点全连接拓扑的固有缺陷 —— 即带宽被固定平均分配给所有互联节点，导致对动态且复杂流量模式的适应性不足。
其实，这一思路与微软中国研究院早些年提出的 DCell、BCube（如上图） 数据中心网络架构非常类似，例如BCube 通过利用服务器 CPU 中转数据替代部分或全部交换机。顺便说一下，BCude也采用了UB-Mesh用到的源路由思路来实现数据转发。而 UB-Mesh 以更昂贵的 NPU 资源替代相对廉价的交换机进行数据的中转。
四、路由策略：依赖非最短路径算法在 nD Full-mesh拓扑中，两点之间存在多条不同长度的路径。UB-Mesh 提出需同时利用最短路径（Shortest Path）与绕行路径（Detour Path）以最大化带宽利用率。
该论文中指出：
“In the nD-FullMesh topology, between two endpoints, there are several possible paths with diverse distances. The system should enable the use of non-shortest paths to maximize bandwidth utilization across the network.”
（在 nD 全连接拓扑中，两节点间存在多条不同距离的路径，系统需支持使用非最短路径以最大化全网带宽利用率。）该多路径转发策略的代价：
[*]多路径转发路由计算复杂度呈指数级上升。如下图所示，源节点需在多个维度的长度不同、且部分链路重叠的Detour路径以及最短路径上实现非常复杂的负载均衡算法；
[*]不同路径（如最短路径与绕行路径）的传输延迟差异显著，加剧集合通信中极力避免的“木桶短板效应”，即便是同一机柜内 NPU 间通信延迟可能因路径不同而差异极大。
五、转发机制：依赖源路由（Source Routing）为充分利用长短不等的多路径，UB-Mesh 不得不采用源路由机制。该论文中提到：
“In order to fully utilize the paths provided by APR, one practical way is leveraging the Source Routing (SR) mechanism.”
（为充分利用 APR 提供的多路径，一种可行方式是采用源路由机制。）
相较于 ECMP（等价多路径）或 WECMP（加权等价多路径）负载均衡，源路由方案的复杂度更高：
[*]源路由状态维护量巨大。源节点需维护到达几乎任意目的节点的所有端到端路径状态信息，这点类似Segment Routing域中的头节点的压力；
[*]数据封装开销增加。因需在数据包中携带额外的路径信息以支持源路由，与业界追求的更高效数据封装格式设计趋势，比如博通 SUE 方案中精简的 AIFH 设计，背道而驰。
六、性价比评估：低估硬件与运维成本UB-Mesh 方案的CapEx和OpEx被严重低估：
[*]资本支出（CapEx）：技术封闭性可能导致厂商锁定，最终导致采购成本上升，IB相对以太网更高的采购成本就是明证；
[*]运维支出（OpEx）：复杂拓扑与路由机制增加故障定位、性能调优难度，运维成本显著上升，IB相对以太网更高的运维成本就是明证。
七、网络可靠性：源路由导致收敛性能下降分布式路由转发机制可通过本地快速收敛实现故障切换，而 UB-Mesh 的源路由机制需将故障信息传递至源节点才能触发路径切换。路由收敛速度慢，单点故障可能引发全网流量震荡，进而影响训练任务的连续性。
该论文中提到：“In UB-Mesh, since each node has a deterministic set of communication target, we can accelerate the routing convergence by directly notifying those nodes upon link failures.”（在 UB-Mesh 中，由于每个节点都有一组确定的通信目标，我们可以通过在链路故障时直接通知这些节点来加速路由收敛。）姑且不论在 MoE 的专家并行通信过程中，All-to-All 通信关系往往呈现动态变化特性，即便针对 如All-Reduce 这类预先规划的确定性通信模式，由于 NPU 同时承担数据中转的路由器功能，一旦出现 NPU 故障或其直连链路故障，如何快速将故障信息通知到所有受影响的源路由头端节点，仍是待解决的难题。八、部署运维便利性：4*4 Rack方阵如何布放？
该论文中提到：“We connect four adjacent racks along two dimensions for constructing inter-rack full-mesh because this is the optimal point considering the reach of active electrical cables. Since each rack has 64 NPUs and each pod has 16 racks, a 4D-FullMesh UB-Mesh-Pod contains 1024 NPUs in total.”（我们沿两个维度连接四个相邻的机柜，以构建机柜间全互联网络（Inter-rack Full-mesh），其原因是考虑到有源电缆（AEC）的有效传输距离限制，该连接规模是最优选择。由于每个机柜包含 64 个 NPU，每个 Pod 包含 16 个机柜，因此一个 4D-FullMesh UB-Mesh-Pod 总计包含 1024 个 NPU。）基于当前业界200G/400G AEC最长5～7米的传输距离，在实现4×4机柜方阵全互联的情况下，不同列机柜间还能保留日常维护通道吗？九、总结UB-Mesh 以 “降低网络成本” 为导向的设计，在貌似获得网络硬件成本优势的同时，引入了拓扑僵化、路由复杂、运维困难等系统性挑战。
对于 AI 训练网络而言，在算力成本占比超过 70% 的当下，牺牲 GPU 资源以换取网络硬件成本节约，其性价比值得商榷。技术演进的核心矛盾，始终是在 “方向选择” 与 “细节优化” 间寻找平衡 —— 而方向选择出现偏差可能导致后续需付出数倍代价去补洞填坑。正如该论文开头所提到的， “Although UB-Mesh’s nD-FullMesh topology offers several theoretical advantages, its concrete architecture design, physical implementation and networking system optimization present new challenges.”（尽管 UB-Mesh 的 n 维全连接网格（nD-FullMesh）拓扑在理论上具备若干优势，但其具体的架构设计、物理实现及网络系统优化仍面临新的挑战。）
不论如何，技术创新需要探索各种路径，尤其是在主流技术路径创新空间有限的背景下，通过差异化技术路线求新求异，本来也是学术研究（包括学术论文创作）中颇为常见的做法，因此探索过程中的各种尝试还是有其价值的。十、探讨针对论文所述AI网络的诸多需求与设计目标，实际上可以在主流技术框架内，采用更简洁实用的架构方案予以实现。具体而言，可将 Scale-out 网络与 Scale-up 网络在物理上分离为两张网络（尽管两者可尽量采用统一的技术栈）：
[*]Scale-out 网络： 用于构建十万甚至百万卡级集群。在以128卡超节点为基本建设单元的场景下，采用 128轨 的两层 CLOS 拓扑以及128*400G高基数（higher-radix）交换机，可以支持百万卡集群规模。在提供同等端口接入能力的前提下，交换机基数越高，CLOS 所需层数越少，光模块用量越少。光模块在网络硬件成本占比约2/3，因此通过节约光模块可以极大降低网络硬件成本。
[*]Scale-up 网络： 专注于在百卡级超节点内实现高带宽通信域，可设计为单级多平面网络架构，以满足超高带宽和超低时延刚性需求。此外，对于百卡规模的 Scale-up 网络，完全可考虑采用有源铜缆（AEC）替代有源光缆（AOC）。相较于 AOC，AEC 在成本与功耗上可降低约 50%，同时可靠性可提升数个数量级。
页:
[1]
