单卡训练正常，多卡扩展后却没有明显提速，问题未必出在模型代码。显卡的运行状态、卡间互联、主机内存和数据通路都可能改变实际吞吐。排查“训练速度慢的硬件瓶颈排查”时，先固定模型、批量大小和训练步数，再逐项比较硬件状态，避免一次改动多个条件。
1. 单卡本身是否降频或受限
持续训练会产生热量；散热不足、功耗限制或供电状态异常，都可能让加速卡的时钟频率低于正常负载水平。先观察训练期间的温度、核心频率、功耗和利用率，而不是只看空闲时的设备信息。NVIDIA设备可用 nvidia-smi 观察状态；AMD设备可用 ROCm 提供的 rocm-smi。具体指标名称会随驱动和版本变化。
- 预热数十步后，记录连续几分钟的频率、温度和功耗。
- 对比空闲与训练状态，检查频率是否长期偏低、温度是否持续逼近设备限制。
- 核对机箱风道、风扇、供电及设备厂商设定的功耗上限；不要直接修改不熟悉的限制值。
若多张卡中只有一张频率明显偏低，先检查该卡的散热位置与供电连接，再做单卡交叉测试。
2. 多卡型号或性能是否不一致
同一任务分配到不同型号、显存容量或运行频率的卡上时，数据并行训练往往要等待较慢的设备完成计算。较小显存的卡还可能迫使程序缩小批量或频繁搬运数据。查看设备型号、显存占用和每张卡的训练步耗时；不要仅凭卡的数量判断总算力。
3. 卡间链路是否降档
加速卡插槽看起来相同，实际链路宽度、代际和主板拓扑仍可能不同。用 lspci -vv 查看 PCIe 设备协商后的速率与宽度，并与设备、主板规格核对；结果应在负载时复查。若多卡时通信等待增加、计算利用率下降，而单卡正常，链路或拓扑值得优先检查。不同平台的最佳配置并不相同，不能只比较标称带宽。
4. 主机CPU、内存与NUMA是否拖慢供数
数据预处理、增强和批次调度也占用主机资源。双路服务器中，设备连接在哪个处理器附近，会影响跨 NUMA 节点访问内存的开销。可用 numactl -H 查看节点与 CPU、内存分布，再对照设备所在节点；同时观察内存是否紧张、是否发生交换。将数据加载进程放到靠近设备的 CPU 节点，适合确认 NUMA 访问是否影响供数，但应保留一组未绑定的对照结果。
5. 数据盘是否跟不上训练读取
小文件很多、数据解码复杂或多个训练进程共用存储，都可能让加速卡等待输入。用 iostat 等系统监控工具观察训练期间磁盘吞吐、队列和等待时间，并将数据读取阶段与纯计算阶段分开测量。若换成已缓存的一小段数据后吞吐明显改善，优先检查存储并发能力、文件布局和解码负载；这并不等于直接更换硬盘就是答案。
6. 多机网络是否限制梯度同步
跨服务器训练要通过网络交换梯度，网卡速率、交换机配置和线路状态都会影响同步时间。先在相同节点数下测单机多卡与跨机多卡，再观察训练中通信等待是否随节点增加而变长。使用系统网卡统计信息检查丢包、错误包和链路速率；测试带宽时还要确认测试端点、并发流和网络路径与训练环境一致。
按顺序缩小范围
- 固定模型、输入尺寸、批量大小和训练步数，分别测单卡与多卡的稳定区间。
- 记录每张卡的利用率、频率、温度、显存和步耗时，找出是否存在明显慢卡。
- 再检查链路、NUMA、内存、存储及网络，每次只调整一项并重复测量。
- 以相同步数的平均耗时和波动范围比较结果；短时间测试可能漏掉热降频或周期性读盘停顿。
按设备状态、数据通路、通信链路的顺序检查，比盲目增加卡数更容易定位问题。系统地进行训练速度慢的硬件瓶颈排查，才能判断瓶颈究竟在单卡、多卡互联还是主机侧。
常见问题
单卡正常，多卡却更慢，先看哪里？
先比较各卡的步耗时和利用率，再检查卡间链路及梯度同步等待。若某张卡持续落后，优先排查该卡状态和型号差异。
显卡利用率低，能否直接判断显卡不够快？
不能。数据读取、CPU预处理、内存访问或通信等待都可能让显卡空闲，应结合训练阶段和系统监控判断。
每次测试需要跑多久？
先预热，再测数分钟并重复几轮；具体时长取决于模型、数据量和设备散热。长任务还应关注温度变化与吞吐波动。
