PyTorch 2.13 将 FlexAttention 带到 Apple Silicon，借助 nn.LinearCrossEntropyLoss 将大词汇量模型的峰值内存降低高达 4 倍，并更新了分布式训练、编译、性能分析和设备端推理。

我们的直播问答环节探讨了 CUDA 版本支持、TorchInductor 中的 CuTeDSL、Python 3.15、ExecuTorch、torch.compile 以及 PyTorch 2.14 的计划。

Andrey Talman (@Meta)、@albanDesmaison (@Meta) 和 Piotr Bialecki (@NVIDIA) 与主持人 Chris Gottbrath（Gottbrath Technologies）共同参与了本次问答。

这段视频解释了 FlexAttention 如何针对请求的掩码模式编译专门的 kernel，从而跳过不必要的计算。它还涵盖了在测试的稀疏配置中，与 SDPA 相比最高约 12 倍的加速，以及 CUDA 上的确定性反向路径——这消除了梯度计算中的一个非确定性来源。

发布博客将这两项更新都标记为 API 不稳定状态。

观看完整的 PyTorch 2.13 发布直播问答：https://youtube.com/live/vbdduGRTQC0?si=cS1V85A7dFUz6DuR…

@PyTorch: PyTorch 2.13 将 FlexAttention 带到 Apple Silicon，借助 nn.Li… 将大词汇量模型的峰值内存降低高达 4 倍，并更新了分布式训练、编译、性能分析和设备端推理。

频道： @PyTorch 来源：https://www.youtube.com/live/vbdduGRTQC0?si=cS1V85A7dFUz6DuR

文字记录

大家好。嗯,欢迎参加我们的直播 呃 PyTorch 团队问答,关于 PyTorch 2.13 版本发布。嗯,本次 会议呢,我们真的会聚焦于 我们三位专家的输入,Albin、Andre 和 Poder。嗯,我们会先做一个 关键更新的简短概述, 由我来介绍,然后我们会 进入问答环节。嗯,当我们 在开头做介绍的时候,请 随时在聊天功能中提出你们的问题, 无论是通过 YouTube 还是 你们加入这个网络研讨会的任何渠道。嗯,这些问题 将真正推动问答环节。 所以,嗯,请把问题发进来,我们会整理 并排队,然后尽可能多地回答。好的。 我是 Chris Gabrath。嗯,今天很荣幸 担任主持人。嗯,我参与 PyTorch 呃已经超过八年了,担任产品和市场 方面的职务,大部分时间我在 NVIDIA 和 Meta。嗯,但现在你会看到我名字下面写着 God breath tech。 我很享受作为自由职业者和普通社区贡献者的状态。 嗯,我喜欢 PyTorch 社区的这一点, 我们可以这样做。 嗯,今天的专家是 Andre Talman、Alvin Desmeasian 和 Pod Bali。 嗯,他们会回答你的问题。 我会逐一介绍他们,也许让他们挥挥手之类的。 呃 Andre 是 Meta 的软件工程师, 主要关注 PyTorch 及其生态系统库的开源发布。 所以他为这次版本的整合做了大量工作。谢谢你,Andre。 呃 Alvin Desmasian 是 Meta 的研究工程师, 他是 PyTorch 的核心维护者负责人。 所以他肩膀上有很多担子。 呃 Pod BKI 是 NVIDIA 的工程总监, 领导 NVIDIA 的 PyTorch 团队, 同时也是 PyTorch 核心维护者。 我们很多人都记得,Poder 是几年前 社区奖项中的超级英雄之一。他是 首届 PyTorch 超级英雄,因为他对社区 做出了惊人的贡献,无论何时何地都回答各种问题, 无论问题多么简单或复杂,这太棒了。 谢谢你,Poder。 嗯,好的,在幕后,所以他们没法挥手, 我们有 Basil 和 Jennifer,他们都是 Linux 基金会的工作人员,支持 PyTorch 基金会。 感谢 Jennifer 和 Basil 让这次网络研讨会得以举办。 我会简短概述一下这个版本。嗯, 在我概述的同时,请随时把问题 发到 LinkedIn 和 YouTube。我们会整理好, 供专家回答。呃,也欢迎查看 PyTorch 发布博客。那里有很多相同的信息。 我在这里做了转述,用我自己的话来说, 但很多信息也都在博客中呈现,如果你想跟着看的话。 呃,我们还根据社区讨论准备了一些种子问题, 只是为了确保这次网络研讨会没有冷场。 嗯,你当然可以加入这些讨论, 在 discuss.pytorch.org 和 devdiscuss.pytorch.org 上, 呃,如果你深度使用 PyTorch,还可以加入 PyTorch Slack。 这能让我们的交流保持顺畅, 但如果有很多问题通过 LinkedIn 和 YouTube 频道进来,那会更有趣。 所以请把问题发到那里。如果没有, 我们就会使用种子问题。 好的。关于 PyTorch 2.13 的概述。 呃 2.13 建立在我们在过去 2.x 系列 12 个版本中所做的工作之上。 我们一直在提升对 AI 开发者重要的 一系列平台的性能,减少内存消耗 和其他类型的开销,简化开发者处理 大规模训练任务的方式,这是很多关注点所在, 同时也在改进模型如何部署到 笔记本电脑、手机、嵌入式和可穿戴设备上。 所以,我们基本上是在把 PyTorch 扩展到 许多不同的方向,跨越许多不同的平台, 我认为这是很棒的一点。 这里有几个具体亮点,我会提一下, 你在发布博客中也会看到, 而且你可能会在这里提问。 其中之一是 Flex Attention 现在可用于 Apple Silicon。 呃,这能提升高达 12 倍的性能, 这真是一个令人惊叹的数字。所以我们很愿意指出这一点。 在 GPU 上的原始性能方面,我们集成了 NVIDIA 的 Cute DSL 作为 Inductor 后端。 呃,这为 gen gym 内核带来了 Cutlass 级别的性能。 对于那些对大型词汇表模型感兴趣的人, 我们添加了融合的线性交叉熵损失, 可以将峰值内存需求降低多达四倍。 这是在效率方面。 呃,在分布式方面, 我们有了一个新的 torch.comms collective communications 后端。 我们讨论这个已经有一段时间了。 工程师们已经研究了,我想大概快一年了。 嗯,但现在它被包含在默认包中, 作为通信后端。 嗯,它提高了大规模集群上 集合操作的容错性和可调试性。 FSDP 在分布式领域也实现了 all-gather 和 reduce-scatter 之间的通信重叠, 以获得更高的训练吞吐量。 如果你对本地工作站和超低功耗嵌入式 或可穿戴 AI 感兴趣,我们有一个相当成熟的 ExecuTorch 运行时,我们已经讨论和改进 很长时间了。它现在已正式集成到 PyTorch 核心中,并且将在相当长的时间内 得到维护和支持。 呃 PyTorch,抱歉,Python 3.15 即将发布。 我想很多人对此感兴趣,我们有点领先, 在 nightly 通道中提供了 PyTorch wheel, 供那些已经在测试和构建的人使用。 如果你对自由线程无 GIL 的工作感兴趣, 我们也有一个更新的 3.15T 构建与之兼容。 此外,ARM V9、Rockom 和 Intel 也有 一些改进。嗯,如果你对这些细节感兴趣, 请提问,或者查看博客和发布说明以了解更多信息, 这些平台上已经纳入的内容。 然后我们还有几个面向未来的 PSAs, 我们希望大家知道。 呃,对于即将发布的 2.14 版本, 我们将进一步收紧发布时间线。 这给了你更多时间来提交 PR, 如果你在为 PyTorch 做贡献,这是好消息。 呃,发布日期不会改变,仍然是 9 月 2 日, 但我们会把分支切割日期从 8 月 3 日 推迟一周到 8 月 10 日。所以我认为这意味着 分支活跃时间从四周缩短到三周, 这真的很酷,很了不起,Andre 和团队 的执行力足够强,才能做到这一点。 另一个人们可能会注意到的变化 [清嗓子] 不属于 2.13,但我们想确保你知道, 它会在 2.14 中出现, 呃,就是今天落地的变化,本周会出现在 nightly 中, 从 setup.py 迁移到 scikit-build 工具链, 你之前会用 setup.py 来设置环境。 所以我们基本上是在使用更符合行业标准的工具。 但这对于开发者的工作流程来说确实是一个小变化, 所以请注意这一点。 另外,在 2.14 中,针对 PyTorch 头文件进行构建 将要求编译器最低支持 C++20。 更旧的标准会在构建时出现硬错误。 这个变化会引入 nightly 构建, 哦,实际上上周已经引入了 nightly 构建。 所以这些都是 PSA,如果你在为 PyTorch 工作, 你可能应该知道这些。显然, 如果你想深入了解其中任何一点,可以提问。 我们显然有专家在这里解释任何方面。 好的。这就是概述。舞台已经搭好, 让我们进入一些问题。我们有用户问题吗? 我目前还没看到。所以让我们先来一个种子问题。 这个问题是:PyTorch 2.13 支持哪些 CUDA 版本? 是的。好的。所以问题是:PyTorch 2.13 支持哪些 CUDA 版本, 与 2.12 相比有什么变化? 我认为这是个好问题。让 Pota 先来回答, 然后也许 Andre 补充。

好的。对于 PyTorch 2.13 版本,默认没有变化。 所以我们仍然为 PyTorch 2.13 发布三个 CUDA 堆栈版本。 默认版本仍然是 CUDA 13.0。所以在 Linux x86 和 ARM 上, 也就是 Linux SPSA 上,你只需要运行 pip install torch, 它会拉取带 CUDA 13 依赖的 2.13 到你的系统。 对于需要或仍在 Volan Pascal 架构上运行的旧用户, 即 SM 60 和 70,他们需要使用 CUDA 12.6 构建。 你可以去 Get Started 页面,然后像往常一样 使用特定的 URL 来获取命令,选择对应的 CUDA 版本。 然后我们标记为实验性 CUDA 版本的是 13.2, 和往常一样保持不变。所以如果你想 在新硬件上运行,例如 Blackwell GPU, 我们鼓励你使用 13.2 构建, 这当然也在支持矩阵中显示, 或者通过安装命令看到。但我想强调的仍然是, 默认体验没有变化,pip install torch 的默认体验在这个版本中仍然会拉取 13.0。 是的,我可以再补充一点。关于 CUDA 12.6, 它目前被视为遗留版本,我们计划在未来的版本中弃用, 可能不是 2.14,但也许是 2.15, 而且已经有一个关于 12.6 弃用的 RFC issue 开放了。 这是第一点。我们目前也在努力将 CUDA 13.2 变为稳定版本。所以我们正在为 13.2 添加所有的 CI 工作流。所以它也被覆盖了, 它将成为稳定版本之一,也有一个 RFC。 就是这样。 好的,谢谢。下一个问题。 好的,下一个问题。 好的。那么这个问题,谢谢大家提出这个问题。 嗯,Triton 支持 PyTorch 在不同架构上运行。 CQile 只支持 NVIDIA GPU。 用 Cute DSL 编写的内核代码 在 NVIDIA GPU 上是否会比用 Triton 编写的代码 获得更高的性能?Pod,你想先回答吗? 好。我会说这取决于具体情况。不幸的是,一如既往, 没有一个明确的答案说它总是能带来更好的性能 或者永远不会。对于这个版本,我认为, 因为我们讨论的是 2.13,之前 Chris 提到了, Inductor 中加入了实验性的 QTS 后端。 所以我目前鼓励大家直接选择这个功能。 你可以指定允许 PyTorch Inductor 在整个自动调优后端中 使用 QTS 作为后端之一。对吗? 如果它给你带来好处,它会选择它。 话虽如此,我们目前看到了不错的结果, 对 QTSA 的体验也很好。 这并不意味着 QTSL 在取代后端中的任何东西。 它现在只是一个额外的 DSL,可以给你加速, 尤其是在当前阶段。它可能会被选择用于特定的元调用。 我相信它也被用于特定的 RMS norm 实现。 所以它已经被使用并且有用了, 但我不会笼统地说它一定会给你带来 比当前默认方案更好的体验。 还有其他人想补充吗? 我认为这是一个很好的时刻,可以认识到 Inductor 的理念,即在一系列不同的编译器技术之间 进行自动调优,这是这个架构的优势之一。 这让我们不必非要选出一个赢家。 我们可以不必在所有情况下都选择一个赢家。 我们可以让 Inductor 后端工具 根据你的代码实际在做什么,在逐调用的基础上选择赢家, 我认为这非常酷。 嗯,好的,让我们进入下一个问题。 好的。下一个问题也是来自社区, 来自这里的与会者。嗯,我会随机点名。 好吧,希望我没有念得太烂。 嗯,你好,你们未来会支持导出到 Stable HLO 和 MLIR 格式吗? 你们有计划将 JAX 组件集成到 PyTorch 代码结构中吗? 这似乎是问 Alvin 的好问题,因为他是核心维护者负责人。 而且我知道他也深入参与了一些与 Google 的集成工作。 所以我认为他可能是回答这个问题的最佳人选。 嗯,是的,我认为,如果你稍微关注一下正在发生的事情, 你会看到这里有很多动态的部分, 而且你提到的其实是很多非常不同的组件。 嗯,关于 Stable HLO 和 MLIR 路径, 特别是如果你指的是通过 torch.export 导出, 是的,有些项目如 torch-mlir 和其他社区项目 非常具体地关注这个用例。 嗯,还有,我相信你也看到了, Google 正在开发 torch-TPU, 这显然也会与这些组件紧密相关, 还有其他后端也在讨论使用 Stable HLO 或 MLIR, 并且在我们生态系统中出现。 所以是的,有很多动态的部分。 嗯,我不认为 PyTorch 核心团队想要告诉后端供应商 是否以及如何使用这些组件, 因为他们才是这些组件的专家。 所以我们支持他们进行这种集成, 主要是从核心外部进行支持, 并确保所有这些组件都能被尽可能好地使用, 这样最终用户就能在他们需要运行的硬件上运行。 嗯,关于 JAX 组件部分, 我不知道你是怎么把这两者联系起来的。 我认为取决于你指的是哪个 JAX 组件。 如果你稍微看一下,你会发现我们现在 对 JAX 有一些可选依赖,主要是因为 为了编写自定义内核,我们之前讨论过 DSL, TPU DSL 基于 Pallas,而 Pallas 在 JAX 中。 所以我们确实使用了 JAX 的一部分, 专门用于为 TPU 编写自定义内核。 嗯,我认为除此之外,我们没有太多 在 JAX 更高级 API 方面的探索。 嗯,但显然 XLA 将是 torch-TPU 讨论中的一个主要组件。 所以请保持关注。 呃,我要为 PyTorch 北美会议打个广告, 那将在两三个月后,也就是 10 月举行, 届时你会听到更多关于 TP 的内容。 太棒了。还有其他人想补充吗? 好的。那么让我们进入下一个问题。 好的。Aman Kar。 你好,你们用 PyTorch 做出了很棒的工作, 多年来一直激励着我。嗯,一个人如何成为 PyTorch 贡献者, 成为 PyTorch 贡献者社区的一员?让我们…