在 NVIDIA Grace Hopper 上分析大型語言模型訓練工作流

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:

Docker:

Step 2: 分配資源

使用 salloc 命令在交互模式下抓取節點。請注意，此示例使用基于 SLURM 的環境：

第 3 步：運行 Singularity 容器

在交互式會話中啟動 NeMo nightly 圖像。

Singularity:

Docker:

第 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 作業：

使用 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 訓練等精度技術如何將效率提升到新的水平。

?