AI 的快速发展催生了模型大小呈指数级增长的时代,特别是在大语言模型 (LLMs) 领域。这些模型凭借其变革能力,正在推动各行各业的创新。然而,训练此类模型的复杂性和计算需求不断增加,因此必须采用细致的优化和分析方法。
尽管生成式 AI 和 LLM 让人兴奋不已,但底层基础设施和优化策略仍然经常被忽视。训练这些模型不仅需要大量计算资源,还需要仔细调整超参数、高效的代码执行和可靠的分析机制,以确保可扩展性和成本效益。
NVIDIA GH200 Grace Hopper 超级芯片代表着 AI 硬件设计的范式转变。凭借其创新的 CPU-GPU 集成和高带宽内存架构,它为 LLM 训练挑战提供了突破性的解决方案。通过 NVLink-C2C 互连技术将 NVIDIA Hopper GPU 与 NVIDIA Grace CPU 相结合,该架构可更大限度地减少瓶颈并更大限度地提高吞吐量,使其成为新一代 AI 工作负载的绝佳选择。
本文将探讨在 NVIDIA Grace Hopper 架构上运行的分析 LLM 训练工作流的关键方面,利用 NVIDIA Nsight Systems 作为强大的性能分析工具。它为从事 LLM 训练工作流的研究人员和工程师提供了全面的指南。它强调了 NVIDIA Nsight Systems 等分析工具在识别瓶颈和优化性能方面的重要性。此外,它还探讨了解释分析数据时的关键因素,并提供了如何利用 NVIDIA Grace Hopper 等先进硬件平台实现高效训练流程的见解。
LLM 的指数级增长
LLM 的演变标志着模型大小的空前增长。从 GPT-2 到 Llama 4 及更高版本,参数数量呈指数级增长,使这些模型能够在众多生成式 AI 任务中取得非凡成就。然而,这种增长带来了巨大的计算挑战。训练先进的 LLM 通常需要数千个 GPU 长时间并行工作,从而消耗大量计算资源。

这些模型规模庞大,不仅需要在算法设计方面进行创新,还需要在硬件架构方面进行创新。NVIDIA Hopper GPU 已成为 LLM 训练的基石,因为其先进的 Tensor Core 和 Transformer 引擎针对混合精度和低精度计算进行了优化。这些功能使模型能够在不影响准确性的情况下执行更快的计算,从而解决大规模 AI 训练中的一个关键瓶颈。
鉴于计算需求呈指数级增长,分析已成为优化工作流程不可或缺的工具。它使研究人员能够分析资源利用率,发现效率低下的问题,并就硬件分配和软件调整做出明智的决策。Nsight Systems 提供系统级应用程序性能视图,使用户能够跟踪执行时间线、查明瓶颈并优化代码以提高可扩展性。
为 LLM 工作流分析准备环境
按照本节中提供的步骤,为分析您的 LLM 微调工作流准备环境。
第 1 步:提取 NVIDIA NeMo 镜像
首先提取针对 NVIDIA GH200 系统优化的 NVIDIA NeMo 镜像。此图像包含高效运行实验所需的所有依赖项。
Singularity:
singularity pull nemo:25.02.sif docker://nvcr.io/nvidia/nemo:25.02.01
Docker:
docker pull nvcr.io/nvidia/nemo:25.02.01
Step 2: 分配资源
使用 salloc
命令在交互模式下抓取节点。请注意,此示例使用基于 SLURM 的环境:
salloc -n 1 -N 1 -p gh -t 2:00:00
第 3 步:运行 Singularity 容器
在交互式会话中启动 NeMo nightly 图像。
Singularity:
singularity run --nv nemo:25.02.sif
Docker:
docker run nvcr.io/nvidia/nemo:25.02.01
第 4 步:下载所需组件
在容器内下载以下内容:
databricks-dolly-15k
dataset for fine-tuning
使用 Nsight Systems 分析微调工作流程
要在微调期间捕获详细的性能数据,请使用 nsys profile
以及针对此工作负载定制的特定switches:
- 设置分析持续时间:
nsys profile -y 360
将分析持续时间设置为 360 秒 (6 分钟) - 延迟分析开始:
nsys profile -d 720
将分析延迟 720 秒 (12 分钟),允许跳过初始设置阶段,专注于分析主要工作负载 - 追踪 CUDA 库:
nsys profile --trace=cuda,cudnn,cublas
监控 CUDA 操作、cuDNN 内核和 cuBLAS 调用 - 指定输出文件:
nsys profile -o sft_llama2_7B
将输出文件命名为sft_llama2_7B.nsys-rep
启用 NeMo 框架容器并设置环境变量后,在交互式节点上启动 fine-tuning 作业:
nsys profile -y 360 -d 720 \
--trace=cuda,cudnn,cublas,osrt,nvtx \
--event-sample=system-wide \
-w true -c cudaProfilerApi -o sft_llama2_7B \
python ...
使用 Nsight Systems 分析第一个分析会话
按所述运行分析会话后,下一步是分析捕获的数据。Nsight Systems 提供丰富的可视化界面,可用于了解应用程序的性能特征。
首先,将 .nsys-rep
文件从 Grace Hopper 机器复制到本地工作站。然后,只需将文件拖放到 Nsight Systems 窗口即可加载。本示例重点关注的主要视图是时间轴视图,该视图显示了运行期间 CPU 和 GPU 活动的详细信息 (图 2) 。

CPU 利用率
在图 2 中时间轴的顶部,Nsight Systems 可视化了 Grace Hopper 计算机上所有 72 个 CPU 核心的利用率。这些柱形图表示每个核心在一段时间内的繁忙程度,所有核心之间的活动一致,表明工作负载分布良好。这对于确保您的训练作业有效利用所有可用的 CPU 资源至关重要。
流
在 CPU 部分下方,Nsight Systems 列出了活动进程和线程。在本例中,关注的主要进程是 python3
,它负责运行 NeMo 框架和我们的 fine-tuning 工作负载。通过检查此过程的活动,您可以深入了解其性能特征。
CUDA 硬件
CUDA 硬件部分详细介绍了 GPU 活动。您将能够看到 CUDA 内核。此处,sm90_xmma_gemm_bf16bf16_bf16f32
似乎主导了已执行的 CUDA 核函数。
内核分析和内存使用率
在“CUDA HW【All Streams】”部分中,您可以剖析GPU执行时间主要由哪些内核决定:

内核表示 GPU 上运行的各个计算任务。在此分析会话中,有一个突出的内核:sm90_xmma_gemm_bf16f16_bf16f32
。此内核占 GPU 总时间的 49.9%。它的名称表示它使用 bfloat16
(BF16) 精度执行矩阵乘法,这是深度学习中的一个关键运算。此内核占据主导地位表明,矩阵乘法运算是我们工作流程中的主要瓶颈。
其他内核(例如 elementwise_kernel
和 vectorized_elementwise_kernel
)有助于元素级运算,但消耗的 GPU 时间较少。
内存使用率
显存占用率部分显示,只有 0.5% 的 GPU 时间归功于 CPU 和 GPU 之间的显存传输和操作。这一低百分比表明,PCIe 或 NVLink 等互连带宽在此特定运行中并不是重大瓶颈。但是,请务必注意,此观察结果与互连带宽特别相关,并不一定意味着内核本身不受内存带宽限制。
工作负载仍可能受到 GPU 内部内存带宽的限制,具体取决于设备内数据的访问和处理方式。根据这些分析数据,您可以合理得出以下结论:互连带宽并非此处的限制因素,而且工作流程似乎主要受计算限制。
计算受限与内存受限的进程
当一个进程的性能主要受限于处理器 (CPU 或 GPU) 的速度时,则被视为受到计算限制。在这种情况下,sm90_xmma_gemm_bf16f16_bf16f32
内核的主导地位确认了工作流的大部分时间都会在 GPU 上执行计算密集型矩阵乘法。
当一个进程的性能主要受限于内存访问 (读取和写入数据) 的速度而非计算速度时,该进程会受到内存限制。大规模数据复制算法或频繁的内存查找都是内存受限进程的示例。
主线程分析
从 GPU 内核和内存使用量的全局视图开始,本节将重点介绍协调微调工作流程的主线程的活动:pt_main_thread
。此线程负责编排数据加载、kernel 启动以及系统不同组件之间的通信。图 4 显示主线程的时间轴视图。

总体 GPU 活动
顶部突出的绿色条表示此线程发起的 GPU 活动。虽然利用率通常较高,但灰色空间的存在表示 GPU 处于闲置状态。这些差距可能来自各种来源,包括:
- CPU 上的数据处理延迟,导致 GPU 等待新工作。
- CPU 线程与 GPU 内核之间的同步问题,导致利用率不足。
- 计算和通信之间的重叠不足,导致数据传输期间 GPU 停止。
CPU 线程
在 GPU 活动下方,我们看到彩色块代表 CPU 线程的执行。这些线程通常处理数据准备、模型参数更新和 kernel 启动等任务。分析这些 CPU 任务的时间和持续时间可以揭示可能导致 GPU 空闲时间的潜在瓶颈。
CUDA 内存传输
时间轴中的橙色条表示 CPU 和 GPU 之间的 CUDA 内存传输。与适合深度学习工作负载的情况相反,这些传输似乎频繁发生,表明数据经常在 CPU 和 GPU 之间移动。这可能会增加开销并降低整体性能,因为频繁的数据移动会拖慢训练过程。优化数据放置以最大限度地减少这些传输可以显著提高效率。
来自 autograd 线程的见解
pt_autograd_0
线程是与 PyTorch 自动梯度引擎相关的关键组件。此引擎可处理反向传播(训练过程的基本组成部分)期间计算梯度的自动微分。
通过在 Nsight Systems 中检查此线程的活动,可以更深入地了解 GPU 和内存使用模式、同步事件以及与梯度计算相关的开销 (图 5) 。

解码时间轴:颜色和活动
时间轴展示了一系列颜色和活动模式,每种模式都对有价值的信息进行编码:
- 绿色部分:表示 autograd 引擎中的活动计算或执行。这些段表示线程主动执行与梯度计算相关的计算的周期。
- 棕色虚线部分:指示线程抢占、上下文切换或线程等待资源的时段。这些中断表明线程的执行正在暂停,这可能是由于其他优先级较高的任务或资源争用造成的。
pthread_cond_wait
块:表示应用程序线程被阻塞并等待条件变量收到信号的实例。如图所示,当 CPU 等待 GPU 上运行的任务完成时,这些块通常会出现。这是优化的关键观察结果。
优化同步
了解等待时间对于优化整体性能至关重要。通过确保 CPU 和 GPU 任务之间更好地同步,减少这些 pthread_cond_wait
事件有助于提高吞吐量。潜在策略包括:
- 计算和通信重叠:通过并行执行计算和数据传输来减少同步点。
- 优化 kernel 启动参数:确保正确配置 kernel 启动的参数,以更大限度地减少 CPU 开销。
- 分析依赖项:仔细检查不同操作之间的依赖项,以识别可能导致不必要延迟的任何瓶颈。
对 pt_autograd_0
线程的详细分析可以揭示 autograd 引擎中的关键瓶颈,并突出显示可改进同步和资源利用率的领域。
结论
本文探讨了分析在优化 LLM 训练工作流中的关键作用。它详细介绍了 NVIDIA Nsight Systems 分析技术,这些技术提供了详细的系统性能视图,从 CPU 利用率到 GPU 内核活动和内存使用情况。
我们分析了同步延迟和 GPU 空闲周期等关键瓶颈,同时强调了优化数据加载和计算的策略。
虽然分析对于识别低效情况至关重要,但这只是难题的一部分。CPU 卸载、Unified Memory、Automatic Mixed Precision (AMP) 和 FP8 训练等高级优化技术为提高性能和可扩展性提供了更多途径。这些方法不仅解决了硬件限制,还使研究人员能够突破 LLM 的可能性界限。
如需了解更多信息,请点播观看 GTC 会议:在 Grace Hopper 超级芯片上配置 Large Language Model 训练。
如需深入了解 Grace Hopper 上的这些高级优化策略,请参阅 NVIDIA Grace Hopper 上 LLM 训练的高级优化策略。相关文章探讨了 Unified Memory 等功能如何简化内存管理,CPU 卸载如何帮助管理 GPU 内存限制,以及 AMP 和 FP8 训练等精度技术如何将效率提升到新的水平。