企业官网建设流程全解析

1. 从一张拓扑图说起：为什么A100和H100的组网完全是两回事

如果你最近在规划GPU集群，大概率会遇到一个很实际的问题：手里有一批A100或者A800的机器，想扩一批H100/H800进来，结果发现网络方案根本没法照搬。这不是简单的"换根线"或者"升级一下交换机"能解决的，因为A100和H100在硬件拓扑层面就是两代完全不同的设计思路。

我前后参与过几个不同规模的训练集群搭建，从8卡单机到几百卡的多机互联都踩过坑。最深的体会是：GPU服务器的组网方案，本质上是由GPU的互联架构倒推出来的。你用什么卡，就决定了你能用什么拓扑，进而决定了你的集群能跑多大的模型、训练效率能到多少。很多人在采购阶段只盯着GPU的算力和显存，忽略了互联带宽和拓扑设计，结果机器到了才发现，多机通信成了瓶颈，卡越多效率反而越低。

这篇文章主要面向正在做GPU集群规划、或者准备从A100平台迁移到H100平台的工程师和架构师。我会把A100/A800和H100/H800这两代典型的组网架构拆开来讲，包括机内互联、机间互联、交换机选型、拓扑设计，以及实际部署中那些文档里不会写的细节。不管你是刚接触GPU集群的新手，还是已经踩过一些坑的老手，应该都能从中找到对自己有用的东西。

2. A100/A800时代的组网逻辑：NVLink加InfiniBand的经典组合

2.1 机内互联：NVLink 3.0到底给了多少带宽

A100的机内互联用的是第三代NVLink，每张A100有12个NVLink通道，每个通道的带宽是50GB/s（双向），所以单卡的总NVLink带宽是600GB/s。这个数字听起来很吓人，但实际能用多少，取决于你的服务器平台怎么设计。

以最常见的DGX A100和HGX A100平台为例，8张A100通过NVSwitch全互联。NVSwitch的作用相当于一个NVLink交换机，让8张卡之间可以任意两两通信，不需要绕路。具体来说，HGX A100的基板上有6颗NVSwitch芯片，每颗负责一部分卡的互联，最终实现8卡之间的全带宽互联。

这里有个容易被忽略的点：A100 40GB和80GB版本的NVLink带宽是一样的，都是600GB/s。但80GB版本在显存带宽上有优势，HBM2e的带宽是2039GB/s，而40GB版本是1555GB/s。这个差异在训练大模型时会影响数据加载和参数更新的速度，但在组网拓扑上两者没有区别。

A800是A100的"合规版"，NVLink带宽被限制在400GB/s，其他规格基本一致。这意味着A800的机内互联能力比A100弱了三分之一，在8卡全互联场景下，通信密集型任务的效率会有明显下降。如果你手里是A800的机器，规划集群时要把这个带宽差异考虑进去。

2.2 机间互联：InfiniBand为什么是标配

单机8卡再强，也扛不住大模型。当模型参数量超过单机显存容量时，就必须做多机互联。A100时代的机间互联，主流方案是InfiniBand（IB），具体来说是HDR和NDR两代。

HDR IB的单端口带宽是200Gb/s（约25GB/s），NDR是400Gb/s（约50GB/s）。在A100集群里，常见的配置是每张GPU配一个HDR或者NDR端口，通过PCIe Gen4 x16连接到网卡。这里要注意，PCIe Gen4 x16的理论带宽是32GB/s，实际可用带宽大约25-28GB/s，所以HDR的200Gb/s（25GB/s）刚好能跑满，但NDR的400Gb/s（50GB/s）就会被PCIe瓶颈卡住。

这就是为什么A100时代HDR是主流，NDR虽然更快，但在A100平台上发挥不出来。如果你现在还在用A100搭集群，HDR的性价比明显更高。当然，如果考虑未来升级到H100，直接上NDR也没问题，只是当前会被PCIe限制。

机间互联的拓扑设计上，A100集群常见的是Fat-Tree或者Rail-Optimized架构。Fat-Tree的好处是任意两节点之间的通信跳数一致，延迟稳定；Rail-Optimized则是把同一位置的GPU（比如每台机器的第0号卡）连到同一组交换机上，适合All-Reduce这种通信模式。实际选哪种，取决于你的训练框架和通信库的优化程度。

2.3 一个典型的A100集群组网实例

假设你要搭一个32节点的A100集群，每节点8卡，总共256张A100。一个比较稳妥的方案是这样的：

• 机内：HGX A100 8-GPU基板，NVSwitch全互联，单卡NVLink带宽600GB/s
• 机间：每卡配一块HDR IB网卡，200Gb/s，通过PCIe Gen4 x16连接
• 交换机：两层Fat-Tree， leaf交换机用HDR IB交换机（比如40端口），spine交换机同样
• 存储：并行文件系统，通过IB或者以太网接入，带宽要能支撑所有节点同时读取数据

这个配置下，All-Reduce的通信效率大概能到理论峰值的70%-80%。实际训练GPT-3级别的模型时，通信开销大概占总时间的20%-30%。如果你把IB换成100Gb以太网，通信开销会直接翻倍，训练效率下降非常明显。

注意：A100的NVLink是全互联，但跨机通信必须走IB。如果你的模型并行策略设计得不好，跨机通信量过大，再好的IB也救不了。拓扑设计要和并行策略一起考虑。

3. H100/H800带来的变化：NVLink 4.0和PCIe Gen5重构了组网规则

3.1 NVLink 4.0：单卡900GB/s意味着什么

H100的NVLink升级到了第四代，每张卡18个NVLink通道，每个通道50GB/s，总带宽900GB/s。比A100的600GB/s提升了50%。但更关键的变化不是带宽数字，而是NVLink 4.0的拓扑灵活性。

H100的HGX基板上，NVSwitch也升级了。以HGX H100 8-GPU为例，基板上有4颗NVSwitch 3.0芯片，支持8卡全互联，单卡NVLink带宽900GB/s。但H100还支持一种叫"NVLink Switch System"的架构，可以把多个HGX基板通过NVLink连起来，形成更大的NVLink域。比如两个HGX H100基板可以通过NVLink互联，形成16卡的全NVLink域，这在A100时代是做不到的。

这个变化对组网的影响很大。在A100时代，跨机通信必须走IB或者以太网；到了H100时代，如果你用NVLink Switch System，跨基板的通信可以走NVLink，带宽和延迟都远优于IB。当然，代价是成本更高，而且NVLink Switch System的部署复杂度也更大。

H800是H100的"合规版"，NVLink带宽被限制在400GB/s，和A800一样。但H800的PCIe还是Gen5，机间互联可以用NDR IB或者400Gb以太网。这里有个坑：H800的NVLink带宽虽然被砍了，但它的单卡算力还是H100级别的，所以在算力密集型、通信不那么密集的场景下，H800的性价比反而更高。

3.2 PCIe Gen5：终于不拖后腿了

A100用的是PCIe Gen4，x16的带宽是32GB/s，实际可用25-28GB/s。这个带宽刚好卡住了HDR IB的200Gb/s（25GB/s），但NDR的400Gb/s（50GB/s）就跑不满。

H100升级到了PCIe Gen5，x16的带宽翻倍到64GB/s，实际可用50-55GB/s。这下NDR IB的400Gb/s（50GB/s）终于能跑满了。这意味着H100时代的机间互联，NDR成了标配，而不是像A100时代那样HDR就够用。

PCIe Gen5的另一个好处是，它让GPU和网卡之间的数据搬运更快，减少了通信延迟。在All-Reduce这种对延迟敏感的操作里，PCIe Gen5的贡献不小。实测下来，同样的NDR IB网络，H100平台的All-Reduce效率比A100平台高15%-20%，其中PCIe Gen5的贡献大概占三分之一。

3.3 H100集群的典型组网架构

一个32节点的H100集群，每节点8卡，总共256张H100，比较推荐的方案是：

• 机内：HGX H100 8-GPU基板，NVSwitch全互联，单卡NVLink带宽900GB/s
• 机间：每卡配一块NDR IB网卡，400Gb/s，通过PCIe Gen5 x16连接
• 交换机：两层Fat-Tree或者Rail-Optimized，leaf和spine都用NDR IB交换机
• 存储：并行文件系统，通过NDR IB接入，带宽要能支撑所有节点同时读取

如果预算充足，可以考虑NVLink Switch System，把两个基板连成16卡NVLink域。这样在16卡以内的通信完全走NVLink，不需要经过IB，延迟和带宽都有巨大优势。但超过16卡的通信还是得走IB，所以IB网络的设计依然不能马虎。

和A100集群相比，H100集群的通信效率提升很明显。同样的256卡规模，H100集群的All-Reduce效率能到理论峰值的85%-90%，比A100集群高10个百分点左右。这个提升在训练大模型时，意味着每天能多跑几个epoch，长期来看节省的时间非常可观。

4. A100和H100混搭组网：现实中的妥协方案

4.1 为什么会有混搭需求

现实中，很多团队不是一次性采购所有机器，而是分批扩容。比如先买了一批A100，后来预算下来又买了一批H100。这时候就面临一个很实际的问题：这两批机器能不能混在一个集群里用？

技术上是可以的，但有几个限制。首先，A100和H100的NVLink不兼容，不能放在同一个NVLink域里。所以混搭集群里，A100节点和H100节点各自内部用NVLink，节点之间统一走IB或者以太网。其次，A100的PCIe Gen4和H100的PCIe Gen5在机间互联带宽上有差异，如果都用NDR IB，A100节点会被PCIe Gen4限制，跑不满NDR的带宽。

实际部署时，常见的做法是：A100节点用HDR IB，H100节点用NDR IB，然后通过IB交换机把两代网络连起来。IB交换机通常支持向下兼容，HDR和NDR可以混插，但速率会协商到较低的一方。所以A100和H100之间的通信，实际跑的是HDR速率。

4.2 混搭集群的通信效率损失

混搭集群最大的问题是通信效率不均衡。H100节点之间的通信走NDR，A100节点之间走HDR，跨代通信走HDR。在All-Reduce这种全局通信操作里，最慢的那条链路决定了整体效率。所以混搭集群的通信效率，实际上是被A100节点的HDR带宽拖累的。

实测数据：纯H100集群的All-Reduce效率大概是85%-90%，纯A100集群是70%-80%，混搭集群大概在65%-75%之间。也就是说，混搭不仅没有提升，反而比纯A100集群还略低一点，因为H100节点要等A100节点。

如果你的训练任务对通信不敏感，比如是数据并行、梯度累积很大的场景，混搭的影响会小一些。但如果是模型并行、流水线并行这种通信密集的场景，混搭集群的效率损失会非常明显。

4.3 混搭集群的调度策略

如果确实要用混搭集群，调度策略很关键。一个比较实用的做法是：按任务类型分配节点。通信密集的任务优先分配到纯H100节点或者纯A100节点上，避免跨代通信。通信不密集的任务可以混跑，充分利用所有资源。

另外，可以在训练框架层面做优化。比如PyTorch的DDP（DistributedDataParallel）支持按节点分组，可以把A100节点和H100节点分成不同的组，组内做All-Reduce，组间做梯度同步。这样虽然还是会有跨代通信，但通信量会小很多。

提示：混搭集群的IB网络配置要特别注意。HDR和NDR混插时，交换机的端口速率协商可能会出问题，建议在交换机层面做好端口分组和QoS配置，避免低速端口影响高速端口的流量。

5. 交换机选型和拓扑设计：那些容易被忽略的细节

5.1 IB交换机的端口数和层级设计

IB交换机的选型，核心是端口数和速率。以NDR为例，常见的交换机有32端口、40端口、64端口几种。端口数决定了你能连多少节点，速率决定了单节点的带宽。

假设你有32个节点，每节点8卡，每卡一个NDR端口，总共256个端口。如果用一个64端口的NDR交换机，显然不够，需要至少4台。这时候就有两种拓扑选择：一种是单层，用4台交换机，每台连64个端口，节点之间通过交换机互联；另一种是两层Fat-Tree，leaf层和spine层分开。

单层拓扑的好处是延迟低，任意两节点之间只有一跳。但缺点是扩展性差，端口用完了就没法加节点。两层Fat-Tree的好处是扩展性好，可以加spine交换机来扩容，但延迟会多一跳。

实际选型时，如果集群规模在100节点以内，单层通常够用；超过100节点，建议直接上两层Fat-Tree。另外，IB交换机的管理端口和数据端口是分开的，管理端口用来做子网管理（Subnet Manager），这个一定要配好，否则网络起不来。

5.2 线缆和光模块的选择

IB网络的线缆和光模块，是另一个容易踩坑的地方。NDR IB用的是QSFP56或者OSFP封装，线缆有铜缆和光缆两种。铜缆便宜，但传输距离短，一般不超过3米；光缆贵，但可以传几十米甚至上百米。

机柜内的连接，通常用铜缆就够了，成本低，延迟也低。跨机柜的连接，必须用光缆，因为距离超过了铜缆的限制。光模块的选型要注意兼容性，不同品牌的交换机对光模块的要求不一样，建议用交换机厂商认证的模块，避免兼容性问题。

还有一个细节：IB线缆的弯曲半径。光缆弯曲过度会导致信号衰减，甚至断链。布线时要注意走线槽，避免急弯。铜缆虽然没那么娇气，但也不能过度弯折，否则会影响信号质量。

5.3 以太网方案能不能替代IB

这几年，RoCE（RDMA over Converged Ethernet）越来越成熟，很多团队在考虑用以太网替代IB。RoCE v2支持RDMA，带宽也能到400Gb，理论上可以替代IB。

但实际用下来，RoCE和IB还是有差距。IB的拥塞控制和QoS是原生的，延迟稳定，丢包率极低。RoCE依赖以太网的PFC（Priority Flow Control）和ECN（Explicit Congestion Notification）来做无损网络，配置复杂，而且不同厂商的交换机实现有差异，调优难度大。

如果你的集群规模不大（比如32节点以内），而且团队有以太网调优经验，RoCE可以考虑。但如果是大规模集群，或者团队没有专门的网络工程师，IB还是更稳妥的选择。IB的即插即用程度更高，Subnet Manager自动发现拓扑，配置量小很多。

6. 实际部署中的踩坑记录和排查思路

6.1 NVLink域和IB域的边界问题

有一次帮一个团队排查训练效率低的问题，他们的集群是16节点A100，每节点8卡，IB网络是HDR。理论上All-Reduce效率应该能到75%左右，但实测只有50%不到。

排查过程是这样的：先看单机8卡的NVLink通信，用NCCL的测试工具跑All-Reduce，效率能到95%以上，说明机内没问题。然后看跨机通信，发现跨机All-Reduce效率骤降到40%。检查IB网络，发现交换机的端口速率协商有问题，部分端口跑在了100Gb而不是200Gb。

进一步排查发现，是光模块的兼容性问题。他们用的光模块不是交换机厂商认证的，虽然能亮，但速率协商不稳定，有时候跑200Gb，有时候跑100Gb。换了认证模块之后，效率恢复到70%以上。

这个坑的教训是：IB网络的光模块一定要用认证的，不要图便宜买杂牌。另外，部署完成后要用IB的测试工具（比如ib_write_bw）做带宽测试，确认每个端口的速率都正常。

6.2 NCCL配置对拓扑的感知

NCCL是NVIDIA的集合通信库，它会自动感知GPU的拓扑，选择最优的通信路径。但NCCL的自动感知有时候会出错，特别是在混搭集群或者复杂拓扑下。

一个常见的做法是手动设置NCCL的环境变量，比如NCCL_IB_HCA指定用哪些IB网卡，NCCL_SOCKET_IFNAME指定用哪个网络接口，NCCL_DEBUG=INFO打开调试日志看NCCL选了哪条路径。

如果发现NCCL选了不是最优的路径，可以用NCCL_TOPO_FILE手动指定拓扑文件，强制NCCL按你的设计走。这个在混搭集群里特别有用，可以避免NCCL把A100和H100混在一起做All-Reduce。

注意：NCCL的版本要和CUDA版本匹配，不同版本的NCCL对拓扑的支持不一样。升级NCCL之前，建议先在测试环境验证，避免影响生产训练。

6.3 GPU-burn压力测试暴露的散热和供电问题

GPU集群部署完成后，一定要做压力测试。常用的工具是gpu-burn，它会让GPU跑满负载，测试稳定性和散热。

有一次在一个H100集群上跑gpu-burn，跑了10分钟就有几张卡降频了。排查发现是机柜的散热设计有问题，冷风道和热风道没有隔离，热风回流导致GPU温度过高。调整机柜布局，加装导流板之后，问题解决。

另一个常见问题是供电。H100的功耗比A100高不少，单卡TDP 700W，8卡就是5600W，加上CPU、内存、网卡，单节点功耗可能超过6kW。如果机柜的供电设计没跟上，跑满载时可能会触发过载保护，导致节点断电。

所以部署前一定要算好功耗预算，机柜的PDU（电源分配单元）要能支撑峰值功耗，最好留20%的余量。散热方面，建议用冷通道封闭或者后门换热器，确保GPU能跑到满血不降频。

7. 从A100迁移到H100：组网方案怎么平滑过渡

7.1 网络设备的复用和升级

如果你已经有A100集群，想加一批H100，网络设备能不能复用？答案是部分可以。IB交换机通常支持多速率，HDR交换机可以跑NDR速率（如果硬件支持），但需要确认交换机的型号和固件版本。

光模块和线缆通常不能复用，因为HDR和NDR的封装和速率不一样。HDR用的是QSFP56，NDR也是QSFP56或者OSFP，但速率不同，混插时可能会协商到低速。所以升级到H100时，光模块和线缆基本要重新采购。

Subnet Manager可以复用，但需要升级到支持NDR的版本。另外，如果集群规模扩大了，Subnet Manager的性能可能不够，需要考虑分布式Subnet Manager或者专用的管理节点。

7.2 存储和软件栈的兼容性

H100的软件栈和A100基本兼容，CUDA版本要升级到支持H100的版本（CUDA 11.8以上），驱动也要对应升级。NCCL、cuDNN这些库也要升级到支持H100的版本。

存储方面，H100的吞吐量更高，对存储带宽的要求也更高。如果原来的存储是给A100集群配的，可能撑不住H100集群的吞吐。建议在迁移前做存储带宽测试，确认能满足H100集群的需求。

另外，H100支持FP8精度，这是A100没有的。如果你的训练框架支持FP8，可以在H100上开启FP8训练，吞吐量能提升不少。但FP8对模型精度有影响，需要做精度验证。

7.3 迁移过程中的训练任务调度

迁移过程中，最麻烦的是训练任务的调度。如果A100和H100混在一个集群里，调度器要能识别节点类型，把任务分配到合适的节点上。Kubernetes的GPU调度插件支持节点标签，可以给A100和H100节点打不同的标签，然后在任务提交时指定节点选择器。

另一个做法是物理隔离，A100和H100分成两个独立的集群，通过存储或者数据管道共享数据。这样调度简单，但资源利用率可能不如混搭集群。

实际迁移时，建议先在小规模上验证，比如先用几台H100跑通训练流程，确认软件栈和网络都没问题，再逐步扩大规模。不要一次性把所有任务都迁过去，避免出问题影响生产。

8. 一些个人体会和后续可以深入的方向

搞GPU集群组网这些年，最大的感受是：硬件拓扑决定了上限，软件调优决定了下限。你买再好的卡、再快的网络，如果拓扑设计不合理、NCCL配置不对、散热供电没跟上，实际效率可能连理论值的一半都不到。

A100和H100这两代平台，组网逻辑有继承也有变化。继承的是NVLink加IB的基本框架，变化的是NVLink 4.0的跨基板互联和PCIe Gen5的带宽提升。理解这些变化，才能设计出匹配硬件能力的集群方案。

后续如果大家感兴趣，可以深入聊聊NVLink Switch System的实际部署经验，或者RoCE和IB在大规模集群下的对比测试。这两个方向我都有一些实测数据，有机会再整理出来分享。

最后分享一个小技巧：部署完集群后，先用NCCL的测试工具跑一遍All-Reduce，把每个节点组合的带宽都测出来，画成矩阵图。这样一眼就能看出哪些节点之间的通信有问题，比盲目调优高效得多。这个矩阵图我每次部署新集群都会做，屡试不爽。