从NVLink到NVSwitch：多GPU互联如何决定大模型训练性能

我调一套 16 卡 A100 训练任务时遇到过一件怪事同样的模型从 8 卡换成 16 卡理论算力翻倍可每轮迭代时间只降了不到 10%。一开始怀疑数据加载后来怀疑框架版本最后查出来是卡和卡之间的通信拓扑拉了后腿。那时候我真正意识到GPU 服务器里值钱的不只是芯片算力还有让 GPU 之间能高效对话的那张“网”。这张网的核心就是 NVLink 和它背后的 NVSwitch。如果你也在做分布式训练、推理基础设施或者只是单纯想搞明白“为什么 NVIDIA 的机器越来越像一台超大型计算机”那这篇博文值得看完。我不会堆太多官方术语而是从工程视角讲清楚两件事NVLink 解决的是单条路够不够快NVSwitch 解决的是很多条路同时跑会不会堵死。说白了NVLink 是高速公路本身NVSwitch 是让几十条高速路交汇而不撞车的立交桥两者缺一不可。1. 先把 NVLink 直连的底牌翻出来1.1 NVLink 本质是给 GPU 修的一条高速通道在 NVLink 出现之前多 GPU 通信主要走 PCIe。PCIe 的问题不是不能用而是太“正式”了每个数据包要经过 CPU、内存、驱动延迟高带宽也被 PCIe 总线共享压得死死的。NVLink 不一样它直接打通 GPU 到 GPU 的物理通道走的是显存地址空间。这句话什么意思意思是 GPU 可以直接 load/store 另一块 GPU 的显存就像访问本地显存一样不需要先把数据搬到 CPU、再通过驱动发出去。这对 AllReduce、AllGather 这种梯度同步操作是质变因为梯度本质上就是显存里的数据NVLink 可以让它们在 GPU 之间直接流动。带宽数字更能说明问题。PCIe Gen5 x16 的单向带宽大概是 64GB/s双向 128GB/s。而 NVLink 3.0 单条链路单向就有 50GB/s双向 100GB/s到了 NVLink 4.0单条链路单向 100GB/s双向 200GB/s。单卡如果配上 18 条 NVLink 链路总带宽能到 900GB/s 甚至更高。这个量级不是拿来算小数的是拿来灌大模型梯度的。1.2 8 卡全互联为什么能成立早期多卡互联最直观的做法是“全互联”每两个 GPU 之间拉一条专用链路谁和谁通信都不干扰。这就像几个朋友凑一起开会每个人需要说话时直接喊一嗓子不用经过传话筒。在 2 卡、4 卡时代这种方案非常好用。双卡 NVLink Bridge 就是典型的 2 点直连4 卡节点在 PCB 上也能用几条 NVLink 串出比较理想的拓扑。到了 8 卡NVIDIA 凭借 A100 每卡 12 条 NVLink 链路的规格再加上几颗 NVSwitch 辅助照样能做到逻辑上的“任意两卡直达”。全互联最大的优点是直觉上很公平任意两个 GPU 之间都有物理链路端到端延迟极低不需要额外交换机转发。所以很多人第一次接触多卡服务器看到nvidia-smi topo -m里面的 NV 标记会下意识觉得“这不就够了吗还要 NVSwitch 干嘛”问题在于这个“够”只发生在 GPU 数量很小的时候。一旦卡数上去全互联的数学账就开始爆炸。1.3 全互联的数学瓶颈每次加卡链路数都在爆炸全互联的链路数是组合数公式N 张卡全互联需要 N(N-1)/2 条链路每张卡需要 N-1 个端口。我列几个数你感受下4 卡需要 6 条链路每卡 3 个端口还好。8 卡需要 28 条链路每卡 7 个端口A100 的 12 条 NVLink 勉强覆盖。16 卡需要 120 条链路每卡 15 个端口已经超过当前所有 GPU 的物理端口数。32 卡需要 496 条链路每卡 31 个端口完全不可行。链路数是平方级增长而 GPU 芯片面积是固定的不可能无限堆 SerDes 端口。就算你能在芯片上塞下 31 个端口PCB 走线、连接器、机箱空间也撑不住。这就是“有了 NVLink 还需要 NVSwitch”的最根本原因NVLink 把单条链路的带宽做到了极致但没法解决链路数量爆炸的问题。2. 直连的墙主要撞在四个地方2.1 端口数量是硬上限芯片上每一个 NVLink 端口对应一组高速 SerDes这组 SerDes 要占芯片面积、要耗电、要散热。GPU 芯片面积是寸土寸金要留给 CUDA Core、Tensor Core、L2 Cache、显存控制器不可能无限划给互联逻辑。以 H100 为例单卡 18 条 NVLink 链路已经算很激进的互联设计再往上堆端口成本会指数级上升而且收益递减。到 16 卡、32 卡这个规模唯一现实的选择就是让 GPU 只保留“够用”的端口数其余互联功能交给专用交换机芯片去承担。2.2 物理走线、板材与信号完整性很多人只看链路数容易忽略物理实现的痛苦。一条 NVLink 4.0 链路是 100GB/s 级别的差分信号对对 PCB 板材、走线长度、阻抗匹配都有严格要求。8 卡全互联的 28 条链路已经让机箱内部密密麻麻16 卡的 120 条链路会让 PCB 层数暴涨、背板连接器数量失控信号质量也会因为串扰和反射急剧下降。我见过一些非原厂的多卡服务器PCB 布线做得粗糙结果表面看拓扑是连着的实际跑起来带宽只有标称的六成。原因就是走线过长、过孔太多信号完整性不行。NVSwitch 的做法是把大量链路集中到交换芯片内部走线外部只需保证 GPU 到交换芯片这一段短而规整这样物理设计反而更容易做。2.3 并发争抢与带宽一致性全互联拓扑在“点对点单发”通信时很漂亮但真实训练场景不是单点通信而是所有 GPU 同时做集合通信。比如 AllReduce8 张卡要互相交换梯度如果走全互联直连某些链路会被流量打满另一些链路却空着流量模型高度不均。NVSwitch 交换平面则像一个大路口立交桥任意两个端口之间都有等宽的虚拟通路调度由交换芯片统一完成并发流量不容易出现某条物理链路成为瓶颈的情况。带宽一致性对大规模训练很重要因为集合通信的性能是“木桶效应”只要有一条链路慢整个迭代就得等它。2.4 算一笔工程账16 卡全互联 vs NVSwitch 方案我做了个简单对比表大家感受一下差距对比项16 卡全互联直连GPU NVSwitch 方案总链路数120 条每卡 6~18 条连接到交换平面总量可控每卡端口数15 个6~18 个按需设计不用把芯片塞满物理布线复杂度极高背板几乎不可能实现中等GPU 到交换芯片短距走线带宽一致性并发流量易不均交叉开关统一调度带宽一致性好可扩展性平方级爆炸几乎不可扩展线性增加交换芯片即可扩展典型产品小规模开发板、双卡桥接DGX、HGX、GB200 等系统表格一拉出来答案已经很明显。NVLink 直连适合小规模、点对点NVSwitch 交换是让 NVLink 域从小规模走向大规模的唯一可行路径。3. NVSwitch 到底做了什么值得单列一个芯片3.1 NVSwitch 的本质是 NVLink 的交叉开关交换平面NVSwitch 并不是网卡也不是普通的以太网交换机它是专门为 NVLink 协议设计的交换芯片。它的核心结构是一个 crossbar也就是交叉开关输入端的每一个 NVLink 端口都可以在芯片内部直接连接到任意一个输出端口不经过存储转发没有解包封包的过程。你可以把它理解成一个“内存语义的电话总机”。以前每个房间要跟其他房间两两拉一根专线现在每个房间只需要接到总机总机在纳秒级别帮你把线路切通。NVSwitch 转发的是 NVLink 的内存事务它直接理解 GPU 显存地址能完成点对点读写、原子操作延迟极低。这也是为什么 NVSwitch 的延迟比普通网络交换低好几个数量级以太网交换要解析二层头、三层头、查路由表、排队再转发NVSwitch 看到端口进来一个事务直接看目标地址在交叉开关里把输入和输出连通几乎不做额外处理。3.2 交叉开关让“任意两点等距”成为现实全互联直连虽然任意两点有物理链路但不同链路的物理长度、转发跳数可能不一样。NVSwitch 统一交换后所有 GPU 到交换平面的路径长度基本一致任意两个 GPU 通信的带宽和延迟都是可预期的。这对并行训练特别重要。比如张量并行里每个 Transformer 层的张量切分在不同 GPU 上前向和反向都需要频繁的 AllGather、ReduceScatter。如果 GPU 之间通信延迟不一致最慢的那一对会拖慢整个训练步。NVSwitch 让拓扑变得均匀训练框架就能更容易做负载均衡和算法优化。NCCL 在检测到有 NVSwitch 的大域时会倾向于使用更激进的通信模式比如基于 NVLink SHARP 的聚合直接在交换平面里做规约数据不需要全部回到 GPU 再算一遍带宽利用率会明显提升。3.3 NVSwitch 三代演进把互联域从板级拉到机柜级NVSwitch 不是新鲜东西从 Volta 时代就存在了但它的重要性是一步步提高的。第一代 NVSwitch 更多是辅助 8 卡全互联到了 A100 的 DGX 系统已经靠 6 颗 NVSwitch 完成 8 卡互联H100 的 DGX/HGX 则升级到 8 颗第三代 NVSwitch配合每卡 18 条 NVLink 链路整卡总带宽到了 900GB/s。真正让 NVSwitch 封神的是 GB200 NVL72 这类超节点。它用 36 颗 NVSwitch 把 72 个 GPU 连成一个 NVLink 域跨机柜通信依然能保持类似单机的带宽和延迟。这意味着一个大模型不再需要拆到多台机器用 InfiniBand 通信而是能在一个 NVLink 域内完成大部分集合通信把网络瓶颈往后推了一大截。所以 NVSwitch 的演进路径很清楚一开始只是“让 8 卡全互联更好做”后来是“让 16 卡、32 卡、72 卡都像一块大 GPU 一样工作”。没有 NVSwitchNVLink 最多也就服务 8 卡有了 NVSwitchNVLink 才能成为超节点架构的基石。3.4 为什么不能拿普通以太网交换机来替代每次讲到 NVSwitch总有人问用普通交换机不也一样吗我再说得直白一点完全不一样。协议不同NVLink 是点对点高速串行协议传输的是 GPU 内存事务以太网是报文协议有帧头、IP、TCP/UDP 封装。延迟不同NVSwitch 转发是交叉开关直达纳秒级以太网交换机至少是微秒级起还有队列拥塞、丢包重传。语义不同NVLink 支持直接读远端显存地址和原子操作像访问本地内存以太网则需要 RDMA 或 socketCPU 要参与数据搬运或至少做内存注册。流量模型不同训练场景的集合通信是高度同步、高并发、大块数据NVSwitch 的交叉开关天然适合这种模型以太网交换机则更适合流量随机、连接多、突发性强的网络。一句话以太网交换机解决的是“机器之间怎么传文件”NVSwitch 解决的是“GPU 之间怎么共享显存”。目标不同方案自然不同。4. 直连与交换的适用边界别一刀切4.1 什么时候全互联直连依然是最优解别看上面把直连说得局限实际很多场景全互联直连就是最优没必要上 NVSwitch。比如2~4 卡小集群做模型微调、单机多卡推理2卡或4卡用 NVLink Bridge 或板载直连成本低延迟极低性能已经够用。中小规模训练8 卡一台机器比如单机 A100/H100 做 LoRA、微调、中小模型预训练NVIDIA 原厂拓扑已经把 8 卡互通做好不需要额外操心。低延迟强绑定的局部通信某些模型并行中特定几张卡之间通信极其频繁让它们保持 NVLink 直连而不是绕经 NVSwitch可以减少一跳延迟。这种情况下硬上 NVSwitch 反而是浪费增加成本增加故障点还未必能跑出更高性能。工程上永远不要为了用某个技术而用某个技术。4.2 什么时候必须上 NVSwitch需要 NVSwitch 的特征也很明显单卡端口数不够覆盖全互联要组 16 卡以上且逻辑上仍然 “一卡直达任意卡”就必须靠交换平面。跨机柜/超节点需求GB200 NVL72 这种规模没有 NVSwitch 根本不可能把 72 卡组织成统一 NVLink 域。多租户动态切分数据中心里常需要把物理 GPU 动态分配给多个任务。NVSwitch 让任意 GPU 子集之间都可以组成高性能通信域而不是被固定直连拓扑绑死。集合通信密集的大模型训练当训练脚本的通信时间占比超过计算时间升级互联拓扑带来的收益比堆算力更明显。概括地说单机 8 卡以内直连够用超过 8 卡、追求大规模聚合通信效率、要做机柜级互联NVSwitch 基本是必选项。4.3 一张对比表快速判断判断维度直连拓扑更合适NVSwitch 交换更合适GPU 规模2~8 卡8 卡以上尤其是 16通信模式点对点、局部通信为主AllReduce/AllGather 等集合通信密集部署形态单机、单板、小集群超节点、机柜级、多租户数据中心成本敏感度高追求性价比低追求性能和规模扩展预期基本不扩展需要平滑扩展 GPU 数量做方案选型时先看规模和流量模型再看预算最后决定要不要上交换平面。5. 我踩过的坑关于 NVLink/NVSwitch 的三个常见误区5.1 误区一NVSwitch 是 NVLink 的替代品这是最常见的误解。很多文章把 NVLink 和 NVSwitch 并列对比好像二选一。实际上 NVSwitch 本身就依赖 NVLink 协议没有 NVLinkNVSwitch 就是一块没有灵魂的芯片。正确理解是NVLink 是链路层的技术标准NVSwitch 是交换层的实现NVSwitch 把很多条 NVLink 链路汇合起来形成一个更大的互连网络。它们不是竞争者而是从“点到点连接”到“多点交换网络”的两个层次。5.2 误区二看到 P2P 不可用就断定没有 NVSwitch我在代码里查 GPU 间能否直接访问时经常看到有人看到cudaDeviceCanAccessPeer返回 false就下结论说这台机器没走 NVLink/NVSwitch。这个判断不严谨。P2P 是否可用还取决于驱动、NUMA 拓扑、peer mapping 是否开启、操作系统策略。有些机器明明拓扑上有 NVLink但 P2P 被驱动或容器配置禁用了返回也是 false。反过来有些直连拓扑下 P2P 也可能可用。最靠谱的判断方式是看nvidia-smi topo -m里面NV代表 NVLink 直连PIX代表经过 PCIe 交换机PXB代表经过 PCIe 桥SYS代表走系统总线。看到大量NV且连接到同一个交换域才能说明 NVSwitch 在起作用。5.3 误区三NVLink 域越大NCCL 就一定越快NVLink 域变大确实能消除一部分跨机网络瓶颈但不是说域越大性能自动翻倍。NCCL 需要感知拓扑并选择合适算法直连拓扑下用 ring 可能不错交换拓扑下 tree 或 NVLS 可能更优如果框架没有正确识别 NVSwitch或者通信数据跨界频繁性能依然会拉胯。我在调 H100 的机器时发现同样的模型用默认 NCCL 参数和手动调整拓扑感知参数吞吐能差 15%~20%。这就是“拓扑对了算法也要跟上”的典型案例。5.4 排查 NVSwitch 是否生效的三个命令这里分享几个实操命令帮助你快速判断一台机器有没有 NVSwitch 在帮忙# 查看 GPU 拓扑矩阵重点是 NV 标记 nvidia-smi topo -m # 查看每对 GPU 的 NVLink 状态和带宽 nvidia-smi q -d NVLINK # 跑 NCCL 的 allreduce 带宽测试看是否接近 NVLink 标称值 # 需要提前编译 nccl-tests ./build/allreduce_perf -b 128M -e 8G -f 2 -g 8如果所有 GPU 之间都显示NV说明处于同一个 NVLink 交换域如果出现PXB或SYS说明部分通信走了 PCIe 或系统总线性能一定会打折。此时再去查驱动、BIOS 里有没有把交换平面正确打开。NCCL 测试也是个好工具。理论 NVLink 带宽 600GB/s 或 900GB/s实际 AllReduce 峰值跑到标称的 80% 以上算正常如果只有一半大概率是拓扑识别错误、NUMA 绑定不对、或者数据跨域了。6. 最后分享一个体会在 GPU 集群这个领域摸爬滚打久了我最大的体会是不要光盯着“单条链路多快”更要想清楚“这些链路怎么组织”。NVLink 解决了单点传输速度的问题NVSwitch 解决了多点互联规模和一致性的问题二者加在一起才构成现代超节点的基础。如果你正在规划多卡集群我的建议是先用nvidia-smi topo -m把现状看清楚再决定要不要为通信拓扑投入。很多时候性能卡点不是算力而是卡与卡之间那条看不见的路。理解 NVLink 和 NVSwitch 的关系是通往规模化部署的第一步也是训练框架调优里最容易被忽略但又最值得花时间的一环。