GPU是如何進行算力管理的？

阿里妹導讀

本篇主要簡單介紹了在AI時代由‘大引數、大資料、大算力’需求下，對GPU算力管理和分配帶來的挑戰。以及面對這些挑戰，GPU算力需要從單卡算力管理、單機多卡算力管理、多機多卡算力管理等多個方面發展出來的業界通用的技術。

一、前言

目前很多關於大模型的文章和介紹都是在大模型的工程應用、演算法最佳化、Prompt工程、PAI、百鍊等多產品架構組合等。但是在關於這些AI/ML訓練任務的管理、任務流的分配、任務的排程關係，資料集的加速等支撐方面介紹比較分散。不同AI任務對於異構資源的排程、分配、隔離的需求是不同，不同的排程策略，對於任務的訓練時間、訓練結果也會產生差異。以及從客戶成本管理角度上看，在GPU卡越來越貴情景下，如何實現AI任務的排程對GPU等異構資源充分利用，實現GPU利用趨於飽和，儘可能減少idle的GPU core，實現效益最大化是至關重要的。

之前在一篇文章中介紹了NvidiaGPU架構的演進歷史及其在AI任務中的最佳化，重點探討了Nvidia透過提升GPU結構、記憶體系統（如HBM、L1/共享快取）以及GPU間互聯技術（如NVLink、NVSwitch）來滿足大模型時代對大資料處理和分散式計算的需求。

如上圖所示， AI任務對於GPU資源的利用方式，以任務視角切入GPU資源的排程，從宏觀到微觀可以劃分為：

雲邊端：雲-邊-端、多雲及混合組網下任務分配情況。不同任務分配對於整體架構的要求 GPU叢集資源排程：任務並行、序列；時間和空間的平衡。

多機多卡排程：多機器組網情況下，資源排程對於機器高速網路的拓撲需求。

單機多卡排程：資源排程對於GPU、CPU、PCIE、GDDR等組網感知。

單卡排程：單卡獨佔分配，單卡多工分配，多工隔離/共享。

此篇文章會基於GPU基礎，從GPU算力角度出發，探尋在面對AI時代帶來的‘大引數、大資料、大並行運算’場景下，客戶如何利用雲原生帶來的高效GPU算力管理能力，實現高GPU更高利用率，以便實現最佳效益。其中部分挑戰，目前也沒好的單一技術辦法，或者是客戶的AI的業務需要從整體平臺架構上去考慮解決途徑。

二、AI時代對GPU算力管理的挑戰

2.1 雲-邊-端業務對算力排程挑戰

目前客戶的整體技術架構朝著多雲/邊緣雲方向發展，一方面是客戶技術發展帶來的結果，另一方面是業務需求帶來的必然結果。那麼對於AI任務來說，之前在單一雲，或者單一節點上，只需要考慮任務的一次排程，即任務從開始到結束只需要被排程一次。但是在‘雲-邊-端’架構體系下，任務需要經歷多次排程，即任務會隨著端側具體的業務場景需要，會從雲、邊、端來回遷移。

下面舉個典型的案例，在汽車自動駕駛場景中：

雲：客戶使用的雲側的集中AI能力。整個架構中AI計算能力最強，延遲最高。

邊：客戶區域化中心AI能力（可能部分客戶沒有區域化中心），AI能力次之，延遲次之。

端：每一臺汽車的AI能力。AI能力最弱，延遲最低。由此可見，從雲-邊-端，對於汽車來說延遲是逐步增加的，可能是幾百ms-幾十ms-幾ms。

當汽車駕駛員沒有開啟自動駕駛能力時，相關的比如地圖、遊戲、音樂、智慧助手等任務會執行在汽車晶片上。
當開啟自動駕駛後，如果本地運算能力不夠。自動駕駛任務肯定要優先執行在汽車晶片上，其他的任務會被遷移排程到邊緣/雲側。
當自動任務駕駛任務結束後，雲/邊緣的任務又要被排程回汽車晶片。

2.2 AI任務特徵對GPU時間或空間挑戰

從計算core微觀上看，core處理程式遵循著分時排程的原則，單個執行緒佔用的資源不會超過一個core。但是從宏觀角度上看，一個任務所佔用的資源可以是少於一個core，也可以多個core，甚者多臺機器或伺服器。比如AI任訓練務的特徵‘大資料、大引數、大並行運算’往往需要大量的core參與資料搬運、資料訓練等。所以任務可以分為序列和並行。

序列處理意味著按順序逐一執行任務，通常適用於計算資源有限而任務尺寸較大的情況。這種方式透過增加計算時間來減少對計算資源的需求。

並行處理則是同時執行多個任務片段，利用更多的計算資源來縮短總的計算時間，這被稱為並行加速。當面對長時間執行的任務時，可以透過將其拆解為多個短任務並在不同的計算資源上並行執行，以此達到節省時間的效果。

現階段一方面GPU資源很緊俏，非常難購買，即使購買到，GPU卡之間的拓撲結果、多臺機器之間的拓撲結果對任務的訓練時間也有很大的影響；另一方面企業的AI任務多種多樣，也不可能專門為每一種AI任務單獨適配GPU卡分配。所以更多的期望是將有限的GPU資源池化後，由統一的平臺實現這些GPU資源面對不同的AI任務，實現不同的資源排程，以便實現GPU資源利用率和AI任務預期結果的雙贏的記過。

2.3 資料量對大規模計算排程挑戰

隨著AI訓練帶來的引數量和資料量的增長，單機器的訓練能力已經不滿足AI任務的需求，訓練模式逐漸被叢集訓練所取代，Nvidia除了推出GPU卡外，也推出了了比如GB200這種多機器的組合叢集。

儘管從AI叢集上看，是個單一的訓練任務，但是其實內部會被拆分成多個子服務執行在不同的GPU伺服器上的GPU卡上。這裡的核心挑戰在於如何管理和最佳化這些小任務之間的互動，當不同任務所需要的資料儲存在其他機器上時，如何快速的搬運這些資料時提高整體AI訓練的關鍵。

2.4 任務特性對算力管理的挑戰

對於阿里雲的GPU機器，比如gn8v，ebmgn8v等提供一機一卡/一機兩卡/一機四卡/一機八卡等多種規格應對不同的AI任務對算力的需求。但是這些卡數的增加不是算力上的純粹增加，其實還涉及到AI任務對於GPU資源排程的分配情況。如果同一個AI任務在無NVLINK情況下，任務分配到同一個CPU下的多個GPU卡，和分配到不同CPU下的GPU卡相比是減少了CPU的接入和切換的。如果不同CPU下GPU之間有資料互動鏈路，其實跨CPU排程其實影響不大。所以在多機多卡情況下，機器的GPU、CPU、網路、記憶體等拓撲鏈路對於排程分配是很重要的。

2.5 多工系統對任務管理的挑戰

現代計算已經從單機模式進化到叢集計算，並進一步擴充套件至跨叢集、跨資料中心乃至雲邊端協同和融合計算。一方面一個大型的資源系統可能執行著來自不同業務部門不同的業務任務，另一方面單個GPU卡的core心越來越多，在GPU-to-GPU的頻寬受限情況下，如何讓不同業務方的任務並行/獨享執行，並能對不同的任務做好資料快取間的隔離和資源QoS保障，也是需要考慮的方面。

三、GPU算力管理

3.1 算力管理概覽

拋開任務管理層面，也就是把上一節的‘雲-邊-端’和‘GPU叢集任務排程’暫且不討論，原因是這兩部分已經不單單是某個產品，或某一個技術能實現的，這個需要客戶從最開始的業務架構的規劃、到AI任務管理平臺，再到硬體層面的拓撲架構等多方面的技術整合和選型，才能滿足所需的AI任務的預期管理。本節主要聚焦在為了滿足業務的不同GPU資源使用的訴求，單卡排程、單機多卡排程和多機多卡排程所發展出來的基礎技術。

3.2 單GPU卡算力管理

3.2.1 MPS（單卡多執行緒並行）

多程序服務（MPS）是對 CUDA 應用程式設計介面（API）的一種替代性實現，並且與原有的二進位制程式碼相容。MPS 的執行時架構旨在透明地支援協作式的多程序 CUDA 應用，主要是訊息傳遞介面（MPI）任務。MPS時Nvidia在Pascal架構引入的，並在Volta架構中進一步的完善。Volat-MPS相比較之前的MPS，主要在以下幾個方面做了提升：

直接提交任務至 GPU：Volta MPS 客戶端可以直接向 GPU 提交任務，無需透過 MPS 伺服器。
獨立的 GPU 地址空間：每個 Volta MPS 客戶端擁有獨立的 GPU 地址空間，不與其他客戶端共享。
有限的執行資源分配以保證服務質量 (QoS)：Volta MPS支援有限的執行資源分配，以確保服務質量。

MPS優勢

提高GPU利用率：MPS使不同程序的核心和記憶體複製操作可以在GPU上併發執行，提升GPU利用率並加快任務完成速度。
減少GPU上下文儲存：MPS伺服器為所有客戶端共享一份GPU儲存和排程資源，減少了資源佔用。
減少GPU上下文切換：透過共享排程資源，MPS消除了程序間切換的開銷，提高了效率。

適用應用場景

MPS特別適用於那些單個程序不足以飽和GPU的應用。透過在同一節點上執行多個程序，MPS增強了併發性。適用於每網格塊數較少的應用；若應用因每網格執行緒數少而GPU佔用率低，使用MPS可提升效能。在強擴充套件場景中，MPS能有效利用剩餘的GPU容量，讓不同程序的核心併發執行，最佳化計算效率。

限制

相關限制

A. 系統限制

作業系統支援：MPS 僅支援 Linux 作業系統。在非 Linux 作業系統上啟動 MPS 伺服器將導致啟動失敗。

Tegra 平臺支援：僅支援 Volta MPS 在 Tegra 平臺上執行。

GPU計算能力要求：MPS 需要計算能力版本為 3.5 或更高的 GPU。如果在應用 CUDA_VISIBLE_DEVICES環境變數後可見的任何一個 GPU 的計算能力低於 3.5，MPS 伺服器將無法啟動。

統一虛擬定址 (UVA)：CUDA 的 UVA 功能必須可用，預設情況下，任何在計算能力版本為 2.0 或更高的 GPU 上執行的 64 位 CUDA 程式都啟用了 UVA。如果 UVA 不可用，MPS 伺服器將無法啟動。

頁鎖定主機記憶體限制：MPS 客戶端可以分配的頁鎖定主機記憶體量受限於 tmpfs 檔案系統 (/dev/shm) 的大小。

獨佔模式限制：獨佔模式限制應用於 MPS 伺服器，而不是 MPS 客戶端。Tegra 平臺不支援 GPU 計算模式。

使用者限制：一個系統上只能有一個使用者擁有活躍的 MPS 伺服器。

使用者排隊機制：MPS 控制守護程序會將來自不同使用者的 MPS 伺服器啟用請求排隊，不管GPU獨佔設定如何，也會導致使用者之間對 GPU 的序列獨佔訪問。

行為歸因：系統監控和會計工具（例如 nvidia-smi、NVML API）將所有 MPS 客戶端的行為歸因於 MPS 伺服器程序。

B. GPU計算模式限制

nvidia-smi支援設定三種Compute Mode：

PROHIBITED：GPU對所有Compute應用都不可用
EXCLUSIVE_PROCESS：GPU一次只分配給一個Context（CPU程序），單個CPU程序的執行緒可以同時向 GPU提交工作
DEFAULT：多個CPU程序可以同時使用 GPU。每個程序的各個執行緒可以同時向 GPU 提交工作。

使用 MPS 實際上會使 EXCLUSIVE_PROCESS 模式對所有 MPS 客戶端表現得像 DEFAULT 模式一樣。MPS 總是允許多個客戶端透過 MPS 伺服器使用 GPU。在使用 MPS 時，建議啟用 EXCLUSIVE_PROCESS 模式，以確保只有一個 MPS 伺服器使用該 GPU。這提供了額外的保障，確保 MPS 伺服器是該GPU上所有 CUDA程式的唯一入口。

C. 應用限制

NVIDIA編解碼SDK不支援：NVIDIA影片編解碼SDK在Volta架構之前的MPS客戶端上不受支援。

僅支援64位應用：只有64位應用程式被支援。

CUDA驅動API版本要求：如果應用程式使用CUDA驅動API，則必須使用CUDA 4.0或更高版本的標頭檔案。

不支援動態並行：如果模組使用了動態並行特性，CUDA模組載入將會失敗。

UID一致性要求：MPS伺服器僅支援與伺服器具有相同使用者ID（UID）的客戶端執行。如果伺服器和客戶端的UID不同，客戶端應用程式將無法初始化。

流回調不支援：在Volta架構之前的MPS客戶端上不支援流回調。呼叫任何流回調API將返回錯誤。

CUDA圖不支援：Volta MPS 之前的Client上，MPS 不支援具有主機節點的 CUDA Graph。

頁鎖定主機記憶體限制：MPS Client應用能夠請求的page-locked host memory數量受tmpfs檔案系統限制（/dev/shm）

MPS客戶端終止的影響：在未同步所有未完成GPU工作的情況下終止MPS客戶端（例如透過Ctrl-C、程式異常如段錯誤、訊號等），可能會使MPS伺服器和其他MPS客戶端處於未定義狀態，導致掛起、意外失敗或資料損壞。

CUDA IPC支援：由MPS Client建立的CUDA Context與沒有使用MPS 建立的CUDA Context之間的CUDA IPC通訊在Volta MPS是支援的

參考網站：https://docs.nvidia.com/deploy/mps/index.html

3.2.2 MIG（單卡單視訊記憶體多租戶執行緒物理隔離）

使用MIG，每個例項的處理器在整個記憶體系統中都有獨立的路徑——片上交叉開關埠、L2快取庫、記憶體控制器和DRAM地址匯流排都唯一分配給一個例項。這確保了單個使用者的工作負載可以以可預測的吞吐量和延遲執行，具有相同的L2快取分配和DRAM頻寬，即使其他任務正在衝擊自己的快取或飽和其DRAM介面。MIG可以分割可用的GPU計算資源（包括流式多處理器或SM和GPU引擎，如複製引擎或解碼器），以提供定義的服務質量（QoS），併為不同的客戶端（如虛擬機器、容器或程序）提供故障隔離。

從NVIDIA安培一代開始的gpu（即具有計算能力>= 8.0的gpu）支援MIG。下表提供了支援的gpu列表：

GPU在MIG中分為GI和CI單元，其中CI單元是GI單元的subset，共享GI單元的共享記憶體和帶框。而GI之間的算力在物理層面是隔離的。而GI是 GPU 切片和 GPU 引擎（DMA、NVDEC 等）的組合。GI內的任何內容總是共享所有記憶體和其GPU，但其SM切片可以進一步細分為CI。GI提供記憶體級別的QoS，每個GPU slice包含專用的GPU記憶體資源，這些資源限制了可用容量和頻寬，並提供記憶體QoS。每個GPU記憶體切片獲得總物理層面GPU 記憶體資源的 1/8，每個 GPU SM 切片獲得總物理層面SM數量的1/7。CI包含父GI的SM切片和其它GPU引擎（DMA、NVDEC 等）的子集，其共享記憶體和引擎。比如下圖是A100卡可以劃分的MIG型別。

相關特性：

提高資源利用率：MIG允許從NVIDIA Ampere架構開始的GPU被安全地分割成最多七個獨立的GPU例項，用於CUDA應用程式，為多個使用者提供獨立的GPU資源以實現最佳的GPU利用率。
多租戶物理隔離：對於具有多租戶使用案例的雲服務提供商（CSP），MIG確保一個客戶不會影響其他客戶的工作或排程，同時提供增強的隔離。

相關限制：

A. 系統限制作業系統支援：MIG 僅支援由 CUDA 支援的 Linux 作業系統發行版。

支援配置：裸金屬、容器、

GPU需要重置：在 A100/A30 上設定 MIG 模式需要 GPU 重置（因此需要超級使用者許可權）。

配置持久化：MIG配置是永續性的，不會隨著系統重啟而被重置。

驅動限制：所有持有驅動程式模組控制代碼的守護程序需要在啟用 MIG 之前停止。

許可權配置：切換 MIG 模式需要 CAP_SYS_ADMIN 能力。其他 MIG 管理，如建立和銷燬例項，預設需要超級使用者，但可以透過調整 /proc/ 中 MIG 能力的許可權委託給非特權使用者。

B. 應用限制

圖形不支援：不支援圖形API（例如OpenGL、Vulkan等）。

不支援G2C：不支援GPU到GPU的P2P（無論是PCIe還是NVLink）。

物理隔離：CUDA應用程式將計算例項及其父GPU例項視為單個CUDA裝置。

跨例項呼叫限制：不支援跨GPU例項的CUDA IPC。跨計算例項的CUDA IPC是支援的。

MPS支援：CUDA MPS在MIG之上支援。唯一的限制是最大客戶端數（48）會根據計算例項的大小按比例降低。

GDR支援：當從GPU例項使用時，支援GPUDirect RDMA。

參考文件：https://docs.nvidia.com/datacenter/tesla/pdf/NVIDIA_MIG_User_Guide.pdf

3.2.3 阿里雲cGPU（單卡算力和視訊記憶體分配）

GPU容器共享技術cGPU是阿里雲基於核心虛擬GPU隔離的容器共享技術。即多個容器共享一張GPU卡，從而實現業務的安全隔離，提高GPU硬體資源的利用率並降低使用成本，可以實現視訊記憶體或算力兩個維度的隔離和組合。

適用應用場景

相容性好：適配標準的Docker和Containerd工作方式，無縫相容k8s。

操作簡單：無需重編譯AI應用，執行時無需替換CUDA庫。

資源靈活劃分：物理GPU的資源可以進行任意劃分。

GPU例項規格無限制：GPU裸金屬例項，虛擬化例項，vGPU例項等各種GPU例項。

應用場景豐富：支援在離線混部業務、支援CUDA AI和渲染應用場景。

功能強大：高優先順序搶佔功能和較高可運維能力，支援熱升級、支援多卡劃分功能。

共享GPU排程的檔案可以在系統的procs中找到，路徑是/proc/cgpu_km

[root@xxx cgpu_km]# tree

├── 0 #GPU序號

│ ├── aaa7d95f0dbf #被呼叫在此的容器ID

│ │ ├── highprio #容器優先順序

│ │ ├── id

│ │ ├── meminfo #視訊記憶體和剩餘視訊記憶體大小

│ │ ├── memsize #容器內的視訊記憶體大小

│ │ └── weight #容器獲取顯示卡最大算力的權重，預設值為1

│ ├── free_weight #該GPU分配pod的權重

│ ├── major

│ ├── max_inst #用於設定容器的最大數量，取值範圍為1~25

│ ├── policy #cGPU算力排程策略

│ └── prio_ratio #高優先順序容器最大可以搶佔的算力。取值範圍：20~99。

├── 1

│ ├── free_weight

│ ├── major

│ ├── max_inst

│ ├── policy

│ └── prio_ratio

├── default_memsize #如果沒有設定ALIYUN_COM_GPU_MEM_CONTAINER引數

├── inst_ctl

├── upgrade #控制熱升級

└── version #cgpu裝置版本號

ALIYUN_COM_GPU_MEM_DEV	設定GPU例項上每張顯示卡的總視訊記憶體大小。該引數值與例項規格有關，視訊記憶體大小按GiB取整數。對於ecs.gn6i-c4g1.xlarge例項，配備1張NVIDIA Tesla T4顯示卡，在GPU例項上執行nvidia-smi可檢視總視訊記憶體大小。
ALIYUN_COM_GPU_MEM_CONTAINER	設定容器內可見的視訊記憶體大小，與ALIYUN_COM_GPU_MEM_DEV結合使用。例如：在一張總視訊記憶體大小為15 GiB的顯示卡上，設定ALIYUN_COM_GPU_MEM_DEV=15 和ALIYUN_COM_GPU_MEM_CONTAINER=1，即效果表示為容器分配1 GiB的視訊記憶體。設定為0或未設定表示停用cGPU。

cGPU算力分配策略

cGPU服務載入cgpu_km的模組時，會按照容器最大數量（max_inst）為每張顯示卡設定時間片（X ms），用於為容器分配GPU算力。

Policy	說明
平均排程（policy=0）	在建立容器時，為容器分配時間片。cGPU服務會從Slice 1時間片開始排程，提交任務到物理GPU，並執行一個時間片（X ms）的時間，然後切換到下一個時間片。每個容器獲得的算力相同，都為1/max_inst。
搶佔排程（policy=1）	在建立容器時，為容器分配時間片。cGPU服務會從Slice 1開始排程，但如果沒有使用某個容器，或者容器內沒有程序開啟GPU裝置，則跳過排程，切換到下一個時間片。
權重搶佔排程（policy=2）	如果在建立容器時設定ALIYUN_COM_GPU_SCHD_WEIGHT大於1，則自動使用權重搶佔排程。cGPU服務按照容器數量（max_inst）將物理GPU算力劃分成max_inst份，但如果ALIYUN_COM_GPU_SCHD_WEIGHT大於1，cGPU服務會將多個時間片組合成一個更大的時間片分配給容器。
固定算力排程（policy=3）	透過指定ALIYUN_COM_GPU_SCHD_WEIGHT和max_inst的佔比，固定算力的百分比。
算力弱排程（policy=4）	為容器分配時間片，隔離性弱於搶佔排程。
原生排程（policy=5）	只用來做視訊記憶體的隔離。原生排程表示NVIDIA GPU驅動本身的排程方式。

3.3 單機多卡GPU算力管理

3.3.1 PCIE&NVLink&NVSwitch（單機多卡組合）

PCIE裝置在單機內可以實現多個裝置的資料傳輸，比如上圖就是一個典型的8卡機器內的，GPU透過PCIE實現裝置之間的互聯，但是NIC、NVME、GPU是共享一個PCIE的總頻寬的。如果涉及跨CPU的GPU之間通訊，則會被CPU之間的鏈路限制。比如圖示的GPU0-GPU1會收到PCIE0的影響，GPU3-GPU5會經過兩個CPU之間的互動。所以資源排程使用的GPU間拓撲架構對任務整體表現是具有很大影響的。

除了PCIE可以實現將單機的GPU卡互聯，實現算力的切換掉配，但是PCIE的頻寬是多個裝置共享，並且最新的gen5 雙向頻寬只有64GB/s，遠遠小於大模型時代資料搬運的需求。NVLink Nvidia開發的是一種雙向 GPU-GPU 直接互連技術，其5.0版本可提供高達 1800 GB/s 的頻寬，比 PCIe 5.0 高出14倍。它連線了英偉達的 Grace CPU 和 Hopper GPU，顯著增強了處理大規模AI模型的能力。作為先進的互聯標準，NVLink 不僅優化了匯流排設計和通訊協議，還透過點對點架構和序列傳輸技術提高了資料交換效率。NVSwitch，作為一個獨立的 NVLink 晶片，支援最多18個 NVLink 連線，進一步提升了多GPU環境中資料流通的速度和並行處理複雜任務的效率。

但是雖然GPU之間繞過了PCIE網絡卡的限制，但是GPU之間的通訊能力，取決於NVLink的數量，如圖所示GPU0-GPU6只有1條NVLink，GPU3-GPU5之間有2條。在Ampere架構之後，Nvidia引入了NVSwitch，使單個機器內任何GPU卡之間的頻寬鏈路獲得了一致性，並且在Hopper架構中將NVLink引入到了機器之間，實現了伺服器組的多GPU卡聯通的一致性。這也是為什麼客戶AI任務需要了解底層GPU拓撲架構，不同的架構也需要適配不同的算力排程分配。

3.3.2 阿里雲cGPU（多卡算力和視訊記憶體分配）

cGPU多卡算力和視訊記憶體分配策略

在3.2.3中已經介紹了阿里雲cGPU以及相關的單卡算力和視訊記憶體分配，可以參考下面的配置給程式配置單機多卡的視訊記憶體和算力的組合分配。

ALIYUN_COM_GPU_VISIBLE_DEVICES

指定容器內可見的GPU顯示卡。

ALIYUN_COM_GPU_VISIBLE_DEVICES=0,1：表示為容器分配第1和第2張顯示卡。

ALIYUN_COM_GPU_MEM_CONTAINER

設定容器內可見的視訊記憶體大小，與ALIYUN_COM_GPU_MEM_DEV結合使用。

ALIYUN_COM_GPU_MEM_CONTAINER=3：表示所有卡視訊記憶體都被設定為3G

ALIYUN_COM_GPU_MEM_CONTAINER=3,1：表示卡的視訊記憶體依次被設定為3G、1G、1G、…1G

ALIYUN_COM_GPU_MEM_CONTAINER=3,4,5,6: 視訊記憶體依次被設定為3G、4G、5G、6G

ALIYUN_COM_GPU_MEM_CONTAINER未設定、包含0:停用cGPU服務

3.4 多機多卡GPU算力管理

3.4.1 NVSwitch

在Hopper架構中中，Nvidia引入了基於模組化的MGX平臺的GB200伺服器，最多可以連結32個GPU，所有 GPU 執行緒能夠訪問高達 19.5TB 的記憶體，總頻寬高達 900GB/s，以及高達 14.4TB/s 的頻寬。

參考資料：https://resources.nvidia.com/en-us-grace-cpu/nvidia-grace-hopper?ncid=so-link-252431-vt04

3.4.2 RDMA

RDMA，全稱 Remote Direct Memory Access（遠端直接記憶體訪問），是一種高效能網路通訊機制。它使一臺計算機能夠直接訪問另一臺計算機的記憶體，而無需作業系統核心或CPU的干預。這種方式可以顯著減輕CPU的負擔，提升資料傳輸速度，降低延遲，並增強整體計算效率。

技術特點-優點

高效能與低延遲：應用程式直接和網絡卡互動進行網路通訊，繞過了核心和CPU切換，降低了CPU使用率，降低了資料傳輸也延遲。

高資料傳輸：資料傳輸無需將複製到網路層，減少資料複製開銷，提高資料傳輸效率。

大規模平行計算：支援多個獨立的通訊流，可在不同的計算節點之間實現高效的資料交換和同步。

快速記憶體訪問：允許遠端節點直接訪問本地記憶體。

硬體off-load：將網路協議棧的處理解除安裝到網絡卡硬體上，減輕CPU的負擔。

技術特點-缺點

專用硬體裝置：需要特定的軟硬體匹配，不是所有的作業系統和網路裝置都支援RDMA。

安全性：允許遠端節點直接訪問本地記憶體，這可能會帶來一些安全性問題。

程式設計複雜性：需要人員對記憶體管理和井發機制有深入的理解。

網路規模限制：RDMA的設計目標是高效能和低延遲，因此它對於網路的穩定性和可靠性要求高，

高成本：需要特定的網絡卡硬體支援，硬體廠商少。

技術分類

按照技術分類，RDMA技術可以分為IB、RoCE和iWARP三種：

IB：L2到L4到需要自己的專用硬體，裝置成本最高

RoCE：可以使用乙太網的交換裝置，將IB的報文封裝成乙太網包進行收發，低成本IB方案。

iWarp：基於TCP/IP協議，相比於RoCE v2和IB具有更好的可靠性，在大規模組網時，優勢明顯。但是效能iWARP要比UDP的RoCE v2和IB差。

技術分類	IB	RoCE	RoCE v2	iWarp
協議	IB專有協議	乙太網	乙太網/UDP	乙太網/TCP
裝置要求	專有硬體和交換機裝置	支援在已有的乙太網(支援PFC)上使用RDMA 網絡卡將RDMA操作轉換成乙太網資料包	在RoCE基礎上使用UDP包傳輸支援Vxlan多租支援跨交換機	使用TCP來實現可靠傳輸
效能	高	中	中	差
成本	高	中	中	低
裝置廠商	nvidia mellanox	nvidia mellanox intel	nvidia mellanox intel	intel eRDMA(底層網路為阿里雲VPC)

3.4.3 阿里雲eRDMA

eRDMA是阿里雲自研的雲上彈性RDMA網路，底層鏈路複用VPC網路，採用全棧自研的擁塞控制CC（Congestion Control）演算法，享有傳統RDMA網路高吞吐、低延遲特性的同時，可支援秒級的大規模RDMA組網。可相容傳統HPC應用、AI應用以及傳統TCP/IP應用。

傳統TCP/IP協議由於其固有的侷限性，如較大的複製開銷、厚重的協議棧處理、複雜的擁塞控制（CC）演算法以及頻繁的上下文切換等，在面對資料中心業務對網路效能日益增長的需求時，逐漸成為應用效能提升的瓶頸。為解決這些問題，遠端直接記憶體訪問（RDMA）技術應運而生，它透過實現零複製和核心旁路等功能，大幅減少了資料傳輸中的延遲與CPU佔用，並提高了吞吐量。然而，由於成本高昂且運維複雜，RDMA的應用範圍受到了限制。針對這一問題，阿里雲開發了增強型RDMA（eRDMA），旨在提供一種在雲端普及的解決方案，既保持了RDMA低延遲的優勢，又降低了部署和使用的門檻，使得更多應用程式能夠受益於更優的網路效能。eRDMA預設採用iWarp模式，相比較IB，RoCE，不需要專門的RDMA裝置，與預設的VPC網路互通，成本最低，有豐富的組網和彈性拓展能力。

功能優勢

高效能：ReRDMA繼承RDMA優勢，應用於VPC中，提供低延遲效能。

普惠：eRDMA免費啟用，購買例項時勾選即可，無需額外付費。

規模部署：eRDMA採用自研CC演算法，適應VPC網路變化，在有損環境中保持良好效能，簡化大規模部署。

彈性擴充套件：eRDMA基於神龍架構，支援ECS例項中動態新增和熱遷移，部署靈活。

共享VPC網路：eRDMA透過ENI複用現有網路資源，不改變業務組網即可啟用RDMA功能，便於整合。

官方已經提供比較詳細的eRDMA資訊，可以參考：https://help.aliyun.com/zh/ecs/user-guide/elastic-rdma-erdma/

3.4.3 GDR

GPUDirect RDMA 是一種在 Kepler GPU和CUDA 5.0 中引入的技術，它利用 PCI Express的標準功能實現 GPU和第三方裝置之間的直接資料交換。第三方裝置包括網路介面、影片採集裝置和儲存介面卡。GPUDirect RDMA 支援 Tesla 和 Quadro GPU。

傳統上，資料在GPU和另一個裝置之間傳輸時，必須透過CPU，這導致潛在的效能瓶頸和延遲增加。GPUDirect技術則透過繞過CPU，直接訪問和傳輸資料，顯著提高系統性能。在設定 GPUDirect RDMA 通訊時，從 PCI Express 裝置的角度來看，所有物理地址對兩個對等裝置都是相同的。在這個物理地址空間中，有線性視窗稱為 PCI BAR。每個裝置最多有六個 BAR 暫存器，因此可以有最多六個活躍的 32 位 BAR 區域。64 位 BAR 消耗兩個 BAR 暫存器。PCI Express 裝置以與系統記憶體相同的方式對對等裝置的 BAR 地址進行讀寫。

參考連結：https://docs.nvidia.com/cuda/gpudirect-rdma

四、小結

本篇主要簡單介紹了在AI時代由‘大引數、大資料、大算力’需求下，對GPU算力管理和分配帶來的挑戰。以及面對這些挑戰，GPU算力需要從單卡算力管理、單機多卡算力管理、多機多卡算力管理等多個方面發展出來的業界通用的技術，比如Nvidia的MPS、MIG、NVLink&NVSwitch，阿里雲的cGPU、RDMA和阿里雲eRDMA。這些技術的出現為客戶充分的按需呼叫GPU資源，將多個GPU資源組合成GPU叢集資源創造了條件了。

但是對每個GPU卡進行算力資源管理、組網管理、環境配置等等這些，對AI任務科學家來說是個巨大挑戰；同時對於客戶來說，業務時面向不同租戶的，不同租戶有不同的AI任務，AI任務需要的GPU資源、AI任務的優先順序，AI任務型別、時效性都是不同的。

所以需要一箇中間的平臺體系，將GPU資源透過一個平臺整合，面對不同的AI任務需求，可以做到不同的分配策略和互相隔離。

OpenLake大資料&AI一體化解決方案

本方案是基於開放可控資料湖倉構建的大資料/搜尋/AI一體化解決方案。透過元資料管理平臺DLF管理結構化和半/非結構化資料，提供湖倉資料表和檔案的安全訪問及IO加速。支援多引擎對接和平權協同計算，透過DataWorks統一開發，並保障大規模任務排程。

點選閱讀原文檢視詳情。