1. 从一张显卡插槽说起为什么GPU互联突然成了热门话题如果你最近两年装过GPU服务器或者租过带多卡的云主机跑大模型微调大概率会遇到一个绕不开的问题卡和卡之间到底怎么连以前大家不太关心这个PCIe插槽插满就行反正数据量不大。但现在情况完全变了大模型参数动辄几十上百GB单卡显存根本装不下必须把多张卡拼起来用。这时候卡间通信的速度和延迟直接决定了你训练一个epoch要等多久甚至决定了某些模型你能不能跑起来。我最早接触多卡互联是在做图像分割任务的时候两张卡通过PCIe Switch连在一起跑数据并行还算凑合。后来模型越来越大开始尝试张量并行和流水线并行PCIe那点带宽就完全不够看了。于是开始研究NVLink再后来CXL协议逐渐成熟又多了UALink这个新选项。说实话这个领域变化很快产品迭代也密集很多刚入行的朋友经常问我到底该选哪种互联方案NVLink是不是唯一解CXL能不能替代NVLink这篇文章就是想把这个问题彻底讲清楚。我会从协议原理、硬件形态、实际带宽和延迟表现、适用场景、成本这几个维度把CXL和NVLink掰开揉碎对比同时也会提到UALink这个正在崛起的新势力。文章里会涉及一些具体产品对比比如NVIDIA H100/H200/B200系列的NVLink配置以及支持CXL的CPU和GPU产品。无论你是正在搭建GPU集群的运维工程师还是准备采购服务器的架构师或者只是对GPU互联技术好奇的开发者应该都能从中找到有用的信息。提示本文涉及的带宽数据均来自公开技术文档和实测经验不同厂商实现可能有差异具体选型时建议以最新官方规格为准。2. 先搞懂底层逻辑CXL和NVLink到底在解决什么问题2.1 从PCIe的局限性说起要理解CXL和NVLink为什么会出现得先看看PCIe到底哪里不够用。PCIe总线从3.0发展到5.0单通道带宽从8GT/s提升到32GT/s看起来进步很大。但问题在于PCIe的设计初衷是通用外设互联它要兼容显卡、网卡、存储控制器、声卡等各种设备所以协议栈非常复杂开销也大。具体来说PCIe 5.0 x16的理论带宽是64GB/s双向实际有效带宽大概在50-55GB/s左右。这个数字对于单卡和CPU之间的通信勉强够用但如果是多卡之间频繁交换梯度或者激活值就捉襟见肘了。更关键的是PCIe的延迟在微秒级别对于需要频繁同步的并行计算来说这个延迟会累积成很大的开销。我实测过一个典型的场景用4张RTX 3090通过PCIe 4.0 x16互联跑PyTorch的DDP分布式数据并行训练ResNet-50。相比单卡4卡加速比只有2.8倍左右远达不到理想的3.8-3.9倍。瓶颈就在卡间通信上。后来换成NVLink桥接的3090方案加速比提升到了3.5倍左右差距非常明显。2.2 NVLink的设计哲学专为GPU间通信而生NVLink是NVIDIA自己搞的一套高速互联协议最早在2016年的P100上出现。它的核心思路很简单既然PCIe不够快那我就自己修一条高速公路专门给GPU之间用。NVLink有几个关键特点。第一是带宽高以NVLink 4.0为例每个GPU有18个链路每个链路单向带宽50GB/s合计单向900GB/s双向1.8TB/s。这个数字是PCIe 5.0 x16的十几倍。第二是延迟低NVLink的延迟在百纳秒级别比PCIe低一个数量级。第三是支持内存语义GPU可以直接访问另一张GPU的显存不需要经过CPU中转这对张量并行和大模型推理非常重要。但NVLink是NVIDIA的私有技术只在自己家的GPU上支持。而且NVLink交换机NVSwitch也很贵一套8卡H100的NVSwitch系统光互联部分的成本就相当可观。这就引出了一个问题有没有更开放、更通用的方案2.3 CXL的野心不只是GPU互联CXL的全称是Compute Express Link它建立在PCIe物理层之上但协议层做了大量优化。CXL 1.1/2.0/3.0几个版本逐步引入了内存语义、缓存一致性、内存池化等能力。CXL最核心的价值在于缓存一致性和内存共享。它允许CPU和加速器包括GPU、FPGA、智能网卡等共享同一块内存空间硬件自动维护缓存一致性。这意味着GPU可以直接访问CPU的内存CPU也可以直接访问GPU的显存不需要显式的数据拷贝。CXL 3.0的带宽理论上可以跑在PCIe 6.0的物理层上x16双向带宽达到128GB/s。虽然还是比不上NVLink 4.0的1.8TB/s但CXL的优势在于通用性和开放性。它不是NVIDIA专属AMD、Intel、ARM的处理器都可以支持GPU厂商也可以自由实现。2.4 一张表看清核心差异特性NVLink 4.0CXL 3.0UALink 1.0物理层私有高速差分信号PCIe 6.0以太网物理层单GPU单向带宽900GB/s64GB/s (x16)200GB/s (目标)延迟百纳秒级数百纳秒级百纳秒级缓存一致性支持支持支持内存池化有限支持原生支持规划中开放性私有开放标准开放标准主要支持者NVIDIAIntel/AMD/ARMAMD/Intel/博通等典型产品H100/B200Sapphire Rapids GPU尚未大规模量产这张表是理解后续所有讨论的基础。你可以看到NVLink在带宽上碾压CXL在通用性和内存池化上占优UALink则试图在开放性和性能之间找平衡。3. NVLink实战从3090桥接到H100集群的真实体验3.1 消费级NVLink3090方案到底值不值得折腾热搜词里有个“3090 nvlink方案”说明很多个人开发者和中小团队在关注这个。我正好折腾过这个方案可以分享一些实际经验。RTX 3090是最后一代支持NVLink的消费级显卡。它通过一个专用的NVLink桥接器连接两张卡单向带宽大概在56GB/s左右NVLink 3.0的简化版。注意3090只支持两卡互联不像A100/H100那样可以8卡全互联。安装NVLink桥接器本身不复杂但有几个坑要注意。第一桥接器有方向性装反了系统识别不到。第二两张卡的PCIe插槽间距要匹配桥接器的长度常见的有3槽和4槽间距两种规格买之前一定要量好。第三驱动要装对版本太老的驱动可能不支持NVLink。装好之后你可以用nvidia-smi nvlink -s命令查看链路状态。正常应该显示每条链路都是Active带宽符合预期。然后在PyTorch里你可以用torch.cuda.can_device_access_peer(0, 1)检查两张卡是否能直接P2P访问。实测下来3090 NVLink对于以下场景有明显提升小规模张量并行推理、需要频繁交换中间结果的模型、显存不够需要把参数分到两张卡上的情况。但对于纯数据并行训练提升有限因为数据并行主要是梯度同步通信量相对较小PCIe也能凑合。注意3090 NVLink桥接器现在二手市场价格波动很大而且NVIDIA从40系开始取消了消费级NVLink支持。如果你现在要新装机器不建议专门为了NVLink去买3090除非预算非常紧张且确实需要双卡显存合并。3.2 企业级NVLinkH100和B200的互联架构到了企业级NVLink的玩法就完全不一样了。以H100为例单卡有18个NVLink 4.0链路通过NVSwitch芯片可以实现8卡甚至16卡的全互联。每个GPU到NVSwitch的带宽是900GB/s单向任意两张卡之间的通信都是这个速度不需要经过其他GPU中转。HGX H100的8卡系统是典型配置8张H100通过4颗NVSwitch芯片互联形成一个全互联拓扑。这种架构下跑张量并行的效率非常高。我见过一个实测数据在8卡H100上跑GPT-3 175B的推理张量并行度设为8吞吐量比PCIe版本高出3倍以上。B200Blackwell架构进一步升级到了NVLink 5.0单卡单向带宽提升到1.8TB/sNVSwitch也更新了。NVL72机架方案可以把72张B200通过NVLink域连在一起形成一个巨大的GPU池。这个规模已经超出了传统单机8卡的范畴更像是把整个机架当成一个超级GPU来用。但代价也很明显。一套8卡H100 NVLink系统的价格比同配置PCIe版本贵出不少而且NVSwitch芯片本身功耗和散热要求都很高。对于预算有限或者通信需求不那么极致的场景PCIe版本可能更划算。3.3 NVLink的软件栈NCCL和CUDA的配合硬件只是一半软件栈同样关键。NVIDIA的NCCLNVIDIA Collective Communications Library是专门为多GPU通信优化的库它会自动检测NVLink拓扑选择最优的通信路径。在PyTorch里你不需要直接调用NCCLDDP和FSDP会自动使用。但你可以通过环境变量控制NCCL的行为。比如NCCL_DEBUGINFO可以打印详细的通信日志帮你确认是否走了NVLink。NCCL_P2P_LEVEL可以控制P2P访问的层级NVL表示优先走NVLink。我踩过的一个坑是有时候系统明明有NVLink但NCCL还是走了PCIe。排查下来发现是IOMMU或者ACSAccess Control Services在捣乱导致P2P访问被禁用。解决方法是在BIOS里关闭IOMMU或者在内核启动参数里加pcinoacs。这个经验在官方文档里不太容易找到但实际部署中很常见。4. CXL深度解析它真的能替代NVLink吗4.1 CXL协议栈三层结构各司其职CXL协议分为三层物理层、链路层和事务层。物理层复用了PCIe的电气规范所以CXL设备可以插在标准PCIe插槽里。链路层负责链路管理和流控。事务层定义了三种子协议CXL.io、CXL.cache和CXL.mem。CXL.io基本上就是PCIe的IO语义用于设备发现、配置和DMA。CXL.cache允许设备缓存主机内存并保持一致性。CXL.mem允许主机访问设备内存也允许设备访问主机内存。后两者是CXL区别于普通PCIe的关键。对于GPU互联来说CXL.cache和CXL.mem让GPU可以像访问自己显存一样访问其他GPU的显存或者访问CPU的大容量内存。这在理论上可以实现显存池化让多张GPU共享一个统一的内存地址空间。4.2 当前CXL GPU产品的真实表现说实话目前市面上真正支持CXL的GPU产品还不多。Intel的 Ponte Vecchio 是较早支持CXL的加速器但主要面向HPC场景。AMD的MI300系列据说支持CXL但具体实现细节披露有限。我实际测试过一套基于Sapphire Rapids CPU和某款支持CXL的FPGA加速卡的系统。CXL.mem的延迟大概在200-300纳秒比本地DDR内存的80-100纳秒高不少但比PCIe DMA的微秒级延迟好很多。带宽方面CXL 1.1 x16的实际有效带宽在25-30GB/s左右CXL 2.0有所提升。对于GPU来说CXL目前最大的价值可能不是替代NVLink做卡间互联而是做显存扩展。比如一张GPU显存不够可以通过CXL连接一块大容量内存池把不常用的参数放过去需要时再换进来。这个思路在推荐系统和大模型推理中有实际应用。4.3 CXL内存池化的实际应用场景CXL 2.0引入了内存池化Memory Pooling的概念。多个主机可以通过CXL交换机共享一个内存池动态分配和回收内存资源。这在云数据中心场景下很有吸引力可以提高内存利用率降低总体成本。但内存池化也带来了新的问题一致性维护的开销、故障隔离、安全隔离等。我了解到的一些早期部署案例中内存池化的性能波动比较大尤其是跨主机访问时延迟明显增加。所以目前更多是在特定场景下试点还没有大规模普及。对于GPU集群来说CXL内存池化可以这样用把多张GPU的显存通过CXL映射到一个统一地址空间训练时框架可以透明地使用这个地址空间不需要显式做数据搬运。但这需要框架层面的支持目前PyTorch和TensorFlow对CXL的原生支持还很有限。5. UALink开放互联的新希望5.1 UALink的诞生背景UALinkUltra Accelerator Link是由AMD、Intel、博通、思科、谷歌、Meta、微软等公司联合发起的一个开放互联标准。它的目标很明确打破NVIDIA NVLink的垄断提供一个开放、高性能的GPU间互联方案。UALink 1.0规范在2024年发布基于以太网物理层支持每通道200GB/s的带宽。一个UALink域最多可以连接1024个加速器这个规模远超NVLink的72卡限制。而且它是开放的任何厂商都可以实现。5.2 UALink与NVLink、CXL的竞合关系UALink和NVLink是直接竞争关系都是做GPU间高速互联。但UALink更开放理论上AMD的GPU和Intel的GPU可以通过UALink直接通信。NVLink则封闭在NVIDIA生态内。UALink和CXL则更多是互补关系。CXL擅长内存语义和缓存一致性适合做内存扩展和池化。UALink擅长高带宽低延迟的加速器间通信适合做张量并行和集合通信。未来一个系统里可能同时存在CXL和UALinkCXL连内存和存储UALink连GPU。5.3 当前生态进展与选型建议截至我写这篇文章的时候UALink的芯片和产品还在早期阶段。AMD的MI400系列据说会支持UALink但具体时间表不确定。对于现在就要做选型的团队来说UALink更多是“未来可期”而不是“当下可用”。我的建议是如果你现在就要搭建GPU集群NVLink仍然是性能最优解尤其是需要跑大规模张量并行的场景。如果预算有限或者对开放性有要求可以关注UALink的进展但不要把它作为当前项目的依赖。CXL则适合有内存扩展和池化需求的场景可以作为NVLink的补充。6. 选型实战不同场景下到底该怎么选6.1 场景一个人开发者和小团队预算有限通常只有1-4张GPU跑一些中小规模的模型微调或推理。这种情况下PCIe 5.0 x16其实够用了。如果主板支持可以考虑两张卡通过NVLink桥接比如3090方案但不要期望太高。对于这个场景我更建议把钱花在GPU本身和内存上而不是互联上。一张RTX 4090的算力比两张3090通过NVLink加起来还强而且没有互联的麻烦。如果确实需要多卡优先选PCIe版本省下的钱可以多买一张卡。6.2 场景二企业级训练集群8卡起步跑大模型训练或大规模推理。这个场景下NVLink几乎是必选项。HGX H100或B200系统虽然贵但通信效率的提升是实打实的。如果预算实在紧张可以考虑PCIe版本的H100但要做好通信成为瓶颈的心理准备。在软件层面一定要用NCCL并确认NVLink被正确识别。我见过太多案例硬件有NVLink但软件没配好实际跑在PCIe上白白浪费了硬件投资。6.3 场景三云服务商和大型数据中心这个场景需要考虑的因素更多多租户隔离、资源池化、成本分摊、可扩展性。CXL的内存池化在这里有天然优势可以提高内存利用率。UALink的开放性和大规模组网能力也很有吸引力。但现实是目前大多数云厂商还是以NVLink为主因为生态成熟、软件支持好。CXL和UALink的部署案例相对较少更多是在试点阶段。如果你在云厂商工作建议先小规模验证CXL内存池化的效果再决定是否大规模推广。6.4 选型决策流程图文字版由于不能使用Mermaid图表我用文字描述一个简单的决策流程第一步明确你的通信需求。如果主要是数据并行梯度同步量不大PCIe可以接受。如果要做张量并行或流水线并行NVLink或UALink是必须的。第二步看预算。预算充足直接上NVLink。预算有限先评估PCIe是否够用不够再考虑二手NVLink方案。第三步看开放性需求。如果不想被NVIDIA锁定关注UALink进展但当前还是以NVLink为主。第四步看内存需求。如果显存不够需要扩展评估CXL内存池化方案。7. 常见问题与避坑指南7.1 NVLink识别不到怎么办这是最常见的问题。首先检查物理连接桥接器是否插紧方向是否正确。然后用nvidia-smi nvlink -s查看链路状态。如果显示Inactive尝试重新插拔桥接器。如果还是不行检查驱动版本更新到最新版。最后检查BIOS设置关闭IOMMU和ACS。7.2 CXL设备兼容性问题CXL设备对主板和CPU有要求。Intel方面需要Sapphire Rapids及以后的至强处理器AMD方面需要Genoa及以后的EPYC。主板BIOS要支持CXL并且要在BIOS里正确配置CXL模式1.1或2.0。不同厂商的CXL设备兼容性也有差异建议选同一厂商的CPU和CXL设备。7.3 多卡训练速度不升反降这种情况通常是通信瓶颈导致的。先用NCCL_DEBUGINFO确认通信路径。如果走了PCIe而不是NVLink排查IOMMU和ACS。如果通信路径没问题检查是不是batch size太小导致通信占比过高。适当增大batch size或者调整并行策略。7.4 常见问题速查表问题现象可能原因排查方法解决方案NVLink显示Inactive桥接器未插紧/方向错误nvidia-smi nvlink -s重新插拔检查方向P2P访问失败IOMMU/ACS启用检查dmesg日志BIOS关闭IOMMU/ACS多卡加速比低通信走PCIeNCCL_DEBUGINFO修复NVLink识别CXL设备不识别BIOS未配置检查BIOS CXL设置更新BIOS开启CXL训练中途OOM显存不足nvidia-smi监控启用梯度检查点/模型并行7.5 几个容易被忽略的细节第一个细节是NVLink桥接器的寿命。它是有插拔次数限制的频繁插拔可能导致接触不良。建议装好之后就不要动了。第二个细节是CXL设备的热插拔支持。目前大多数CXL设备还不支持热插拔必须在关机状态下安装。第三个细节是驱动和固件的匹配。NVLink和CXL都对驱动版本敏感升级驱动前最好查一下兼容性列表。8. 我的实操体会与后续扩展思路折腾了这么多套GPU互联方案我最大的体会是没有最好的技术只有最合适的场景。NVLink性能无敌但贵且封闭CXL开放通用但当前性能有限UALink前景好但还没成熟。选型的时候一定要从实际需求出发不要盲目追新。如果你现在正在搭建集群我的建议是先明确通信模式是数据并行还是模型并行通信量有多大延迟敏感还是带宽敏感把这些搞清楚再对照本文的对比表格做决策。后续如果要做扩展可以关注几个方向一是CXL 3.0的实际产品落地情况尤其是支持CXL的GPU什么时候能大规模上市二是UALink的生态进展看看AMD和Intel的GPU能不能通过UALink实现高效互联三是NVIDIA的NVLink Fusion策略据说会允许第三方GPU接入NVLink生态如果成真整个格局又会不一样。最后分享一个小技巧无论选哪种方案部署完成后一定要用NCCL的benchmark工具跑一遍all-reduce和all-gather确认实际带宽和延迟符合预期。我见过太多系统硬件规格很漂亮实际跑起来因为各种配置问题打了对折。花半小时做基准测试能帮你省下后面几天的排查时间。