企业官网建设流程全解析

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/s，B200时代是1.8TB/s。这里要提醒一句：这个数字通常是双向双工的总带宽，也就是读和写同时进行时的合计值。如果只算单方向的峰值，要除以2。这个误会对容量规划很重要——你在估算梯度同步理论上限的时候，如果拿双工带宽去算，会得出一个过于乐观的结论。

第二点是对等内存访问。NVLink不只是传输数据的管道，它实现了GPU之间的“直接内存访问”，简单说就是GPU A可以直接读GPU B的显存地址，不用先把数据拷到CPU内存再拷过去。这听起来好像理所当然，但在PCIe时代，跨设备显存访问是要CPU参与“搬运”的，那一步的开销非常可观。NVLink把这个“搬运”过程压缩到了硬件层面自动完成，这让数据并行训练里的梯度集合操作省了大量时间。

第三点是NVSwitch和NVLink域。当GPU数量超过一定规模，全互联的“每张卡连到每张卡”在物理上是没法做到的——你想一想，8张卡，两两相连，那就是28条链路的“全连接网”，到了64张卡就是2016条链路，PCB上根本放不下。NVSwitch的引入改变了这个局面：GPU先连到NVSwitch，NVSwitch之间再高速互联，整个系统看起来像是一个虚拟的全连接网络。这意味着任何一张GPU到另一张GPU的逻辑路径都是“一跳”的，带宽损失被控制在很小的范围内。

2.3 一张表看清NVLink各代的带宽演进

我自己整理了一张表，方便你快速对比各代产品：

从V100到B200，NVLink的单卡带宽翻了三番，这个提升力度比同期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.mem，CPU的集成内存控制器必须支持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 关键性能指标对比

这张表是我做决策时的“第一张过滤网”。如果你的核心瓶颈是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只是第一步，UEC（Ultra 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无损网络。这样组合下来，性能、成本和扩展性都能取得一个比较理想的平衡。你可以把它当成一个参考起点，再结合自己的业务去调整。

片间互联这件事，说到底是把“计算”和“搬运”这两件事重新组合。将来计算单元的形态可能会变，但“算得快”和“搬得快”的博弈会一直在。能把这两者匹配好的人，在任何规模的数据中心里都不会过时。