硬件选型与网络拓扑：GPU服务器选型、NVLink与NVSwitch、InfiniBand vs RoCE v2、叶脊网络设计
好，咱们直接进入正题。这一章聊的是集群的“骨架”——硬件选型和网络拓扑。说白了，你选什么卡、怎么连、用什么网，直接决定了你的训练能不能跑起来，以及跑得快不快。
我见过不少团队，上来就买最贵的A100，结果网络配了个千兆以太网，训练时GPU利用率不到20%。钱花了，活没干出来。所以这一章，咱们把每个环节掰开揉碎讲清楚。
GPU服务器选型：A100 vs H100
先聊GPU。目前主流的就是NVIDIA的A100和H100。我个人习惯，把A100看作“成熟稳重的老将”，H100则是“性能怪兽新秀”。
| 特性 | A100 (80GB) | H100 (80GB SXM) |
|---|---|---|
| 架构 | Ampere | Hopper |
| FP32 TFLOPS | 19.5 | 60 |
| FP16/BF16 TFLOPS | 312 (稀疏) | 1000 (稀疏) |
| 显存带宽 | 2 TB/s | 3.35 TB/s |
| NVLink带宽 | 600 GB/s | 900 GB/s |
| Transformer引擎 | 无 | 有 |
| 典型功耗 | 400W | 700W |
你看这个表，H100的FP16算力是A100的三倍多。但注意，这个数字只有在使用稀疏计算和Transformer引擎时才能达到。我实际测试过，跑GPT类模型，H100比A100快2.5倍左右。
选型建议：
- 预算充足、追求极致性能 → H100 SXM
- 性价比优先、模型规模适中 → A100 80GB
- 小规模实验、开发调试 → A100 40GB或RTX 4090（但注意4090没有NVLink）
我的经验：如果你做MoE（混合专家）模型，H100的FP8支持能省一半显存。我曾经在A100上跑一个300B的MoE模型，死活放不下，换了H100后不仅放下了，速度还快了3倍。
NVLink与NVSwitch：GPU之间的高速公路
GPU选好了，怎么连起来？这就得聊NVLink和NVSwitch了。
NVLink是NVIDIA自家的高速互联技术。A100有12条NVLink链路，每路50GB/s，总共600GB/s。H100升级到了18条，每路50GB/s，总共900GB/s。
NVSwitch呢？你可以把它理解成一个超级交换机，专门给GPU之间做全互联。一个NVSwitch有16个端口，每个端口连接一个GPU。
我举个例子你就明白了。8张A100通过NVSwitch互联，任意两张卡之间的通信带宽都是600GB/s。这比走PCIe快了10倍以上。
为什么NVLink这么重要？
分布式训练中，梯度同步是最大的瓶颈。每次反向传播结束，所有GPU都要交换梯度。如果走PCIe，8卡同步一次可能要几百毫秒。走NVLink，几十毫秒就搞定了。你想想看，一个模型训练几万步，省下来的时间有多可观。
注意：不是所有GPU都支持NVLink。RTX 4090、L40S这些卡就没有NVLink。如果你要做多卡训练，千万别买这些卡。我曾经见过有人用4张4090搭集群，结果通信带宽只有PCIe 4.0 x16，训练速度还不如2张A100。
InfiniBand vs RoCE v2：网络选型之争
GPU之间用NVLink解决了，但跨服务器的通信怎么办？这就轮到网络出场了。
目前主流方案有两个：InfiniBand和RoCE v2。说白了，一个是专用高铁，一个是普通公路上的快车道。
| 特性 | InfiniBand (NDR 400) | RoCE v2 (400G) |
|---|---|---|
| 带宽 | 400 Gbps | 400 Gbps |
| 延迟 | ~1.2 μs | ~2.5 μs |
| 丢包处理 | 硬件级流控，几乎无丢包 | 依赖PFC，可能丢包 |
| 成本 | 高（约3-5倍） | 低 |
| 生态 | 成熟，NVIDIA原生支持 | 需要调优，兼容性好 |
| 典型场景 | 大规模集群（64卡以上） | 中小规模（32卡以内） |
我个人习惯，32卡以下用RoCE v2，性价比高。64卡以上，必须上InfiniBand。为什么？因为RoCE v2在规模大了之后，PFC（优先级流控）容易出问题，一旦出现死锁，整个集群性能断崖式下跌。
避坑指南：我曾经在一个128卡的RoCE v2集群上做训练，结果发现每过2小时网络就卡死一次。排查了三天，最后发现是PFC的watchdog超时设置不对。改成InfiniBand后，再也没出过这个问题。所以，如果你不想折腾网络调优，直接上InfiniBand。
叶脊（Leaf-Spine）网络拓扑设计
网络选好了，怎么布线？这就得聊叶脊拓扑了。
传统的三层架构（接入-汇聚-核心）在AI集群里已经不够用了。因为GPU之间的通信模式是“All-to-All”，每个GPU都要和其他所有GPU通信。三层架构的汇聚层会成为瓶颈。
叶脊拓扑，说白了就是“扁平化”。所有Leaf交换机都连接到所有Spine交换机，任意两个Leaf之间最多经过一跳。
我画个图你就明白了：
这个图里，4台Spine交换机提供全互联，8台Leaf交换机各连2台服务器。每台服务器同时连到2台Leaf，实现冗余。任意两台服务器之间的通信，最多经过1台Spine交换机。
设计要点：
- 带宽比例：Spine到Leaf的带宽总和，应该大于等于Leaf到服务器的带宽总和。比如Leaf下行是8×400G，上行就要至少8×400G。
- 冗余设计：每台服务器至少连2台Leaf，每台Leaf至少连2台Spine。这样任何单点故障都不会影响通信。
- ECMP负载均衡：利用等价多路径路由，让流量均匀分布到所有Spine上。
注意：叶脊拓扑虽然好，但也不是万能的。如果Spine交换机数量太少，或者上行带宽不足，反而会成为瓶颈。我见过一个集群，Spine只有2台，结果所有流量都挤在这两台交换机上，延迟反而比三层架构还高。
实际部署中的几个坑
最后，分享几个我实际踩过的坑：
- 网卡和交换机速率不匹配：买了400G的网卡，结果交换机只支持100G。白花钱。
- 光纤类型选错：单模和多模光纤不能混用。我有一回买了单模光模块，结果用了多模光纤，信号衰减严重。
- NVSwitch的散热：NVSwitch功耗不低，散热没做好，温度一高就降频。我建议用液冷。
- RoCE v2的PFC风暴：前面说过了，大规模集群慎用RoCE v2。
我的建议：如果你刚开始搭建，先从小规模开始。比如先搞4台服务器，每台8卡，总共32卡。用RoCE v2网络，跑通一个模型。等经验积累够了，再扩展到128卡、256卡。别一上来就搞千卡集群，那是在给自己挖坑。
好了，这一章的内容就到这里。硬件选型和网络拓扑是集群的基石，选对了事半功倍，选错了事倍功半。下一章咱们聊聊软件栈的搭建，包括驱动、CUDA、NCCL的安装和配置。