PyTorch 2.13 Release Blog

PyTorch 2.13 版本发布博客 – PyTorch

精选项目

我们非常高兴地宣布 PyTorch® 2.13 版本正式发布（版本说明）！

PyTorch 2.13 版本包含以下改进：

• FlexAttention 支持 Apple Silicon（MPS），在稀疏模式下相比 SDPA 最高可提升约 12 倍性能，并在 CUDA 上实现确定性反向计算路径以支持可复现的梯度计算
• CuTeDSL "原生 DSL" 后端为 Inductor 提供第二条高性能代码路径（与 Triton 并行），显著提升编译速度
• nn.LinearCrossEntropyLoss 将最终预测和损失计算操作合并，可减少大词汇量语言模型训练时 GPU 峰值内存使用量高达 4 倍
• 新增 torchcomms 通信后端用于 PyTorch 分布式，提升大规模集群训练的容错性、可扩展性和调试能力
• FSDP2 现在通过专用进程组（可选启用）实现 reduce-scatter 和 all-gather 通信重叠，提升分布式训练吞吐量
• 通过 pytorch 仓库索引支持 Linux 上 Python 3.15 wheel，包含兼容 free-threaded 3.15t 的构建版本
• 更广泛的平台支持：ROCm 新增 AOTriton 0.12b 与原生 HIP CMake，Arm 新增 Armv9-A torch.compile 目标，Intel XPU 新增设备遥测 API

该版本自 PyTorch 2.12 以来包含 3,328 次提交，来自 526 位贡献者。我们衷心感谢社区的持续贡献。一如既往，我们鼓励您尝试这些新特性并反馈问题，帮助我们持续改进 2.13 版本。更多关于如何开始使用 PyTorch 2.x 系列的信息，请访问我们的入门页面。

有疑问？欢迎参加 2026 年 7 月 22 日上午 11 点 PT 的直播问答，嘉宾包括 Alban Desmaison、Andrey Talman、Piotr Bialecki，主持人 Chris Gottbrath。我们将简要介绍本次发布内容并实时回答您的问题。立即注册

在 2.x 系列中，PyTorch 正从以研究为主的框架演进为统一的、与硬件无关的大规模生产训练和推理平台。PyTorch 2.11 引入了分布式训练的可微集体操作和下一代 GPU 的 FlashAttention-4。PyTorch 2.12 新增了设备无关的 torch.accelerator.Graph API，批处理特征分解速度提升最高达 100 倍，并支持微量化导出。

PyTorch 2.13 在多个平台和规模上进一步提升性能：FlexAttention 在 Apple Silicon 上实现最高 12 倍加速，CuTeDSL 为 Inductor 带来 CUTLASS 级别的 GEMM 内核，融合的 nn.LinearCrossEntropyLoss 可减少大词汇量模型的峰值内存使用量达 4 倍。在分布式方面，新的 torchcomms 后端提升了集群规模下的容错性和调试能力，FSDP2 实现了 all-gather 和 reduce-scatter 之间的通信重叠以提升训练吞吐量。本次发布还标志着 ExecuTorch 被集成到 PyTorch 核心，使设备端推理成为框架的一等公民。

性能改进

FlexAttention Flash 后端的确定性反向计算

此改进专注于提升现有FlexAttention CUDA实现的正确性和调试能力，通过使梯度计算可复现。默认情况下，FlexAttention flash后端在反向传播中使用原子操作进行dQ累积，这会引入非确定性——相同输入的重复运行可能会产生略微不同的梯度。这使得调试、回归测试和可复现研究变得困难。

新的确定性反向路径（compute_dq_write_order）通过预计算的写入顺序取代原子操作，在不显著影响性能的情况下保证梯度逐位可复现。在create_block_mask上的端到端性能开销测量显示，长序列长度（例如S=32768时增加0.2%）的开销远低于1%，使确定性对大多数生产工作负载而言几乎零成本。用户可通过现有torch.use_deterministic_algorithms(True)设置启用该功能，无需额外代码修改。

API不稳定

（PR #174813 by Driss Guessous, Meta）

大型MPS操作迁移到原生Metal

PyTorch的MPS后端此前将大部分操作委托给Apple的MPSGraph框架，这会为每个调度增加编译和调度开销。对于高频、延迟敏感的操作，这种开销可能主导执行时间。此次发布将广泛的操作集迁移至手动编写的Metal计算内核——复制/类型转换、均匀/正态/randint分布、比较运算、归约（sum/mean）、cumsum/cumprod、排序（多块和稳定排序）、嵌入反向传播，以及带边界检查的scatter/gather操作。

原生Metal路径消除了MPSGraph的每个操作编译成本，使PyTorch能直接控制线程调度和内存访问模式，在Apple Silicon上常见训练和推理工作负载的内核启动延迟显著降低。

（PR #184740 by Nikita Shulga, Meta, #185609 and #185119 by Irakli Salia, EPAM.)

Apple Silicon（MPS）上的FlexAttention

FlexAttention是PyTorch的统一API，用于将自定义注意力模式表示为编译成融合内核的普通Python函数，现已支持Metal/MPS。MPS实现为稀疏预填充和解码路径（包括GQA和捕获缓冲区）提供了手动编写的Metal内核。因此，您无需为每个注意力变体编写自定义CUDA内核，只需用FlexAttention编写两行Python函数，编译器将自动为您构建快速内核。

稀疏掩码的基准结果令人印象深刻。在长而稀疏的注意力模式上，FlexAttention相比SDPA的加速效果显著——例如在1×8×32768×64形状、256元素滑动窗口（0.8%密度）的测试中，FlexAttention耗时约35ms，而SDPA耗时约431ms（约12.3倍加速）；较小的8192长度/64窗口案例实现约4.15倍加速。如预期，密集模式仍更倾向于SDPA。API不稳定（PR #182552、#186215和#181575 by Irakli Salia, EPAM）

核心特性

nn.LinearCrossEntropyLoss

在标准的大词汇量训练（例如具有10万+词汇量的语言模型）中，计算交叉熵损失需要生成整个词汇表上的logits矩阵，这可能会消耗数十GB的GPU内存。nn.LinearCrossEntropyLoss（以及对应的linear_cross_entropy函数）将最终的线性投影和交叉熵计算融合为一个模块，按块处理词汇维度，从不生成完整的logits矩阵。这在大词汇量任务中可将内存峰值降低至原来的1/4，同时保持与未融合路径的数值等价性。该实现开箱即用支持标签平滑、权重绑定和z-loss正则化，并与torch.compile集成以进一步优化。作为nn.Linear + nn.CrossEntropyLoss的直接替代方案，采用该模块无需其他代码修改。

（由Pearu Peterson、OpenTeams提交的#172446、#172286和#185852）

使用torch.load直接加载Safetensors

由于Safetensors支持内存映射加载且没有任意代码执行风险，该格式已成为分发模型权重的广泛采用标准（被Hugging Face、Stability AI等使用）。此前加载safetensors文件需要安装并导入单独的库。现在torch.load("foo.safetensors")原生支持该格式，可自动检测格式并直接返回张量。这消除了常见工作流程中的依赖项，使PyTorch成为加载以safetensors格式分发模型的无缝替代方案。

API不稳定（由Nikita Shulga、Meta提交的PR #170592）

Python 3.15二进制支持 – 发布工程

PyTorch wheel现在支持Python 3.15，包括实验性的免费线程3.15t构建。重要说明：Python 3.15目前处于预发布（beta）阶段，最终稳定版本计划于2026年10月发布。支持仅限于torch wheel（torchvision尚未为3.15构建），且仅限于x86_64和aarch64架构的Linux构建，涵盖CPU、CUDA、ROCm和XPU变体。Python 3.15上尚未支持torch.compile。此版本中，该Python版本没有Windows或macOS 3.15 wheel。

Python 3.15和3.15t wheel未发布到PyPI——只能通过download.pytorch.org下载，使用以下任一命令：

CPU

pip3 install torch –index-url https://download.pytorch.org/whl/cpu

CUDA（替换CUDA版本，例如cu126/cu130）

pip3 install torch –index-url https://download.pytorch.org/whl/cu130

ROCm（替换ROCm版本）

pip3 install torch –index-url https://download.pytorch.org/whl/rocm7.2

XPU

pip3 install torch –index-url https://download.pytorch.org/whl/xpu

当在免费线程解释器下运行时，相同命令会安装免费线程3.15t构建。

API不稳定。更新请参见跟踪问题：#184352（由Nikita Shulga提交的PR #182954，Andrey Talman、Meta提交的PR #184600和#186244，Rob Timpe、OpenTeams提交的#186017）

分布式训练

torchcomms后端

PyTorch分布式训练历史上一直依赖c10d的ProcessGroup抽象进行集体通信（如all-reduce、all-gather等），该抽象主要围绕NCCL设计。随着分布式训练变得越来越复杂（多维并行、弹性扩展、异构互连），原始后端的错误处理和可观测性限制已成为运维团队的操作瓶颈。

torchcomms 是一个新推出的通信后端，已集成到 PyTorch Distributed 的 CI 和 device-mesh 路径中，提供增强的容错能力（优雅超时和部分组恢复）、在大规模集群中的更好可扩展性，以及通过结构化日志和集体追踪实现更丰富的调试能力。它作为现有 c10d 后端的现代替代方案，同时保持 API 兼容性。

(PR #181662 by Tristan Rice, Meta, #178533 Pangiotis Kourdis, Intel, and #182057 by Kapil Sharma, Meta)

FSDP2 独立的 Reduce-Scatter 组

在完全分片数据并行（FSDP）训练中，默认情况下 all-gather 和 reduce-scatter 共享同一个 NCCL 通信器。由于 NCCL 会在同一通信器上序列化操作，这两个集合操作无法重叠，导致通信带宽利用率不足。FSDPModule.set_separate_reduce_scatter_group(enable=True) 为 reduce-scatter 分配独立的 NCCL 通信器，使其能够与 all-gather 操作并行执行。这实现了 AG/RS 重叠，可在不修改模型代码的情况下提升完全分片工作负载的训练吞吐量。

(PR #186335 by Wei Feng, Meta)

编译与导出

torch.compiler.set_default_backend

当使用自定义或树外编译器后端（例如针对专用硬件）时，用户过去必须显式传递 backend= 参数到每个 torch.compile() 调用中，这使得代码冗长且容易出错。torch.compiler.set_default_backend 借鉴了 torch.set_default_dtype 和 torch.set_default_device 的模式，允许后端作者或基础设施团队一次性设置进程范围的默认值。所有后续的 torch.compile() 调用将自动使用该后端，除非显式传递的 backend= 参数覆盖了默认值。这简化了在大型代码库中自定义后端的采用过程。

(PR #178944 by Angela Yi, Meta)

平台特性与更新

CUDA

#### Inductor 的 CuTeDSL “原生 DSL” 后端

CuTeDSL 是基于 NVIDIA 的 CuTe（CUDA Templates）库构建的 Python 原生领域特定语言，使开发者能够直接控制 GPU 张量布局、分块策略和内存访问模式。PyTorch 的 Inductor 编译器现在可以将 CuTeDSL 作为 Triton 的替代代码生成后端使用——特别针对矩阵乘法（GEMM）和归一化（RMSNorm）操作，这两者是变压器训练中性能最关键的操作。这些源自 Quack 的内核覆盖方案可在不依赖 Triton 的情况下生成更高质量的矩阵乘法代码。内核编译也从线程池迁移至子进程池，消除了 Python 的 GIL 瓶颈，提升了编译时并行性。

API 不稳定 (PR #181267 by Michael Lazos, #182108 by Simon Layton, and #186310 by Driss Guessous, Meta)

ROCm

#### AOTriton 0.12b、Origami GEMM 选择、原生 HIP CMake

ROCm 增加了三项改进：AOTriton 升级至 0.12b，支持非对称头维度、确定性算法以及新的 GPU 目标（gfx1100/gfx1151 稳定版，gfx950 上部分 FlashAttention v3）。Origami 工具通过分析 GEMM 配置选择替代暴力自动调优，显著减少调优时间。构建系统现在使用 CMake 的原生 HIP 语言支持。

(PR #184288 and #172512 by Xinya Zhang and Umesh Chand, AMD)

Arm

#### torch.compile 的 Armv9-A 目标支持

torch.compile 在 AArch64 上现已支持识别 Armv9-A CPU（例如 AWS Graviton4 使用的 Neoverse V2），通过 Inductor 代码生成器正确传递目标三元组和特性集（128 位和 256 位 SVE）。x86 的行为保持不变。

API 不稳定（PR #184555 由 Zhibo Li，Arm 提交）

XPU（Intel GPU）

#### 设备遥测 API

新增的 Intel GPU 查询 API 可暴露运行时设备状态：内存使用情况（torch.xpu.device_memory_used）、利用率、功耗、时钟频率和温度，以及设备级同步和硬件属性（最后一级缓存大小、集成 GPU 检测）。API 不稳定

（PR #183431、#183429、#183428 和 #183427 由 Guangye Yu，Intel 提交）

C++ ABI

#### torch::stable::Generator

现在通过稳定的 C++ ABI（之前始终传递为 null），自定义内核作者可以获取 at::Generator，从而在 ABI 稳定的扩展中启用 RNG 支持，而无需重新编译 PyTorch 内部组件。

（PR #186423 和 #183930 由 Jane Xu，Meta 和 Chris Leonard，Red Hat 提交）

性能分析与调试

实验性 CUPTI 监控分析器

PyTorch 现有的分析器通过 CUPTI 的活动 API 收集 GPU 活动，这需要同步点，可能在多线程工作负载中导致时间扭曲和与 GIL 的竞争。新的实验性 CUPTI 监控后端异步收集 GPU 指标（完全脱离 GIL），在重用现有 CPU 分析器路径的同时消除了分析器引起的开销。结果是合并的 Chrome 跟踪，准确反映实际执行时间，GPU 侧用户注释会自动重新创建用于 record_function 范围。这使得在不显著影响性能的情况下对生产训练循环进行分析成为可能。

（PR #186037 和 #186295 由 Natalia Gimelshein，Meta 提交）

CUDAGraph.get_graph_data()

在调试 CUDA 图捕获的性能问题时，之前需要外部工具或手动检查才能理解内部结构（哪些内核运行、依赖关系、执行顺序）。CUDAGraph.get_graph_data() 以编程方式暴露完整的图拓扑：节点类型、内核名称、依赖边以及 ID 重新映射以匹配 CUPTI 分析器输出。这使开发人员能够将捕获的图结构与分析的内核启动相关联，从而轻松识别瓶颈、不必要的序列化或捕获图内的次优内核融合。

（PR #183165 由 Natalia Gimelshein，Meta 提交）

废弃功能与不兼容更改

• 已移除命名张量功能。已弃用的命名张量特性（Tensor.names 及相关 API）已硬性移除，以减少开销和代码膨胀。详见 #173895。

• 分布式集合操作重命名为单一方案。all_gather_into_tensor → all_gather_single 和 reduce_scatter_tensor → reduce_scatter_single，与 torchcomms 对齐。旧名称仍作为标记为弃用的薄包装器保留，通过 FutureWarning 警告。详见 #186123。

• 已移除 Bazel 构建。Bazel 构建从未被广泛采用，且依赖过时的 Bazel 6；现已移除。详见 #180883。

非功能更新

• Python 支持：Linux 二进制矩阵中已移除 CPython 3.13t。（初步的 Python 3.15 和 3.15t 二进制支持见上文。）详见 #182951。

• CUDA：CUDA 13.0 仍是默认构建版本；现在 CUDA Linux 始终构建小型轮子，CUDA 12.8/12.9 构建已移除；cu13 二进制中不再包含 ptxas。详见 #180612、#174716。

• Triton : 版本更新至 3.7.1。详见 #186792。

• oneDNN : 子模块升级至 v3.12。详见 #181222。

更新（7/8）：移除了两个已不再使用的术语"prototype"的实例。

/post-content

/inner-wrap