導言——AI 大模型以其優異的自然語言了解能力、跨媒體處理能力以及逐漸走向通用 AI 的潛力成為近年 AI 領域的熱門方向。業内頭部廠商近期推出的大模型的參數量規模都達到了萬億、10 萬億級别。
前幾天橫空出世的 AI 爆款産品 ChatGPT，可以聊天、寫代碼、解答難題、寫小說，其技術底座正是基于微調後的 GPT3.5 大模型，參數量多達 1750 億個。據報道，GPT3.5 的訓練使用了微軟專門建設的 AI 計算系統，由 1 萬個 V100 GPU 組成的高性能網絡叢集，總算力消耗約 3640 PF-days (即假如每秒計算一千萬億次，需要計算 3640 天)。
圖 1. ChatGPT 的 AI 内容生成
如此大規模、長時間的 GPU 叢集訓練任務，對網絡互聯底座的性能、可靠性、成本等各方面都提出極緻要求。對此，追求極緻高性能與高可用的星脈高性能計算網絡面世了。
在最新的自然語言了解任務榜單 CLUE 上，騰訊首個低成本、可落地的 NLP 萬億大模型訓練斬獲總榜、分類榜和閱讀了解榜三個榜首，其在訓練速度以及訓練精度上全面超越傳統算力叢集，甚至超過人類水準。而在金榜題名的背後，星脈高性能計算網絡為騰訊萬億大模型構築了高性能網絡底座。
圖 2. 自然語言了解任務榜 CLUE
星脈網絡在極緻高性能上，采用 1.6T 超帶寬接入、多軌道聚合流量網絡架構、異構網絡自适應通信優化技術、定制加速通信庫，建構了 1.6T ETH RDMA 網絡，實作了 AI 大模型通信性能的 10 倍提升，GPU 使用率 40% 提升，通信時延降低 40%，單叢集規模達到 2K（最大規模 32K），基于全自研網絡硬體平台網絡建設成本降低 30%，模型訓練成本節省 30%~60%。在高可用保障上，通過全自動化部署配置核查，覆寫伺服器 NUMA、PCIE、NVSwitch、NCCL、網卡、交換機數百個配置項，并通過實時 Service Telemetry 技術監控業務系統運作效率，保障大規模叢集部署，實作性能實時監控與故障告警。
圖3. 星脈高性能計算網絡
1 AI 時代下的網絡訴求：極緻網絡
網絡性能決定 GPU 叢集算力
根據阿姆達爾定律，串行通信決定了并行系統整體運作效率，并行系統節點數越多，其通信占比越高，通信對整體系統運作效率的影響越大。
在大模型訓練任務場景，動辄需要幾百甚至幾千張 GPU 卡的算力，伺服器節點多、跨伺服器通信需求巨大，使得網絡帶寬性能成為 GPU 叢集系統的瓶頸。
特别是 MoE（混合專家系統）在大模型架構中的廣泛應用，由于其稀疏門控特性建構在 All-to-All 通信模式之上，會随叢集規模的增長對網絡性能提出極高要求。業界近期針對 All-to-All 的優化政策，都是極緻利用網絡提供的大帶寬來縮短通信耗時，進而提升 MoE 模型的訓練速度。
圖 4. MoE 模型引入 All-to-All 集合通信操作
Lepikhin, Dmitry, et al. "Gshard: Scaling giant models with conditional computation and automatic sharding." arXiv preprint arXiv:2006.16668 (2020).
網絡可用性決定 GPU 叢集算力穩定性
GPU 叢集規模達到一定量級後，如何保障叢集系統的穩定性，是除了性能外必須面對的另一個挑戰。網絡的可用性，決定了整個叢集的計算穩定性，這是由于：
1）網絡故障域大：相比單點 GPU 故障隻影響叢集算力的千分之幾，網絡故障會影響數十個甚至更多 GPU 的連通性，隻有網絡穩定才能維持系統算力的完整性。
2）網絡性能波動影響大：相比單個低性能 GPU 或伺服器容易被隔離，網絡作為叢集共享資源，性能波動會導緻所有計算資源的使用率都受影響。
是以在大模型任務訓練的整個周期中（數天、數周），維持網絡的穩定高效，是 GPU 訓練叢集在工程化實踐中極其重要的目标，對網絡運維帶來新的挑戰。
圖 5. 網絡故障 / 性能對叢集算力影響大
2 創造高性能——AI 訓練叢集下的極緻性能網絡
面對千億、萬億參數規模的大模型訓練，僅僅是單次計算疊代内梯度同步需要的通信量就達到了百 GB 量級，此外還有各種并行模式、加速架構引入的通信需求，使得傳統低速網絡的帶寬遠遠無法支撐 GPU 叢集的高效計算。是以要充分發揮 GPU 計算資源的強大算力，必須建構一個全新的高性能網絡底座，用高速網絡的大帶寬來助推整個叢集計算的高效率。面向 AI 大模型訓練需求，騰訊推出了業界領先的高性能計算網絡架構——星脈：采用 1.6T 超帶寬接入、多軌道聚合流量網絡架構、異構網絡自适應通信、定制加速通信庫，建構了 1.6T ETH RDMA 高性能網絡。
超帶寬計算節點
AI 大模型訓練是一種帶寬敏感的計算業務，騰訊星脈網絡為每個計算節點提供 1.6T 的超高通信帶寬，帶來 10 倍以上的通信性能提升。
星脈網絡主要特點有：采用無阻塞 Fat-Tree 拓撲，單叢集規模支援 2K GPU，超 EFLOPS（FP16）的叢集算力；可靈活擴充網絡規模，最大支援 32K GPU 計算叢集；計算網絡平面配備 8 張 RoCE 網卡，提供 1.6Tbps 的超高帶寬接入。
圖 6. 星脈組網架構
圖 7. 集合通信性能理論模組化
上圖從理論上展示了 1.6Tbps 帶寬與 100Gbps 帶寬的集合通信性能對比。可以看到，對于 AllReduce 和 All-to-All 這兩種典型通信模式，在不同叢集規模下，1.6Tbps 超帶寬都會帶來 10 倍以上的通信性能提升。
圖 8. GPT3 模型訓練性能
上圖是對 GPT3 模型的實測性能資料，主要通信模式是 AllReduce。以 64 GPU 規模為例，由于 1.6Tbps 超帶寬網絡将 AllReduce 的耗時大幅縮短 14 倍，将通信占比從 35% 減少到 3.7%，最終使得單次疊代的訓練耗時減少 32%。從叢集算力的角度，相當于用同樣的計算資源，超帶寬網絡能将系統算力提升 48%。
圖 9. T5-MoE 模型訓練性能
上圖是對 T5-MoE 模型的實測性能資料，主要通信模式是 All-to-All。同樣可以看到，在 64 GPU 模型下，1.6Tbps 帶寬下的單次疊代訓練耗時降低 64%。從叢集算力的角度，相當于用同樣的計算資源，超帶寬網絡能将系統算力提升 2.8 倍。
多軌道流量聚合架構
除了超帶寬計算節點，星脈網絡對通信流量做了基于多軌道的流量親和性規劃，使得叢集通信效率達 80% 以上。
多軌道流量聚合架構将不同伺服器上位于相同位置的網卡，都歸屬于同一 ToR switch；不同位置的網卡，歸屬于不同的 ToR switch。由于每個伺服器有 8 張計算平面網卡，這樣整個計算網絡平面從實體上劃分為 8 個獨立并行的軌道平面，如下圖所示（不同顔色代表不同的軌道）。
圖 10. 多軌道流量聚合架構
在多軌道網絡架構中，AI 訓練産生的通信需求（AllReduce、All-to-All 等）可以用多個軌道并行傳輸加速，并且大部分流量都聚合在軌道内傳輸（隻經過一級 ToR switch），小部分流量才會跨軌道傳輸（需要經過二級 switch），大幅減輕了大規模下的網絡通信壓力。
圖 11. 集合通信效率
從上圖實測的集合通信性能可以看出，在不同網絡規模下，AllReduce 與 All-to-All 始終能維持較高的集合通信效率。
異構網絡自适應通信
大規模 AI 訓練叢集架構中，GPU 之間的通信實際上由多種形式的網絡來承載的：機間網絡（網卡 + 交換機）與機内網絡（NVLink/NVSwitch 網絡、PCIe 總線網絡）。星脈網絡将機間、機内兩種網絡同時利用起來，達成異構網絡之間的聯合通信優化，使大規模 All-to-All 通信在業務典型 message size 下的傳輸性能提升達 30%。
圖 12. 異構網絡自适應通信
上圖展示了 All-to-All 集合通信如何利用異構網絡來優化。當機間、機内網絡同時使能時（右圖）：不同 host 上相同位置的 GPU 仍然走機間網絡通信；但是要去往不同位置的 GPU（比如 host1 上的 GPU1 需要向其他 host 上的 GPU8 發送資料），則先通過機内網絡轉發到對應位置的 GPU 代理上，然後通過該 GPU 代理走機間網絡來完成通信。
異構網絡通信帶來的優勢有兩點：1）異構網絡通信使得機間網絡的流量數目大幅減少；2）異構網絡通信使機間網絡的流量大部分都聚合在軌道内傳輸（隻經過一級 ToR switch）。異構網絡通過将小流聚合為大流的方式來減少流量的數目，減少對機間網絡的沖擊（RDMA QP 數量、擁塞控制、微突發等），進而提升整網的傳輸性能。
圖 13. 異構網絡自适應通信提升 All-to-All 性能
從上圖的實測資料可以看出，異構網絡通信在大規模 All-to-All 場景下對中小 message size 的傳輸性能提升在 30% 左右。
定制加速通信庫
騰訊高性能集合通信庫 TCCL（Tencent Collective Communication Library）定制适配星脈網絡硬體平台，在 AllReduce/AllGather/ReduceScatter 等常用通信模式下帶來 40% 的性能加速。
星脈網絡基于 1.6Tbps ETH RDMA 網絡定制，從網絡性能、建設成本、裝置供應、網絡可靠性等多方面綜合考慮，大量部署了 2*100Gbps 的單網卡硬體。從伺服器角度上看，需要管理、配置 8 張 2*100G 的網卡；從網絡架構角度上看，每張網卡需要上聯兩個 LA/ToR switch 來保證帶寬與可靠性。組網架構圖如下所示。
圖 14. 2*100G 網卡雙端口動态聚合組網架構
面對定制設計的高性能組網架構，業界開源的 GPU 集合通信庫（比如 NCCL）并不能将網絡的通信性能發揮到極緻，進而影響大模型訓練的叢集效率。為解決星脈網絡的适配問題，我們基于 NCCL 開發了高性能集合通信庫 TCCL，在網卡裝置管理、全局網絡路由、拓撲感覺親和性排程、網絡故障自動告警等方面融入了定制設計的解決方案。
圖 15. TCCL 集合通信性能
從上圖實測的集合通信性能可以看出，在 AllReduce/AllGather/ReduceScatter 等常用通信模式下，針對星脈網絡定制的 TCCL 都會帶來 40% 左右的通信性能提升。
3 駕馭高性能——最大以太 RDMA 網絡的工程實踐
一匹馬再快，若桀骜不馴，也難以稱之為“良駒”。
為了駕馭高性能，我們先是實作了端網部署一體化以及一鍵故障定位，提升高性能網絡的易用性，進而通過精細化監控與自愈手段，提升可用性，為極緻性能的星脈網絡提供全方位營運保障。
端網部署一體化
衆所周知，RDMA 為業務帶來了大帶寬低延遲時間，但同時其複雜多樣化的配置也往往被網絡營運人員诟病，因為一套錯誤的配置往往影響業務性能，還有可能會帶來很多的不符合預期的問題。在星脈網絡之前，據統計 90% 的高性能網絡故障 case 均是配置錯誤導緻的問題。出現這一問題的主要原因就是網卡配置套餐多，取決于架構版本，業務類型和網卡類型。在高性能網絡營運平台提供的端網一體部署能力下，大模型訓練系統的整體部署時間從 19 天縮減到 4.5 天，并保證了基礎配置 100% 準确。
圖 16. 高性能網絡自動化部署
對此，我們先是實作了基礎網絡自動部署流程，整個自動部署的架構主要具備三方面的特點，第一是通過 API 提供單台 / 多台并行部署的能力。第二是在部署前，我們提供預校驗的功能，一個是檢查需要部署的機器上聯交換機是否也配置了合理的擁塞控制相關配置，否則會影響到 RDMA 使用的性能。并将結果回報給到使用者。
最後是自動選擇配置模闆，我們會識别影響網卡配置模闆的因素，包括架構版本，業務類型以及網卡類型，例如不同的網卡類型，配置的指令不同，選擇的模闆也不同。但這個流程對于使用者側是完全透明的。
圖 17. 高性能網絡自動化驗收
在網絡與端側的基礎配置完成後，為了保證傳遞品質，營運平台會做進一步的自動化驗收，其中包含：
1）端網基礎環境校驗：通過端網狀态資料以及周邊建設系統的資訊采集，在硬體上判斷 PCIe，光子產品，連線等是否正确。在軟體上通過配置審計校驗端網配置是否正确。
2）RDMA 基礎測試：通過運作 Perftest，并進行資料采集分析，判斷網卡性能是否達到預期。
3）通信庫性能測試：通過運作 NCCL/TCCL test，并進行資料采集分析，判斷集合通信性能是否達到預期。
4）模型 & 可靠性測試：運作典型模型訓練，判斷業務模型性能是否達到預期；通過設計端側故障模拟、網絡内故障模拟以及交換機配置錯誤等三類故障來判斷業務可用性是否達到預期。
以上四個步驟全部通過後正式轉為傳遞狀态，否則會關聯自動故障定位手段進行相關排查。
全棧巡檢，一鍵故障定位
回顧過往，網絡營運在伺服器與交換機之間形成了分界線。然後在端網協同的高性能網絡下，不僅僅需要考慮傳統交換機上的問題定位，更要結合端側“網卡，中間件等”的狀态資料綜合判斷。在端側能力具備的條件下，困擾了網絡營運人員多年的問題“是否出現在網絡交換機上”迎刃而解。同時也随着端側營運能力的加強，針對不同的營運使用者，自動排障的工具集也将多樣化。
例如“一機八卡”的複雜拓撲下，連線與網段配置的正确率直接影響到應用是否能夠成功建立，對此，我們通過封裝交換機與伺服器狀态資料，關聯網管拓撲資訊，做到快速診斷與自動化檢查。一方面在網絡傳遞時屏蔽問題，另一方面快速定位營運中的網絡挪線等操作帶來的通信問題。
除了軟體相關問題外，硬體故障也一樣逃不出高網營運平台的法眼，例如在驗收中發現部分網卡 8QP 帶寬最多隻能跑到 50Gbps 左右。通過故障池的沉澱，一鍵自動檢測出 PCIE 帶寬協商出錯，定界為硬體故障，并自動推送到伺服器營運相關人員進行網卡硬體更換。
圖 18. 高性能網絡自動排障
高性能網絡一鍵故障定位提供了兩方面的功能，一方面可以快速定界問題所向，精準推送到對應團隊的營運人員（網絡 or 業務），減少團隊之間的溝通成本，劃分責任界限。另一方面可以一鍵快速定位問題根因，并給出解決手段。
整體系統具備階層化多元度的特征，通過端側伺服器以及交換機上的各種計數，向上邏輯封裝抽象為子功能，例如帶寬校驗 & 丢包校驗等。之後繼續向上邏輯封裝，形成定位與定界的場景，底層複雜的技術與邏輯徹底透明化，自下而上，最終呈現到使用者的隻有簡單易用的場景按鈕。目前高性能網絡營運平台已支援“性能不足”、“業務丢包”、“配置異常”、“連接配接建立不成功”四個次元的一鍵故障定位，優雅地為高性能網絡業務提供一鍵自檢，健康可視等功能。
業務無感秒級網絡自愈
一些網絡故障（例如靜默丢包）的發生是不可被預期的，在網絡故障演練時發現，一些網絡故障（例如靜默丢包）發生後通信庫就會出現逾時，導緻訓練業務程序長時間卡死，雖然可以依靠拉起定期的儲存的 checkpoint，但是也需要回退版本，損失精度，且整個過程需要幾十分鐘來加載和推送參數等。此前我們通過網絡上的各種探測手段，或是基于探針，或是基于裝置狀态，加上控制器路由隔離手段，将故障自愈時間控制在 20s 以内。然而在面對高性能業務的秒級自愈要求下，我們轉變了避障思路，需求起源于業務，那麼為何不把避障的主動權交于業務呢？為了讓極緻性能恒久，我們推出了秒級故障自愈産品——“HASH DODGING”。
我們創造性地提出基于 Hash 偏移算法的網絡相對路徑控制方法。即，終端僅需修改資料標頭特定字段（如 IP 頭 TOS 字段）的值，即可使得修改後的包傳輸路徑與修改前路徑無公共節點。該方案可在網絡資料平面發生故障（如靜默丢包、路由黑洞）時幫助 TCP 快速繞過故障點，不會産生對标準拓撲及特定源端口号的依賴。也可用于保證多路徑協定（如 MPTCP）中各子流均勻負載到不同網絡節點，避免性能退化。
圖 19. 單路徑傳輸協定使用本方案實作确定性換路
通過端網協同，我們先是在端側實作了協定棧層面的 TCP&RDMA 狀态檢測，通過核心擷取協定棧狀态資訊。進而細粒度的獲得業務流吞吐、丢包等資訊，将故障發現降低到 600ms 以内。其次在故障換路上，相對于更換五元組改變 hash 結果的不确定性，我們在自研交換機上實作了基于 HASH 偏移的确定性換路特性，業務可以通過更換魔術字來確定 100% 更換到其餘路徑上。當發生靜默丢包時，端側無需依賴于網絡，自身快速秒級内避障。
4 結語
未來随着 GPU 算力的持續提升，GPU 叢集網絡架構也需要不斷疊代更新，才能保證系統算力的高使用率與高可用性。星脈高性能計算網絡作為騰訊大規模訓練叢集的重要基石，會持續在超帶寬、異構網絡通信、通信庫定制加速、智能監控等技術上不斷創新，為 AI 大模型訓練構築可靠的高性能網絡底座。
· E小萌 ·
添加小助手微信