不出意外,AI是今年云棲大會的絕對主角,無論是主論壇的主旨演講還是各分論壇的大咖論道,無不充斥著人工智能的青春荷爾蒙。作為資深網工,我們重點帶大家探秘10.31日下午的《可預期網絡:AI Infra》專場。可預期網絡專場邀請了英偉達SVP Gilad,博通VP Mohan,以及阿里云基礎網絡負責人蔡德忠等行業頂級專家齊聚云棲小鎮,頗有些華山論劍的味道。再加上IB和以太網在AI集群市場上的激烈廝殺,以及近期國際上成立UEC聯盟來構建新一代高性能網絡等最熱門的話題,顯而易見的結果就是兩個字,“火爆“。幾百人的會場,3個小時,從始至終座無虛席。
主旨演講1:阿里云《端網融合的可預期網絡》
言歸正傳,論壇的第一個主旨演講是阿里云的蔡德忠,付斌章和席永青帶來的《端網融合的可預期網絡》。這個演講對阿里云針對AI集群網絡的設計理念以及當前的解決方案做了深入的闡述,干貨滿滿,尤其是很多AI大模型實際的訓練數據和流量模型是第一次向外披露,充分展示了阿里云基礎設施團隊的硬核創新能力,體現了阿里云作為業界頭部云廠商推動業界進步的技術擔當。整個演講內容分為三部分:
Part 1: 為什么需要AI集群網絡?
首先,傳統數據中心網絡內的東西向流量呈現“多、小、相對穩定“的特點,而AI集群內的東西向流量則呈現”少,大、突發/并發“的特點。根據演講中的示例,某ECS大客戶的鏈接規模達到了100K規模,而靈駿大客戶訓練任務的鏈接數只有60多個。正是因為有1000倍的數量上的差異,所以原本在通用計算場景下無法實現的per-flow的流量工程,在AI場景都變得順理成章了。
另外,因為ECS集群內同時運行的任務種類和數量更多,很多個小流匯總在一起,反而在統計學意義上呈現出一種“相對穩定”的狀態,但是總的帶寬利用率也仍然只有20%左右。
靈駿集群內的流量則完全不同,因為訓練任務是周期性迭代的,導致網絡上的流量也是周期性的突發,并且每次突發都可以打滿網絡帶寬。這就給網絡設計帶來了很大的挑戰,因為網工們都知道“少量大象流”是ECMP的噩夢,非常容易導致Hash不均的問題出現。
阿里云的解決辦法是多級的流量工程,從最上層的任務調度一直到最底層的Adaptive Routing,根據實際部署實踐,這套“降龍十八掌”打下來,很好的解決上面這些問題,最后展示的大幅度性能提升也佐證了這種多級流量工程帶來的效果。
Part2: 如何構建AI集群網絡?
其次,并行訓練需要的GPU數量越來越大,并且GPU服務器有NVLINK提供機內高速互聯。
基于這兩個前提,阿里云的HPN7.0架構基于博通 51.2T的TH5交換芯片搭建了一個單層1K GPU,2層16K GPU的極致性能網絡架構,并且已經在上個月正式開服了,這也是全球第一個實現51.2T交換機大規模商用的云廠商,一方面說明阿里云有足夠的前瞻性,準確預測了需求,同時也證明其強大的研發能力。
另外,演講中比較有意思的一點是關于集群最大規模的討論。因為業界也有可以支持更大規模的集群架構,但是阿里云的架構師強調這些更大規模的集群架構在當前IDC功耗限制下是沒有意義的。這個觀點與英偉達的首席科學家Bill Dally在今年的某次演講中表達的觀點不謀而合,即當前的AI集群是“power gating”的。
如果國內的IDC的總功率仍停在每棟樓10MW左右的能力,那么單集群搞10W卡或者更大其實意義也不大。畢竟因為時延的關系,我們一般不會跨樓構建集群。但是這里有個變量,在新的法規限制下,單芯片算力下降了,那么是否就需要更大規模的網絡架構可能是一個需要重新討論的問題。此外,在強大的需求推動下,相信未來也會有超高功率的IDC出現。
最后就是面向serverless場景的技術挑戰。事實上,阿里云在容器網絡領域也有很深的技術積累。Nimitz容器網絡從2017年開始在阿里內部服務ODPS業務,21年開始和高網相結合,構成了一套完整的支持多租的高性能網絡解決方案。在AI這個場景下,由于并行訓練任務對高性能網絡的性能有極致追求,而傳統的SRIOV+VxLAN的標準解決方案會帶來不可忽略的性能損失,所以阿里云提出了全新的vSolar+RDMAv6的解決方案。
vSolar是對Solar RDMA的擴展,也是Solar RDMA從存儲走向計算的一個重要優化。通過基于virtio的混合虛擬化技術,既保證了租戶隔離的安全需求,同時確保性能敏感的數據通路沒有任何性能損失,再配合基于IPv6的地址編碼技術RDMAv6實現了網絡地址的隔離。最終在這套解決方案的加持下,阿里云自研的高性能網卡EIC雖然是基于FPGA實現的(underlay性能不如ASIC方案),其overlay網絡性能完全可以媲美ASIC方案,這就是架構創新的優勢吧。再疊加阿里云自研的HPCC擁塞控制和多路徑傳輸技術,應用的端到端性能可以更上一層樓。
Part3:未來展望
由于時間的關系,未來展望部分講的比較簡短。核心的觀點是堅定的基于開放的以太網生態打造新的高性能網絡技術,特別提到了GPU的互聯部分。當前以英偉達為主導的異構計算生態下,GPU的IO分為PCIe(以太)和NVLINK兩個部分,其中 PCIe/以太部分用于實現scale out,NVLINK部分用于實現scale up。而當前國際上的UEC聯盟也在探索GPU全出以太網接口,即無論scale out還是scale up都采用以太網。這種方法的好處是顯而易見的,因為以太網是開放的,可以吸納全球的力量來促進技術進步。
主旨演講2:英偉達《Networking for AI》
第二個主旨演講來自于英偉達的Gilad,他是Mellanox的聯合創始人,英偉達全球高級副總裁,在HPC和高性能網絡領域有著豐富的經驗。同時Gilad來自以色列,這一次也是排除了萬難(換了3班飛機)才來到了中國參加云棲大會,說明了他對中國市場以及云棲大會的高度重視。對于他的到來,現場觀眾也報以了雷鳴般掌聲,來表達了歡迎和感謝。Gilad的演講題目是《Networking for AI》。回想今年在中國臺灣舉行的ComputeX大會上,Jensen Huang就介紹了Spectrum以太網方案。當時業界就有疑惑,難道英偉達放棄IB了嗎?這次Gilad演講給出了還算比較清晰的定義,Spectrum面向AI Cloud,而IB面向AI Factory。
關于設計理念部分,Gilad的見解和阿里云基本相同,也強調了網絡性能的重要性,特別是長尾時延的重要性。因為AI訓練是典型的并行計算應用,一個慢節點就會導致整個任務的性能下降,所以只是峰值性能高是不能滿足要求的。為了解決這個問題,英偉達在Spectrum+BF3的整體以太網方案率先支持了Adaptive Routing技術,從而可以實現穩定的、可預期的網絡性能。Gilad也多次提到可預期(Predictable),這一點和阿里云的觀點完全一致,正所謂英雄所見略同。
可以預料到的是,Gilad最后還是轉向推薦他們的IB解決方案。與以太網相比,IB最大的優勢在于對In-network Computing的支持,例如SHARP技術。根據Gilad展示的數據,使能SHARP之后集合通信性能是默認模式下的1.7倍,這個收益還是非常具有吸引力的。據說國內不少廠商都采購了IB,并且在積極推動SHARP的應用。不過按照UEC披露的信息來看,未來以太網交換芯片也會支持相關功能,咱們拭目以待吧。
主旨演講3:博通《Unleashing Ethernet: The Ubiquitous choice of Networking for AI/ML Clusters》
第三個主旨演講來自于博通的Mohan,他是博通全球副總裁、首席架構師。Mohan的演講題目是《Unleashing Ethernet: The Ubiquitous choice of Networking for AI/ML Clusters》。博通作為以太網交換芯片的絕對領導者,其態度非常鮮明,即基于以太網打造AI/ML集群網絡。背景部分不再重復,直入主題。Mohan演講中重點強調了“調度”的重要性,包括switch scheduled和endpoint scheduled兩種方案。
Switch scheduled方案是利用Jericho3-AI作為leaf交換機,利用Ramon3作為spine交換機。其核心思想包括幾點:1)在leaf交換機之間建立credit流控,只有接收端的交換機有空閑的credit,發送端交換機才允許將報文注入網絡,2)報文在注入網絡時,會被切成固定大小的“cell”,并將不同的cell均勻的分發到不同的網絡路徑上,實現負載均衡,3)用VOQ技術避免HOL blocking。由于時間關系,Mohan在會上講的細節不多,感興趣的同學可以參考這個演講(博通交換機調度方案)。
端側調度的核心思想來自于NSDI‘22的論文(EQDS論文),基本思路還是receiver-based credit調度。最近幾年,sender調速和receiver調速的爭論很多,其實Bill Dally教授在《Principles and Practices of Interconnection Networks》一書中講解input-arbiter和output-arbiter的時候分析的很清楚,兩者本質上沒有區別。另外,ACK和credit又有什么區別呢?ACK的目的不也是用于釋放/增大窗口嗎?那么稍微優化一下ACK的反饋機制就夠了?總體上感覺,雖然博通和阿里云都在講流量調度,但是阿里云的視角更寬一些,從集群任務調度到底層AR都有涉及,而博通的方案還是局限在網卡和交換機。當然這與兩個公司在生態中的站位是有關的。個人感覺阿里云的方案更全面。
當然Mohan演講中最吸引眼球還要是UEC話題。UEC最早是在今年OCP大會上公開的,博通、AMD、Intel、Meta、Microsoft是其中的主力成員,目標是在AI/ML這個市場上構建基于以太網的網絡生態。目前AI集群中,GPU網絡仍然分為scale out網絡和scale up網絡。Scale out網絡的實際標準是RoCE和IB,scale up網絡的事實標準是NVLINK。UEC的核心目標是把兩個網絡都統一到以太網。但這也并不是很容易,例如NVLINK需要支持緩存一致性協議,從而可以實現一個“Giant GPU”,以太網是否可以高效的支持緩存一致性協議是目前主要的問題。
圓桌論壇
前面的演講精彩紛呈,圓桌會議也是熱烈非凡,頗有華山論劍的感覺。
在AI大模型時代,數據中心網絡架構該如何演進,高性能網絡協議又該如何演進是目前行業內最熱門的話題,針對這個問題,專家們的觀點總體上是一致的,即網絡的發展一定是要滿足應用需求來發展的,那么當前最重要的需求還是支持更大規模的模型訓練,那么協議的設計、AR和CC算法的設計都是圍繞這個目標來展開的。
為此,UEC已經在嘗試給出自己的答案,但是也有專家提出UEC并不是目前唯一的“努力”,谷歌也提出了Falcon方案并計劃開源。由于UDP提供了一個最基礎的datagram語義,所以Falcon也是采用了業界普遍的做法,和SRD、Solar 一樣,采用在UDP之上進行擴展的方式來滿足各自的業務需求,在高性能網絡傳輸的核心功能方面,Falcon 和阿里的 Solar-RDMA,AWS 的SRD 沒有太多本質區別,都是圍繞多路徑傳輸,更加先進的流控,以及支持更大規模連接方面在增強,但是Falcon在安全性,以及協議的多樣性支持方面有所增強,從而可以支持多種應用,例如RoCE和NVMe,甚至 TCP,但是據一些渠道獲取的信息,Falcon 在Google 內部并沒有大規模部署。
關于NVLINK 和IB 的關系,Gilad也闡述了自己的觀點,他認為NVLINK和IB是面向不同場景下設計的,所以兩者之間不存在替換的關系,所有在未來不會看到IB完全取代NVLINK的情況,不過在需求的推動下,目前GH200已經支持了256個GPU通過NVLINK Switch互聯,未來這個網絡的規模可能會更大,當NVLINK大規模組網時也會遇到以前大規模IB或者以太網已經遇到的擴展性問題,所以NVLINK在某種程度上與IB進行協同甚至融合又是一個確定性的趨勢。
在GPU集群如何 scale up 方面,Mohan堅持認為未來會統一到Ethernet,事實上,AMD和Intel最新的GPU已經在使用以太網來實現Scale up網絡了,那么是不是可以說技術上全部基于以太網是可行的,那么剩下的就是商業選擇了,不同廠家可能會有不同的選擇。
如果從客戶的角度來看(云廠商是芯片廠商的客戶),客戶肯定不希望有五花八門的網絡方案,這一點阿里云的專家也表達的非常清晰。云廠商的這個訴求其實也是比較容易理解的,網絡不只是一個個芯片,實際上是一個復雜的分布式系統,需要配套的監控和運營系統,以及相應的運營團隊。如果每個GPU廠商都采用自己定義的私有協議,那么云廠商就需要為每種芯片定制監管控系統,并且配置單獨的運營團隊。當然這些復雜度和成本最終一定會轉嫁到更下游的消費者。
參考白盒交換機市場,所有交換芯片廠商都支持SONiC,那么下游的云廠商只需要適配SONiC就好了,回顧SONiC的歷史,早期也有其他競對方案,通過多年的持續迭代最終逐漸歸一到SONiC,相信GPU互聯標準這塊也會有類似的過程,通過市場的選擇,最終一定會出現一個事實標準,可能是UEC,也可能是其他,但是一定是一個開放的、大家可以共同參與的生態。
阿里云早在2019 年就提出了端網融合的可預期網絡這個網絡發展方向,這是基于阿里云從2016年就開始研發部署 RDMA 高性能網絡,并在大規模部署實踐中不斷創新而提出來的理念。
隨著AI大模型的火熱,行業內對“Predictable” 這個詞使用的頻率已經越來越高,對于可預期網絡的理解也越來越具像化了,這次圓桌論道,行業內的多位專家也是多次提及 Predictable, Predictable 可預期網絡目的是規避網絡“抖動”,這對于高并發,高帶寬,同步通信等大模型訓練的網絡流量特質而言,收益是巨大的,因為提升大算力集群線性擴展度不僅僅需要絕對網絡性能的提升,而且需要降低網絡長尾延時,規避木桶短板,提供穩定的高性能,而這就是可預期網絡(Predictable Network)的真正精髓所在。
-
AI
+關注
關注
87文章
31139瀏覽量
269477 -
阿里云
+關注
關注
3文章
967瀏覽量
43119 -
大模型
+關注
關注
2文章
2490瀏覽量
2864 -
AI大模型
+關注
關注
0文章
316瀏覽量
322
原文標題:華山論劍:AI 大模型時代的高性能網絡如何演進?
文章出處:【微信號:SDNLAB,微信公眾號:SDNLAB】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論