UALink 是最近圈子里出现频率最高的单词之一而另一边NVIDIA 咬着自己的 NVLink Fusion 体系不动摇。两边争夺的恰恰是同一个东西基于 Chiplet 的超节点 Scale-up 互连。我自己这几年一直在折腾 GPU 集群和大模型训练对“超节点”这三个字的体感变化非常明显。这篇内容就把 NVLink Fusion 和 UALink 放在一起拆一拆聊清楚它们到底在争什么以及真到落地时你该怎么选。先说一个基本判断Scale-up 互连不是“把速度做快一点”那么简单。它牵涉到内存语义、可靠性、芯片封装、交换机拓扑、底层软件栈甚至是整个产业生态的话语权。NVLink Fusion 代表的是极致但封闭的路径UALink 代表的是可组合、开放但仍有大量工程问题的路径。两条路现在都在跑谁也没有彻底胜出。1. 超节点与 Scale-up 互连先搞清楚大家在争什么1.1 为什么突然都在说“超节点”过去搭 AI 集群主流思路是 scale-out一台 8 卡机器摆在那里然后把几十台甚至几千台机器用以太网或专有网络连起来。这个思路解决的是“总量”问题但对“单任务的极端规模”并不友好。大模型训练和 MoE 推理发展到今天单个模型权重已经可以塞满一整台机器的显存还不够这时候拼的是显存池到底有多大、卡与卡之间的通信到底有多快。超节点实际上就是把“一个计算域”缩小到物理上非常紧凑的一组加速器里。你看到的可能是 16 卡、32 卡甚至更多但它们对外呈现出来的行为更像一个超大号 GPU而不是一堆独立显卡。这种设计需要极宽的互连带宽、极低的通信时延、很强的内存一致性以及能把这些能力暴露给上层框架的成熟软件栈。如果说 InfiniBand 解决的是数据中心里千卡万卡的远端通信那超节点解决的就是同一颗“大脑”内部的信号传输。1.2 超节点互连的几个硬指标我自己评判一套 Scale-up 方案通常只看五个维度带宽单卡到单卡、单卡到交换机、主流集合通信操作的实测吞吐。这是最直观的指标但也是最容易被宣传材料忽悠的维度。时延缓存一致性和 load/store 语义对时延极度敏感。几百纳秒和几微秒之间会让整个软件架构完全不同。扩展规模一个超节点最多能支持多少加速器互联这决定了你的显存池能有多大。可靠性与可运维性链路带宽再高一旦链路抖动、故障隔离做不好照样跑不起来。软件生态底层接口暴露得越“亲密”上层框架的优化空间就越大但反过来封闭接口也意味着你很难脱离厂商的控制。我这里想多说一句Scale-up 互连和普通网络最大区别在于它通常不是“发一个报文等远端处理再等响应”这么简单。很多时候它要支持 peer-to-peer 的显存访问要支持原子操作要让一个进程看起来好像拥有整个超节点的全部显存。这个能力听起来很爽但实现起来极其困难因为你需要处理一致性问题、故障模型、甚至不同芯片之间的内存排序规则。这也是为什么 NVLink Fusion 和 UALink 虽然做的是类似的事但它们的技术哲学完全不同。2. NVLink Fusion 方案拆解闭源、极致、深度绑定的 Scale-up 体系2.1 NVLink、NVSwitch、C2CNVLink Fusion 从哪来NVLink Fusion 并不是一个突然冒出来的单一接口。它更像是 NVIDIA 多年技术路线的一个“汇流点”。最早是 NVLink 做 GPU 间 point-to-point 互连后来 NVSwitch 把它扩展成全网状拓扑再后来 NVLink-C2C 又把 CPU、GPU、DPU 之间的 chip-to-chip 互连拉了进来。这套组合在一起才形成了今天我们看到的 NVLink Fusion 形态。从定位上看NVLink Fusion 的核心不是某一个物理层协议而是一整套“超节点互连抽象”。它既包含了芯片封装层面的 die-to-die 通道也包含了跨 GPU 模块的高速交换能力。你可以把它理解成 NVIDIA 把“芯片内部怎么连”和“加速器之间怎么连”放进了同一套设计语言里让软件的视角非常干净。对做系统的人来说这意味着从驱动、集合通信库到上层框架NVIDIA 都能做全链路优化。2.2 NVLink Fusion 里的 Chiplet 逻辑为什么标题里要强调 Chiplet因为现在加速器内部已经不是单一整颗芯片。一个大的 GPU 或 AI 加速器里面可能集成了计算芯粒、缓存芯粒、IO 芯粒甚至不同的芯粒来自不同代际或不同工艺。Chiplet 的好处是良率和灵活性代价是内部互连复杂度大幅上升。NVLink Fusion 的聪明之处在于它把“芯片内部芯粒之间的互连”和“芯片之间/节点之间的 Scale-up 互连”放在同一个一致性框架下管理。你不需要在软件里去区分“这个地址是通过内部总线访问还是通过外部链路访问”。对开发者来说整块显存看起来就是一块统一的可寻址空间。这个抽象在 CUDA、NVLink 对应的库、NCCL 这些组件里已经打磨了很多年实际用起来的体验是你只要选对拓扑和传输方式大部分性能问题都不会让你去跟裸硬件搏斗。从技术实现上看NVLink Fusion 也会用到不少关于带宽分配、拥塞控制、链路可靠性的手段。NVSwitch 在这里扮演的角色不是普通交换机而是一个低时延、高扇出的一致性交換核心。比如在一个八卡或十六卡的超节点里所有 GPU 通过 NVSwitch 两跳之内就能互访而且每个方向的带宽都能得到保证。这个体验在纯软件栈里很难复制。2.3 为什么说它“强但是贵”NVLink Fusion 的优点在工程上非常明显性能好、时延低、生态成熟。但它的问题也同样明显那就是封闭性。你只能用 NVIDIA 的 GPU或者严格限制生态内的组件。互连的细节规范不开放第三方很难在底层做兼容设备。成本控制主动权完全在 NVIDIA 手里。带宽越高溢价空间越大。软件绑定很深你一旦基于 NVLink Fusion 做了大量性能优化迁移到别的平台几乎等于重写。我并不是在否定 NVIDIA 的工程能力。恰恰相反NVLink Fusion 很多设计决策是合理且极致的。但如果你身处一个需要多供应商供应、或者有国产和开源替代需求的环境就很难接受这种“全家桶”式绑定。这也是 UALink 之所以会出现的直接原因。3. UALink 面向的开放世界3.1 为什么会冒出 UALinkUALink 背后是一个由多家加速器芯片厂商和云厂商组成的开放联盟AMD、Broadcom、Cisco、Google、HPE、Intel、Microsoft、Meta 这些名字列出来你就知道它的目标不是做一个小打小闹的实验协议而是想建立一个能对抗“NVLink 式垄断”的开放 Scale-up 互连标准。UALink 的核心理念是加速器之间的 Scale-up 连接不应该绑定某一家厂商的私有协议。它希望不同厂商的 GPU、DPU、AI 加速器甚至未来的 generic accelerator都能通过同一套互连规范连在同一个超节点里。这样用户在架构选型时可以在计算侧选择最合适的芯片在互连侧选择兼容的标准产品而不是被迫接受一个整体打包方案。从我接触到的信息来看UALink 早期重点会放在直接内存访问语义、低时延交换、以及多个加速器之间的内存共享能力上。也就是说它想做的事情和 NVLink Fusion 很像但是用一种更开放、更可组合的方式来实现。3.2 从 PHY 到协议栈UALink 大概会长什么样因为 UALink 仍在快速迭代我不建议把某个具体速率当成铁律。但我们可以从逻辑层次上去理解它物理层大概率会用高速 SerDes通过铜线或光模块连接各个加速器。速率目标直接对标当前高速互连的主流水平。链路层需要保证可靠传输、链路训练、误码率监控。这部分基础设施和高速以太网有共通之处但也有专门为内存访问优化的语义。事务层这是 Scale-up 互连的灵魂。它需要支持 load/store、显存到显存的 DMA、原子操作、以及类似 RDMA 但不那么“网络化”的访问模型。控制面和软件接口UALink 需要有标准化的驱动、内核接口、以及能对接 UCC、UCX、libfabric 这些中间件的抽象层否则上层框架没法直接用。很多人会问UALink 和 PCIe/CXL 有什么区别。简单说PCIe 是通用外设总线CXL 在做内存扩展和缓存一致性但它们都不是为“加速器到加速器”这种极高频、极大规模互连而生的。UALink 更像是直接瞄准“GPU-to-GPU”这个场景的专用协议。它要解决的是语义和时延的问题而不仅是带宽问题。3.3 UALink 与 Chiplet 的关系把“内部互连”和“节点互连”拆开Chiplet 在 UALink 体系里的定位也很关键。通常一颗加速器内部会用 UCIe 或者厂商自己的 die-to-die 互连把多个芯粒组合起来这类互连负责芯片内部的数据搬运物理距离极短带宽可以做得非常夸张。而 UALink 负责的是从一个芯片到另一个芯片或者从一个模组到另一个模组的互连。这种“内外分离”的设计比 NVLink Fusion 更灵活。UCIe 管内部UALink 管外部两边用适配器接起来。这样芯片厂商可以自由选择内部是更多计算芯粒还是更多缓存芯粒只要对外暴露一个标准的 UALink 端口就能加入超节点生态。这种做法对多供应商供应非常友好。风险也很明显如果内部互连和外部互连存在语义差异一致性、时延、软件抽象都会遇到不小的工程挑战。4. 核心对比NVLink Fusion vs UALink4.1 关键维度对比我试着把主要差异拉一张表方便你直接对照。维度NVLink FusionUALink开放性私有方案生态由 NVIDIA 主导开放联盟标准多家厂商参与部署形态与 NVIDIA GPU/NVSwitch 深度绑定面向多厂商加速器互连物理层私有高速SerDes搭配NVSwitch开放的高速SerDes设计目标兼容多类设备内存语义统一显存地址、强一致性抽象成熟目标支持load/store、DMA、原子操作标准仍在成熟软件生态CUDA、NCCL、NVSHMEM 等体系完善UCC、UCX、libfabric 等开放中间件正在适配性能调优全链路可控性能释放容易跨多厂商调优难度大但可组合性强成本与供应链单一供应商议价空间小多供应商竞争理论上更有议价空间风险技术锁定、续约价格不可控标准成熟度不够、生态碎片化风险适合场景追求极致性能和统一堆栈的 AI 训练集群异构加速、云厂商自研芯片、非 NVIDIA 生态这张表里最关键的一列我认为是“软件生态”。因为硬件互连想做到一个数量级的性能差异非常难但要靠软件适配拉低效率却非常容易。NVLink Fusion 能这么稳靠的不只是 NVLInk 高带宽而是 CUDA 和 NCCL 长期优化出来的“互联即显存”的体验。UALink 想替代的不只是物理层而是要把这层软件体验也做出来这个难度远大于定一个协议。4.2 具体场景怎么选如果手头就是一套 NVIDIA DGX/HGX 平台要跑大规模 GPT 类训练NVLink Fusion 几乎是最省心的选择。你不需要考虑怎么让不同厂商的卡在同一个超节点里协调工作因为硬件和驱动早就把路铺好了。你只需要写 CUDA 代码剩下的调度和通信优化基本可以由库和驱动完成。如果团队是搞云基础设施的上面有大量异构加速器或者正在自研 AI 芯片总线方案再香也不能用。这时候 UALink 的价值就很大它让超节点不再依赖单一芯片品牌云厂商可以在不同供应商之间选择性价比最高的组合。代价是你大概率需要自己投入不少系统软件团队去做协议适配、故障处理、性能调优。换句话说选择 NVLink Fusion 是花钱买省心选择 UALink 是自己动手换自由。4.3 可以混合用吗从逻辑上讲NVLink Fusion 和 UALink 是完全不同生态直接混用很难。但在实际数据中心里它们不一定是对抗关系。你可以用 NVLink Fusion 在单个 NVIDIA 超节点内部做高性能计算然后用 UALink 或高速网络把这些超节点连成更大规模的集群。也可以在一套系统里同时出现非 NVIDIA 加速器和 NVIDIA 加速器分别组成各自的小群体再通过类似网桥/网关的组件把两个群体串起来。当然这种混合形态不会太优雅时延和一致性都会有损失。如果应用对通信极其敏感混合方案的性能可能反而不如单生态。这也是目前选择 UALink 的人最头疼的问题标准还太新不可能像 NVLink 那样做到开箱即用。5. 现在做超节点互连建议怎么落地5.1 先把拓扑画清楚无论是选 NVLink Fusion 还是 UALink第一件事都是画拓扑。你需要先确定超节点由多少加速器构成加速器之间是不是全连接要不要用到交换机以及每层交换的收敛比是多少。不要上来就买一堆线缆先把“谁和谁必须高带宽、谁和谁可以共享路径”算清楚。举个例子8 卡超节点如果能做全连接集合通信的 all-reduce 会非常舒服但如果是 32 卡不使用交换机链路数量和成本会爆炸。这时候就要分成多个小集群再通过二级交换把它们串起来。NVLink Fusion 因为有自己的 NVSwitch拓扑规划相对容易UALink 的开放生态则需要你自己考虑 switch 的选择和兼容性初期建议先用模拟器验证拓扑再动硬件。5.2 留好协议适配层底层互连最怕的就是软件接口被锁死。我的建议是哪怕暂时不用 UALink也尽量在中间件层面保持抽象。比如集合通信不要直接调用 NCCL 底层 API而是通过 UCC 或类似上层抽象来封装。训练框架和算子库也不要在代码里写死某个厂商的互联接口。这样做短期内可能多写一层代码但长期看能让你在两套互连方案之间迁移时少踩很多坑。我见过太多团队性能优化一上头直接在项目里塞满厂商私有 API后来换平台时整个人都崩溃了。5.3 常见坑与排查思路Scale-up 互连的系统级问题往往不是单一链路的问题而是整体拓扑和软件栈的问题。我整理几个常见坑链路训练失败物理层不稳定通常和线缆、光模块、背板走线有关。先做单链路回环测试再逐步扩到全拓扑不要一上来就跑全集群压力测试。多节点集合通信带宽减半很多时候不是互连不行而是某些端口没有均匀打满流量。检查交换机的路由规则、哈希算法、是否涉及跨片转发。内存一致性问题目前 UALink 这类开放标准还在完善NVLink Fusion 优化多年但也不是完全没有边界条件。遇到数据不一致先把 CUDA/内存模型相关配置拉出来逐项核对再看远端内存操作的原子性是否被正确声明。驱动和固件版本错配开放生态最常见的问题是不同厂商的驱动版本互相打架。建议先固定一组经过验证的版本组合再谈性能优化。最后再分享一个我个人的操作习惯不管用哪套互连方案我都会在项目初期就写一个“互连健康检查”脚本定时采集带宽、时延、重传、链路误码这些指标。不是每个异常都意味着要停机但这些数据能帮你快速定位是脚本问题、网络问题还是协议本身的问题。调试 Scale-up 互连最怕的不是性能差而是不知道差在哪一层。养成这个习惯至少能让你在 NVLink Fusion 和 UALink 之间切换时心里有底。 超节点Scale-up互连之争：NVLink Fusion与UALink深度解析
UALink 是最近圈子里出现频率最高的单词之一而另一边NVIDIA 咬着自己的 NVLink Fusion 体系不动摇。两边争夺的恰恰是同一个东西基于 Chiplet 的超节点 Scale-up 互连。我自己这几年一直在折腾 GPU 集群和大模型训练对“超节点”这三个字的体感变化非常明显。这篇内容就把 NVLink Fusion 和 UALink 放在一起拆一拆聊清楚它们到底在争什么以及真到落地时你该怎么选。先说一个基本判断Scale-up 互连不是“把速度做快一点”那么简单。它牵涉到内存语义、可靠性、芯片封装、交换机拓扑、底层软件栈甚至是整个产业生态的话语权。NVLink Fusion 代表的是极致但封闭的路径UALink 代表的是可组合、开放但仍有大量工程问题的路径。两条路现在都在跑谁也没有彻底胜出。1. 超节点与 Scale-up 互连先搞清楚大家在争什么1.1 为什么突然都在说“超节点”过去搭 AI 集群主流思路是 scale-out一台 8 卡机器摆在那里然后把几十台甚至几千台机器用以太网或专有网络连起来。这个思路解决的是“总量”问题但对“单任务的极端规模”并不友好。大模型训练和 MoE 推理发展到今天单个模型权重已经可以塞满一整台机器的显存还不够这时候拼的是显存池到底有多大、卡与卡之间的通信到底有多快。超节点实际上就是把“一个计算域”缩小到物理上非常紧凑的一组加速器里。你看到的可能是 16 卡、32 卡甚至更多但它们对外呈现出来的行为更像一个超大号 GPU而不是一堆独立显卡。这种设计需要极宽的互连带宽、极低的通信时延、很强的内存一致性以及能把这些能力暴露给上层框架的成熟软件栈。如果说 InfiniBand 解决的是数据中心里千卡万卡的远端通信那超节点解决的就是同一颗“大脑”内部的信号传输。1.2 超节点互连的几个硬指标我自己评判一套 Scale-up 方案通常只看五个维度带宽单卡到单卡、单卡到交换机、主流集合通信操作的实测吞吐。这是最直观的指标但也是最容易被宣传材料忽悠的维度。时延缓存一致性和 load/store 语义对时延极度敏感。几百纳秒和几微秒之间会让整个软件架构完全不同。扩展规模一个超节点最多能支持多少加速器互联这决定了你的显存池能有多大。可靠性与可运维性链路带宽再高一旦链路抖动、故障隔离做不好照样跑不起来。软件生态底层接口暴露得越“亲密”上层框架的优化空间就越大但反过来封闭接口也意味着你很难脱离厂商的控制。我这里想多说一句Scale-up 互连和普通网络最大区别在于它通常不是“发一个报文等远端处理再等响应”这么简单。很多时候它要支持 peer-to-peer 的显存访问要支持原子操作要让一个进程看起来好像拥有整个超节点的全部显存。这个能力听起来很爽但实现起来极其困难因为你需要处理一致性问题、故障模型、甚至不同芯片之间的内存排序规则。这也是为什么 NVLink Fusion 和 UALink 虽然做的是类似的事但它们的技术哲学完全不同。2. NVLink Fusion 方案拆解闭源、极致、深度绑定的 Scale-up 体系2.1 NVLink、NVSwitch、C2CNVLink Fusion 从哪来NVLink Fusion 并不是一个突然冒出来的单一接口。它更像是 NVIDIA 多年技术路线的一个“汇流点”。最早是 NVLink 做 GPU 间 point-to-point 互连后来 NVSwitch 把它扩展成全网状拓扑再后来 NVLink-C2C 又把 CPU、GPU、DPU 之间的 chip-to-chip 互连拉了进来。这套组合在一起才形成了今天我们看到的 NVLink Fusion 形态。从定位上看NVLink Fusion 的核心不是某一个物理层协议而是一整套“超节点互连抽象”。它既包含了芯片封装层面的 die-to-die 通道也包含了跨 GPU 模块的高速交换能力。你可以把它理解成 NVIDIA 把“芯片内部怎么连”和“加速器之间怎么连”放进了同一套设计语言里让软件的视角非常干净。对做系统的人来说这意味着从驱动、集合通信库到上层框架NVIDIA 都能做全链路优化。2.2 NVLink Fusion 里的 Chiplet 逻辑为什么标题里要强调 Chiplet因为现在加速器内部已经不是单一整颗芯片。一个大的 GPU 或 AI 加速器里面可能集成了计算芯粒、缓存芯粒、IO 芯粒甚至不同的芯粒来自不同代际或不同工艺。Chiplet 的好处是良率和灵活性代价是内部互连复杂度大幅上升。NVLink Fusion 的聪明之处在于它把“芯片内部芯粒之间的互连”和“芯片之间/节点之间的 Scale-up 互连”放在同一个一致性框架下管理。你不需要在软件里去区分“这个地址是通过内部总线访问还是通过外部链路访问”。对开发者来说整块显存看起来就是一块统一的可寻址空间。这个抽象在 CUDA、NVLink 对应的库、NCCL 这些组件里已经打磨了很多年实际用起来的体验是你只要选对拓扑和传输方式大部分性能问题都不会让你去跟裸硬件搏斗。从技术实现上看NVLink Fusion 也会用到不少关于带宽分配、拥塞控制、链路可靠性的手段。NVSwitch 在这里扮演的角色不是普通交换机而是一个低时延、高扇出的一致性交換核心。比如在一个八卡或十六卡的超节点里所有 GPU 通过 NVSwitch 两跳之内就能互访而且每个方向的带宽都能得到保证。这个体验在纯软件栈里很难复制。2.3 为什么说它“强但是贵”NVLink Fusion 的优点在工程上非常明显性能好、时延低、生态成熟。但它的问题也同样明显那就是封闭性。你只能用 NVIDIA 的 GPU或者严格限制生态内的组件。互连的细节规范不开放第三方很难在底层做兼容设备。成本控制主动权完全在 NVIDIA 手里。带宽越高溢价空间越大。软件绑定很深你一旦基于 NVLink Fusion 做了大量性能优化迁移到别的平台几乎等于重写。我并不是在否定 NVIDIA 的工程能力。恰恰相反NVLink Fusion 很多设计决策是合理且极致的。但如果你身处一个需要多供应商供应、或者有国产和开源替代需求的环境就很难接受这种“全家桶”式绑定。这也是 UALink 之所以会出现的直接原因。3. UALink 面向的开放世界3.1 为什么会冒出 UALinkUALink 背后是一个由多家加速器芯片厂商和云厂商组成的开放联盟AMD、Broadcom、Cisco、Google、HPE、Intel、Microsoft、Meta 这些名字列出来你就知道它的目标不是做一个小打小闹的实验协议而是想建立一个能对抗“NVLink 式垄断”的开放 Scale-up 互连标准。UALink 的核心理念是加速器之间的 Scale-up 连接不应该绑定某一家厂商的私有协议。它希望不同厂商的 GPU、DPU、AI 加速器甚至未来的 generic accelerator都能通过同一套互连规范连在同一个超节点里。这样用户在架构选型时可以在计算侧选择最合适的芯片在互连侧选择兼容的标准产品而不是被迫接受一个整体打包方案。从我接触到的信息来看UALink 早期重点会放在直接内存访问语义、低时延交换、以及多个加速器之间的内存共享能力上。也就是说它想做的事情和 NVLink Fusion 很像但是用一种更开放、更可组合的方式来实现。3.2 从 PHY 到协议栈UALink 大概会长什么样因为 UALink 仍在快速迭代我不建议把某个具体速率当成铁律。但我们可以从逻辑层次上去理解它物理层大概率会用高速 SerDes通过铜线或光模块连接各个加速器。速率目标直接对标当前高速互连的主流水平。链路层需要保证可靠传输、链路训练、误码率监控。这部分基础设施和高速以太网有共通之处但也有专门为内存访问优化的语义。事务层这是 Scale-up 互连的灵魂。它需要支持 load/store、显存到显存的 DMA、原子操作、以及类似 RDMA 但不那么“网络化”的访问模型。控制面和软件接口UALink 需要有标准化的驱动、内核接口、以及能对接 UCC、UCX、libfabric 这些中间件的抽象层否则上层框架没法直接用。很多人会问UALink 和 PCIe/CXL 有什么区别。简单说PCIe 是通用外设总线CXL 在做内存扩展和缓存一致性但它们都不是为“加速器到加速器”这种极高频、极大规模互连而生的。UALink 更像是直接瞄准“GPU-to-GPU”这个场景的专用协议。它要解决的是语义和时延的问题而不仅是带宽问题。3.3 UALink 与 Chiplet 的关系把“内部互连”和“节点互连”拆开Chiplet 在 UALink 体系里的定位也很关键。通常一颗加速器内部会用 UCIe 或者厂商自己的 die-to-die 互连把多个芯粒组合起来这类互连负责芯片内部的数据搬运物理距离极短带宽可以做得非常夸张。而 UALink 负责的是从一个芯片到另一个芯片或者从一个模组到另一个模组的互连。这种“内外分离”的设计比 NVLink Fusion 更灵活。UCIe 管内部UALink 管外部两边用适配器接起来。这样芯片厂商可以自由选择内部是更多计算芯粒还是更多缓存芯粒只要对外暴露一个标准的 UALink 端口就能加入超节点生态。这种做法对多供应商供应非常友好。风险也很明显如果内部互连和外部互连存在语义差异一致性、时延、软件抽象都会遇到不小的工程挑战。4. 核心对比NVLink Fusion vs UALink4.1 关键维度对比我试着把主要差异拉一张表方便你直接对照。维度NVLink FusionUALink开放性私有方案生态由 NVIDIA 主导开放联盟标准多家厂商参与部署形态与 NVIDIA GPU/NVSwitch 深度绑定面向多厂商加速器互连物理层私有高速SerDes搭配NVSwitch开放的高速SerDes设计目标兼容多类设备内存语义统一显存地址、强一致性抽象成熟目标支持load/store、DMA、原子操作标准仍在成熟软件生态CUDA、NCCL、NVSHMEM 等体系完善UCC、UCX、libfabric 等开放中间件正在适配性能调优全链路可控性能释放容易跨多厂商调优难度大但可组合性强成本与供应链单一供应商议价空间小多供应商竞争理论上更有议价空间风险技术锁定、续约价格不可控标准成熟度不够、生态碎片化风险适合场景追求极致性能和统一堆栈的 AI 训练集群异构加速、云厂商自研芯片、非 NVIDIA 生态这张表里最关键的一列我认为是“软件生态”。因为硬件互连想做到一个数量级的性能差异非常难但要靠软件适配拉低效率却非常容易。NVLink Fusion 能这么稳靠的不只是 NVLInk 高带宽而是 CUDA 和 NCCL 长期优化出来的“互联即显存”的体验。UALink 想替代的不只是物理层而是要把这层软件体验也做出来这个难度远大于定一个协议。4.2 具体场景怎么选如果手头就是一套 NVIDIA DGX/HGX 平台要跑大规模 GPT 类训练NVLink Fusion 几乎是最省心的选择。你不需要考虑怎么让不同厂商的卡在同一个超节点里协调工作因为硬件和驱动早就把路铺好了。你只需要写 CUDA 代码剩下的调度和通信优化基本可以由库和驱动完成。如果团队是搞云基础设施的上面有大量异构加速器或者正在自研 AI 芯片总线方案再香也不能用。这时候 UALink 的价值就很大它让超节点不再依赖单一芯片品牌云厂商可以在不同供应商之间选择性价比最高的组合。代价是你大概率需要自己投入不少系统软件团队去做协议适配、故障处理、性能调优。换句话说选择 NVLink Fusion 是花钱买省心选择 UALink 是自己动手换自由。4.3 可以混合用吗从逻辑上讲NVLink Fusion 和 UALink 是完全不同生态直接混用很难。但在实际数据中心里它们不一定是对抗关系。你可以用 NVLink Fusion 在单个 NVIDIA 超节点内部做高性能计算然后用 UALink 或高速网络把这些超节点连成更大规模的集群。也可以在一套系统里同时出现非 NVIDIA 加速器和 NVIDIA 加速器分别组成各自的小群体再通过类似网桥/网关的组件把两个群体串起来。当然这种混合形态不会太优雅时延和一致性都会有损失。如果应用对通信极其敏感混合方案的性能可能反而不如单生态。这也是目前选择 UALink 的人最头疼的问题标准还太新不可能像 NVLink 那样做到开箱即用。5. 现在做超节点互连建议怎么落地5.1 先把拓扑画清楚无论是选 NVLink Fusion 还是 UALink第一件事都是画拓扑。你需要先确定超节点由多少加速器构成加速器之间是不是全连接要不要用到交换机以及每层交换的收敛比是多少。不要上来就买一堆线缆先把“谁和谁必须高带宽、谁和谁可以共享路径”算清楚。举个例子8 卡超节点如果能做全连接集合通信的 all-reduce 会非常舒服但如果是 32 卡不使用交换机链路数量和成本会爆炸。这时候就要分成多个小集群再通过二级交换把它们串起来。NVLink Fusion 因为有自己的 NVSwitch拓扑规划相对容易UALink 的开放生态则需要你自己考虑 switch 的选择和兼容性初期建议先用模拟器验证拓扑再动硬件。5.2 留好协议适配层底层互连最怕的就是软件接口被锁死。我的建议是哪怕暂时不用 UALink也尽量在中间件层面保持抽象。比如集合通信不要直接调用 NCCL 底层 API而是通过 UCC 或类似上层抽象来封装。训练框架和算子库也不要在代码里写死某个厂商的互联接口。这样做短期内可能多写一层代码但长期看能让你在两套互连方案之间迁移时少踩很多坑。我见过太多团队性能优化一上头直接在项目里塞满厂商私有 API后来换平台时整个人都崩溃了。5.3 常见坑与排查思路Scale-up 互连的系统级问题往往不是单一链路的问题而是整体拓扑和软件栈的问题。我整理几个常见坑链路训练失败物理层不稳定通常和线缆、光模块、背板走线有关。先做单链路回环测试再逐步扩到全拓扑不要一上来就跑全集群压力测试。多节点集合通信带宽减半很多时候不是互连不行而是某些端口没有均匀打满流量。检查交换机的路由规则、哈希算法、是否涉及跨片转发。内存一致性问题目前 UALink 这类开放标准还在完善NVLink Fusion 优化多年但也不是完全没有边界条件。遇到数据不一致先把 CUDA/内存模型相关配置拉出来逐项核对再看远端内存操作的原子性是否被正确声明。驱动和固件版本错配开放生态最常见的问题是不同厂商的驱动版本互相打架。建议先固定一组经过验证的版本组合再谈性能优化。最后再分享一个我个人的操作习惯不管用哪套互连方案我都会在项目初期就写一个“互连健康检查”脚本定时采集带宽、时延、重传、链路误码这些指标。不是每个异常都意味着要停机但这些数据能帮你快速定位是脚本问题、网络问题还是协议本身的问题。调试 Scale-up 互连最怕的不是性能差而是不知道差在哪一层。养成这个习惯至少能让你在 NVLink Fusion 和 UALink 之间切换时心里有底。