10 月 28 日，PyTorch 基金会发布 PyTorch 2.15。这一版本最关键的改动是：在 2.14 中作为可选预览项「nccl2」的重写版 NCCL 后端，如今默认支撑所有 nccl 进程组。回滚路径保留为设置 TORCH_DIST_USE_NCCL2=0 或使用「nccl-legacy」。

自 PyTorch 2.14 以来，该版本包含来自 583 名贡献者的 3117 次提交。对一个训练框架而言，把通信后端整体换掉并设为默认，是风险最高的一类变更；PyTorch 选择在 2.15 完成，说明其生产化路线已从「研究友好」转向「运维友好」。

卡死诊断：从人工复现到自动落盘

集群规模下，一块 GPU 停滞就可能拖垮整个训练任务。2.15 引入与后端无关的 flight recorder（飞行记录器）：集合通信挂起时，它会把事后分析（post-mortem）写入磁盘；看门狗健康状态发布到调试服务器，任一 rank 超时即触发所有 rank 同时转储。此外，在 NCCL 2.29 及以上版本中，容错重配置路径允许存活 rank 跳过完整 bootstrap，降低训练中断的运维成本。

这一方向对应企业侧的真实痛点。Futurum Research 2026 年 10 月发布的《2H 2026 AI 平台全球企业决策者调查》显示，55.4% 的 AI 决策者把 AI 智能体的可靠性与幻觉管理列为生产环境的首要挑战。

FSDP2 与单边传输：更细的控制粒度

FSDP2 新增精度覆盖能力：MoE 路由门控、归一化权重等对精度敏感的参量可保持 fp32，其余部分以 bf16 训练，整个梯度累加步骤可捕获进单个 CUDA graph。新推出的单边传输 API 以 NIXL 为首个后端，支持可被 CUDA graph 捕获的 read_stream/write_stream 传输，为基础设施团队提供绕过集合通信开销的底层原语。调查中 51% 的企业采取自研与采购相平衡的 AI 策略，这类细粒度控制正是从试点走向规模化训练的分水岭。

硬件覆盖：英伟达、苹果、AMD、英特尔全线推进

• 苹果 Silicon：新增 float8_e4m3fn 与 _scaled_mm 支持；grouped_mm 解码快路径在 M3 Ultra 上跑 MoE 解码达到 1.32–1.34 倍 tokens/s；单行 softmax 在 128,256 词表上延迟降低 8 倍，norm 全归约提速 100 倍以上。

• AMD：gfx950 上新增 FlyDSL 内核，gfx1250（MI450）获得 Tensor Data Mover 支持，并提供 ROCm 10.0 wheel。

• 英伟达：CUDA 13.2 成为默认 wheel，CUDA 13.4 可并行选用。

开源作为超大规模云厂商集中的对冲

调查给出的云支出结构值得注意：微软三款产品——Azure AI Foundry 20.4%、Azure OpenAI Service 19.9%、Azure Machine Learning 12.8%——合计占 AI 专用云支出的平均 53.1%。同时 64.0% 的企业通过云厂商采购基础模型。在这一格局下，框架层成为基础设施可移植性的主要抓手：在 PyTorch 上训练的负载，迁移云环境时无需重写训练栈。2.15 的生产加固，实质上加强了云层之下的开源底座。

接下来看什么

11 月 5 日网络研讨会后，生产团队从 nccl-legacy 迁移到新默认后端的速度；2027 年一季度 gfx950/MI450 与英特尔 GPU 能否转化为可测量的非英伟达负载份额；M3 Ultra 上 1.32–1.34 倍的 MoE 解码提升是否加速端侧或边缘企业推理落地；AWS、谷歌、微软在托管训练服务中多快暴露 2.15 的新能力；以及 FSDP2 的 CUDA graph 梯度累加与 fp32 精度覆盖，能否在接下来两个季度进入主流训练框架与配方。