一、背景

在之前的系列文章中，筆者已經(jīng)系統(tǒng)性地介紹過大規(guī)模 LLM 訓(xùn)練面臨的各種挑戰(zhàn)以及可能涉及的問題和解決方案。在對(duì)大規(guī)模任務(wù)進(jìn)行 Profiling 分析的時(shí)候，面對(duì)成千上萬的 kernel 也經(jīng)?？嗖豢把裕胍ㄟ^統(tǒng)計(jì)分析來診斷相應(yīng)的問題，并為優(yōu)化提供更多的可能性。碰巧看到了字節(jié)跳動(dòng) Seed 的這篇文章，雖然社區(qū)內(nèi)沒有看到太多討論，不過其確實(shí)與我們的一些思路不謀而合，這里進(jìn)行簡(jiǎn)單介紹。

其實(shí)文章中的大部分結(jié)論性內(nèi)容筆者在之前的文章中都已總結(jié)過，比如：

• 大規(guī)模 GPU 集群運(yùn)維實(shí)踐：假裝萬卡 GPU 集群經(jīng)驗(yàn)中，我們提到過硬件（GPU 降頻，PCIe 鏈路降級(jí)）導(dǎo)致的訓(xùn)練任務(wù)降速；以及軟件（Python 垃圾回收）導(dǎo)致的周期性降速等。
• 大模型訓(xùn)練中的負(fù)載均衡：挑戰(zhàn)與解決方案解析中，我們也提到了一些因?yàn)樨?fù)載不均衡導(dǎo)致無法充分發(fā)揮算力的問題，包括：

流水線并行（PP） Stage 的負(fù)載不均衡導(dǎo)致的問題和解決方案。

MoE 中專家負(fù)載不均衡導(dǎo)致的問題和方案。

長(zhǎng)序列負(fù)載不均衡問題和優(yōu)化方案。

多模態(tài)和長(zhǎng)序列場(chǎng)景中樣本序列長(zhǎng)度不均衡導(dǎo)致的問題和改進(jìn)方案。

一些碎碎念：最近停更了將近半個(gè)月，一方面是確實(shí)太忙，沒有太多精力；另一方面是技術(shù)迭代太快，看了很多東西都沒來得及記錄。比如，筆者不久之前還推測(cè)“不久的未來一定會(huì)有 30B 規(guī)模 Dense 模型 Reasoning 能力接近或超越 DeepSeek R1”，沒想到這個(gè)“不久”這么快到來；在介紹 Reasoning 相關(guān)工作時(shí)也提到，混合 Reasoning 和非 Reasoning 模型必定會(huì)出現(xiàn)，沒想到現(xiàn)在基本已是標(biāo)配；最后，LLaMA-4、Qwen3 等模型相繼推出，Google Gemini 也屢創(chuàng)新高，期待 DeepSeek R2 能再創(chuàng)輝煌。

二、摘要

LLM 訓(xùn)練是當(dāng)前對(duì)分布式計(jì)算要求最高的任務(wù)之一，通常需要成千上萬的 GPU，并且需要頻繁進(jìn)行跨機(jī)器同步。這種工作模式容易受到 Straggler 的影響（即，訓(xùn)練可能因少數(shù)慢 Worker 而變慢）。在字節(jié)跳動(dòng)的場(chǎng)景中，作者發(fā)現(xiàn) Straggler 并非總是簡(jiǎn)單的硬件故障引起，可能源于多種復(fù)雜因素。

本文研究旨在通過對(duì)字節(jié)跳動(dòng) LLM 訓(xùn)練集群 5 個(gè)月的追蹤數(shù)據(jù)，全面探討 LLM 訓(xùn)練中的 Straggler 問題。核心方法是采用假設(shè)分析，模擬無 Straggler 的理想場(chǎng)景，并與實(shí)際情況對(duì)比。通過這種方式作者探討了以下問題：

1. Straggler 對(duì)于訓(xùn)練任務(wù)的影響頻率及對(duì)訓(xùn)練任務(wù)的具體影響。
2. Straggler 能否表現(xiàn)出時(shí)間或空間上的規(guī)律性。
3. Straggler 現(xiàn)在的潛在根源是什么。

三、引言

3.1 問題背景

LLM 訓(xùn)練中，Straggler 的影響與集群中訓(xùn)練任務(wù)采用的分布式并行策略密切相關(guān)。典型的 LLM 訓(xùn)練會(huì)采用混合并行策略，包括 DP（Data Parallelism）、PP（Pipeline Parallelism）、TP（Tensor Parallelism）；在 MoE 模型中，也通常會(huì)采用 EP（Expert Parallelism）；在長(zhǎng)序列場(chǎng)景還會(huì)采用 SP（Sequence Parallelism）或 CP（Context Parallelism）。所有這些策略都需要頻繁協(xié)調(diào)以在 GPU 和服務(wù)器間同步結(jié)果，因而容易受到 Straggler 的影響。

為了緩解 Straggler 問題，常見的手段如下所示，通常比較少采用：

• 使用冗余的備份節(jié)點(diǎn)，資源浪費(fèi)較嚴(yán)重。
• 異步 SGD，數(shù)學(xué)不等價(jià)，精度有損。
• 丟棄慢 Worker 的更新，數(shù)學(xué)不等價(jià)，精度有損。

鑒于 LLM 訓(xùn)練任務(wù)容易受 Straggler 影響，作者分析了字節(jié)跳動(dòng) LLM 訓(xùn)練集群 2024 年 1 月到 5 月期間收集的追蹤數(shù)據(jù)，以便進(jìn)行分析。

3.2 混合并行訓(xùn)練和 Straggler

Straggler 定義：若所有 Worker 完成分配任務(wù)所需時(shí)間相同，則采用混合并行技術(shù)的 LLM 訓(xùn)練任務(wù)被視為無 Straggler 現(xiàn)象。這可以最大限度減少了同步所需時(shí)間，實(shí)現(xiàn)理想的無 Straggler 場(chǎng)景，達(dá)到最佳性能?；谶@一定義，任何導(dǎo)致 Worker 進(jìn)度滯后的問題均被視為 Straggle 現(xiàn)象。不僅包括針對(duì)單一 Worker 的硬件故障，也包括影響所有 Worker 的不可預(yù)測(cè)停滯（比如垃圾回收），以及數(shù)據(jù)不均等問題導(dǎo)致 Workload 不均。

DP/ZeRO/FSDP：將訓(xùn)練數(shù)據(jù)分割至多個(gè) Worker，每個(gè) Worker 均持有整個(gè)模型的副本。

• 采用 DP 時(shí)，每個(gè) Step 各 Worker 被分配一個(gè)訓(xùn)練 Batch。該 Worker 執(zhí)行其 Batch 的 Forward 與 Backward 計(jì)算，隨后所有 Worker 在進(jìn)入下一 Step 訓(xùn)練前進(jìn)行梯度 AllReduce 操作。此梯度 AllReduce 步驟要求 Worker 間同步，任一 Worker 的延遲都可能導(dǎo)致整體停滯，形成拖尾效應(yīng)。
• ZeRO 和 FSDP 對(duì) DP 進(jìn)行了擴(kuò)展，通過跨 Worker 切分優(yōu)化器狀態(tài)、參數(shù)和/或梯度來降低單 GPU 內(nèi)存需求。與梯度 AllReduce 不同，ZeRO 和 FSDP 需執(zhí)行梯度計(jì)算的 ReduceScatter 步驟、Device-Local 參數(shù)更新步驟，以及參數(shù) AllGather 步驟來完成每次訓(xùn)練迭代。其中 ReduceScatter 與 AllGather 操作均需跨 Worker 同步，因此同樣易受 Straggler Worker 影響。

PP：將模型切分至多個(gè) Worker，每個(gè) Worker 持有模型連續(xù)層的不相交子集，稱為 PP Stage。PP 降低了模型權(quán)重和激活值對(duì)單塊 GPU 內(nèi)存的需求。訓(xùn)練過程中，一個(gè) Batch 的數(shù)據(jù)被劃分為若干 Micro-Batch，通過 PP Stage 進(jìn)行流水線式訓(xùn)練。已有多種 Micro-Batch 調(diào)度策略，如 GPipe、1F1B 及 VPP（Virtual PP）。這些調(diào)度策略均假設(shè)計(jì)算在各流水線階段間均勻分配，旨在最小化 PP Bubble —— 即某 Stage 因等待前一 Stage 數(shù)據(jù)而空閑的時(shí)間。若 PP Stage 分配不均，最慢 Stage 將阻礙其他階段，形成性能瓶頸。因此，PP 易因 Stage 間計(jì)算分配不均而受拖累。

TP 和 CP：除 PP 外，還可采用 TP 和 CP，進(jìn)一步降低單 GPU 內(nèi)存需求。TP 在各 Worker 間劃分每層權(quán)重，CP 則在節(jié)點(diǎn)間分割序列 Token。二者均需在每層 Transformer 后執(zhí)行同步步驟，以聚合 TP 或 CP 組內(nèi)所有 Worker 的部分計(jì)算結(jié)果。由于同步時(shí)慢速設(shè)備會(huì)拖累整體進(jìn)度，TP 與 CP 同樣易受 Straggler Worker 影響。本文不分析 TP 和 CP 組內(nèi)的系統(tǒng)性落后 Worker 問題。

在實(shí)際訓(xùn)練中，通常會(huì)采用混合并行策略，其性能優(yōu)于任何單一策略。采用混合并行策略時(shí)，Worker 可組織為一個(gè)超立方結(jié)構(gòu)，每個(gè)維度對(duì)應(yīng)一種并行策略。如下圖 Figure 1 所示，展示了一種 DP-PP-TP 的混合并行策略。

• 一個(gè)速度較慢的 TP Worker 會(huì)拖慢所屬的 PP Rank，進(jìn)而產(chǎn)生 PP 性能瓶頸。
• 這個(gè) PP 瓶頸又會(huì)進(jìn)一步減緩該 Worker 所屬的整個(gè) DP Rank，延后梯度同步，并阻礙其他 DP Rank 的進(jìn)度。

四、方法

4.1 LLM 訓(xùn)練任務(wù)追蹤

集群配置：收集追蹤數(shù)據(jù)的集群專用于訓(xùn)練，并由多個(gè)團(tuán)隊(duì)內(nèi)部共享。集群中的機(jī)器采用與 NVIDIA DGX 服務(wù)器類似的硬件配置：每臺(tái)服務(wù)器 8 個(gè) GPU，通過 NVLink 或 PCIe 鏈路互連，包括 4 或 8 個(gè)百 Gbps NIC、一個(gè)專用于存儲(chǔ)和管理的獨(dú)立 NIC、數(shù)百個(gè) CPU Core 及數(shù) TB 內(nèi)存。服務(wù)器間通過高性能交換機(jī)以三層 CLOS 拓?fù)浣Y(jié)構(gòu)互聯(lián)。網(wǎng)絡(luò)無收斂，并且經(jīng)過精心調(diào)優(yōu)，確保不會(huì)因網(wǎng)絡(luò)擁塞導(dǎo)致性能下降。

任務(wù)調(diào)度：在集群上可同時(shí)調(diào)度多個(gè)任務(wù)，每個(gè)任務(wù)在其執(zhí)行期間獨(dú)占分配的 GPU 資源。調(diào)度器確保每項(xiàng)任務(wù)使用相同類型的 GPU，以實(shí)現(xiàn)硬件配置的一致性。此外，調(diào)度器會(huì)以最優(yōu)方式分配 GPU，保證任務(wù)所需 GPU 在網(wǎng)絡(luò)拓?fù)渲形恢孟噜?。由于大型任?wù)以 8 的倍數(shù)申請(qǐng) GPU，不同大規(guī)模任務(wù)不會(huì)共用同一臺(tái)服務(wù)器。加之網(wǎng)絡(luò)無擁塞，這意味著即便任務(wù)運(yùn)行于同一集群，也不會(huì)因資源爭(zhēng)搶出現(xiàn) Straggler 現(xiàn)象。

數(shù)據(jù)采集：本研究所用追蹤數(shù)據(jù)采集自 2024 年 1 月 1 日至 2024 年 5 月 31 日期間提交的 LLM 預(yù)訓(xùn)練任務(wù)。鑒于研究聚焦大規(guī)模任務(wù)，僅分析至少使用 128 塊 GPU 的任務(wù)，并根據(jù)規(guī)則剔除無效或不適合分析的數(shù)據(jù)，最終得到 3079 個(gè)有效任務(wù)樣本。這些任務(wù)包含采用 Dense 架構(gòu)和 MoE 架構(gòu)的模型，分別配置了短序列或長(zhǎng)序列上下文訓(xùn)練。其中 31.7% 的任務(wù)使用 ≥256 塊GPU，18.3% 使用 ≥ 512 塊 GPU，3.6% 使用 ≥ 5000 塊 GPU?？傮w而言，這些分析樣本覆蓋了 LLM 訓(xùn)練任務(wù)總 GPU 時(shí)長(zhǎng)的一半左右。

其中所有任務(wù)均采用開源 Megatron-LM 的定制版本完成。使用的 Megatron-LM 框架已經(jīng)集成自研的性能分析工具 NDTimeline（GitHub - volcengine/veScale: A PyTorch Native LLM Training Framework [3]），默認(rèn)情況下，該工具會(huì)對(duì)任務(wù)中 10% 的訓(xùn)練 Step 進(jìn)行采樣分析。對(duì)于每個(gè)被分析的 Step，工具會(huì)記錄一系列重要操作的開始和結(jié)束時(shí)間，這些操作包括 Forward 和 Backward 計(jì)算以及通信操作。詳細(xì)如下圖 Table 1 所示。

為了降低追蹤大量小型 Kernel 的成本，分析中的 Forward 和 Backward 操作通常包括多個(gè) GPU Kernel。此外，NDTimeline 會(huì)定期同步任務(wù)中所有機(jī)器的時(shí)鐘，這使得能夠?qū)R不同機(jī)器上的相關(guān)操作，以便進(jìn)行假設(shè)分析。

在追蹤記錄中的每個(gè)操作，其日志包括操作類型、開始和結(jié)束時(shí)間戳，以及一組元數(shù)據(jù)，如訓(xùn)練 Step ID、Micro-Batch ID、PP Rank 和 DP Rank。這些元數(shù)據(jù)可以幫助重建操作間的依賴關(guān)系，對(duì)于模擬無 Straggler 情況下的替代 Timeline 至關(guān)重要。

4.2 用于假設(shè)分析的模擬器

假設(shè)分析的目標(biāo)是通過回答以下問題來評(píng)估 Straggler 的影響：

• 如果所有 Straggler 都不存在，任務(wù)會(huì)耗時(shí)多久？
• 如果除特定一組 Straggler 外其他都不存在，任務(wù)又會(huì)耗時(shí)多久？

為了解答這些問題，作者模擬了一個(gè)不存在 Straggler 的替代 Timeline。核心觀點(diǎn)在于，在沒有 Straggler 的情況下，相似操作的耗時(shí)應(yīng)當(dāng)是相同的?；谶@一觀點(diǎn)，作者首先嘗試估算在無 Straggler 的理想情境下每個(gè)操作的持續(xù)時(shí)間。然后，模擬這樣一個(gè)替代時(shí)間線：操作按其依賴關(guān)系啟動(dòng)，并在估算的理想時(shí)長(zhǎng)內(nèi)完成。通過比較模擬作業(yè)完成時(shí)間（JCT）與實(shí)際追蹤記錄中的時(shí)間，便能評(píng)估 Straggler 現(xiàn)象對(duì)整體效率的影響。

估計(jì)無 Straggle 的理想操作時(shí)長(zhǎng)。從概念上講，可以將追蹤到的操作組織成一個(gè)四維張量，維度分別為：訓(xùn)練 Step、Micro-Batch、PP Rank 和 DP Rank。作者將此張量稱為 OpDuration 張量。如上 Table 1 中的每種操作類型都有一個(gè)這樣的張量。

• 對(duì)于計(jì)算操作，張量中的元素直接對(duì)應(yīng)追蹤到的操作時(shí)長(zhǎng)。
• 對(duì)于通信操作，計(jì)算追蹤時(shí)長(zhǎng)中的一個(gè)子部分，稱為傳輸時(shí)長(zhǎng)。由于通信是作為集合操作（或 P2P）的一部分進(jìn)行的，單個(gè)操作的追蹤時(shí)長(zhǎng)受兩個(gè)因素影響：（1）數(shù)據(jù)傳輸?shù)搅硪?Rank 所需的時(shí)間，即“傳輸時(shí)長(zhǎng)”；（2）等待同一集合操作（或 P2P）中其他操作開始的時(shí)間，即“阻塞時(shí)長(zhǎng)”。在這兩個(gè)因素中，“傳輸時(shí)長(zhǎng)”是集合操作固有的，而“阻塞時(shí)長(zhǎng)”則由操作調(diào)度決定。因此，在 OpDuration 張量中，作者僅為通信操作類型（如 Params-Sync、Forward-Send 等）存儲(chǔ)“傳輸時(shí)長(zhǎng)”。為了估算一個(gè)操作的“傳輸時(shí)長(zhǎng)”，作者取同一集合操作（或 P2P 操作）中所有對(duì)等操作的最大開始時(shí)間，并從該操作的結(jié)束時(shí)間中減去這一最大開始時(shí)間。

提取操作依賴關(guān)系。模擬器需要兩項(xiàng)輸入：理想化操作時(shí)長(zhǎng)與操作依賴模型。接下來，闡述模擬器的依賴模型，該模型源自當(dāng)前使用的基于 Megatron-LM 的訓(xùn)練系統(tǒng)。

在此依賴模型中，每個(gè) Worker 運(yùn)行若干“Stream”以執(zhí)行其操作。同一 Stream 上安排的所有操作按序執(zhí)行，而跨 Stream 的操作只要滿足依賴關(guān)系便可并發(fā)執(zhí)行。具體而言，每個(gè) Worker 擁有:

• 一個(gè)執(zhí)行全部 Forward 與 Backward 操作的 Stream
• 一個(gè)執(zhí)行所有 DP 專用通信操作的 Stream
• 四個(gè)各執(zhí)行不同類型 PP 專用通信操作的流：

Forward-recv（RF）

Backward-recv（RB）

Forward-send（SF）

Backward-send（SB）

各操作間的依賴關(guān)系如下圖 Figure 2 所示：

• 相同 Stream 的依賴關(guān)系：Stream 內(nèi)的操作根據(jù)其在追蹤記錄中的啟動(dòng)時(shí)間進(jìn)行排序。假設(shè)相鄰操作之間存在隱式依賴。
• DP 通信與計(jì)算依賴關(guān)系：在每個(gè) PP Stage：

首個(gè) Micro-Batch 的 Forward 操作需在完成對(duì)應(yīng)的 params-sync 集合通信（以獲取該 Stage 參數(shù)）之后進(jìn)行，如下圖 Figure 2 所示（Syncparams → CF, mid=1）。

這些參數(shù)會(huì)被本地緩存，供后續(xù) Micro-Batch 使用。不同 Micro-Batch 計(jì)算出的梯度會(huì)在本地累積，然后在 DP Rank 間進(jìn)行聚合。因此，最后一個(gè) Micro-Batch 的 Backward 應(yīng)在執(zhí)行 grads-sync 集體通信之前完成，以便跨 DP Rank 聚合該 PP Stage 的梯度，如下圖 Figure 2 所示（CB,mid=8 → Syncgrads）。

• PP 通信與計(jì)算依賴關(guān)系：

         除首個(gè) PP  Rank 外，任何一個(gè) Micro-Batch 在 PP Rank p 上的 Forward 與 Backward 操作，必須等待同一 GPU 上該 Micro-Batch 的 Forward-receive（RF） 與 Backward-receive（RB） 通信操作完成后才能啟動(dòng)，如下圖 Figure 2 所示（例如，RF,mid=1 → CF,mid=1，RB,mid=7 → CB,mid=7）。

          同理，除最后一個(gè) PP Rank 外，任何 Micro-Batch 在 PP Rank p 上的 Forward-send（SF） 與 Backward-send（SB） 操作，必須待同一 GPU 上該 Micro-Batch 的 Forward 與 Backward 操作結(jié)束后方可開始，如下圖 Figure 2 所示（例如，CF,mid=1 → SF,mid=1，CB,mid=7 → SB,mid=7）。

• 跨 Rank 通信依賴關(guān)系：對(duì)于給定的 Micro-Batch，其 DP 通信操作（即 params-sync 和 grads-sync）在所有具有相同 PP Rank 的 DP 進(jìn)程間形成一個(gè)集合通信組。同理，該 Micro-Batch 的 PP send 與 receive 操作則在相鄰的、具有相同 DP Rank 的 PP 進(jìn)程之間形成配對(duì)關(guān)系。此類集合（或 P2P）操作組的依賴模型規(guī)定，任一單獨(dú)操作的數(shù)據(jù)傳輸均需在所有操作啟動(dòng)后方能開始。

模擬一個(gè)替代 Timeline。根據(jù)依賴模型和理想時(shí)長(zhǎng)，可以通過以下規(guī)則模擬另一種執(zhí)行 Timeline：

• 模擬器在所有依賴操作完成后立即啟動(dòng)下一項(xiàng)操作。換言之，操作的開始時(shí)間為其依賴的上一個(gè)操作的最晚結(jié)束時(shí)間。
• 計(jì)算操作一經(jīng)啟動(dòng)即視為完成，其結(jié)束時(shí)間為開始時(shí)間 + OpDuration 中對(duì)應(yīng)的操作時(shí)長(zhǎng)。
• 對(duì)于每個(gè)通信操作，模擬器會(huì)等待同一集合通信組（或 P2P）中的所有對(duì)等操作都啟動(dòng)。操作的結(jié)束時(shí)間為該組中最晚啟動(dòng)時(shí)間 + OpDuration 中存儲(chǔ)的相應(yīng)“傳輸時(shí)長(zhǎng)”。

4.3 與 Straggler 相關(guān)的降速和 GPU 浪費(fèi)的指標(biāo)

模擬器可以估算在沒有 Straggler 干擾的替代 Timeline 的 JCT，那么應(yīng)該計(jì)算哪些指標(biāo)來量化 Straggler 的影響呢？作者用 Tideal 表示無 Straggler 的 JCT。為了考慮模擬過程中引入的誤差，也使用未修改的操作時(shí)長(zhǎng)對(duì)原始 Timeline 進(jìn)行模擬，并將得到的 JCT 記為 T。模擬誤差相對(duì)較小。此外，部分追蹤數(shù)據(jù)存在較大的模擬誤差，為了確保分析的準(zhǔn)確性，作者剔除了模擬誤差 >= 5% 的追蹤數(shù)據(jù)。為了量化與 Straggle 任務(wù)相關(guān)的性能下降程度，作者計(jì)算慢速指標(biāo) S，即比例：

除了與整體 Straggle 相關(guān)的性能下降外，還希望量化由不同類型操作中的 Straggle 導(dǎo)致的性能下降（如 Table  1）。為此，作者首先為每種操作類型 t 計(jì)算其操作類型降速值 St，具體方法如下：

其中，Tideal 是按上述方法計(jì)算出的理想 JCT，而 T?tideal 表示當(dāng)操作類型 t 的 OpDuration 中的元素未被固定時(shí)的 JCT。

在作者的集群中，一個(gè)作業(yè)在其整個(gè)運(yùn)行期間獨(dú)占 GPU 資源。因此，JCT 的增加（或下降）可以直接轉(zhuǎn)化為該作業(yè)所浪費(fèi)的 GPU 小時(shí)數(shù)。具體來說，通過以下公式估算作業(yè)的資源浪費(fèi)比例，即浪費(fèi)的 GPU 小時(shí)百分比：

同樣地，可以通過計(jì)算 1 ? 1/St 來估算因不同操作類型導(dǎo)致的資源浪費(fèi)情況。

五、Straggler 的影響

5.1 Straggler 普遍存在，并導(dǎo)致不可忽視的資源浪費(fèi)

如下圖 Figure 3 展示了所有作業(yè)中資源浪費(fèi)百分比的累積分布函數(shù)（CDF）?？梢钥闯觯粉櫟挠?xùn)練任務(wù)中，42.5% 存在 Straggler。更為嚴(yán)重的是，由于 Straggler 的存在，超過 10% 的作業(yè)至少浪費(fèi)了分配到的 GPU 時(shí)間的 21.3%，而約 1% 的作業(yè)浪費(fèi)了分配的 GPU 資源的 45% 以上。整體數(shù)據(jù)顯示，由于 Straggler，追蹤的所有作業(yè)中有 10.4% 的 GPU 時(shí)間被浪費(fèi)。

此外，作者還研究了那些執(zhí)行速度大幅下降（S > 3）的作業(yè)，發(fā)現(xiàn)這些均為大型作業(yè)，且問題往往源于不到 3% 的 Worker。在大多數(shù)情況下，速度緩慢的操作集中在計(jì)算環(huán)節(jié)，而非通信過程?；诖?，作者認(rèn)為服務(wù)器問題（可能是硬件故障或配置錯(cuò)誤）通常是導(dǎo)致這些問題的罪魁禍?zhǔn)住?/p>

5.2 Step 在落后任務(wù)中表現(xiàn)出類似的降速現(xiàn)象

接下來，作者探究了任務(wù)降速究竟是少數(shù)極慢步驟還是多數(shù)步驟共同作用。作者將顯著降速比 S  > 1.1 的任務(wù)定義為 Straggle 任務(wù)。為此，作者將單個(gè) Step 的降速比定義為該 Step 執(zhí)行時(shí)間與理想 Step 執(zhí)行時(shí)間（例如，Tideal/n 對(duì)應(yīng)含 n 個(gè)訓(xùn)練步驟的任務(wù)）之比。

如下圖 Figure 4 展示了經(jīng)過任務(wù)整體降速比歸一化后的單 Step 降速比 CDF。數(shù)據(jù)顯示，中位數(shù) Step 的歸一化降速比為 1.0，即使 90 分位 Step 的歸一化降速比也僅為 1.06。表明大多數(shù)步驟的降速程度與任務(wù)整體降速比相當(dāng)，說明 Straggle 現(xiàn)象并非由臨時(shí)環(huán)境因素導(dǎo)致，而是源于更持續(xù)性的問題。這一結(jié)果同時(shí)意味著，僅需采樣少量訓(xùn)練 Step 來分析 Straggle 任務(wù)就足以實(shí)現(xiàn)成本效益最大化。

5.3 哪些操作導(dǎo)致了 Straggle

如下圖 Figure 5 展示了追蹤數(shù)據(jù)中所有作業(yè)按操作類型劃分的資源浪費(fèi)比例。與 FALCON 的研究結(jié)論不同，作者發(fā)現(xiàn)多數(shù)減速源于計(jì)算操作而非通信環(huán)節(jié)。這得益于作者集群中充足的網(wǎng)絡(luò)帶寬、專用 LLM 訓(xùn)練集群的使用以及多項(xiàng)內(nèi)部網(wǎng)絡(luò)優(yōu)化與調(diào)參措施。

Figure 5 同時(shí)顯示，PP-level 通信的影響略高于 DP-level 通信操作。與預(yù)期相符，因?yàn)?DP-level 通信存在大量 Overlap，相比 PP-level 通信 Kernel（多發(fā)生于訓(xùn)練 Step 關(guān)鍵路徑上的預(yù)熱和冷卻階段）能容忍更多降速。

5.4 作業(yè)規(guī)模與 Straggle 有何關(guān)聯(lián)

令人驚訝的是，并未觀察到任務(wù)降速與任務(wù)規(guī)模之間存在明顯的正相關(guān)關(guān)系。這表明，任務(wù)規(guī)模并非導(dǎo)致滯后的決定性因素，而模型類型或人為因素等其他因素可能扮演著更為關(guān)鍵的角色。例如，超大規(guī)模任務(wù)通常由值班團(tuán)隊(duì)精心維護(hù)，并能比其他任務(wù)獲得更好的優(yōu)化，因此它們的降速情況未必比小型任務(wù)更糟。再比如，長(zhǎng)上下文任務(wù)更容易觀察到受到 Straggle 影響，但這些任務(wù)通常規(guī)模較小，當(dāng)與其他模型混合時(shí)，這種偏差反而使結(jié)果呈現(xiàn)出任務(wù)規(guī)模與降速之間的反向關(guān)聯(lián)。

六、根本原因

作者重點(diǎn)針對(duì)那些執(zhí)行速度明顯減慢的作業(yè)進(jìn)行研究，即速度降幅 S ≥ 1.1 的情況。由于確定作業(yè)降速的根本原因需手動(dòng)檢查，因此作者并沒有探究所有可能的成因，而是聚焦于常見誘因。

6.1 是否應(yīng)該歸因到個(gè)別 Worker

作者首先分析了有多少 Straggle 是由于 Worker 的硬件或軟件問題所致。由于作者執(zhí)行了健康檢查，預(yù)計(jì)僅有少數(shù)節(jié)點(diǎn)容易出現(xiàn)問題。因此，若某項(xiàng)任務(wù)因少數(shù) Worker 的問題導(dǎo)致降速，則修正這些問題 Worker 上的操作的執(zhí)行時(shí)間（將其設(shè)置為理想執(zhí)行時(shí)間），足以優(yōu)化整個(gè)任務(wù)的完成時(shí)間。

作者基于這一觀察來衡量問題 Worker 對(duì)落后任務(wù)的影響。采用與之前相同的方法，通過估算操作降速百分比來計(jì)算每個(gè) Worker 造成的降速，具體而言，定義 Worker w 的降速 Sw 為：

其中，T?wideal 是僅修復(fù)非 Worker w 上執(zhí)行的操作時(shí)的 JCT（由模擬器得出），而 Tideal 是所有操作均被修復(fù)時(shí)的 JCT。

接下來，針對(duì)每項(xiàng)任務(wù)，篩選出速度減慢程度 Sw 位居該任務(wù)前 3% 的 Worker 集合 W。若少數(shù) Worker 因硬件（或軟件）問題表現(xiàn)不佳，那么 W 將包含這些 Worker。隨后，計(jì)算這些 Worker 對(duì)任務(wù)整體降速所貢獻(xiàn)的比例 MW。

其中，T 代表模擬的原始 Step 時(shí)長(zhǎng)（未修正任何 Straggle），TWideal 為僅修正選定 Worker 上運(yùn)行的操作時(shí)的模擬 Step 時(shí)長(zhǎng)，而 Tideal 則是所有 Straggle 被修正后的理想模擬 Step 時(shí)長(zhǎng)。

對(duì)于大規(guī)模作業(yè)（涉及數(shù)千個(gè) Worker），計(jì)算 MW 成本很高，每個(gè) Worker w 需要運(yùn)行數(shù)千次模擬以計(jì)算 Sw。因此，作者采用一種近似方法來擴(kuò)展分析：不單獨(dú)計(jì)算各 Worker 的降速程度，而是測(cè)量整個(gè) DP Rank 和 PP Rank 的降速情況。隨后，為每個(gè) Worker 賦予其所屬 DP 和 PP Rank 中較小的（即最小的）降速值（任何 Worker 必屬于一個(gè) DP Rank 和一個(gè) PP Rank）。這一方法將所需模擬次數(shù)從 DP-Degree × PP-Degree 減少到 DP-Degree + PP-Degree，從而大幅降低計(jì)算復(fù)雜度。

如下圖 Figure 6 展示了 Straggle 作業(yè)的 MW CDF?？梢钥闯觯瑑H有 1.7% 的 Straggle 作業(yè)中，Worker 問題導(dǎo)致了超過 50% 的顯著時(shí)延。據(jù)此可以得出結(jié)論：在追蹤的數(shù)據(jù)中，問題 Worker 并非大多數(shù) Straggle 作業(yè)的主導(dǎo)因素。作者進(jìn)一步調(diào)查了少數(shù)由問題 Worker 主導(dǎo)作業(yè)降速的情況，發(fā)現(xiàn)這些情況造成的降速程度顯著更大：有問題 Worker 的作業(yè)降速比為 3.04，而平均降速比僅為 1.28。

6.2 PP Stage 不均衡

在作者的追蹤分析中，發(fā)現(xiàn) PP 最后一個(gè) Stage 相比其他 Stage 的計(jì)算不均衡問題是導(dǎo)致 Straggle 現(xiàn)象的常見原因。最后一個(gè) Stage 包含 LM Head，還有 Loss 計(jì)算，因此在模型切分時(shí)經(jīng)常無意間造成最后一個(gè) Stage 計(jì)算量突增的情況，進(jìn)而引發(fā)性能瓶頸。

為了驗(yàn)證損失層的耗時(shí)問題，作者運(yùn)行了一個(gè)包含 4 個(gè) PP Stage 的任務(wù)：前 3 個(gè) Stage 各 9 個(gè) Transformer Layer，最后一個(gè) Stage 額外多一個(gè)損失層（包括 LM Head）。最后一層的邏輯運(yùn)算耗時(shí)是普通 Transformer 層的 9 倍以上，導(dǎo)致最后一個(gè) Stage 的 Forward（Backward）速度比平均水平慢 2.07x（1.41x）。

采用與之前類似的量化方法，作者獲得一些觀測(cè)結(jié)果，如下圖 Figure 7 所示，展示了不同任務(wù)中 MS（最后一個(gè) PP Stage 的影響系數(shù)）的 CDF，可以看出，39.3% 的任務(wù)中主要降速（MS >= 0.5）源自最后一個(gè) PP Stage。

接下來，作者進(jìn)一步探討了能否緩解這一問題。采用與 LLaMA 3 類似的方法：給最后一個(gè) PP Stage 少分配 ε 個(gè)層數(shù)。然而，手動(dòng)調(diào)整 ε 值存在多重挑戰(zhàn)：

• 首先，劃分模型時(shí)，必須將完整的 Transformer 層分配給 PP Stage，限制了各 Stage 間的計(jì)算分配靈活性；
• 其次，當(dāng)詞表增大或最大序列長(zhǎng)度/隱藏層尺寸減小時(shí)，損失層耗時(shí)（相對(duì)于 Transformer 層）占比會(huì)上升。隨著詞表增加，這種現(xiàn)象將愈發(fā)普遍，這會(huì)導(dǎo)致需要在前置階段執(zhí)行更多 Transformer 層以平衡最后一個(gè) PP Stage 的耗時(shí)。如此一來，可用 PP Stage 數(shù)量受限，每個(gè) Virtual Stage 包含的層數(shù)超出理想值，制約了模型并行效率。因此，即便 ε 取值合理，仍可能導(dǎo)致性能未達(dá)最優(yōu)。

針對(duì)前述包含 9 個(gè) Transformer 層的任務(wù)，作者也嘗試手動(dòng)調(diào)整各 PP Stage 的層數(shù)分配，發(fā)現(xiàn)通過人工切分可獲得 9.9% 的加速效果。但即便經(jīng)過手動(dòng)調(diào)優(yōu)，各 Stage 計(jì)算負(fù)載仍不完全均衡 —— 例如調(diào)優(yōu)后最后一個(gè) PP Stage 的 Forward 計(jì)算耗時(shí)仍為其他 Stage 的 1.55x。

6.3 序列長(zhǎng)度不均衡

作者又進(jìn)一步分析了 Worker 速度慢、PP Stage 負(fù)載不均無法解釋的任務(wù)。深入研究發(fā)現(xiàn)，對(duì)于長(zhǎng)上下文任務(wù)，訓(xùn)練數(shù)據(jù)間序列長(zhǎng)度的差異是導(dǎo)致任務(wù)降速的重要原因。如下圖 Figure 10 展示了某個(gè)最大序列長(zhǎng)度為 32K 的訓(xùn)練任務(wù)的序列長(zhǎng)度分布情況，可以看出有比較明顯的長(zhǎng)尾現(xiàn)象：

序列長(zhǎng)度的差異之所以成為問題，主要是 SelfAttention 的算法復(fù)雜度呈二次方關(guān)系。在訓(xùn)練中通常會(huì)采用 Sample Packing 的方式盡可能降低序列不均導(dǎo)致的問題，但是 SelfAttention 部分的不均衡依然無法避免，比如一個(gè) 32K 序列的 SelfAttention 計(jì)算量是 32 個(gè) 1K 序列計(jì)算量的 32 倍（預(yù)訓(xùn)練階段通常也會(huì)采用 Sample Packing，但不會(huì)添加 Attention Mask，可以保障負(fù)載比較均衡，而長(zhǎng)度擴(kuò)展或 SFT 等階段會(huì)添加 Attention Mask，因此會(huì)存在這個(gè)問題）。

不同 Micro-Batch 間計(jì)算時(shí)間的差異會(huì)導(dǎo)致 PP Stage 出現(xiàn) Bubble，并使得 DP 的各個(gè) Worker 完成時(shí)間不同步，如下圖 Figure 8 所示，這兩種情況共同造成了 Straggle 問題。

上述分析基于計(jì)算時(shí)間與 O(Σsi2) 成正比的觀察。如下圖 Figure 9 中通過實(shí)驗(yàn)驗(yàn)證了這一假設(shè)：針對(duì)典型任務(wù)的前幾個(gè)訓(xùn)練 Step，繪制了每個(gè) Micro-Batch 的處理時(shí)長(zhǎng)與 Σsi2 的關(guān)系圖，結(jié)果證實(shí)二者確實(shí)存在正比關(guān)系。

接下來，作者量化了因序列長(zhǎng)度不平衡而導(dǎo)致作業(yè)降速的比例。由于追蹤數(shù)據(jù)未能提供足夠信息來修正序列長(zhǎng)度不平衡的問題，故無法沿用之前的度量標(biāo)準(zhǔn)。因此采用一種 Forward-Backward 相關(guān)性指標(biāo)來衡量序列長(zhǎng)度失衡引發(fā)的降速現(xiàn)象。該指標(biāo)基于以下觀察：若某 Micro-Batch 的 Forward 計(jì)算因序列長(zhǎng)度不均而變慢，則其 Backward 同樣會(huì)以相近程度放緩，且 Forward-Backward 計(jì)算時(shí)間應(yīng)存在關(guān)聯(lián)性。如下圖 Figure 11 展示了每個(gè) Straggle 作業(yè)（即 S ≥ 1.1 的作業(yè)）中某 PP Stage 的皮爾遜相關(guān)系數(shù)。經(jīng)驗(yàn)表明，相關(guān)系數(shù) ≥ 0.9 的作業(yè)極可能因序列長(zhǎng)度失衡而降速。以此閾值為界，發(fā)現(xiàn) 21.4% 的作業(yè)受到序列長(zhǎng)度不平衡影響，其平均降速程度達(dá) 1.34 倍。

此外，如下圖 Figure 12 中，作者分析了最大序列長(zhǎng)度的變化如何影響作業(yè)降速。隨著最大序列長(zhǎng)度的增長(zhǎng)，序列長(zhǎng)度不平衡的影響更為顯著。然而，上下文長(zhǎng)度也在不斷增加，因此解決這一可擴(kuò)展性挑戰(zhàn)變得愈發(fā)重要。

解決這一問題的思路也比較簡(jiǎn)單，因?yàn)橥ㄟ^序列長(zhǎng)度可以準(zhǔn)確預(yù)測(cè) Micro-Batch 的計(jì)算時(shí)間（如 Figure 9），因此可以在一個(gè) Global Batch 進(jìn)行數(shù)據(jù)的重排（數(shù)學(xué)等價(jià)），讓不同的 DP Rank 中的計(jì)算盡可能均衡，這一目標(biāo)可以通過貪心算法實(shí)現(xiàn)。在一個(gè)最大序列長(zhǎng)度為 32K 的典型任務(wù)上測(cè)試此方法后，觀察到吞吐量提升了 23.9%。

6.4 Python 自動(dòng)垃圾回收

Python 的垃圾回收（GC）是導(dǎo)致降速的另一個(gè)主要原因。集群中的任務(wù)都使用 Python 運(yùn)行，其 Runtime 在認(rèn)為必要時(shí)會(huì)觸發(fā) GC。一旦觸發(fā)，GC 可能耗費(fèi)數(shù)百毫秒，在此期間，用戶程序會(huì)被暫停，新 Kernel 無法啟動(dòng)，進(jìn)而阻塞 Forward 計(jì)算。需要注意的是，Backward 不受影響，因?yàn)樗鼈冇?C++ 發(fā)起。

由于不同 Python 進(jìn)程在不同時(shí)間觸發(fā) GC，該問題進(jìn)一步惡化，如下圖 Figure 13 所示，當(dāng) GC 暫停單個(gè) Worker 進(jìn)程時(shí)，整個(gè)訓(xùn)練作業(yè)都會(huì)阻塞，隨著 Worker 進(jìn)程數(shù)量的增加，此類暫停次數(shù)也隨之增加。因此，隨著模型規(guī)模的擴(kuò)大，由 GC 引發(fā)的 Straggle 愈發(fā)嚴(yán)重。

因此，作者工程團(tuán)隊(duì)實(shí)施了一項(xiàng)有計(jì)劃的 GC 優(yōu)化方案，旨在減少因 GC 導(dǎo)致的 Straggle 問題。該優(yōu)化措施關(guān)閉了 Python 的自動(dòng)垃圾回收機(jī)制，改為根據(jù)用戶設(shè)定的訓(xùn)練 Step 間隔手動(dòng)觸發(fā) GC，確保所有 Worker 同步執(zhí)行 GC。此措施顯著降低了 GC 相關(guān)的 Straggle：在使用 128 個(gè) DP Rank 的任務(wù)中，通過設(shè)定每 500 Step 執(zhí)行一次 GC，性能提升了 12.6%。

然而如何確定合適的 GC 間隔也很有挑戰(zhàn)，間隔過長(zhǎng)可能導(dǎo)致內(nèi)存耗盡而任務(wù)崩潰，間隔過短可能影響性能。由于不同任務(wù)的內(nèi)存分配速率不同，合適的 GC 與具體任務(wù)密切相關(guān)，因此作者默認(rèn)不開啟，而讓用戶自主選擇。

此外，作者還觀察到，隨著任務(wù)推進(jìn)，GC 導(dǎo)致的暫停時(shí)間會(huì)逐漸延長(zhǎng)，造成訓(xùn)練吞吐持續(xù)下降。推測(cè)原因是內(nèi)存泄露導(dǎo)致堆內(nèi)存持續(xù)增長(zhǎng)，進(jìn)而延長(zhǎng)了 GC 暫停時(shí)間。需要說明的是，計(jì)劃性 GC 能有效掩蓋此類泄露的影響，維持訓(xùn)練吞吐的穩(wěn)定。

6.5 其他根本原因

除了上述問題外，作者還探討了其他可能得原因：

• CUDA 內(nèi)存碎片化。偶發(fā)情況下，發(fā)現(xiàn)內(nèi)存碎片化會(huì)顯著拖慢 PyTorch 的 CUDA 內(nèi)存分配性能，致使 cudaFree 與 cudaMalloc 調(diào)用頻次激增，進(jìn)而造成 Forward 或 Backward 計(jì)算操作異常緩慢。在數(shù)據(jù)追蹤中，表現(xiàn)為同一 TP Group 內(nèi)不同 TP Rank 上運(yùn)行的通信 Kernel 啟動(dòng)時(shí)間參差不齊但卻近乎同時(shí)完成，暗示部分通信 Kernel 存在啟動(dòng)延遲。通過調(diào)取 PyTorch 運(yùn)行日志確認(rèn)相關(guān)任務(wù)確實(shí)頻繁調(diào)用內(nèi)存管理接口后，作者啟用了內(nèi)存分配器追蹤功能進(jìn)行復(fù)現(xiàn)測(cè)試。重跑過程中觀察到大量 segment_alloc 與 segment_free 調(diào)用，證實(shí) PyTorch 內(nèi)存分配器為癥結(jié)所在。
• 虛假 Kernel 依賴問題。在初期訓(xùn)練大型 MoE 模型時(shí)，發(fā)現(xiàn)用于梯度同步的 ReduceScatter Kernel 會(huì)阻塞其他無依賴關(guān)系的 Kernel 啟動(dòng)，導(dǎo)致任務(wù)嚴(yán)重降速。推測(cè)成因在于無關(guān) Kernel 共享同一 CUDA 硬件隊(duì)列引發(fā)的虛假依賴。實(shí)踐證明調(diào)高 CUDA_DEVICE_MAX_CONNECTIONS 參數(shù)可緩解此現(xiàn)象。但值得注意的是，該問題會(huì)隨模型框架迭代時(shí)隱時(shí)現(xiàn)，作者仍在持續(xù)探究其深層機(jī)制。

6.6 總結(jié)：觀察和啟發(fā)

基于之前的根因分析可以得到如下結(jié)論：

• 極少數(shù)的 Straggle 任務(wù)是機(jī)器問題（無論硬件還是軟件）引起，這意味著傳統(tǒng)的健康指標(biāo)不太可能有助于檢測(cè)或預(yù)防大多數(shù) Straggle 問題。
• 導(dǎo)致 Straggle 的最常見原因包括：PP Stage 分配不均、每個(gè) Micro-Batch 中序列長(zhǎng)度的不均衡，以及 Python GC 引起的暫停。
• 作者還發(fā)現(xiàn)兩種不太常見的 Straggle 原因：PyTorch 內(nèi)存碎片化和虛假內(nèi)存依賴。

七、在線檢測(cè) Straggler

作者還開發(fā)了一個(gè)名為 SMon 的 Online 服務(wù)。該服務(wù)在每次 NdTimeline 性能分析會(huì)話（記錄數(shù)十個(gè)訓(xùn)練 Step）后自動(dòng)運(yùn)行。SMon 能夠提供熱力圖來呈現(xiàn) Worker 節(jié)點(diǎn)的降速情況：

• 每個(gè)單元格表示一個(gè) Worker，其 x 和 y 軸對(duì)應(yīng) DP 和 PP 的 Rank，顏色深淺表示降速程度。
• 可以簡(jiǎn)化識(shí)別 Straggle Worker 的過長(zhǎng)；也可以幫助識(shí)別降速的根源。
• 如下圖 Figure 14 所示，Worker 問題、PP Stage 劃分不均衡以及序列長(zhǎng)度不均導(dǎo)致的降速展現(xiàn)出了各自獨(dú)特的模式。

八、參考鏈接

1. ??https://www.arxiv.org/abs/2505.05713??
2. ??https://github.com/ByteDance-Seed/StragglerAnalysis??
3. ??https://github.com/volcengine/veScale??

本文轉(zhuǎn)載自???????AI閑談???????，作者：AI閑談