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

異構計算的主要驅動力來自于暗硅和異構硬件的發展趨勢。數據中心硬件日益多樣化，用戶以多租共享的方式使用硬件。因此，統一管理需求逐漸產生。為管理計算和存儲異構硬件，通常需要在統一空間內對其進行抽象和管理，最終實現用戶對硬件透明化的使用。異構計算集群調度和資源管理系統在人工智能系統中類似于傳統操作系統，對底層異構資源（如GPU、CPU等）進行抽象，對上調度深度學習作業并分配資源。在啟動作業后，還需進行資源隔離、環境隔離和作業生命周期管理。

異構計算集群管理系統簡介

異構計算集群管理系統是一種系統軟件，負責管理計算機集群內的多個節點的硬件（如GPU、CPU、內存、磁盤等）和軟件資源（如框架、作業、鏡像等），并為計算機程序（通常是深度學習訓練作業）提供通用服務（如作業提交、調試、監控、克隆等）。簡而言之，異構計算集群管理系統是一種管理和優化計算機集群內硬件和軟件資源的系統軟件，旨在為深度學習訓練提供通用服務。

一、多租環境運行的訓練作業

多租環境提交運行作業

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

當前深度學習場景下，平臺系統管理的資源是異構的（如CPU、GPU等）。與深度學習開發者獨占服務器進行模型訓練相比，多用戶共享多GPU服務器有很大的不同。這也為異構計算集群管理系統（簡稱平臺或深度學習平臺）的設計帶來相應需求，主要體現在以下幾個方面：

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

1）每個用戶為不斷改進模型、超參數調優、調試和優化作業向平臺提交大量作業。

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

2、作業環境需求多樣

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

3、作業資源需求多樣

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

4、服務器軟件環境單一

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

5、服務器空閑資源組合多樣

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

從上述問題可以看出，需要統一的平臺系統來支撐調度和資源管理。其在底層抽象和管理計算資源，在上層為應用提供隔離且易用的作業運行環境。簡而言之，是支持深度學習應用管理分布式GPU服務器集群的操作系統。

二、作業生命周期

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

GPU 集群

1、平臺上作業生命周期

1）作業提交與排隊

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

2）作業資源分配與調度

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

3）作業執行完成與釋放

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

2、可以將作業在平臺上的狀態抽象為以下狀態機

1)作業準備與提交：觸發作業提交動作

●提交成功

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

2)作業排隊：觸發作業調度動作

●調度成功

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

3)作業部署運行：觸發作業執行動作

●執行成功

●作業失敗，重試次數<=N：重新開始提交

●作業失敗，重試次數>N：作業失敗退出

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

三、集群管理系統架構

異構集群管理系統架構

異構集群管理系統通常包含多個組件。其中，調度器負責資源與作業的管理，監控系統負責監控系統的健康狀態并發出警報，Web界面提供用戶交互接口，存儲系統則用于存儲數據、模型和代碼。

1、平臺的主要組件包括

1)集群調度與資源管理模塊

統一管理集群資源，調度作業到空閑資源上，回收已完成作業的資源。控制平面可以選擇Kubernetes、Mesos等系統，也可以使用面向深度學習作業的定制調度器。

2）鏡像中心

存儲Docker鏡像，供用戶提交和共享鏡像，作業下載鏡像。可以使用公共中心如Docker Hub，也可以構建私有中心或使用云鏡像中心。

3）存儲模塊

扮演數據平面角色，存儲數據、模型和代碼。用戶上傳和作業下載數據。

4）作業生命周期管理器

部署、監控、重試作業以及診斷錯誤是單作業的控制平面所涉及的任務。在這個平面上，可以構建自動機器學習系統，而不需要考慮其他作業。在平臺接口的基礎上，可以選擇使用K8S Operator、Framework Controller或YARN AppMaster等工具來實現這些功能。

5）集群監控與報警

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

6）集成開發環境

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

7）測試集群

為隔離生產環境，可以部署一個小規模的測試集群，用于開發和測試。

2、平臺部署模式

1）本地部署

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

2）公有云部署

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

3）混合云

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

4）多云

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

本地與云部署成本趨勢

訓練作業，鏡像與容器

平臺作業與開發體驗

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

一、深度學習作業

在本地機器或獨占服務器上開發訓練模型時，環境問題較少，還未暴露更多挑戰。獨占環境的情況如下:

●無需考慮依賴環境和資源隔離問題

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

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

●數據直接上傳到本地磁盤，帶寬高

●直接在磁盤執行啟動腳本，修改調試方便

如果環境準備好，可以通過下面的腳本啟動訓練:

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

{

// 作業名稱

"jobName": "resnet",

// 鏡像名稱

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

// 輸入數據存儲路徑

"dataDir": "/tmp/data",

// 數據結果存儲路徑

"outputDir": "/tmp/output",

...

// 任務規格:資源需求、啟動腳本等

"taskRoles": [

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

]

}

從作業提交規格示例可以看出，當用戶將作業提交到有4塊GPU服務器時,平臺需要提供以下支持:

1、環境依賴

1）問題

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

2）解決方法

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

2、數據與代碼

1）問題

平臺上運行的是深度學習訓練作業，每個作業需要輸入數據和代碼。如果直接上傳到服務器會造成過大負載，則無法復用數據和代碼。

2）解決方法

通過指定"dataDir"和"outputDir"路徑來處理作業的輸入數據和輸出結果。用戶提前上傳數據和代碼到平臺指定的文件系統路徑下，未來平臺會將網絡文件系統中的數據和代碼掛載到運行作業的機器上。

3、資源申請量

1）問題

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

2）解決方法

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

4、資源隔離

1）問題

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

2）解決方法

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

5、任務部署模式

1）問題

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

2）解決方法

用戶明確告知需要啟動的任務數量，平臺啟動多個任務副本進行訓練。

6、作業啟動命令

1）問題

平臺需要知道作業的啟動命令來啟動和執行代碼。

2）解決方法

用戶在作業中明確描述啟動入口命令，啟動并執行代碼。

二、環境依賴：鏡像（Image）

當用戶在平臺上執行作業時，首要問題是本地環境與集群環境差異：

●服務器沒有預裝所需個性化環境

●不同作業需要不同框架、依賴和版本，安裝繁瑣且重復

●服務器上有大量重復安裝的庫，占用空間

●深度學習特有問題：需要安裝CUDA、框架等

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

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

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

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

PyTorch 鏡像文件中包含的依賴

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

當用戶在平臺上執行作業時，如何避免作業間的資源爭用干擾，實現資源隔離：

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

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

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

●深度學習的特殊問題：如何隔離GPU的核和內存?

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

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

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

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

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

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

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

四、從操作系統視角看 GPU 技術棧

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

1、修改內核

將GPU設備驅動和調度邏輯集成到內核中，通過擴展內核實現GPU的虛擬化和調度。但這種方法需要修改內核，代價較大。

2、在用戶空間實現資源管理組件

通過封裝內核接口提供調度和虛擬化支持。這種方法兼容性較好，也更容易迭代。已經有一些相關工作實現了用戶級的GPU虛擬化管理。

將GPU納入操作系統統一資源管理的目的是讓GPU能夠像CPU一樣被多任務調度，這是實現GPU多租戶和自動化管理的基礎。

CPU和GPU技術棧與操作系統抽象

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

五、人工智能作業開發體驗（Development Experience）

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

1、客戶端集成開發環境（IDE）

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

2、一站式人工智能開發插件

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

3、代碼完成工具

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

通過Web界面提交作業到集群

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

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

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

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

人工智能作業的不同開發環境

如圖所示，開發者通常會經歷以下三個階段：本地開發、測試服務器開發和打包程序提交到平臺執行。在每個階段，都會進行相應的操作。首先，在本地開發階段，開發者會在自己的計算機上編寫和測試程序。然后，在測試服務器開發階段，會對程序進行更嚴格的測試，以確保其能夠在生產環境中正常運行。最后，在打包程序提交到平臺執行階段，開發者會將程序打包并提交到集群管理系統進行批處理。在執行作業的過程中，開發者需要監控作業狀態并進行調試，以確保程序能夠順利執行并返回正確的結果。根據訓練結果，開發者可以調整和優化程序，然后開始下一次的作業提交。

人工智能作業開發體驗時序圖

如下圖所示，當作業已經調試完成，用戶會經歷以下的步驟與平臺交互完成訓練過程：

●用戶首先上傳數據到存儲

●上傳鏡像到鏡像中心

●提交作業規格。填寫數據，鏡像路徑，資源需求和啟動命令行

●集群調度器調度作業

●空閑 GPU 節點拉取（Pull）鏡像

●空閑 GPU 節點啟動作業

●掛載文件系統

●作業運行啟動

●作業監控不斷匯報性能指標和日志用于觀測與調試

●訓練完成作業保存結果

提交到集群的作業生命周期

調度

平臺調度器

在作業進程啟動之前，平臺需要進行決策，確定當前作業應該在哪些服務器和GPU上運行，以及哪個作業可以優先執行，進而進行調度決策。下面將圍繞調度問題的抽象和優化目標，以及可用于深度學習作業調度的傳統調度算法進行介紹，了解作業調度的經典問題和解決方法。

一、調度問題優化目標

調度是分配資源以執行任務的過程。在深度學習平臺中，資源包括處理器、GPU、內存等，而任務則是用戶提交的作業。調度活動由稱為調度器的進程執行。調度器的算法通常旨在使所有計算機資源保持忙碌，讓多個用戶高效地共享系統資源實現目標服務質量。

在運行深度學習作業的集群服務器上，會部署一個操作系統進行作業管理與調度，即異構資源管理系統也稱作深度學習平臺。該系統不同于傳統操作系統，其特點是運行的“進程”一般為深度學習作業。

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

1、作業延遲與吞吐相關指標

1）排隊延遲

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

●公平性

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

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

可能導致資源無法分配和等待

2）平均響應時間

從提交請求到產生第一個響應的時間量的平均值。

3）平均作業完成時間

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

4）完工時間

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

5）吞吐

單位時間能完成的作業數量（吞吐量越大越好）。

2、平臺資源利用率相關指標

1）資源利用率

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

2）資源碎片

作業分配后造成個別節點資源無法被再分配，產生碎片問題。碎片越少，代表資源浪費越少。也是和資源利用率相關的指標。

3、公平與服務水平相關指標

1）公平性

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

2）服務水平協議

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

如下圖所示，平臺中包含以下集群與作業的包含層級關系，不同層次中蘊含不同的調度問題，可以將之后涉及的面向深度學習調度算法也映射到其中的層級問題的解決方法。

平臺中的作業調度問題總覽

二、單作業調度—群調度

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

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

并行啟動執行作業可能產生的問題

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

并行執行作業可能產生的問題

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

三、作業間調度—主導資源公平 DRF（Dominant Resource Fairness）調度

在包含多種異構資源的系統中，實現多作業公平的資源調度是一項挑戰。深度學習作業需要使用CPU、GPU和內存等多種資源，因此需要一種考慮多種資源的公平調度策略。DRF（Dominant Resource Fairness）是一種用于多資源公平調度的算法，通過使用主導份額的概念來比較多種資源的分配。

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

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

2個作業的DRF調度實例

以下的資源申請需求中，主導資源是內存。

以下的資源申請需求中，主導資源是GPU。

四、組間作業調度—容量調度（Capacity Scheduling）

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

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

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

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

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

1、提高利用率（Utilization）

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

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

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

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

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

2）允許多用戶以多租形式使用集群。控制單用戶的可以消耗的最大資源，防止其占用過多資源，導致其他進程無法申請資源。

3、彈性和SLA

1）獎勵資源（Bonus Resource）

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

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

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

容量調度

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

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

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

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

六、搶占式調度

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

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

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

作業等待時間過長問題

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

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

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

2）通知作業（即隊列A）控制器即將觸發搶占。

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

搶占強度

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

數據進行模擬，看能否提升當前目標并超越基準算法。最后，對結果進行分析，并形成分析報告或論文。

面向深度學習的集群管理系統

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

一、深度學習工作負載的需求

1、深度學習訓練作業 vs. 傳統的數據中心批處理作業

1）執行時間長

訓練時間持續數小時甚至幾天

2）迭代計算

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

3）內存數據量動態變化

在訓練過程中不同的時間點做檢查點有不同的內存數據量

4）性能可預測性

資源消耗可預測性，可以通過運行時監控獲取

2、分布式深度學習訓練作業的特點

1）對GPU拓撲結構敏感

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

2）反饋驅動探索

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

根據深度學習作業的特性和硬件體系結構，軟件棧和硬件棧的支持可以協同設計面向深度學習的作業調度策略，以提升資源利用率等指標。

二、異構硬件的多樣性

深度學習作業訓練時主要的計算單元是GPU，而用于這種計算的服務器通常會掛載多塊GPU。這種硬件體系結構在某些方面與傳統的數據中心作業使用的服務器有所不同，因此也帶來了一些挑戰。

1、通信代價

由于多塊GPU之間的互聯方式多樣，不同的放置方式可能會受到GPU拓撲結構的影響，進而影響數據通信的代價和性能。GPU根據一定的拓撲結構掛載在PCIe總線或交換機上，因此GPU與GPU之間的通信可能會在節點內跨越PCIe、PCIe交換機，或者在節點之間跨越InfiniBand或以太網。

2、資源爭用

由于作業本身可能會與其他作業共享服務器、數據總線等資源，因此也會受到來自其他作業的爭用和干擾。GPU拓撲結構與任務的放置方式會影響多卡與分布式作業的訓練性能。因此，可以考慮啟發優化策略，即根據集群和服務器節點的GPU拓撲結構的親和性來調度任務。

三、深度學習平臺的管理與運維需求

深度學習平臺需要對上管理深度學習模型訓練作業，對下管理以GPU和InfiniBand為代表的異構硬件，平臺管理與運維也面臨一些挑戰。相比機器學習工程師、數據科學家等使用平臺的用戶，深度學習平臺管理員更加關注以下的設計目標：

1、效率

GPU集群價格昂貴，更新換代頻繁，如何有效地規劃集群，提升投入產出比，以及如何在現有集群中減少資源碎片，提升利用率，是平臺管理員面臨的重要挑戰。調度算法在一定程度上能夠優化和提升集群的資源利用率。

2、公平性

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

3、穩定性

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

2）由于節點上的異構硬件也有一定概率產生硬件問題，例如GPU故障，造成平臺穩定性的挑戰。如何高效、敏捷地發現和修復故障，除了工具的支持，還需要系統化的系統設計、開發流程設計與管理策略設計共同作用。

4、可維護性

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

5、用戶體驗

用戶體驗良好并統一的作業提交、作業管理與調試工具，能大幅提升用戶的開發生產力，同時也能減輕平臺運維工程師的負擔。

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

四、深度學習負載與異構硬件下的調度設計

下面將從深度學習平臺的調度算法入手，介紹考慮不同設計目標和側重點的調度算法設計。這些調度器由于設計目標不同，所基于的假設也不同，同時實現和對作業的入侵性也不同。因此，在選用和設計調度器時，需要考慮不同算法的優劣勢并根據平臺現狀酌情選擇。

1、框架與平臺協同設計的調度器設計

1）反應模式（Reactive Mode）

類似于傳統調度器的事件驅動設計，根據不同的事件和狀態（如作業到達、離開、失效）觸發調度策略。可以將其整體策略抽象為一個狀態機。

分布式作業調度受局部性影響

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

當觸發調度時，該調度策略優先考慮親和性，在調度過程中按照以下優先級考慮和排序節點進行作業分配，以減少深度學習作業的數據I/O開銷并提升性能。其優先考慮的待分配節點優先級為：

●擁有相同親和性的節點。

●還未標注親和性的節點。

●有不同親和性的節點。

●進行超額訂閱，在有相同親和性的節點暫停和恢復其他作業。

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

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

16 塊 GPU 集群中，Gandiva 調度實例

2）內省模式（Introspective Mode）

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

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

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

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

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

Gandiva不斷重復這個過程，直到非空閑服務器上的空閑GPU數量小于一定閾值（實驗中使用3/4作為閾值），或者直到沒有作業能夠受益于作業遷移。

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

2、面向特定場景問題（多租）的調度器設計

排隊延遲問題

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

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

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

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

藍海大腦異構集群管理解決方案

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

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

一、業務挑戰

1、高風險

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

2、高成本

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

3、難以維護

搭建異構驗證環境不僅消耗硬件資源，而且使得整個數據庫基礎架構更加復雜，維護起來更加困難。這種復雜性可能會導致潛在的錯誤和故障，增加了維護成本和難度。

二、方案優勢

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

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

2、功能一致數據庫自動適配，用戶無需區分底層的芯片形態，透明無感

自動適應不同的底層芯片形態，無需關心底層的硬件細節，感覺就像在使用一個統一的功能一致的數據庫。

3、數據一致，支持異構芯片，副本數據一致性校驗，確保數據一致性和正確性，具備容災切換能力

保證在異構芯片上的副本數據保持一致性，通過數據一致性校驗來確保數據的準確性和一致性。同時，這個系統還具備容災切換的能力，可以在發生故障時快速切換到備用系統上。

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

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

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

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

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

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

7、異構資源統一管理提供多集群的計算、存儲、網絡等資源的統一視圖， 并實現多集群網絡打通、鏡像統一管理

提供多集群的計算、存儲、網絡等資源的統一視圖，實現多集群網絡打通和鏡像統一管理。

8、構建基于多種指標的自動伸縮策略，搭配負載均衡器，實現業務彈性

基于多種指標的自動伸縮策略，結合負載均衡器，可以實現業務的彈性擴展和收縮，保持業務的高可用性和性能。

9、支持x86/ARM/國產化等多架構裸金屬服務器的管理，幫助用戶實現上電自動發現、一鍵部署開通與統一網絡管理

支持x86、ARM和國產化等多架構裸金屬服務器的管理，并且可以幫助用戶實現上電自動發現、一鍵部署開通和統一網絡管理等功能。

10、實現與虛擬機、容器的業務網絡打通

幫助用戶實現與虛擬機和容器等不同環境之間的業務網絡打通，使得不同環境之間的通信更加順暢和高效。

三、應用場景

1、高性能計算(HPC)

HPC領域利用異構集群進行天氣預報、地震分析、石油勘探等科學計算。典型配置是使用多核CPU服務器組成主集群,同時加入GPU服務器用于并行加速。也會采用不同的網絡拓撲和互聯來優化吞吐和延遲。

2、人工智能(AI)

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

3、大數據分析

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

4、科學計算

利用異構集群進行天文統計學分析、粒子物理模擬、量子化學計算等。除了GPU服務器,也會采用FPGA、ASIC等專硬加速器進行優化。

5、工程設計

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

6、金融

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

7、軍事國防

異構集群可應用于軍事仿真,指揮控制,圖像識別等任務。出于安全考慮，敏感應用會采用定制化芯片。