整体追踪分析简介#
创建于:2024 年 1 月 2 日 | 最后更新:2024 年 1 月 5 日 | 最后验证:2024 年 11 月 5 日
作者: Anupam Bhatnagar
在本教程中,我们将演示如何使用整体追踪分析(HTA)来分析分布式训练任务的追踪数据。请按照以下步骤开始。
安装 HTA#
我们建议使用 Conda 环境来安装 HTA。要安装 Anaconda,请参阅 Anaconda 官方文档。
使用 pip 安装 HTA
pip install HolisticTraceAnalysis
(可选但推荐)设置一个 Conda 环境
# create the environment env_name conda create -n env_name # activate the environment conda activate env_name # When you are done, deactivate the environment by running ``conda deactivate``
入门#
启动 Jupyter notebook 并将 trace_dir
变量设置为追踪文件的位置。
from hta.trace_analysis import TraceAnalysis
trace_dir = "/path/to/folder/with/traces"
analyzer = TraceAnalysis(trace_dir=trace_dir)
时间分解#
为了有效利用 GPU,了解它们在特定任务上如何花费时间至关重要。它们是主要用于计算、通信、内存事件,还是处于空闲状态?时间分解功能提供了对这三类时间花费的详细分析。
空闲时间 - GPU 处于空闲状态。
计算时间 - GPU 用于矩阵乘法或向量运算。
非计算时间 - GPU 用于通信或内存事件。
为实现高训练效率,代码应最大化计算时间,并最小化空闲时间和非计算时间。以下函数生成一个数据帧,为每个 rank 提供详细的时间使用分解。
analyzer = TraceAnalysis(trace_dir = "/path/to/trace/folder")
time_spent_df = analyzer.get_temporal_breakdown()

当在 get_temporal_breakdown 函数中将 visualize
参数设置为 True
时,它还会生成一个按 rank 分解的条形图。

空闲时间分解#
深入了解 GPU 空闲时间及其原因有助于指导优化策略。当没有内核在 GPU 上运行时,GPU 被视为空闲。我们开发了一种算法,将空闲时间分为三个不同的类别:
主机等待: 指的是由于 CPU 未能足够快地将内核入队以保持 GPU 完全利用而导致的 GPU 空闲时间。这类低效率问题可以通过检查导致速度减慢的 CPU 算子、增加批量大小和应用算子融合来解决。
内核等待: 这指的是在 GPU 上启动连续内核时的短暂开销。归因于此类的空闲时间可以通过使用 CUDA Graph 优化来最小化。
其他等待: 此类别包括由于信息不足而当前无法归因的空闲时间。可能的原因包括使用 CUDA 事件在 CUDA 流之间进行同步以及启动内核的延迟。
主机等待时间可以解释为 GPU 因 CPU 而停顿的时间。我们将空闲时间归因于内核等待的启发式方法如下:
连续内核之间的间隔 < 阈值
默认阈值为 30 纳秒,可以通过 consecutive_kernel_delay
参数进行配置。默认情况下,仅计算 rank 0 的空闲时间分解。要计算其他 rank 的分解,请在 get_idle_time_breakdown 函数中使用 ranks
参数。空闲时间分解可以如下生成:
analyzer = TraceAnalysis(trace_dir = "/path/to/trace/folder")
idle_time_df = analyzer.get_idle_time_breakdown()

该函数返回一个数据帧元组。第一个数据帧包含每个 rank 上每个流按类别划分的空闲时间。

当 show_idle_interval_stats
设置为 True
时,会生成第二个数据帧。它包含每个 rank 上每个流空闲时间的摘要统计信息。

提示
默认情况下,空闲时间分解显示每个空闲时间类别的百分比。将 visualize_pctg
参数设置为 False
,函数将以绝对时间作为 y 轴进行渲染。
内核分解#
内核分解功能可以分解每种内核类型(如通信(COMM)、计算(COMP)和内存(MEM))在所有 rank 上所花费的时间,并以饼图的形式呈现每个类别所占的时间比例。

内核分解的计算方式如下:
analyzer = TraceAnalysis(trace_dir = "/path/to/trace/folder")
kernel_type_metrics_df, kernel_metrics_df = analyzer.get_gpu_kernel_breakdown()
该函数返回的第一个数据帧包含用于生成饼图的原始值。
内核持续时间分布#
由 get_gpu_kernel_breakdown 返回的第二个数据帧包含每个内核的持续时间摘要统计信息。具体来说,这包括每个 rank 上每个内核的计数、最小值、最大值、平均值、标准差、总和以及内核类型。

利用这些数据,HTA 创建了许多可视化图表以识别性能瓶颈。
每个 rank 上每种内核类型的前几个内核的饼图。
每个前几名内核和每种内核类型在所有 rank 上的平均持续时间的条形图。

提示
所有图像均使用 plotly 生成。将鼠标悬停在图表上会在右上角显示模式栏,允许用户缩放、平移、选择和下载图表。
上面的饼图显示了排名前 5 的计算、通信和内存内核。为每个 rank 生成了类似的饼图。可以使用传递给 get_gpu_kernel_breakdown 函数的 num_kernels
参数配置饼图以显示排名前 k 的内核。此外,duration_ratio
参数可用于调整需要分析的时间百分比。如果同时指定了 num_kernels
和 duration_ratio
,则 num_kernels
优先。

上方的条形图显示了 NCCL AllReduce 内核在所有 rank 上的平均持续时间。黑线表示每个 rank 上的最小和最大时间。
警告
当使用 jupyter-lab 时,请将“image_renderer”参数值设置为“jupyterlab”,否则图表将不会在 notebook 中渲染。
有关此功能的详细演练,请参阅仓库示例文件夹中的 gpu_kernel_breakdown notebook。
通信与计算重叠#
在分布式训练中,大量时间花费在 GPU 之间的通信和同步事件上。为了实现高 GPU 效率(例如 TFLOPS/GPU),保持 GPU 被计算内核超额订阅至关重要。换句话说,GPU 不应因未解决的数据依赖而阻塞。衡量计算被数据依赖阻塞程度的一种方法是计算通信与计算的重叠。如果通信事件与计算事件重叠,则观察到更高的 GPU 效率。缺乏通信和计算重叠将导致 GPU 空闲,从而导致低效率。总而言之,更高的通信计算重叠是可取的。为了计算每个 rank 的重叠百分比,我们测量以下比率:
(通信时花费在计算上的时间)/(花费在通信上的时间)
通信计算重叠可以如下计算:
analyzer = TraceAnalysis(trace_dir = "/path/to/trace/folder")
overlap_df = analyzer.get_comm_comp_overlap()
该函数返回一个数据帧,其中包含每个 rank 的重叠百分比。

当 visualize
参数设置为 True 时,get_comm_comp_overlap 函数还会生成一个按 rank 表示重叠的条形图。

增强计数器#
内存带宽和队列长度计数器#
内存带宽计数器测量通过内存复制(memcpy)和内存设置(memset)事件从 H2D、D2H 和 D2D 复制数据时使用的内存复制带宽。HTA 还计算每个 CUDA 流上的待处理操作数。我们称之为队列长度。当一个流上的队列长度达到或超过 1024 时,新的事件无法在该流上调度,CPU 将会停顿,直到 GPU 流上的事件处理完毕。
generate_trace_with_counters API 输出一个带有内存带宽和队列长度计数器的新追踪文件。新的追踪文件包含指示 memcpy/memset 操作使用的内存带宽的轨道以及每个流上队列长度的轨道。默认情况下,这些计数器是使用 rank 0 追踪文件生成的,新文件的名称中包含后缀 _with_counters
。用户可以通过在 generate_trace_with_counters
API 中使用 ranks
参数为多个 rank 生成计数器。
analyzer = TraceAnalysis(trace_dir = "/path/to/trace/folder")
analyzer.generate_trace_with_counters()
生成的带有增强计数器的追踪文件的屏幕截图。

HTA 还使用以下 API 提供了内存复制带宽和队列长度计数器的摘要,以及在代码分析部分中这些计数器的时间序列:
要查看摘要和时间序列,请使用:
# generate summary
mem_bw_summary = analyzer.get_memory_bw_summary()
queue_len_summary = analyzer.get_queue_length_summary()
# get time series
mem_bw_series = analyzer.get_memory_bw_time_series()
queue_len_series = analyzer.get_queue_length_series()
摘要包含计数、最小值、最大值、平均值、标准差、第 25、50 和 75 百分位数。

时间序列只包含值发生变化的时间点。一旦观察到一个值,时间序列将保持不变直到下一次更新。内存带宽和队列长度时间序列函数返回一个字典,其键是 rank,值是该 rank 的时间序列。默认情况下,仅为 rank 0 计算时间序列。
CUDA 内核启动统计#

对于在 GPU 上启动的每个事件,CPU 上都有一个相应的调度事件,例如 CudaLaunchKernel
、CudaMemcpyAsync
、CudaMemsetAsync
。这些事件通过追踪中的一个通用相关 ID 链接起来 - 见上图。此功能计算 CPU 运行时事件的持续时间、其对应的 GPU 内核以及启动延迟,例如,GPU 内核开始和 CPU 算子结束之间的差值。内核启动信息可以如下生成:
analyzer = TraceAnalysis(trace_dir="/path/to/trace/dir")
kernel_info_df = analyzer.get_cuda_kernel_launch_stats()
下面是生成的数据帧的屏幕截图。

CPU 操作、GPU 内核的持续时间以及启动延迟使我们能够发现以下情况:
短 GPU 内核 - 持续时间小于相应 CPU 运行时事件的 GPU 内核。
运行时事件异常值 - 持续时间过长的 CPU 运行时事件。
启动延迟异常值 - 调度时间过长的 GPU 内核。
HTA 为上述三个类别中的每一个生成分布图。
短 GPU 内核
通常,CPU 端的启动时间在 5-20 微秒之间。在某些情况下,GPU 执行时间低于启动时间本身。下图帮助我们了解这种情况在代码中发生的频率。

运行时事件异常值
运行时异常值取决于用于分类异常值的截止值,因此 get_cuda_kernel_launch_stats API 提供了 runtime_cutoff
参数来配置该值。

启动延迟异常值
启动延迟异常值取决于用于分类异常值的截止值,因此 get_cuda_kernel_launch_stats API 提供了 launch_delay_cutoff
参数来配置该值。

结论#
在本教程中,您学习了如何安装和使用 HTA,这是一个性能工具,使您能够分析分布式训练工作流程中的瓶颈。要了解如何使用 HTA 工具执行追踪差异分析,请参阅使用整体追踪分析进行追踪差异分析。