1. 一个被反复问的问题GPU互联到底该走哪条路做AI基础设施或者高性能计算这么多年我几乎每隔一阵子就会被问同一个问题想把多张卡高效地连起来做训练到底该用NVLink还是走以太网最近一段时间又多了一个变量就是CXL。很多人把它当成又一个“高速互联方案”跟NVLink和以太网摆在一起比带宽、比时延结果越比越糊涂。先给个直观的结论这三者的关系与其说是竞争不如说是各自解决不同层面的“搬运问题”。NVLink解决的是单机柜内部、GPU与GPU之间的超高速数据流动它的核心指标是带宽和时延恨不得把数据当成“在同一个芯片里搬寄存器”那种速度来搬。以太网解决的是服务器之间、机柜之间、甚至数据中心之间的数据流动它的核心指标是通用性、规模和成本你不可能让每一台机器的GPU都拉一根NVLink铜缆连到全世界。CXL这个新玩家则切了一个过去没人真正做好的蛋糕——它解决的是内存层面的扩展和共享让计算节点之间可以把内存当作本地内存一样访问而不是像网络那样“发消息、收消息”的模型。换句话说你想让4张GPU在一台机器里协同训练一个大模型NVLink是答案你想把几百台机器组成一个训练集群以太网是基础设施你想让一台机器用上隔壁机器的空闲内存或者在多台机器之间构建一个统一的内存池CXL才是对路的那个。这篇文章不打算写成教科书式的协议科普而是从实际工程选型和排障的角度把我这些年看过的、踩过的、测过的真实感受整理出来。里面有NVLink的拓扑细节和带宽计算方式有CXL跟PCIe的血缘关系也有以太网在AI集群里被重新定义的几个关键变化。如果你正在规划一台多卡服务器、设计一个训练集群或者单纯被这些名词搞得很焦虑这篇应该能帮你把思路理顺。2. NVLink的统治力来源不是“更快的PCIe”而是一套完整的私有总线架构很多人对NVLink的第一个误解就是觉得它只是把PCIe的通道做宽、频率做高本质上还是同类东西。这个理解错得很离谱。NVLink在架构层面跟PCIe是完全不同的设计思路它的目标是建立一张GPU之间的全互联网络而不是简单地“把数据从A搬到B”。2.1 从PCIe到NVLink为什么PCIe撑不住多卡训练要理解NVLink存在的理由先得看清楚PCIe在这个场景里卡在哪。PCIe总线的设计初衷是“通用I/O”——CPU要访问硬盘、网卡、声卡、显卡走的都是同一条总线它的核心追求是兼容性和低成本而不是极致的点对点带宽。即便到了PCIe 5.0单条x16通道的双向带宽也只有64GB/s而且这个数字是所有挂在这条总线上的设备共享的。当你在一个PCIe Switch下面挂了4张GPU它们之间的通信要经过PCIe Switch转发时延和带宽损耗都很难看。我在实际测过基于PCIe互联的四卡训练跑一个简单的all-reduce操作带宽利用率能到六成就算不错。而当模型并行度提高、梯度同步越来越频繁的时候PCIe成了整个训练流程里最明显的瓶颈。NVLink就是在这个背景下诞生的——NVIDIA从Volta架构开始直接在GPU芯片上加了一套专属于GPU之间通信的总线不走PCIe那套仲裁和路由机制而是点对点直连协议精简时延低得多。2.2 NVLink关键机制双工带宽、直接内存访问和域拓扑NVLink在技术上值得展开的细节有好几个最重要的我觉得是三点真正的双向全双工、对等内存访问的能力、以及通过NVSwitch扩展出的全域拓扑。先说双工。NVLink的带宽标称经常让很多人兴奋比如H100的NVLink带宽标称900GB/sB200时代是1.8TB/s。这里要提醒一句这个数字通常是双向双工的总带宽也就是读和写同时进行时的合计值。如果只算单方向的峰值要除以2。这个误会对容量规划很重要——你在估算梯度同步理论上限的时候如果拿双工带宽去算会得出一个过于乐观的结论。第二点是对等内存访问。NVLink不只是传输数据的管道它实现了GPU之间的“直接内存访问”简单说就是GPU A可以直接读GPU B的显存地址不用先把数据拷到CPU内存再拷过去。这听起来好像理所当然但在PCIe时代跨设备显存访问是要CPU参与“搬运”的那一步的开销非常可观。NVLink把这个“搬运”过程压缩到了硬件层面自动完成这让数据并行训练里的梯度集合操作省了大量时间。第三点是NVSwitch和NVLink域。当GPU数量超过一定规模全互联的“每张卡连到每张卡”在物理上是没法做到的——你想一想8张卡两两相连那就是28条链路的“全连接网”到了64张卡就是2016条链路PCB上根本放不下。NVSwitch的引入改变了这个局面GPU先连到NVSwitchNVSwitch之间再高速互联整个系统看起来像是一个虚拟的全连接网络。这意味着任何一张GPU到另一张GPU的逻辑路径都是“一跳”的带宽损失被控制在很小的范围内。2.3 一张表看清NVLink各代的带宽演进我自己整理了一张表方便你快速对比各代产品架构对应GPU单GPU NVLink带宽双向关键改进VoltaV100300 GB/s第一代NVLink多GPU直连AmpereA100600 GB/s引入NVSwitch三代域内带宽提升HopperH100900 GB/s支持更强NVLink域跨节点规模扩大BlackwellB2001.8 TB/s带宽翻倍功耗效率同步改进从V100到B200NVLink的单卡带宽翻了三番这个提升力度比同期PCIe的迭代幅度大得多。这也是为什么NVIDIA能理直气壮地说“多卡训练就用NVLink别折腾别的”——在单机柜尺度内在通用I/O标准里没有任何一个协议能在延迟和带宽两个维度上同时追平它。不过NVLink的强大也有代价它基本是NVIDIA的私有生态AMD的GPU用不了Intel的GPU也用不了而且NVLink域有规模上限H100的域是单机柜内数十张级别再往上就要靠网络协议来跨越了。这就自然引出了下一层的问题——跨机器、跨机柜靠什么连3. CXL的真实定位它连的是内存而不只是“另一个高速接口”CXL在热搜词里经常跟NVLink并列出现但它俩的出发点完全不同。我举个例子你就明白了NVLink解决的是“两个芯片怎么一起算”CXL解决的是“芯片怎么访问更大的内存池”。前者是协同计算的通道后者是扩展内存的通道。这两件事在超大规模计算里都重要但解决的问题根本不是一个维度。3.1 CXL从PCIe“长出来”但走了一条不同的路CXL其实是在PCIe的物理层上发展出来的协议。你可以把它理解为它借用了PCIe的“路”但跑了一套更聪明的“交通规则”。CXL规范目前主要分三种协议CXL.io负责设备发现和初始化跟PCIe很类似CXL.cache负责让CPU访问设备内存时保持缓存一致性CXL.mem则是让系统把设备上挂的内存当成系统内存的一部分直接使用。这里最值得展开的是CXL.mem带来的“内存池化”概念。传统上每台服务器的内存是固定挂在CPU旁边的DIMM插槽上的容量上限就是主板能插多少条内存。而在CXL架构下你可以把一柜子的内存通过CXL交换机聚合成一个大的内存资源池哪个节点需要更多内存就从池子里动态划分给它。这台机器内存不够用了另一台机器空闲着几十GB过去只能通过软件层面的远程内存调度勉强凑合CXL允许硬件层面就直接支持这种“借内存”的操作时延比网络远程内存访问低得多容量又比本地DIMM灵活得多。这背后的关键机制是缓存一致性。让CPU访问不属于本地主机的物理内存而不出乱子需要在硬件层面维护一致性协议——也就是当多个CPU核、多个设备都在读写同一块物理内存区域时它们看到的必须是一致的数据。CXL.mem通过发送缓存行粒度的读写请求和监听消息来保证这一点粒度比网络缓存机制细得多。3.2 为什么CXL被归类进“片间互联”但和NVLink关注的尺度不一样很多人把CXL跟NVLink放在同一类里做对比我猜主要是因为intel、NVIDIA这些厂商都在“片间互联”这个筐里发布了相关产品。但较真地说CXL更准确的定位是“节点内部和节点近邻的缓存一致性内存互联”它的尺度需求是机架级而不是GPU之间那种亚微秒级别的数据搬运。NVLink的一条关键数据是GPU之间的all-reduce操作时延可以压到微秒级以下而CXL内存访问的典型时延在数百纳秒到微秒之间跟本地内存的访问时延差距还在一个量级内但比直接走网络的远程内存访问快一个数量级以上。所以CXL适合的场景是“我需要更多内存”而不是“我需要更高的GPU间同步带宽”。这个区分特别重要。当你做显存密集型推理或训练比如某些大模型的KV Cache把显存吃满、需要把部分状态放到远端时CXL能提供一个比“走以太网拉到另一台机器”好得多的中间层。而当你在做模型并行、张量并行时每步计算都要同步大量梯度那种通信密集场景下CXL替代不了NVLink。简单说CXL把内存延展出去了NVLink把算力粘合起来了。3.3 实操视角评估CXL选型时的几个关键点CXL现在到了什么成熟度如果你去做选型有些点必须提前想清楚。第一CPU和内存控制器的支持。要真正利用CXL.memCPU的集成内存控制器必须支持CXL协议英特尔和AMD的新一代服务器CPU都已经或即将支持但具体到每一代主板和BIOS功能开启情况差异很大。我见过不少人在老主板上试CXL内存扩展卡结果只能当普通PCIe设备识别完全发挥不了内存池化的作用。第二CXL内存的容量和带宽比本地内存有明显差距。第一代CXL内存时延大概是本地DDR5的两到三倍带宽大概是本地的一半多一些。这意味着它适合做容量扩展不适合做热数据和频繁访问场景的替代。做系统设计时要把热数据放在本地内存把冷数据和低频率访问的数据放在CXL扩展内存或池化内存里这个分层思想很关键。第三CXL交换机生态还没完全成熟。内存池化的终极形态需要CXL Switch来连接多个主机和多个内存池模组但目前可商用的CXL交换机产品还不多OCP相关规范还在演进中。如果你现在就要落地这个方案大概率是先做点对点的内存扩展而不是一步到位做机架级内存池。CXL的价值在于它把“内存是每个节点私有的”这个几十年来的物理约束松动了。对于云厂商和超大规模计算中心来说这直接意味着内存利用率可以显著提升因为不用再为每个节点预留一大堆冗余内存以应对峰值需求了。4. 以太网为什么能在AI集群里重新翻红RoCE、无损网络与新的加速标准聊完了两种“私有/半私有”的互联方案该回到最基础、最通用的以太网了。你可能会问以太网不是传统I/O网络吗它真的能承担片间互联的职责吗说实话在很多AI集群里以太网已经是实打实的“主力军”只是它用的方式发生了一些关键变化。4.1 从“尽力而为”到“无损可靠”RoCEv2重塑了以太网的高性能能力传统以太网是“尽力而为”的传输模式——数据发出去能不能到、什么时候到网络层不保证。TCP协议在传输层做了可靠性和重传机制但在高性能分布式训练场景下TCP的重传和拥塞控制带来的时延抖动很要命。RDMA over Converged Ethernet这个协议的出现改变了一切。它把RDMA远程直接内存访问的能力搬到以太网上来让网卡可以直接把数据从一台机器的应用内存搬到另一台机器的应用内存跳过操作系统的协议栈和CPU拷贝数据传输的CPU占用率大幅降低。更重要的是RoCEv2的操作是“有损的底线”网络结构必须被配置成“无损”模式来确保不丢包——如果万一丢了包性能和稳定性都会急剧恶化。这个概念怎么理解呢你可以把普通以太网想象成一条经常堵车的城市道路偶尔有追尾丢包司机也不在乎慢慢再走就行。但RoCE环境是高铁轨道每列车都是按极高速度和极短间隔运行的一列车追尾后面一整串全得停恢复的时间成本极高。所以RoCE要求网络里的交换机和网卡启用PFC优先级流量控制和ECN显式拥塞通知等机制把丢包的可能性压到最低。4.2 无损网络的设计要点PFC、ECN和缓冲管理要把RoCE跑得好网络设计是一个专门的活。我提三个我在项目里实际踩过坑的地方。第一是PFC的“死锁”陷阱。PFC允许交换机在接收缓冲区满的时候向对端发送暂停帧让对方停一下给自己时间处理积压的数据。看起来很美但如果你在多个端口上不加区分地启用PFC可能造成“某一个端口的暂停信号波及到其他优先级流量”的连锁反应导致整个网络吞吐暴跌甚至出现PFC死锁。我见过一次很典型的故障某个机柜的RoCE流量突然从40Gbps掉到几百Mbps查到最后就是PFC配置时把控制流量的优先级也卷进来了控制面板消息被暂停帧卡住全网路由协议震荡。设计RoCE网络时第一件事就是把流量的优先级规划好——哪些队列允许PFC哪些不允许一定要提前定死绝不能图省事全开。第二是ECN的阈值调优。ECN的作用是让交换机在拥塞前就标记数据包网卡收到标记后自动降低发送速率。但ECN的阈值设得太低会导致传输速率不必要地频繁下降设得太高又起不到预警作用。这里没有通用值得根据实际业务的队列深度和时延预算做一轮轮测试。我通常的调法是先用交换机厂商的默认推荐值跑一套基准测试然后逐步降低阈值的百分比观察吞吐和时延曲线找到拐点再反向微调。第三是缓冲管理。无损网络里交换机缓冲区就是“蓄水池”水来得太猛时靠它缓冲。不同交换机的缓冲大小差异巨大有些廉价交换机的缓冲只有几百KB跑RoCE几乎不可能稳定这也是为什么很多AI集群宁可多花钱上高端交换机——它们的缓冲大、调度算法成熟能有效吸收微突发流量。4.3 以太网相对NVLink和CXL的真正优势规模、生态和开放说到这儿以太网的定位就很清楚了。它的延迟虽然比NVLink高一到两个数量级带宽在单链路层面也做不到NVLink那种TB级协商速率但它的优势在于三点。一是规模无上限。NVLink域有物理边界CXL内存池也有机架级限制但以太网能从一台机器的一个网口延伸到全世界的任何一台机器。大规模训练集群动辄几千张GPU靠的只能是网络协议而不是私有总线。二是生态极其开放。从网卡、交换机到线缆有无数厂商互相竞争价格和供应链的灵活性都不是私有协议能比的。三是技术迭代速度极快。以太网标准本身在从400G往800G和1.6T演进加上无损网络特性的加持实际能提供给分布式训练的有效带宽在持续提升。现在的趋势是AI训练集群普遍采用“混合互联”架构机柜内部的GPU用NVLink机柜之间的规模扩展用RoCE以太网或者InfiniBand。很多人问我InfiniBand跟以太网怎么选我的态度很务实如果单看峰值性能和生态成熟度InfiniBand在超大规模HPC里表现很强但如果你已经有大规模以太网运维经验、预算有限、又不喜欢被一家厂商的私有协议捆绑RoCE以太网是性价比非常高的选择。5. 选型实战从带宽、时延、成本、生态四个维度对比这三个协议前面把三个协议各自的定位和特性讲清楚了这一节直接给出选型时的对比思路。做技术选型不能只看纸面指标还得结合你手里的工作负载、预算和组织现状来权衡。5.1 关键性能指标对比维度NVLinkCXL以太网RoCE典型带宽600GB/s - 1.8TB/s单GPU双向约64-128GB/s当前CXL 3.0100Gb/s - 800Gb/s单链路典型时延微秒级以下数百纳秒至微秒级数微秒至数十微秒通信模型GPU直接内存访问缓存一致性的内存扩展RDMA需处理网络协议互联范围单机柜/单域机架级/机柜级全局无边界生态开放性私有NVIDIA开放标准PCIe SIG等开放标准IEEE/OCP主要成本私有专有硬件单价高新品初期成本较高标准化设备竞争充分这张表是我做决策时的“第一张过滤网”。如果你的核心瓶颈是GPU之间的梯度同步那NVLink的吸引力是压倒性的如果你在做大规模推理服务、内存容量不足CXL值得认真评估如果你要构建一个上千卡规模的训练集群以太网几乎是唯一的主流开放选项。5.2 从应用场景倒推协议选择选型的核心逻辑不是“哪个性能好选哪个”而是“我这个应用最痛的点是什么最可能被哪个协议治好”。单机多卡大模型训练模型大到需要张量并行或流水线并行显存不够放一整份模型需要多卡协同——第一选择一定是NVLink。原因无他张量并行的每一层计算都依赖跨卡通信通信时延直接决定训练效率。我用H800做过一个实验同一个模型在NVLink环境下的训练吞吐比走PCIe高出一倍还多那个差距不是优化代码能补回来的。推理场景显存不足模型推理时要把权重加载到显存当显存不够时传统做法是把部分层放到CPU内存用PCIe搬运效果很差。CXL内存扩展在这里有非常大价值把不常用的权重放CXL内存常用权重留在显存访问CXL内存比访问远端CPU内存快得多推理启动时间和吞吐都能明显改善。如果你现在就有“显存不够但又不想买更大显存卡”的痛CXL是值得关注的方向。大规模分布式训练当你的训练集群超过一个机柜比如64卡以上就必须依赖网络来同步梯度。这里的核心决策是选InfiniBand还是RoCE。InfiniBand性能好、生态完整但价格让人肉疼RoCE成本可控、运维经验和工具链更通用。我个人的经验是如果你的团队对Linux网络和交换机配置很熟RoCE完全能担起重任不必迷信InfiniBand。5.3 成本、功耗和运维复杂度有时候比带宽数字更关键做工程决策的人都知道性能只是众多维度之一。我见过不止一个项目实验室里用NVLink做小规模测试效果惊艳一算规模扩大到几百卡的成本和散热直接打退堂鼓。NVLink的铜缆和光模块都很贵而且每个NVLink域都需要独立布线机柜的功耗密度也会显著提高。CXL现在还处在早期带CXL功能的CPU、内存模组、交换机的价格都不低生态还不够成熟落地时要做好“做小白鼠”的心理准备。以太网则便宜得多标准化程度高二手设备也好买好卖运维工具链从Wireshark到各种网管平台都很成熟。从运维复杂度来看NVLink域基本是“黑盒”——NVIDIA自己维护驱动和firmware你只能通过nvidia-smi和DCGM工具查看健康状态。CXL目前还需要BIOS和操作系统层面的深度配合配置过程相对繁琐。以太网的运维复杂度则来自“无损网络调优”这一层——PFC、ECN、缓冲管理的配置和排障需要一个有经验的网络工程师。很多AI团队低估了这一点直到出问题才发现跑RoCE的网络和对传统TCP网络的运维逻辑完全不是一回事。6. 趋势判断与实战忠告接下来几年的互联格局会怎么变这一节聊聊我这几年观察到的行业走向以及一些踩坑之后的实在话。6.1 三个我比较确信的趋势第一NVLink会继续往更高带宽和更大域扩展但它的“墙”会越来越明显。Blackwell的1.8TB/s已经接近电信号在PCB上的物理极限下一代必然要靠光互连或者共封装光学来突破。同时NVIDIA也在把NVLink从纯GPU互联扩展到GPU和DPU、GPU和存储之间的互联试图把整个机柜变成一台巨大的“超级GPU”。这个战略很清楚让计算、网络、存储的边界在机柜内全部模糊化从而锁死自己的生态位。第二CXL会逐步从内存扩展走向真正的资源池化。等CXL交换机成熟后内存池、甚至加速器池化都会成为现实这会让数据中心的资源利用率上一个台阶。但这条路没那么快我预估真正大规模部署还需要两三年。第三以太网在AI集群中的角色会继续变重。RoCE只是第一步UECUltra Ethernet Consortium正在制定面向超大规模AI的下一代开放网络标准它会在RoCE的基础上改进拥塞控制、多路径和负载均衡目标是让开放式以太网的性能无限接近InfiniBand。这对不想被NVIDIA私有协议捆绑的客户来说是个实实在在的好消息。6.2 实战排障经验几个最好提前知道的坑我在这个领域踩过的坑不少挑几个典型的分享出来。第一个是NVLink的健康检查。很多人默认NVLink只要驱动装好就能满速跑实际不是。有一回我在一个八卡机上做训练发现梯度同步时延异常偏高查了半天不是代码问题最后用nvidia-smi nvlink -s查看链路状态发现有一根NVLink链路处于降级状态——firmware升级后没做链路重训练导致的。建议每台多卡服务器上线前都把nvidia-smi nvlink -s的所有链路状态打一遍日志记录基线训练突然变慢时先查这个能省下大量排查时间。第二个是RoCE网络的“掉速但不报错”现象。无丢包网络里不会像TCP那样频繁重传所以很多掉速问题的表象是“吞吐降低但没有任何报错”原因是ECN的隐式降速在发力。排查时不要只盯着丢包率要同时看交换机的ECN标记计数和网卡的发送速率曲线。有一回我调一个40Gbps的RoCE连接应用层吞吐一直只有8Gbps网络层怎么看都“正常”最后发现是网卡的拥塞控制算法在ECN标记率超过某个阈值后直接把发送速率降到最低档调了一下ECN阈值就好了。第三个是CXL初期落地的BIOS坑。CXL内存在服务器上能不能被正确识别跟BIOS版本、内存训练算法都有关系同样的硬件换一版BIOS可能表现完全不同。我的建议是如果你要试CXL先选定一个“黄金组合”CPU型号BIOS版本CXL内存型号全部验证通过后再扩展不要一上来就追求多种硬件组合的兼容性。6.3 给选型者的最后一句实在话技术选型最忌讳的是“拿着单一指标做全局决策”。NVLink和CXL、以太网并不是同一条赛道上的对手它们更像是不同长度的“尺子”——NVLink管毫米级CXL管厘米级以太网管米级。真正高效的AI基础设施往往是这三把尺子同时上阵各管一段。我自己当前的混合实践是单机柜内的8卡训练全走NVLink显存告急的推理节点考虑加CXL内存扩展跨机柜、跨区域的大规模集群走RoCE无损网络。这样组合下来性能、成本和扩展性都能取得一个比较理想的平衡。你可以把它当成一个参考起点再结合自己的业务去调整。片间互联这件事说到底是把“计算”和“搬运”这两件事重新组合。将来计算单元的形态可能会变但“算得快”和“搬得快”的博弈会一直在。能把这两者匹配好的人在任何规模的数据中心里都不会过时。 GPU互联选型指南：NVLink、CXL与RoCE的对比与实战
1. 一个被反复问的问题GPU互联到底该走哪条路做AI基础设施或者高性能计算这么多年我几乎每隔一阵子就会被问同一个问题想把多张卡高效地连起来做训练到底该用NVLink还是走以太网最近一段时间又多了一个变量就是CXL。很多人把它当成又一个“高速互联方案”跟NVLink和以太网摆在一起比带宽、比时延结果越比越糊涂。先给个直观的结论这三者的关系与其说是竞争不如说是各自解决不同层面的“搬运问题”。NVLink解决的是单机柜内部、GPU与GPU之间的超高速数据流动它的核心指标是带宽和时延恨不得把数据当成“在同一个芯片里搬寄存器”那种速度来搬。以太网解决的是服务器之间、机柜之间、甚至数据中心之间的数据流动它的核心指标是通用性、规模和成本你不可能让每一台机器的GPU都拉一根NVLink铜缆连到全世界。CXL这个新玩家则切了一个过去没人真正做好的蛋糕——它解决的是内存层面的扩展和共享让计算节点之间可以把内存当作本地内存一样访问而不是像网络那样“发消息、收消息”的模型。换句话说你想让4张GPU在一台机器里协同训练一个大模型NVLink是答案你想把几百台机器组成一个训练集群以太网是基础设施你想让一台机器用上隔壁机器的空闲内存或者在多台机器之间构建一个统一的内存池CXL才是对路的那个。这篇文章不打算写成教科书式的协议科普而是从实际工程选型和排障的角度把我这些年看过的、踩过的、测过的真实感受整理出来。里面有NVLink的拓扑细节和带宽计算方式有CXL跟PCIe的血缘关系也有以太网在AI集群里被重新定义的几个关键变化。如果你正在规划一台多卡服务器、设计一个训练集群或者单纯被这些名词搞得很焦虑这篇应该能帮你把思路理顺。2. NVLink的统治力来源不是“更快的PCIe”而是一套完整的私有总线架构很多人对NVLink的第一个误解就是觉得它只是把PCIe的通道做宽、频率做高本质上还是同类东西。这个理解错得很离谱。NVLink在架构层面跟PCIe是完全不同的设计思路它的目标是建立一张GPU之间的全互联网络而不是简单地“把数据从A搬到B”。2.1 从PCIe到NVLink为什么PCIe撑不住多卡训练要理解NVLink存在的理由先得看清楚PCIe在这个场景里卡在哪。PCIe总线的设计初衷是“通用I/O”——CPU要访问硬盘、网卡、声卡、显卡走的都是同一条总线它的核心追求是兼容性和低成本而不是极致的点对点带宽。即便到了PCIe 5.0单条x16通道的双向带宽也只有64GB/s而且这个数字是所有挂在这条总线上的设备共享的。当你在一个PCIe Switch下面挂了4张GPU它们之间的通信要经过PCIe Switch转发时延和带宽损耗都很难看。我在实际测过基于PCIe互联的四卡训练跑一个简单的all-reduce操作带宽利用率能到六成就算不错。而当模型并行度提高、梯度同步越来越频繁的时候PCIe成了整个训练流程里最明显的瓶颈。NVLink就是在这个背景下诞生的——NVIDIA从Volta架构开始直接在GPU芯片上加了一套专属于GPU之间通信的总线不走PCIe那套仲裁和路由机制而是点对点直连协议精简时延低得多。2.2 NVLink关键机制双工带宽、直接内存访问和域拓扑NVLink在技术上值得展开的细节有好几个最重要的我觉得是三点真正的双向全双工、对等内存访问的能力、以及通过NVSwitch扩展出的全域拓扑。先说双工。NVLink的带宽标称经常让很多人兴奋比如H100的NVLink带宽标称900GB/sB200时代是1.8TB/s。这里要提醒一句这个数字通常是双向双工的总带宽也就是读和写同时进行时的合计值。如果只算单方向的峰值要除以2。这个误会对容量规划很重要——你在估算梯度同步理论上限的时候如果拿双工带宽去算会得出一个过于乐观的结论。第二点是对等内存访问。NVLink不只是传输数据的管道它实现了GPU之间的“直接内存访问”简单说就是GPU A可以直接读GPU B的显存地址不用先把数据拷到CPU内存再拷过去。这听起来好像理所当然但在PCIe时代跨设备显存访问是要CPU参与“搬运”的那一步的开销非常可观。NVLink把这个“搬运”过程压缩到了硬件层面自动完成这让数据并行训练里的梯度集合操作省了大量时间。第三点是NVSwitch和NVLink域。当GPU数量超过一定规模全互联的“每张卡连到每张卡”在物理上是没法做到的——你想一想8张卡两两相连那就是28条链路的“全连接网”到了64张卡就是2016条链路PCB上根本放不下。NVSwitch的引入改变了这个局面GPU先连到NVSwitchNVSwitch之间再高速互联整个系统看起来像是一个虚拟的全连接网络。这意味着任何一张GPU到另一张GPU的逻辑路径都是“一跳”的带宽损失被控制在很小的范围内。2.3 一张表看清NVLink各代的带宽演进我自己整理了一张表方便你快速对比各代产品架构对应GPU单GPU NVLink带宽双向关键改进VoltaV100300 GB/s第一代NVLink多GPU直连AmpereA100600 GB/s引入NVSwitch三代域内带宽提升HopperH100900 GB/s支持更强NVLink域跨节点规模扩大BlackwellB2001.8 TB/s带宽翻倍功耗效率同步改进从V100到B200NVLink的单卡带宽翻了三番这个提升力度比同期PCIe的迭代幅度大得多。这也是为什么NVIDIA能理直气壮地说“多卡训练就用NVLink别折腾别的”——在单机柜尺度内在通用I/O标准里没有任何一个协议能在延迟和带宽两个维度上同时追平它。不过NVLink的强大也有代价它基本是NVIDIA的私有生态AMD的GPU用不了Intel的GPU也用不了而且NVLink域有规模上限H100的域是单机柜内数十张级别再往上就要靠网络协议来跨越了。这就自然引出了下一层的问题——跨机器、跨机柜靠什么连3. CXL的真实定位它连的是内存而不只是“另一个高速接口”CXL在热搜词里经常跟NVLink并列出现但它俩的出发点完全不同。我举个例子你就明白了NVLink解决的是“两个芯片怎么一起算”CXL解决的是“芯片怎么访问更大的内存池”。前者是协同计算的通道后者是扩展内存的通道。这两件事在超大规模计算里都重要但解决的问题根本不是一个维度。3.1 CXL从PCIe“长出来”但走了一条不同的路CXL其实是在PCIe的物理层上发展出来的协议。你可以把它理解为它借用了PCIe的“路”但跑了一套更聪明的“交通规则”。CXL规范目前主要分三种协议CXL.io负责设备发现和初始化跟PCIe很类似CXL.cache负责让CPU访问设备内存时保持缓存一致性CXL.mem则是让系统把设备上挂的内存当成系统内存的一部分直接使用。这里最值得展开的是CXL.mem带来的“内存池化”概念。传统上每台服务器的内存是固定挂在CPU旁边的DIMM插槽上的容量上限就是主板能插多少条内存。而在CXL架构下你可以把一柜子的内存通过CXL交换机聚合成一个大的内存资源池哪个节点需要更多内存就从池子里动态划分给它。这台机器内存不够用了另一台机器空闲着几十GB过去只能通过软件层面的远程内存调度勉强凑合CXL允许硬件层面就直接支持这种“借内存”的操作时延比网络远程内存访问低得多容量又比本地DIMM灵活得多。这背后的关键机制是缓存一致性。让CPU访问不属于本地主机的物理内存而不出乱子需要在硬件层面维护一致性协议——也就是当多个CPU核、多个设备都在读写同一块物理内存区域时它们看到的必须是一致的数据。CXL.mem通过发送缓存行粒度的读写请求和监听消息来保证这一点粒度比网络缓存机制细得多。3.2 为什么CXL被归类进“片间互联”但和NVLink关注的尺度不一样很多人把CXL跟NVLink放在同一类里做对比我猜主要是因为intel、NVIDIA这些厂商都在“片间互联”这个筐里发布了相关产品。但较真地说CXL更准确的定位是“节点内部和节点近邻的缓存一致性内存互联”它的尺度需求是机架级而不是GPU之间那种亚微秒级别的数据搬运。NVLink的一条关键数据是GPU之间的all-reduce操作时延可以压到微秒级以下而CXL内存访问的典型时延在数百纳秒到微秒之间跟本地内存的访问时延差距还在一个量级内但比直接走网络的远程内存访问快一个数量级以上。所以CXL适合的场景是“我需要更多内存”而不是“我需要更高的GPU间同步带宽”。这个区分特别重要。当你做显存密集型推理或训练比如某些大模型的KV Cache把显存吃满、需要把部分状态放到远端时CXL能提供一个比“走以太网拉到另一台机器”好得多的中间层。而当你在做模型并行、张量并行时每步计算都要同步大量梯度那种通信密集场景下CXL替代不了NVLink。简单说CXL把内存延展出去了NVLink把算力粘合起来了。3.3 实操视角评估CXL选型时的几个关键点CXL现在到了什么成熟度如果你去做选型有些点必须提前想清楚。第一CPU和内存控制器的支持。要真正利用CXL.memCPU的集成内存控制器必须支持CXL协议英特尔和AMD的新一代服务器CPU都已经或即将支持但具体到每一代主板和BIOS功能开启情况差异很大。我见过不少人在老主板上试CXL内存扩展卡结果只能当普通PCIe设备识别完全发挥不了内存池化的作用。第二CXL内存的容量和带宽比本地内存有明显差距。第一代CXL内存时延大概是本地DDR5的两到三倍带宽大概是本地的一半多一些。这意味着它适合做容量扩展不适合做热数据和频繁访问场景的替代。做系统设计时要把热数据放在本地内存把冷数据和低频率访问的数据放在CXL扩展内存或池化内存里这个分层思想很关键。第三CXL交换机生态还没完全成熟。内存池化的终极形态需要CXL Switch来连接多个主机和多个内存池模组但目前可商用的CXL交换机产品还不多OCP相关规范还在演进中。如果你现在就要落地这个方案大概率是先做点对点的内存扩展而不是一步到位做机架级内存池。CXL的价值在于它把“内存是每个节点私有的”这个几十年来的物理约束松动了。对于云厂商和超大规模计算中心来说这直接意味着内存利用率可以显著提升因为不用再为每个节点预留一大堆冗余内存以应对峰值需求了。4. 以太网为什么能在AI集群里重新翻红RoCE、无损网络与新的加速标准聊完了两种“私有/半私有”的互联方案该回到最基础、最通用的以太网了。你可能会问以太网不是传统I/O网络吗它真的能承担片间互联的职责吗说实话在很多AI集群里以太网已经是实打实的“主力军”只是它用的方式发生了一些关键变化。4.1 从“尽力而为”到“无损可靠”RoCEv2重塑了以太网的高性能能力传统以太网是“尽力而为”的传输模式——数据发出去能不能到、什么时候到网络层不保证。TCP协议在传输层做了可靠性和重传机制但在高性能分布式训练场景下TCP的重传和拥塞控制带来的时延抖动很要命。RDMA over Converged Ethernet这个协议的出现改变了一切。它把RDMA远程直接内存访问的能力搬到以太网上来让网卡可以直接把数据从一台机器的应用内存搬到另一台机器的应用内存跳过操作系统的协议栈和CPU拷贝数据传输的CPU占用率大幅降低。更重要的是RoCEv2的操作是“有损的底线”网络结构必须被配置成“无损”模式来确保不丢包——如果万一丢了包性能和稳定性都会急剧恶化。这个概念怎么理解呢你可以把普通以太网想象成一条经常堵车的城市道路偶尔有追尾丢包司机也不在乎慢慢再走就行。但RoCE环境是高铁轨道每列车都是按极高速度和极短间隔运行的一列车追尾后面一整串全得停恢复的时间成本极高。所以RoCE要求网络里的交换机和网卡启用PFC优先级流量控制和ECN显式拥塞通知等机制把丢包的可能性压到最低。4.2 无损网络的设计要点PFC、ECN和缓冲管理要把RoCE跑得好网络设计是一个专门的活。我提三个我在项目里实际踩过坑的地方。第一是PFC的“死锁”陷阱。PFC允许交换机在接收缓冲区满的时候向对端发送暂停帧让对方停一下给自己时间处理积压的数据。看起来很美但如果你在多个端口上不加区分地启用PFC可能造成“某一个端口的暂停信号波及到其他优先级流量”的连锁反应导致整个网络吞吐暴跌甚至出现PFC死锁。我见过一次很典型的故障某个机柜的RoCE流量突然从40Gbps掉到几百Mbps查到最后就是PFC配置时把控制流量的优先级也卷进来了控制面板消息被暂停帧卡住全网路由协议震荡。设计RoCE网络时第一件事就是把流量的优先级规划好——哪些队列允许PFC哪些不允许一定要提前定死绝不能图省事全开。第二是ECN的阈值调优。ECN的作用是让交换机在拥塞前就标记数据包网卡收到标记后自动降低发送速率。但ECN的阈值设得太低会导致传输速率不必要地频繁下降设得太高又起不到预警作用。这里没有通用值得根据实际业务的队列深度和时延预算做一轮轮测试。我通常的调法是先用交换机厂商的默认推荐值跑一套基准测试然后逐步降低阈值的百分比观察吞吐和时延曲线找到拐点再反向微调。第三是缓冲管理。无损网络里交换机缓冲区就是“蓄水池”水来得太猛时靠它缓冲。不同交换机的缓冲大小差异巨大有些廉价交换机的缓冲只有几百KB跑RoCE几乎不可能稳定这也是为什么很多AI集群宁可多花钱上高端交换机——它们的缓冲大、调度算法成熟能有效吸收微突发流量。4.3 以太网相对NVLink和CXL的真正优势规模、生态和开放说到这儿以太网的定位就很清楚了。它的延迟虽然比NVLink高一到两个数量级带宽在单链路层面也做不到NVLink那种TB级协商速率但它的优势在于三点。一是规模无上限。NVLink域有物理边界CXL内存池也有机架级限制但以太网能从一台机器的一个网口延伸到全世界的任何一台机器。大规模训练集群动辄几千张GPU靠的只能是网络协议而不是私有总线。二是生态极其开放。从网卡、交换机到线缆有无数厂商互相竞争价格和供应链的灵活性都不是私有协议能比的。三是技术迭代速度极快。以太网标准本身在从400G往800G和1.6T演进加上无损网络特性的加持实际能提供给分布式训练的有效带宽在持续提升。现在的趋势是AI训练集群普遍采用“混合互联”架构机柜内部的GPU用NVLink机柜之间的规模扩展用RoCE以太网或者InfiniBand。很多人问我InfiniBand跟以太网怎么选我的态度很务实如果单看峰值性能和生态成熟度InfiniBand在超大规模HPC里表现很强但如果你已经有大规模以太网运维经验、预算有限、又不喜欢被一家厂商的私有协议捆绑RoCE以太网是性价比非常高的选择。5. 选型实战从带宽、时延、成本、生态四个维度对比这三个协议前面把三个协议各自的定位和特性讲清楚了这一节直接给出选型时的对比思路。做技术选型不能只看纸面指标还得结合你手里的工作负载、预算和组织现状来权衡。5.1 关键性能指标对比维度NVLinkCXL以太网RoCE典型带宽600GB/s - 1.8TB/s单GPU双向约64-128GB/s当前CXL 3.0100Gb/s - 800Gb/s单链路典型时延微秒级以下数百纳秒至微秒级数微秒至数十微秒通信模型GPU直接内存访问缓存一致性的内存扩展RDMA需处理网络协议互联范围单机柜/单域机架级/机柜级全局无边界生态开放性私有NVIDIA开放标准PCIe SIG等开放标准IEEE/OCP主要成本私有专有硬件单价高新品初期成本较高标准化设备竞争充分这张表是我做决策时的“第一张过滤网”。如果你的核心瓶颈是GPU之间的梯度同步那NVLink的吸引力是压倒性的如果你在做大规模推理服务、内存容量不足CXL值得认真评估如果你要构建一个上千卡规模的训练集群以太网几乎是唯一的主流开放选项。5.2 从应用场景倒推协议选择选型的核心逻辑不是“哪个性能好选哪个”而是“我这个应用最痛的点是什么最可能被哪个协议治好”。单机多卡大模型训练模型大到需要张量并行或流水线并行显存不够放一整份模型需要多卡协同——第一选择一定是NVLink。原因无他张量并行的每一层计算都依赖跨卡通信通信时延直接决定训练效率。我用H800做过一个实验同一个模型在NVLink环境下的训练吞吐比走PCIe高出一倍还多那个差距不是优化代码能补回来的。推理场景显存不足模型推理时要把权重加载到显存当显存不够时传统做法是把部分层放到CPU内存用PCIe搬运效果很差。CXL内存扩展在这里有非常大价值把不常用的权重放CXL内存常用权重留在显存访问CXL内存比访问远端CPU内存快得多推理启动时间和吞吐都能明显改善。如果你现在就有“显存不够但又不想买更大显存卡”的痛CXL是值得关注的方向。大规模分布式训练当你的训练集群超过一个机柜比如64卡以上就必须依赖网络来同步梯度。这里的核心决策是选InfiniBand还是RoCE。InfiniBand性能好、生态完整但价格让人肉疼RoCE成本可控、运维经验和工具链更通用。我个人的经验是如果你的团队对Linux网络和交换机配置很熟RoCE完全能担起重任不必迷信InfiniBand。5.3 成本、功耗和运维复杂度有时候比带宽数字更关键做工程决策的人都知道性能只是众多维度之一。我见过不止一个项目实验室里用NVLink做小规模测试效果惊艳一算规模扩大到几百卡的成本和散热直接打退堂鼓。NVLink的铜缆和光模块都很贵而且每个NVLink域都需要独立布线机柜的功耗密度也会显著提高。CXL现在还处在早期带CXL功能的CPU、内存模组、交换机的价格都不低生态还不够成熟落地时要做好“做小白鼠”的心理准备。以太网则便宜得多标准化程度高二手设备也好买好卖运维工具链从Wireshark到各种网管平台都很成熟。从运维复杂度来看NVLink域基本是“黑盒”——NVIDIA自己维护驱动和firmware你只能通过nvidia-smi和DCGM工具查看健康状态。CXL目前还需要BIOS和操作系统层面的深度配合配置过程相对繁琐。以太网的运维复杂度则来自“无损网络调优”这一层——PFC、ECN、缓冲管理的配置和排障需要一个有经验的网络工程师。很多AI团队低估了这一点直到出问题才发现跑RoCE的网络和对传统TCP网络的运维逻辑完全不是一回事。6. 趋势判断与实战忠告接下来几年的互联格局会怎么变这一节聊聊我这几年观察到的行业走向以及一些踩坑之后的实在话。6.1 三个我比较确信的趋势第一NVLink会继续往更高带宽和更大域扩展但它的“墙”会越来越明显。Blackwell的1.8TB/s已经接近电信号在PCB上的物理极限下一代必然要靠光互连或者共封装光学来突破。同时NVIDIA也在把NVLink从纯GPU互联扩展到GPU和DPU、GPU和存储之间的互联试图把整个机柜变成一台巨大的“超级GPU”。这个战略很清楚让计算、网络、存储的边界在机柜内全部模糊化从而锁死自己的生态位。第二CXL会逐步从内存扩展走向真正的资源池化。等CXL交换机成熟后内存池、甚至加速器池化都会成为现实这会让数据中心的资源利用率上一个台阶。但这条路没那么快我预估真正大规模部署还需要两三年。第三以太网在AI集群中的角色会继续变重。RoCE只是第一步UECUltra Ethernet Consortium正在制定面向超大规模AI的下一代开放网络标准它会在RoCE的基础上改进拥塞控制、多路径和负载均衡目标是让开放式以太网的性能无限接近InfiniBand。这对不想被NVIDIA私有协议捆绑的客户来说是个实实在在的好消息。6.2 实战排障经验几个最好提前知道的坑我在这个领域踩过的坑不少挑几个典型的分享出来。第一个是NVLink的健康检查。很多人默认NVLink只要驱动装好就能满速跑实际不是。有一回我在一个八卡机上做训练发现梯度同步时延异常偏高查了半天不是代码问题最后用nvidia-smi nvlink -s查看链路状态发现有一根NVLink链路处于降级状态——firmware升级后没做链路重训练导致的。建议每台多卡服务器上线前都把nvidia-smi nvlink -s的所有链路状态打一遍日志记录基线训练突然变慢时先查这个能省下大量排查时间。第二个是RoCE网络的“掉速但不报错”现象。无丢包网络里不会像TCP那样频繁重传所以很多掉速问题的表象是“吞吐降低但没有任何报错”原因是ECN的隐式降速在发力。排查时不要只盯着丢包率要同时看交换机的ECN标记计数和网卡的发送速率曲线。有一回我调一个40Gbps的RoCE连接应用层吞吐一直只有8Gbps网络层怎么看都“正常”最后发现是网卡的拥塞控制算法在ECN标记率超过某个阈值后直接把发送速率降到最低档调了一下ECN阈值就好了。第三个是CXL初期落地的BIOS坑。CXL内存在服务器上能不能被正确识别跟BIOS版本、内存训练算法都有关系同样的硬件换一版BIOS可能表现完全不同。我的建议是如果你要试CXL先选定一个“黄金组合”CPU型号BIOS版本CXL内存型号全部验证通过后再扩展不要一上来就追求多种硬件组合的兼容性。6.3 给选型者的最后一句实在话技术选型最忌讳的是“拿着单一指标做全局决策”。NVLink和CXL、以太网并不是同一条赛道上的对手它们更像是不同长度的“尺子”——NVLink管毫米级CXL管厘米级以太网管米级。真正高效的AI基础设施往往是这三把尺子同时上阵各管一段。我自己当前的混合实践是单机柜内的8卡训练全走NVLink显存告急的推理节点考虑加CXL内存扩展跨机柜、跨区域的大规模集群走RoCE无损网络。这样组合下来性能、成本和扩展性都能取得一个比较理想的平衡。你可以把它当成一个参考起点再结合自己的业务去调整。片间互联这件事说到底是把“计算”和“搬运”这两件事重新组合。将来计算单元的形态可能会变但“算得快”和“搬得快”的博弈会一直在。能把这两者匹配好的人在任何规模的数据中心里都不会过时。