YOLOv11 四卡训练卡住不动，切换单卡却正常：一次多 GPU DDP 训练排查记录
一、问题现象
最近在云训练机上训练 YOLOv11 自定义工业缺陷数据集时，我原本准备使用四张 GPU 加快训练，训练指令大致如下：
yolo detect train data=./yaml/xxx.yaml model=yolo11m.pt epochs=200 patience=30 imgsz=2048 batch=32 device=0,1,2,3但是启动训练后，程序一直停在多卡初始化阶段，训练没有正常进入第一个 epoch。等待一段时间后，日志也没有继续明显刷新，看起来像“卡住不动”。
后来把参数改为单卡：
device=0训练就可以正常启动并进入 epoch。
也就是说，模型、数据集、标签和基本训练参数并没有完全失效；真正出问题的环节，大概率出现在多 GPU 训练额外触发的 DDP 分布式环境上。
二、为什么单卡正常，多卡却会卡住？
很多人会以为，多卡训练只是把：
device=0改成：
device=0,1,2,3实际上并不是这么简单。
单卡训练时，YOLO 只需要启动一个训练进程，直接调用一张显卡即可。
而多卡训练时，Ultralytics 会启动 DDP（Distributed Data Parallel，分布式数据并行）模式。简单理解，就是每张显卡都会对应一个训练进程，多个进程之间需要同步模型参数、梯度、数据和训练状态。
所以只要其中一张卡、一个子进程或某个通信环节出问题，其他进程就可能一直在等待，最终表现为：
日志停在 DDP 初始化附近；
GPU 利用率不高，甚至一直为 0；
显存看似占了一点，但训练不进入 epoch；
单卡训练正常，多卡训练失败或卡住。
因此，单卡能跑通，并不代表四卡环境一定正常；它只能说明模型、数据和基础训练流程大概率没有致命问题。
三、多卡训练卡住时，先不要急着重装环境
遇到这种情况，我建议按下面顺序排查，而不是一上来就重装 CUDA、PyTorch 或系统。
1. 先确认单卡能否正常训练
先使用：
device=0如果单卡可以正常进入训练，并且 loss、mAP 等指标正常变化，那么可以初步排除以下问题：
数据集路径完全错误；
yaml 文件无法读取；
标签格式整体异常；
模型文件无法加载；
当前训练参数完全不可用。
这一步很重要，因为它能把问题范围从“整个训练流程”缩小到“多卡 DDP 环境”。
2. 查看每张显卡是否都正常可用
在训练机终端执行：
nvidia-smi重点看下面几项：
四张显卡是否都能识别；
是否有某张卡已经被其他训练任务占用；
每张卡的显存是否差异很大；
是否有残留 Python 进程没有退出；
GPU 利用率是否长期为 0。
如果其中一张 GPU 被其他任务占用、显存不足，或者状态异常，多卡训练就可能无法正常初始化。
3. 注意 batch 和显卡数量是否匹配
我这里使用四张 GPU，设置的是：
batch=32 device=0,1,2,3理论上平均下来就是每张卡处理 8 张图，这种设置通常比较合理。
但如果总 batch 太小、不能被 GPU 数量整除，或者图片尺寸很大导致某张显卡显存先爆，也可能导致多卡训练异常。
例如，2048 分辨率下模型显存压力明显比 640 或 1024 大得多。即使总 batch 看起来不大，多卡训练时仍然需要结合显存情况逐步测试。
建议按下面顺序尝试：
# 先测试两张卡 device=0,1 batch=16确认两张卡正常后，再测试四张卡：
device=0,1,2,3 batch=32不要直接认为“有四张卡，就一定要四张卡全部开满”。
4. DataLoader 也可能导致看似“多卡卡住”
YOLO 训练除了 GPU 外，还会启动数据加载进程读取图片、标签并进行增强。
如果数据量很大、图片分辨率很高，或者数据中混有损坏图片、异常标签、路径问题，多卡下的 DataLoader 会比单卡更容易暴露问题。
排查时可以先降低 workers：
yolo detect train data=./yaml/xxx.yaml model=yolo11m.pt epochs=200 imgsz=2048 batch=16 device=0,1 workers=2如果降低workers后可以正常启动，说明问题可能和数据读取、多进程加载或服务器 CPU 资源有关。
同时建议检查：
是否有损坏图片；
图片和标签是否一一对应；
标签中是否存在空行、类别编号越界；
数据路径是否包含特殊字符；
网络盘或挂载磁盘读取是否稳定。
5. 自定义模块和 DDP 兼容性也要注意
如果使用的是官方原版 YOLO，一般 DDP 兼容性会相对好一些。
但如果项目里加入了自定义网络模块、自定义数据增强、自定义 Trainer、改过数据集读取逻辑，多卡训练时就可能出现问题。
原因是多卡 DDP 需要启动多个子进程，而部分自定义对象无法被正常传递到子进程中。单卡不需要处理这个问题，所以可能单卡正常、多卡异常。
因此，如果项目加入过自定义模块，建议先用官方模型和最基础参数测试多卡环境：
yolo detect train data=./yaml/xxx.yaml model=yolo11n.pt epochs=2 imgsz=640 batch=16 device=0,1如果这个最小测试能跑通，再逐步恢复自己的模型、分辨率和训练参数。
四、我这次的处理方式
这次训练时，多卡模式没有正常进入训练流程，但切换成单卡后可以正常运行。
因此我没有继续在当下任务里反复消耗时间排查四卡，而是先使用单卡完成当前训练，保证模型迭代不被卡住。
后续如果确实需要提升训练速度，再单独安排时间排查多卡环境，建议顺序如下：
单卡确认模型和数据正常；
两卡、小 batch、低分辨率进行最小测试；
检查
nvidia-smi中每张 GPU 的状态；降低
workers；检查 PyTorch、CUDA、驱动版本是否匹配；
最后再恢复四卡、2048 分辨率和正式 batch。
这样排查效率会比“直接四卡硬跑”高很多。
五、结论
YOLOv11 多卡训练卡住、单卡却正常，通常不是模型本身突然坏了，而是多卡 DDP 训练比单卡多了一层进程通信、显卡同步和数据加载的问题。
对于实际项目来说，优先级应该是：
先让模型稳定训练，再追求多卡加速。
尤其是工业缺陷检测项目，数据分辨率大、训练周期长、客户现场问题多。与其为了开满显卡浪费半天时间，不如先用单卡把模型跑出来、验证效果，再单独处理多卡环境问题。
六、快速排查清单
单卡
device=0是否能正常训练nvidia-smi是否识别到所有 GPU是否有其他进程占用显卡
batch 是否适合当前显卡数量和显存
是否尝试过先用两张卡测试
是否降低过
workers数据集中是否有损坏图片、空标签或异常标签
是否使用了自定义模块、Trainer 或数据增强
PyTorch、CUDA、驱动版本是否匹配
是否先用最小模型、低分辨率跑通 DDP
参考资料
Ultralytics YOLO 训练文档：Model Training with Ultralytics YOLO | Ultralytics
PyTorch Distributed 文档：Redirecting…
