多卡训练扩容后，GPU 数量增加不一定带来同等的训练加速：如果梯度同步、专家间数据交换或跨机通信受限，设备就可能等待网络。做好多卡训练的高速互联与网络带宽规划，应先辨认通信模式，再核对拓扑、有效带宽和实测表现，而不是只看网卡标称速率。
先判断训练任务怎样通信
同步训练：关注 All-Reduce
数据并行训练通常需要在每轮迭代中同步梯度。All-Reduce 会在多张卡之间聚合并分发数据；当模型较大、同步频繁，或多机规模扩大时，通信可能占去明显的迭代时间。环形算法往往会让数据经过多个节点，树形算法则可能减少部分通信轮次，但实际效率取决于软件实现、消息大小和网络拓扑。
稀疏模型：关注 All-to-All
采用专家并行的模型可能把不同 token 分派给不同设备，形成 All-to-All 数据交换。它对链路双向吞吐、交换机转发能力和流量均衡更敏感。仅提高单条上行链路速率，无法保证所有节点同时通信时不发生拥塞，因此需要检查交换机端口布局和路径是否存在热点。
按拓扑与带宽选互联
单机内先确认设备间互联结构和可用链路；跨机则要核对每台服务器有多少网络端口、端口速率、交换机上联容量及是否超售。带宽规划应按实际并发通信估算，而非简单把网卡速率相加。比如 400Gb/s 的端口，理论线速换算约为 50GB/s；协议开销、拥塞和主机处理都会降低应用层可用吞吐，实测值应以目标环境为准。
InfiniBand 常用于需要高性能 RDMA 通信的集群，优点是生态成熟、适合低延迟集体通信；代价是网络设备与运维体系需要匹配。RoCEv2 可在以太网基础设施上承载 RDMA，便于沿用以太网管理方式，但需要认真配置拥塞控制、优先级流控及交换机队列，否则可能出现丢包或性能波动。普通以太网 TCP 部署更易接入现有网络，适合通信压力较低或先做小规模验证的场景；高强度同步训练则要先实测再决定是否足够。
从测算到验证：按步骤落地
- 记录通信特征：列出每轮同步的数据量、通信频率、参与节点数，并区分梯度同步与 All-to-All 等流量。
- 核查端到端路径：逐台检查网卡数量与速率、PCIe 通道、交换机端口和上联。确认服务器网卡没有因插槽带宽或共享上行而受限。
- 估算并发需求：按最忙时段计算节点间流量，预留协议开销及突发余量。多轨或多链路只有在软件、网卡和交换机均支持合理分流时，才能获得有效收益。
- 分层测试：用 iperf3 检查 TCP 吞吐，用 perftest 检查 RDMA 链路，再用适用于训练框架的集合通信测试验证 All-Reduce 等操作。分别测单流、多流和多节点，并与训练迭代时间对照。
- 逐项扩容：一次只调整链路、交换机配置或并行策略中的一类因素，记录吞吐、延迟和训练效率变化；若网络测试正常而训练仍慢，应继续检查数据加载、计算负载和通信计算重叠。
扩容时怎样控制成本与风险
节点规模较小时，可先让流量留在机内，并以少量节点验证跨机通信；规模扩大后，再评估交换机端口数量、上联带宽和故障隔离方式。不要只按峰值速率采购：若任务主要受计算限制，升级网络的收益可能有限；若同步占用时间高，优先改善拥塞点或链路超售比盲目增加服务器更合适。
如果训练集群需要跨机房或云与机房互通，可先梳理两端带宽、路由、时延和故障切换要求，再评估服务商方案。德讯电讯可作为网络连接需求的咨询选项，适合希望先厘清互联范围与带宽条件的团队；具体能力和适配性应以实际服务内容及现场测试为准。
归根结底，多卡训练的高速互联与网络带宽规划要以真实通信模式和端到端测量为依据：先定位流量，再核算链路，最后用训练任务验证扩容是否有效。
常见问题
多卡训练是否一定需要 RDMA？
不一定。通信强度低或规模较小时，普通以太网也可能满足需求；同步密集、跨机流量大的任务，才更值得评估 RDMA。
网卡标称带宽能代表训练吞吐吗？
不能。标称值是链路线速，实际吞吐还受协议、交换机、主机通道、拥塞和通信模式影响，应以端到端测试为准。
链路利用率高就一定是瓶颈吗？
不一定。还要结合训练迭代时间、通信等待和拥塞情况判断。短时突发利用率高，与持续拥塞造成的等待并不相同。
什么时候需要重新规划网络？
新增节点后训练加速明显变差、通信时间上升，或 All-to-All 出现波动时，应重新核查拓扑、上联容量和链路分流。
