共计 5147 个字符，预计需要花费 13 分钟才能阅读完成。
Profiler v1.9 的改良次要针对在运行时和 / 或内存上能耗最重大的执行步骤，共事将 GPU 和 CPU 之间的工作负载调配进行可视化。
Profiler v1.9 新增五个次要性能包含：
1、分布式训练视图： 这有助于你把握分布式训练任务中，耗费的工夫和内存。假如你有一个训练模型，当你要把负载分成 Worker 节点并行运行时，可能会像黑盒一样，呈现各种各样的问题。模型整体的指标是进步训练速度。这个分布式训练视图有助于你诊断和调试单个节点内的问题。
2、内存视图： 借助该视图，你能够更好地理解内存应用状况。这个工具能显示程序在不同运行阶段的流动内存分配情况，从而帮忙你防止 Out of Memory 谬误的产生。
3、GPU 利用可视化： 该工具能够确保 GPU 失去充分利用。
4、云存储反对： Tensorboard 插件当初能够从 Azure Blob Storage、Amazon S3 和 Google Cloud Platform 读取解析数据。
5、跳转源代码： 该性能反对堆栈跟踪信息可视化，并能够间接跳转至源代码。这有助于你依据剖析后果疾速优化和迭代代码。
PyTorch Profiler Colab 传送门
汉化版 Colab 传送门
Colab 内容一览：
- 筹备数据和模型
- 应用 Profiler 记录执行事件
- 运行 Profiler
- 应用 TensorBoard 查看后果并分析模型性能
- 借助 Profiler 进步性能
- 应用其余高级功能分析性能
开始应用 PyTorch Profiling 工具
首先：
$ pip install torch-tb-profiler
import torch.profiler as profiler
With profiler.profile(XXXX)备注： 对于 CUDA 和 CPU 的剖析，详见 Here
with torch.profiler.profile(
activities=[
torch.profiler.ProfilerActivity.CPU,
torch.profiler.ProfilerActivity.CUDA],- profiler.record_function(“$NAME”)：容许为函数区块增加装璜器 (decorator，指与名称相干的标签)。
- profiler.profile 下的 Profile_memory=True 参数，能够对 CPU 和 GPU 的内存占用状况进行剖析。
对 PyTorch 模型性能进行可视化
### 分布式训练
深度学习的最新进展证实了大型数据集和大型模型的价值，这也意味着模型训练须要更多的计算资源。
分布式数据并行 (DDP) 和英伟达多卡通信框架 (NCCL) 是 PyTorch 中宽泛采纳的范式，用于减速深度学习训练。
在这个版本的 PyTorch Profiler 中，现已反对 NCCL 后端的 DDP。
计算 / 通信概览
在分布式训练视图中的「计算 / 通信概览」中，用户能够察看所有 Worker 之间「load balancer」节点的计算与通信比，这是依照颗粒度来掂量的。
load balancer 相干链接：Here)
情景 1:
如果一个 Worker 的计算和重叠工夫，比其余 Worker 长，这可能示意工作负载平衡中存在问题，或有一个节点是 straggler。计算是 GPU 内核工夫之和，减去重叠工夫。重叠工夫是指计算过程中，通过交织通信节俭的工夫。
重叠工夫越长，示意计算和通信之间的并行性更好。 现实情况下，计算和通信齐全互相重叠。通信是总的通信工夫减去重叠工夫。
以下示例展现了这种状况在 Tensorboard 上的体现。
straggler 示例
情景 2:
如果批尺寸较小（即所有 Worker 上的计算都比拟少），或须要传输的数据较大，那么计算通信比也可能较小，在 Profiler 中能够看到 GPU 利用率低，等待时间长。
用户能够依据这种计算 / 通信视图 review 代码，通过采纳梯度累积来缩小通信，或通过减少批尺寸来缩小通信比例。DDP 通信工夫取决于模型大小。批尺寸与模型大小无关。因而，减少批尺寸能够使计算工夫更长、计算通信例更大。
### 同步 / 通信概览
在同步 / 通信视图中，用户能够察看通信效率。这是用步骤工夫减去计算和通信工夫得进去的。同步工夫是期待并与其余 Worker 同步的总通信工夫的一部分。同步 / 通信视图包含初始化、数据加载器、CPU 计算等。
从该视图中能够得悉： 总通信量中真正用于替换数据的比例是多少，期待其余 Worker 提供数据的空置工夫是多少。
例如，如果存在低效的工作负载平衡或 straggler 问题，就能够在同步 / 通信视图中发现。这个视图将展现一些 Worker 的等待时间比其余 Worker 长。
从上表能够得悉每个节点中所有通信算子的具体统计数据。通过该表能够理解调用了哪些算子类型，每个算子被调用了多少次，每个算子所传输的数据大小是多少，等等。
### 内存视图
利用该工具，能够理解模型中算子的硬件资源耗费。理解算子层面的工夫和内存耗费，有助于解决性能瓶颈问题，进而放慢模型运行速度。 鉴于 GPU 内存大小无限，优化内存应用效率有助于：
- 容许运行更大规模的模型，在终端级别的工作上体现更好。
- 容许更大的批尺寸，进步训练速度。
Profiler 记录了 Profiler 距离期间的所有内存调配。抉择「设施」就能够看到每个算子在 GPU 侧或主机侧的内存应用详情。
留神：必须启用 profile_memory=True 来生成以下内存数据。
相干链接：Here
With torch.profiler.profile(Profiler_memory=True # this will take 1 – 2 minutes to complete.)重要定义：
- 「Size Increase」显示所有调配字节的总和，减去所有内存开释字节。
- 「Allocation Size」显示不包含内存开释的所有调配字节的总和。
- 「Self」意味着调配的内存不是来自任何 child 算子，而是由算子自行调配的。
### 时间轴上的 GPU 指标
利用该性能，你能够在一个或多个 GPU 利用不充沛时，轻松调试性能问题。现实状况下，你的程序应该有很高的 GPU 利用率（尽可能达到 100% 的 GPU 利用率），CPU 到 GPU 的通信老本最低，且没有功耗。
概述： 概述页面强调了三个重要的 GPU 应用指标 (即 GPU Utilization、Est. SM Efficiency 以及 Est. Achieved Occupancy) 在不同层面的后果。
从实质上讲，每个 GPU 都有很多 SM，每个 SM 都有很多 Warp，能够同时执行很多线程。Warp 执行 的线程多，是因为其数量取决于 GPU。从更高角度来看，时间轴上的 GPU 指标能够帮忙开发者对整个堆栈有全局观，这十分重要。
如果 GPU 利用率很低，则表明模型有潜在问题。常见起因如下：
- 内核中的并行性有余，即批尺寸过小
- 在一个循环中调用小内核，即启动 overhead 没被摊销
- CPU 或 I/O 瓶颈导致工作内容有余，GPU 利用率低
在概览页面中，性能倡议局部是一些能够进步 GPU 利用率的可行性倡议。在这个例子中，GPU 利用率很低，所以性能倡议是减少批尺寸。依据性能倡议，将批尺寸从 4 减少到 32，使 GPU 利用率减少了 60.68%。
GPU 利用率： 在 Profiler 中，当 GPU 引擎执行一个工作负载时会呈现一个步骤间隔时间 (step interval time)。利用率百分比越高越好。仅通过 GPU 利用率来判断性能瓶颈，后果并不精确。你无奈借此得悉到底有多少流处理器 (Streaming Multiprocessor) 在运行。
留神，尽管这个指标对检测闲暇期很有帮忙，但高数值并不代表 GPU 的利用率很高。如，一个单线程间断运行的内核，其 GPU 利用率将达到 100%。
预估流处理器效率 (Est. SM Efficiency) 是一个更细化的指标， 它示意在跟踪全过程中，正在应用的 SM 的百分比，代表 SM 上至多有一个流动 wrap 的 time 百分比，以及那些闲暇 warp。
NVIDIA 文档：Here
Est. SM Efficiency 也有局限性。如每个区块只有一个线程的内核，无奈齐全利用所有 SM。只根据 SM Efficiency 无奈得悉每个 SM 的利用率，只能晓得每个 SM 正在进行的操作，这包含期待内存加载后果时的进展。
为了放弃 SM 的高利用率，必须保障足够数量的 ready wrap，只有产生停滞就能够运行。
对于性能诊断问题而言，预估实现的占用率（Est. Achieved Occupancy）比 Est. SM Efficiency 和 GPU 利用率更精确。预估实现的占用率表明每个 SM 有多少 warp 能够同时流动。领有数量足够多的流动 warp 通常是实现良好吞吐量的要害。与 GPU 利用率和 SM Efficiency 不同，让这个值尽可能高并不是终极目标。
从教训角度登程，通过将这个指标进步到 15% 或以上，能够取得良好的吞吐量收益。但在某些时候，也会遇到收益递加的状况。例如，如果该值曾经达到 30%，接下来的收益就变得不确定了。这个指标展现了内核执行期间，所有 warp scheduler 的平均值
NVIDIA 文档：Here
Est. Achieve Occupancy 的值越大越好。
具体细节：Resnet50_batchsize4
具体细节：Resnet50_batchsize32
内核视图：内核有「Blocks per SM」和「Est. Achieved Occupancy」。
Est. Achieved Occupancy 是比拟模型运行状况的无利工具。
每个 SM 的均匀取块数 (Mean Blocks per SM)：
每 SM 的区块数量 = 该内核的区块数 / 该 GPU 的 SM 数。如果这个数字小于 1，表明 GPU 多处理器没有被齐全利用。”Mean Blocks per SM “ 是这个内核 name 所有运行的加权平均值，应用每次运行的时长作为权重。
均匀 Est. Achieved 占用率 (Mean Est. Achieved Occupancy：
Est. Achieved Occupancy 的定义与上述概述雷同。Mean Est. Achieved Occupancy 是这个内核 name 所有运行的加权平均值，应用每次运行的继续时长作为权重。
跟踪视图：
跟踪视图显示的是一个工夫线，示意模型中算子的持续时间，以及是哪个零碎执行的操作。这个视图能够帮忙你辨认高耗费和长执行，是不是因为输出或模型训练引起的。目前，该跟踪视图可显示一个工夫线内的 GPU 利用率和 Est. SM Efficiency。
上述例子中，「ProfilerStep5」在线程 28022 期间的 GPU 利用率比「Optimizer.step」期间要高。能够通过放大来查看相干起因。
从上图可知，前者的内核比后者长。后者的内核执行工夫太短，导致 GPU 利用率升高。
Est. SM Efficiency： 每个内核都有一个计算出的 EST. SM Efficiency，介于 0-100% 之间。例如，上面的内核只有 64 个区块，而这个 GPU 的 SM 为 80，则它的「Est. SM Efficiency」为 64/80，即 0.8。
### 云存储反对
运行 pip install tensorboard 后，为了通过云供应商读取数据，你能够运行：
torch-tb-profiler[blob]
torch-tb-profiler[gs]
torch-tb-profiler[s3]借助 pip install torch-tb-profiler[blob], pip install torch-tb-profiler[gs]，或 pip install torch-tb-profiler[S3] 能够通过云服务商读取数据。
更多信息，请参考：Here
### 跳转至源代码
将 TensorBoard 和 PyTorch Profiler 间接集成到 Visual Studio Code (VS Code) 中的一大益处，就是能从 Profiler 的 stack trace 间接跳转至源代码（文件和行）。VS Code Python 扩大现已反对 TensorBoard 集成。
只有当 Tensorboard 在 VS Code 中运行时，跳转到源代码才可用。如果 profiling with_stack=True，stack trace 就会呈现在插件 UI 上。点击 PyTorch Profiler 中的 stack trace，VS Code 就会关上相应的文件，并间接跳转到对应代码，以便进行调试。这样就能够依据剖析后果和倡议，迅速对代码进行优化和批改。
用 Visual Studio Code Plug In UI 跳转至源代码
对于如何优化批尺寸性能，请查看具体教程：Here
PyTorch Profiler 也能够与 PyTorch Lightning 集成，只需用 trainer.profiler=pytorch 来启动 lightning 训练任务即可生成 trace。
具体示例：Here
原文地址：Here