案例驗證：分析NCCL-Tests運行日志優化Scale-Out網絡拓撲
背景：All-reduce 和 Ring 算法
GPU[并行計算]中需要大規模地在計算節點之間同步參數梯度，產生了大量的集合通信流量。為了優化集合通信性能，業界開發了不同的集合通信庫（xCCL），其核心都是實現 All-Reduce，這也是分布式訓練最主要的通信方式。
LLM訓練中的 All Reduce 操作一般分為三個步驟：
- 把每個節點的數據切分成N份;
- 通過reduce-scatter，讓每個節點都得到1/N的完整數據塊;
- 通過all-gather，讓所有節點的每個1/N數據塊都變得完整
基于這種流量模式，Ring算法是目前實現該操作最常見的基礎算法之一。
顧名思義，Ring算法構建了一個環形網絡——每個節點的數據會被切分成N份數據在所有GPU之間移動，且每個GPU只和相鄰的GPU通信。這種流水線模式能充分利用所有節點的發送和接收帶寬，減少 GPU 等待數據的空閑時間，同時也改善了傳輸[大數據]塊時的性能和時延抖動問題。（但對于小規模數據傳輸，Ring算法可能會表現出較高的延遲和低效。）
工具說明：NCCL-Tests
NVIDIA提供的NCCL是當前面向AI的集合通信事實標準，NCCL-Test 是 NVIDIA 開源的工具，我們可以在官方Github下載來進行不同算法的 性能測試 （例如：ring，trees…）。本次測試使用All reduce的ring算法來進行性能評估。
**代碼語言：**javascript
復制
root@bm-2204kzq:~# /usr/local/openmpi/bin/mpirun #多機集群測試需要使用MPI方式執行
--allow-run-as-root
-bind-to none #不將進程綁定到特定的CPU核心
-H 172.17.0.215:8,172.17.0.81:8 # host列表，:后指定每臺機器要用的GPU數量
-np 16 #指定要運行的進程數，等于總GPU數量
-x NCCL_SOCKET_NTHREADS=16
-mca btl_tcp_if_include bond0
-mca pml ^ucx -mca btl ^openib #指定BTL的value為'^openib'
-x NCCL_DEBUG=INFO #NCCL的調試級別為info
-x NCCL_IB_GID_INDEX=3
-x NCCL_IB_HCA=mlx5_0:1,mlx5_2:1,mlx5_3:1,mlx5_4:1
-x NCCL_SOCKET_IFNAME=bond0 #指定了 NCCL 使用的網絡接口
-x UCX_TLS=sm,ud #調整MPI使用的傳輸模式
-x LD_LIBRARY_PATH -x PATH
-x NCCL_IBEXT_DISABLE=1 #如使用RoCE網絡，此處應禁用
-x NCCL_ALGO=ring
/root/nccl-tests/build/all_reduce_perf -b 512 -e 18G -f 2 -g 1 #執行all reduce操作
NCCL-Tests常用參數及解釋
- GPU 數量
- -t,--nthreads 每個進程的線程數量配置， 默認 1；
- -g,--ngpus 每個線程的 GPU 數量，默認 1；
- 數據大小配置
- -b,--minbytes 開始的最小數據量，默認 32M；
- -e,--maxbytes 結束的最大數據量，默認 32M；
- 數據步長設置
- -i,--stepbytes 每次增加的數據量，默認: 1M；
- -f,--stepfactor 每次增加的倍數，默認禁用；
- NCCL 操作相關配置
- -o,--op 指定哪種操作為reduce，僅適用于Allreduce、Reduce或ReduceScatter等操作。默認值為：求和（Sum）；
- -d,--datatype 指定使用哪種數據類型，默認 : Float；
- 性能相關配置
- 測試相關配置
- -p,--parallel_init <0/1> 使用線程并行初始化 NCCL，默認: 0；
- -c,--check <0/1> 檢查結果的正確性。在大量GPU上可能會非常慢，默認：1；
- -z,--blocking <0/1> 使NCCL集合阻塞，即在每個集合之后讓CPU等待和同步，默認：0；
- -G,--cudagraph 將迭代作為CUDA圖形捕獲，然后重復指定的次數，默認：0；
案例驗證：優化GPU互連拓撲
下圖是一個未優化的雙機8卡(H20)組網測試拓撲：
按照一般CPU云數據中心的連接方式，將同服務器的網卡連接到一臺交換機上，兩臺交換機之間有4條400G鏈路相連。參與測試的為星融元（Asterfusion）交換機（CX732Q-N，32 x 400GE QSFP-DD, 2 x 10GE SFP+）。
NCCL-Test 性能測試結果
**代碼語言：**javascript
復制
# out-of-place in-place
# size count type redop root time algbw busbw #wrong time algbw busbw #wrong
# (B) (elements) (us) (GB/s) (GB/s) (us) (GB/s) (GB/s)
512 128 float sum -1 56.12 0.01 0.02 0 54.54 0.01 0.02 0
1024 256 float sum -1 55.09 0.02 0.03 0 53.85 0.02 0.04 0
2048 512 float sum -1 55.67 0.04 0.07 0 54.84 0.04 0.07 0
4096 1024 float sum -1 55.70 0.07 0.14 0 55.05 0.07 0.14 0
8192 2048 float sum -1 56.36 0.15 0.27 0 56.53 0.14 0.27 0
16384 4096 float sum -1 57.21 0.29 0.54 0 57.02 0.29 0.54 0
32768 8192 float sum -1 60.74 0.54 1.01 0 59.87 0.55 1.03 0
65536 16384 float sum -1 67.42 0.97 1.82 0 68.41 0.96 1.80 0
131072 32768 float sum -1 109.6 1.20 2.24 0 108.8 1.20 2.26 0
262144 65536 float sum -1 108.3 2.42 4.54 0 108.3 2.42 4.54 0
524288 131072 float sum -1 115.0 4.56 8.55 0 112.8 4.65 8.72 0
1048576 262144 float sum -1 135.0 7.77 14.57 0 129.4 8.10 15.19 0
2097152 524288 float sum -1 144.6 14.51 27.20 0 142.9 14.67 27.51 0
4194304 1048576 float sum -1 222.0 18.89 35.43 0 220.0 19.07 35.75 0
8388608 2097152 float sum -1 396.5 21.15 39.66 0 392.1 21.40 40.12 0
16777216 4194304 float sum -1 736.3 22.78 42.72 0 904.7 18.55 34.77 0
33554432 8388608 float sum -1 1405.5 23.87 44.76 0 1542.0 21.76 40.80 0
67108864 16777216 float sum -1 2679.0 25.05 46.97 0 2721.0 24.66 46.24 0
134217728 33554432 float sum -1 5490.1 24.45 45.84 0 5291.6 25.36 47.56 0
268435456 67108864 float sum -1 10436 25.72 48.23 0 11788 22.77 42.70 0
536870912 134217728 float sum -1 25853 20.77 38.94 0 23436 22.91 42.95 0
1073741824 268435456 float sum -1 47974 22.38 41.97 0 54979 19.53 36.62 0
2147483648 536870912 float sum -1 117645 18.25 34.23 0 117423 18.29 34.29 0
4294967296 1073741824 float sum -1 248208 17.30 32.44 0 229171 18.74 35.14 0
8589934592 2147483648 float sum -1 474132 18.12 33.97 0 476988 18.01 33.77 0
17179869184 4294967296 float sum -1 949191 18.10 33.94 0 965703 17.79 33.36 0
# Out of bounds values : 0 OK
- size (B)：操作處理的數據的大小，以字節為單位；
- count (elements)：操作處理的元素的數量；
- type：元素的數據類型；
- redo p：使用的歸約操作；
- root：-1 表示這個操作沒有根節點（all-reduce 操作涉及到所有的節點）；
- time (us)：操作的執行時間，以微秒為單位；
- algbw (GB/s)：算法帶寬，以 GB/s 為單位；
- busbw (GB/s)：總線帶寬，以 GB/s 為單位；
- wrong：錯誤的數量，如果這個值不是 0，那可能表示有一些錯誤發生。
查看結果時需要關注如下幾點：
- 數據量增加時，帶寬是否會下降（下降明顯不符合預期）；
- 帶寬的峰值，每次算到的帶寬峰值，可以只關注 in 或者 out；
- 平均值，在數據量遞增的情況下，可能無法體現最終的結果；
- 請確保數據量足夠大，可以壓到帶寬上限（通過調整 b、e 或者 n 選項）。
分析以上信息可以發現：平均總線帶寬僅22GB/s，在達到47GB/s左右的峰值流量后，隨著數據量越大帶寬性能卻在下降，與正常值相差甚遠。
機內拓撲分析
通過 nvidia-smi topo -m 可以得知機內設備拓撲
將上表轉化為如下示意圖：
NCCL通信路徑分析
NCCL中用Channel的概念表示一個通信路徑，在初始化的過程會自動感知拓撲并計算最佳的通信路徑。為了更好的利用帶寬和網卡實現并發通信，NCCL會使用多channel。NCCL-test運行日志里列出了16組channel如下：
**代碼語言：**javascript
復制
### ChannelNum:16
bm-2204kzq:252978:253054 [0] NCCL INFO Channel 00/16 : 0 7 5 6 4 3 1 2 8 15 13 14 12 11 9 10
bm-2204kzq:252978:253054 [0] NCCL INFO Channel 01/16 : 0 7 5 6 4 3 1 10 8 15 13 14 12 11 9 2
bm-2204kzq:252978:253054 [0] NCCL INFO Channel 02/16 : 0 7 5 6 12 11 9 10 8 15 13 14 4 3 1 2
bm-2204kzq:252978:253054 [0] NCCL INFO Channel 03/16 : 0 7 5 14 12 11 9 10 8 15 13 6 4 3 1 2
bm-2204kzq:252978:253054 [0] NCCL INFO Channel 04/16 : 0 7 5 6 4 3 1 2 8 15 13 14 12 11 9 10
bm-2204kzq:252978:253054 [0] NCCL INFO Channel 05/16 : 0 7 5 6 4 3 1 10 8 15 13 14 12 11 9 2
bm-2204kzq:252978:253054 [0] NCCL INFO Channel 06/16 : 0 7 5 6 12 11 9 10 8 15 13 14 4 3 1 2
bm-2204kzq:252978:253054 [0] NCCL INFO Channel 07/16 : 0 7 5 14 12 11 9 10 8 15 13 6 4 3 1 2
bm-2204kzq:252978:253054 [0] NCCL INFO Channel 08/16 : 0 7 5 6 4 3 1 2 8 15 13 14 12 11 9 10
bm-2204kzq:252978:253054 [0] NCCL INFO Channel 09/16 : 0 7 5 6 4 3 1 10 8 15 13 14 12 11 9 2
bm-2204kzq:252978:253054 [0] NCCL INFO Channel 10/16 : 0 7 5 6 12 11 9 10 8 15 13 14 4 3 1 2
bm-2204kzq:252978:253054 [0] NCCL INFO Channel 11/16 : 0 7 5 14 12 11 9 10 8 15 13 6 4 3 1 2
bm-2204kzq:252978:253054 [0] NCCL INFO Channel 12/16 : 0 7 5 6 4 3 1 2 8 15 13 14 12 11 9 10
bm-2204kzq:252978:253054 [0] NCCL INFO Channel 13/16 : 0 7 5 6 4 3 1 10 8 15 13 14 12 11 9 2
bm-2204kzq:252978:253054 [0] NCCL INFO Channel 14/16 : 0 7 5 6 12 11 9 10 8 15 13 14 4 3 1 2
bm-2204kzq:252978:253054 [0] NCCL INFO Channel 15/16 : 0 7 5 14 12 11 9 10 8 15 13 6 4 3 1 2
Device map 顯示 Rank #0-7、#8-15在同一服務器
**代碼語言：**javascript
復制
### Device maps
## GPU map
# Rank 0 Group 0 Pid 252978 on bm-2204kzq device 0 [0x0f] NVIDIA H20
# Rank 1 Group 0 Pid 252979 on bm-2204kzq device 1 [0x34] NVIDIA H20
# Rank 2 Group 0 Pid 252980 on bm-2204kzq device 2 [0x48] NVIDIA H20
# Rank 3 Group 0 Pid 252981 on bm-2204kzq device 3 [0x5a] NVIDIA H20
# Rank 4 Group 0 Pid 252982 on bm-2204kzq device 4 [0x87] NVIDIA H20
# Rank 5 Group 0 Pid 252983 on bm-2204kzq device 5 [0xae] NVIDIA H20
# Rank 6 Group 0 Pid 252984 on bm-2204kzq device 6 [0xc2] NVIDIA H20
# Rank 7 Group 0 Pid 252985 on bm-2204kzq device 7 [0xd7] NVIDIA H20
# Rank 8 Group 0 Pid 253834 on bm-2204qhn device 0 [0x0f] NVIDIA H20
# Rank 9 Group 0 Pid 253835 on bm-2204qhn device 1 [0x34] NVIDIA H20
# Rank 10 Group 0 Pid 253836 on bm-2204qhn device 2 [0x48] NVIDIA H20
# Rank 11 Group 0 Pid 253837 on bm-2204qhn device 3 [0x5a] NVIDIA H20
# Rank 12 Group 0 Pid 253838 on bm-2204qhn device 4 [0x87] NVIDIA H20
# Rank 13 Group 0 Pid 253839 on bm-2204qhn device 5 [0xae] NVIDIA H20
# Rank 14 Group 0 Pid 253840 on bm-2204qhn device 6 [0xc2] NVIDIA H20
# Rank 15 Group 0 Pid 253841 on bm-2204qhn device 7 [0xd7] NVIDIA H20
結合每個channel的具體路徑信息（詳見文末），在所有16條channel下的機間流量僅有以下8種固定的rank組合：10-0、2-8、1-10、9-2、6-12、14-4、5-14、13-6，對應的，產生通信的網卡有且僅有：
**代碼語言：**javascript
復制
優化前性能不佳的原因是: 所有跨節點的并行流量都需跨交換機在四條互聯鏈路上[負載均衡]，而現有的ECMP負載均衡對大流不夠友好，形成了性能瓶頸。
所以在設計Scale-out網絡拓撲的時候，我們應讓集群內所有同軌道的網卡連接在一臺交換機上，使集群性能達到最優。
按此方式調整后，測得單機四卡模式跨RoCE交換機（CX732Q-N）的總線帶寬與網卡直連數值相近，約195GB/s。
更多內容請參考：
https://asterfusion.com/
https://mp.weixin.qq.com/s/HHCxpaidUfAZwH6G6PwmKg
審核編輯 黃宇
聲明：本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人，不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用，如有內容侵權或者其他違規問題，請聯系本站處理。
舉報投訴
-
網絡
+關注
關注
14文章
7600瀏覽量
89257 -
AI
+關注
關注
87文章
31536瀏覽量
270348 -
SCALE
+關注
關注
3文章
14瀏覽量
14083
發布評論請先 登錄
相關推薦
請問，多個while循環該怎么做運行日志呢？
1個while循環里面的事件好像可以用移位寄存器做個運行日志可是多個while循環應該怎么把里面的發生的事件穿插到整個程序的運行日志中呢？
發表于 09-18 09:18
如何去實現嵌入式linux設備中應用運行日志呢
嵌入式linux設備中應用運行日志的實現最近在做一個項目時,需要記錄設備運行中情況,以方便對故障進行跟蹤定位,完善.所以決定采用記錄程序運行日志,經過在網上搜索,采用Log4cplus+BOA方案
發表于 11-04 08:24
車載網絡FlexRay拓撲結構的優化
車載網絡FlexRay 拓撲結構的優化 網絡拓撲結構對于汽車安全系統有著重要的影響。該文從新型FlexRay 線控剎車
發表于 10-24 14:57
?36次下載
芯片驗證分析及測試流程優化技術
以失效分析的數據作為基本數據結構，提出了測試項目有效性和測試項目耗費時間的折中作為啟發信息的優化算法，提出了 芯片驗證 分析及測試流程優化技
發表于 06-29 17:58
?97次下載
對于大規模系統日志的日志模式提煉算法的優化
LARGE框架是部署在中國科學院超級計算環境中的日志分析系統，通過日志收集、集中分析、結果反饋等步驟對環境中的各種日志文件進行監控和
發表于 11-21 14:54
?7次下載
基于互惠能力的對等網絡拓撲優化算法
。它從節點自身能力和外部環境因素兩個方面來計算節點的互惠能力，在此基礎上對非結構化對等網絡的拓撲結構進行優化。分析與實驗結果表明，該拓撲
發表于 11-29 17:27
?0次下載
基于Hadoop與聚類分析的網絡日志分析模型
針對海量web日志數據在存儲和計算方面存在的問題，結合當前的大數據技術，提出一種基于Hadoop與聚類分析的網絡日志分析模型。利用Hadoop中的MapReduce編程模型對海量Web
發表于 12-07 15:40
?0次下載
人類互作網絡拓撲模塊分析
鑒于網絡醫學中尚未有對疾病分類與功能蛋白模塊功能同質性分析之間關系的研究，展開以下研究工作：首先，利用Mesh、String9等數據庫中的數據構建了基因關系網絡；其次，采用基于優化模塊
發表于 12-13 16:11
?11次下載
無線傳感器網絡簇級拓撲模型的演化分析研究資料
網絡簇級拓撲演化模型;拓撲動態分析表明，該模型能夠很好地體現無線傳感器簇間的拓撲生長過程，由該模型演化成的無線
發表于 11-29 14:29
?9次下載
嵌入式linux設備中應用運行日志的實現
嵌入式linux設備中應用運行日志的實現? ? ? 最近在做一個項目時,需要記錄設備運行中情況,以方便對故障進行跟蹤定位,完善.所以決定采用記錄程序運行日志,經過在網上搜索,采用
發表于 11-01 17:22
?8次下載
使用NCCL 2.12將所有all2all性能翻倍
NCCL 2.12 版本顯著提高了所有 2 所有通信集體性能。 Download 最新的 NCCL 版本，并親身體驗改進后的性能。
針對大量log日志快速定位錯誤地方
查看服務器、應用運行日志，這是每個程序員必備的工作技能，因為，日志是最好的查找出錯問題在哪的途徑。如果當服務器爆了，你卻連如何定位錯誤都不知道？
ZnGeP2的本征缺陷計算之PREPARE模塊運行流程
新建目錄ZnGeP2，在./ZnGeP2/目錄內同時準備好以上的POSCAR文件與 dasp.in 文件，執行 dasp 1 ，即可啟動PREPARE模塊，此后無需額外操作。DASP會輸出 1prepare.out 文件記錄程序的運行日志。
ZnGeP2的本征缺陷計算之DEC模塊運行流程
確認TSC模塊完成后，回到ZnGeP2目錄，使用命令 dasp 3 執行DEC模塊。DEC模塊會在第一步已經生成的dec目錄中繼續輸出相關文件，包括缺陷結構，缺陷計算目錄，以及運行日志文件 3dec.out 。等待程序完成期間無需額外操作。
工商網監
評論