默认通信后端的变化也是诊断变化

PyTorch 2.15 发布说明中，使用 nccl 的进程组默认切换到重写后端；2.14 时它还是可选 nccl2。communicator 随进程组提前创建，满足 NCCL 版本要求时可选择 shrink/grow 快速重配置，让存活 rank 避免完整 bootstrap。旧实现保留 TORCH_DIST_USE_NCCL2=0 与 nccl-legacy 两条回退路径。

这不是只换一个速度更快的库。collective 卡住时，后端无关的 flight recorder 写出事后记录；watchdog 健康状态送到 debug server，一个 rank 超时会触发所有 rank 转储。由此可以对照各 rank 在故障时的工作，而不是仅从最终超时信息猜测原因。原文把这组 API 标记为 unstable，并未承诺自动恢复所有故障。

单边传输与精度控制改变什么

新增 transport API 通过 store 连接 peer，不要求进程组或 collective。首个后端 NIXL 的 read_stream/write_stream 将传输放进 CUDA stream，因此能随 CUDA graph 捕获。它适合表达点对点数据移动，但不能据此假设已有 collective 程序无改动就获得相同语义。

FSDP2 可让 MoE router gate、norm 权重保留 fp32，其余参数用 bf16，并仍在每个 fully_shard 中做一次 all-gather。梯度精度也可逐参数设置，累积直接进入 .grad；reduce_dtype=None 时的默认行为因此有兼容性影响。流水线改为临近接收才分配缓冲、发送结束后释放前向输出，并以 max_outstanding_sends 控制在途发送预算。这些是精度、内存和重叠程度的配置边界，不是统一加速承诺。

阅读这份版本说明的实用顺序

对于分布式作业，我会先核对后端选择和梯度 dtype，再看通信捕获及内存预算，因为默认值变化可能发生在尚未主动使用新 API 时。发布说明还移除 Python 3.10 支持，默认 wheel 转向 CUDA 13.2；这类环境条件应与具体后端功能分开检查。

性能章节的 NVFP4 优化通过把反量化标量折入 GEMM、减少逐层 pointwise launch，以及让 consumer 与 GEMM 尾部重叠来改善 decode。MPS 上的 MoE decode 数字来自 M3 Ultra 的专门路径，不能套用到 NCCL 或 AMD 作业。这里的阅读结论是把升级视作可观测性和执行语义的变化；官方版本说明提供具体入口，但没有替代目标应用的数值与故障回归。

来源：原始工程文章