【Bug已解决】NCCL timeout for validation 解决方案一、现象长什么样训练用多卡 DDP / FSDP 正常但一到validation验证 / eval阶段就卡住几分钟后报RuntimeError NCCL timeout ... communicator was destroyed or timed out或者进程直接 hang 在 eval 的某个集合通信上。最小判据触发训练正常进入 validation 阶段后 NCCL 超时 现象eval 卡住 - NCCL timeout 根因验证阶段各 rank 的 collective 通信不对齐有的 rank 调了、有的没调 影响训练能跑eval 必挂无法完成一轮完整迭代最迷惑的是训练阶段有集合通信完全正常偏偏 eval 阶段看起来更轻量超时。因为 eval 阶段某些 rank 没参与 collective导致参与的那部分 rank 永远等不到同伴。二、背景NCCL 的集合通信all-reduce / broadcast / barrier是阻塞式的所有参与该 communicator 的 rank 必须在同一集合操作上会合少一个都不行。验证阶段常见的不对齐来源只有 rank0 做 eval很多脚本让if accelerator.is_main_process:跑 eval其它 rank 跳过。若 eval 内部有 all-reduce比如聚合各 rank 的 eval lossrank0 调了、其它 rank 没调 - rank0 永远等 - 超时。eval dataloader 长度各 rank 不同某些 rank 的 eval 数据少提前结束没进最后那个 collective其它 rank 还在等 - 超时。训练末尾的 barrier 与 eval 的 collective 混用训练结束有个barrier()但 eval 的某 rank 因早退没到 barrier - 超时。eval 没用 DistributedSampler各 rank 读到的 eval 样本数不同迭代次数不同collective 不对齐。混合精度 / autocast 在 eval 形状变化某些 rank 因 batch 形状不同走了不同分支collective 调用次数不同。根因是eval 阶段各 rank 的集合通信调用不对齐——这是 NCCL 超时在验证阶段几乎唯一的原因。三、根因抽象成代码示意# 错误只有 rank0 做 eval 且 eval 内含 all-reduce if accelerator.is_main_process: loss evaluate(model) # 内部 all-reduce 各 rank eval loss # rank0 调 all-reduce其它 rank 没调 - 超时根因链条eval 阶段某些 rank 跳过 collective只 rank0 跑、或数据早结束参与的 rank 调了 all-reduce / broadcast / barrier等待同伴缺席的 rank 不调用永远到不了会合点NCCL 等待超过NCCL_TIMEOUT- 超时训练阶段所有 rank 都参与 collective 所以正常eval 阶段不对齐所以炸。一句话eval 阶段各 rank 的 collective 通信调用不对齐参与的 rank 永远等缺席的 rank。四、最小可运行复现用纯 Python 模拟部分 rank 缺席 collective 导致永久等待超时# repro_nccl_val.py def collective(ranks_participating, all_ranks): # 集合通信要求所有 rank 参加缺席即永久等待 if set(ranks_participating) ! set(all_ranks): raise TimeoutError(NCCL timeout 部分 rank 未参与 collective) return synced def main(): all_ranks [0, 1, 2, 3] try: # eval 只有 rank0 调 collective collective([0], all_ranks) except TimeoutError as e: print(复现成功 -, e) if __name__ __main__: main()运行输出复现成功 - NCCL timeout 部分 rank 未参与 collective部分 rank 缺席 collective 即超时正是真实 bug 的抽象用TimeoutError代指 NCCL timeout。五、解决方案第一层最小直接修复最小且必须的一步保证 eval 阶段所有 rank 都参与同样的 collective。要么所有 rank 都跑 eval用DistributedSampler保证各 rank eval 数据齐、迭代次数一致要么 eval 完全不碰 collective只 rank0 算、最后用accelerator.gather时注意对齐# fix_layer1.py # 方案 A所有 rank 都跑 eval用 DistributedSampler eval_sampler DistributedSampler(eval_dataset) eval_loader DataLoader(eval_dataset, samplereval_sampler) model.eval() for batch in eval_loader: with torch.no_grad(): loss model(batch).loss # 所有 rank 都参与聚合 - 对齐 acc_loss accelerator.gather(loss) # eval 末尾统一 barrier所有 rank 都到 accelerator.wait_for_everyone()要点所有 rank 用DistributedSampler跑 eval迭代次数一致collective 对齐accelerator.gather/wait_for_everyone让每个 rank 都参与避免只有 rank0 跑 eval 且内部有 collective。六、解决方案第二层结构性改进把每个阶段的 collective 对齐做成显式不变量定义一个Barrier/ 阶段协议强制所有 rank 在同一组 collective 上会合并在 eval 前校验各 rank 的 eval 步数一致# fix_layer2.py from dataclasses import dataclass from typing import List dataclass class PhaseProtocol: name: str expected_collectives: List[str] class SyncPhase: def __init__(self, acc): self.acc acc def eval_phase(self, eval_steps: int): # 先校验所有 rank 的 eval 步数一致防止长度不同导致不对齐 steps self.acc.gather(torch.tensor(eval_steps)) assert steps.min() steps.max(), 各 rank eval 步数不一致 - collective 会错位 # 统一在 eval 前后 barrier self.acc.wait_for_everyone() # ... 跑 eval所有 rank 参与 collective ... self.acc.wait_for_everyone() # 用法 SyncPhase(acc).eval_phase(eval_stepslen(eval_loader))要点eval_steps一致性校验提前暴露长度不同这一最常见不对齐源前后wait_for_everyone保证所有 rank 进入 / 退出 eval 对齐阶段协议把collective 对齐固化避免某 rank 早退。七、解决方案第三层断言 / CI 守护写 pytest 验证eval 阶段所有 rank 参与 collective、步数一致# test_nccl_val.py import pytest def collective_ok(participants, all_ranks): return set(participants) set(all_ranks) def test_all_ranks_join_eval(): assert collective_ok([0,1,2,3], [0,1,2,3]) def test_partial_join_times_out(): with pytest.raises(AssertionError): assert collective_ok([0], [0,1,2,3]) def test_eval_steps_consistent(): steps [10, 10, 10, 10] assert min(steps) max(steps), eval 步数必须一致 def test_early_exit_caught(): # 某 rank 早退步数少 - 应被校验拦下 steps [10, 10, 8, 10] with pytest.raises(AssertionError): assert min(steps) max(steps)CI 一旦有人改出只有 rank0 跑 eval 内部 collectivetest_partial_join_times_out逻辑可拦截。八、排查清单validation 阶段 NCCL timeout 时确认是否只有 rank0 跑 eval 且 eval 内有 all-reduce / gather检查 eval dataloader 是否用DistributedSampler各 rank 步数是否一致看是否有 rank 因数据早结束而没进最后的 collective按第五 / 六节让所有 rank 参与 eval collective或 eval 完全不碰 collective训练正常、eval 超时几乎可断定是 eval collective 不对齐适当调大NCCL_TIMEOUT只是缓解根因仍是不对齐把第七节的 pytest 接进 CI守护eval 所有 rank 参与、步数一致。九、小结validation 阶段 NCCL 超时根因是 eval 阶段各 rank 的集合通信调用不对齐有的 rank 跑 eval 并调用 all-reduce / gather有的 rank只 rank0 跑、或数据早结束没调用参与的 rank 永远等缺席者 - 超时。训练阶段所有 rank 都参与所以正常。三层层级第一层所有 rank 用DistributedSampler跑 evalcollective 对齐wait_for_everyone第二层用PhaseProtocol校验 eval 步数一致、前后强制 barrier第三层pytest 验证 eval 所有 rank 参与、步数一致锁进 CI。核心教训NCCL 的集合通信是全或无的会合——任何 rank 缺席的 collective 都会让其余 rank 永久等待。训练阶段因所有 rank 对称参与而正常eval 阶段因主进程单独跑 / 数据长度不同极易破坏对称。任何跨阶段的集体通信都必须保证所有 rank 在相同的调用点上会合。
【Bug已解决】NCCL timeout for validation 解决方案一、现象长什么样训练用多卡 DDP / FSDP 正常但一到validation验证 / eval阶段就卡住几分钟后报RuntimeError NCCL timeout ... communicator was destroyed or timed out或者进程直接 hang 在 eval 的某个集合通信上。最小判据触发训练正常进入 validation 阶段后 NCCL 超时 现象eval 卡住 - NCCL timeout 根因验证阶段各 rank 的 collective 通信不对齐有的 rank 调了、有的没调 影响训练能跑eval 必挂无法完成一轮完整迭代最迷惑的是训练阶段有集合通信完全正常偏偏 eval 阶段看起来更轻量超时。因为 eval 阶段某些 rank 没参与 collective导致参与的那部分 rank 永远等不到同伴。二、背景NCCL 的集合通信all-reduce / broadcast / barrier是阻塞式的所有参与该 communicator 的 rank 必须在同一集合操作上会合少一个都不行。验证阶段常见的不对齐来源只有 rank0 做 eval很多脚本让if accelerator.is_main_process:跑 eval其它 rank 跳过。若 eval 内部有 all-reduce比如聚合各 rank 的 eval lossrank0 调了、其它 rank 没调 - rank0 永远等 - 超时。eval dataloader 长度各 rank 不同某些 rank 的 eval 数据少提前结束没进最后那个 collective其它 rank 还在等 - 超时。训练末尾的 barrier 与 eval 的 collective 混用训练结束有个barrier()但 eval 的某 rank 因早退没到 barrier - 超时。eval 没用 DistributedSampler各 rank 读到的 eval 样本数不同迭代次数不同collective 不对齐。混合精度 / autocast 在 eval 形状变化某些 rank 因 batch 形状不同走了不同分支collective 调用次数不同。根因是eval 阶段各 rank 的集合通信调用不对齐——这是 NCCL 超时在验证阶段几乎唯一的原因。三、根因抽象成代码示意# 错误只有 rank0 做 eval 且 eval 内含 all-reduce if accelerator.is_main_process: loss evaluate(model) # 内部 all-reduce 各 rank eval loss # rank0 调 all-reduce其它 rank 没调 - 超时根因链条eval 阶段某些 rank 跳过 collective只 rank0 跑、或数据早结束参与的 rank 调了 all-reduce / broadcast / barrier等待同伴缺席的 rank 不调用永远到不了会合点NCCL 等待超过NCCL_TIMEOUT- 超时训练阶段所有 rank 都参与 collective 所以正常eval 阶段不对齐所以炸。一句话eval 阶段各 rank 的 collective 通信调用不对齐参与的 rank 永远等缺席的 rank。四、最小可运行复现用纯 Python 模拟部分 rank 缺席 collective 导致永久等待超时# repro_nccl_val.py def collective(ranks_participating, all_ranks): # 集合通信要求所有 rank 参加缺席即永久等待 if set(ranks_participating) ! set(all_ranks): raise TimeoutError(NCCL timeout 部分 rank 未参与 collective) return synced def main(): all_ranks [0, 1, 2, 3] try: # eval 只有 rank0 调 collective collective([0], all_ranks) except TimeoutError as e: print(复现成功 -, e) if __name__ __main__: main()运行输出复现成功 - NCCL timeout 部分 rank 未参与 collective部分 rank 缺席 collective 即超时正是真实 bug 的抽象用TimeoutError代指 NCCL timeout。五、解决方案第一层最小直接修复最小且必须的一步保证 eval 阶段所有 rank 都参与同样的 collective。要么所有 rank 都跑 eval用DistributedSampler保证各 rank eval 数据齐、迭代次数一致要么 eval 完全不碰 collective只 rank0 算、最后用accelerator.gather时注意对齐# fix_layer1.py # 方案 A所有 rank 都跑 eval用 DistributedSampler eval_sampler DistributedSampler(eval_dataset) eval_loader DataLoader(eval_dataset, samplereval_sampler) model.eval() for batch in eval_loader: with torch.no_grad(): loss model(batch).loss # 所有 rank 都参与聚合 - 对齐 acc_loss accelerator.gather(loss) # eval 末尾统一 barrier所有 rank 都到 accelerator.wait_for_everyone()要点所有 rank 用DistributedSampler跑 eval迭代次数一致collective 对齐accelerator.gather/wait_for_everyone让每个 rank 都参与避免只有 rank0 跑 eval 且内部有 collective。六、解决方案第二层结构性改进把每个阶段的 collective 对齐做成显式不变量定义一个Barrier/ 阶段协议强制所有 rank 在同一组 collective 上会合并在 eval 前校验各 rank 的 eval 步数一致# fix_layer2.py from dataclasses import dataclass from typing import List dataclass class PhaseProtocol: name: str expected_collectives: List[str] class SyncPhase: def __init__(self, acc): self.acc acc def eval_phase(self, eval_steps: int): # 先校验所有 rank 的 eval 步数一致防止长度不同导致不对齐 steps self.acc.gather(torch.tensor(eval_steps)) assert steps.min() steps.max(), 各 rank eval 步数不一致 - collective 会错位 # 统一在 eval 前后 barrier self.acc.wait_for_everyone() # ... 跑 eval所有 rank 参与 collective ... self.acc.wait_for_everyone() # 用法 SyncPhase(acc).eval_phase(eval_stepslen(eval_loader))要点eval_steps一致性校验提前暴露长度不同这一最常见不对齐源前后wait_for_everyone保证所有 rank 进入 / 退出 eval 对齐阶段协议把collective 对齐固化避免某 rank 早退。七、解决方案第三层断言 / CI 守护写 pytest 验证eval 阶段所有 rank 参与 collective、步数一致# test_nccl_val.py import pytest def collective_ok(participants, all_ranks): return set(participants) set(all_ranks) def test_all_ranks_join_eval(): assert collective_ok([0,1,2,3], [0,1,2,3]) def test_partial_join_times_out(): with pytest.raises(AssertionError): assert collective_ok([0], [0,1,2,3]) def test_eval_steps_consistent(): steps [10, 10, 10, 10] assert min(steps) max(steps), eval 步数必须一致 def test_early_exit_caught(): # 某 rank 早退步数少 - 应被校验拦下 steps [10, 10, 8, 10] with pytest.raises(AssertionError): assert min(steps) max(steps)CI 一旦有人改出只有 rank0 跑 eval 内部 collectivetest_partial_join_times_out逻辑可拦截。八、排查清单validation 阶段 NCCL timeout 时确认是否只有 rank0 跑 eval 且 eval 内有 all-reduce / gather检查 eval dataloader 是否用DistributedSampler各 rank 步数是否一致看是否有 rank 因数据早结束而没进最后的 collective按第五 / 六节让所有 rank 参与 eval collective或 eval 完全不碰 collective训练正常、eval 超时几乎可断定是 eval collective 不对齐适当调大NCCL_TIMEOUT只是缓解根因仍是不对齐把第七节的 pytest 接进 CI守护eval 所有 rank 参与、步数一致。九、小结validation 阶段 NCCL 超时根因是 eval 阶段各 rank 的集合通信调用不对齐有的 rank 跑 eval 并调用 all-reduce / gather有的 rank只 rank0 跑、或数据早结束没调用参与的 rank 永远等缺席者 - 超时。训练阶段所有 rank 都参与所以正常。三层层级第一层所有 rank 用DistributedSampler跑 evalcollective 对齐wait_for_everyone第二层用PhaseProtocol校验 eval 步数一致、前后强制 barrier第三层pytest 验证 eval 所有 rank 参与、步数一致锁进 CI。核心教训NCCL 的集合通信是全或无的会合——任何 rank 缺席的 collective 都会让其余 rank 永久等待。训练阶段因所有 rank 对称参与而正常eval 阶段因主进程单独跑 / 数据长度不同极易破坏对称。任何跨阶段的集体通信都必须保证所有 rank 在相同的调用点上会合。
)
