聽說，現在已經有人在搞十萬卡集群了！

什么概念呢？100000張GPU或者AI加速卡攢在一起，組團干活，提供“核彈級”算力。

這么頂，真有必要嗎？必須有，業界大佬都在這么干！

只因AGI太火爆，引發了算力“軍備競賽”，十萬卡集群已經成為業界頂尖大模型公司的標配，xAI、Meta、OpenAI都在搞！

即便大家如此激進，算力瓶頸仍然拖了大模型迭代的后腿。

坊間傳聞，GPT5遲遲不能發布的原因之一，就是算力不足。

而國內的頭部大模型廠商，也都在互相較勁，緊鑼密鼓地籌建十萬卡集群…

總之，趨勢在那里擺著，算力基礎設施必須要跟上，“不搞就會落后，落后就要挨揍”！

“十萬卡”集群，有多難搞？

首先，你懂的，家里確實要有礦！

一臺8卡服務器，十萬卡就是12500臺服務器，這就是250億了。

所以，十萬卡集群，都是巨頭或者拿到巨額投資的公司在搞。

但是，對于國內企業來說，光“家里有礦”還不夠，第一道技術坎就把大家卡住了。

這道坎就是：十萬卡規模的智算中心，必須要跨地域部署。

為什么要把一個好好的數據中心拆散，讓他們跨地域呢？

首先，十萬卡集群，是妥妥的超級電老虎，一天的耗電量，高達300萬度，相當于北京東城區居民一天的電量。

單一物理數據中心，很難滿足這種用電需求。

同時，這樣的超標電老虎，會對所在區域的電網造成沖擊，超出電網的配電限制。

不止如此，十萬張卡，光服務器機房的面積就超過10萬平方米。

相當于14個足球場那么大，這還不包括其他數據中心配套設施，不做特殊規劃，根本放不下。

所以，能耗和空間的制約，讓這種超標集群，不得不跨樓、跨園區部署，考慮到電力供給，甚至要跨城市組網。

大家都知道，在單個物理數據中心操控調度海量算力卡，就已經很難了，要考慮傳輸性能、穩定性、故障恢復、各種并行策略等等。

一旦跨了地域，難度更是飆升了無數倍↓

比如，受電力、配網、空間等限制，在實際部署中，集群不得不分布在兩個相距100KM的數據中心…

但IB和RoCE等無損網絡的原始設計，就不是為這樣的跨地域、超長距、高延遲場景服務的，它們受不了這種“沒苦硬吃”的工作。

以前，在單一數據中心內部，網絡鏈路的設計通常都是按照1:1收斂的，全網無阻塞，所有GPU流量不沖突，滿足訓練時各種并行策略對帶寬和時延的要求。

現在，跨地域部署之后，兩個數據中心間互聯帶寬，充其量也就幾百個T，看著不少，攤到每個節點、每塊GPU，那就是獨木橋。

有效帶寬容量差了幾十上百倍，調度稍有不慎，就會“塞車”。

這100公里的距離，會帶來額外500μs的延遲，相當于數據中心本地網絡的100倍（約5μs）。

IB/RoCE的網卡、交換機、重傳機制、擁塞控制機制都是按照10μs級別時延來設計的，面對500μs這種超綱問題，結果完全不可控。

而且，模型并行算法，在常規設計中也只考慮了網絡低時延、帶寬最大化的場景，這種長距的高延遲甚至都超過了一次矩陣計算的時間。

距離產生美，也產生了麻煩。

很難想象吧，這點距離，幾乎成了國內十萬卡集群無法跨越的鴻溝，簡直Mission Impossible了。

跨地域“十萬卡”，有人搞定了

真的要一別兩寬嗎？不！

最新消息，百度百舸團隊給出了自己的解決方案，讓跨地域構建“十萬卡集群”成為可能。

百度百舸具體是怎么干的呢？

一、先夯實基本功，把本地萬卡+集群玩到飛起，儲備跨地域組網能力。

?網絡性能升級

本地大規模集群都搞不好的話，想搞跨地域那就是空談，百度智能云在原有萬卡集群網絡的基礎上，對自研網絡交換機進行升級。

升級后，整張高性能網絡具備了更為智能的動態負載均衡能力，徹底消除哈希沖突和網絡擁塞。

即便面對十萬卡產生的海量數據沖擊，也可以輕松應對，提供無阻塞、低延遲轉發。

?平滑可擴展的架構設計

十萬卡并非一蹴而就，即便本地數據中心五萬張卡，那也可能是從千卡、萬卡、兩萬卡…逐步升級起來的。

百度高性能網絡在架構設計上，支持Pod級別的按需平滑擴容，建好的部分，可以立即投入使用，建一批投產一批，工期時間短，擴容無壓力。

?提升整體穩定性

十萬卡集群相比萬卡集群，在設備故障率不變的情況下，訓練任務故障率會極速增長，這將給系統穩定性帶來極大挑戰。

百度百舸4.0內置了一套自動化容錯機制，致力于訓練任務永不中斷。

比如，單網卡故障，任務會流量切換到同機網卡繼續傳輸數據，網絡故障修復后，任務自動回切。

比如，單節點故障，該節點全部數據可通過內存和網絡導入到備用機器中繼續訓練任務。

同時，針對無法自動化恢復的錯誤，百舸4.0提供了更加快速的「感知－定位－重啟－恢復」服務。

怎么個快法？

首先，百度自研的集合通信庫BCCL，內置了錯誤感知的專用觀察方法和故障定位的專用能力，將錯誤感知從傳統的10+分鐘縮短到秒級，并且秒級鎖定故障節點。

故障定位后，接下來就是快速任務重啟和斷點恢復，百度百舸平臺提供分級恢復策略，根據任務類型，用最省事、最快的方法恢復任務。

接下來，還記得我們前面說的“Graph重建”嗎？

重啟的任務直接通過RDMA從重建節點的內容中獲取Checkpoint，原地繼續下一步的計算，重啟時間從過去10+分鐘縮短到分鐘級。

這么說吧，百度百舸通過上述這一系列操作（性能提速、可擴展架構、穩定性設計），不僅提升了萬卡級集群的能力，也為挑戰十萬卡集群打好了底子。

接下來，就是十萬卡的大場面了↓

二、集中火力，攻克跨地域集群難點。

?物理設施層“加班整活”

RDMA網絡對丟包和擁塞是“零容忍”的，但是，從數據中心內部可以肆意狂奔的“陽關道”，到數據中心之間路窄車多的“獨木橋”，堵車在所難免。

為此，百度百舸團隊專門設計了一套無擁塞網絡機制，借助流量工程的思路進行流量調度。

簡單講，就是在數據中心互聯出口部署自研的流量控制器，根據訓練任務的模型特征，將需要跨地域的訓練任務流量均勻地調度到出口鏈路上，避免擁塞。

長距離的高延時問題，會讓傳統的擁塞控制不靈。

針對這種“基因型BUG”，百度百舸的方案是通過自研交換機代答，來縮短端側感知擁塞的響應時間，降低高延時的負面影響。

?集合通信鏈路層“持續優化”

百度自研的集合通信庫BCCL，可以根據不同的網絡時延場景，動態調整Buffer大小。

比如跨區域高時延場景，增加Buffer大小，在不產生擁塞的同時將鏈路打滿，讓網絡吞吐量發揮到極致。

同時，在模型訓練中，要讓所有的GPU工作量都飽和，沒人閑著摸魚，效率才能最大化。

這依賴于網絡傳輸和GPU之間的默契配合，它們就像流水線工人一樣絲滑默契。

但是跨域集群的高時延，會讓原來GPU和網絡之間的那種默契配合被打亂節奏，導致GPU閑置摸魚，訓練效率下降。

百度集合通信庫BCCL通過優化Channel算力排布，在借助大Buffer將網絡能力打滿的基礎上，成功讓GPU滿負荷運轉，高效率的流水線又開起來了。

在這里，BCCL對算力的排布優化主要包括兩個層面↓

第一是增加Channel數量，提升GPU中參與通信的SM資源量，并在一條鏈路上實現多Channel并發傳輸，讓集合通信性能跑滿。

第二是優化Channel結構，根據底層鏈路特征（時延、帶寬），進行合理分組，盡量避免或者減少使用性能差異大的鏈路做強同步通信。

vs

?計算框架層“卷到極致”

在GPU計算時代，即便是單一數據中心內部，整個端到端鏈路也存在不同能力的連接方式，比如NVLink、PCIe、RDMA網絡等等，各自的帶寬和延遲差異明顯。

如今，再跨地域，又額外增加了長距離RDMA這種差異化鏈路。

因此，必須要根據網絡拓撲制定更為合適的并行策略，讓計算和網絡進一步深度融合，才能讓計算效率最大化。

百度百舸的計算框架層能夠比較不同流量類型對各種鏈路的容忍度，然后對訓練任務作出并行策略調整，從而卷出了最優的集合通信性能來承載最佳模型訓練性能。

?長距傳輸“無損保護倒換”

跨區的傳輸線路相比數據中心內部脆弱了許多，比如城市施工挖斷了光纖。

一條光纖被挖斷，就可能影響幾十個400G端口（每條光纖可承載數十T帶寬）。

傳統高可用保護方案會導致大量機器的50ms丟包，從而造成訓練進度受損，非常影響客戶體驗。

為此，百度百舸團隊設計了傳輸無損保護倒換方案，通過線路側雙活、支路側緩存并行檢測的手段，實現無損倒換，數據不丟失、不重傳，訓練業務0中斷。

好了，十萬卡集群因為距離產生的難關，都被百度百舸逐一搞定了，距離不再是問題。

那么這就萬事俱備了嗎？不！還差好幾萬張卡呢。

國內的情況你懂的，成套的一萬張卡都很難湊齊，更不用說十萬張卡。

怎么辦呢，只能一云多芯，最終組成多芯混合的十萬卡集群。

本來跨區域就夠難了，再加上混合多芯，真是難上加難。

但你大可放心，“多芯”難題，百度百舸早就搞定了，上一期我們就介紹過，傳送門在這里：《不是GPU買不起，而是多芯混合更有性價比》。

還有如何搭建多芯混合集群動畫，大家可以一起復習

百度預判了趨勢，早早為?萬卡集群做好了一切準備：距離不是問題、多芯混合不是問題，穩定性持續加碼…

實測數據顯示，在百度百舸4.0的加持之下，100KM以內跨地域范圍內訓練性能單?訓練任務，性能折損低于4%，混合多芯集群相對單芯集群，訓練效能損耗低于5%！