Source: iSlide

Gemini GPU Partitioning 分割共享簡介

Patrick Fu
Gemini Open Cloud 雙子星雲端
11 min readJul 2, 2021

--

GPU 共享的目標

前兩篇分別介紹了 K8S scheduler機器學習工作共享實體 GPU 的好處,今天讓我們把這兩個概念連接起來,介紹一下我們和清大 LSA Lab合作的專案 Gemini ,是如何實現 GPU 分割共享 (GPU Partitioning) 的解決方案。

要做到分割並共享實體GPU,我認為需要解決以下四個基本目標:

  1. 多個機器學習專案可以被派送到同一個GPU上,但在同一個時間上,各個專案的硬體資源必須完全隔離。
  2. 實體GPU資源能彈性分割,不一定每個專案都得平分實體GPU資源。
  3. 儘量提高GPU 的使用率,同時儘量減低管理的overhead
  4. 使用者無須修改現有程式,就能使用分割GPU 的功能。

使用分割 GPU 容器的生命週期

Gemini 設計了一種新的 POD kind,叫 SharePOD。從一個Kubernetes使用者的角度,使用這個 Gemini分割GPU 的容器 (SharePOD)跟普通的POD並沒有什麼差別。這也是上述目標4,使用者無須修改任何程式就可以使用分割後的GPU的目的。但在底層的實現上,Gemini 還是選用了K8S CRD 的功能,去客製化一個可以管理 SharePOD 的 scheduler,並設計了一些可以在K8S Slave node 上部署跟管理虛擬GPU的相關元件,去管理虛擬GPU跟派送SharePOD,並達成多專案可共享一個實體GPU 的目的:

Gemini 設計的 SharePOD,對於使用者而言,這和其他的 kind 沒有差別。唯一先決條件就是系統管理員要先定義好一組可以使用虛擬GPU的 POD Flavor。

虛擬 GPU Flavor 的意義是,它可以使用 RequestLimit 來控制單個容器的 GPU 計算資源的使用範圍。Request 確保容器能夠獲得其所需要的虛擬GPU資源,例如有 1/2、1/4、1/8 的實體 GPU 等等,讓最起碼的虛擬 GPU 資源能得到保障與預留。而相反地,Limit 確保容器不能使用超過特定值的虛擬 GPU 資源,如果把 Limit 設定為 100%,就是在該實體 GPU 沒有其他工作負載在共用的時候,這個 SharePOD 可以使用到整個實體GPU的意思。

這個設計是為了達到上述「彈性資源分割」的目標。機器學習容器最起碼能享用到 Request 保障額度的虛擬GPU,但在整個實體GPU沒有被佔滿情況下,容器則可彈性地使用到更多的GPU資源,以可提高GPU整體的使用率。

使用者只要在部署 SharePOD 容器時,選擇一個有虛擬GPU的Flavor,就可以直接在容器內,使用分割後的GPU,無須修改其他部署容器的參數。

誠如前篇文章介紹 K8S scheduler 的 Filtering 跟 Scoring 的 Policy,SharePOD 的 scheduler 還是會根據這些條件去選擇可以派送容器的K8S worker,但SharePOD scheduler 會多加考慮的,就是 Device manager 目前記錄其他 SharePOD 所用到的實體GPU 資源,來決定把SharePOD派送到哪一個K8S worker node 上。這個設計的目的,是為了增加GPU整體使用率,也同時減低碎片化(Fragmentation)的問題。

虛擬GPU 的概念

當SharePOD scheduler 選了最理想的 K8S worker node 後,Gemini Device Manager 除了會在這個worker node上部署SharePOD外,還會在 slave node 上部署一個虛擬GPU的dummy POD,並把這個 SharePOD 的資料存到Gemini 的config DB 內。虛擬 GPU dummy POD 的目的,就是為了達成 CUDA compatibility,讓CUDA以為這個實體GPU已經被分派給一個容器,這樣子使用者就不用改動任何的程式,安心地使用Gemini分割後的GPU。

圖二.Device Manager 功能

Device Manager 另外一項重要任務,就是要記錄實體GPU被分割使用的狀況,好讓SharePOD scheduler將下一個虛擬GPU可以指派到這個實體GPU上,以達成多個專案共享GPU的目的。我們下面會介紹這個功能。圖二表示了上述的 Device Manager 功能。

以上描述了 Gemini GPU Partitioning 功能的後台,意即在K8S master node 上運作的部份。接下來介紹 Gemini GPU Partitioning 的前台,就是在每一個K8S worker 上的運作。這裡大致上可再分為兩部份:一是監控SharePOD上虛擬GPU的使用量。二是更有效去使用GPU分割的time slice(GPU kernel burst)。我們先來談一下虛擬GPU 監控。

監控虛擬GPU的使用量

如前文所述,在SharePOD上掛載的虛擬GPU所執行的GPU kernel,有著非同步(asynchronous) 與 Non-Preemptive 的特性。因此 SharePOD 的scheduler,沒有辦法先訂定一個 time slice,去限制這些GPU kernel在GPU上執行的時間。

要彈性分割GPU給不同的專案使用,Gemini的SharePod scheduler就一定要知道目前每個SharePOD使用了多少GPU的資源。所以我們一定要在GPU kernel 執行結束後,去收集虛擬GPU使用資源的數量,再去決定scheduler 下來要派送的SharePOD。

Gemini GPU Partitioning 設計了一個CUDA GPU跟CPU 同步event的監控機置。同步event是表示CPU等待 GPU kernel 執行結束,這時候Monitor 就可以把GPU kernel 執行的資訊,回傳給在後台上的Device manager,寫到config DB內。

CUDA 同步event Monitor,是一個CUDA runtime library的API hook。我們選擇這個方式的另一個原因,就是因為它保持了CUDA程式的透明度( Transparency),讓使用者不須追加任何原始碼就可以收集到虛擬GPU 的資源使用資訊。

GPU Kernel burst

CUDA 同步event是用來block CPU等待GPU kernel執行結束,所以它是一個很昂貴的指令。假如我們在每一次GPU kernel結束時都做一次同步,對效能的影響會很大。

尤其近年GPU的功能愈來愈強大,強大到總是等待CPU派送下一個kernel過來,因此Gemini GPU Partitioning設計了GPU kernel burst功能,試圖在同一個GPU time slice內,執行多個GPU kernel,來減低 performance overhead。

圖三是一個簡單描述kernel burst 的概念。 K1到Kn代表GPU kernel,S1到Sn 代表Sync event。在第一個 Sync event 發生時,GPU 已經執行了K1和K2,這時候 Gemini 的event Monitor就會把K1和K2的資源使用量回傳到後台的Device Manager。這樣GPU空轉的時間,就會大幅減低。Kernel burst有時候可能會引會一些「過度使用」(overuse) 的狀況,見下圖右,這個是可以利用設定time slice quota來控制的,我們以後再寫文章來討論。

圖三. Kernel Burst 的概念

總結

為了做到讓GPU為多個機器學習專案所共享,Gemini設計了一個虛擬GPU的概念。在Kubernetes的執行環境上,我們把這些虛擬GPU派給一種新的Pod kind,叫做SharePOD。同時,我們也延伸了POD flavor 的概念,讓flavor 可以使用分割後的一小部份GPU資源。這樣我們就可以把這些SharePOD派送到K8S worker node 上,共享使用一張GPU。這裡強調的「共享」 ,是指我們利用GPU愈來愈強大的功能,在同一時段(time slice quota)內,將不同的SharePOD,共同使用同一張GPU,但在任一時間點上,這張GPU還是只屬於一個SharePOD的。這樣的虛擬化也保證了不同專案完全隔離的目標,不會因為共享實體GPU,而影響到另一個專案數據的完整性(integrity)。

圖四. Gemini GPU Partitioning 系統架構

Gemini GPU Partitioning 分割功能,可分為前台跟後台。如圖四。前台執行在K8S worker node上,包括了一個CPU/GPU同步event的Monitor,去收集資源使用數據,送到後台。另外前台也設計了一個kernel burst 的功能,儘量減低performance 的 overhead。

Gemini GPU Partitioning 的後台,則包括了一個Device manager,去管理虛擬GPU跟實體GPU的mapping,並存取虛擬GPU資源使用數據。另外,後台也設計了一個SharePOD scheduler,根據使用數據來派送SharePOD,來達成共享GPU的目的。

--

--

Patrick Fu
Gemini Open Cloud 雙子星雲端

符儒嘉於美國矽谷資訊軟體業工作約30 年,曾在IBM、Amdahl、Sun、Interwoven任職,2009回國加入雲端中心之研發團隊,擔任雲端中心關鍵計畫Cloud OS 系統軟體開發之計畫主持人,將其在美國所累積的系統軟體開發知識與經驗,運用於雲端中心之計畫執行中。