當我們在云上部署 DeepSeek 系列大模型的時候,可以選擇多機或者單機 8 卡的 GPU 裸金屬實例運行滿血版,或者選擇單卡和雙卡 GPU 虛擬機運行蒸餾版。這些 GPU 云服務器實例能否發揮多機、多卡、單卡的性能,將直接影響部署的 DeepSeek 服務的吞吐能力。除此之外,在訓練場景中這些實例的相關能力能將直接影響訓練時長。本文將針對 GPU 云服務器的軟件系統設計和實現進行概述,并分享百度智能云的新實踐成果。

 

　　1.GPU 處理數據流程

 

　　在具體討論 GPU 云服務器的軟件設計工作之前,我們首先來看下 GPU 在服務器中是如何工作的。下圖是一個簡化的 GPU 處理數據的流程圖,以便梳理一下影響 GPU 云服務器性能的關鍵因素。從圖中我們可以看到,數據處理分為以下幾個步驟:

 

　　第 1 步,所有數據都需要從網絡或者存儲中讀取到內存。這里就涉及到網絡或者存儲的傳輸性能。

 

　　第 2 步,當讀取到內存之后,CPU 需要從內存中讀取相關數據進行預處理,然后將預處理后的數據再寫回到內存中。這個過程就涉及到內存自身的帶寬性能和 CPU 的處理性能。

 

　　第 3 步 ,數據需要從內存拷貝到 GPU 的顯存中。這就涉及到 GPU 和系統內存之間的數據傳輸性能,一般稱之為 H2D(Host To Device)。

 

　　第 4 步,GPU 從 GPU 顯存中讀取相關的數據進行運算。此時主要涉及 GPU 的顯存帶寬和 GPU 的計算性能。如果數據比較龐大,單個GPU無法處理,就涉及到多個 GPU 的處理,那么這里就涉及到多 GPU 之間的集合通信。

 

　　第 5 步,如果是單機多卡的情況,就涉及到 GPU 在機內之間數據傳輸的性能;如果是多機多卡的場景,那么就涉及到多節點之間的網絡傳輸性能。

 

　　第 6 步,當 GPU 運算完成后,數據需要從 GPU 的顯存再拷貝到內存中。這里也涉及到 GPU 和系統內存之間的數據傳輸性能。一般稱之為 D2H(Device To Host)。

 

　　我們在設計 GPU 云服務器時,需要綜合考慮上面 GPU 數據處理鏈路的每一個環節,然后結合業務特點和使用成本,進行 GPU 云服務器的設計。

 

　　2.GPU 云服務器設計的層次劃分

 

　　談到 GPU 云服務器的設計,我們一般分為了 4 個層次。下圖展現了這個層次結構,涉及到硬件和軟件的多個層面。

 

　　首先從下面來看,主要是 GPU 云服務器底層基礎技術組件,包括如硬件選型、拓撲結構、GPU 互聯和虛擬化技術。這些技術不僅決定了單卡運行的效率,也會影響上層多卡通信的效率。

 

　　向上一層是多卡通信方式。此時我們需要考慮硬件和軟件的支持程度,比如是采用共享內存、P2P 、NVLink 還是 GDR 結構,每一種結構都需要考慮到對應的硬件和軟件實現。比如有的軟件不支持 P2P,此時我們可能就需要退回到共享內存的方式。如果涉及到大模型就需要采用多機多卡,此時還涉及到 RDMA 網絡的通訊。

 

　　再上一層是集合通信庫,即在多卡通信的場景下,我們需要考慮如何提升集合通信的性能,一般會各種 CCL (Collective Communications Library )的通信庫,這些庫會基于 GPU 卡的互聯技術和軟件支持,來進行合理的選路。一般來說會先探測出當前的 GPU 能進行哪些通信(比如支持 P2P 或者支持共享內存),然后根據該結果進行合理的選路,并通過合適的通信算法,大化提升集合通信的性能。

 

　　再往上就是 AI 框架。AI 框架依賴于集合通信的性能以提高 AI 計算的能力。

 

　　下面我們將詳細敘述底部的 2 個層次如何影響到 GPU 云服務器設計。

 

　　2.1.GPU 云服務器基礎技術

 

　　首先來看下 GPU 云服務器的底層實現技術,這關系到 GPU 云服務器性能的基礎,通常包括如下幾方面:

 

　　硬件選型:選擇合適的硬件,包括 CPU,內存,GPU,網絡和存儲等。

 

　　拓撲結構,包括實際的硬件拓撲。如果 GPU 云服務器采用虛擬化技術,則包含虛擬拓撲。

 

　　硬件拓撲:

 

　　NUMA 拓撲,包括 CPU、內存和外設等拓撲結構。

 

　　PCIe 拓撲:包括 GPU 和 RDMA 網卡等設備的 PCIe 拓撲結構。

 

　　虛擬拓撲:主要指以上拓撲在虛擬機里的實現。

 

　　GPU 互聯技術,主要指 GPU 的互聯方式:

 

　　如果是單機,包括 PCIe 或者專有總線,影響到單機內多卡通信的效率。

 

　　如果是多機,主要指多機多卡的互聯,包括各種網絡協議,如 RDMA 協議,或者專有各種總線協議。

 

　　虛擬化技術:主要是指 GPU 云服務器是虛擬機形態還是裸金屬形態。

 

　　前者的 GPU 云服務器以虛擬機形態實現,涉及到 CPU,內存,GPU 的虛擬化,會影響到 GPU 的運行效率。

 

　　后者的 GPU 云服務器以裸金屬形態實現,主要特點是網絡和存儲的通過硬卸載到 DPU 來提供服務。

 

　　2.1.1.硬件選型

 

　　CPU:根據 GPU 云服務器的用途,如推理或者訓練,選擇合適的 CPU。需要考慮的因素,主要有 CPU 的平臺類型、核心數量和主頻。

 

　　內存:GPU 云服務器應配備足夠容量和帶寬的內存,以支持 GPU 的數據處理需求。例如,使用 DDR5 內存可以提供高達 1200 GB/s 的理論帶寬。

 

　　GPU:根據 GPU 服務器的用途,如推理或者訓練,選擇合適的 GPU,主要考慮 GPU 的計算性能、顯存大小和互聯方式等。

 

　　網絡:通常包括南北向和東西向兩張網絡。前者通常用于存儲網絡業務,后者負責 GPU 跨機通信。要確保兩張網絡的帶寬都足夠高,以避免數據傳輸成為瓶頸。例如,A100/A800 機型的東西向的網卡帶寬達 100 Gbps 或者 200 Gbps,不同的網卡帶寬會導致集合通信的帶寬有差異,從而影響集群訓練的性能。

 

　　存儲:通常配置大容量的 SSD 磁盤,用來存儲業務的數據,這里主要考慮磁盤的 I/O 性能和容量等因素。但在進行集群訓練時通常會采用分布式文件系統用于存儲業務數據,那么對本地磁盤的需求就沒有那么高,而分布式文件系統的選型就至關重要。

 

　　硬件選型中,每個組件的性能要合理配合,不能導致系統存在瓶頸。比如 CPU 預處理數據時,如果性能過低,會導致 GPU 等待時間過長,或者網絡帶寬低導致獲取數據速度慢,都會導致 GPU 的使用率降低。

 

　　2.1.2.單機硬件拓撲結構

 

　　單機層面的硬件拓撲,主要涉及 GPU 和 GPU,GPU 和其他組件的拓撲結構,主要包括如下方面:

 

　　CPU、內存和 GPU 的 NUMA 拓撲。

 

　　包括 GPU 和 RDMA 網卡的 PCIe 拓撲。

 

　　2.1.2.1.NUMA 拓撲

 

　　NUMA(Non-Uniform Memory Access,即非統一內存訪問)是一種針對多處理器系統的內存組織方式,每個處理器都有自己的本地內存,處理器訪問本地內存的速度比訪問其他處理器的內存要快。

 

　　GPU 云服務器大多具備多路 CPU,那么系統的 NUMA 拓撲和設置,不僅影響到 CPU 對內存訪問的性能,還影響到一些需要訪問內存的外設的性能,比如網卡和  GPU 等設備。有關 NUMA 的問題主要包括

 

　　是否開啟 NUMA:系統可以選擇在 BIOS 設置中,開啟 NUMA,也可以不開啟 NUMA。

 

　　如果開啟 NUMA,開啟幾個 NUMA node。有些 CPU 內部采用多 Die 設計,每個 Die 可以組成一個 NUMA node,那么一個 CPU 就可以支持一個或者多個 NUMA node。一路 CPU 作為一個 NUMA node,軟件設置和開發更加簡單,適合大多數業務場合;而一路 CPU 開啟多個 NUMA node,更多應用在需要對內存進行更精細操作的業務場合。

 

　　GPU 設備如何分配到每個 NUMA node 上。大多數時候 GPU 都是均衡分配到每個 NUMA node 上,這樣每個GPU都會和本 NUMA node 上內存進行數據交互,減輕 PCIe 鏈路的負載。

 

　　對于虛擬化場合,是否輸出 NUMA 信息到虛擬機里,也是個影響 GPU 性能的重要考量因素。

 

　　2.1.2.2.PCIe 拓撲

 

　　涉及以下幾方面:

 

　　GPU 是否通過 PCIe 接口直連 CPU。

 

　　GPU 是否連接 PCIe Switch。

 

　　同一個 PCIe Switch 連接幾個 GPU。

 

　　GPU 和 RDMA 網卡的拓撲設計。

 

　　2.1.3.GPU 互聯技術

 

　　多個 GPU 之間的互聯,根據擴展方式的不同,可以分為 Scale Up 和 Scale Out 兩種方式。Scale Up 是指在同一臺服務器上增加 GPU 的數量,提升單機性能,通常可以通過 PCIe 總線和專有總線來擴展。

 

　　PCIe 總線:GPU 通常通過 PCIe連接到 CPU,可以是直通或者通過 PCIe Switch,那么同一主機上的 GPU 可以通過 PCIe 進行通信。

 

　　專有總線:為了彌補 PCIe 總線帶寬低的問題,不同 GPU 廠商實現了專有總線,進行單機內的多個 GPU 的互聯,也是 GPU 單機內 Scale Up 的重要手段。

 

　　Scale Out 通過增加多臺服務器,每臺服務器上配置多個 GPU,形成一個 GPU 集群,來提升整體計算能力,通常通過 RDMA 網絡和其他專有網絡技術來實現。

 

　　高速網絡技術:多機之間通過高速網絡技術進行互聯,目前通常采用的是 RDMA 技術。當前國際組織超以太聯盟,UEC (Ultra Ethernet Consortinum),正在制定新的高速網絡協議來改進 RDMA 協議。

 

　　2.1.3.1.PCIe 總線

 

　　PCIe 主要用于連接 CPU 與其他高速設備如 GPU、SSD 和網卡等,2003 年 PCIe 1.0 版本發布,目前已經更新到 6.0 版本,傳輸速率高達 64 GT/s,16 通道的雙向帶寬可以達到 256 GB/s,性能和可擴展性不斷提高。GPU 通常通過PCIe 連接到 CPU,可以是直通或者通過 PCIe Switch,那么同一主機上的 GPU 可以通過 PCIe 進行通信。

 

　　2.1.3.2.專有總線 - NVIDIA NVLink

 

　　PCIe 總線迭代速度趕不上 GPU 對互聯帶寬的需求,當前可用的PCIe 5.0 總線的雙向帶寬只有 128GB/s,無法滿足需求,于是各個 GPU 廠家都推出了自己的專有總線。NVLink 是 NVIDIA 推出的支持 GPU 之間高效通信的總線,目前 NVLink 已經發展到了第 4 代,在 H100 中可以達到高 900 GB/s 的雙向帶寬。

 

　　圖片4.jpg

 

　　NVSwitch 是它的 Switch 芯片,可以支持 GPU 全域互聯,目前已經發展到了第 3 代。

 

　　圖片5.jpg

 

　　如果僅僅使用 NVLink,只能實現點對點的連接,而如果加入到 Switch 之后,就可以實現任意兩個 GPU 之間的高速互聯,解決了點對點通信的拓撲缺陷。

 

　　2.1.3.3.專有總線 - 華為 HCCS

 

　　HCCS 是華為自研的一款高速互聯總線,主要用于昇騰系列 AI 處理器之間的互聯。它提供了一種高效、可靠的數據傳輸方式,使得多個昇騰處理器能夠協同工作,共同完成大規模的 AI 計算任務。HCCS 采用對等拓撲,單鏈路的大帶寬是 56 GB/s。昇騰 910B 中的 HCCS 采用點對點拓撲,單鏈路的大帶寬是 56 GB/s。

 

　　2.1.3.4.RDMA

 

　　當涉及到多機 GPU 通信時,目前主流的選擇是 RDMA 網絡,包含 Infiniband 和 RoCE 網絡。傳統的 TCP/IP 網絡通信因為需要操作系統內核的介入,涉及較多數據移動和數據復制,不適用高性能計算和大數據分析等需要 I/O 高并發、低時延的場景。RDMA 是一種計算機網絡技術,網卡可以直接遠程訪問內存或者 GPU 顯存的數據,而無需操作系統內核介入,不占用 CPU 資源,可以顯著提高數據傳輸的性能并且降低延遲,因此更適配于大規模并行計算機集群的網絡需求。

 

　　2.1.4.虛擬化技術

 

　　虛擬化技術主要分為兩大類:

 

　　傳統虛擬化,主要是基于 Qemu/KVM 實現的虛擬化。

 

　　基于 DPU 的虛擬化,主要基于 DPU 實現的虛擬化。

 

　　他們共同要解決的問題主要是:

 

　　系統虛擬化:如果采用傳統虛擬化技術,既包含 CPU 和內存虛擬化,也包含各種設備的虛擬化,比如 GPU 和 RDMA 網卡。

 

　　網絡虛擬化:這里的網絡主要指 VPC(Virtual Private Cloud)網絡的虛擬化。

 

　　存儲虛擬化:主要指塊設備的存儲虛擬化,后端存儲設備可以是本地存儲,也可以是遠程的存儲系統。

 

　　2.1.4.1.傳統虛擬化

 

　　傳統的 GPU 云服務器,都是基于 CPU 的硬件虛擬化技術來實現,并且大多使用 QEMU 和 KVM 開源技術來開發。GPU 通過透傳的方式透傳到虛擬機里,GPU 的性能損耗很低。

 

　　2.1.4.2.基于 DPU 的虛擬化

 

　　當前云廠商主流 GPU 云服務器,都開始基于 DPU 進行設計。DPU 是繼 CPU 和 GPU 之后的「第三顆主力芯片」,其設計目標是卸載 CPU 在網絡傳輸和存儲的負載。基于 DPU 設計的服務器,大多數為裸金屬服務器,沒有采用傳統虛擬化技術,此時 CPU 和 GPU 基本實現了零損耗。

 

　　2.2.GPU 云服務器的多卡通信

 

　　基于上面介紹過的 GPU 硬件互聯技術,接下來討論在硬件能力的基礎上,多個 GPU 之間如何實現實現多卡通信,這涉及到硬件和軟件的支持。我們知道,很多 AI 模型已經超過了單個 GPU 的顯存大小。無論是推理還是訓練,都需要多 GPU 來實現。這就涉及到單機多卡和多機多卡的通信問題,這也是我們在 GPU 云服務器設計時面臨的主要挑戰之一。首先是單機多卡通信的場景,主要有三種方式。

 

　　第一種是共享內存。在這種通信方式中,多個 GPU 會通過系統內存來共享數據。從下圖中可以看出,當 GPU 0 和 GPU 1 進行通信時,GPU 0 會先把數據從顯存搬遷到系統內存(即共享內存)中,然后 GPU 1 再從系統內存中讀取到自身的顯存中。一般來說,該方式的通信效率低,雙向帶寬在 10 ~ 20 GBps 左右。

 

　　第二種是 PCIe 的 P2P。這種通信方式相較于第一種來說,無論讀寫都不需要系統內存做中轉,GPU 0 可以直接向 GPU 1 發起通信,這種通信方式的雙向帶寬在 40 ~ 50 GBps 左右。

 

　　第三種是專有總線。這種方式是通過 GPU 廠商提供的專有總線進行通信,比如說 NVIDIA 的 NVLink、華為的 HCCS 以及 AMD 的 Infinity Fabric 等。這種方式比 PCIe 的傳輸帶寬要的多。以 NVLink 舉例,專有總線的雙向帶寬可以達到 400-900 GBps,相比于 PCIe 的 P2P 通信來說要高出一個數量級。而且在實際通信的過程中,采用專有總線的方式大大提升了單機多卡的通信效率。

 

　　然后是多機多卡通信的場景,就需要采用上面介紹的 RDMA 網絡技術來實現。多卡通信的性能,決定了上層集合通信的性能。集合通信庫會先探測出當前的 GPU 和系統能進行哪些多卡通信的方式,然后根據該結果進行合理的選路,同時選擇合適的通信算法,大化提升集合通信的性能。

 

　　2.2.1.共享內存方式

 

　　單機上多個 GPU 可以通過 PCIe 總線,訪問系統內存來共享數據,從而達到通信的目標。

 

　　2.2.2.PCIe 的 P2P

 

　　單機上多個 GPU 也可以通過 PCIe 總線,直接進行通信,這就是 P2P 通信。

 

　　2.2.3.專有總線技術

 

　　上面我們介紹過幾個廠家的專有互聯硬件總線,它們都需要相應的軟件支持,來到達單機多卡的通信。

 

　　2.2.4.多機互聯 - GDR

 

　　多機多卡場景下,傳統的 TCP/IP 網絡通信速度過慢,無法滿足業務的需求。目前我們主要使用基于 RDMA 網絡的 GDR 技術來實現, 即 GPU Direct RDMA。它支持 RDMA 的網卡直接訪問 GPU 的數據,大大提升了多機多卡的通信效率。下面我通過一個例子來為大家講解 GDR 是如何提升通信效率的。在傳統的多卡通信中,即圖中紅色步驟,共分為 5 步:GPU 將數據傳給內存 —— RDMA 網卡從內存中拿到數據 —— RDMA 網卡將數據傳給另外一個節點的 RDMA 網卡 —— 新節點的 RDMA 網卡將數據傳給該節點的內存 —— GPU 從內存中拿到該數據。而 GDR 的方式繞過了系統內存的中轉,讓 RDMA 網卡可以直接從 GPU 處獲取數據,如圖中藍色步驟,共分為 3 步:RDMA 網卡從 GPU 處獲取數據—— RDMA 網卡將數據傳給另外一個節點的 RDMA 網卡 —— 新節點的 RDMA 網卡將數據傳輸給 GPU。

 

　　得益于 GDR 的方式可以在 PCIe Switch 中進行傳輸,不僅僅提供了高速了數據傳輸,同時也減少了上行鏈路中的帶寬爭搶。相比于傳統的方式,采用 GDR 的方法可以提升整體 3-4 倍的帶寬。大大提升了多機多卡的通信效率。

 

　　3.百度智能云的 GPU 云服務器設計實踐

 

　　百度智能云主要有兩類 GPU 云服務器的實例,第一類是 BCC(Baidu Cloud Compute) GPU 云服務器,基于 Qemu/KVM 虛擬化的 GPU 服務器。第二類是 BBC(Baidu Baremetal Compute) GPU 云服務器,即基于裸金屬的 GPU 云服務器。

 

　　3.1.BCC GPU 云服務器

 

　　我們先來看 BCC,即基于 Qemu/KVM  虛擬化的 GPU 云服務器。整體的設計如下圖所示:下方是實際的 GPU 硬件,上層是包括 VFIO 和 KVM 在內的內核,再往上是 Hypervisor 和實際的虛擬機。主要適用于小模型的訓練和推理、圖像識別、推薦系統等場景。

 

　　在這樣的結構中,GPU 會通過 VFIO 技術整卡透傳給虛擬機,使得整體算力的的損耗比較小。此外,它還可以支持 1 卡、2 卡、4 卡和 8 卡的實例,讓客戶可以根據實際需要來進行采購,大大降低了客戶的使用成本。但在這種結構中,BCC 的拓撲結構是虛擬的,這也意味著虛擬機中的拓撲結構和實際物理形態中的拓撲結構是有差異的。這些會為實際業務的運行帶來一些性能影響,我們通過一些虛擬機的設計消化了影響,分別為:

 

　　GPU 的 NUMA 感知。

 

　　支持多 GPU 的 P2P。

 

　　支持 A100/A800  的 Shared NVSwitch 機型。

 

　　支持 RDMA 網絡。

 

　　3.1.1.支持 GPU 的 NUMA 感知

 

　　虛擬機里為什么需要 GPU 的 NUMA 感知呢?主要的原因在于保證 CPU 和 GPU 在同一個 NUMA 下,這樣就可以避免數據在系統內存和 GPU 顯存之間的傳輸性能損失。實際上,系統內存、CPU 和 GPU 都存在 NUMA 屬性的,如果彼此之間不在一個  NUMA 中,那么實際的性能差距就會受到影響,尤其是在 AMD MILAN 平臺上, GPU 跨 NUMA 訪問的 PCIe 帶寬只有同 NUMA 訪問性能的一半。

 

　　在虛擬機實現時,如果沒有考慮到 NUMA 屬性,當我們將 GPU 透傳到虛擬機時,CPU 0 以及 Memory 0 不知道它要訪問的 GPU 是在同一個 NUMA 下還是跨 NUMA,這就大大降低了 GPU 和內存之間的傳輸效率。所以我們需要在 GPU 透傳到虛擬機的時候,讓它感知到在哪一個 NUMA 下,這樣在虛擬機內就可以強制把 GPU、CPU 以及 Memory 綁定在一起,大大降低了傳輸過程中的性能損失。在實現時,虛擬機每個 NUMA 的 CPU 都會擴展出一個 PCIe bus。此時,實際物理機上的 NUMA 0 上的 GPU,在透傳給虛擬機的時候就會掛載到虛擬機的 NUMA 0 的 PCIe bus 上,NUMA 1 上的 GPU 會掛載到 NUMA 1 的 PCIe bus 上,這樣 GPU 就可以在虛擬機中感知到 NUMA,從而避免跨 NUMA 傳輸的性能損失。

 

　　3.1.2.支持多 GPU 的 PCIe P2P

 

　　我們的第二個改進是在虛擬機內對 GPU 的 PCIe P2P 支持。在物理機上如果要支持多 GPU 的 P2P,一般需要滿足兩個條件:

 

　　硬件層面支持:比如 PCIe Root Complex 或者 PCIe Switch 支持 P2P。

 

　　軟件層面支持:需要驅動端支持 PCIe P2P 的傳輸。

 

　　在物理機以上兩個條件都是支持的,但是當 GPU 透傳到虛擬機的時候就,要支持 PCIe P2P 就有新問題。第一個問題是因為虛擬機的 PCIe 拓撲結構是扁平的,驅動在虛擬機內無法識別 GPU 的拓撲,所以無法開啟 GPU 的 P2P 能力。這里需要修改 Hypervisor 的實現,在 Hypervisor 模擬的 GPU PCIe 配置空間里增加一個 PCI Capability,讓驅動識別出 GPU 的 P2P 親和性,這樣 GPU 驅動就可以根據這個信息來開啟 P2P 能力。第二個問題是,如果在物理機上通過 PCIe Switch 連接的兩個 GPU,要在虛擬機場景下進行 P2P 通信,比物理的性能要差很多。這是因為透傳到虛擬機的 GPU 不支持 ATS,他們的 P2P 通信都會被路由到 IOMMU,而無法通過 PCIe Switch  中轉,這樣通信的路徑就長了,導致性能下降。這個問題目前暫時無法解決。

 

　　3.1.3.支持 A100/A800 的 Shared NVSwitch 機型

 

　　第三個改進是實現了對 A100 和 A800 的 Shared NVSwtich 機型的支持。下圖是 A100 和 NVSwitch 連接的拓撲圖。我們可以看到,一臺機器中有 8 張 A100 的卡,以及 6 個 NVSwitch。它通過 NVSwitch 的連線,可以進行任意兩卡之間的 NVlink 高速互聯。

 

　　圖片6.jpg

 

　　但如果要做 A100 的虛擬機,會存在有一個問題:如果我們要實現一個 2 卡的虛擬機,在將 GPU 傳到虛擬機的同時還需要透傳 NVSwitch。但由于 NVSwitch 采用了全連接的形式,如果要保證兩卡的滿速互聯,那么就需要將 6 個 NVSwitch 都透傳到虛擬機中,此時剩下的 6 張 GPU 就無法繼續使用 NVSwitch,這就造成了 GPU 資源的浪費。為了解決這個問題,可以使用如下兩種方案:第一種是 Full Passthrough 機型。這種方案就是將所有的 GPU 和所有的 NVSwitch 都透傳到一個虛擬機中,但這樣的機型在 1 卡、2 卡、4 卡的情況下會損失部分 NVLink 的帶寬。

 

　　另外一種是 Shared NVSwtich 機型。這種設計需要創建一個 Service VM 的虛擬機,這個虛擬機只透傳 NVSwitch。而用戶使用的虛擬機則只需要透傳 GPU。在 Service VM 中可以對 NVSwitch 進行管控,讓用戶虛擬機內的 GPU 都可以進行高速互聯。

 

　　通過這樣的方式,解決了用戶使用 1 卡、2 卡或者 4 卡虛擬機時,虛擬機內部  GPU 之間 NVLink 高速互聯不損失的問題。

 

　　3.1.4.支持 RDMA 網絡

 

　　第四個改進是支持 RDMA 網卡透傳。有的 GPU 機型,除了要透傳 GPU 外,還需要把 RDMA 網卡透傳到虛擬機里。透傳 RDMA 網卡這點從技術上實現是比較簡單的,但是如果未做任何優化手段的話,實測發現,虛擬機里的 GDR 性能,只有物理機的 25% 左右,這顯然是無法接受的。為了改進這個問題,需要我們做一些相關的設置和改進。

 

　　首先就是網卡需要支持 ATS 功能,并在透傳前打開網卡的 ATS 功能。ATS 主要的工作就是緩存地址翻譯的結果。RDMA 網卡向 IOMMU 請求地址翻譯,并將得到的物理地址存儲到網卡的緩存中。這樣當 RDMA 網卡數據包時,可以直接使用緩存的物理地址。

 

　　其次是打開 PCIe Switch 上的 ACS 功能,主要是使能 Downstream Port 的 acsctl 的 DirectTrans 標志位,這樣,PCIe Switch 就可以直接轉發網卡的數據包給 GPU,而不是通過 RC 來進行中轉,這大大降低了數據包的傳輸路徑。

 

　　通過以上兩個設置,就可以加速虛擬機中的 GDR 傳輸性能。但是我們發現另外一個問題,即多機 NCCL 的性能只有物理機的 1/4。在物理機拓撲中,RDMA 網卡和 GPU 在同一個 PCIe Switch 下,但是在虛擬機拓撲中, GPU 和 RDMA 網卡是平鋪在一個總線上的。而對于 NCCL 來說,如果是物理機的場景,那么 NCCL 就會選擇 GDR 通信;而在虛擬機場景下,NCCL 則會認為這些網卡和 GPU 無法做 GDR 通信,因此還是按傳統的通過內存中轉的方式來進行通訊。我們采用了 2 種解決方法來修復這個問題:

 

　　第一種方式是修改虛擬機拓撲的方式,即通過增加 PCIe Switch 的方式,讓 GPU 和 RDMA 網卡在同一個 PCIe Switch下,這種方法能讓虛擬機拓撲和物理機的保持一致,這樣 NCCL 選路也和在物理機的保持一致。

 

　　第二種方式是修正 NCCL 的拓撲識別結果。我們在每一個 GPU 和它相鄰的 RDMA 網卡中加了一個虛擬的 PCIe Switch,然后將這個拓撲文件通過環境變量提供給 NCCL。通過這樣欺騙的方式,讓 NCCL 「誤以為」 GPU 0 和 RDMA 0 在同一個 PCIe Switch下,這樣就可以進行 GDR 通信。

 

　　通過這樣的方式,我們虛擬的集合通信的性能可以和我們的物理機打平。

 

　　3.2.BBC GPU 云服務器(裸金屬)

 

　　接著是 BBC GPU 云服務器,即基于裸金屬的 GPU 云服務器。服務器的外設除了 GPU、NVSwitch 和 RDMA 等硬件之外,還通過 PCIe 總線連接了一個 DPU,給主機提供網絡和存儲的卸載功能,主機上的網絡和存儲的相關功能都在 DPU 上實現。這類服務器相比 BCC 服務器來說,因為 CPU、內存、GPU 都不需要虛擬化,整體的算力損耗是零。

 

　　目前,我們已經實現了 BCC 和 BBC 的融合,在統一的硬件架構上,既可以交付虛擬機形態或者裸金屬形態的 GPU 計算實例。

 

　　3.2.1 DPU 功能

 

　　DPU 核心能力在于卸載、加速和隔離數據中心的基礎設施任務,從而釋放主機的 CPU 算力,提升整體主機的系統效率。其核心功能包括:網絡功能卸載:DPU 通過硬件加速處理網絡協議(如 VxLAN 或者 RDMA 等),將虛擬交換機(如 OVS)的負載從 CPU 轉移到 DPU,顯著降低網絡時延并提升吞吐量。存儲加速:支持 NVMe-oF 協議,實現遠程存儲訪問性能接近本地存儲,并通過 SNAP 技術優化存儲虛擬化,減少 CPU 對存儲協議(如 iSCSI、NVMe)的處理開銷。

 

　　3.2.2.常用 BBC GPU 機型介紹

 

　　3.2.2.1 A800 機型

 

　　以下是我們主推的 A800 訓練機型,它的規格如下:

 

　　CPU:Intel Xeon 8350C 3.1G。

 

　　GPU:8 × A800 SXM4 80GB。

 

　　NVLink:GPU 卡間雙向 400 GB/s。

 

　　網卡:8 × CX6 100G RoCEv2。

 

　　其中 8 個 A800 芯片通過 6 個 NVLink Switch 芯片進行卡間的高速互聯,雙向帶寬達到 400 GB/s,同時通過 4 張 PCIe Switch 和網卡進行連接。(每張 PCIe Switch 連接了兩張 A800 和兩張 CX6 100G RoCEv2 的網卡進行 GDR 的通訊)。

 

　　3.2.2.2.L20 機型

 

　　目前百度智能云也提供了 L20 的機型。由于 L20 可以進行卡間的 P2P 傳輸。所以每個 PCIe Switch 都連接了 2 張 L20 和一張 400G RoCE v2 網卡,大大提升多機互聯的帶寬。通過這樣的架構設計,我們既可以做模型的推理,也可以進行大模型的訓練。

 

　　3.2.2.3 H20 機型

 

　　百度智能云也提供了 H20 96GB 顯存版本的 BBC 機型。H20 96GB 是 H100 的精簡版,雖然對算力進行了剪裁,但是保留了 H100 的卡間互聯帶寬,支持 NVLink 和 NVSwitch,適合大模型的推理和訓練。H20 96G 8 卡 BBC 機型支持單機跑 DeepSeek V3 和 DeepSeek R1 模型的滿血版本。百度智能云同時推出了 H20  141GB 顯存版本的機型,提供單卡 141GB 的顯存,對 Deepseek 大模型提供了更高的吞吐支持。

 

　　4.GPU 云服務器的未來發展

 

　　4.1.Scale Up 和 Scale Out 的融合統一

 

　　在過去萬卡集群的建設中,云廠商的注意力主要放在 Scale Out 上,通過多機互聯技術合理的網絡架構,建設一個超大規模的集群,以實現超強算力。同時,Scale Out 和 Scale Up 技術是互相促進和發展,Scale Out 的互聯帶寬要匹配對應的 Scale Up 帶寬,如果 Scale Up 帶寬很高,而相應的 Scale Out 的帶寬較低,會造成集合通信在多節點上成為瓶頸。這個相互關系,我們可以從 H800 實例配置 400G 的 RDMA 中可見一斑。不過,隨著集群能力的要求越來越高,單純擴大規模變得不夠經濟有效,Scale Up 逐漸成為關注點,并且兩者之間的邊界變得模糊,節點間和節點內的互聯技術逐漸對齊,以 NVL72 為代表的「高密機型」就是這個思想的體現,使用 NVLink 作為節點間的連接方式。

 

　　4.2.推理卡和訓練卡的分野

 

　　大模型推理需求的爆發,將使得成本的關注變得非常敏感。相比算力的提高,大模型推理對 GPU 顯存的大小和互聯帶寬有著更高的需求,從 DeepSeek R1/V3 可見一斑。同時,專用芯片的崛起,將進一步降低大規模部署情況下的成本。例如現在各大廠商都在設計針對推理優化的 ASIC 芯片,通過簡化計算單元、采用 SRAM 替代 HBM,可以實現數倍于傳統 GPU 的能效比提升。