今天的前沿 高性能計算 （ HPC ）系統(tǒng)包含數(shù)以萬計的 GPU 。在 NVIDIA 系統(tǒng)中， GPU 通過 NVLink 擴展互連在節(jié)點上連接，并通過 InfiniBand 等擴展網(wǎng)絡(luò)跨節(jié)點連接。 GPU 用于并行通信、共享工作和高效運行的軟件庫統(tǒng)稱為 NVIDIA Magnum IO ，是用于并行、異步和智能數(shù)據(jù)中心 IO 的架構(gòu)。

對于許多應(yīng)用，擴展到這樣的大型系統(tǒng)需要 GPU 之間的細(xì)粒度通信的高效率。這對于以強伸縮性為目標(biāo)的工作負(fù)載尤其重要，因為在工作負(fù)載中添加了計算資源以減少解決給定問題的時間。

NVIDIA Magnum IO NVSHMEM 是一個基于 OpenSHMEM 規(guī)范的通信庫，它為 HPC 系統(tǒng)中所有 GPU 的存儲器提供分區(qū)全局地址空間（ PGAS ）數(shù)據(jù)訪問模型。

由于該庫支持 GPU 集成通信，因此對于以強擴展為目標(biāo)的工作負(fù)載而言，它是一個特別適合且高效的工具。在這個模型中，數(shù)據(jù)是通過單邊讀、寫和原子更新通信例程訪問的。

由于與 GPU 架構(gòu)緊密集成，該通信模型通過 NVLink 實現(xiàn)了細(xì)粒度數(shù)據(jù)訪問的高效率。然而，由于主機 CPU 需要管理通信操作，因此節(jié)點間數(shù)據(jù)訪問的高效率仍然是一個挑戰(zhàn)。

本文在 NVSHMEM 中介紹了一種新的通信方法，稱為 InfiniBand GPUDirect 異步（ IBGDA ） ，它建立在 GPUDirect Async 系列技術(shù)之上。 IBGDA 在 NVSHMEM 2.6.0 中引入，并在 NVSHMEM 2.7.0 和 2.8.0 中進(jìn)行了顯著改進(jìn)。它使 GPU 在發(fā)出節(jié)點間 NVSHMEM 通信時繞過 CPU ，而不會對現(xiàn)有應(yīng)用程序進(jìn)行任何更改。如我們所示，這將顯著提高使用 NVSHMEM 的應(yīng)用程序的吞吐量和擴展能力。

代理啟動的通信

圖 1 .使用 CPU 代理啟動 NIC 通信的 GPU 通信會導(dǎo)致通信瓶頸

使用 NVLink 進(jìn)行節(jié)點內(nèi)通信可以通過 GPU 流式多處理器（ SM ）啟動的加載和存儲指令實現(xiàn)。然而，節(jié)點間通信涉及向網(wǎng)絡(luò)接口控制器（ NIC ）提交工作請求以執(zhí)行異步數(shù)據(jù)傳輸操作。

在引入 IBGDA 之前， NVSHMEM InfiniBand Reliable Connection （ IBRC ）傳輸使用 CPU 上的代理線程來管理通信（圖 1 ）。使用代理線程時， NVSHMEM 執(zhí)行以下操作序列：

應(yīng)用程序啟動 CUDA 內(nèi)核，在 GPU 內(nèi)存中生成數(shù)據(jù)。

應(yīng)用程序調(diào)用 NVSHMEM 操作（例如nvshmem_put）以與另一個處理元件（ PE ）通信。當(dāng)執(zhí)行細(xì)粒度或重疊通信時，可以在 CUDA 內(nèi)核內(nèi)調(diào)用此操作。 NVSHMEM 操作將工作描述符寫入主機內(nèi)存中的代理緩沖區(qū)。

NVSHMEM 代理線程檢測工作描述符并啟動相應(yīng)的網(wǎng)絡(luò)操作。

以下步驟描述了與 NVIDIA InfiniBand 主機通道適配器（ HCA ）（如 ConnectX-6 HCA ）交互時代理線程執(zhí)行的操作順序：

CPU 創(chuàng)建一個工作描述符，并將其排入工作隊列（ WQ ）緩沖區(qū)，該緩沖區(qū)位于主機內(nèi)存中。

此描述符指示請求的操作（如 RDMA 寫入），并包含源地址、目標(biāo)地址、大小和其他必要的網(wǎng)絡(luò)信息。

CPU 更新主機內(nèi)存中的門鈴記錄（ DBR ）緩沖區(qū)。此緩沖區(qū)用于恢復(fù)路徑，以防 NIC 將寫入數(shù)據(jù)丟棄到其門鈴（ DB ）。

CPU 通過向其 DB （ NIC 硬件中的寄存器）寫入來通知 NIC 。

NIC 從 WQ 緩沖區(qū)讀取工作描述符。

NIC 使用 GPUDirect RDMA 直接從 GPU 內(nèi)存復(fù)制數(shù)據(jù)。

NIC 將數(shù)據(jù)傳輸?shù)竭h(yuǎn)程節(jié)點。

NIC 通過將事件寫入主機存儲器上的完成隊列（ CQ ）緩沖區(qū)來指示網(wǎng)絡(luò)操作已完成。

CPU 輪詢 CQ 緩沖器以檢測網(wǎng)絡(luò)操作的完成。

CPU 通知 GPU 操作已完成。如果存在 GDRCopy ，則直接將通知標(biāo)志寫入 GPU 存儲器。否則，它會將該標(biāo)志寫入代理緩沖區(qū)。 GPU 在相應(yīng)的存儲器上輪詢工作請求的狀態(tài)。

雖然這種方法是便攜式的，可以為批量數(shù)據(jù)傳輸提供高帶寬，但它有兩個主要缺點：

CPU 周期被代理線程連續(xù)消耗。

由于代理線程存在瓶頸，您無法達(dá)到細(xì)粒度傳輸?shù)?NIC 吞吐量峰值?，F(xiàn)代 NIC 每秒可以處理數(shù)以億計的通信請求。雖然 GPU 可以以這種速度生成請求，但 CPU 代理的處理速度要低幾個數(shù)量級，這為細(xì)粒度通信模式造成了瓶頸。

InfiniBand GPUDirect 異步

圖 2 .使用 IBGDA 的 GPU 通信啟用從 GPU SM 到 NIC 的直接控制路徑，并從關(guān)鍵路徑中刪除 CPU

與代理啟動的通信不同， IBGDA 使用 GPUDirect Async – Kernel initiated （ GPUDirectAsync – KI ）使 GPU SM 能夠直接與 NIC 交互。這如圖 2 所示，涉及以下步驟。

應(yīng)用程序啟動 CUDA 內(nèi)核，在 GPU 內(nèi)存中生成數(shù)據(jù)。

應(yīng)用程序調(diào)用 NVSHMEM 操作（如nvshmem_put）以與另一個 PE 通信。 NVSHMEM 操作使用 SM 創(chuàng)建 NIC 工作描述符，并將其直接寫入 WQ 緩沖區(qū)。與 CPU 代理方法不同，此 WQ 緩沖區(qū)駐留在 GPU 內(nèi)存中。

SM 更新 DBR 緩沖區(qū)，該緩沖區(qū)也位于 GPU 存儲器中。

SM 通過寫入 NIC 的 DB 寄存器來通知 NIC 。

NIC 使用 GPUDirect RDMA 讀取 WQ 緩沖區(qū)中的工作描述符。

NIC 使用 GPUDirect RDMA 讀取 GPU 內(nèi)存中的數(shù)據(jù)。

NIC 將數(shù)據(jù)傳輸?shù)竭h(yuǎn)程節(jié)點。

NIC 通過使用 GPUDirect RDMA 寫入 CQ 緩沖區(qū)來通知 GPU 網(wǎng)絡(luò)操作已完成。

如圖所示， IBGDA 從通信控制路徑中消除了 CPU 。使用 IBGDA 時， GPU 和 NIC 直接交換通信所需的信息。 WQ 和 DBR 緩沖區(qū)也移動到 GPU 存儲器，以提高 SM 訪問時的效率，同時保留 NIC 通過 GPUDirect RDMA 的訪問。

Magnum IO NVSHMEM 評估

我們比較了 NVSHMEMIBGDA 傳輸和 NVSHMEMIBRC 傳輸?shù)男阅埽笳呤褂么砭€程來管理通信。這兩種傳輸都是標(biāo)準(zhǔn) NVSHMEM 分發(fā)的一部分。所有基準(zhǔn)測試和案例研究均在通過 NVIDIA ConnectX-6 200 Gb / s InfiniBand 網(wǎng)絡(luò)和 NVIDIA Quantum HDR 交換機連接的四臺 DGX-A100 服務(wù)器上運行。

為了突出 IBGDA 的效果，我們禁用了通過 NVLink 的通信。即使 PE 位于同一節(jié)點上，這也會強制通過 InfiniBand 網(wǎng)絡(luò)執(zhí)行所有傳輸。

單面輸入帶寬

我們首先運行了shmem_put_bw基準(zhǔn)測試，該測試包含在 NVSHMEM 性能測試套件中，并使用nvshmem_double_put_nbi_block發(fā)布數(shù)據(jù)傳輸。該測試測量使用單邊寫入操作在一系列通信參數(shù)上傳輸固定數(shù)量的總數(shù)據(jù)時所獲得的帶寬。

對于節(jié)點間傳輸，此操作在執(zhí)行網(wǎng)絡(luò)通信時使用線程塊中的一個線程，而不管線程塊中有多少線程。這是已知的，也稱為協(xié)作線程陣列（ CTA ）。在不同的 DGX-A100 節(jié)點上啟動了兩個 PE 。設(shè)置為每個線程塊一個線程，每個線程塊有一個 QP （ NIC 隊列對，包含 WQ 和 CQ ）。

圖 3 shmem_put_bwIBRC 顯示了當(dāng)您擴展到更多的 QP 和 CTA 時， CPU 代理對小消息大小造成的帶寬上限

圖 4 shmem_put_bw IBGDA 證明，隨著 CTA 和 QPs 數(shù)量的增加，小消息大小的帶寬可以擴展

圖 3 和圖 4 顯示了在不同數(shù)量的 CTA 和消息大小下，具有 IBRC 和 IBGDA 的shmem_put_bw的帶寬。如圖所示，對于具有大消息的粗粒度通信， IBGDA 和 IBRC 都可以達(dá)到峰值帶寬。當(dāng)應(yīng)用程序發(fā)出來自至少四個 CTA 的通信時， IBRC 可以用小到 16KiB 的消息使網(wǎng)絡(luò)飽和。

進(jìn)一步增加 CTA 的數(shù)量不會減少我們觀察到峰值帶寬時的最小消息大小。限制較小消息帶寬的瓶頸在 CPU 代理線程中。雖然這里沒有顯示，但我們也嘗試增加 CPU 代理線程的數(shù)量，并觀察到類似的行為。

通過消除代理瓶頸，當(dāng) 64 個 CTA 發(fā)出通信時， IBGDA 實現(xiàn)了峰值帶寬，消息小到 2 KiB 。這一結(jié)果突出了 IBGDA 支持更高級別通信并行性的能力以及由此帶來的性能改進(jìn)。

對于 IBRC 和 IBGDA ，每個 CTA 中只有一個線程參與網(wǎng)絡(luò)操作。換句話說，只需要 64 個線程（而不是 1024 × 64 個線程）就可以在 2 KiB 消息大小下實現(xiàn)峰值帶寬。

還表明， IBGDA 帶寬繼續(xù)隨著執(zhí)行通信的 CTA 的數(shù)量而擴展，而 IBRC 代理在四個 CTA 時達(dá)到其擴展極限。因此， IBGDA 為消息大小小于 1 KiB 的 NVSHMEM 塊放入操作提供了高達(dá) 9.5 倍的吞吐量。

提高小郵件的吞吐量

shmem_p_bw基準(zhǔn)使用標(biāo)量nvshmem_double_p操作將數(shù)據(jù)直接從 GPU 寄存器發(fā)送到遠(yuǎn)程 PE 。此操作是線程范圍的，這意味著調(diào)用此操作的每個線程都傳輸一個 8 字節(jié)的數(shù)據(jù)字。

在接下來的實驗中，我們?yōu)槊總€ CTA 啟動了 1024 個線程，并增加了 CTA 的數(shù)量，同時保持 QPs 的數(shù)量與 CTA 的數(shù)目相等。

圖 5 .國際復(fù)興開發(fā)銀行和國際銀行發(fā)展局之間的賣出率比較 shmem_p_bw 顯示了 IBGDA 在每秒發(fā)送數(shù)百萬條小消息方面的性能優(yōu)勢

另一方面， IBGDA 的 put 速率可以達(dá)到 180 MOPS ，接近 215 MOPS 的峰值 NIC 消息速率限制。該圖還顯示，如果滿足聚結(jié)條件， IBGDA 可以達(dá)到幾乎 2000 MOPS 。

圖 5 顯示，無論 CTA 和 QP 的數(shù)量如何， IBRC 的投入率（單位：百萬次操作/秒（ MOPS ））上限為 1.7 MOPS 左右。另一方面， IBGDA 的消息速率隨著 CTA 的數(shù)量而增加，接近 NVIDIA ConnectX-6 InfiniBand NIC 的 215 MOPS 硬件限制，只有 8 個 CTA 。

在該配置中， IBGDA 會根據(jù)nvshmem_double_p操作向 NIC 發(fā)出一個工作請求。這突出了 IBGDA 在涉及大量小消息的細(xì)粒度通信中的優(yōu)勢。

IBGDA 還提供了當(dāng)目標(biāo)地址在同一扭曲內(nèi)連續(xù)時的自動數(shù)據(jù)合并。此功能允許發(fā)送一條大消息，而不是 32 條小消息。對于希望將分散的數(shù)據(jù)直接從 GPU 寄存器傳輸?shù)侥康牡氐倪B續(xù)緩沖區(qū)的應(yīng)用程序來說，它非常有用。

圖 5 顯示了當(dāng)滿足數(shù)據(jù)合并條件時， put 速率可以達(dá)到超過 NIC 峰值消息速率。

Jacobi 方法案例研究

分析了 NVSHMEM Jacobi 基準(zhǔn) 的性能，以證明 IBGDA 在實際應(yīng)用中的性能與 IBRC 相比。該存儲庫包括 Jacobi 解算器的兩個 NVSHMEM 實現(xiàn)。

在第一個實現(xiàn)中，每個線程使用標(biāo)量nvshmem_p操作在數(shù)據(jù)可用時立即發(fā)送數(shù)據(jù)。眾所周知，該實現(xiàn)與 NVLink 配合使用效果良好，但與 IBRC 配合使用效果不佳。

第二種實現(xiàn)在每個 CTA 調(diào)用nvshmem_put_nbi_block以發(fā)起通信之前將數(shù)據(jù)聚合到連續(xù)的 GPU 緩沖器中。這種數(shù)據(jù)聚合技術(shù)與 IBRC 配合使用很好，但增加了 NVLink 上的開銷，其中nvshmem_p操作可以將數(shù)據(jù)從寄存器直接存儲到遠(yuǎn)程 PE 的緩沖區(qū)。這種不匹配突出了優(yōu)化給定代碼以實現(xiàn)放大和縮小時的一個挑戰(zhàn)。

圖 6 .使用 P 和 PUT 以及 IBRC 和 IBGDA 的 Jacobi 實現(xiàn)的延遲比較

圖 6 顯示， IBGDA 對小消息通信效率的改進(jìn)有助于解決這些挑戰(zhàn)。該圖表顯示了強縮放實驗中 Jacobi 內(nèi)核 1000 次迭代的延遲，其中 PE 的數(shù)量增加，同時保持固定的矩陣大小。使用 IBRC ，nvshmem_p版本的 Jacobi 的延遲是 nvshmem _ put 版本的 8 倍多。

另一方面，nvshmem_p和nvshmem_put版本均與 IBGDA 兼容，并與 NVLink 上nvshmem_p的效率相匹配。 IBGDA nvshmem_p版本與nvshmem_put與 IBRC 的延遲相匹配。

結(jié)果表明，與nvshmem_put相比，具有 IBGDA 的nvshmem_p具有略高的延遲。這是因為與發(fā)送許多小消息相比，發(fā)送一條大消息會導(dǎo)致較低的網(wǎng)絡(luò)開銷。

雖然這些開銷是網(wǎng)絡(luò)的基礎(chǔ)，但 IBGDA 可以通過并行向 NIC 提交許多小消息傳輸請求來使應(yīng)用程序隱藏這些開銷。

全對全延遲案例研究

圖 7.IBRC 和 IBGDA 之間 32 PE All to All 傳輸?shù)难舆t比較

圖 7 顯示了 IBRC 和 IBGDA 的 NVSHMEM 所有對所有集合操作的延遲，突出了 IBGDA 在小消息性能方面的優(yōu)勢。

對于 IBRC ，代理線程是來自設(shè)備的所有操作的序列化點。代理線程成批處理請求以減少開銷。然而，根據(jù)何時向設(shè)備提交操作，在設(shè)備上幾乎同時提交的操作可能會由代理線程的單獨循環(huán)處理。

代理的操作串行化會產(chǎn)生額外的延遲，并掩蓋 NIC 和 GPU 的內(nèi)部并行性。 IBGDA 結(jié)果顯示總體延遲更為一致，尤其是對于小于 16KiB 的消息。

Magnum IO NVSHMEM 提高了網(wǎng)絡(luò)性能

在本博客中，我們展示了 Magnum IO 如何提高小消息網(wǎng)絡(luò)性能，尤其是對于部署在 HPC 數(shù)據(jù)中心數(shù)百或數(shù)千個節(jié)點上的大型應(yīng)用程序。 NVSHMEM 2.6.0 引入了 InfiniBand GPUDirect Async ，它使 GPU 的 SM 能夠直接向 NIC 提交通信請求，繞過 CPU 在 NVIDIA InfiniBand 網(wǎng)絡(luò)上進(jìn)行網(wǎng)絡(luò)通信。

與管理通信的代理方法相比， IBGDA 可以在更小的消息大小下保持顯著更高的吞吐量。這些性能改進(jìn)對于需要強大擴展性的應(yīng)用程序尤其重要，并且隨著工作負(fù)載擴展到更大數(shù)量的 GPU ，消息大小往往會縮小。

IBGDA 還縮小了 NVLink 和網(wǎng)絡(luò)通信之間的小消息吞吐量差距，使您更容易優(yōu)化代碼，以在當(dāng)今 GPU 加速的 HPC 系統(tǒng)上進(jìn)行擴展和擴展。