傳統的推理服務均是集中式，大多是單機部署。即使是多機部署，機器規模也非常小，對網路的頻寬和時延需求都不大。當前大規模 PD 分離式推理系統來說，對網路通訊的需求則發生了變化：
-
引入大規模的 EP 專家並行。EP 會從單機和雙機的小規模，變成更大規模，因此 EP 之間的「 Alltoall 通訊域」成倍增長。這對於網路基礎設施、Alltoall 運算元等的通訊效率都提出了更高的要求，它們會直接影響 OTPS、TPOT 等指標，從而影響最終的使用者體驗。
-
PD 分離式部署，Prefill 和 Decode 之間會有 KV Cache 流量的傳輸，KV Cache 通訊的時延直接影響推理服務整體的效能。
為了提升大規模 PD 分離式推理系統的效率，百度智慧雲針對性地優化了網路基礎設施和通訊元件：
-
物理網路層面：為適配 Alltoall 流量專門建設了「4us 端到端低時延」 HPN 叢集，支援自適應路由功能徹底解決網路雜湊衝突，保證穩定的低時延。
-
流量管理層面：最佳化 Alltoall 多打一 incast 流量導致的降速問題。對 HPN 網路中訓練、推理等不同型別流量進行佇列管理，實現訓推任務的互不干擾。透過自研高效能 KV Cache 傳輸庫實現 DCN 彈性 RDMA 滿頻寬傳輸。
-
通訊元件層面：Alltoall 運算元最佳化，相比開源的方案，大幅提升 Prefill 和 Decode 的 Alltoall 通訊效能。針對 batch size 級別的動態冗餘專家編排，將專家均衡度控制在了 1.2 以下，確保叢集中所有 GPU 通訊時間大致相同。最佳化雙流，實現最大程度的計算和通訊 overlap，整體提升 20% 吞吐。
下面我們逐一介紹百度智慧雲在以上幾個層面的最佳化實踐。
百度智慧雲在訓練場景下的 HPN 網路架構設計已經有著豐富的經驗，AIPod 使用多導軌網路架構，GPU 伺服器配有 8 張網絡卡，然後每張網絡卡分別連到一個匯聚組的不同 LEAF 上。在 LEAF 和 SPINE 層面，透過 Full Mesh 的方式進行互聯。
以下圖為例，考慮一個訓練場景下的 3 層架構 HPN 網路：
-
非 MoE 訓練任務的流量特徵
在傳統非 MoE 的訓練場景下，跨機通訊產生的流量大多數都是同號卡流量。例如在梯度同步時候產生的 AllReduce 或者 ReduceScatter 或者 AllGather，PP 之間的 SendRecv 等。同號卡通訊最佳情況可以只經過一跳，以上圖為例，每個 LEAF 交換機有 64 個下聯口，因此 64 臺伺服器規模同號卡通訊理論上可以做到一跳可達。
規模再大，就只能經過 SPINE 或者最差經過 SUPER SPINE 來進行通訊。為了減少流量上送 SPINE，百度百舸在任務排程的時候會自動進行伺服器的親和性排程。在建立任務的時候，儘量把同一通訊組下的 Rank 排布在同一 LEAF 交換機下的伺服器內，那麼理論上大部分流量都可以收斂在 LEAF 下。
-
MoE 推理流量特徵
對於推理服務來說，MoE EP 之間的 Alltoall 通訊流量模式與 AllReduce 等不同，會產生大量的跨導軌流量。雖然對於 Prefill 階段來說，可以透過軟體實現層面規避掉跨導軌的流量，但是 Decode 階段仍然無法避免跨導軌，這會導致多機之間的通訊不只是同號卡通訊，跨機流量大部分並不能一跳可達，會有大量的流量上到 SPINE 或者 SUPER SPINE，從而導致時延增加。
-
MoE 訓練流量特徵
對於 MoE 訓練的流量會更加複雜，綜合了訓練和推理的流量特徵，既存在傳統的梯度同步產生的 AllReduce 或者 ReduceScatter 或者 AllGather，PP 之間的 SendRecv，也存在 EP 之間的 Alltoall 流量。這些流量不但會出現跨導軌傳輸的問題，他們之間可能會存在 overlap 導致互相干擾。
鑑於 Alltoall 通訊的特點，我們在設計 HPN 網路的時候，會考慮優先保證跨導軌流量至多 2 跳可達，讓 Alltoall 流量收斂到 SPINE 層，以這種方式儘量減少跨導軌的通訊時延。如下圖所示：
LEAF 層所有裝置全部有一根線接入同一臺 SPINE 交換機，這樣可以讓叢集內 Alltoall 跨導軌流量全部收斂到 SPINE 層，跨導軌通訊時延可以進一步從 5us+ 縮小為 4us。
這種經過最佳化後的 HPN 網路架構，能接入的卡數主要取決於交換機晶片支援的最大的下聯口有多少。雖然對於超大模型的訓練任務來說，這個叢集規模可能不夠，但是對於推理來說，通常不需要那麼大規模的機器，是可以滿足需求的。
同時，由於 Alltoall 通訊流量的特徵，LEAF 到 SPINE 之間的通訊流量會成為常態。當流量需要透過 SPINE 傳輸的時候，會由 hash 選擇 SPINE 出口的過程，這時候有可能會產生 hash 衝突，導致網路抖動。因此為了避免 hash 衝突，百度智慧雲基於自研交換機實現自適應路由。如下圖所示：圖片假設 A 和 C 進行 Alltoall 跨導軌通訊，A 發出的流量必然要經過 SPINE，那麼流量在到達 LEAF 的時候，會基於 packet 做 hash，並結合鏈路的負載情況動態選擇最優的出口，將報文傳送到多個 SPINE 上。
基於報文 hash 到不同的物理路徑，百度智慧雲實現了鏈路負載均衡，消除因 hash 衝突時延增加導致的效能抖動，實現穩定的低時延網路。
-
Alltoall 多打一，不合理的配置造成降速
在推理服務中，EP 間的 Alltoall 通訊流量特性與傳統訓練中的 AllReduce 完全不同，網路上多打一造成的 incast 流量非常常見。這種 incast 的嚴重程度會隨著規模的增大而增大。incast 流量的突發，可能會造成接收側網絡卡上聯的交換機埠向傳送側反壓 PFC，導致網路降速。
傳統 Alltoall 流量多打一的示意圖如下，假設機器 A 和機器 C 的 GPU0、GPU2、GPU4、GPU6 都需要給機器 B 的 GPU0 傳送資料，那麼在網路上就會出現 8 打 1 的情況。
傳統的 Alltoall 實現，例如 PyTorch 內部呼叫的 Alltoall，是使用 send recv 去實現的，如果使用 PXN 可以縮小網路上的發生多打一的規模，但是多打一依然存在，如下圖所示：
因此無論 Alltoall 的運算元實現方式如何，網路上的多打一都無法避免。此時如果網路側的擁塞控制演算法的配置不合理，對擁塞過於敏感，就會產生降速，進而對整體吞吐造成影響。
-
推理訓練任務中非 Alltoall 流量的干擾
除此之外，如果叢集內還存在其他流量，例如訓練任務 DP（資料並行）之間的 AllReduce 或者 ReduceScatter 或者 AllGather，或者 PD（Prefill-Decode）之間的 KV Cache 傳輸，也會對 Alltoall 的流量造成影響，從而進一步降低推理引擎的整體吞吐。
因此無論是端側網絡卡的配置，或者是交換機的配置，都需要針對 Alltoall 這種多打一 incast 流量做針對性最佳化，同時儘量避免叢集內其他流量對 Alltoall 流量造成影響。
針對這種情況，我們給出的解決方案如下：
-
在佇列管理層面，透過端側網絡卡將 EP 的流量做專門的優先順序配置，將 Alltoall 流量匯入到高優先順序佇列。其他訓練的流量，比如 AllReduce 等使用低優先順序佇列。
-
在資源層面，在端側網絡卡和交換機的高優先順序佇列上，預留更多的 buffer，分配更高比例的頻寬，優先的保證高優先順序佇列的流量。
-
在擁塞控制演算法配置層面，高優先順序佇列關閉 ECN 標記功能，讓 DCQCN 演算法對 Alltoall 流量微突發造成的擁塞不做出反應，從而解決 incast 問題造成的降速。
在經過端側網絡卡和網側交換機配合調整後，可以保障 Alltoall 通訊流量的通訊頻寬和傳輸時延，實現訓推任務的互不干擾，並有效的緩解 incast 流量帶來的非預期的降速而造成的效能抖動。
經過測試，在我們部署的推理服務中，Alltoall 過程的整體通訊時延有 5% 的降低。
在 PD 分離式推理系統中，還存在 PD 之間 KV Cache 傳輸的流量。相比 Alltoall 雖然他的頻寬需求不算大，但為了避免二者的流量互相干擾，通常我們會讓 KV Cache 的傳輸流量單獨走 DCN 網路，使其與 Alltoall 的流量完全隔離開。
在 DCN 網路的設計上，為了保證 KV Cache 流量的傳輸頻寬，其網路架構收斂比採用 1：1。端側網絡卡支援彈性 RDMA，使用 RDMA 協議保證 KV Cache 的高效能傳輸。
在傳輸庫層面，百度智慧雲使用自研的高效能 KV Cache RDMA 傳輸庫，其介面設計與框架層深度定製，支援上層框架分層傳輸，也支援多層 KV Cache 的批次傳輸，便於在框架層做計算與傳輸的 overlap。
透過以上設計最佳化，KV Cache 傳輸在主網絡卡可以用滿頻寬，傳輸時間可以完全被計算 overlap 住，不成為推理系統的瓶頸。
在有了高頻寬低時延的網路基礎設施的基礎上，如何用好網路基礎設施，是推理服務軟體層面需要重點考慮的事情。
在我們對 PD 分離推理服務的 profile 分析當中，發現了一些影響網路通訊效率的關鍵因素。
目前社群開源的 DeepEP 已經給出了推理系統中 dispatch 和 combine 過程的 Alltoall 高效能的運算元的實現，且效能表現優異。
對於 Prefill 來說，由於輸入的 batch size 較大，Alltoall 通訊運算元的同號卡傳輸階段為了平衡視訊記憶體資源和效能，採用分 chunk 傳輸的方式，傳送和接收會迴圈使用一小塊視訊記憶體，並對每次 RDMA 傳送以及機內 NVLink 傳輸的 token 數做了限制。
透過實際觀測網絡卡的傳輸頻寬，發現其並沒有被打滿。在此基礎上，我們對網路傳輸的視訊記憶體的大小，以及每一輪發送接收的最大 token 數等配置，針對不同的 GPU 晶片，做了一些精細化的調整，使之在效能上有進一步的提升。透過最佳化，DeepEP 的傳輸效能有大概 20% 的效能提升，網路頻寬已經基本被打滿。
對於 Decode 來說，DeepEP 的實現是多機之間的 EP 通訊，不區分機內和機間，一律採用網路傳送。這樣做的考慮是為了機內傳輸也不消耗 GPU 的 SM 資源，完成網路傳送後運算元即可退出。在網路傳輸的時間內做計算，完成後再呼叫 Alltoall 的接收運算元，以此來實現計算和通訊的 overlap。但這樣做的缺點是機內的 NVLink 的頻寬並沒有被高效的利用起來，網路傳輸的資料量會變大。
因此，百度智慧雲透過在 GPU 運算元內使用 CE 引擎做非同步複製，在不佔用 GPU SM 資源的情況下，也能實現機內 NVLink 頻寬的高效利用，同時不影響計算和通訊的 overlap。
EP 專家之間如果出現處理 token 不均衡的情況，將會導致 Alltoall 通訊運算元的不同 SM 之間，以及不同 GPU 的通訊運算元之間，出現負載不均的情況，導致的結果就是整體通訊時間會被拉長。
由於 EP 專家之間的負載均衡是推理服務引擎提升吞吐的非常重要的一環，經過百度智慧雲的大規模的線上實踐的經驗來看，靜態冗餘專家並不能很好的保證專家均衡。因此我們專門適配了針對 batch size 級別的動態冗餘專家，把專家均衡度（max token/avg token）基本控制在了 1.2 以下，不會出現明顯的「快慢卡」的情況
通訊和計算 overlap，隱藏通訊的開銷，一直都是推理服務，或者大模型訓練中，非常重要的課題。
在百度智慧雲的實踐中，我們在線上大規模的推理服務中開啟了雙流。為了儘量隱藏掉通訊的開銷，達到最好的 overlap 的效果，除了做 EP 之間的專家均衡以外，對計算運算元也做了針對性的最佳化，例如對計算運算元和通訊運算元 kernel launch 的順序做合理排布，對二者所需的 SM 資源做合理的分配，避免出現計算運算元佔滿 SM 導致通訊運算元 launch 不進去的情況，儘可能的消滅掉 GPU 間隙的資源浪費。透過這些最佳化，整體的吞吐可以提升 20% 以上。
百度智慧雲在大規模 PD 分離式推理基礎設施最佳化的實踐中，充分展現了網路基礎設施、通訊元件與上層業務特徵深度融合的重要性。這種融合不僅是技術層面的創新，更是對實際業務需求的深刻理解和響應。
