PyTorch 2.15：分布式训练、低精度推理与多硬件支持全面升级

导语

PyTorch 2.15 延续 2.x 系列从研究框架走向大规模生产平台的路线。本次版本由 583 位贡献者提交 3,117 个变更，重点并不在单一算子，而在分布式训练的可诊断性、显存与通信调度，以及不同硬件平台上的推理效率。

核心要点

• 重写 NCCL 后端成为默认：所有使用 nccl 的进程组默认采用新后端。它支持更积极的通信器创建，并在满足条件时通过 shrink/grow 路径加快故障后的重配置。若需要回退，可使用 TORCH_DIST_USE_NCCL2=0 或 nccl-legacy。
• 集体通信卡死更容易排查：新增与后端无关的 flight recorder。当 collective 长时间无响应时，各 rank 可以写出事后记录，帮助定位是哪一阶段或哪一设备阻塞了训练。该能力尤其面向多机多卡生产环境。
• 一侧数据传输进入 torch.distributed：新的传输 API 以 NIXL 为首个后端，读写操作可直接排入 CUDA stream，并支持 CUDA Graph 捕获，为不依赖进程组或 collective 的数据移动提供基础。
• FSDP2 与流水线并行更可控：精度敏感参数可以保持 fp32，其余参数使用 bf16；梯度累积可捕获为一个 CUDA Graph，梯度规约也能与后续计算重叠。流水线并行则改进接收缓冲区分配、发送预算和 unshard 时机，以降低显存占用与通信暴露。
• 推理和平台覆盖继续扩展：NVIDIA Blackwell 上的 NVFP4 解码减少并优化 kernel 启动；Apple Silicon 增加 FP8、grouped_mm 解码路径和公开的 MPS stream API。版本同时提供 CUDA 13.2 默认 wheel、CUDA 13.4 wheel、ROCm 10.0 wheel，并推进 AMD 与 Intel GPU 支持。

意义与影响

这次升级体现出 PyTorch 正把“能运行”进一步推进到“可观测、可调优、可恢复”。对大模型训练团队而言，通信挂起的事后记录和更细粒度的 FSDP2 控制，可能比单个算子加速更直接地影响运维成本。对推理场景而言，Blackwell 的低精度解码和 Apple Silicon 的专用路径，则显示 PyTorch 正针对不同芯片的工作负载进行更深入的优化。

不过，部分新接口仍标注为 API Unstable，采用前应结合具体版本和硬件环境验证。升级时还需要检查 CUDA、ROCm、驱动及现有分布式故障恢复流程的兼容性。

来源：PyTorch Blog