隨著人工智能在工業(yè)和學(xué)術(shù)界大規(guī)模的應(yīng)用，深度學(xué)習(xí)訓(xùn)練需求日益迫切。各組織機構(gòu)投入大量資金購置和搭建配置GPU和InfiniBand網(wǎng)卡異構(gòu)計算集群。集群管理系統(tǒng)(也稱平臺)支持模型訓(xùn)練，提供作業(yè)、數(shù)據(jù)和模型管理，并提供資源隔離。資源管理系統(tǒng)是深度學(xué)習(xí)系統(tǒng)的基礎(chǔ)，企業(yè)級場景下，上層框架和應(yīng)用通常在資源管理系統(tǒng)提供的資源上運行。

異構(gòu)計算的主要驅(qū)動力來自于暗硅和異構(gòu)硬件的發(fā)展趨勢。數(shù)據(jù)中心硬件日益多樣化，用戶以多租共享的方式使用硬件。因此，統(tǒng)一管理需求逐漸產(chǎn)生。為管理計算和存儲異構(gòu)硬件，通常需要在統(tǒng)一空間內(nèi)對其進行抽象和管理，最終實現(xiàn)用戶對硬件透明化的使用。異構(gòu)計算集群調(diào)度和資源管理系統(tǒng)在人工智能系統(tǒng)中類似于傳統(tǒng)操作系統(tǒng)，對底層異構(gòu)資源（如GPU、CPU等）進行抽象，對上調(diào)度深度學(xué)習(xí)作業(yè)并分配資源。在啟動作業(yè)后，還需進行資源隔離、環(huán)境隔離和作業(yè)生命周期管理。

異構(gòu)計算集群管理系統(tǒng)簡介

異構(gòu)計算集群管理系統(tǒng)是一種系統(tǒng)軟件，負責(zé)管理計算機集群內(nèi)的多個節(jié)點的硬件（如GPU、CPU、內(nèi)存、磁盤等）和軟件資源（如框架、作業(yè)、鏡像等），并為計算機程序（通常是深度學(xué)習(xí)訓(xùn)練作業(yè)）提供通用服務(wù)（如作業(yè)提交、調(diào)試、監(jiān)控、克隆等）。簡而言之，異構(gòu)計算集群管理系統(tǒng)是一種管理和優(yōu)化計算機集群內(nèi)硬件和軟件資源的系統(tǒng)軟件，旨在為深度學(xué)習(xí)訓(xùn)練提供通用服務(wù)。

一、多租環(huán)境運行的訓(xùn)練作業(yè)

多租環(huán)境提交運行作業(yè)

在企業(yè)級深度學(xué)習(xí)場景中，大型企業(yè)通常擁有許多機器學(xué)習(xí)科學(xué)家和工程師，并且擁有大量GPU服務(wù)器。為提高效率和資源共享，面向深度學(xué)習(xí)場景設(shè)計的多租戶平臺系統(tǒng)備受青睞。如上圖所示，在企業(yè)環(huán)境下，不同用戶會提交不同框架（如PyTorch、TensorFlow等）的深度學(xué)習(xí)作業(yè)，具有不同的資源需求（如單GPU卡、多GPU卡），共享一個物理集群以減少硬件資源的浪費。

當(dāng)前深度學(xué)習(xí)場景下，平臺系統(tǒng)管理的資源是異構(gòu)的（如CPU、GPU等）。與深度學(xué)習(xí)開發(fā)者獨占服務(wù)器進行模型訓(xùn)練相比，多用戶共享多GPU服務(wù)器有很大的不同。這也為異構(gòu)計算集群管理系統(tǒng)（簡稱平臺或深度學(xué)習(xí)平臺）的設(shè)計帶來相應(yīng)需求，主要體現(xiàn)在以下幾個方面：

1、多作業(yè)(Job)和多用戶

1）每個用戶為不斷改進模型、超參數(shù)調(diào)優(yōu)、調(diào)試和優(yōu)化作業(yè)向平臺提交大量作業(yè)。

2）不同人工智能團隊(如計算機視覺、自然語言處理、語音識別等)都使用平臺。每個團隊很多工程師會在同一時間段內(nèi)向平臺申請資源來執(zhí)行作業(yè)。

2、作業(yè)環(huán)境需求多樣

當(dāng)前深度學(xué)習(xí)技術(shù)棧不夠統(tǒng)一，不同的用戶可能使用不同的框架和庫，如TensorFlow、PyTorch、Hugging Face等。用戶可能使用開源項目，其中有些項目較老舊，有些則使用最新的框架。用戶不希望頻繁地進行版本適配。此外，開源框架的版本也可能不一致，導(dǎo)致底層依賴如NVIDIA CUDA的版本也不同。在共享機器的情況下，需要確保環(huán)境相互獨立，不受其他用戶安裝的Python、PyTorch等版本的影響。

3、作業(yè)資源需求多樣

用戶提交的深度學(xué)習(xí)作業(yè)包括分布式訓(xùn)練作業(yè)、單機訓(xùn)練或調(diào)試任務(wù)以及大規(guī)模分布式訓(xùn)練任務(wù)。這些作業(yè)的需求資源量各不相同，有些需要更多的資源，有些則需要較少的資源。即使申請的GPU數(shù)量相同，不同的作業(yè)和模型也會導(dǎo)致資源利用率的差異。平臺需要按需分配資源，以減少資源的碎片化。用戶希望作業(yè)能夠像使用獨占資源一樣運行，不受其他作業(yè)的資源和命名空間沖突的干擾，以便盡快完成模型訓(xùn)練。平臺需要實現(xiàn)作業(yè)運行期間的資源隔離，以確保服務(wù)質(zhì)量。

4、服務(wù)器軟件環(huán)境單一

平臺方在購買和部署資源時，難以預(yù)測和規(guī)劃用戶未來的軟件和版本需求，這主要是因為用戶使用的框架和庫多種多樣，而且版本也不盡相同。為了簡化運維，平臺方通常會統(tǒng)一操作系統(tǒng)和驅(qū)動，并保持版本一致，以減少兼容性問題。但這與用戶多樣化的環(huán)境需求相矛盾。即使部署不同系統(tǒng)和環(huán)境，也難以精確地適配用戶不斷變化的需求。

5、服務(wù)器空閑資源組合多樣

盡管平臺批量購買同型號機器，但因用戶申請資源和作業(yè)生命周期不同，資源釋放后平臺空閑資源組合非常多樣，需要設(shè)計調(diào)度策略提高資源利用率。

從上述問題可以看出，需要統(tǒng)一的平臺系統(tǒng)來支撐調(diào)度和資源管理。其在底層抽象和管理計算資源，在上層為應(yīng)用提供隔離且易用的作業(yè)運行環(huán)境。簡而言之，是支持深度學(xué)習(xí)應(yīng)用管理分布式GPU服務(wù)器集群的操作系統(tǒng)。

二、作業(yè)生命周期

在展開平臺組件與功能前，先了解一下深度學(xué)習(xí)作業(yè)（作業(yè)的生命周期）在平臺上是如何提交和執(zhí)行。

GPU 集群

1、平臺上作業(yè)生命周期

1）作業(yè)提交與排隊

用戶首先在本地測試作業(yè)依賴環(huán)境，并將其打包為鏡像，然后上傳到公共鏡像中心。接著，將代碼和數(shù)據(jù)等上傳到平臺的文件系統(tǒng)中。之后，通過提交工具（如Web、命令行、API）填寫資源申請、啟動命令、部署方式、鏡像、代碼和數(shù)據(jù)路徑等信息（在提交時需要權(quán)衡資源需求和排隊時間）。

2）作業(yè)資源分配與調(diào)度

平臺在收到資源申請后會將其排隊，等待調(diào)度器的輪詢。當(dāng)調(diào)度器輪詢到該作業(yè)時，會根據(jù)集群的空閑資源狀況和調(diào)度算法決定在哪些有空閑資源的節(jié)點上啟動該作業(yè)。如果無法滿足作業(yè)的資源需求，作業(yè)將繼續(xù)排隊等待。如果提交作業(yè)失敗或超時，用戶需要調(diào)整作業(yè)信息后重新提交。

3）作業(yè)執(zhí)行完成與釋放

作業(yè)被調(diào)度后，平臺會在有空閑資源的節(jié)點上啟動作業(yè)，下載鏡像，掛載代碼和數(shù)據(jù)，進行資源限制與隔離，然后啟動執(zhí)行。平臺在執(zhí)行中收集運行指標和日志以供調(diào)試。作業(yè)完成后平臺釋放資源，繼續(xù)分配給其他作業(yè)使用。

2、可以將作業(yè)在平臺上的狀態(tài)抽象為以下狀態(tài)機

1)作業(yè)準備與提交：觸發(fā)作業(yè)提交動作

●提交成功

●提交失敗：重新開始提交

2)作業(yè)排隊：觸發(fā)作業(yè)調(diào)度動作

●調(diào)度成功

●調(diào)度失?。褐匦麻_始提交

3)作業(yè)部署運行：觸發(fā)作業(yè)執(zhí)行動作

●執(zhí)行成功

●作業(yè)失敗，重試次數(shù)<=N：重新開始提交

●作業(yè)失敗，重試次數(shù)>N：作業(yè)失敗退出

用戶的操作實際上是在這些狀態(tài)之間不斷切換，最終達到作業(yè)成功執(zhí)行或失敗。如果執(zhí)行成功，用戶可以在完成后獲取結(jié)果和模型。

三、集群管理系統(tǒng)架構(gòu)

異構(gòu)集群管理系統(tǒng)架構(gòu)

異構(gòu)集群管理系統(tǒng)通常包含多個組件。其中，調(diào)度器負責(zé)資源與作業(yè)的管理，監(jiān)控系統(tǒng)負責(zé)監(jiān)控系統(tǒng)的健康狀態(tài)并發(fā)出警報，Web界面提供用戶交互接口，存儲系統(tǒng)則用于存儲數(shù)據(jù)、模型和代碼。

1、平臺的主要組件包括

1)集群調(diào)度與資源管理模塊

統(tǒng)一管理集群資源，調(diào)度作業(yè)到空閑資源上，回收已完成作業(yè)的資源?？刂破矫婵梢赃x擇Kubernetes、Mesos等系統(tǒng)，也可以使用面向深度學(xué)習(xí)作業(yè)的定制調(diào)度器。

2）鏡像中心

存儲Docker鏡像，供用戶提交和共享鏡像，作業(yè)下載鏡像?？梢允褂霉仓行娜鏒ocker Hub，也可以構(gòu)建私有中心或使用云鏡像中心。

3）存儲模塊

扮演數(shù)據(jù)平面角色，存儲數(shù)據(jù)、模型和代碼。用戶上傳和作業(yè)下載數(shù)據(jù)。

4）作業(yè)生命周期管理器

部署、監(jiān)控、重試作業(yè)以及診斷錯誤是單作業(yè)的控制平面所涉及的任務(wù)。在這個平面上，可以構(gòu)建自動機器學(xué)習(xí)系統(tǒng)，而不需要考慮其他作業(yè)。在平臺接口的基礎(chǔ)上，可以選擇使用K8S Operator、Framework Controller或YARN AppMaster等工具來實現(xiàn)這些功能。

5）集群監(jiān)控與報警

監(jiān)控硬件、服務(wù)和作業(yè)狀態(tài)并進行報警是監(jiān)控系統(tǒng)的一項重要任務(wù)。在這個過程中，可以選擇使用Prometheus、Grafana、AlertManager等開源系統(tǒng)來實現(xiàn)監(jiān)控和報警功能。此外，也可以開發(fā)自定義監(jiān)控指標來滿足特定需求。

6）集成開發(fā)環(huán)境

為用戶提供Web門戶、REST API、IDE(如VS Code、Jupyter Notebook)等，用于作業(yè)提交、管理、監(jiān)控和調(diào)試。

7）測試集群

為隔離生產(chǎn)環(huán)境，可以部署一個小規(guī)模的測試集群，用于開發(fā)和測試。

2、平臺部署模式

1）本地部署

一些公司出于數(shù)據(jù)合規(guī)等需求，選擇使用開源平臺或自研平臺進行本地部署，保證數(shù)據(jù)和鏡像在自有數(shù)據(jù)中心，這對運維和開發(fā)工程師要求較高。需要自建數(shù)據(jù)中心或在已有基礎(chǔ)設(shè)施上部署，初始投資大且需資源規(guī)劃。需要全職運維團隊維護軟件、監(jiān)控等，且需要平臺服務(wù)軟件的定制開發(fā)能力。硬件迭代速度快，經(jīng)過一段時間后容易淘汰，更新又需要高成本。

2）公有云部署

一些公司購買云的IaaS或PaaS服務(wù)來搭建平臺，減輕運維壓力，利用云平臺的最新技術(shù)，實現(xiàn)彈性擴縮容，但數(shù)據(jù)和代碼需上云，長期成本高。初期投資小，按用量付費，大部分運維由云供應(yīng)商完成，適合初期使用。但一些公司出于數(shù)據(jù)合規(guī)無法全部上云。成本隨規(guī)模增長可能無法承擔(dān)。

3）混合云

一些公司采用敏感數(shù)據(jù)在本地，非敏感數(shù)據(jù)和彈性資源在云端的方案。

4）多云

一些公司為防云供應(yīng)商鎖定或綜合選擇性價比，會采用多云方案和工具。

本地與云部署成本趨勢

訓(xùn)練作業(yè)，鏡像與容器

平臺作業(yè)與開發(fā)體驗

集群管理系統(tǒng)需要面對多個用戶的作業(yè)共享服務(wù)器資源，為解決環(huán)境依賴和資源隔離問題，需要采用鏡像和運行時資源隔離等機制。下面將從作業(yè)在集群管理系統(tǒng)上的依賴隔離、運行時資源隔離以及人工智能作業(yè)開發(fā)體驗幾個方面進行介紹。

一、深度學(xué)習(xí)作業(yè)

在本地機器或獨占服務(wù)器上開發(fā)訓(xùn)練模型時，環(huán)境問題較少，還未暴露更多挑戰(zhàn)。獨占環(huán)境的情況如下:

●無需考慮依賴環(huán)境和資源隔離問題

●Python環(huán)境依賴路徑在本地，通過包管理器或環(huán)境變量隔離

●GPU環(huán)境依賴路徑固定在本地，通過環(huán)境變量切換

●數(shù)據(jù)直接上傳到本地磁盤，帶寬高

●直接在磁盤執(zhí)行啟動腳本，修改調(diào)試方便

如果環(huán)境準備好，可以通過下面的腳本啟動訓(xùn)練:

python train.py --batch_size=256 --model_name=resnet50

{

// 作業(yè)名稱

"jobName": "resnet",

// 鏡像名稱

"image": "example.tensorflow:stable",

// 輸入數(shù)據(jù)存儲路徑

"dataDir": "/tmp/data",

// 數(shù)據(jù)結(jié)果存儲路徑

"outputDir": "/tmp/output",

...

// 任務(wù)規(guī)格:資源需求、啟動腳本等

"taskRoles": [

{ ... "taskNumber": 1, "cpuNumber": 8, "memoryMB": 32768, "gpuNumber": 1, "command": "python train.py --batch_size=256 --model_name=resnet50" }

]

}

從作業(yè)提交規(guī)格示例可以看出，當(dāng)用戶將作業(yè)提交到有4塊GPU服務(wù)器時,平臺需要提供以下支持:

1、環(huán)境依賴

1）問題

平臺集群中的機器系統(tǒng)和環(huán)境都相同，如何支持用戶使用不同的深度學(xué)習(xí)框架(如TensorFlow和PyTorch)、庫和版本?

2）解決方法

通過指定的"image"鏡像名稱解決環(huán)境依賴問題。用戶需要提前將依賴打包構(gòu)建為Docker鏡像，提交到指定的鏡像中心，供作業(yè)下載使用。

2、數(shù)據(jù)與代碼

1）問題

平臺上運行的是深度學(xué)習(xí)訓(xùn)練作業(yè)，每個作業(yè)需要輸入數(shù)據(jù)和代碼。如果直接上傳到服務(wù)器會造成過大負載，則無法復(fù)用數(shù)據(jù)和代碼。

2）解決方法

通過指定"dataDir"和"outputDir"路徑來處理作業(yè)的輸入數(shù)據(jù)和輸出結(jié)果。用戶提前上傳數(shù)據(jù)和代碼到平臺指定的文件系統(tǒng)路徑下，未來平臺會將網(wǎng)絡(luò)文件系統(tǒng)中的數(shù)據(jù)和代碼掛載到運行作業(yè)的機器上。

3、資源申請量

1）問題

用戶提交單GPU、多GPU或分布式作業(yè)，平臺無法靜態(tài)分析作業(yè)資源需求，如果不明確配置會導(dǎo)致資源浪費或不足。

2）解決方法

用戶明確聲明所需GPU、CPU和內(nèi)存資源，平臺根據(jù)策略分配匹配的空閑資源。

4、資源隔離

1）問題

同一服務(wù)器上運行多個作業(yè)時,如何避免作業(yè)間互相干擾?

2）解決方法

平臺可以通過容器cgroup等技術(shù)對進程進行資源限定和隔離。

5、任務(wù)部署模式

1）問題

對于分布式作業(yè)，如果用戶不說明，平臺無法知道需要啟動的任務(wù)數(shù)。

2）解決方法

用戶明確告知需要啟動的任務(wù)數(shù)量，平臺啟動多個任務(wù)副本進行訓(xùn)練。

6、作業(yè)啟動命令

1）問題

平臺需要知道作業(yè)的啟動命令來啟動和執(zhí)行代碼。

2）解決方法

用戶在作業(yè)中明確描述啟動入口命令，啟動并執(zhí)行代碼。

二、環(huán)境依賴：鏡像（Image）

當(dāng)用戶在平臺上執(zhí)行作業(yè)時，首要問題是本地環(huán)境與集群環(huán)境差異：

●服務(wù)器沒有預(yù)裝所需個性化環(huán)境

●不同作業(yè)需要不同框架、依賴和版本，安裝繁瑣且重復(fù)

●服務(wù)器上有大量重復(fù)安裝的庫，占用空間

●深度學(xué)習(xí)特有問題：需要安裝CUDA、框架等

平臺需要采用以下技術(shù)方案來解決：

利用鏡像隔離整體環(huán)境并在之上創(chuàng)建新環(huán)境，以層級構(gòu)建的方式復(fù)用每一個層級，此方法既保證個性化環(huán)境，同時也確保性能和資源消耗最小。此方法主要依賴主流平臺通過Docker鏡像來實現(xiàn)，而Docker鏡像則通過Union文件系統(tǒng)等機制實現(xiàn)高效存儲。

Union文件系統(tǒng)聯(lián)合掛載多個目錄以形成一個合并的視圖，而Docker則利用此機制以更高效地存儲文件和包。Docker支持多種Unionfs，例如下一層的AUFS和更上層的OverlayFS。

下面將通過一個實例來理解和構(gòu)建鏡像以及使用方法。用戶編寫的Dockerfile可通過其中的命令構(gòu)建和打包鏡像，構(gòu)建成功后可上傳到鏡像中心。平臺在啟動作業(yè)時會下載鏡像到服務(wù)器，并使用它來配置作業(yè)環(huán)境。

PyTorch 鏡像文件中包含的依賴

三、運行時資源隔離：容器

當(dāng)用戶在平臺上執(zhí)行作業(yè)時，如何避免作業(yè)間的資源爭用干擾，實現(xiàn)資源隔離：

●集群資源被共享，如何確保作業(yè)進程不相互干擾和搶占資源?

●如何讓不同作業(yè)在同一臺機器上運行在獨立的命名空間避免沖突?

●如何在保證隔離的同時使作業(yè)啟動越快越好?

●深度學(xué)習(xí)的特殊問題：如何隔離GPU的核和內(nèi)存?

●平臺通常使用容器技術(shù)解決運行時的資源隔離。容器主要通過兩種機制實現(xiàn)資源隔離：

控制組Cgroups：可以控制、統(tǒng)計和隔離一組進程的資源(如CPU、內(nèi)存等)。

命名空間Namespaces：將系統(tǒng)資源包裝在抽象中，使每個命名空間中的進程擁有獨立的資源，實現(xiàn)命名空間隔離。

由于深度學(xué)習(xí)目前依賴GPU進行訓(xùn)練，為讓容器支持掛載GPU，GPU廠商通常會提供針對Docker的特殊支持。例如NVIDIA提供nvidia-docker。用戶可以參考其文檔進行環(huán)境配置。

但由于GPU等加速器虛擬化支持不如CPU成熟，目前主流是以加速器為粒度進行掛載和隔離，無法像CPU那樣進行細粒度的時分復(fù)用、內(nèi)存隔離和動態(tài)遷移。

環(huán)境配置完成后，用戶可以運行掛載特定數(shù)量GPU的容器。例如通過以下NVIDIA Docker命令在容器中掛載2個GPU：

nvidia-docker run --gpus 2 --rm nvidia/cuda nvidia-smi此命令會啟動一個容器,并掛載2個GPU進容器,容器內(nèi)可以看到這2個GPU。

四、從操作系統(tǒng)視角看 GPU 技術(shù)棧

操作系統(tǒng)通常負責(zé)進程的資源管理和多任務(wù)調(diào)度。在計算機中，GPU被抽象為設(shè)備，操作系統(tǒng)通過ioctl系統(tǒng)調(diào)用進行設(shè)備控制。有兩種主要思路試圖將GPU技術(shù)納入操作系統(tǒng)的管理，并提供多租戶、虛擬化等功能支持：

1、修改內(nèi)核

將GPU設(shè)備驅(qū)動和調(diào)度邏輯集成到內(nèi)核中，通過擴展內(nèi)核實現(xiàn)GPU的虛擬化和調(diào)度。但這種方法需要修改內(nèi)核，代價較大。

2、在用戶空間實現(xiàn)資源管理組件

通過封裝內(nèi)核接口提供調(diào)度和虛擬化支持。這種方法兼容性較好，也更容易迭代。已經(jīng)有一些相關(guān)工作實現(xiàn)了用戶級的GPU虛擬化管理。

將GPU納入操作系統(tǒng)統(tǒng)一資源管理的目的是讓GPU能夠像CPU一樣被多任務(wù)調(diào)度，這是實現(xiàn)GPU多租戶和自動化管理的基礎(chǔ)。

CPU和GPU技術(shù)棧與操作系統(tǒng)抽象

從圖中可以看出，操作系統(tǒng)能夠為CPU程序提供大量的系統(tǒng)調(diào)用支持，同時也能對各種硬件進行抽象管理，并支持用戶的多進程與多租戶。然而在GPU程序的情況下，當(dāng)前的模型更像是客戶端與服務(wù)器之間的抽象，GPU被視為一種設(shè)備，CPU程序會向GPU提交作業(yè)并從其獲取響應(yīng)結(jié)果。然而，操作系統(tǒng)對GPU本身的操作通常只能通過有限的交互與控制來實現(xiàn)，通常使用的交互方式是ioctl。

五、人工智能作業(yè)開發(fā)體驗（Development Experience）

在使用集群管理系統(tǒng)時，人工智能算法工程師通常會使用以下工具進行人工智能作業(yè)與Python腳本的開發(fā)：

1、客戶端集成開發(fā)環(huán)境（IDE）

這種工具提供完整的開發(fā)環(huán)境，可以進行Python開發(fā)、調(diào)試、語法高亮等功能，例如Visual Studio Code。在人工智能場景下，算法工程師主要使用VS Code進行Python程序開發(fā)、調(diào)試、語法高亮、智能代碼完成、預(yù)裝代碼片段和版本管理Git的支持。用戶可以根據(jù)自身需求更改主題、鍵盤快捷鍵、首選項，并安裝添加額外功能的擴展。

2、一站式人工智能開發(fā)插件

Tools for AI當(dāng)前已改名為Visual Studio Code Azure機器學(xué)習(xí)擴展。此工具提供部署到云端或邊緣的支持、常用深度學(xué)習(xí)庫的支持、本地實驗再部署到大規(guī)模集群、集成自動化機器學(xué)習(xí)，以及通過CI/CD工具跟蹤實驗和管理模型。

3、代碼完成工具

Kite for VS Code適用于VS Code的各種語言，通過海量代碼庫訓(xùn)練人工智能模型，提供智能代碼完成服務(wù)，包括智能感知、代碼片段和光標跟隨的文檔AI代碼完成。Kite支持Python等文件類型，代碼補全將大幅提升開發(fā)生產(chǎn)力，這也是集成開發(fā)環(huán)境的優(yōu)勢。同時，OpenAI也開源了Copilot進行常見語言和通用程序的智能化代碼提示和程序合成（Program Synthesis）。使用VS Code等類似的客戶端IDE進行開發(fā)的特點是功能強大，調(diào)試、補全等功能完善。

通過Web界面提交作業(yè)到集群

開發(fā)者在提交作業(yè)到集群之前通常會經(jīng)歷三個階段的開發(fā)。首先，會在自己的開發(fā)環(huán)境中進行編程和測試，確保程序沒有錯誤后才會提交到集群平臺。

Python人工智能程序的編寫可以在本地使用VS Code等工具進行。VS Code通過插件方便了本地調(diào)試、代碼靜態(tài)檢測和代碼完成，這能夠顯著提升開發(fā)效率，同時不需要等待平臺資源的排隊。對于快速開發(fā)初始程序，這種方法非常方便。如果本地設(shè)備沒有GPU，可以考慮安裝CPU版本的深度學(xué)習(xí)框架進行開發(fā)和測試。

如果有可用的測試服務(wù)器掛載有GPU，開發(fā)者可以在第二個階段將作業(yè)提交到測試服務(wù)器進行測試。對于小規(guī)模作業(yè)，也可以在服務(wù)器上完成一定程度的訓(xùn)練。然而，GPU無法滿足大規(guī)模多卡和分布式訓(xùn)練，或者搜索空間巨大的超參數(shù)搜索需求。因此，調(diào)試完成的程序可以在測試服務(wù)器上構(gòu)建Docker鏡像或上傳數(shù)據(jù)等。在此階段，使用VS Code配合Remote SSH插件進行遠程開發(fā)比較適合。

當(dāng)用戶確保程序開發(fā)完成時，可以將作業(yè)提交到平臺進行批處理作業(yè)的執(zhí)行（用戶可以選擇使用命令行工具、Web或REST API進行作業(yè)提交）。由于GPU是稀缺資源，可能會經(jīng)歷一定的排隊流程（例如數(shù)小時）。在這種情況下，用戶可以利用閑暇時間繼續(xù)開發(fā)新的作業(yè)或閱讀論文，尋找新的優(yōu)化點或調(diào)試其他作業(yè)和模型。提交作業(yè)后，可以參考下圖的流程，進行作業(yè)的完整執(zhí)行。這個過程更適合通過Web訪問作業(yè)監(jiān)控界面、SSH登錄到作業(yè)進行調(diào)試，或者通過作業(yè)容器部署啟動Jupyter進行交互式開發(fā)。

人工智能作業(yè)的不同開發(fā)環(huán)境

如圖所示，開發(fā)者通常會經(jīng)歷以下三個階段：本地開發(fā)、測試服務(wù)器開發(fā)和打包程序提交到平臺執(zhí)行。在每個階段，都會進行相應(yīng)的操作。首先，在本地開發(fā)階段，開發(fā)者會在自己的計算機上編寫和測試程序。然后，在測試服務(wù)器開發(fā)階段，會對程序進行更嚴格的測試，以確保其能夠在生產(chǎn)環(huán)境中正常運行。最后，在打包程序提交到平臺執(zhí)行階段，開發(fā)者會將程序打包并提交到集群管理系統(tǒng)進行批處理。在執(zhí)行作業(yè)的過程中，開發(fā)者需要監(jiān)控作業(yè)狀態(tài)并進行調(diào)試，以確保程序能夠順利執(zhí)行并返回正確的結(jié)果。根據(jù)訓(xùn)練結(jié)果，開發(fā)者可以調(diào)整和優(yōu)化程序，然后開始下一次的作業(yè)提交。

人工智能作業(yè)開發(fā)體驗時序圖

如下圖所示，當(dāng)作業(yè)已經(jīng)調(diào)試完成，用戶會經(jīng)歷以下的步驟與平臺交互完成訓(xùn)練過程：

●用戶首先上傳數(shù)據(jù)到存儲

●上傳鏡像到鏡像中心

●提交作業(yè)規(guī)格。填寫數(shù)據(jù)，鏡像路徑，資源需求和啟動命令行

●集群調(diào)度器調(diào)度作業(yè)

●空閑 GPU 節(jié)點拉?。≒ull）鏡像

●空閑 GPU 節(jié)點啟動作業(yè)

●掛載文件系統(tǒng)

●作業(yè)運行啟動

●作業(yè)監(jiān)控不斷匯報性能指標和日志用于觀測與調(diào)試

●訓(xùn)練完成作業(yè)保存結(jié)果

提交到集群的作業(yè)生命周期

調(diào)度

平臺調(diào)度器

在作業(yè)進程啟動之前，平臺需要進行決策，確定當(dāng)前作業(yè)應(yīng)該在哪些服務(wù)器和GPU上運行，以及哪個作業(yè)可以優(yōu)先執(zhí)行，進而進行調(diào)度決策。下面將圍繞調(diào)度問題的抽象和優(yōu)化目標，以及可用于深度學(xué)習(xí)作業(yè)調(diào)度的傳統(tǒng)調(diào)度算法進行介紹，了解作業(yè)調(diào)度的經(jīng)典問題和解決方法。

一、調(diào)度問題優(yōu)化目標

調(diào)度是分配資源以執(zhí)行任務(wù)的過程。在深度學(xué)習(xí)平臺中，資源包括處理器、GPU、內(nèi)存等，而任務(wù)則是用戶提交的作業(yè)。調(diào)度活動由稱為調(diào)度器的進程執(zhí)行。調(diào)度器的算法通常旨在使所有計算機資源保持忙碌，讓多個用戶高效地共享系統(tǒng)資源實現(xiàn)目標服務(wù)質(zhì)量。

在運行深度學(xué)習(xí)作業(yè)的集群服務(wù)器上，會部署一個操作系統(tǒng)進行作業(yè)管理與調(diào)度，即異構(gòu)資源管理系統(tǒng)也稱作深度學(xué)習(xí)平臺。該系統(tǒng)不同于傳統(tǒng)操作系統(tǒng)，其特點是運行的“進程”一般為深度學(xué)習(xí)作業(yè)。

每臺服務(wù)器掛載多塊商用 GPU，InfiniBand 網(wǎng)卡等異構(gòu)硬件。深度學(xué)習(xí)平臺也要在整體上對作業(yè)提供所管理的硬件的“一定抽象層次”上的多路復(fù)用。同時，由于整個系統(tǒng)不僅一個用戶會提交多個作業(yè)，整個資源池被多個公司內(nèi)部組和用戶共享，這就是多租（Multi-Tenancy）系統(tǒng)。

1、作業(yè)延遲與吞吐相關(guān)指標

1）排隊延遲

描述作業(yè)在調(diào)度器隊列中等待資源分配所花費的時間。排隊延遲越低，代表用戶作業(yè)需要等待的時間越短越高效。其主要受兩個因素影響：

●公平性

用戶作業(yè)是否能夠公平地分配到所需的資源

●局部性和資源碎片化問題

可能導(dǎo)致資源無法分配和等待

2）平均響應(yīng)時間

從提交請求到產(chǎn)生第一個響應(yīng)的時間量的平均值。

3）平均作業(yè)完成時間

一批作業(yè)的平均完成時間（該指標能夠代表系統(tǒng)性能）。如考慮分布式作業(yè)的局部性，影響通信時間，進而影響平均作業(yè)完成時間。

4）完工時間

一批作業(yè)中，第一個作業(yè)到最后一個作業(yè)整體完成時間（時間越小越好）。有些調(diào)度算法也考慮所有作業(yè)的整體完工時間作為優(yōu)化目標，因為最小化完工時間等價于最大化資源效率。

5）吞吐

單位時間能完成的作業(yè)數(shù)量（吞吐量越大越好）。

2、平臺資源利用率相關(guān)指標

1）資源利用率

描述用于作業(yè)的資源占總資源的百分比（利用率越高越好）。

2）資源碎片

作業(yè)分配后造成個別節(jié)點資源無法被再分配，產(chǎn)生碎片問題。碎片越少，代表資源浪費越少。也是和資源利用率相關(guān)的指標。

3、公平與服務(wù)水平相關(guān)指標

1）公平性

資源使用在平臺用戶或組之間平均或按指定配額比例分配。

2）服務(wù)水平協(xié)議

服務(wù)級別協(xié)議是平臺和用戶之間的承諾。如平臺服務(wù)的公平性、質(zhì)量、可用性、責(zé)任等在平臺和用戶之間進行約定和達成一致。

如下圖所示，平臺中包含以下集群與作業(yè)的包含層級關(guān)系，不同層次中蘊含不同的調(diào)度問題，可以將之后涉及的面向深度學(xué)習(xí)調(diào)度算法也映射到其中的層級問題的解決方法。

平臺中的作業(yè)調(diào)度問題總覽

二、單作業(yè)調(diào)度—群調(diào)度

群調(diào)度是一種在并行系統(tǒng)中使用的調(diào)度算法，用于調(diào)度相關(guān)的線程或進程在不同的處理器上同時啟動和運行。深度學(xué)習(xí)作業(yè)通常需要群調(diào)度，以確保所有必需的加速設(shè)備都準備好后才開始訓(xùn)練過程。如果沒有使用群調(diào)度，可能會導(dǎo)致問題的出現(xiàn)。因為深度學(xué)習(xí)作業(yè)通常需要同時執(zhí)行多個任務(wù)，如果有依賴任務(wù)沒有啟動，已啟動的任務(wù)可能會在等待同步點或頻繁切換上下文而無法繼續(xù)運行，進而導(dǎo)致訓(xùn)練任務(wù)無法進行。

同時，已啟動的任務(wù)如果不釋放資源，可能會導(dǎo)致資源的浪費，產(chǎn)生死鎖現(xiàn)象。如下圖所示，兩個作業(yè)都申請了部分資源，但還需要其他資源才能啟動，這就產(chǎn)生了死鎖現(xiàn)象。

并行啟動執(zhí)行作業(yè)可能產(chǎn)生的問題

通過利用群調(diào)度技術(shù)，可以同時啟動深度學(xué)習(xí)任務(wù)進程，以解決之前提到的例子中的問題。如下圖所示，可以讓作業(yè)A、B和C交替執(zhí)行，以確保所有任務(wù)能夠順利完成。這種方式讓已啟動的任務(wù)能夠繼續(xù)運行，而不會因等待其他未啟動的任務(wù)而造成訓(xùn)練中斷或資源浪費。

并行執(zhí)行作業(yè)可能產(chǎn)生的問題

當(dāng)然群調(diào)度也存在一定的局限性。比如可能會增加資源碎片化的風(fēng)險，并且在共享集群中的利用率較低。如圖中的t1和t2時間段，GPU 7和8就處于空閑狀態(tài)，造成了資源浪費。

三、作業(yè)間調(diào)度—主導(dǎo)資源公平 DRF（Dominant Resource Fairness）調(diào)度

在包含多種異構(gòu)資源的系統(tǒng)中，實現(xiàn)多作業(yè)公平的資源調(diào)度是一項挑戰(zhàn)。深度學(xué)習(xí)作業(yè)需要使用CPU、GPU和內(nèi)存等多種資源，因此需要一種考慮多種資源的公平調(diào)度策略。DRF（Dominant Resource Fairness）是一種用于多資源公平調(diào)度的算法，通過使用主導(dǎo)份額的概念來比較多種資源的分配。

與其他策略不同，DRF滿足幾個理想的屬性。首先，鼓勵用戶共享資源，從而保證公平性。其次，DRF是防策略的，即用戶沒有動力通過謊報需求來增加作業(yè)資源的分配。用戶基于最大最小公平，謊報更多的資源則需要更多的排隊時間。同時，DRF是無嫉妒的，即用戶不羨慕其他用戶的分配。最后，DRF分配是帕累托有效的，即不可能在不損害某些人利益的前提下使另一些人獲益。

DRF調(diào)度策略的簡要總結(jié)是：通過同類型資源在集群整體資源中的份額確定主導(dǎo)資源。基于最大最小公平的針對多資源類型（例如GPU、CPU）的調(diào)度算法。

2個作業(yè)的DRF調(diào)度實例

以下的資源申請需求中，主導(dǎo)資源是內(nèi)存。

以下的資源申請需求中，主導(dǎo)資源是GPU。

四、組間作業(yè)調(diào)度—容量調(diào)度（Capacity Scheduling）

除能夠公平地分配多個作業(yè)外，平臺管理員還需要考慮如何讓多個小組共享集群，以及如何為多個組織共享集群資源。在共享集群資源的同時，還需要為每個組織提供最小容量保證，以確保能夠獲得所需的資源?？臻e資源應(yīng)該能夠彈性地供其他組織利用，以提高資源利用率和減少資源浪費。

相比傳統(tǒng)容量調(diào)度調(diào)度，深度學(xué)習(xí)作業(yè)也需要考慮調(diào)度 GPU 及 GPU 顯存容量。Capacity Scheduler是大數(shù)據(jù)平臺中常用的主流調(diào)度器，可以將深度學(xué)習(xí)訓(xùn)練作業(yè)和大數(shù)據(jù)作業(yè)都視為批處理作業(yè)。允許多個租戶安全地共享一個大型集群，并在分配容量的限制下及時為應(yīng)用程序分配資源。

以下圖為例，Team A、B、C共享集群，每個組都有多個用戶，每個用戶都會提交作業(yè)使用集群資源。如果不考慮組間公平性，Team A即使再申請45的資源，如果沒有使用完畢也會造成浪費，同時也會讓Team C無法申請資源，產(chǎn)生饑餓現(xiàn)象。

資源占用過多造成其他組無法分配資源問題

所以，容量調(diào)度為支持多租（Multi-Tenant）資源共享設(shè)計了以下的策略集合：

1、提高利用率（Utilization）

1）虛擬集群（Virtual Cluster）組能夠看到的是虛擬資源視圖，并不綁定具體機器，作業(yè)啟動后才會分配相應(yīng)的資源，這樣有助于提高資源利用率。

2）層級隊列（Hierarchical Queues）支持隊列的分層結(jié)構(gòu)，以確保在允許其他隊列使用空閑資源之前，在組織的子隊列之間共享資源，從而提供更多的控制和可預(yù)測性。

3）隊列內(nèi)可以正交組合其他作業(yè)間調(diào)度算法，如先進先出（FIFO），DRF等。在異構(gòu)計算場景中，仍然可以采用適合多維資源調(diào)度的其他自定義調(diào)度器。

2、多租與提升公平性（Fairness）

1）從某種意義上說，隊列將分配到網(wǎng)格容量的一小部分，因為它們可以使用一定容量的資源。提交到隊列的所有應(yīng)用程序都可以訪問分配給隊列的容量。管理員可以對分配給每個隊列的容量配置軟限制和可選的硬限制。

2）允許多用戶以多租形式使用集群?？刂茊斡脩舻目梢韵牡淖畲筚Y源，防止其占用過多資源，導(dǎo)致其他進程無法申請資源。

3、彈性和SLA

1）獎勵資源（Bonus Resource）

對于其他組沒有使用的資源，可以臨時免費出讓給有需要的團隊，但當(dāng)資源持有者需要時，則需要搶占資源歸還給持有者。

2）搶占（Preemption）配合獎勵資源使用，保證對用戶提供的服務(wù)等級協(xié)議（SLA）

如下圖所示，當(dāng)管理員配置最小和最大的組使用資源限額，這樣能夠確保組與組之間都有可用的資源。

容量調(diào)度

五、虛擬集群（Virtual Cluster）機制

在集群內(nèi)，組和用戶所看到的的資源配額一般情況下，并沒有綁定到具體的物理機器，而是在調(diào)度后決定作業(yè)部署的物理機器。這背后是通過虛擬集群 (Virtual Cluster) 映射所實現(xiàn)的。而虛擬集群和之前介紹的控制組（Cgroups）的設(shè)計較為類似。在此會看到很多集群產(chǎn)生的問題，在傳統(tǒng)的操作系統(tǒng)中都能找到類似的設(shè)計問題與原則。

如下圖所示，虛擬集群會配置用戶組的配額和視圖，物理集群是在調(diào)度后在運行時綁定的。這樣可以大幅提升資源利用率，減少資源碎片。

虛擬集群和物理集群映射與綁定

六、搶占式調(diào)度

一些集群管理員希望通過策略共享虛擬集群內(nèi)的空閑資源，以減少組內(nèi)資源的浪費，但單純出讓資源并不能保證原有用戶能夠隨時回收對應(yīng)的配額資源，從而無法保證對原用戶的SLA（服務(wù)等級協(xié)議）。這個問題可以通過搶占調(diào)度來解決，也就是當(dāng)資源的原有用戶需要資源時，終止使用獎勵資源的作業(yè)進程，回收資源給原配額用戶。搶占調(diào)度通常用于以下場景：

1、讓資源饑餓的作業(yè)或短作業(yè)搶占一定資源，以降低作業(yè)的平均響應(yīng)時間

由于深度學(xué)習(xí)作業(yè)的韌性并不完善，因此一般不會為此類需求使用搶占調(diào)度。如下圖所示，APP2長時間無法得到資源，就無法執(zhí)行，而其執(zhí)行時間實際上很短。這就需要通過搶占機制進行調(diào)度，讓APP2獲取一定資源執(zhí)行，以保證降低平均響應(yīng)時間。

作業(yè)等待時間過長問題

2、出讓虛擬集群的空閑資源形成獎勵資源，供其他虛擬集群中的作業(yè)使用，從而提高整體資源利用率。

在深度學(xué)習(xí)中，通常出于這個原因使用搶占調(diào)度。如下圖所示，A隊列中配置10個可用資源，但由于集群有空閑資源，多提供20個獎勵資源給C6和C7。此時，如果C隊列需要使用20個資源，集群應(yīng)該保證能夠觸發(fā)搶占。當(dāng)APP1的C6和C7使用的資源被標記為可以被搶占后，其資源可以通過以下步驟被搶占：

1）從過度使用的隊列中獲取需要被搶占的容器（即隊列A的C6和C7）。

2）通知作業(yè)（即隊列A）控制器即將觸發(fā)搶占。

3）等待直到被搶占作業(yè)運行終止。

搶占強度

搶占式調(diào)度對深度學(xué)習(xí)作業(yè)帶來挑戰(zhàn)，因為深度學(xué)習(xí)作業(yè)在被搶占時只能失敗，而在默認情況下無法像傳統(tǒng)操作系統(tǒng)一樣進行上下文切換。目前有些工作通過提供框架或設(shè)備驅(qū)動庫層的檢查點機制，配合調(diào)度器實現(xiàn)搶占與恢復(fù)，但由于并非原生支持，因此存在一定的開銷，且支持的框架與場景有限，尚未得到廣泛應(yīng)用。未來可以設(shè)計更好的深度學(xué)習(xí)檢查點和恢復(fù)技術(shù)，以減少搶占后作業(yè)失效造成的被強占作業(yè)資源無效使用的問題。

數(shù)據(jù)進行模擬，看能否提升當(dāng)前目標并超越基準算法。最后，對結(jié)果進行分析，并形成分析報告或論文。

面向深度學(xué)習(xí)的集群管理系統(tǒng)

下面將介紹針對深度學(xué)習(xí)負載和GPU服務(wù)器特點而設(shè)計的平臺調(diào)度算法，以更好地滿足新負載和硬件的需求，并提高資源利用率等指標。

一、深度學(xué)習(xí)工作負載的需求

1、深度學(xué)習(xí)訓(xùn)練作業(yè) vs. 傳統(tǒng)的數(shù)據(jù)中心批處理作業(yè)

1）執(zhí)行時間長

訓(xùn)練時間持續(xù)數(shù)小時甚至幾天

2）迭代計算

作業(yè)主干部分是迭代的計算，每輪迭代可以切分為小時間窗口的任務(wù)

3）內(nèi)存數(shù)據(jù)量動態(tài)變化

在訓(xùn)練過程中不同的時間點做檢查點有不同的內(nèi)存數(shù)據(jù)量

4）性能可預(yù)測性

資源消耗可預(yù)測性，可以通過運行時監(jiān)控獲取

2、分布式深度學(xué)習(xí)訓(xùn)練作業(yè)的特點

1）對GPU拓撲結(jié)構(gòu)敏感

數(shù)據(jù)并行策略通信傳遞梯度，模型并行策略通信傳遞中間結(jié)果張量，GPU與GPU之間傳輸帶寬容易形成瓶頸。所以考慮GPU親和性的任務(wù)放置策略，對降低分布式訓(xùn)練作業(yè)的完工時間有幫助。

2）反饋驅(qū)動探索

在自動化機器學(xué)習(xí)場景下，用戶會一次性提交大量的深度學(xué)習(xí)作業(yè)。這些作業(yè)的特點是反饋驅(qū)動探索。用戶通常會嘗試多個作業(yè)配置（多項工作），并利用這些工作的早期反饋（準確度，誤差等）來決定是否優(yōu)先考慮或終止其中的某些作業(yè)。

根據(jù)深度學(xué)習(xí)作業(yè)的特性和硬件體系結(jié)構(gòu)，軟件棧和硬件棧的支持可以協(xié)同設(shè)計面向深度學(xué)習(xí)的作業(yè)調(diào)度策略，以提升資源利用率等指標。

二、異構(gòu)硬件的多樣性

深度學(xué)習(xí)作業(yè)訓(xùn)練時主要的計算單元是GPU，而用于這種計算的服務(wù)器通常會掛載多塊GPU。這種硬件體系結(jié)構(gòu)在某些方面與傳統(tǒng)的數(shù)據(jù)中心作業(yè)使用的服務(wù)器有所不同，因此也帶來了一些挑戰(zhàn)。

1、通信代價

由于多塊GPU之間的互聯(lián)方式多樣，不同的放置方式可能會受到GPU拓撲結(jié)構(gòu)的影響，進而影響數(shù)據(jù)通信的代價和性能。GPU根據(jù)一定的拓撲結(jié)構(gòu)掛載在PCIe總線或交換機上，因此GPU與GPU之間的通信可能會在節(jié)點內(nèi)跨越PCIe、PCIe交換機，或者在節(jié)點之間跨越InfiniBand或以太網(wǎng)。

2、資源爭用

由于作業(yè)本身可能會與其他作業(yè)共享服務(wù)器、數(shù)據(jù)總線等資源，因此也會受到來自其他作業(yè)的爭用和干擾。GPU拓撲結(jié)構(gòu)與任務(wù)的放置方式會影響多卡與分布式作業(yè)的訓(xùn)練性能。因此，可以考慮啟發(fā)優(yōu)化策略，即根據(jù)集群和服務(wù)器節(jié)點的GPU拓撲結(jié)構(gòu)的親和性來調(diào)度任務(wù)。

三、深度學(xué)習(xí)平臺的管理與運維需求

深度學(xué)習(xí)平臺需要對上管理深度學(xué)習(xí)模型訓(xùn)練作業(yè)，對下管理以GPU和InfiniBand為代表的異構(gòu)硬件，平臺管理與運維也面臨一些挑戰(zhàn)。相比機器學(xué)習(xí)工程師、數(shù)據(jù)科學(xué)家等使用平臺的用戶，深度學(xué)習(xí)平臺管理員更加關(guān)注以下的設(shè)計目標：

1、效率

GPU集群價格昂貴，更新?lián)Q代頻繁，如何有效地規(guī)劃集群，提升投入產(chǎn)出比，以及如何在現(xiàn)有集群中減少資源碎片，提升利用率，是平臺管理員面臨的重要挑戰(zhàn)。調(diào)度算法在一定程度上能夠優(yōu)化和提升集群的資源利用率。

2、公平性

使用深度學(xué)習(xí)平臺的用戶既有工程目的，也有很多是科研目的。在訓(xùn)練生產(chǎn)模型的同時，也有一些是研究投稿、趕論文截止的需求。這使得相比傳統(tǒng)批處理調(diào)度場景，用戶有類似特定時段的峰值資源使用需求。平臺需要保證各組資源使用的公平性，同時提前規(guī)劃好用戶的資源使用，同時兼顧峰值利用需求，需要管理員設(shè)計好相應(yīng)的策略。

3、穩(wěn)定性

1）由于深度學(xué)習(xí)框架的設(shè)計者在初始沒有像大數(shù)據(jù)社區(qū)一樣把容錯當(dāng)成第一要義，框架提供基礎(chǔ)的檢查點機制，但是需要用戶控制，沒有自動備份與恢復(fù)的支持，在之后的設(shè)計版本和社區(qū)工具中才有彈性等功能的支持。這給底層平臺帶來比較大的運維負擔(dān)。

2）由于節(jié)點上的異構(gòu)硬件也有一定概率產(chǎn)生硬件問題，例如GPU故障，造成平臺穩(wěn)定性的挑戰(zhàn)。如何高效、敏捷地發(fā)現(xiàn)和修復(fù)故障，除了工具的支持，還需要系統(tǒng)化的系統(tǒng)設(shè)計、開發(fā)流程設(shè)計與管理策略設(shè)計共同作用。

4、可維護性

平臺團隊同時在開發(fā)和運維平臺，可維護性也是平時減少運維負擔(dān)的一個重要考慮的因素。通過微服務(wù)等手段將功能模塊盡可能地拆分，能夠讓故障的定位與修復(fù)最小化，同時良好的DevOps流程搭建、敏捷的開發(fā)與項目管理也為平臺的可維護性提升起到關(guān)鍵的作用。

5、用戶體驗

用戶體驗良好并統(tǒng)一的作業(yè)提交、作業(yè)管理與調(diào)試工具，能大幅提升用戶的開發(fā)生產(chǎn)力，同時也能減輕平臺運維工程師的負擔(dān)。

除以上指標，平臺也會關(guān)注性能（吞吐、完工時間等）指標。平臺本身模塊眾多，涉及的外部交互的軟硬件多樣，使用和維護的用戶也很多，所以其面對的問題場景較為復(fù)雜。作為平臺設(shè)計者和使用者需要全面考慮，性能只是其中的一個環(huán)節(jié)，還要以系統(tǒng)化的視角去設(shè)計和管理整個異構(gòu)資源，為上層應(yīng)用負載與用戶提供更加透明與便捷的用戶體驗。

四、深度學(xué)習(xí)負載與異構(gòu)硬件下的調(diào)度設(shè)計

下面將從深度學(xué)習(xí)平臺的調(diào)度算法入手，介紹考慮不同設(shè)計目標和側(cè)重點的調(diào)度算法設(shè)計。這些調(diào)度器由于設(shè)計目標不同，所基于的假設(shè)也不同，同時實現(xiàn)和對作業(yè)的入侵性也不同。因此，在選用和設(shè)計調(diào)度器時，需要考慮不同算法的優(yōu)劣勢并根據(jù)平臺現(xiàn)狀酌情選擇。

1、框架與平臺協(xié)同設(shè)計的調(diào)度器設(shè)計

1）反應(yīng)模式（Reactive Mode）

類似于傳統(tǒng)調(diào)度器的事件驅(qū)動設(shè)計，根據(jù)不同的事件和狀態(tài)（如作業(yè)到達、離開、失效）觸發(fā)調(diào)度策略?？梢詫⑵湔w策略抽象為一個狀態(tài)機。

分布式作業(yè)調(diào)度受局部性影響

通過圖表可以看到，將同樣需要2塊GPU卡的作業(yè)分別調(diào)度在相同PCIe交換機、跨交換機和跨節(jié)點下進行部署運行，會產(chǎn)生40%~5x的降速。因此，對于多卡作業(yè)，考慮部署的局部性，通過親和性調(diào)度可以讓作業(yè)執(zhí)行更快，節(jié)省更多的資源執(zhí)行其他作業(yè)，從而對整體完工時間有益，并提升資源利用率。

當(dāng)觸發(fā)調(diào)度時，該調(diào)度策略優(yōu)先考慮親和性，在調(diào)度過程中按照以下優(yōu)先級考慮和排序節(jié)點進行作業(yè)分配，以減少深度學(xué)習(xí)作業(yè)的數(shù)據(jù)I/O開銷并提升性能。其優(yōu)先考慮的待分配節(jié)點優(yōu)先級為：

●擁有相同親和性的節(jié)點。

●還未標注親和性的節(jié)點。

●有不同親和性的節(jié)點。

●進行超額訂閱，在有相同親和性的節(jié)點暫停和恢復(fù)其他作業(yè)。

●不滿足以上條件，則作業(yè)排隊等待。

以圖為例，調(diào)度器將需要1個GPU的作業(yè)放在一起，但需要2或4個GPU的作業(yè)放置在不同的服務(wù)器上。此外，通過選擇負載最小的服務(wù)器，試圖平衡每臺服務(wù)器上的超額訂閱負載，以防止1個GPU需求作業(yè)的服務(wù)器中各有6個1個GPU需求的作業(yè)。

16 塊 GPU 集群中，Gandiva 調(diào)度實例

2）內(nèi)省模式（Introspective Mode）

應(yīng)用于作業(yè)執(zhí)行后，持續(xù)監(jiān)控并定期優(yōu)化當(dāng)前作業(yè)的放置（Placement），同時通過擴展框架支持細粒度的檢查點和恢復(fù)功能，為后續(xù)備份與遷移策略提供基礎(chǔ)原語的支持。通過不斷監(jiān)控作業(yè)利用率和節(jié)點資源利用率，進行作業(yè)的裝箱（Bin Packing）、遷移（Migration）、增長收縮（Grow-Shrink）、超額訂閱和時間切片（Time Slicing），進而提升整體資源利用率，降低作業(yè)的完工時間（Makespan）。

裝箱（Bin Pack）是指在保證GPU顯存約束的情況下，根據(jù)浮點運算量，將更多的作業(yè)裝箱到相同GPU，提升資源利用率。時分復(fù)用（Time Slicing）則是利用框架層或底層實現(xiàn)的檢查點和恢復(fù)機制，多個作業(yè)可以通過時分復(fù)用，共享單塊GPU。這可以類比于一種粗粒度的進程上下文切換（Context Switching）機制。

遷移（Migration）則是利用框架層或底層實現(xiàn)的檢查點和恢復(fù)機制，當(dāng)有空閑資源或獎勵資源時，動態(tài)遷移作業(yè)使用獎勵資源，加速訓(xùn)練。當(dāng)作業(yè)需要被搶占以歸還資源時，遷移作業(yè)保證作業(yè)之前的訓(xùn)練不失效。

上圖展示了一個集群實驗的示例。在多作業(yè)調(diào)度的場景中，有4個需要2塊GPU的作業(yè)，這些作業(yè)都已經(jīng)調(diào)度，但其中3個作業(yè)沒有好的親和性（J1、J2和J3），只有J0的GPU被打包分配到了相同的節(jié)點。3分鐘后，一個使用DeepSpeed框架訓(xùn)練的作業(yè)訓(xùn)練完成并釋放8塊GPU，其中3塊在圖中以綠色圓圈表示，并分布在不同服務(wù)器。這三塊GPU有潛力提升當(dāng)前多個作業(yè)的訓(xùn)練效率。

調(diào)度器啟動遷移流程，重新分配J1、J2和J3到放置在一起的GPU。為減少碎片，選擇將空閑GPU最多的服務(wù)器上的作業(yè)進行遷移。然后開始遷移正在運行的作業(yè)從當(dāng)前服務(wù)器（空閑GPU更多的）到另一個服務(wù)器（空閑GPU更少的），以便同作業(yè)的任務(wù)可以在同一臺服務(wù)器的GPU上執(zhí)行。

Gandiva不斷重復(fù)這個過程，直到非空閑服務(wù)器上的空閑GPU數(shù)量小于一定閾值（實驗中使用3/4作為閾值），或者直到?jīng)]有作業(yè)能夠受益于作業(yè)遷移。

共享資源集群中，Gandiva 進行作業(yè)遷移實例

2、面向特定場景問題（多租）的調(diào)度器設(shè)計

排隊延遲問題

上圖展示兩個月內(nèi)的日志數(shù)據(jù)，涉及一個擁有2232個GPU的集群，11個租戶，私有集群，共享多租集群，以及HiveD優(yōu)化后的共享多租集群情況。其中，紅色線條顯示了由于多租環(huán)境下的要求，作業(yè)需要滿足節(jié)點親和性硬約束（盡可能將作業(yè)調(diào)度到通信距離更近的節(jié)點），導(dǎo)致平均有7倍的延遲。HiveD OSDI 提出，如果調(diào)度深度學(xué)習(xí)作業(yè)時同時考慮多租環(huán)境和GPU親和性，會盡可能將親和性高的資源整體分配給作業(yè)，這會導(dǎo)致集群調(diào)度容易出現(xiàn)排隊延遲較高的異常。

HiveD通過設(shè)計多級單元格（Cell）結(jié)構(gòu)，并采用伙伴單元格分配（Buddy Cell Allocation）算法，以確保在滿足上述約束的前提下，資源能夠高效分配，降低排隊時間和資源碎片化。同時，HiveD能夠與其他調(diào)度器兼容集成使用。

下圖展示了四個級別的單元格結(jié)構(gòu)：GPU（Level-1）、PCIe交換機（Switch）(Level-2)、CPU套接字（Socket）（Level-3）和節(jié)點級別（Level-4）。當(dāng)前實例集群有一個機架，由四個8-GPU節(jié)點組成，由三個租戶A、B和C共享。

HiveD機架的多級單元分配示例

藍海大腦異構(gòu)集群管理解決方案

隨著企業(yè)規(guī)模逐漸擴展，特別是私有云數(shù)據(jù)庫架構(gòu)中經(jīng)常存在多種硬件機型和操作系統(tǒng)版本，對這些硬件進行批量更換和升級是一項高風(fēng)險、高成本的工作。藍海大腦異構(gòu)集群管理解決方案不僅可以協(xié)助企業(yè)充分利用現(xiàn)有設(shè)備，還提供了平滑過渡方案，為新型硬件、異構(gòu)芯片的灰度替換提供支持。同時，該解決方案還支持國密算法加密副本的混合部署，為企業(yè)國產(chǎn)化升級提供安全穩(wěn)定的解決方案。

藍海大腦異構(gòu)集群管理解決方案通過主備集群架構(gòu)，備集群使用新型硬件完成了第一階段的灰度驗證，期間對主集群業(yè)務(wù)沒有任何影響。AI異構(gòu)計算平臺，包含AI計算、AI存儲、AI加速、AI容器四大核心套件，具有高性能、高彈性、高速互聯(lián)、高性價比等特性。AI計算方面，提供基于自研GPU硬件架構(gòu)X-MAN的高性能實例，充分滿足AI單機訓(xùn)練、分布式集群訓(xùn)練、AI推理部署等對算、存、傳的性能訴求。AI存儲方面，基于AI存儲架構(gòu)，從數(shù)據(jù)上云、數(shù)據(jù)存儲、數(shù)據(jù)處理和數(shù)據(jù)加速為計算提供全鏈條的支撐。AI加速方面，通過存訓(xùn)推一體化加速，通過對存儲訪問、模型訓(xùn)練和推理的加速進一步提速AI任務(wù)。AI容器方面，AI容器提供GPU顯存和算力的共享與隔離，集成PaddlePaddle、TensorFlow、Pytorch等主流深度學(xué)習(xí)框架，支持AI任務(wù)編排、管理等。

一、業(yè)務(wù)挑戰(zhàn)

1、高風(fēng)險

傳統(tǒng)數(shù)據(jù)庫硬件的批量替換風(fēng)險很高，因為缺乏有效的灰度方案來逐步引入更改，而異構(gòu)復(fù)制方案又難以確保數(shù)據(jù)的一致性。如果同一批次硬件或操作系統(tǒng)存在統(tǒng)一問題，往往會集中爆發(fā)，嚴重的情況下可能對業(yè)務(wù)造成不可挽回的損失。

2、高成本

傳統(tǒng)替換方案往往需要部署專屬環(huán)境來進行長期驗證，這會產(chǎn)生高昂的資源并行成本。這些成本包括但不限于購買和維護額外的硬件、能源消耗和管理人力資源以監(jiān)視和維護這些并行系統(tǒng)。

3、難以維護

搭建異構(gòu)驗證環(huán)境不僅消耗硬件資源，而且使得整個數(shù)據(jù)庫基礎(chǔ)架構(gòu)更加復(fù)雜，維護起來更加困難。這種復(fù)雜性可能會導(dǎo)致潛在的錯誤和故障，增加了維護成本和難度。

二、方案優(yōu)勢

1、兼容開放支撐海光、鯤鵬、Intel等多種芯片及其生態(tài)，滿足不同的用戶和場景需求

兼容多種類型的芯片，包括海光、鯤鵬和Intel等，并且可以支持這些芯片的生態(tài)系統(tǒng)。

2、功能一致數(shù)據(jù)庫自動適配，用戶無需區(qū)分底層的芯片形態(tài)，透明無感

自動適應(yīng)不同的底層芯片形態(tài)，無需關(guān)心底層的硬件細節(jié)，感覺就像在使用一個統(tǒng)一的功能一致的數(shù)據(jù)庫。

3、數(shù)據(jù)一致，支持異構(gòu)芯片，副本數(shù)據(jù)一致性校驗，確保數(shù)據(jù)一致性和正確性，具備容災(zāi)切換能力

保證在異構(gòu)芯片上的副本數(shù)據(jù)保持一致性，通過數(shù)據(jù)一致性校驗來確保數(shù)據(jù)的準確性和一致性。同時，這個系統(tǒng)還具備容災(zāi)切換的能力，可以在發(fā)生故障時快速切換到備用系統(tǒng)上。

4、混合部署，支持多副本混部、主備集群混部、機房混部等多種形態(tài)，支持長期混部運行

支持多種部署形態(tài)，比如多副本混部、主備集群混部和機房混部等。不同的部署形態(tài)可以滿足不同的業(yè)務(wù)需求，并且系統(tǒng)還支持長期混部運行，使得系統(tǒng)的可用性和穩(wěn)定性得到了極大的提升。

5、灰度切換支持按可用區(qū)（Zone）切換，最細粒度支持按表分區(qū)灰度切換，支持平滑灰度遷移替換

支持灰度切換，用戶可以選擇按可用區(qū)進行切換，最細粒度可以按表分區(qū)進行灰度切換。

6、灰度加密支持國密算法加密副本的混部，為全局開啟加密存儲提供平滑過渡方案

支持使用國密算法進行加密，可以在混部過程中對數(shù)據(jù)進行加密，為全局開啟加密存儲提供了平滑過渡方案。

7、異構(gòu)資源統(tǒng)一管理提供多集群的計算、存儲、網(wǎng)絡(luò)等資源的統(tǒng)一視圖， 并實現(xiàn)多集群網(wǎng)絡(luò)打通、鏡像統(tǒng)一管理

提供多集群的計算、存儲、網(wǎng)絡(luò)等資源的統(tǒng)一視圖，實現(xiàn)多集群網(wǎng)絡(luò)打通和鏡像統(tǒng)一管理。

8、構(gòu)建基于多種指標的自動伸縮策略，搭配負載均衡器，實現(xiàn)業(yè)務(wù)彈性

基于多種指標的自動伸縮策略，結(jié)合負載均衡器，可以實現(xiàn)業(yè)務(wù)的彈性擴展和收縮，保持業(yè)務(wù)的高可用性和性能。

9、支持x86/ARM/國產(chǎn)化等多架構(gòu)裸金屬服務(wù)器的管理，幫助用戶實現(xiàn)上電自動發(fā)現(xiàn)、一鍵部署開通與統(tǒng)一網(wǎng)絡(luò)管理

支持x86、ARM和國產(chǎn)化等多架構(gòu)裸金屬服務(wù)器的管理，并且可以幫助用戶實現(xiàn)上電自動發(fā)現(xiàn)、一鍵部署開通和統(tǒng)一網(wǎng)絡(luò)管理等功能。

10、實現(xiàn)與虛擬機、容器的業(yè)務(wù)網(wǎng)絡(luò)打通

幫助用戶實現(xiàn)與虛擬機和容器等不同環(huán)境之間的業(yè)務(wù)網(wǎng)絡(luò)打通，使得不同環(huán)境之間的通信更加順暢和高效。

三、應(yīng)用場景

1、高性能計算(HPC)

HPC領(lǐng)域利用異構(gòu)集群進行天氣預(yù)報、地震分析、石油勘探等科學(xué)計算。典型配置是使用多核CPU服務(wù)器組成主集群,同時加入GPU服務(wù)器用于并行加速。也會采用不同的網(wǎng)絡(luò)拓撲和互聯(lián)來優(yōu)化吞吐和延遲。

2、人工智能(AI)

AI訓(xùn)練任務(wù)會使用成百上千張GPU來搭建規(guī)模巨大的異構(gòu)集群，例如NVIDIA的DGX SuperPOD。針對不同的訓(xùn)練階段,可以靈活使用不同型號的GPU服務(wù)器。AI推理任務(wù)則會采用專門的AI加速卡,按需彈性部署。

3、大數(shù)據(jù)分析

大數(shù)據(jù)平臺如Apache Hadoop、Spark會搭建以標準X86服務(wù)器為中心的大規(guī)模集群，并加入GPU服務(wù)器用于機器學(xué)習(xí)算法的并行加速。不同類型的分析任務(wù)可以負載到不同規(guī)格的服務(wù)器上。

4、科學(xué)計算

利用異構(gòu)集群進行天文統(tǒng)計學(xué)分析、粒子物理模擬、量子化學(xué)計算等。除了GPU服務(wù)器,也會采用FPGA、ASIC等專硬加速器進行優(yōu)化。

5、工程設(shè)計

汽車、航空航天的設(shè)計需要進行復(fù)雜物理仿真,通過異構(gòu)集群進行并行仿真可以大幅提升效率。此外還需要使用GPU渲染、圖像處理。

6、金融

金融量化交易使用異構(gòu)集群提升回測和交易性能。加入FPGA可以實現(xiàn)超低延遲的高頻交易。區(qū)塊鏈也需要大規(guī)模挖礦集群提供算力。

7、軍事國防

異構(gòu)集群可應(yīng)用于軍事仿真,指揮控制,圖像識別等任務(wù)。出于安全考慮，敏感應(yīng)用會采用定制化芯片。