硬件拓扑与链路：从单机到集群的通信骨架
做GPU集群，说白了就是在跟通信瓶颈较劲。我这些年调过的集群，十有八九的性能问题都出在拓扑上——不是带宽不够，就是延迟太高，再不然就是链路被某个大模型训练任务给撑爆了。今天咱们就把这些硬件链路掰开揉碎了讲清楚。
NVLink与NVSwitch：GPU之间的高速公路
先聊聊单机内部的GPU互联。NVLink这东西，我最早接触是在P100时代，那时候还是2.0版本，带宽只有160GB/s。到了H100的NVLink 4.0，单条带宽已经飙到900GB/s了。你想想看，这速度有多夸张？
核心要点：NVLink是NVIDIA私有的高带宽、低延迟互联技术，专门用于GPU之间的直接通信。它绕过了CPU和PCIe，让GPU之间可以像共享内存一样交换数据。
NVSwitch则是NVLink的集线器。一个NVSwitch芯片有64个NVLink端口，可以组成全互联拓扑。我在部署DGX A100的时候，8张GPU通过6个NVSwitch芯片实现了全互联——任何两张GPU之间都有3条NVLink链路，带宽高达600GB/s。
为什么会需要这么高的带宽？你想想大模型训练时的All-Reduce操作，几百GB的梯度要在所有GPU之间同步。如果走PCIe，那延迟和带宽都扛不住。NVLink+NVSwitch的方案，说白了就是把GPU集群变成了一个巨大的「GPU内存池」。
实战经验：我曾经在调优一个千亿参数模型时发现，单机内8卡通信只用了不到30%的NVLink带宽。后来一查，是数据并行策略没配好，梯度分片太小，导致小包通信占满了NVLink的链路层开销。把梯度分片从4MB调到64MB后，带宽利用率直接飙到85%。
InfiniBand与RoCEv2：跨节点的生死抉择
跨节点通信，目前就两个主流选择：InfiniBand和RoCEv2。我两个都用过，各有各的脾气。
| 特性 | InfiniBand | RoCEv2 |
|---|---|---|
| 带宽 | HDR 200Gbps / NDR 400Gbps | 100Gbps / 200Gbps / 400Gbps |
| 延迟 | ~1μs（端到端） | ~3-5μs（端到端） |
| 拥塞控制 | 硬件级，原生支持 | 依赖DCQCN等软件方案 |
| 成本 | 高（交换机+网卡都贵） | 中（利用现有以太网） |
| 生态 | NVIDIA独家，但成熟 | 开放，厂商多 |
InfiniBand，我个人习惯叫它「贵族方案」。它的拥塞控制是硬件实现的，你几乎不用操心。我在一个256节点的集群上跑过LLaMA-65B训练，IB网络下的All-Reduce延迟只有RoCEv2的1/3。但代价呢？一台Mellanox QM9700交换机就要几十万。
RoCEv2，说白了就是「以太网上的RDMA」。它便宜，但坑也多。我曾经在一个RoCEv2集群上遇到「PFC死锁」——某个节点发了个大包，把整个网络的优先级流控给卡死了，所有GPU通信全部挂起。查了三天才发现是某个交换机的PFC阈值配错了。
避坑指南：我曾经在RoCEv2集群上部署时，忽略了DCQCN参数的调优。默认配置下，一旦出现拥塞，带宽直接掉到30%。后来参考了NVIDIA的官方调优指南，把α、β、γ三个参数重新配了一遍，才把带宽拉回到95%以上。记住：RoCEv2不是即插即用的。
PCIe Gen4/Gen5拓扑：被忽视的瓶颈
很多人只盯着NVLink和IB，却忘了PCIe这个「老黄牛」。实际上，GPU和CPU之间的通信、NVMe SSD的访问，全得走PCIe。
PCIe Gen4 x16的单向带宽是32GB/s，Gen5翻倍到64GB/s。听起来不错？但你要知道，一张H100的显存带宽是3.35TB/s。PCIe这点带宽，连显存带宽的零头都不到。
我建议你关注两个点：
- PCIe拓扑结构：CPU直连的PCIe通道数有限。比如AMD EPYC 7763有128条PCIe Gen4通道，Intel Xeon Platinum 8380只有64条。如果一张GPU占16条，那8张GPU就要128条——CPU直连根本不够，必须通过PCIe Switch扩展。
- 跨Socket通信：双路服务器里，GPU如果挂在不同的CPU Socket上，跨Socket通信要走Infinity Fabric或UPI。这个延迟比同Socket通信高2-3倍。我建议把同一张GPU的通信尽量限制在同一个Socket内。
实战案例：我在一个4路服务器上部署8卡训练时，发现GPU0和GPU4之间的通信延迟比GPU0和GPU1高了4倍。一查拓扑图，GPU0挂在Socket0上，GPU4挂在Socket2上，中间要跨两个Socket的UPI链路。后来我把数据并行的rank映射调整了一下，让同一个模型副本的GPU尽量在同一个Socket内，训练吞吐提升了18%。
跨节点与跨机柜拓扑：胖树与Dragonfly+
当集群规模超过几百个节点时，网络拓扑就成了决定性因素。目前主流就两种：胖树（Fat-Tree）和Dragonfly+。
胖树拓扑，说白了就是「多级交换机堆叠」。比如一个三层的胖树：Leaf层连接GPU节点，Spine层做汇聚，Core层做核心交换。它的好处是带宽可以线性扩展——你加节点，就加Leaf和Spine交换机就行。
但胖树有个问题：跨机柜通信的跳数多。一个256节点的胖树，跨机柜通信可能要经过6跳交换机，延迟增加不少。
Dragonfly+拓扑，这是Cray（现HPE）搞出来的方案。它的核心思想是「分组全互联」——把节点分成多个组，组内全互联，组间通过少量全局链路连接。这样跨机柜通信只需要2-3跳，延迟低很多。
我记得在部署一个512节点的集群时，我们对比了胖树和Dragonfly+的方案。同样跑All-Reduce，Dragonfly+的延迟比胖树低了40%。但代价是Dragonfly+的布线复杂度高，而且对路由算法要求高——路由配不好，很容易出现「热点链路」。
选型建议：如果你的集群规模在128节点以内，胖树就够用了，成本低、运维简单。超过256节点，我建议认真考虑Dragonfly+。不过要做好心理准备——Dragonfly+的故障排查比胖树难一个数量级。我曾经花了两周才定位到一个Dragonfly+的路由环路问题。
知识体系总览
下面这张图，是我梳理的GPU集群通信拓扑的核心逻辑。从单机内部的NVLink/NVSwitch，到跨节点的InfiniBand/RoCEv2，再到跨机柜的胖树/Dragonfly+，每一层都有它的瓶颈和优化点。
嗯，这张图把三层拓扑串起来了。你从上往下看，每一层的带宽都在下降，延迟都在增加。所以优化通信的关键，就是尽量让数据在「低层」完成交换——能走NVLink就别走IB，能走IB就别走胖树。
最后说一句：硬件拓扑是死的，但人的脑子是活的。我见过太多人拿着顶级硬件却跑不出性能，也见过有人用中端硬件通过拓扑优化把性能翻倍。记住，理解拓扑，才能驾驭集群。