運營商大模型硬件基礎設施創新及RDMA流量控制技術研究

車碧瑤 張永航 廖怡 唐劍 樊小平 趙繼壯 陸鋼

(1.中國電信股份有限公司研究院,北京 102209;2.中國電信天翼云科技有限公司,北京 100007)

0 引言

“真正認真對待軟件的人應該自己制造硬件”[1]。經過十幾年的發展,云計算已經走到了硬件創新成為行業主要驅動力的階段。隨著2022年底大模型時代的開啟,全球頭部云服務商2023年除了推出自己的各種大模型,也堅定地在大模型硬件基礎設施上進行了自主研發。本文首先對電信運營商在大模型硬件基礎設施領域自主創新的路線選擇進行了分析和研究,然后重點論述了基于中國電信云網融合大科創實驗裝置在遠程直接內存訪問(Remote Direct Memory Access,RDMA)擁塞控制方面的研究進展。

1 運營商大模型硬件基礎設施創新路線圖

大模型硬件基礎設施創新主要包括以下3個層面。

一是研發人工智能(Artificial Intelligence,AI)算力芯片。2023年,AWS推出第二代AI芯片Trainium 2,微軟推出Maia 100,谷歌推出TPUv5p,這些產品均選擇走可對特定AI業務場景加速的專用集成電路(Application Specific Integrated Circuit,ASIC)芯片路線,而不是通用圖形處理器(Graphics Processing Unit,GPU)路線。

二是研發數據處理單元(Data Processing Unit,DPU)。例如,AWS的Nitro、谷歌的IPU、阿里巴巴的CIPU、中國電信的紫金DPU等。DPU設備是云服務商的根本技術所在,云主機最重要的虛擬化、網絡通信、存儲、安全功能全部下沉到此設備中;與過去智能網卡只能提供部分軟件卸載不同,現在整個基礎架構軟件堆棧都可以在DPU上實現,中央處理器(Central Processing Unit,CPU)釋放后可給最終用戶售賣更多核;頭部云服務商自研DPU的產品路線上均選擇對能夠體現自身架構獨特性的功能進行強化;因功能非常復雜且需要嵌入云服務商各自獨特的功能,故產業界DPU標準化程度還不高。

三是研發運行在數據中心專用通信硬件上的實時處理邏輯。例如,嵌入高速網卡中的RDMA擁塞控制邏輯、網絡負載均衡邏輯和交換機上的定制化協議處理邏輯等。

第一、二層面硬件自主研發的商業價值主要體現在:一方面,自研芯片可給云服務商加持其他公司難以復制的核心競爭力,如AWS的IPU Nitro;另一方面,大幅降低云服務商采購第三方先進芯片的投資額,可以預估一旦谷歌原生多模態大模型Gemini的領先效果被業界廣泛認可,則訓練Gemini的谷歌張量處理器(Tensor Processing Unit,TPU)會一改以前只是自用的局面,外部客戶也會從通用GPU轉向更便宜的谷歌自研芯片TPU,谷歌會大大降低外購GPU成本。

但第一、二層面的硬件研發需要巨大的投入和時間積累并且失敗風險很高,目前的實現路徑有以下幾種模式。

一是與大型芯片公司聯合研發,既可解決自身能力不足問題,又提高了項目的成功率。例如,微軟組建數百人的獨立團隊,與AMD聯合開發代號名為Athena的AI芯片,此項目預估已投入20 億美元以上;谷歌TPU v1～v4均由博通共同設計,除了芯片設計之外,博通公司還為谷歌提供了關鍵的知識產權,并負責了制造、測試和封裝新芯片等步驟,以供應谷歌的新數據中心,博通公司還與其他客戶(如Facebook、微軟和AT&T等公司)合作設計ASIC芯片。

二是收購半導體設計公司,走獨立自主的芯片設計路線。例如,亞馬遜多年前收購Annapurna Labs,設計出的AI推理/訓練和網絡芯片均已規模部署。

三是收購初創公司獲得完整知識產權(Intellectual Property,IP)和人才,如微軟收購DPU初創公司Fungible。

四是組建設計團隊,直接購買第三方完整IP修改后定制出自己的芯片,但除了因符合云服務商定制化需求的IP供應商很少外,商務合作模式也受限于運營商標準化采購流程比較難以操作。

五是與已經成功流片的小體量的初創設備商合作進行上層功能定制,快速推出自己的芯片。

六是基于現場可編程門陣列(Field Programmable Gate Array,FPGA)開展核心IP完全自主可控的產品研發,逐步積累芯片研發經驗,時機成熟啟動流片,最后實現低成本芯片規?；渴?微軟早在2010年就啟動了以FPGA路線為主的硬件研發;由于FPGA在信息通信網絡設備中廣泛存在,運營商在云中選擇同樣的FPGA路線可實現IP的復用;針對高端云網設備(高速DPU+高速交換機)極難解耦的困境,運營商端側的FPGA設備可以實現異構廠家交換機協議的兼容,保持運營商對網絡的核心掌控力。

綜上所述,結合運營商自身業務場景、實際需求和研發現狀,對硬件基礎設施創新3個層面分析如下:芯片研發耗時漫長,投資巨大,見效慢,且流片失敗風險極高。選擇上層功能定制合作模式的自研芯片見效快,但由于運營商研發人員沒有真正深度參與IP設計,從長遠看不利于核心競爭力的掌控。因此,在第三層面研發嵌入到特殊硬件中的硬件邏輯則相對周期較短,風險可控,實現獨有技術架構的可能性較大。例如,隨著業界100 G以上高速網卡在需求方引導下逐步開放可編程接口,研發面向大模型智算場景運行在高速網卡上的RDMA流量控制邏輯是一種性價比較高的選擇。

RDMA流量控制技術是保證大模型訓練網絡性能的關鍵技術之一。RDMA流量控制技術主要包括RDMA擁塞控制與RDMA多路徑負載均衡兩種技術:RDMA擁塞控制技術用于調控各個計算端服務器向數據中心網絡的發送數據的速度;RDMA多路徑負載均衡技術的目標是讓流入網絡的報文公平且最大化地利用組網中所有物理鏈路,盡快完成流傳遞,避免出現一部分鏈路過載而另一部分鏈路利用率不高的情況。這兩種技術現階段都需要在符合特定規范的硬件中嵌入運營商自主研發的控制邏輯,才能在100 G、200 G、400 G甚至未來800 G的高速網卡和高速交換機中發揮作用。

2023年,中國電信股份有限公司研究院與中國電信天翼云科技有限公司緊密協同在RDMA擁塞控制方面持續發力,結合運營商智算網絡規模大、可靠性要求高等特征確定研發目標:重點關注可部署性,盡可能破除對基于優先級的流量控制(Priority-Based Flow Control,PFC)的依賴,簡化交換機配置,避免繁瑣的顯式擁塞通知(Explicit Congestion Notification,ECN)水線調優,得到高速、NO-PFC、NO-ECN、Zero Queuing的擁塞控制算法?；诖罂苿撗b置仿真實驗平臺和物理實驗平臺,通過方法創新不斷挑戰性能曲線,自主研發擁塞控制技術(Chinatelecom Congestion Control,CTCC),在Incast場景、全閃存儲場景、混合專家(Mixed of Expert,MoE)大模型訓練場景實測結果有明顯對比優勢。

2 RDMA流量控制技術業界研究現狀

2.1 主流技術路線

隨著大模型算力性能飛速提升,為實現更高的GPU計算加速比,云主機網絡帶寬從主流通用云計算的單端口25 G演進到單端口400 G,此時基于軟件的網絡堆棧已經無法發揮出網卡的全部性能。頭部云服務商在高算力數據中心的各種業務中開始廣泛采用RDMA技術,將網絡堆棧卸載到網卡硬件中,實現數據直接傳輸。但RDMA網絡在協調低延遲、高帶寬利用率和高穩定性方面面臨著挑戰。由于網絡丟包對業務(尤其是大模型訓練業務)影響較大,避免網絡擁塞并發揮網絡全鏈路負載是保證算網協同場景性能的關鍵,云服務提供商都在此領域積極布局自主研發創新。

數據中心網絡擁塞主要由Incast流量和流量調度不均導致,為應對這兩類場景,提高RDMA網絡的性能和可靠性,業界采用擁塞控制算法和流量路徑負載均衡兩種技術路線。前者致力于提出高效的擁塞控制協議,感知鏈路擁塞狀態后進行流級別控速;后者調整進入網絡的各種流量路徑避免擁塞,特別是解決在大模型訓練業務場景下復雜的組網架構、通信模式極易引起的局部鏈路過載等問題。

主流擁塞控制算法主要通過ECN、往返時延(Round-Trip Time,RTT)、帶內網絡遙測(In-band Network Telemetry,INT)等信號感知鏈路擁塞,并做出微秒級響應。當前業界最普遍采用的、基于ECN信號的代表性算法是微軟和Mellanox聯合研發的數據中心量化擁塞通知(Data Center Quantized Congestion Notification,DCQCN)算法[2],需要交換機在擁塞時標記數據包,并由接收側反饋到發送側網卡進行速率控制?；赗TT的方案依賴網卡硬件實現高精度的時延測試,不需要交換機參與,部署相對容易,谷歌提出的TIMELY和SWIFT算法[3-4]均采用該路線;基于INT信號的方案依賴鏈路中交換機記錄的出口速率和隊列深度等信息精確控制飛行流量,要求交換機支持特定格式的INT報文[5-6]。

在流量路徑負載均衡控制方面,業界主流技術路線包括動態負載均衡和多路徑傳輸兩種。動態負載均衡感知鏈路故障或擁塞狀態,修改數據包頭中生成負載均衡哈希(Hash)算法Key值的相關字段,實現自適應路由,騰訊提出端網協同的快速故障自愈Hash DODGING方案[7]采用該路線,網卡和交換機上采用基于Hash偏移的網絡路徑控制方法,感知故障后終端修改數據包頭的服務類型字段值實現重新選路;多路徑傳輸路線的主要設計思路是包級別甚至信元(Cell)級別的負載均衡實現方案,以解決傳統等價多路徑(Equal Cost Multipath,ECMP)算法在長/短流混合場景負載分配不均導致長尾時延的問題。AWS的SRD協議[8]實現逐包轉發的負載均衡技術,依賴自研芯片Nitro完成亂序重排。谷歌提出新型網絡架構Aquila[9],定制TiN(ToR-in-NIC)芯片實現網卡和交換機硬件級的緊耦合改造,采用私有L2 Cell Based協議GNet提供Cell級交換能力。博通公司采用分布式分散式機箱(Distributed Disaggregated Chassis,DDC)組網方案[10],提出基于網卡的全網端到端Cell改造以及僅在葉脊網絡(Leaf-Spine)之間進行Cell改造的實現方案。

目前,先進的負載均衡方案大多依賴端網協同,需要交換機和網卡提供各種定制化能力。由于尚未形成統一的標準,設備商基于各自獨有技術提供能力支持,現階段開放性不足,難以異廠家設備組網,在運營商現網環境中大規模應用存在阻礙。端到端擁塞控制算法可以在不進行業務軟件、網絡硬件設備更新的前提下優化網絡擁塞和時延,是提升大規模集群網絡通信性能最具成本效益的方法。結合現網環境和業務場景,運營商可先著手于短期內能落地、易部署的高效擁塞控制算法,在數據中心改造升級過程中結合實際情況探索端網協同的負載均衡策略,提出更完備的流量控制解決方案。

2.2 面臨挑戰與優化目標

DCQCN是標準網卡中默認的RDMA擁塞控制算法,只有當交換機隊列累積至超過ECN水線才能感知擁塞,導致在大規模Incast場景擁塞緩解速度慢,收斂前持續觸發PFC。此外,DCQCN算法超參數數量過多,性能與參數選擇強相關,在實際部署中調參困難。此外,DCQCN算法完全依賴于路徑中交換機標記ECN擁塞后對端返回給發送端的擁塞通知報文(Congestion Notification Packet,CNP)調速,此方案有如下優劣勢。

在各個發送端,由于一臺交換機下所有發送端收到的擁塞信號接近,很容易導致各個流以相同的計算公式在同等輸入條件下得到的速度相近,吞吐波形圖中體現為各條流曲線基本重合。通過大科創裝置的物理實驗平臺,觀測到DCQCN吞吐量接近鏈路帶寬且各條流曲線公平性非常好。

ECN信號無法反饋準確的交換機隊列長度,擁塞情況下極易導致隊列累積觸發PFC。如果一條鏈路上出現多種流量混跑,因為交換機每個端口的優先級隊列只有8條,超過8個業務時必然存在多個業務共享一個交換機優先級隊列的情況。各個業務的流量模型不同時,可能出現共享隊列的流彼此影響,觸發PFC時端口暫停導致受害者流的問題。

調速應同時考慮交換機鏈路和主機處理速度雙重因素,但交換機的ECN信號無法反映對端主機上的業務處理速度。

綜合考慮運營商現網設備現狀與實際業務需求,從業務性能、網絡可靠性、成本等方面出發,提出自主可控的CTCC擁塞控制算法2023年設計目標:一是降低業務延遲,滿足RDMA網絡高吞吐、低時延的需求。算法基于端到端的RTT信號監控網絡擁塞狀態,快速做出響應,控制交換機隊列長度,減少數據包在網絡中的排隊延遲和抖動。二是支持NO-PFC。算法能夠在NO-PFC配置下正常工作,避免持續丟包降低網絡性能,保證網絡可靠性。三是簡化部署步驟。工業級網絡實踐中往往強調可部署性,新的擁塞控制方案應當不需要對網絡設備進行任何修改,主要在網卡上實現和配置,降低部署的成本和復雜度。

3 中國電信自研RDMA擁塞控制算法

交換機隊列長度是網絡擁塞狀態的直接反應,維持穩定的低交換機隊列能夠同時實現低延遲和高吞吐。排除軟件側時延抖動,RTT大小主要受數據包經過交換機的排隊延遲影響,能夠快速反應網絡擁塞狀態的變化。隨著硬件性能的提升,網卡能夠提供更高的時鐘精度和更準確的時間戳功能。這使得通過網卡進行高精度延遲測量成為可能,為基于RTT信號的數據中心RDMA擁塞控制協議的設計與實現提供了前提條件。

針對DCQCN基于ECN信號調速導致隊列累積、對網絡擁塞反應滯后、PFC依賴程度較高等問題,考慮使用RTT信號進行更細粒度的調速,提出一種端到端的、基于速率(Rate-Based)的擁塞控制協議,可基于現有商用網卡或DPU的可編程擁塞控制(Programmable Congestion Control,PCC)功能實現。與現有算法相比主要有以下兩點創新:依賴RTT信號進行Rate-Based調速,實現交換機免配置,能夠有效維持交換機低隊列,降低延遲;以支持NO-PFC配置為出發點,設置收到否定應答(Negative ACKnowledge,NACK)報文時快速降速,減少丟包帶來的性能損失。

3.1 算法設計

如圖1所示,CTCC算法使用RTT信號體現網絡擁塞的變化趨勢,設置目標RTT,當實測RTT高于目標RTT時表明網絡發生擁塞,控制發送端網卡降速;實測RTT低于目標RTT時表明網絡暢通,可試探性增速。此外,網卡收到NACK信號快速降速,避免持續丟包造成網絡性能損失。

圖1 CTCC擁塞控制算法實現框架

CTCC算法主要在網卡中實現,采用無需修改RDMA協議或軟件協議棧的RTT探測方式,發送端網卡在擁塞控制算法請求RTT探測時主動發出探測包,收到RTT響應報文或NACK基于加性增乘性減(Additive Increase Multiplicative Decrease,AIMD)策略調速。接收端網卡負責返回應答(Acknowledgement,ACK)報文和NACK報文,收到RTT探測包時記錄相關時間戳,生成RTT響應報文返回發送方。為避免反向鏈路擁塞增加RTT信號反饋延遲,設置RTT響應報文高優先級。該算法無需交換機參與,能夠降低部署成本,更好地支持動態環境下的網絡調整和擴/縮容操作。

CTCC算法難點描述:典型場景如7 000 個發送方往一個接收方打流,約束條件為7 000 個發送方彼此完全未知,每個發送方只能通過往接收方發送探測幀獲得微秒級延遲后進行發送速率控制;目標為7 000個發送方要速率快速收斂達到一致以保證公平性,同時避免總發送速率超過接收方鏈路帶寬,避免交換機隊列太滿產生PFC暫停幀,瓶頸鏈路吞吐要盡量逼近鏈路帶寬。此外,在網絡動態變化或復雜業務場景下,如打流期間對相同接收方動態新增1 000 個或動態減少1 000 個發送方、發送方物理鏈路混跑有多種業務流量、跨多個交換機、大小業務流混跑等場景,依然要滿足上述目標。

3.2 算法優勢分析

純RTT方案無需交換機配合,基于現有商用網卡實現,減少替換和運維成本。CTCC算法僅基于RTT信號進行擁塞控制,無需交換機支持可編程等高級功能,且基于商用網卡提供的PCC框架實現,無需定制化硬件。

收到NACK快速降速,支持NO-PFC場景。算法設置網卡收到NACK后直接將速率減半,在關閉PFC的情況下也能應對大規模突發場景,快速降速大幅減少丟包數量,降低丟包帶來的性能損失。

參數數量少,降低調優難度。算法不依賴PFC和ECN,免去配置交換機水線的繁瑣步驟;且網卡實現簡單,超參數數量少,極大地降低了算法調優難度,減少部署和運維工作量。

3.3 控制器設計

在算法研發測試過程中,隨著測試環境節點數的增加,算法燒寫、網卡和交換機配置等準備工作量劇增,且極易出現不同節點算法配置不一致等問題。為驗證算法可商用需要進行覆蓋多種基礎場景的上千項測試,測試結果的統一記錄和匯總是結果分析和算法優化的基礎。為解決該問題,自主研發出CTCC集中控制器,提供圖形化操作界面,實現多設備算法鏡像一鍵燒寫、動態超參數下發、算法類型切換、自動化測試、測試結果實時監控、試驗結果跟蹤等一系列功能,大大降低了研發測試的工作量和復雜性,保證測試結果可靠。

其中,超精度網絡指標采集及監控是CTCC控制器的重要組成部分和一大技術難點。擁塞控制技術在研發過程中往往需要觀測流量變化瞬間的網絡性能的變化,對指標采集精度提出非常高的要求。CTCC控制器采用網絡遙感技術,通過推模式(Push Mode)周期性地主動向采集器上送設備的接口流量統計、CPU或內存數據等信息,相對傳統拉模式(Pull Mode)的一問一答式交互,可提供更實時、更高速的數據采集功能。之后,經過Protocol Buffer編碼,實時上報給采集器進行接收和存儲。通過上述方案,可實現亞秒級以上的監控精度。

3.4 算法性能評估

利用商用網卡可編程架構實現自研算法,基于大科創裝置的物理實驗臺搭建8臺服務器通過1臺交換機連接的網絡環境,通過性能測試(Perftest)命令進行打流測試驗證自研算法優勢。測試使用的網卡支持per-QP和per-IP兩種調速模式,per-QP模式下為每個連接(QueuePair,QP)單獨調速,per-IP模式為相同目的互聯網協議(Internet Protocol,IP)地址的QP分配相同的速率?？紤]到同一目的IP的流可能通過負載均衡分配到不同的鏈路上,擁塞狀態會存在差異,設置相同發送速率并不合理。在測試中,采用per-QP模式對每個QP進行細粒度調速,根據鏈路實際擁塞情況調整速率。對于DCQCN算法,測試時開啟PFC,相關參數使用網卡和交換機推薦的默認值。對于CTCC算法,測試時關閉網卡和交換機的PFC功能。

CTCC算法維持交換機低隊列避免丟包:將7臺服務器作為發送方,另外1臺作為接收方,控制7個發送方同時起1 000 個QP向接收方打流,對比DCQCN和CTCC算法在大規模Incast擁塞場景的性能。測試結果顯示DCQCN算法擁塞控制基本失效,始終維持10 MB以上的交換機隊列,打流過程中持續觸發PFC,易造成PFC風暴、死鎖等問題,從而影響網絡性能。CTCC算法最高交換機隊列僅為1.22 MB,且在沒有開啟PFC的狀態下無丟包。DCQCN算法Perftest測得的發送端總和帶寬為97.98 Gbit/s,瓶頸鏈路帶寬利用率為95.4%。CTCC算法測得的發送端總和帶寬為90.70 Gbit/s,瓶頸鏈路帶寬利用率為91.5%。

CTCC算法實現低時延:為驗證自研算法在時延方面存在的優勢,在上述測試場景中添加同方向的小流,測試小流完成的時延。由于DCQCN算法維持高隊列,小流延遲達到1 154.77 μs,而CTCC算法能夠有效維持低交換機隊列,小流延遲平均值為20.31 μs,與DCQCN相比降低99%。

以上兩項測試結果驗證了CTCC能夠在保證高吞吐的同時顯著降低時延。與DCQCN相比,大規模Incast場景CTCC算法交換機平均隊列和小流時延降低90%以上,在DCQCN持續觸發PFC的情況下實現穩定狀態無丟包。盡管控制交換機低隊列易導致吞吐損失,且RTT探測包會占用少量帶寬,CTCC仍保證了90%以上的帶寬利用率,與DCQCN相比吞吐損失低于5%。

4 結束語

本文總結了業內RDMA擁塞控制算法研究趨勢,結合運營商實際組網環境和業務場景需求提出研發目標,設計了一種交換機免配置的擁塞控制算法,基于大科創裝置驗證了其在物理環境中的性能優勢。隨著自主研發DPU、交換機技術的不斷突破,產業各方會持續開展RDMA關鍵技術攻關,加強面向大模型訓練場景數據中心網絡極致負載分擔、RDMA擁塞控制算法等核心技術研究,基于新的硬件設備設計結合多種信號的高效擁塞控制算法,并規劃擁塞控制與負載均衡結合的全套解決方案,推動產業鏈的成熟與落地。