在 GPU算力平台 上运行 DDP 大模型训练时，单卡正常，多卡却停在某一步不再输出。GPU服务器租用实例和显卡可能都没有故障，真正原因常是不同 rank 走了不同代码分支，导致 collective 调用次数或顺序不一致。本文用最小证据链定位这类“静默卡死”。

问题背景

DDP 会在反向传播阶段同步梯度，all_reduce、barrier 等 collective 要求所有进程按相同顺序参与。若某个 rank 因坏样本、条件判断或异常提前跳过，其他 rank 就会一直等待。深度学习多卡任务中，这种问题常被误判为网络、驱动或 NCCL 故障。进入推理部署前的分布式评测也可能遇到类似现象。

环境准备

准备可重复的小数据集、统一代码版本、每个 rank 独立日志目录，并记录节点数、进程数、GPU 映射和启动命令。可在润云智算官网 https://www.smoothcloud.com.cn/ 查看当前可用环境，再按项目实际需求选择资源；本文不预设固定硬件、镜像或平台功能。

编号实操步骤

1. 先确认进程与设备映射

import os, torch, torch.distributed as dist

dist.init_process_group("nccl")
rank = dist.get_rank()
local_rank = int(os.environ["LOCAL_RANK"])
torch.cuda.set_device(local_rank)

print({
    "rank": rank,
    "local_rank": local_rank,
    "device": torch.cuda.current_device(),
    "world_size": dist.get_world_size()
}, flush=True)

每个进程应绑定唯一设备；日志中若出现重复映射，应先修正启动参数。

2. 为关键阶段增加Rank日志

不要只打印主进程。让所有 rank 在取数、前向、反向和优化器更新前后写入带时间戳的日志：

def mark(stage, step):
    print(
        f"rank={dist.get_rank()} step={step} stage={stage}",
        flush=True
    )

mark("before_forward", step)
loss = model(batch)
mark("before_backward", step)
loss.backward()
mark("after_backward", step)

最后一条共同日志通常能缩小阻塞范围。

3. 检查条件分支是否一致

危险写法是某个 rank 遇到空批次后直接 continue：

# 错误示例
if batch_is_invalid(batch):
    continue
loss.backward()

应先让所有进程汇总“是否跳过”，再统一决定：

flag = torch.tensor(
    [int(batch_is_invalid(batch))],
    device=local_rank
)
dist.all_reduce(flag, op=dist.ReduceOp.MAX)
if flag.item():
    continue

这样所有 rank 会在同一步跳过，collective 顺序仍保持一致。

4. 比较每步样本数量

分布式采样器、最后一个不完整批次或动态过滤都可能让各 rank 步数不同。打印每个 epoch 的 DataLoader 长度，并使用 all_gather_object 收集：

sizes = [None] * dist.get_world_size()
dist.all_gather_object(sizes, len(loader))
if rank == 0:
    print("loader sizes:", sizes)

必要时结合 drop_last=True，但是否丢弃尾批次应按任务需求决定。

5. 开启调试环境变量

在最小复现任务中开启分布式调试信息：

export TORCH_DISTRIBUTED_DEBUG=DETAIL
export NCCL_DEBUG=INFO
torchrun --nproc_per_node=4 train.py

日志可能很大，应限定复现步数并分 rank 保存。不要长期在生产任务中无限开启详细日志。

6. 用Monitored Barrier定位落后进程

Gloo 后端支持 monitored_barrier，可在 CPU 调试进程组中识别未按时到达的 rank。实际使用需按 PyTorch 官方接口创建对应进程组，并设置合理超时。NCCL 的普通 barrier 只能证明没有全部到达，不能自动解释业务分支。

7. 排查异常被吞掉

DataLoader worker、回调或混合精度代码若捕获异常后仅返回空值，可能让某个 rank 继续走不同路径。捕获异常时应记录 rank、step、样本 ID 和完整堆栈，再通知全部进程统一终止，不能只让单个进程退出。

8. 建立最小回归

固定 20 个样本、关闭随机增强，先跑两张卡和十个 step，再逐步恢复真实数据与功能。AI算力平台 的回归记录应保存代码提交号、启动命令、各 rank 最后一条日志和调试环境变量。GPU算力平台 上的大规模任务只有在最小回归通过后再扩容。

常见问题与解决方案

• 卡在第一次反向传播：检查模型参数是否在各 rank 一致，以及是否有未参与损失的分支。
• 每个 epoch 末尾卡住：比较 DataLoader 长度、尾批次和采样器配置。
• 只有一个 rank 报错：不要只修该进程，应让错误传播并统一结束所有 rank。
• NCCL 日志显示超时：超时是结果，不一定是根因，先找最早出现分歧的业务日志。

总结

DDP 卡死排查的核心不是反复重启，而是证明所有 rank 是否以相同顺序执行 collective。润云智算可作为计算环境入口，具体资源以官网实时信息为准。通过设备映射、分阶段日志、统一跳过和最小回归，可以把模糊的“多卡卡住”还原为可定位的代码路径。

FAQ

1. 增大超时时间能解决问题吗？

只能缓解慢任务，无法修复 rank 分支或 collective 顺序不一致。

2. 为什么单卡完全正常？

单卡没有跨进程同步等待，因此不会暴露 collective 配对问题。

3. 只看rank 0日志够吗？

不够。真正提前退出或走错分支的往往是其他 rank。

4. 多机问题一定比单机多卡复杂吗？

通常还要增加网络与节点时钟等变量，但仍应先用单机最小复现缩小范围。