网站会员系统wordpress,研究院网站建设方案,手机端视频网站模板,回收手表的网站动动发财的小手#xff0c;点个赞吧#xff01; 训练深度学习模型#xff0c;尤其是大型模型#xff0c;可能是一项昂贵的支出。我们可以使用的管理这些成本的主要方法之一是性能优化。性能优化是一个迭代过程#xff0c;我们不断寻找提高应用程序性能的机会#xff0c;然… 动动发财的小手点个赞吧 训练深度学习模型尤其是大型模型可能是一项昂贵的支出。我们可以使用的管理这些成本的主要方法之一是性能优化。性能优化是一个迭代过程我们不断寻找提高应用程序性能的机会然后利用这些机会。在之前的文章中例如此处我们强调了拥有适当工具来进行此分析的重要性。工具的选择可能取决于许多因素包括训练加速器的类型例如 GPU、HPU 或其他和训练框架。 本文[1]的重点是在 GPU 上使用 PyTorch 进行训练。更具体地说我们将重点关注 PyTorch 的内置性能分析器 PyTorch Profiler以及查看其结果的方法之一PyTorch Profiler TensorBoard 插件。 这篇文章并不是要取代有关 PyTorch Profiler 的官方 PyTorch 文档或使用 TensorBoard 插件来分析分析器结果。我们的目的是展示如何在日常开发过程中使用这些工具。 一段时间以来我对 TensorBoard 插件教程的一个部分特别感兴趣。本教程介绍了一个在流行的 Cifar10 数据集上训练的分类模型基于 Resnet 架构。接下来演示如何使用 PyTorch Profiler 和 TensorBoard 插件来识别和修复数据加载器中的瓶颈。 如果仔细观察你会发现优化后的GPU利用率为40.46%。现在没有办法粉饰这一点这些结果绝对是糟糕的应该让你彻夜难眠。正如我们过去所扩展的GPU 是我们训练机器中最昂贵的资源我们的目标应该是最大化其利用率。 40.46% 的利用率结果通常代表着加速训练和节省成本的重要机会。当然我们可以做得更好在这篇博文中我们将努力做得更好。我们将首先尝试重现官方教程中提供的结果看看我们是否可以使用相同的工具来进一步提高训练性能。 玩具示例 下面的代码块包含 TensorBoard 插件教程定义的训练循环并进行了两处小修改 我们使用与本教程中使用的 CIFAR10 数据集具有相同属性和行为的假数据集。 我们初始化 torch.profiler.schedule将预热标志设置为 3将重复标志设置为 1。我们发现预热步骤数量的轻微增加提高了分析结果的稳定性。 import numpy as npimport torchimport torch.nnimport torch.optimimport torch.profilerimport torch.utils.dataimport torchvision.datasetsimport torchvision.modelsimport torchvision.transforms as Tfrom torchvision.datasets.vision import VisionDatasetfrom PIL import Imageclass FakeCIFAR(VisionDataset): def __init__(self, transform): super().__init__(rootNone, transformtransform) self.data np.random.randint(low0,high256,size(10000,32,32,3),dtypenp.uint8) self.targets np.random.randint(low0,high10,size(10000),dtypenp.uint8).tolist() def __getitem__(self, index): img, target self.data[index], self.targets[index] img Image.fromarray(img) if self.transform is not None: img self.transform(img) return img, target def __len__(self) - int: return len(self.data)transform T.Compose( [T.Resize(224), T.ToTensor(), T.Normalize((0.5, 0.5, 0.5), (0.5, 0.5, 0.5))])train_set FakeCIFAR(transformtransform)train_loader torch.utils.data.DataLoader(train_set, batch_size32, shuffleTrue)device torch.device(cuda:0)model torchvision.models.resnet18(weightsIMAGENET1K_V1).cuda(device)criterion torch.nn.CrossEntropyLoss().cuda(device)optimizer torch.optim.SGD(model.parameters(), lr0.001, momentum0.9)model.train()# train stepdef train(data): inputs, labels data[0].to(devicedevice), data[1].to(devicedevice) outputs model(inputs) loss criterion(outputs, labels) optimizer.zero_grad() loss.backward() optimizer.step()# training loop wrapped with profiler objectwith torch.profiler.profile( scheduletorch.profiler.schedule(wait1, warmup4, active3, repeat1), on_trace_readytorch.profiler.tensorboard_trace_handler(./log/resnet18), record_shapesTrue, profile_memoryTrue, with_stackTrue) as prof: for step, batch_data in enumerate(train_loader): if step (1 4 3) * 1: break train(batch_data) prof.step() # Need to call this at the end of each step 本教程中使用的 GPU 是 Tesla V100-DGXS-32GB。在这篇文章中我们尝试使用包含 Tesla V100-SXM2–16GB GPU 的 Amazon EC2 p3.2xlarge 实例重现本教程的性能结果并进行改进。尽管它们共享相同的架构但这两种 GPU 之间存在一些差异。我们使用 AWS PyTorch 2.0 Docker 映像运行训练脚本。 TensorBoard 查看器概述页面中显示的训练脚本的性能结果如下图所示 我们首先注意到与教程相反我们实验中的概述页面torch-tb-profiler 版本 0.4.1将三个分析步骤合并为一个。因此平均总步时间为 80 毫秒而不是报告的 240 毫秒。这可以在“跟踪”选项卡中清楚地看到根据我们的经验该选项卡几乎总是提供更准确的报告其中每个步骤大约需要 80 毫秒。 请注意我们的起始点为 31.65% GPU 利用率和 80 毫秒的步长时间与教程中分别介绍的 23.54% 和 132 毫秒的起始点不同。这可能是由于训练环境包括 GPU 类型和 PyTorch 版本的差异造成的。我们还注意到虽然教程基线结果清楚地将性能问题诊断为 DataLoader 中的瓶颈但我们的结果却并非如此。我们经常发现数据加载瓶颈会在“概览”选项卡中将自己伪装成高比例的“CPU Exec”或“其他”。 优化1多进程数据加载 让我们首先应用本教程中所述的多进程数据加载。由于 Amazon EC2 p3.2xlarge 实例有 8 个 vCPU我们将 DataLoader 工作线程的数量设置为 8 以获得最大性能 train_loader torch.utils.data.DataLoader(train_set, batch_size32, shuffleTrue, num_workers8) 本次优化的结果如下所示 对单行代码的更改使 GPU 利用率提高了 200% 以上从 31.65% 增加到 72.81%并将训练步骤时间减少了一半以上从 80 毫秒减少到 37 毫秒。 本教程中的优化过程到此结束。虽然我们的 GPU 利用率 (72.81%) 比教程中的结果 (40.46%) 高很多但我毫不怀疑像我们一样您会发现这些结果仍然非常不令人满意。 个人评论您可以随意跳过想象一下如果 PyTorch 在 GPU 上训练时默认应用多进程数据加载可以节省多少全球资金确实使用多重处理可能会产生一些不需要的副作用。尽管如此必须有某种形式的自动检测算法可以运行以排除识别潜在问题场景的存在并相应地应用此优化。 优化2内存固定 如果我们分析上次实验的 Trace 视图我们可以看到大量时间37 毫秒中的 10 毫秒仍然花费在将训练数据加载到 GPU 上。 为了解决这个问题我们将应用 PyTorch 推荐的另一个优化来简化数据输入流即内存固定。使用固定内存可以提高主机到 GPU 数据复制的速度更重要的是允许我们使它们异步。这意味着我们可以在 GPU 中准备下一个训练批次同时在当前批次上运行训练步骤。有关更多详细信息以及内存固定的潜在副作用请参阅 PyTorch 文档。 此优化需要更改两行代码。首先我们将 DataLoader 的 pin_memory 标志设置为 True。 train_loader torch.utils.data.DataLoader(train_set, batch_size32, shuffleTrue, num_workers8, pin_memoryTrue) 然后我们将主机到设备的内存传输在训练函数中修改为非阻塞 inputs, labels data[0].to(devicedevice, non_blockingTrue), \ data[1].to(devicedevice, non_blockingTrue) 内存固定优化的结果如下所示 我们的 GPU 利用率现在达到了可观的 92.37%并且我们的步数时间进一步减少。但我们仍然可以做得更好。请注意尽管进行了这种优化性能报告仍然表明我们花费了大量时间将数据复制到 GPU 中。我们将在下面的步骤 4 中再次讨论这一点。 优化3增加批量大小 对于我们的下一个优化我们将注意力集中在上一个实验的内存视图上 该图表显示在 16 GB 的 GPU 内存中我们的利用率峰值低于 1 GB。这是资源利用不足的一个极端例子通常尽管并非总是表明有提高性能的机会。控制内存利用率的一种方法是增加批处理大小。在下图中我们显示了将批处理大小增加到 512内存利用率增加到 11.3 GB时的性能结果。 虽然 GPU 利用率指标没有太大变化但我们的训练速度显着提高从每秒 1200 个样本批量大小 32 为 46 毫秒到每秒 1584 个样本批量大小 512 为 324 毫秒。 注意与我们之前的优化相反增加批量大小可能会对训练应用程序的行为产生影响。不同的模型对批量大小的变化表现出不同程度的敏感度。有些可能只需要对优化器设置进行一些调整即可。对于其他人来说调整到大批量可能会更困难甚至不可能。请参阅上一篇文章了解大批量训练中涉及的一些挑战。 优化4减少主机到设备的复制 您可能注意到了我们之前的结果中饼图中代表主机到设备数据副本的红色大碍眼。解决这种瓶颈最直接的方法就是看看是否可以减少每批的数据量。请注意在图像输入的情况下我们将数据类型从 8 位无符号整数转换为 32 位浮点数并在执行数据复制之前应用归一化。在下面的代码块中我们建议对输入数据流进行更改其中我们延迟数据类型转换和规范化直到数据位于 GPU 上 # maintain the image input as an 8-bit uint8 tensortransform T.Compose( [T.Resize(224), T.PILToTensor() ])train_set FakeCIFAR(transformtransform)train_loader torch.utils.data.DataLoader(train_set, batch_size1024, shuffleTrue, num_workers8, pin_memoryTrue)device torch.device(cuda:0)model torch.compile(torchvision.models.resnet18(weightsIMAGENET1K_V1).cuda(device), fullgraphTrue)criterion torch.nn.CrossEntropyLoss().cuda(device)optimizer torch.optim.SGD(model.parameters(), lr0.001, momentum0.9)model.train()# train stepdef train(data): inputs, labels data[0].to(devicedevice, non_blockingTrue), \ data[1].to(devicedevice, non_blockingTrue) # convert to float32 and normalize inputs (inputs.to(torch.float32) / 255. - 0.5) / 0.5 outputs model(inputs) loss criterion(outputs, labels) optimizer.zero_grad() loss.backward() optimizer.step() 由于这一变化从 CPU 复制到 GPU 的数据量减少了 4 倍并且红色碍眼的现象几乎消失了 我们现在的 GPU 利用率达到新高达到 97.51%训练速度达到每秒 1670 个样本让我们看看我们还能做什么。 优化5将渐变设置为“无” 在这个阶段我们似乎充分利用了 GPU但这并不意味着我们不能更有效地利用它。一种流行的优化据说可以减少 GPU 中的内存操作即在每个训练步骤中将模型参数梯度设置为 None 而不是零。有关此优化的更多详细信息请参阅 PyTorch 文档。实现此优化所需要做的就是将optimizer.zero_grad调用的set_to_none设置为True optimizer.zero_grad(set_to_noneTrue) 在我们的例子中这种优化并没有以任何有意义的方式提高我们的性能。 优化6自动混合精度 GPU 内核视图显示 GPU 内核处于活动状态的时间量并且可以成为提高 GPU 利用率的有用资源 该报告中最引人注目的细节之一是未使用 GPU Tensor Core。 Tensor Core 可在相对较新的 GPU 架构上使用是用于矩阵乘法的专用处理单元可以显着提高 AI 应用程序性能。它们的缺乏使用可能代表着优化的主要机会。 由于 Tensor Core 是专门为混合精度计算而设计的因此提高其利用率的一种直接方法是修改我们的模型以使用自动混合精度AMP。在 AMP 模式下模型的部分会自动转换为较低精度的 16 位浮点并在 GPU TensorCore 上运行。 重要的是请注意AMP 的完整实现可能需要梯度缩放但我们的演示中并未包含该梯度缩放。在进行调整之前请务必查看有关混合精度训练的文档。 下面的代码块演示了启用 AMP 所需的训练步骤的修改。 def train(data): inputs, labels data[0].to(devicedevice, non_blockingTrue), \ data[1].to(devicedevice, non_blockingTrue) inputs (inputs.to(torch.float32) / 255. - 0.5) / 0.5 with torch.autocast(device_typecuda, dtypetorch.float16): outputs model(inputs) loss criterion(outputs, labels) # Note - torch.cuda.amp.GradScaler() may be required optimizer.zero_grad(set_to_noneTrue) loss.backward() optimizer.step() 对 Tensor Core 利用率的影响如下图所示。尽管它继续表明有进一步改进的机会但仅用一行代码利用率就从 0% 跃升至 26.3%。 除了提高 Tensor Core 利用率之外使用 AMP 还可以降低 GPU 内存利用率从而释放更多空间来增加批处理大小。下图捕获了 AMP 优化且批量大小设置为 1024 后的训练性能结果 尽管 GPU 利用率略有下降但我们的主要吞吐量指标进一步增加了近 50%从每秒 1670 个样本增加到 2477 个样本。我们正在发挥作用 注意降低模型部分的精度可能对其收敛产生有意义的影响。与增加批量大小见上文的情况一样使用混合精度的影响会因模型而异。在某些情况下AMP 会毫不费力地工作。其他时候您可能需要更加努力地调整自动缩放器。还有一些时候您可能需要显式设置模型不同部分的精度类型即手动混合精度。 优化7在图形模式下训练 我们将应用的最终优化是模型编译。与默认的 PyTorch 急切执行模式相反其中每个 PyTorch 操作都“急切”运行编译 API 将模型转换为中间计算图然后以最适合底层的方式编译为低级计算内核。 以下代码块演示了应用模型编译所需的更改 model torchvision.models.resnet18(weightsIMAGENET1K_V1).cuda(device)model torch.compile(model) 模型编译优化结果如下所示 与之前实验中的 2477 个样本相比模型编译进一步将我们的吞吐量提高到每秒 3268 个样本性能额外提升了 32% (!!)。 图编译改变训练步骤的方式在 TensorBoard 插件的不同视图中非常明显。例如内核视图表明使用了新的融合的GPU 内核而跟踪视图如下所示显示了与我们之前看到的完全不同的模式。 总结 在这篇文章中我们展示了玩具分类模型性能优化的巨大潜力。尽管还有其他性能分析器可供您使用每种分析器都有其优点和缺点但我们选择了 PyTorch Profiler 和 TensorBoard 插件因为它们易于集成。 我们应该强调的是成功优化的路径将根据训练项目的细节包括模型架构和训练环境而有很大差异。在实践中实现您的目标可能比我们在此介绍的示例更困难。我们描述的一些技术可能对您的表现影响不大甚至可能使情况变得更糟。我们还注意到我们选择的精确优化以及我们选择应用它们的顺序有些随意。强烈鼓励您根据项目的具体细节开发自己的工具和技术来实现优化目标。 机器学习工作负载的性能优化有时被视为次要的、非关键的和令人讨厌的。我希望我们已经成功地让您相信节省开发时间和成本的潜力值得在性能分析和优化方面进行有意义的投资。 Reference [1] Source: https://towardsdatascience.com/pytorch-model-performance-analysis-and-optimization-10c3c5822869 本文由 mdnice 多平台发布
