增加服务器和显卡，不一定能让训练更快。跨节点训练需要频繁交换梯度或中间数据；当网络传输跟不上计算，显卡就会等待通信完成。评估显卡服务器多卡互联方案时，不能只看网卡标称速率，还要关注实际吞吐、延迟、拓扑和任务的通信比例。
带宽不足会造成什么影响
训练时间缩短得越来越少
数据并行训练常通过 all-reduce 汇总各卡梯度。以环形算法为例，每个参与设备需要传输的数据量通常与梯度总量同一数量级；设备数增加时，通信阶段可能变长。若计算时间无法覆盖通信时间，增加节点带来的速度提升就会变小，严重时多加服务器也可能几乎没有收益。
显卡利用率下降，训练表现更不稳定
通信受限时，计算任务可能在同步点等待较慢的节点。表现包括 GPU 利用率周期性下滑、每步耗时增加，以及不同训练批次间耗时波动。若链路存在拥塞、丢包或重传，问题还可能集中在某些时段或节点，而不只是整体速度慢。
扩容成本上升，排错更复杂
采购更多计算卡却没有匹配网络能力，可能让新增算力无法充分发挥。更麻烦的是，数据读取慢、CPU 瓶颈、网卡配置错误和网络拥塞都可能呈现类似的训练变慢现象，单看 GPU 利用率不能直接判断原因。
先区分标称带宽与有效带宽
网卡标注的 100、200 或 400 Gb/s 是链路速率，不能直接等同于训练程序可用吞吐。协议开销、交换机端口配置、主机总线、网卡数量与流量竞争都会影响结果；多端口速率相加，也不代表单个通信任务一定能获得相同吞吐。
以太网部署范围广、设备选择灵活，适合已有以太网基础设施且通信压力适中的场景。采用 RoCEv2 时，可以在以太网上承载低延迟的远程直接内存访问，但对网络拥塞控制、交换机配置和端到端运维要求较高。InfiniBand 通常用于重视高性能集群通信的环境，性能和管理方式取决于具体代际、设备及拓扑；专用基础设施投入也需纳入成本比较。三者没有脱离工作负载的绝对优劣。
按步骤排查瓶颈并选择互联方案
确认是否真的受网络限制。记录训练每步耗时、GPU 利用率、网络接口吞吐和丢包情况，并与单节点运行作对照。测试应尽量使用同一模型、批量大小和数据条件。
测量节点间通信。先用适合所用网络的带宽与延迟测试工具测量节点间链路，再运行训练框架提供的通信基准。若单机多卡正常、跨节点明显变慢，网络或跨节点通信配置就值得优先检查。
核对路径和拥塞。检查网卡速率、交换机端口、路由、网卡绑定以及多节点同时传输时的表现。多台服务器汇聚到少数上行链路会形成 oversubscription（超额订阅）；即使端口标称速率较高，集中通信时仍可能竞争带宽。
依据测量结果扩容。通信强、节点数多且已有相应运维能力，可评估 RoCEv2 或 InfiniBand；负载通信较少、网络以通用业务为主时，可先改善以太网拓扑与链路配置。比较显卡服务器多卡互联方案时，应同时核算端口、交换机、布线、冗余和维护成本。
结论与常见问题
互联带宽不足的核心影响，是通信等待吞掉计算收益，导致训练变慢、资源闲置和扩容效率下降。用基准测试定位瓶颈，再结合工作负载选择显卡服务器多卡互联方案，比单纯追求更高标称速率更可靠。
带宽不足一定会让 GPU 利用率持续偏低吗？
不一定。计算与通信可以重叠，部分任务的通信等待不明显；同步频繁、通信量大的任务通常更容易受影响。
只升级网卡就能解决问题吗？
不一定。交换机上行、节点拓扑、网卡配置和拥塞都可能成为瓶颈，应先测量端到端吞吐。
怎样判断该选以太网还是 InfiniBand？
结合实测通信需求、现有网络、设备投入和运维能力比较；不能只依据网卡标称速率作决定。
