PyTorch 2.14 Release Blog

PyTorch 2.14 版本发布博客 – PyTorch

特色项目

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

PyTorch 2.14 版本包含以下重大改进：

• NVGEMM 将 CuTeDSL 生成的 CUTLASS 内核引入 Inductor，支持尾部融合、缩放和 NVFP4 GEMM，以及与 Triton 和 ATen 一同自动调优的分组归约尾部
• PyTorch 分布式新增 nccl2 后端，从 torchcomms 移植而来，实现完整的集体通信契约，包含非阻塞通信器和即时通信器分割
• 故障容忍成为 c10d 的一级概念，支持原地进程组重配置、单边 RMA 窗口，以及适用于所有后端（而不仅限于 NCCL）的飞行记录器
• Apple Silicon 新增原生线性代数运算，包括 Jacobi 内核 SVD、eigh、QR 和 Cholesky，配合五部分归约重写以及进一步的 MPSGraph 到 Metal 内核迁移
• torch.switch 将 torch.cond 扩展为多分支结构，torch.while_loop 现在可以被 CUDA 图捕获
• 通过 @dynamic_spec 实现跨 torch.compile、torch.export 和 make_fx 的声明式动态形状
• 更广泛的平台支持：通过 TheRock pip SDK 生成 ROCm 7.14 轮子，Intel XPU 新增原生图捕获能力，Inductor 支持 Rubin（sm_107）架构
• 实验性 torch.compile 复数张量支持：可选支持将复数运算分解为实部和虚部计算，使编译器后端能优化更多复数工作负载

该版本包含自 PyTorch 2.13 以来 487 位贡献者的 2,995 次提交。我们衷心感谢社区的持续贡献。一如既往，我们鼓励大家尝试新特性并反馈问题，帮助我们持续改进 2.14 版本。更多关于如何开始使用 PyTorch 2.x 系列的信息，请访问我们的入门页面。关于本版本的任何问题，欢迎参加我们的问答网络研讨会。该研讨会将于 2026 年 9 月 17 日星期四举行，由 Meta 的 Andrey Talman、Natalia Gimelshein，Reflection AI 的 Joe Spisak 以及 Gottbrath Tech 的 Chris Gottbrath（主持人）分享 2.14 版本概述并解答社区问题。立即注册

参加即将于 2026 年 10 月 20-21 日在加州圣何塞举行的 PyTorch Conference North America，与全球 PyTorch 社区交流。通过涵盖编译器与运行时、分布式通信、设备可移植性、发布工程、CI、可观测性、加速器集成、贡献者基础设施等主题的会议，探索 PyTorch 框架的最新进展。PyTorch Conference 是工程师、研究人员和维护者解决训练、推理、内核、应用和负责任 AI 实际问题的汇聚之地。

在 2.x 系列演进过程中，PyTorch 正从以研究为主的框架，逐步发展为统一的、与硬件无关的大规模生产训练和推理平台。PyTorch 2.12 新增了设备无关的 torch.accelerator.Graph API 和微缩量化导出支持。PyTorch 2.13 在 Apple Silicon 上实现了 FlexAttention，为 Inductor 添加了 CuTeDSL 代码路径，并引入了用于大规模集群训练的 torchcomms。

PyTorch 2.14 直接基于这些研究方向进行开发。CuTeDSL 路径逐步成熟为 NVGEMM，这是一个完整的 GEMM 后端，支持尾部融合和低精度计算。torchcomms 作为 nccl2 后端集成到主代码库中，通过容错重新配置和单边 RMA 窗口，将容错能力从后端细节提升为 c10d 概念。Apple Silicon 从关注内核转向原生线性代数运算，动态形状通过贯穿编译、导出和追踪的规范实现声明式定义。

PyTorch 2.14 在性能、可靠性和硬件支持方面带来了显著改进。该版本引入了 NVGEMM，这是一种新的 GPU 数学后端，可自动为矩阵运算选择最快的内核——包括支持降低精度格式以减少训练和推理过程中的内存占用。对于跨多台机器进行训练的团队，重新设计的分布式通信后端（nccl2）提供了更好的可扩展性，而新的容错功能使训练任务能够在节点故障后恢复，而无需从头开始重新启动。

Apple Silicon 用户可受益于原生线性代数例程（SVD、QR、Cholesky 等）以及广泛迁移到手动调优的 Metal 内核，显著降低 Mac GPU 的开销。在编译器方面，新增的控制流原语（torch.switch、torch.while_loop）为模型作者在编写仍能高效编译的动态逻辑时提供更多灵活性，而新的 @dynamic_spec 装饰器则提供了一种简洁统一的方式，声明哪些张量维度可以在运行时发生变化——简化了编译、导出和追踪流程中的工作流。

平台支持扩展至 AMD ROCm 7.14、Intel XPU 原生图捕获以及 NVIDIA 下一代 Rubin 架构。在底层实现上，编译器现在默认将通信与计算重叠，更智能地批量处理小型 GPU 内核，并减少每次调用的开销——所有改进共同作用，使端到端模型执行速度更快，且无需用户修改任何代码。

性能改进

大型 MPS 操作迁移到原生 Metal

继 2.13 版本启动的迁移工作后，更多 MPS 操作器从 Apple 的 MPSGraph 框架迁移至手写 Metal 计算内核，包括 index_add、index_select、argmin、argmax、conv3d、median、nanmedian、linspace、arange、nan_to_num、log_sigmoid、sigmoid_backward、mish 和 GLU。

归约操作获得了专门的五部分重写，涵盖完整归约、内维归约、步长和批量外维归约、小维和窄内核，以及 argmax 和 argmin 的 split-K 路径。最后一部分将 min 和 max 从 MPSGraph 迁移出去。跳过输入上转换并使用 vec4 加载，消除了 MPSGraph 路径无法避免的工作。

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

API 不稳定

（PR #191101、#191097、#191098、#191099 和 #191100 由 Irakli Salia、Hugging Face 提交，#187109 和 #188802 由 Nikita Shulga、Thinking Machines Lab 提交）

MPS 内存和复制路径

长期运行的解码工作负载使 MPS 缓存分配器的保留内存占用增长过快。现在分配器将大块分配分组以限制保留内存，并使用放置堆以减少碎片化。

主机与设备之间的传输路径也得到了优化。CPU到MPS的复制操作直接从固定缓冲区进行，采用事件延迟回收机制；相同数据类型且连续的复制操作使用计算内核而非图结构；逐元素操作在内部连续切片视图上实现向量化；cat操作针对任意维度新增了向量化连续快速路径。

(PR #187441 和 #190438 由 Irakli Salia, Hugging Face, #189512 和 #188613 由 Nikita Shulga, Thinking Machines Lab, #188483 和 #188200 由 Joona Havukainen, Apple)

MPS 上的 F.linear 解码路径

单令牌解码将 [B, 1, K] 激活值传递给 F.linear，这种形状此前在 MPS 上会偏离快速路径，根据修复记录，这会导致 bf16 和 fp16 精度下 8.5 倍的性能下降。现在已正确路由序列长度为 1 的情况，新增的 GEMV 内核支持主导自回归解码的向量-矩阵形状。通过路由修复和新 GEMV 内核的结合，解决了 MPS 与 CUDA 在自回归工作负载之间最大的性能差距之一。

(PR #189855 由 Giovanni Versiglioni, Apple, #186927 由 Irakli Salia, Hugging Face)

Inductor 默认启用计算与通信重叠

Inductor 的 simple_overlap 重排序机制通过将集合操作与独立计算交错执行，使通信不再处于关键路径上。该功能现已默认启用，而非需要手动开启。通过默认启用重叠，经 Inductor 编译的分布式训练工作负载可自动获得更好的 GPU 利用率，无需任何配置更改。

(PR #184240 , # 184235 由 Ivan Kobzarev, Meta)

训练图的 reorder_for_locality 可选开启

reorder_for_locality 是 Inductor 的后向传播局部性重排序功能，现在可通过新配置项 reorder_for_locality_in_training（默认关闭）在训练图中启用，此前该功能仅在推理阶段运行。这将局部性优化扩展到训练工作负载，为用户提供了调节训练图缓存行为的调优选项，同时不影响默认行为。

(PR #186643 由 @reger-men)

Inductor 中的组合内核与约简操作

组合内核将多个小型内核合并为一次启动，但此前批次中若存在一个非常大的约简操作，会主导整个内核的形状。现在大尺寸约简操作已从组合分区中分离，组合约简支持动态 RBLOCK 缩放，子内核主体以非内联设备函数形式发出以降低寄存器压力。每个组合内核主体共享代码，针对 GB200 调整了拆分约简启发式策略。总体效果是减少内核启动次数并优化资源使用，弥补了单个过大约简操作可能影响整个融合批次的性能缺口。

(PR #186668 , #186957 和 #190689 由 Karthick Panner Selvam, Meta, #184323 由 Jason Ansel, Meta, #188579 由 Liqiang Lu, Nvidia)

Dynamo 每次调用开销

对于包含许多小型编译区域的模型，每次调用的固定成本比图质量更重要。此次发布在多个方面降低了该成本。compile_wrapper 避免了每次调用时 DispatchKeySet 的 pybind 频繁变更，torch._dynamo.disable 采用更高效的路径，预图分析器标记仅在分析器激活时才生成。未使用的函数输入跳过守卫创建，pytree 参数（如 dataclasses 和 namedtuples）的 invoke_subgraph 重用查找速度更快。这些微优化共同降低了进入编译代码的开销，使 torch.compile 更适用于现实世界中混合大量小型编译区域和即时执行的模型。

(PR #190390 , #190392 和 #190623 由 William Wen, Meta 提交，#187782 和 #191817 由 Aditya Sanjeev 提交)

即时调度与 CPU 内核

多个即时模式的热点路径成本降低。PyObject 调度得到优化，AOTAutograd 在保存反向传播的图输入视图时避免了昂贵的 Tensor.detach() 操作，当分析器关闭时 autograd 停止复制 at::Tensor，addmm 在 C 和 D 不同时避免设备间复制，CPU 的 quantile 和 nanquantile 使用部分选择而非完整排序。

这些针对性修复降低了即时模式中的每操作成本，收紧性能下限，使线性层、autograd 书keeping 和统计聚合等常见操作不再携带不必要的开销。它们在不强制用户使用 torch.compile 的情况下，保持了 PyTorch 默认开发体验的速度。

(PR #187949 #189759 和 #189582 由 Richard Zou, Meta 提交，#191706 由 Animesh Jain, Meta 提交，以及 #188394 由 Kimon N. 提交)

核心功能

torch.linalg.polar 和 torch.linalg.matrix_sqrth

torch.linalg 的两项新增功能。torch.linalg.polar 使用 cuSOLVER 的 QDWH 算法计算极分解，CPU、CUDA 和 MPS 上均有反向公式，使其可在训练循环中使用而不仅限于分析。torch.linalg.matrix_sqrth 计算对称和埃尔米特正定矩阵的矩阵平方根，此前此类情况需要手动组合特征分解。

(PR #185837 由 Simon Layton, Meta 提交，#189732 由 Irakli Salia, Hugging Face 提交，#187987 由 Colin Alberts, Cisco 提交)

Autograd 扩展点

新增三项功能提供了对构建和检查 autograd 图的更多控制。torch.autograd.graph.node_creation_hook 在每个 autograd 节点创建时触发，使工具能够在图构建时附加元数据或注册钩子，而非后续重建上下文——典型场景是将反向传播的内存使用归因于生成它的前向区域。ctx.set_output_grad_dtype 允许自定义 autograd.Function 声明输出梯度的 dtype，独立于输出本身的存储 dtype，适用于混合精度函数中两者不匹配的情况。cdist 和 pdist 现在支持双重反向传播，解除此前 create_graph=True 的使用限制——海森矩阵、梯度惩罚以及通过成对距离计算的海森向量积现在均可实现。

API 不稳定 (PR #189284 由 Edward Yang, Meta 提交，#189634 由 @SongyuanZhao 提交，#188901 由 Colin Alberts, Cisco 提交)

torch.switch 高阶操作

torch.cond 表达的是双向分支，因此要实现 n 路分发必须使用嵌套条件语句，这会增加跟踪图的规模并模糊意图。torch.switch 是一个新的高阶操作，用于根据索引进行多路分支，Dynamo 通过提升参数去重机制，使共享操作数不会在每个分支中被重复提升。其结果是提供了一种更高效且表达能力更强的方式来跟踪具有多路分支的模型，特别是在 torch.cond 嵌套曾是实际障碍的专家混合架构中。

(PR #182902 和 #188374 由 Thomas Ortner，IBM 提交)

适用于秩 3 输入的 SDPA 融合后端

缩放点积注意力现在对秩 3 输入会调度到融合的 CUDA 后端，而不是回退到数学路径，因此传递未批处理或已展平张量的调用者无需重塑即可获得融合内核。此修复关闭了一个常见性能陷阱，即缺失或展平的批处理维度会静默绕过快速融合内核。

(PR #192271 由 Driss Guessous，Meta 提交)

对复数张量的 torch.compile 实验性支持

torch.compile 现在支持使用复数张量的程序。支持的复数操作会被分解为编译器后端可优化的实值计算。这使得信号处理、科学计算和复数神经网络等更复杂的数字工作负载能够受益于编译执行。并非所有复数操作目前都已支持。详见功能跟踪问题，实现

(PR #167621 和 #169832，#172813 由 Hameer Abbasi，OpenTeams 提交)

更小的 API 增加项

本次发布新增了一些较小的公共功能。

• torch.utils.checkpoint.checkpoint 在 eager 模式下接受装饰器和柯里化调用约定 ( #189411 由 Edward Yang，Meta 提交)。

• 只读 DLPack 导出和 ReadOnlyTensorWrapper，使消费者可以接收到必须保持不变的张量 ( #188554 由 Edward Yang，Meta 提交)。

• Generator.philox_state 向 Python 暴露 Philox RNG 状态保留功能 ( #191019 由 Simon Layton，Meta 提交)。

• torch.accelerator 新增 initial_seed、get_rng_state 和 get_rng_state_all，缩小了与 CUDA 特定 RNG API 的差距 ( #186597 由 Guangye Yu，Intel 提交)。

• LBFGS 新增 maximize 选项，并在空参数组上作为空操作 ( #187309 由 Raj Vijay Firke，Red Hat 提交)。

• linear_cross_entropy（在 2.13 中引入）在 chunked 路径上支持概率目标 ( #187053 由 Pearu Peterson，Quansight 提交)。

• c10::utils::get_env 和 set_env 暴露给 Python ( #191015 由 Nikita Shulga，Thinking Machines Lab 提交)。

Python 3.15 支持与 Torchvision ABI 稳定性 – 发布工程

PyTorch 2.14 增加了对 Python 3.15 的二进制支持，包括无 GIL 的自由线程构建（3.15t）在所有平台。为 x86_64 和 aarch64 Linux、Windows 和 Apple Silicon 上的 macOS 发布了轮子，涵盖 CPU、CUDA、ROCm 和 XPU 构建。同时 TorchVision 0.29.0 发布，与相同平台集的 3.15 和 3.15t 轮子匹配。

TorchVision 现在相对于 torch 2.14 是 ABI 稳定的！这意味着 TorchVision 0.29 将与未来的 torch 版本（如 2.15、2.16 等）兼容。升级 torch 时无需重新安装 TorchVision。因此，我们可能会停止与 PyTorch 同步发布 TorchVision。但 TorchVision 仍会持续维护和开发：我们仍会发布版本，只是更新频率可能不同。

安装

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.14

XPU

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

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

对于免费线程构建同样适用。安装到 3.15t 解释器时，pip 会自动解析 cp315t wheel 文件。

torch.compile 目前尚不支持 Python 3.15

2.14 版本对 Python 3.15 的支持仅限于 eager 模式。在 Python 3.15 下调用 torch.compile 会引发 RuntimeError 而非静默回退，因此该限制会立即显现而非表现为性能损失。如果工作负载依赖 torch.compile，目前建议继续使用 Python 3.14 或更早版本。

Dynamo 对 3.15 的支持正在积极开发中，新解释器的字节码和符号转换处理已实现。开发进展可跟踪 pytorch/pytorch#184352。

分布式训练

nccl2 后端

torchcomms 在 2.13 版本中作为通信后端集成到 PyTorch Distributed 的 CI 和 device-mesh 路径中。在 2.14 版本中，API 已合并到主代码库，新增了 nccl2 c10d 后端（通过 USE_C10D_NCCL 控制），基于可复用的 NcclApi 抽象实现了完整的 Work 合约。该后端仅支持 eager 模式，新增了一侧窗口、容错、挂起/恢复内存卸载等功能，并大幅简化了实现。兼容性 nccl-lazy 包装器会按需为需要旧延迟初始化行为的工作负载构建对等 P2P 通信器。

（由 Tristan Rice, Meta 提交的 PR #188582、#189359、#190943 和 #191272，以及 Tushar Jain, Meta 提交的 #191528 和 #192105）

c10d 中的容错集合操作

在大型作业中某个 rank 失败时，通常的恢复方式是拆除进程组并重启，这会导致整个集群的热状态丢失。现在后端和 ProcessGroup 提供了重新配置接口，允许在原地重建组，通过相同的路径连接中止钩子和集合操作前后的钩子。Gloo 与 nccl2 一同获得容错支持，重新配置 API 已在文档中说明。

（由 Tristan Rice, Meta 提交的 PR #186298、#186300、#187381 和 #191384）

单边（RMA）窗口 API

后端和 ProcessGroup 新增了单边窗口接口，与现有的双边集合操作一起提供远程内存访问语义。单边操作允许 rank 在不需对等方发起匹配调用的情况下读写对等方内存，适用于嵌入查找、权重传输和专家路由等不规则访问模式。这通过 nccl2 后端暴露了新的 ncclGet 和 ncclPut API。

（由 Tristan Rice, Meta 提交的 PR #186299 和 #189360）

与后端无关的飞行记录器

飞行记录器（用于诊断挂起和不匹配集合操作的集体跟踪缓冲区）此前绑定到 NCCL。现在 FlightRecorderHook 通过 ProcessGroup 钩子进行记录，因此适用于任何后端，日志序列化可通过 DebugMode 实现跨平台。调试 Gloo 或自定义后端作业时不再需要放弃跟踪信息。

(PR #189363 by Tristan Rice, Meta, #185010 by Jason Ansel, Meta)

可插拔分布式后端

以前添加通信后端意味着要修补c10d。现在后端可以通过Python入口点进行注册，后端字符串会自动限定作用域，实现访问器也已开放。我们已将PyProcessGroup的跳板程序与C++实现同步，因此树外后端可以从C++或Python中实现完整的集体操作接口，包括batch_isend_irecv、合并管理器以及清理后的*_single变体。

(PR #187388 , #186853 and #188570 by Tristan Rice, Meta, #187494 by Kapil Sharma, Meta )

torch.distributed API改进：set_timeout、按操作超时、get_backend_impl、钩子、weights_only=True、*_single

我们对torch.distributed API进行了大量改进，既增强了控制能力，也清理了一些不一致性。现在可以通过稳定的torch.distributed.set_timeout方法在初始化后更改进程组的集体操作超时时间——例如在加载缓慢的检查点时延长超时，或在某个进程卡住时缩短超时使其快速失败而非等待完整默认窗口。我们还支持所有超时场景下的按操作集体操作。通过torch.distributed.get_backend_impl可以更便捷地访问高级后端特性，并为其添加程序化钩子来自定义行为和实现可观测性。对象集体操作现在支持与torch.load相同的weights_only=True模式，可提升训练集群安全性。我们还统一了所有单张张量变体的命名方式，现在都使用_single后缀，例如all_to_all_single。

(PR #187387 and #187693 by Tristan Rice, Meta)

DTensor单维分片策略

DTensor的分片规则过去是针对整个设备网格按操作符编写的，因此每个规则都需要列举所有网格维度的放置组合——当网格维度超过一个时，这种写法冗长且容易出错。本次发布继续将操作符覆盖范围转移到单维策略函数，这些函数描述单个网格维度如何对操作符进行分片，而将网格扩展的逻辑交给框架处理；矩阵、数学和张量操作已在此处转换，直接注册的register_op_strategy操作符数量从158个减少到114个。卷积操作在窗口能精确平铺最后一个空间维度时（零填充、膨胀系数1、步长等于内核宽度、该维度可被内核宽度乘网格尺寸整除）也新增了分片支持，这些卷积在正向和反向传播时将在本地执行，而非通过allgather进行复制。新规则比被替换的旧规则更严格，因此以前偶然匹配基础策略的注解现在将被报告需要重新分布，迁移后的操作符也不再生成Partial("product")。这使已注册分片规则的总操作符数量达到1239个，较2026年1月的585个显著增加。

(PR #186667 , #179203 , #186754 , and #192147 by Anshul Sinha, Meta)

对称内存：NCCL后端修复和内存分配布局

对称内存的 NCCL 后端存在一些仅在运行时才会暴露的缺陷：barrier() 会引发未实现错误，且信号垫在分配后从未被清零，导致信号协议缺乏可靠的实现基础。这两个问题现已修复——barrier 现在复用现有的 CUDA 屏障内核，信号垫在分配时即被清零。信号垫现在在所有三个后端（CUDA、NCCL、NVSHMEM）的每个对称分配中都位于最前面，这样回收或调整大小的分配不会继承被污染的信号垫，且只需清零信号垫本身而非整个内存块——大型分配不再需要每次 alloc() 时都执行完整的缓冲区 memset 操作。在多流场景中，信号垫清零时机可能较为复杂，用户可能希望在用户空间代码中显式执行以确保顺序正确。当驱动程序报告支持时，CUDA 分配现在会设置 GPUDirect RDMA 能力标志。信号垫插槽仍在同一分配的进程组之间共享，因此重叠组的并发屏障可能会相互干扰。

API 不稳定（PRs #188051 by Kapil Sharma, Meta, #189088 by Junjie Wang, NVIDIA, #189941 by Natalia Gimelshein, Meta）

对称内存：从普通集合操作访问 NCCL 对称内核

基于对称内存的内核在 NCCL 2.27 版本中已支持 NVLink 域。这些功能自 2026 年 1 月起在 PyTorch 的夜间构建版本中实现，但此前缺乏便于用户使用的文档说明。根据用户反馈，本次发布改进了相关文档。现在文档涵盖对称内存和环形/树状集合操作——通过 register_mem_pool(pool, symm=True) 注册 torch.cuda.MemPool，或 set_backend("NCCL") 加上 rendezvous 配置，同时说明了适用规则（任意数据类型的 all_gather；仅支持 float 类型（排除 float64）的 SUM/AVG 操作）和要求（NCCL 2.27+、单一直接 NVLink 域、NCCL_WIN_ENABLE）。用户可通过 NCCL_DEBUG_SUBSYS=TUNING 下的 [Symmetric] 标签或性能分析中的 ncclSymkDevKernel_* 名称进行验证。

API 不稳定（PR #192515 by Kapil Sharma, Meta）

#### 对称内存：单边 get 操作

通常从其他 rank 读取数据需要通过集合操作实现：所有 rank 都会参与并同步，即使只有单个 rank 实际需要数据。现在对称内存新增了 get 操作，这是一种单边复制机制，可直接将对端的对称内存分配复制到本地目标张量，无需对端参与或全局同步。该功能支持 NVSHMEM、NCCL 对称内存和 CUDA 后端（XPU 和 rocSHMEM 尚未支持），要求源内存为通过 rendezvous 注册的对称内存分配，且数据类型和元素数量需与目标匹配。这是当前进行中的单边 DTensor 工作的基础实现，可直接用于任何需要从单个 peer 拉取数据而非全量收集的算法场景。

API 不稳定（PR #182378 by Benjamin Brock, Intel）

TokenSwitch

专家混合训练的大量时间消耗在将每个token发送到持有其选定专家的rank以及将专家输出带回的过程，团队通常会自行实现这一过程，包括反向传播，且需依赖供应商的内核库。TokenSwitch为其提供了接口——create_routing()、dispatch()、combine()，其中TokenSwitchNCCL是首个后端，基于NCCL的专家并行内核构建。当不指定out=参数时，dispatch和combine返回可微张量，因此可以像普通autograd追踪的Python代码一样编写MoE层；若传递out=参数，则保留缓冲区复用路径但放弃autograd。该代码尚处于早期阶段：该模块为私有模块，需要使用USE_NCCL_EP=1并针对NCCL 2.30版本进行编译，因此目前仅限NVIDIA使用，且无法通过标准wheel获取。

（由Ke Wen，NVIDIA提交的PR #178712和#181314）

单Rank编译

分布式任务中的每个rank都会独立编译相同模型，因此在训练开始前，单次耗时数分钟的编译操作会被重复执行N次。单Rank编译机制使编译产物可被所有rank复用：make_fx不再将追踪rank的设备信息写入factory和cast操作，Inductor的代码生成器和Triton启动器会在加载时解析设备信息，因此生成的源码在所有rank间保持一致，基于cuda:0编译的内核可在cuda:3上加载运行。DeviceMesh.get_group()同样从mesh图中获取组信息而非硬编码torchbind ProcessGroup，这曾导致图无法序列化；在legacy标志下，dist.all_reduce等传统集合通信操作会以函数式形式进行追踪。torchtitan的实验性graph_trainer展示了预期形态：单进程提前编译并生成一个所有rank在启动时加载的产物，无需N-GPU任务即可生成——但该模式假设每个程序仅使用单个加速器设备，若图涉及第二个设备则会拒绝执行，且该功能默认关闭，需通过torch.compiler.config.compile_on_one_rank启用。

（由Aaron Orenstein，阿尔伯塔大学提交的PR #187869、#186892、#187870和#188215）

编译与导出

使用@dynamic_spec的声明式动态形状

PyTorch 现在可以通过指定哪些输入维度会发生变化来实现动态形状支持，但此前每种入口点都需要不同的机制——torch.export 使用 dynamic_shapes 字典，torch.compile 使用粗粒度的 dynamic= 标志，make_fx 使用全局追踪模式。在所有情况下，这些声明都位于调用站点，远离其描述的模型。此版本新增了 torch.fx.experimental.dynamic_spec 下的 ShapesSpec API：只需定义一次维度（如 ShapeVar("batch", min=2, max=128)），即可在多个输入中复用，构建派生维度如 batch * 2，并附加假设如 batch % 2 == 0。所有三种入口点现在都通过 dynamic_shapes= 关键字统一接受该规范。@dynamic_spec 装饰器可将该规范直接附加到函数或模块的 forward 方法上，因此 torch.compile、严格或非严格的 torch.export.export，以及 make_fx(tracing_mode="fake") 都能自动识别，无需在调用站点传递参数。通过这种方式声明的维度会成为未绑定符号，编译器无法静默地根据偶然追踪到的批次大小进行特化——代价是形状相关的分支现在会以数据依赖的错误形式暴露，而非通过守卫和重新编译。该 API 仍处于实验阶段并持续演进：make_fx 的支持目前仅限于 tracing_mode="fake"，且将规范与 prefer_deferred_runtime_asserts_over_guards=True 结合，或装饰器与调用站点的 dynamic_shapes= 参数同时使用时会引发错误。

API 不稳定（PR #187639、#185982、#187602、#186751 和 #187010，作者：Laith Sakka，Meta）

AOTInductor 外部常量与零拷贝权重共享

此前，若要服务多个共享相同权重的 AOTInductor 模型，每个模型容器都需要在 GPU 上分配并加载自己的权重副本。新的 C API AOTInductorModelContainerCreateWithExternalConstants 允许调用者在容器创建时传入权重张量；AOTI 完全跳过常量加载，直接使用调用者的内存，因此一个副本可以支持多个模型，或通过 CUDA IPC 在进程间共享。调用者保留所有权，这意味着这些张量的生命周期必须长于容器，且该 API 仅通过 C ABI 提供，目前尚无 Python 入口点。现有代码路径不受影响——新构造函数仅在明确提供外部常量时才会触发。对于需要服务同一基础模型多个变体的舰队，这将每个模型的权重内存转化为单个共享分配。

API 不稳定（PR #188643，作者：@iuliur-meta）

AOTInductor 编译

此前，使用 triton.autotune_at_compile_time=False 打包模型时，整个代码生成过程需要运行两次：编译、运行以收集内核元数据、重置状态，然后重新编译以进行打包。现在该路径在单次代码生成过程中即可生成 JIT 和 AOTI 包装器主体，仅运行一次 JIT 主体并使用真实输入捕获 Triton 内核配置，然后将其嵌入打包后的源代码中。torch.cond 和 torch.while_loop 现在在新路径上得到支持。此外，cpp_wrapper 现在可以生成显式的用户流和事件（目前仅限 CUDA，且无法与 CUDA 图表同时使用）。懒惰自动调优流程中的第二次代码生成已移除，追踪的多流代码现在可保留在 AOTI 包中。

API 不稳定（PR #184735 和 #184736，作者：@desertfire；PR #182971，作者：Brian Bustamante）

AOTInductor 常量加载

加载模型权重会将权重从主机内存复制到GPU，而同步地从可分页内存中复制出数据会强制执行全局设备同步，这会阻塞其他流上正在运行的推理。AOTInductorSetUsePinnedAsyncConstantsCopy通过固定内存中转缓冲区来路由常量加载和更新，使主机复制与设备传输重叠，配套的调用用于设置缓冲区大小，AOTI_COPY_USE_PINNED_ASYNC环境变量作为回退方案。该功能默认关闭，必须在创建模型或容器前启用。此前从加载.so文件到模型准备就绪的间隔没有日志输出，现在设置AOTI_LOG_LOADING会输出[AOTI_LOAD]标记，包含复制时间及固定内存池诊断信息。对于在实时流量中频繁切换模型的服务器，这种组合可以在加载期间保持GPU其余部分持续忙碌，并使缓慢的加载过程无需重新构建即可诊断。

API 不稳定（PR #186258 和 #186309 由 @joshuuuasu 提交）

Helion 后端集成

手动编写快速GPU内核需要选择分块大小、循环顺序和内存访问模式，然后为每个新形状和每个新GPU重新调整所有参数。Helion将这一过程提升到更高层次：你只需用Python编写算法，Helion会搜索调度空间并为你生成Triton代码。PyTorch 2.14将Helion注册为原生DSL注册表（2.13引入）的第三个条目，因此Helion编写的内核可以像Triton和CuTeDSL内核一样覆盖ATen操作，通过torch.backends.python_native.helion进行控制。注册需要helion包及其降级后端，ROCm构建版本不可用。此版本中没有操作符通过Helion路由；这是为后续版本中基于Helion的内核覆盖奠定基础。

（PR #190636 由 Karthick Panner Selvam，Meta 提交）

平台特性与更新

CUDA

#### NVGEMM，Inductor 的 CuTeDSL GEMM 后端

PyTorch 2.13 引入了用于 TorchInductor 的 NVGEMM CuTeDSL 后端，此次发布我们很高兴扩展对尾部融合（epilogue fusion）的支持——此前版本只能生成独立内核，后续操作（如偏置加法、激活函数、重新缩放）需在单独内核中重新读取内存结果。本次发布采用 NVGEMM，即 NVIDIA 官方 cutlass.operators API，生成的候选内核与 Triton 和 ATen 在 mm、addmm 和 scaled_mm 操作中竞争。其内核以 Triton 模板方式融合尾部操作：addmm 的偏置加法、链式逐点操作以及对 GEMM 结果的归约操作，包括返回归约值和完整输出矩阵的场景。融合现在也覆盖低精度路径，因此 scaled GEMM 后的逐点操作会折叠到内核中，NVFP4 的运行时全局缩放在尾部处理中应用而非单独乘法。融合内核还会缓存到磁盘，因此今天从头重新编译它们的进程将复用已有缓存。通过在 max_autotune 下的 max_autotune_gemm_backends 添加 NVGEMM 启用该功能，需要 nvidia-cutlass-dsl 4.6.0，NVFP4 路径需要 Blackwell，后端无法表达的尾部操作会回退到 Triton，这些场景保留现有融合方式。我们正在持续投入该后端，目前正在进行自动调优时间和性能的进一步优化。

API Unstable (PRs #186183 , #187013 , #189772 , #189774 , #189805 , #190808 and #190823 by Michael Lazos, Meta)

#### CUDA 图生命周期钩子

想要从外部监控 CUDA 图的工具（如性能分析器或内存追踪器）之前只能注册每个图的钩子，这在图由 Inductor 或 NCCL 而非工具本身构建时毫无帮助。此版本新增了模块级钩子，这些钩子会在进程中的每个图上触发（捕获开始和结束、重放开始和结束、实例化、销毁），同时新增每个图的重放开始/结束钩子，以及之前不存在的捕获开始钩子。CUDAGraph 还新增了 register_destroy_callback 和 retain_object 方法，用于将清理操作或对象生命周期与图本身绑定；如果回调释放了图仍引用的内存，请传递 synchronize_before_release=True，因为销毁操作是异步的，在重放过程中释放内存可能导致使用已释放内存的错误。现在可观测性工具可以跟踪图的完整生命周期，而无需图代码知道工具的存在，且注册钩子不会产生任何开销。

API Unstable (PR #190582 and #190602 by Natalia Gimelshein, #191299 and #192162 by @dolpm)

#### 单个 CUDA 图中的多个内存池

此前 CUDAGraph 捕获只能绑定到一个内存池，这意味着需要从独立内存池分配的内存（对称内存是迫使这一问题出现的典型场景）无法参与捕获区域。现在捕获可以使用 torch.cuda.use_mem_pool() 进入侧边内存池，图会保留所有内存池：g.pool() 返回传递给 torch.cuda.graph() 的主内存池，g.pools() 返回包含所有侧边内存池的完整集合（包括捕获期间进入的内存池）。这使得对称内存缓冲区可以在 CUDA 图中存活，从而解除分布式工作负载的图捕获限制（这些工作负载通过专用内存池进行分配）。一个现有限制仍然存在：use_mem_pool 按线程 ID 路由分配，因此在启用多线程 autograd 的情况下，若在 use_mem_pool 中调用 .backward()，反向传播分配不会发送到内存池——如果需要此功能，请在同一线程上运行 autograd。

API Unstable (PR #187929 by @Aidyn-A)

#### torch.while_loop 的 CUDA 图捕获

数据依赖的循环次数一直是工作负载无法完全被 CUDA 图捕获的标准原因之一，这迫使需要设备到主机的拷贝来决定执行多少次迭代，并在你最希望保持捕获完整性时中断捕获。现在 torch.while_loop 可以通过 CUDA 的 while 条件节点被捕获到 CUDA 图中：条件在节点添加前于父流中评估，并在每次循环体执行结束时重新评估，因此单个捕获图在重放时可以运行由运行时决定的迭代次数。这本身不会带来吞吐量提升——关键在于循环不再迫使你退出图捕获，因此像对可变长度索引张量进行归约，或对可变数量的打包序列应用损失等场景，现在可以保留在一个图中。常规的 while_loop 约束仍然适用，包括固定最大循环次数和仅支持张量作为携带输入。

API Unstable (PR #186055 by Daniel Galvez, NVIDIA)

#### CUDA 图的内核注释

torch.cuda.graph_annotations 使与 CUDA 图捕获一起使用的内核注释 API 公开：mark_kernels 允许你通过名称标记 GPU 工作，这样在后续导出性能分析器跟踪时，会以标签形式显示，而不是作为匿名内核启动。此前这仅适用于在 mark_kernels 作用域内词法捕获的前向传递内核——反向传递内核在自动微分实际运行时稍后捕获，从未被标记。现在反向传递内核会通过上述的 node_creation_hook 机制自动注释，将其归因于创建它们的前向作用域，包括通过双重反向传递和检查点重新计算。对于希望自行进行反向归因的调用者，可通过 backward=False 选择退出。

API 不稳定（PR #189417 和 #191563，Edward Yang，Meta）

#### 事后内存快照注释

内存快照功能已允许你向分配附加元数据，但仅限于分配创建时——某些信息（例如张量是否被自动微分图保留）只有在被打包到反向磁带后才能知晓。torch.cuda.memory._annotate_tensor(tensor, metadata) 允许你事后向活动分配附加元数据，作为独立的时间戳事件记录，不会覆盖分配时记录的内容。视图和偏移张量会自动解析到分配的基地址，内存快照可视化工具现在会在时间线中将这些注释与分配信息并列显示。

API 不稳定（PR #190575，Edward Yang，Meta）

#### CUDA 上的 TunableOp

TunableOp 在运行时会为每个输入形状配置可用的 GEMM 实现并缓存最快的方案，但在 CUDA 构建中，此前它只能选择一个候选方案——cuBLAS 默认方案。现在它还会注册 cuBLASLt 启发式候选方案，候选数量由 PYTORCH_TUNABLEOP_CUBLASLT_REQUESTED_ALGO_COUNT 或 torch.cuda.tunable.set_cublaslt_requested_algo_count() 设置。这是一个用于挽救标准启发式处理效果差的形状的工具，而非通用加速方案：在 H100 上平均性能基本持平，单个形状性能范围从 0.66x 到 1.57x。离线调优也修复了当填充后的主维度等于 m/n/k 之一时，此前 tune_gemm_in_file 会静默调整错误形状的问题。

API 不稳定（PR #186270，Grayson Derossi，NVIDIA 和 #189355，Aditya Srichandan，AMD）

#### cuBLASLt 作为分组 GEMM 后端

分组 GEMM 驱动 MoE 层，其中许多不同形状的矩阵乘法会同时发出。cuBLASLt 加入 CUTLASS 和回退方案作为后端：在 Blackwell（CUDA 13.2+）和 Hopper（CUDA 13.3+）上 fp16 的默认后端，通过 torch.backends.cuda.matmul.prefer_cublaslt_grouped_gemm = True 可选启用 bf16。这种划分反映了测量结果——它在不规则的 MoE 风格分组上表现优异，但在统一的分组上通常落后于 CUTLASS 的 bf16 内核。它与 torch.compile 和 CUDA 图兼容；唯一需要自行处理的是矩阵和主维度的 16 字节对齐。

API 不稳定（PR #177037，Grayson Derossi，NVIDIA）

ROCm

#### 分组 GEMM、CK 模板和 Origami（ROCm GEMM）

在 AMD GPU 上运行的 Mixture-of-experts 模型此前无法使用 Inductor 编译的 Triton 分组 GEMM，该功能此前仅限于 NVIDIA SM90+ 硬件 —— ROCm 会退回到较慢的 hipBLASLt/rocBLAS 循环调用。此次发布将 Triton 优化引入 ROCm，包括 FP8 扩展版本，同时使 Composable Kernel GEMM 模板支持 JIT cpp_wrapper 编译，而不仅限于预编译。此外，AMD 的分析分块大小选择器 Origami 现在默认启用 ROCm max-autotune 功能，Inductor 可以通过延迟模型选择接近最优的 GEMM 配置，而无需进行完整的自动调优扫描。所有改进均为 ROCm 特有功能，仅影响 max-autotune 路径；NVIDIA 用户不会看到任何变化。

API 不稳定（PR #188600 和 #188742 由 Nichols A. Romero, AMD 提交，#185505 由 Bin Bao, Meta 提交，#186644 由 Umesh Chand, AMD 提交）

#### RDNA3 的 FlexAttention 分块配置

AMD RDNA3 GPU（Radeon 工作站和消费级显卡，不包括 MI 系列数据中心显卡）此前使用的 FlexAttention 分块大小未针对架构进行优化，导致中短序列长度的性能潜力未被充分挖掘。此次发布新增了专为 RDNA3 优化的序列长度感知分块配置，使 Inductor 能根据实际序列长度选择匹配的分块大小，而非固定默认值。结果在数百 token 级别实现了约 2-8 倍的延迟降低，且在极短序列上无性能下降。如果你在其他 AMD 或 NVIDIA 硬件上运行 FlexAttention，此更改不适用于你。

API 不稳定（PR #177840 由 Robert Esclapez, AMD 提交）

MPS（Apple Silicon）

#### 原生线性代数

MPS 线性代数此前依赖 Apple 的 MPSGraph 原语，或在超出基础功能时完全回退到 CPU，这使得混合 CPU/MPS 的往返操作成为数值代码中常见的性能瓶颈。此次发布用原生 Metal 内核替代了多个功能缺口。SVD、eigh 和 lstsq 现在通过 Jacobi 风格内核原生支持 float32 和 complex64（float64 回退到 CPU，因为 Metal 不支持双精度类型，以及小矩阵/批次中 GPU 启动开销不划算的情况）——这还启用了依赖它们的 matrix_rank、pinv、cond 和 norm 计算，但非厄米特特征值计算留待后续实现。Cholesky 采用基于 matmul2d 的尾部更新算法实现更快的面板分解（速度提升约 1.2–2.8 倍，视规模而定），并修复了 complex dtype 的正确性问题（此前无 dtype 保护，可能导致静默错误）。lu_factor 和 lu_solve 从 Apple 的 MPSMatrixDecompositionLU 迁移到手写 Metal 内核，操作级性能提升显著——提交者在小批量矩阵上测得超过 100 倍提升，在大矩阵上提升 2–9 倍。最后，新增 geqrf，将 linalg_qr 重构为与 CPU 和 CUDA 共享无设备依赖代码路径的版本，matrix_exp 和 linalg.polar（包括其反向传播）现在也支持 MPS —— 但 matrix_exp 仅在约 512×512 以上规模超越 CPU。

（PR #185954 由 Darko Simonovski 提交，#187022 和 #191836 由 Irakli Salia, Hugging Face 提交，#189192 由 Kurt Mohler, OpenTeams 提交，#187038、#189200、#188954、#189701 和 #189732 由 Irakli Salia, Hugging Face 提交）

#### FlexAttention 改进

在FlexAttention于2.13版本引入MPS后，此次发布填补了多个实际使用中暴露的空白。KV批处理广播功能使键/值张量可以在查询批处理中共享，而无需完全匹配——这是分页注意力的先决条件，后者需要此功能来通过共享的KV缓存服务多个序列。flex_attention现在可以同时返回log-sum-exp和max-score辅助输出，与主结果一起，这为任何需要使用注意力权重的场景（自定义损失、分析以及最终的MPS原生反向支持）提供了必要条件。score_mod/mask_mod函数现在可以直接捕获动态形状值（SymInts），因此基于运行时大小构建的掩码（例如与序列长度相关的截止值）不再需要每次形状变化时都重新编译。后续优化进一步将这些捕获的SymInts限制为32位整数（当值适配时），因为内核中的64位算术明显更慢。

（PR #187722、#187768、#188362和#188403、#188663，由Irakli Salia、Hugging Face贡献）

#### MPS预填充注意力加速

苹果公司新推出的macOS 26.2中的Metal Performance Primitives（MPP）为Metal内核暴露了此前不可用的、用于注意力类工作负载的底层构建模块。此次发布利用这些新特性，为MPS引入了第二个预填充注意力内核，将MLX在M5芯片上采用的方法迁移过来，并扩展至更早的苹果芯片世代，支持fp16/bf16输入且头维度为64、96、128或256且查询长度大于8（macOS 26.2+；其他形状和数据类型仍使用现有的simdgroup-matrix内核）。性能提升显著——作者的基准测试显示，与之前内核相比，在所有头维度和序列长度上速度提升约2-4倍，头维度越小、序列越长提升越明显。对于在苹果芯片上运行注意力密集型模型的用户，这是一项无需代码修改即可实现的预填充加速——MPS会在形状和数据类型符合条件时自动选择更快的内核。该内核的性能优势在苹果M5硬件上表现最佳，因为底层的每通道数据布局正是针对该硬件验证的；此前苹果芯片世代的表现未经过独立验证，可能与上述数据不一致。API不稳定（PR #182256，由Irakli Salia、Hugging Face贡献）

#### CTC损失的MPS加速

ctc_loss——无对齐序列模型（如语音识别和OCR）的损失函数——首次在MPS上实现了前向和反向传播，填补了此前迫使Mac用户回退到CPU执行该操作的空白。该实现遵循与CUDA内核相同的对数域方法，包括对可变长度（填充）批次的正确处理。在苹果芯片上端到端训练基于CTC的模型时，不再需要为损失计算切换到CPU。API不稳定（PR #187716和#188187，由Kurt Mohler、OpenTeams贡献）

XPU（Intel GPU）

#### 增强的XPU图性能

XPU图减少了图捕获和重放的开销，提升了执行效率，为基于Intel® Arc™ B系列及更新的Intel GPU的图训练和推理工作负载带来更优性能。

（PR #188874，由Jing Ma、Intel贡献）

#### scaled_mm的MXFP8和MXFP4支持

新增对MXFP8和MXFP4的支持，适用于scaled_mm，为下一代Intel GPU的软件提前做好准备，并帮助开发者为新兴的低精度计算格式的AI工作负载进行预演。API不稳定（PR #181726、#181727和#187315，Carson Wang，Intel）

#### 分布式AI工作负载的对称内存

为scale-up部署启用了XPU对称内存后端，在Intel GPU上解锁异步张量并行（Async TP），为更具扩展性的分布式AI工作负载奠定基础。

API不稳定（PR #185102，Cherry Zhang，Intel）

#### 细粒度的Intel GPU进程级内存追踪

新增torch.xpu.list_gpu_processes()，实现按进程维度对Intel GPU内存使用情况进行详细追踪和报告。

API不稳定（PR #185192，Guangye Yu，Intel）

#### 扩展的WSL2支持

新增对运行在Windows Subsystem for Linux 2（WSL2）下的Ubuntu 24.04和Ubuntu 26.04的支持，使开发者能够更便捷地从Windows环境构建和运行Intel GPU上的AI工作负载。

C++ ABI

#### 扩展的torch::stable接口

使用torch::stable中定义的API子集的C++应用可以依赖跨版本的ABI兼容性，本次发布进一步扩展了该接口范围。（C++应用如果愿意定期重建或固定libtorch版本，也可以使用libtorch.so的完整API接口）继2.13版本中引入的torch::stable::Generator之后，本次新增PyObject到torch::stable::Tensor的转换、Tensor::has_storage方法，以及bitwise_and、bitwise_or、left_shift、right_shift、permute、view_dtype、index_select、floor_divide和is_pinned的稳定重载。更多实用工具已迁移至仅头文件的torch::headeronly（包括fastAtomicAdd和isinf/isnan），扩展作者无需链接libtorch即可使用这些工具。

C++接口API不稳定，而C接口API稳定且ABI稳定。（PR #183323，Paweł Gadziński，NVIDIA；#189877、#191973和#193604，Jane Xu，Meta；#192083和#192097，Chris Leonard，Red Hat）

性能分析与调试

#### 针对固定CPU内存的内存快照

内存快照功能此前已涵盖设备内存分配，但未包含用于主机到设备传输的固定（页锁定）主机内存——因此如果这类内存出现意外增长，无法通过已有工具进行观察。固定缓冲区也容易被忽略：通常一次性分配并在进程生命周期内保持存在，因为CUDA图需要任何捕获复制操作的固定主机地址。现在将record_host=True传递给torch.cuda.memory._record_memory_history()，将同时捕获固定内存分配，作为新的host_segments和host_traces键与现有设备数据并列显示。这为追踪内存泄漏或异常增长提供了主机和设备内存的统一视图。目前memory_viz可视化工具尚未渲染主机数据，通过原始cudaHostRegister调用在PyTorch分配器之外创建的分配也无法被捕获。

API不稳定（PR #182407，Edward Yang，Meta）

废弃功能与不兼容变更

• TorchScript废弃警告现已可见，且TorchScript已从导入路径中移除。废弃的isIntegral重载已被移除。详见#189914和#187115。

• Python函数事件默认被排除在profiler.key_averages()之外，这会导致性能分析输出出现可见变化。详见#188631。

• 在性能分析器中，已弃用的 use_cuda 选项被移除，with_modules 也被弃用；模式匹配器、BasicEvaluation、profiler_metrics 和 profiler_measure_per_kernel 被移除。详见 #192543、#192808、#187362、#187439 和 #187204。

• Dynamo TVM 后端的 Relay 路径在 FutureWarning 弃用后被移除，请改用 relax 前端。详见 #189639 和 #190766。

• 在分布式模块中，_set_pg_timeout 被 torch.distributed.set_timeout 取代，setSequenceNumberForGroup 变为已弃用的无操作函数，控制集合操作的实现被移除，基于单卡编译的 torch.distributed 别名被替换为 torch.compiler.config。详见 #187387、#188611、#188617 和 #187869。

• CUDA 绿色上下文的 set 和 pop 方法已被弃用，绿色上下文功能已迁移至 CUDA Python 绑定中。详见 #188419 和 #185527。

• 使用 weights_only 加载稀疏张量时会验证一致性。详见 #184750。

• linear_cross_entropy 中的平衡准确率策略已被移除。详见 #188283。

非功能更新

组件

2.13

2.14

CUDA

12.6, 13.0, 13.2

默认 wheel

CUDA 13.0

CUDA 13.0，无变化

ROCm

7.1, 7.2

7.2, 7.14。7.1 已移除；7.14 通过 TheRock 提供

Python

3.10 到 3.15（包含 3.14t、3.15t）

无变化

C++ 标准

C++20

• 构建系统已从 setuptools 迁移到 scikit-build-core，Windows 和 macOS 的 wheel 构建已重构为 Python 管道。详见 #180247、#184407 和 #187944。

• ROCm 7.14 的 wheel 通过 TheRock pip SDK 构建，使用基于 RPATH 的库解析，manywheels 通过 auditwheel 重新打包以修复超过 4 GB 的 wheel 的无效 ZIP64，工具链从 rocm_smi 迁移到 amd_smi。详见 #190276、#189903 和 #190014。

• cuDNN 升级至 9.24 并重新启用 conv 引擎 5，oneDNN 升级至 3.12.3，XPU 支持包升级至 2026.1。详见 #189483、#188785 和 #189593。

• C++20 仍为最低标准，头文件保护机制已全面启用。详见 #178150。

• 新增 CI 和平台覆盖范围包括原生 linux-riscv64 构建镜像、B200 基准测试工作流、专用于 P2P IPC 测试的 H100 网络测试机，以及 Intel BMG 客户端冒烟测试。详见 #190887、#192659、#191280 和 #187421。

• Inductor 针对 Rubin（sm_107）优化了向量化逐元素计算内核。详见 #190654 和 #190546。

/post-content

/inner-wrap