先检查nvidia-smi topo -p2p r输出是否大量显示N/A或PHB而非PIX/SYS，若P2P未通则all_reduce降速3–5倍；确认硬件拓扑、BIOS设置，禁用CUDA_VISIBLE_DEVICES并显式绑定设备，backend必须设为"nccl"，再通过nvidia-smi dmon -s u -d 1观察PCIe带宽是否饱和。
PyTorch多卡训练慢，先看nvidia-smi里有没有P2P通信被禁用
多卡训练卡在数据搬运上，常见原因是GPU之间无法直连（P2P），被迫走PCIe Switch或CPU内存中转。运行nvidia-smi topo -p2p r，如果输出里大量显示N/A或PHB（PCIe Host Bridge）而非PIX（P2P over NVLink）或SYS（P2P over PCIe），说明P2P没通。此时torch.distributed的all_reduce等操作会降速3–5倍。
实操建议：
- 确认硬件支持：NVLink需同代Tesla/V100/A100/H100且主板/桥接器支持；PCIe P2P则要求GPU插在同一PCIe Root Complex下（通常同一CPU socket下的PCIe插槽）
- 检查BIOS设置：部分服务器需开启
ACS (Access Control Services) Override或关闭SR-IOV才能启用P2P - 临时启用P2P（仅限PCIe）：
sudo nvidia-smi -i 0,1 -r重启设备后重试nvidia-smi topo -p2p r，但该操作会中断所有GPU进程
用torch.cuda.set_device()和torch.distributed.init_process_group()前必须对齐可见设备
常见错误是脚本里写os.environ["CUDA_VISIBLE_DEVICES"]="0,1"，但启动时又用python -m torch.distributed.launch --nproc_per_node=2 train.py，导致rank 0看到的是逻辑GPU 0（物理卡0），rank 1看到的却是逻辑GPU 1（物理卡1）——看似正确，实则CUDA_VISIBLE_DEVICES被launch工具二次处理，rank 1实际绑定到了物理卡0，两卡争抢同一总线。
正确做法：
立即学习“Python免费学习笔记（深入）”；
- 彻底禁用
CUDA_VISIBLE_DEVICES环境变量，改用torch.cuda.set_device(args.local_rank)显式绑定 - 确保
init_process_group的backend设为"nccl"（NCCL自动启用P2P/NVLink，gloo不支持） - 验证设备拓扑：
print(f"Rank {args.rank}: device {torch.cuda.current_device()}, name {torch.cuda.get_device_name()}")
nvidia-smi dmon -s u -d 1实时看PCIe带宽是否打满
即使P2P通了，PCIe带宽也可能成瓶颈。比如A100单卡PCIe 4.0 x16理论带宽约32 GB/s，但训练中all_reduce频繁同步梯度（尤其大模型），若实测rx（接收）持续＞25 GB/s，说明PCIe已饱和，此时换NVLink或减少batch_size比调学习率更有效。
关键观察点：
- 运行
nvidia-smi dmon -s u -d 1后关注rx列，单位是MB/s；换算时注意1 GB/s = 1000 MB/s（非1024） - 对比单卡与多卡的
rx值：若多卡rx总和远高于单卡（如单卡1.2 GB/s → 双卡合计＞20 GB/s），说明通信开销主导了延迟 - NCCL环境变量可缓解：
export NCCL_PCIE_DISABLE=0（强制启用PCIe P2P）、export NCCL_ASYNC_ERROR_HANDLING=1（避免同步等待拖慢）
DDP封装后model.forward()变慢？检查torch.nn.parallel.DistributedDataParallel的find_unused_parameters
设find_unused_parameters=True会让DDP遍历整个计算图找未参与反向传播的参数，每次forward都触发一次图分析，小模型可能慢20%，大模型直接卡住。这不是PCIe问题，但常被误判为硬件瓶颈。
排查方式：
- 先关掉它：
find_unused_parameters=False（默认值），只在多分支网络（如某些检测头、条件计算）真有未使用参数时才开 - 开之前加日志：
torch.autograd.set_detect_anomaly(True)，运行时报错会明确指出哪层参数没被用到 - 注意：即使开了，也别在
eval()模式下调用model.train()再切回去，DDP内部状态可能混乱，导致后续forward异常慢
真正难定位的是PCIe链路质量——比如某根PCIe插槽接触不良，nvidia-smi显示正常，但rx抖动剧烈、偶发0值，这种得换槽或查主板手册确认PCIe通道分配。
