开始使用

概述

推出 PyTorch 2.0，这是我们迈向 PyTorch 下一代 2 系列发布的第一步。在过去的几年里，我们不断创新和迭代，从 PyTorch 1.0 到最新的 1.13，并转到新成立的 PyTorch 基金会，该基金会是 Linux 基金会的一部分。

除了我们出色的社区之外，PyTorch 的最大优势在于，我们继续作为一流的 Python 集成、命令式风格、API 的简单性和选项。PyTorch 2.0 提供了相同的急切模式开发和用户体验，同时从根本上改变和增强了 PyTorch 在底层编译器级别的运行方式。我们能够提供更快的性能并支持动态形状和分布式。

在下面，您将找到所有信息，以便更好地了解 PyTorch 2.0 是什么、它将走向何方，更重要的是如何立即开始使用（例如，教程、要求、模型、常见问题解答）。还有很多东西需要学习和开发，但我们期待社区的反馈和贡献，以使 2 系列变得更好，并感谢所有使 1 系列如此成功的人。

PyTorch 2.x：更快、更 Pythonic，并且比以往任何时候都更动态

今天，我们宣布推出 torch.compile，此功能将 PyTorch 性能推向新的高度，并开始将 PyTorch 的部分内容从 C++ 移回 Python。我们相信这是 PyTorch 的一个重大新方向——因此我们称之为 2.0。 torch.compile 是一项完全附加（且可选）的功能，因此根据定义，2.0 是 100% 向后兼容的。

支撑 torch.compile 的是新技术——TorchDynamo、AOTAutograd、PrimTorch 和 TorchInductor。

• TorchDynamo 使用 Python 帧评估挂钩安全地捕获 PyTorch 程序，这是一项重大创新，是我们 5 年来对安全图形捕获进行研发的结果

• AOTAutograd 将 PyTorch 的自动微分引擎作为跟踪自动微分来生成提前的向后跟踪。

• PrimTorch 将约 2000+ 个 PyTorch 运算符规范化为约 250 个基本运算符的闭合集，开发人员可以针对这些运算符构建完整的 PyTorch 后端。这大大降低了编写 PyTorch 功能或后端的障碍。
• TorchInductor 是一款深度学习编译器，可为多个加速器和后端生成快速代码。对于 NVIDIA 和 AMD GPU，它使用 OpenAI Triton 作为关键构建模块。

TorchDynamo、AOTAutograd、PrimTorch 和 TorchInductor 使用 Python 编写，并支持动态形状（即能够发送不同大小的张量而不引起重新编译），这使它们具有灵活性、易于破解，并降低了开发人员和供应商的进入门槛。

为了验证这些技术，我们使用了一组来自各种机器学习领域的 163 个开源模型。我们仔细构建了此基准，以包括图像分类、对象检测、图像生成、各种 NLP 任务（如语言建模、问答、序列分类、推荐系统和强化学习）等任务。我们将基准分为三类

• HuggingFace Transformers 中的 46 个模型
• TIMM 中的 61 个模型：Ross Wightman 的一系列最先进的 PyTorch 图像模型
• TorchBench 中的 56 个模型：来自整个 github 的精选流行代码库

我们不会修改这些开源模型，除非添加一个 torch.compile 调用来包装它们。

然后，我们测量加速并验证这些模型的准确性。由于加速可能取决于数据类型，因此我们测量 float32 和自动混合精度 (AMP) 的加速。我们报告加权平均加速的非均匀值为0.75 * AMP + 0.25 * float32，因为我们发现 AMP 在实践中更为常见。

在这些 163 个开源模型中，torch.compile 在 93% 的时间内有效，并且该模型在 NVIDIA A100 GPU 上的训练速度提高了 43%。在 Float32 精度下，其平均运行速度提高了 21%，在 AMP 精度下，其平均运行速度提高了 51%。

注意事项：在 NVIDIA 3090 等台式机级 GPU 上，我们测量到的加速低于 A100 等服务器级 GPU。截至今日，我们的默认后端 TorchInductor 支持 CPU 以及 NVIDIA Volta 和 Ampere GPU。它（目前）不支持其他 GPU、xPU 或较旧的 NVIDIA GPU。

试用：torch.compile 处于开发的早期阶段。从今天开始，您可以在nightly 二进制文件中试用torch.compile。我们预计将在 2023 年 3 月初发布第一个稳定的 2.0 版本。

在 PyTorch 2.x 的路线图中，我们希望在性能和可扩展性方面进一步推进编译模式。正如我们在今天的会议上所讨论的，其中一些工作正在进行中。其中一些工作尚未开始。其中一些工作是我们希望看到的，但我们自己没有能力去做。如果您有兴趣做出贡献，请在本月开始在向工程师提问：2.0 现场问答系列中与我们聊天（详情见本文末尾）和/或通过 Github / 论坛。

推荐

以下是 PyTorch 的一些用户对我们新方向的看法

Sylvain Gugger，HuggingFace transformers 的主要维护者

“只需添加一行代码，PyTorch 2.0 就能在训练 Transformers 模型时将速度提高 1.5 倍到 2 倍。这是自混合精度训练推出以来最令人兴奋的事情！”

Ross Wightman，TIMM 的主要维护者（PyTorch 生态系统中最大的视觉模型中心之一）

“它可以直接开箱即用，适用于大多数 TIMM 模型，用于推理和训练工作负载，无需更改代码”

Luca Antiga，Lightning AI 的 CTO，也是PyTorch Lightning 的主要维护者之一

“PyTorch 2.0 体现了深度学习框架的未来。无需用户干预即可捕获 PyTorch 程序并获得巨大的设备加速和程序操作，这为 AI 开发人员开启了一个全新的维度。”

动机

我们对 PyTorch 的理念一直是保持灵活性与可黑客性为首要任务，其次是性能。我们努力实现

1. 高性能急切执行
2. Pythonic 内部结构
3. 分布式、自动微分、数据加载、加速器等的良好抽象

自 2017 年推出 PyTorch 以来，硬件加速器（例如 GPU）的计算速度提高了约 15 倍，内存访问速度提高了约 2 倍。因此，为了保持急切执行的高性能，我们不得不将 PyTorch 内部的大部分内容移至 C++。将内部结构移至 C++ 会降低其可黑客性，并增加代码贡献的进入门槛。

从第一天起，我们就了解到急切执行的性能限制。2017 年 7 月，我们启动了第一个研究项目，以开发 PyTorch 编译器。该编译器需要使 PyTorch 程序快速运行，但不能以牺牲 PyTorch 体验为代价。我们的关键标准是保留某些类型的灵活性——支持研究人员在探索的不同阶段使用的动态形状和动态程序。

技术概述

多年来，我们在 PyTorch 中构建了多个编译器项目。让我们将编译器分解为三个部分

• 图获取
• 图降低
• 图编译

在构建 PyTorch 编译器时，图获取是更艰巨的挑战。

在过去的 5 年中，我们构建了 torch.jit.trace、TorchScript、FX 跟踪、Lazy Tensors。但没有一个让我们觉得能提供我们想要的一切。有些灵活但速度不快，有些速度快但不灵活，有些既不快也不灵活。有些用户体验很差（比如在不知情的情况下出错）。虽然 TorchScript 很有前景，但它需要对你的代码及其依赖的代码进行重大更改。对代码进行重大更改的需求让许多 PyTorch 用户望而却步。

TorchDynamo：可靠且快速地获取图

今年早些时候，我们开始研究 TorchDynamo，这是一种使用 PEP-0523 中引入的 CPython 特性（称为帧评估 API）的方法。我们采用数据驱动的方法来验证其在图捕获中的有效性。我们使用 7000 多个用 PyTorch 编写的 Github 项目作为我们的验证集。虽然 TorchScript 和其他方法甚至难以在 50% 的时间内获取图，而且通常开销很大，但 TorchDynamo 99% 的时间 都能正确、安全地获取图，而且开销可以忽略不计——无需对原始代码进行任何更改。这时我们意识到，我们终于突破了多年来在灵活性和速度方面苦苦挣扎的障碍。

TorchInductor：使用按运行定义的 IR 进行快速代码生成

对于 PyTorch 2.0 的新编译器后端，我们从用户编写高性能自定义内核的方式中汲取灵感：越来越多地使用 Triton 语言。我们还希望一个编译器后端使用与 PyTorch eager 类似的抽象，并且通用到足以支持 PyTorch 中广泛的功能。TorchInductor 使用 Pythonic 按运行定义的循环级别 IR，将 PyTorch 模型自动映射到 GPU 上生成的 Triton 代码和 CPU 上的 C++/OpenMP。TorchInductor 的核心循环级别 IR 仅包含约 50 个运算符，并且它在 Python 中实现，使其易于破解和扩展。

AOTAutograd：将 Autograd 重新用于提前图

对于 PyTorch 2.0，我们知道我们想要加速训练。因此，至关重要的是，我们不仅要捕获用户级代码，还要捕获反向传播。此外，我们知道我们想要重新使用现有的经过实战检验的 PyTorch autograd 系统。AOTAutograd 利用 PyTorch 的 torch_dispatch 可扩展性机制来跟踪我们的 Autograd 引擎，使我们能够“提前”捕获反向传递。这使我们能够使用 TorchInductor 加速我们的正向和反向传递。

PrimTorch：稳定的基本运算符

为 PyTorch 编写后端具有挑战性。PyTorch 有 1200 多个运算符，如果您考虑每个运算符的各种重载，则有 2000 多个。

因此，编写后端或跨切特征成为一项枯燥乏味的工作。在 PrimTorch 项目中，我们致力于定义更小且稳定的运算符集。PyTorch 程序可以始终降低到这些运算符集。我们的目标是定义两个运算符集

• 具有大约 250 个运算符的 Prim 运算符，它们是相当低级别的。这些适用于编译器，因为它们足够低级，以至于您需要将它们重新融合在一起才能获得良好的性能。
• 具有大约 750 个规范运算符的 ATen 运算符，适用于按原样导出。这些适用于已经在 ATen 级别集成的后端或不会编译以从 Prim 运算符等较低级别运算符集恢复性能的后端。

我们在下面的开发人员/供应商体验部分中对此主题进行了更多讨论

用户体验

我们引入了一个简单的函数 torch.compile，它包装您的模型并返回一个已编译的模型。

compiled_model = torch.compile(model)

此 compiled_model 持有对您模型的引用，并将 forward 函数编译为更优化的版本。在编译模型时，我们提供了一些旋钮来调整它

def torch.compile(model: Callable,
  *,
  mode: Optional[str] = "default",
  dynamic: bool = False,
  fullgraph:bool = False,
  backend: Union[str, Callable] = "inductor",
  # advanced backend options go here as kwargs
  **kwargs
) -> torch._dynamo.NNOptimizedModule

• mode 指定编译器在编译时应优化什么。

  • 默认模式是一个预设，它尝试在不花费太多时间编译或使用额外内存的情况下高效地编译。
  • 其他模式（例如 reduce-overhead）会大大减少框架开销，但会消耗少量额外内存。 max-autotune 编译时间较长，试图生成最快的代码。
• dynamic 指定是否启用动态形状的代码路径。某些编译器优化无法应用于动态形状的程序。明确指定您想要动态形状或静态形状的编译程序将帮助编译器为您提供经过更好优化的代码。
• fullgraph 类似于 Numba 的 nopython。它将整个程序编译成一个单一图，或者给出无法这样做的原因说明。大多数用户不需要使用此模式。如果您非常注重性能，那么您可以尝试使用它。
• backend 指定要使用的编译器后端。默认情况下，使用 TorchInductor，但还有其他一些可用的后端。

编译体验旨在以默认模式提供最大的好处和最大的灵活性。以下是您在每种模式下获得的内容的心理模型。

现在，让我们看一个编译真实模型并运行它的完整示例（使用随机数据）

import torch
import torchvision.models as models

model = models.resnet18().cuda()
optimizer = torch.optim.SGD(model.parameters(), lr=0.01)
compiled_model = torch.compile(model)

x = torch.randn(16, 3, 224, 224).cuda()
optimizer.zero_grad()
out = compiled_model(x)
out.sum().backward()
optimizer.step()

您第一次运行 compiled_model(x) 时，它会编译模型。因此，运行时间较长。后续运行速度很快。

模式

编译器有一些预设，它们以不同的方式调整编译后的模型。您可能正在运行一个小型模型，由于框架开销而速度较慢。或者，您可能正在运行一个大型模型，几乎无法放入内存中。根据您的需要，您可能需要使用不同的模式。

# API NOT FINAL
# default: optimizes for large models, low compile-time
#          and no extra memory usage
torch.compile(model)

# reduce-overhead: optimizes to reduce the framework overhead
#                and uses some extra memory. Helps speed up small models
torch.compile(model, mode="reduce-overhead")

# max-autotune: optimizes to produce the fastest model,
#               but takes a very long time to compile
torch.compile(model, mode="max-autotune")

读取和更新属性

访问模型属性的工作方式与在急切模式下相同。您可以访问或修改模型的属性（例如 model.conv1.weight），就像您通常所做的那样。在代码校正方面，这是完全安全可靠的。TorchDynamo 在代码中插入保护措施，以检查其假设是否成立。如果属性以某种方式更改，那么 TorchDynamo 会知道根据需要自动重新编译。

# optimized_model works similar to model, feel free to access its attributes and modify them
optimized_model.conv1.weight.fill_(0.01)

# this change is reflected in model

挂钩

模块和张量 挂钩 目前无法完全工作，但随着我们完成开发，它们最终将发挥作用。

序列化

您可以序列化 optimized_model 或 model 的状态字典。它们指向相同参数和状态，因此是等效的。

torch.save(optimized_model.state_dict(), "foo.pt")
# both these lines of code do the same thing
torch.save(model.state_dict(), "foo.pt")

目前无法序列化 optimized_model。如果您希望直接保存对象，请改而保存 model。

torch.save(optimized_model, "foo.pt") # Error
torch.save(model, "foo.pt")           # Works

推理和导出

对于模型推理，在使用 torch.compile 生成编译模型后，在实际模型服务之前运行一些预热步骤。这有助于减轻初始服务期间的延迟峰值。

此外，我们将引入一种称为 torch.export 的模式，它会仔细导出整个模型和保护基础设施，以满足需要保证和可预测延迟的环境。 torch.export 需要对您的程序进行更改，特别是如果您有数据相关控制流的情况下。

# API Not Final
exported_model = torch._dynamo.export(model, input)
torch.save(exported_model, "foo.pt")

这处于开发的早期阶段。请关注 PyTorch 大会上的导出路径演讲以了解更多详情。您还可以在本月开始的“工程师问答：2.0 现场问答系列”中参与此主题的讨论（更多详情见本文末尾）。

调试问题

编译模式是不透明的，很难调试。您会有如下问题

• 为什么我的程序在编译模式下崩溃？
• 编译模式是否与急切模式一样准确？
• 为什么我没有看到加速？

如果编译模式产生错误或崩溃，或与急切模式产生不同的结果（超出机器精度限制），则不太可能是您的代码的错。但是，了解哪一部分代码导致了错误是有用的。

为了帮助调试和重现，我们创建了几个工具和日志记录功能，其中一个脱颖而出：Minifier。

Minifier 会自动将您看到的错误缩小为一小段代码。这小段代码会重现原始错误，您可以使用缩小的代码提交 github 问题。这将帮助 PyTorch 团队轻松快速地修复问题。

如果您没有看到预期的加速，那么我们有 torch._dynamo.explain 工具，它可以解释哪些部分的代码导致了我们所谓的“图中断”。图中断通常会阻碍编译器加速代码，而减少图中断的数量可能会加速您的代码（直到收益递减的某个限制）。

您可以在我们的 故障排除指南 中阅读有关这些内容的更多信息。

动态形状

在研究支持 PyTorch 代码通用性时，一个关键要求是支持动态形状，并允许模型采用不同大小的张量，而无需在形状发生变化时每次都进行重新编译。

截至今日，对动态形状的支持有限，并且正在快速开发中。它将在稳定版本中实现全部功能。它被 dynamic=True 参数隐藏，我们在一个功能分支（符号形状）上取得了更多进展，我们已成功使用 TorchInductor 在训练中以完整的符号形状运行 BERT_pytorch。对于具有动态形状的推理，我们有更多覆盖范围。例如，让我们看看动态形状有用的常见设置 - 使用语言模型进行文本生成。

我们可以看到，即使形状从 4 动态变化到 256，编译模式也能够始终比 eager 模式高出 40%。如果不支持动态形状，常见的解决方法是填充到最接近的 2 的幂。但是，从下图中可以看到，它会产生大量的性能开销，并且还会导致编译时间明显延长。此外，填充有时难以正确完成。

通过在 PyTorch 2.0 的编译模式中支持动态形状，我们可以获得最佳的性能和易用性。

当前的工作正在快速发展，在我们对基础设施进行根本性改进时，我们可能会暂时让一些模型回归。有关我们在动态形状方面取得进展的最新更新，请参阅此处。

分布式

总之，torch.distributed 的两个主要分布式包装器在编译模式下运行良好。

DistributedDataParallel (DDP) 和 FullyShardedDataParallel (FSDP) 都在编译模式下工作，并提供比 eager 模式更好的性能和内存利用率，但有一些注意事项和限制。

DistributedDataParallel (DDP)

DDP 依赖于将重叠的 AllReduce 通信与反向计算结合起来，并将较小的逐层 AllReduce 操作分组到“桶”中以提高效率。与 DDP 结合使用时，TorchDynamo 编译的 AOTAutograd 函数会阻止通信重叠，但通过为每个“桶”编译单独的子图并允许通信操作在子图外部和子图之间发生，可以恢复性能。编译模式下的 DDP 支持目前还需要 static_graph=False。有关 DDP + TorchDynamo 的方法和结果的更多详细信息，请参阅 此帖子。

FullyShardedDataParallel (FSDP)

FSDP 本身是 PyTorch 的“beta”功能，由于可以调整要包装的子模块，并且通常有更多的配置选项，因此其系统复杂性高于 DDP。如果使用 use_original_params=True 标志进行配置，FSDP 可与 TorchDynamo 和 TorchInductor 配合使用，适用于各种流行模型。目前预计会遇到特定模型或配置的一些兼容性问题，但会积极改进，如果提交了 github 问题，则可以优先考虑特定模型。

用户指定 auto_wrap_policy 参数，以指示其模型的哪些子模块应一起包装在用于状态分片的 FSDP 实例中，或手动将子模块包装在 FSDP 实例中。例如，当每个“transformer 块”都包装在单独的 FSDP 实例中时，许多 transformer 模型都能很好地工作，因此一次只需要实现一个 transformer 块的完整状态。Dynamo 将在每个 FSDP 实例的边界处插入图中断，以允许正向（和反向）中的通信操作在图外部和与计算并行发生。

如果在不将子模块包装在单独的实例中使用 FSDP，则它会退回到与 DDP 类似的操作，但没有分桶。因此，所有梯度都在一个操作中减少，即使在 Eager 中也不能有计算/通信重叠。此配置仅针对 TorchDynamo 进行了功能性测试，但未针对性能进行测试。

开发人员/供应商体验

使用 PyTorch 2.0，我们希望简化后端（编译器）集成体验。为此，我们专注于减少运算符的数量和简化运算符集的语义，这是启动 PyTorch 后端所必需的。

以图形形式，PT2 堆栈如下所示

从图表的中间开始，AOTAutograd 以超前的方式动态捕获自动梯度逻辑，生成 FX 图表格式的正向和反向运算符图。

我们提供了一组强化分解（即以其他运算符为基础编写的运算符实现），可以利用它们来减少后端需要实现的运算符数量。我们还通过一个称为功能化的过程，有选择地重写复杂的 PyTorch 逻辑（包括变异和视图），从而简化 PyTorch 运算符的语义，并保证运算符元数据信息，如形状传播公式。这项工作正在积极进行中；我们的目标是提供一组具有简化语义的原始且稳定的约 250 个运算符，称为PrimTorch，供应商可以利用（即选择加入）它来简化其集成。
在减少和简化运算符集之后，后端可以选择在 Dynamo（即中间层，紧接在 AOTAutograd 之后）或 Inductor（下层）集成。我们将在下面描述做出此选择的某些注意事项，以及围绕后端混合的未来工作。

Dynamo 后端

具有现有编译器堆栈的供应商可能会发现最容易以 TorchDynamo 后端集成，接收一个以 ATen/Prims IR 为基础的 FX 图。请注意，对于训练和推理，集成点将紧接在 AOTAutograd 之后，因为我们目前将分解作为 AOTAutograd 的一部分应用，并且如果针对推理，仅仅跳过特定于反向的步骤。

Inductor 后端

供应商还可以直接将他们的后端集成到 Inductor 中。Inductor 接收由 AOTAutograd 生成的由 ATen/Prim 操作组成的图，并进一步将其降低到循环级别 IR。如今，Inductor 为其循环级别 IR 提供了逐点、归约、分散/收集和窗口操作的降低。此外，Inductor 创建融合组，执行索引简化、维度折叠，并调整循环迭代顺序以支持高效的代码生成。然后，供应商可以通过提供从循环级别 IR 到特定于硬件的代码的映射来进行集成。目前，Inductor 有两个后端：（1）生成多线程 CPU 代码的 C++，（2）生成高性能 GPU 代码的 Triton。这些 Inductor 后端可以用作备用后端的灵感来源。

后端接口混合（即将推出）

我们已经构建了用于将 FX 图形划分为子图的实用程序，这些子图包含后端支持的操作符，并急切执行其余部分。这些实用程序可以扩展为支持“混合后端”，配置为哪些后端运行图形的哪些部分。但是，后端还没有一个稳定的接口或契约来公开其操作符支持、对操作符模式的偏好等。这仍然是一项正在进行的工作，我们欢迎早期采用者的反馈。

最后的想法

我们对 PyTorch 2.0 及以后的发展方向感到非常兴奋。最终 2.0 版本的道路将是坎坷的，但请尽早加入我们的旅程。如果您有兴趣深入研究或为编译器做出贡献，请继续阅读以下内容，其中包括有关如何开始（例如教程、基准、模型、常见问题解答）以及本月开始的工程师问答：2.0 现场问答系列的更多信息。其他资源包括

• 开始使用
• 教程
• 文档
• 开发者讨论

使用 PyTorch 2.0 加速 Hugging Face 和 TIMM 模型

作者：Mark Saroufim

torch.compile() 可以轻松尝试不同的编译器后端，通过单行装饰器 torch.compile() 使 PyTorch 代码运行得更快。它可以直接在 nn.Module 上作为 torch.jit.script() 的替代方案使用，而无需您进行任何源代码更改。我们希望这一行代码更改能够为绝大多数您已经在运行的模型提供 30%-2 倍的训练时间加速。

opt_module = torch.compile(module)

torch.compile 支持任意 PyTorch 代码、控制流、变异，并附带对动态形状的实验性支持。我们对这一发展感到非常兴奋，我们称之为 PyTorch 2.0。

对我们而言，此公告与众不同之处在于，我们已经对一些最流行的开源 PyTorch 模型进行了基准测试，并获得了从 30% 到 2 倍不等的显着加速 https://github.com/pytorch/torchdynamo/issues/681。

这里没有技巧，我们已经通过 pip 安装了流行的库，如 https://github.com/huggingface/transformers、https://github.com/huggingface/accelerate 和 https://github.com/rwightman/pytorch-image-models，然后在它们上面运行 torch.compile()，就是这样。

很少能同时获得性能和便利性，但这就是核心团队认为 PyTorch 2.0 如此令人兴奋的原因。

要求

对于 GPU（新一代 GPU 将大幅提升性能）

pip3 install numpy --pre torch --force-reinstall --index-url https://download.pytorch.org/whl/nightly/cu117

对于 CPU

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

可选：验证安装

git clone https://github.com/pytorch/pytorch
cd tools/dynamo
python verify_dynamo.py

可选：Docker 安装

我们还在 PyTorch nightly 二进制文件中提供了所有必需的依赖项，你可以通过以下方式下载：

docker pull ghcr.io/pytorch/pytorch-nightly

对于临时实验，只需确保你的容器可以访问所有 GPU

docker run --gpus all -it ghcr.io/pytorch/pytorch-nightly:latest /bin/bash

开始使用

请阅读 Mark Saroufim 的完整博文，他在其中为你提供教程和真实模型，让你今天就能试用 PyTorch 2.0。

我们对 PyTorch 的目标是构建一个广度优先编译器，它可以加速人们在开源中运行的大多数实际模型。Hugging Face Hub 最终成为我们非常有价值的基准测试工具，确保我们进行的任何优化实际上都有助于加速人们想要运行的模型。

该博文教程将准确展示如何复制这些加速，让你像我们一样对 PyTorch 2.0 感到兴奋。所以请试用 PyTorch 2.0，享受免费性能，如果你没有看到，请打开一个问题，我们将确保你的模型得到支持 https://github.com/pytorch/torchdynamo/issues

毕竟，除非你的模型实际运行得更快，否则我们不能声称我们创建了一个广度优先。

常见问题解答

1. 什么是 PT 2.0？
   2.0 是最新的 PyTorch 版本。PyTorch 2.0 提供了相同的急切模式开发体验，同时通过 torch.compile 添加了编译模式。此编译模式有可能在训练和推理期间加速你的模型。

2. 为什么是 2.0 而不是 1.14？
   PyTorch 2.0 就是 1.14 的样子。我们发布了我们认为会改变你使用 PyTorch 的方式的重要新功能，因此我们称之为 2.0。

3. 如何安装 2.0？有任何其他要求吗？

   安装最新的 nightly 版本

   CUDA 11.8
   

    pip3 install numpy --pre torch torchvision torchaudio --force-reinstall --index-url https://download.pytorch.org/whl/nightly/cu118
   

   CUDA 11.7

    pip3 install numpy --pre torch torchvision torchaudio --force-reinstall --index-url https://download.pytorch.org/whl/nightly/cu117
   

   CPU

    pip3 install numpy --pre torch torchvision torchaudio --force-reinstall --index-url https://download.pytorch.org/whl/nightly/cpu
   

4. 2.0 代码是否向后兼容 1.X？
   是的，使用 2.0 无需修改你的 PyTorch 工作流。一行代码 model = torch.compile(model) 可以优化你的模型以使用 2.0 栈，并与你的其他 PyTorch 代码平滑运行。这完全是可选择的，你无需使用新的编译器。

5. 2.0 默认启用吗？
   2.0 是发布的名称。torch.compile 是在 2.0 中发布的功能，你需要明确使用 torch.compile。

6. 如何将我的 PT1.X 代码迁移到 PT2.0？
   你的代码应该按原样工作，无需任何迁移。如果你想使用 2.0 中引入的新编译模式功能，那么你可以通过一行代码优化你的模型来开始：model = torch.compile(model)。
   虽然提速主要在训练期间观察到，但如果你的模型运行得比 eager 模式快，你也可以将其用于推理。

    import torch
         
    def train(model, dataloader):
      model = torch.compile(model)
      for batch in dataloader:
        run_epoch(model, batch)
   
    def infer(model, input):
      model = torch.compile(model)
      return model(\*\*input)
   

7. 为什么我应该使用 PT2.0 而不是 PT 1.X？
   参见问题 (2) 的答案。

8. 在运行 PyTorch 2.0 时，我的代码有什么不同之处？
   开箱即用，PyTorch 2.0 与 PyTorch 1.x 相同，你的模型以 eager 模式运行，即每一行 Python 代码都一个接一个地执行。
   在 2.0 中，如果你将模型包装在 model = torch.compile(model) 中，你的模型在执行前会经历 3 个步骤
   1. 图获取：首先，模型被重写为子图块。TorchDynamo 可以编译的子图被“扁平化”，而其他子图（可能包含控制流代码或其他不受支持的 Python 构造）将回退到 Eager 模式。
   2. 图降低：所有 PyTorch 操作都被分解为特定于所选后端的组成内核。
   3. 图编译，其中内核调用它们相应的面向特定设备的底层操作。
9. PT2.0 向 PT 添加了哪些新组件？
   • TorchDynamo 从 Python 字节码生成 FX 图。它使用 保护 来维护 eager 模式功能，以确保生成的图是有效的（阅读更多）
   • AOTAutograd 生成与 TorchDynamo 捕获的前向图相对应的后向图（阅读更多）。
   • PrimTorch 将复杂的 PyTorch 操作分解为更简单、更基本的运算 (了解更多).
   • [后端] 后端与 TorchDynamo 集成，将图编译成可以在加速器上运行的 IR。例如，TorchInductor 将图编译成 Triton 以进行 GPU 执行，或编译成 OpenMP 以进行 CPU 执行 (了解更多).

10. 2.0 当前支持哪些编译器后端？
    默认且最完整的后端是 TorchInductor，但 TorchDynamo 有一个不断增长的后端列表，可以通过调用 torchdynamo.list_backends() 来找到。

11. 分布式训练如何与 2.0 配合使用？
    编译模式下的 DDP 和 FSDP 在 FP32 中比 Eager 模式快 15%，在 AMP 精度下快 80%。PT2.0 进行了额外的优化，以确保 DDP 的通信计算重叠与 Dynamo 的部分图创建正常工作。确保使用 static_graph=False 运行 DDP。更多详细信息 在此。

12. 如何了解更多有关 PT2.0 开发的信息？
    PyTorch 开发者论坛 是直接从构建它们的开发人员那里了解 2.0 组件的最佳场所。

13. 我的代码在 2.0 的编译模式下运行得更慢了！
    性能下降最可能的原因是图中断太多。例如，模型前向中的 print 语句之类的无害内容会触发图中断。我们有诊断这些问题的方法 - 了解更多 在此。

14. 我之前运行的代码在 2.0 的编译模式下崩溃了！如何调试它？
    以下是一些用于分类代码可能失败的位置和打印有用日志的技术：https://pytorch.ac.cn/docs/stable/torch.compiler_faq.html#why-is-my-code-crashing。

向工程师提问：2.0 直播问答系列

我们将为社区举办一系列直播问答，以便与专家进行更深入的提问和对话。请查看全年主题的完整日历。如果您无法参加：1) 它们将被录制以供将来观看，2) 您可以在每周五上午 10 点太平洋标准时间参加我们的 Dev Infra 办公时间 @ https://github.com/pytorch/pytorch/wiki/Dev-Infra-Office-Hours。

请点击此处查看日期、时间、说明和链接。

免责声明：加入现场会议和提交问题时，请勿分享您的个人信息、姓氏和公司。

观看 PyTorch 大会上的演讲

• TorchDynamo
• TorchInductor
• 动态形状
• 导出路径