PyTorch 2.15 换掉 NCCL 后端：一个多卡训练老手的升级笔记

看到 2.15 发布，我先想到的是排障

2026 年 10 月 29 日，PyTorch 2.15 发布，重写后的 NCCL 后端转正为默认。做多机多卡的人看到这条消息大概有两种反应：不跑分布式的人觉得无所谓，跑分布式的人会先去确认回退开关还在不在。

我属于后者。这几年处理过的分布式问题里，最难缠的永远是"进程还在、日志不动、GPU 利用率掉到 0"的那种。所以看到这次改动，我第一反应不是性能能提升多少，而是出问题时能不能定位、能不能退回去。

为什么 NCCL 的改动值得单独留意

NCCL 是 GPU 之间做 all-reduce、all-gather 这些集合通信的底座，DDP、FSDP 基本都压在上面。后端重写意味着拓扑探测、通信调度、错误处理都换了实现。这类改动在小规模实验里几乎看不出来，但在几十张卡、连续跑几个小时的任务上，差异会被放大成 hang 或者吞吐抖动。

这次有三个对排障友好的点

第一，collective 挂起时会转储 flight recorder 的现场。这条对我来说价值最大。以前遇到 hang，只能靠逐个 rank 看堆栈，运气不好什么都抓不到；有了现场转储，至少能判断是哪个 rank、卡在哪一步集合通信。

第二，回退路径留着。TORCH_DIST_USE_NCCL2=0 和 nccl-legacy 都还在。我的习惯是把这类开关提前写进启动脚本，而不是等出了问题再去翻 release note。

第三，默认值变了，行为就跟着变。这不是优点也不是缺点，只是提醒：升级不能只跑一遍单卡 smoke test。

如果是我推这次升级，会这么走

先在非核心集群上，两机两卡跑一遍完整的 all-reduce，再加一次小规模 DDP 训练，观察有没有超时或挂起——不建议直接拿主力集群试。

然后打开 NCCL 调试日志，对比新旧后端的初始化过程和拓扑识别结果。拓扑如果识别得不一样，性能曲线基本也会跟着变。

最后才进主力集群灰度，并且把回退开关和告警一起准备好。顺序不能反，尤其是回退预案，一定要在灰度之前就位。

写在最后

NCCL 后端重写属于那种"升级收益不直观、回滚成本却很高"的变更。我的经验是，越是底层的改动，越要把验证做在前面。8 卡以上的训练任务，与其追新版本，不如先把回退路径握在手里。