NVLink、UALink与UEC：AI集群Scale-up互连路线深度横评

算力圈子里最近半年最热闹的话题，不是又出了多少T的算力芯片，而是“Scale-up”这个词被反复提起。会议室里天天有人问：NVLink都做到一个机柜72卡无阻塞了，为什么还要搞UALink？以太网不是又慢又抖吗，凭什么也来掺和Scale-up？还有人说，UALink和UEC，不就是用来跟英伟达砍价的筹码吗。

这篇文章，我想结合过去几年做AI集群网络、分布式训练性能调优的经验，把这三条路线彻底捋清楚。它们到底在比什么，你的集群到底需不需要关注，哪些是真实的工程约束，哪些只是PPT上的参数。读完你应该能自己判断：下一个预算周期，网络这块该往哪个方向押注。

1. 为什么“Scale-up”突然成了AI集群的焦点

1.1 大模型训练把通信模式推到了临界点

几年前我们搭训练集群，基本思路很简单：单机内靠PCIe和NVLink，跨机靠InfiniBand或者100G以太网，通信就分两种——梯度同步和参数拉取。模型并行只是少数人的高级玩法，绝大多数训练跑的是数据并行，通信集中在每次迭代末尾的AllReduce上。这种模式下，网络带宽有上限，但延迟稍微高一点问题不大，因为同步频率低，每次迭代几分钟甚至更长。

现在的模型尺寸和数据并行方式完全变了。千亿甚至万亿参数模型，单卡显存放不下，张量并行（TP）把一层网络的权重切成多份，每次前向和反向都要做大量节点间同步；MoE模型里的专家并行（EP），每个token都可能被路由到不同节点的专家上，带来的是密集的All-to-All通信。通信已经从“每轮训练一次”变成了“每个算子都来一次”。

这直接导致了一个问题：跨节点的通信延迟和带宽，开始直接决定端到端训练效率。用大白话说，以前网络慢一点顶多是“吃饭的时候多等两分钟”，现在网络慢，相当于“每吃一口饭都要重新点一次单”。优化通信路径的收益，远比优化单卡算力更立竿见影。

1.2 Scale-up域与传统Scale-out的本质差异

通信模式和需求变了之后，“Scale-up”这个词就浮出水面了。过去我们说的Scale-up，是指一台服务器加CPU、加内存、加硬盘，升级单机性能；在AI语境下，Scale-up指的是把多个加速器（GPU、NPU、TPU）通过某种高速互连，组成一个逻辑上的“超级大GPU”。

Scale-up和传统Scale-out有本质区别。Scale-out网络是面向“机器”之间通信设计的，数据包从一台机器的网卡出去，经过交换机和拥塞控制，再到另一台机器的网卡，链路可能几百米甚至跨园区；Scale-up域则更接近“总线”概念，它要解决的是几厘米到几米范围内，一堆计算芯片如何像紧耦合的多核处理器一样协同工作。

从技术表现上看，Scale-up网络必须是：单端口带宽极高（至少数百GB/s），端到端延迟极低（微秒级甚至亚微秒级），而且最好支持内存语义——也就是能直接读写远端加速器的显存。这不是普通的TCP/IP数据包能轻松做到的。NVLink、UALink，以及专门为AI优化的“超以太网”UEC，本质上都是在争夺这个“超级GPU内部总线”的定义权。

1.3 为什么这场争论现在才爆发

NVLink其实已经存在好多代了，过去也没见以太网阵营天天盯着它做对标。现在UALink和超以太网联盟（UEC）都跳出来，核心原因就一个：AI集群的规模冲破了旧有边界。

以前一个GPU服务器机箱，8张卡通过NVLink连成一个大域，8卡甚至16卡之间的通信都在机箱内完成。但现在NVL72这种72卡系统，把NVLink域扩展到整个机架，这个“大域”的生存空间大幅扩张。问题是，只有英伟达能做这种域，其他所有硬件厂商，包括博通、AMD、Intel、Meta、微软，都意识到如果继续让NVLink单方面定义Scale-up边界，整个AI硬件生态的利润和价值都会被英伟达吸走。

所以UALink和UEC几乎是同时出现的，一个对标NVLink做私有GPU互连，一个想把以太网改造到能承担Scale-up流量。这不再是一个纯粹的技术问题，而是开放生态对封闭系统的反击。要理解这盘棋，关键是把三家的技术路线放到同一坐标系里看。

2. 三个玩家分别是什么：NVLink、UALink与以太网Scale-up

2.1 NVLink：把私有化做到极致的性能标杆

NVLink的起点是GPU之间的专用数据通路，最早用于双卡直连。发展到现在，NVLink已经不只是“一根线”的级别，而是一套完整的交换式Fabric。在DGX H100这种SXM服务器里，8张GPU之间通过NVLink Switch芯片或全连接拓扑实现无阻塞互连；到了GB200 NVL72，更是把72张GPU和NVLink Switch整合到一个机柜里，形成一个可以被整个训练任务共享的显存池和通信域。

实测来看，NVLink最厉害的地方不只是带宽，那是连到CPU上的PCIe总线永远追不上的，更重要的是它的延迟极低。低延迟让张量并行这类细粒度通信变得可行，也让NVLink SHARP这类“网内计算”有机会落地——AllReduce的归约操作可以在交换层完成，数据不用全部汇到一个节点，省掉了大量流量往返。这是英伟达十年软硬件垂直整合的结果：GPU、NVSwitch、CUDA、NCCL库全都是自己家，协议可以在每一层做定制，没有兼容性包袱。

代价也很明显：想用NVLink域，必须整机采购英伟达系统，扩展性、可维护性、价格都被牢牢限制。

2.2 UALink：开放阵营为GPU量身定制的“新总线”

UALink的全称是Ultra Accelerator Link，由AMD、博通、思科、Google、Intel、Meta、Microsoft等公司组成的联盟推动。它的定位非常明确：在加速器之间建立一个高带宽、低延迟、面向内存语义的互连标准，对标的就是NVLink。你可以把它理解成“开放版NVLink”——不是通过IP网络去传输数据，而是定义一种让GPU、AI加速器之间直接共享内存的总线标准，它基于高速SerDes和类似CXL的内存语义，但目标不是CPU和内存之间的连接，而是加速器到加速器的连接。

这带来两个关键看点。第一，它想打破“Scale-up域只能跟着GPU厂商走”的现状，让不同厂商的加速器也能用同一个开放协议互联，用户第一次有可能把AMD的卡、Intel的卡、自研AI芯片放进同一个Scale-up域。第二，它把内存语义作为一等公民，加速器可以读写远端设备的内存，这正好对上了显存池化、KV Cache共享、模型并行这类需求。

UALink的物理链路规划和PCIe/CXL一脉相承，意味着它可以大量复用现有SerDes、Retimer、交换芯片技术，不用从零发明物理层。从路线上看，它要挑战的不是“以太网走不走得通”这个问题，而是“如果一个客户不想被NVLink锁死，他能不能买到一套性能和NVLink域打平的硬件组合”。

2.3 以太网Scale-up：用超以太网联盟重新定义网络

UALink对标NVLink，超以太网联盟（Ultra Ethernet Consortium，UEC）的走位则更野：它想证明以太网也能做Scale-up。要做这么多事情，需要的就不只是把端口速率从400G提到800G，而是要对以太网的传输控制机制动大手术。

传统以太网是“尽力而为”的，网络拥塞了就丢包，丢了就重传，这在大模型细粒度同步场景下是致命的。RoCEv2算是把RDMA搬到了以太网上，但实际用起来，因为PFC（优先级流控）和ECN/DCQCN这些机制在复杂拓扑下很难调，动不动就出现“拥塞树”、“PFC死锁”、“慢节点”问题，运维同学都叫苦不迭。UEC的做法是从链路层、传输层到网卡行为一起改造：引入数据包喷洒（Packet Spraying）让流量更平均地散布到多条路径上，支持乱序提交，重新设计多路径拥塞控制，避免依赖PFC这种全网络范围的刹车机制，同时把遥测数据标准化，让交换机、网卡、管理平面实时联动。

目标很明确：把以太网的延迟和可靠性做到接近InfiniBand甚至NVLink域的水平，同时保留以太网“人人都会用、设备随便凑齐、接口统一”的开放生态。相比UALink专注于几米内的Scale-up，以太网还想顺手把Scale-out的数据中心网络也统一起来，让大家只维护一套网络栈。

3. 硬核横评：带宽、延迟、内存语义、拓扑与生态

3.1 带宽与延迟：为什么不是一个量级的“快”

很多人看到NVLink的带宽数字，第一反应是“以太网这辈子都不可能追得上”，这话要分情况说。NVLink域内的连接距离通常只有几十厘米到几米，走的是背板、铜缆或者专用光模块，它省掉了IP/TCP协议栈的封装和路由开销，可以做到单GPU总带宽达到TB/s级别，延迟亚微秒。UALink在几百到几千加速器规模内，目标相当接近这个量级，因为它同样面向超短距离、专用协议、内存语义。

以太网则天然要跨越更长的距离，承担更复杂的网络拓扑，MAC层、编解码、FEC、交换和路由步骤一个都不能少。即便是UEC对数据通路做了大量精简，物理距离和协议栈的固有开销也决定了它很难在“单跳延迟”上和NVLink域硬碰硬。但在机架级、集群级场景，400G和800G以太网的单端口带宽已经非常夸张，团队看重的更多是“这一跳拥塞能不能控制住”，而不是“延迟是不是亚微秒”。

所以三者不是在同一个量级上比“快”，而是在不同物理距离和开放性约束下，探索怎样最高效地把算力组合起来。

以下是几个关键参数的横向对比，我结合公开规范与实测经验整理：

3.2 内存语义：共享黑板与群发邮件的差别

如果只用一句话概括NVLink、UALink和以太网在“语义”上的差别，我会说：前两者想让一堆加速器像共享一块黑板那样同步工作，以太网则更像是让机器之间用非常高效的信使互相投递邮件。数据并行时，发邮件就够了；张量并行、显存池化、KV Cache共享这些场景，共享黑板的价值会迅速放大。

以太网这边也有RDMA，RoCEv2已经可以做到远端内存直读写，但缺乏缓存一致性保障，也没有像NVLink SHARP那样的网内归约优化，应用层通常还是要把数据“拉到本地算一遍”。UALink的设计目标之一就是把这些“算”真正下沉到交换和链路层，让加速器之间的数据流动更像CPU访问内存。需要注意的是，NVLink和UALink的“内存语义”也并没有完全等同，NVLink经过多年迭代更像一台巨型GPU的村内总线，而UALink目前更侧重于加速器之间显存互访和可组合性，离真正的缓存一致性还有很长的路要走。

3.3 拓扑弹性：机柜内的超级GPU vs 数据中心级网络

NVLink域现在最有震慑力的地方，在于它可以物理上把几十张GPU变成一个单一的通信域。单机柜NVL72的拓扑里，任意两张卡通信都不需要经过传统网络交换芯片，延迟和带宽非常均匀。但这种“超级GPU”很难跨越机柜，因为NVLink交换网络的设计目标就是短距离、高带宽、低时延，距离变长后信号完整性和光模块成本都会失控。

UALink的思路类似，本质上还是把Scale-up域限制在一个较小的物理空间里，比如同一个机柜内或相邻几个机柜。以太网反过来，它可以延伸到整个数据中心，但在跨距离通信时就需要借助交换机级联、路由协议、三层ECMP这些传统机制，这会重新引入延迟和抖动。所以在真实大型集群中，答案不是选A不选B，而是把两者嵌套起来：机柜内用NVLink或UALink组成一个大型“逻辑节点”，机柜之间再用以太网或InfiniBand把这些节点拼成集群。

3.4 生态与控制力：跑分背后的商业逻辑

单纯比协议效率，NVLink仍然领先，但商业世界从来不只比性能。云厂商和大型AI公司最害怕的事情，是单一供应商同时握有算力定价权和网络定价权，导致基础设施规划没有任何回旋余地。UALink和UEC存在的意义，首先是给这些买方一个谈判筹码和一个可落地的备选方案。

从生态成熟度看，NVLink+英伟达的CUDA/NCCL栈几乎是无敌的，开发者不需要自己关心底层通信，一切看起来很美好。UALink目前还要等AMD、Intel等厂商在ROCm/RCCL里真正把驱动和库做成熟，中间还有很长的软件适配过程。UEC则相对幸运，它站在标准以太网生态的肩膀上，Linux内核、DPDK、libfabric、OpenUCX这些基础软件都在往新的UEC传输层靠拢。生态大战不太可能速战速决，最终会变成“封闭的最优解”和“开放的足够好用”之间的长期拉扯。

4. 工程落地：从PPT参数到机房现实的差距

4.1 物理层同源：SerDes、光模块、功耗散热都是硬约束

看完上面这些对比，有人可能会觉得UALink和NVLink完全是两个物种。但真到了工程师手里，你会发现所有高速互连最终都要落到底层物理层：高速SerDes。无论是800G以太网、UALink，还是NVLink域，都在用112G甚至224G SerDes，差别只是封装格式、FEC和协议帧格式不同。

这意味着一个残酷的事实：即使今天所有服务器都改成UALink，你还是要建一套高密度、高功耗、高散热的高速网络基础设施，和建800G以太网一样费电、费钱。NVLink域的内部通信很多走机柜内铜缆，但跨机柜的主干连接，同样需要光模块。一个NVL72机柜的功率已经接近100kW级别，这数据中心的供电和液冷改造才是真正的瓶颈。协议再高效，也绕不开物理空间的限制。

4.2 拥塞控制：无丢包与重排之间的刀尖起舞

以太网做AI高性能传输，最大的敌人一直是拥塞。RoCEv2时代，大家印象最深的就是PFC的副作用：一条流堵了，优先级暂停帧会逐跳往上传递，把整个交换域的流量都拖下水，网络工程师恨不得封了PFC。UEC想做得更聪明，用Packet Spraying把流量尽量打散到所有可用路径上，允许接收端处理乱序包，再用网卡和交换机协同的遥测来做精细化拥塞控制。

听起来很美，但代价是乱序提交会消耗CPU、内存甚至专用硬件资源，网卡上要做更复杂的重排序逻辑。NVLink和UALink因为拓扑更可控、路径更短，拥塞控制的压力小得多。实战中你会发现，参数差不多的两款“以太网Scale-up方案”，网卡上重排序缓存的深度不同，在大规模All-to-All下表现可能天差地别。选型不能只看链路速率，要看网卡的实现细节。

4.3 可运维性：诊断工具与故障域的取舍

私有协议最大的痛点之一是“黑盒”。NVLink链路如果出现训练性能突然下降，你通常只能借助厂商提供的工具去看链路重传、降速、温度，想拿到底层原始计数器和寄存器信息很难。而以太网的好处是，在Linux上你随手就是ethtool、netstat、Wireshark，遇到问题可以从数据包层面一层层看，诊断成本完全不在一个量级。

UALink目前处于两者之间：它希望做得比NVLink更开放，会暴露一些标准的遥测接口，但第一代硬件和驱动还没经过大规模生产环境检验，故障处理经验几乎为零。对于大团队来说，可运维性往往比多出来的那点带宽更重要。训练集群一次断线、一次慢链路，浪费的成本可能就是几十万显卡时，协议标准的“准确性”没有想象中那么值钱，“诊断效率”才是最值钱的。

5. 实际选型怎么做：从需求拆解到测试验证

5.1 先判断你的集群瓶颈究竟是带宽还是延迟

不管外面吵得多凶，回到自己的项目里，首先要回答的问题是：你的训练负载中，通信瓶颈到底是带宽还是延迟。如果是纯数据并行，梯度同步频率低，延迟不是核心，端到端带宽更关键；如果用了大量张量并行、流水线并行、MoE专家路由，通信非常频繁，延迟抖动比带宽更致命。

判断方法很简单，直接看模型代码里的并行配置，再用NCCL或RCCL的通信日志看每个通信算子的耗时占比。如果通信时间占总迭代时间超过两三成，Scale-up路线就值得投资；如果通信时间占比不到一成，先把瓶颈排查放到存储、数据加载、算子优化上更划算。

5.2 一套可复用的Scale-up验证流程

技术选型不能信PPT，要按照一套固定的步骤去做真机验证。我建议至少走完下面这几步：

1. 先摸清单节点拓扑。用nvidia-smi topo -m（英伟达卡）或rocminfo（AMD卡）看卡间互连路径，确认是不是所有卡都在同一个Scale-up域内，这对后续压测结果解读很重要。
2. 跑基线的P2P带宽与延迟测试。CUDA生态下用p2pBandwidthLatencyTest，ROCm下用rocprof或类似工具，记录矩阵内两两通信结果。如果延迟测试里出现明显的离群卡，大概率是拓扑或链路问题。
3. 跑跨节点的All-Reduce/All-to-All测试。推荐nccl-tests里的all_reduce_perf和alltoall_perf，记录不同消息量下的总线带宽和延迟曲线。重点观察消息量从1MB到几百MB的变化曲线，很多方案在小包延迟和超大包带宽上各有优势。
4. 用真实模型做端到端验证。网络benchmark再好，最后也要看真实训练吞吐。建议选1-2个典型模型（比如GPT类预训练和一个MoE模型），调好TP/PP/EP并行度，跑几百步，对比吞吐和稳定性。
5. 记录抖动和收敛性。不仅看平均吞吐，还要看每步耗时是否稳定。通信抖动大的网络，会影响长任务稳定性，可能造成训练中断或loss spikes。

下面是我常用的一个验证表格，可以直接沿用：

5.3 按规模选择：实验室、机柜级与云级集群的不同答案

如果你只是一个高校实验室或者初创团队，单机8卡就够用，NVL域或PCIe互连已经够好，完全没有必要为了“追新”去上面凑UALink或者800G以太网的设备，账算不过来。如果到了数十卡、上百卡甚至一个机柜的规模，但团队网络运维能力有限，采购一体化的NVLink系统确实省心，代价是预算单一、扩展路径被锁死；如果不想绑定，UALink刚开始有商业硬件，可以作为“摸底测试”对象，但别指望它马上达到与NVLink域同等级的生产稳定性。

到了千卡以上集群，事情会变得更复杂。大型云厂商几乎一定会同时保留两个方向：一部分采购NVLink域来做最紧耦合的训练负载，一部分投入UALink和UEC生态，用来控制成本和训练非紧耦合任务。这个决策已经不完全是技术问题，而是供应链安全、议价能力和工程维护能力的综合权衡。

6. 常见认知误区与避坑建议

6.1 四个经常被忽视的判断陷阱

第一个误区是“以太网永远做不了Scale-up”。如果这里的Scale-up指的是亚微秒内存语义，以太网确实做不到；但如果指的是在100米内的机柜间提供“够用”的高带宽、低抖动通信，UEC已经有明确路线图。不要拿老眼光看新规范。

第二个误区是“UALink一出，NVLink的护城河就被填平了”。UALink目前规范和第一批硬件都还处于早期，软件栈翻车是大概率事件。NVLink能成为事实标准，靠的是十年软硬件迭代，不是一个标准文档就能撼动的。

第三个误区是“带宽翻倍，训练一定提速”。通信负载通常是离散且同步的，带宽翻倍可能只是把通信时间从20毫秒降到15毫秒，而整个迭代时间从300毫秒变成295毫秒，提升不到2%。先算清楚延迟和带宽占整个训练流程的权重，再决定该追哪边的性能。

第四个误区是“有了Scale-up域，就不用关心Scale-out网络了”。NVL72每个机柜72张卡，机柜之间照样要靠网络连接。Scale-up域和Scale-out网络的边界不会消失，只会被重新划分，两者永远是并行建设。

6.2 我踩过的坑与建议

从去年到今年，我见过不止一个项目把所有预算都砸在NVLink域上，结果跨机柜网络从800G以太网降配到400G，最后MoE模型的All-to-All流量把网络出口打爆，训练效率反而不如等预算配更均衡的集群。也见过团队对UEC抱有特别高的期待，一上来就拆掉旧RoCE网络换新设备，结果因为网卡重排序策略没调好，小包延迟反而飙升，最后只能回退配置。

作为一个经常两头折腾的人，我的建议是：不管选哪条路线，先留出至少20%的预算和运维精力来建设“第二套网络”或“备用路径”。Scale-up之争短期内不会有终局，但你的业务需求不会等技术标准的终局。真正稳妥的做法，是把Scale-up域视作“形态更灵活的单机显卡扩展”，把以太网视作“永远需要的集群粘合剂”，两者分开评估吞吐、成本、故障率和运维难度。

另外准备一个性能基线和历史对比库。每次新的固件、驱动、网络协议版本上线前，都先跑一遍之前提到的基准测试，用数据说话。等上一两年再回看，你会感谢当初留下了这些记录。