算力調(diào)度的基礎知識

編者按

“算力調(diào)度”的概念，這幾年越來越多的被提及。剛聽到這個概念的時候，我腦海里一直拐不過彎。作為底層芯片出身的我，一直認為：算力是硬件的服務器和集群，他在某個地方，就是固定的；根本就不存在算力的調(diào)度，調(diào)度的應該是上層的業(yè)務軟件。

經(jīng)過跟行業(yè)眾多朋友的交流和思考后，我逐漸能夠理解“算力調(diào)度”所表達的意思。從業(yè)務的視角，客戶關心的是業(yè)務本身，需要算力隨時隨地可用，而不需要關注承載業(yè)務的具體的硬件在哪里。當然，要實現(xiàn)不需要關注硬件，有許多工作要做，這就是“算力調(diào)度”要完成的事情，也就是說：“算力調(diào)度，不僅僅是調(diào)度”。

本篇文章，我們簡單聊一聊算力調(diào)度，僅供探討，歡迎私信交流。

1 計算任務的特征

1.1 計算任務的時間和空間特征

計算任務（Workload，也譯作工作任務、工作負載等），是一個或一組相關的、運行中的應用程序。

站在軟件運行的角度，根據(jù)運行時間的長短，我們可以把計算任務簡單的分為兩類，短期型任務和常駐型任務：

短期型任務指的是，任務開始執(zhí)行，會在一定的時間內(nèi)運行完成，結(jié)束后會釋放計算資源。

常駐型任務指的是，沒有外部強制關閉的話，任務會一直處于執(zhí)行狀態(tài)，不會結(jié)束。

從微觀的看，某個特定的處理器，在其上運行的程序（線程）是分時調(diào)度的。這樣，線程的資源占用不會大于1個CPU核。

但相對宏觀的某個計算任務（一個進程或一組相關的進程），其占用的處理器資源既可以少于1個CPU核，也可以是多個CPU核，甚至多個CPU芯片、多臺服務器的集群，直到成千上萬臺服務器的大集群。最典型的例子就是AI大模型訓練，需要上千臺服務器上萬張GPU卡的計算集群來運行大模型訓練的計算任務，并且一次計算任務運行會持續(xù)數(shù)十天。

串行和并行，會影響計算任務的時間和空間。串行，是以時間換空間；反過來，并行則是以空間換時間。

當計算資源有限而計算任務尺寸較大時，可以把計算任務拆分成許多小計算任務，然后這些小計算任務串行運行。雖然計算的時間會增大，但可以在較小規(guī)模的計算資源上完成計算。

反過來，當計算任務的運行時間非常長，我們也可以把任務拆分成短任務，這些短任務并行運行在不同的計算資源上，從而減少計算的時間。這也就是我們經(jīng)常說的并行加速。

1.2 計算的兩種形態(tài)

根據(jù)軟件任務的尺寸和硬件服務器尺寸的匹配程度，可以簡單的把計算分為兩種類型：

第一種，一臺硬件服務器處理很多件計算任務。

像云計算，通過虛擬化或容器的方式，可以把單臺服務器分割成多份，每一個虛機或容器，就運行“一個計算任務”，一臺服務器可以同時支持多個計算任務運行。

目前，AI推理的計算任務，通常也可以在一臺服務器尺寸范圍內(nèi)完成。也因此，AI推理計算任務通常是基于云虛機或容器的方式來運行。

第二種，很多臺硬件服務器處理一件計算任務。

如超級計算（HPC），超算的計算節(jié)點可以看做是一臺計算機，然后超算實際上是這些計算節(jié)點組成的計算集群。超算的計算任務都比較大，通過并行占用所有計算資源的方式，達到快速計算的目的。

AI模型的訓練的計算任務，尺寸非常大，所以把模型進行拆分，拆分成若干小的計算任務，并且這些小的計算任務之間的聯(lián)系更加緊密，是一種緊耦合的關系。也因此，AI模型的訓練，通常是千卡萬卡，甚至更多GPU卡的高性能集群計算，各個需要計算節(jié)點之間需要高速（網(wǎng)絡）互聯(lián)通信。AI訓練的計算架構(gòu)，更接近HPC。

1.3 分布式解構(gòu)

隨著系統(tǒng)越來越大，單機計算已經(jīng)非常的少見，集群計算已經(jīng)成為主流。云計算模式，雖然某個具體的計算任務是放在一臺計算服務器上去運行，而實際的情況很可能是——這個計算任務是某個巨服務解構(gòu)拆分出的其中一個微服務。每個微服務聚焦做一個相對簡單的事情，從而使得單個微服務可以在單機上以虛機或容器的方式運行。

那這樣的話，計算豈不可以統(tǒng)一到一種形態(tài)？即單個計算任務需要多臺計算服務器來承載其運行。這里的關鍵，是在于大計算任務解構(gòu)拆分的不同小計算任務之間的交互耦合度。這樣，根據(jù)交互耦合度和網(wǎng)絡硬件實現(xiàn)，我們分為如下幾個情況（耦合性依次降低）：

IB高性能網(wǎng)絡+內(nèi)存一致性硬件加速。計算任務之間完全緊耦合，通常采用超級計算（HPC）模式。超算的各個節(jié)點之間主流是通過IB網(wǎng)絡連接，但會在其上構(gòu)建高效的內(nèi)存一致性協(xié)議加速處理，從而使得整個超算連成一臺計算機。

IB高性能網(wǎng)絡。計算任務之間，聯(lián)系緊密，數(shù)據(jù)量大，延遲敏感。計算機集群，通過IB網(wǎng)絡連接。本質(zhì)上仍然是多臺計算機組成的計算集群，計算任務間靠點對點通信交互數(shù)據(jù)。典型案例如AI大模型訓練。

RoCEv2高性能網(wǎng)絡。計算任務之間延遲敏感，但聯(lián)系緊密程度再低一些，通常可以選用RoCEv2的方式。RoCEv2在高性能、兼容性和低成本方面達成一個均衡。典型案例如EBS高性能塊存儲和分布式文件存儲。

標準Ethernet網(wǎng)絡。計算任務之間完全解耦，則通常采用標準以太網(wǎng)的方式。傳統(tǒng)的云計算下，微服務解構(gòu)的互聯(lián)網(wǎng)業(yè)務通常采取此網(wǎng)絡方式。

2 理想化的算力調(diào)度

依據(jù)計算任務的時間和空間特性，相對應的算力調(diào)度方式也就分為四類：

短期的小尺寸計算任務。這是通常大家理解的算力調(diào)度，也是算力調(diào)度最簡單的情況。

短期的大尺寸計算任務。超算或AI大模型訓練的計算模式。

常駐的小尺寸計算任務。云計算常見的業(yè)務組織方式，是常駐的小尺寸計算任務。

長期的大尺寸計算任務。實際的互聯(lián)網(wǎng)型業(yè)務系統(tǒng)。

這里，我們從計算的角度，談一下計算方式的統(tǒng)一：

一個是，計算任務的解構(gòu)（計算任務的彈性）。大尺寸的計算任務，可以拆分成若干個小尺寸的計算任務。從而使得計算任務能夠匹配單個裸機的計算主機（裸機、虛擬機、容器等）；

另一個，計算資源的池化（虛擬化）和再組合（計算主機的彈性）。計算主機可以從1/N個處理器核、擴展到多個處理器核，甚至擴展到M個計算節(jié)點。因為計算主機的彈性，從而使得計算主機既可以適配小尺寸的計算任務，也可以適配大尺寸的計算任務。

兩者相向而行，并且均具有一定的（尺寸）彈性，從而能夠盡可能的適配對方。

3 實際算力調(diào)度中的問題

3.1 問題一：靜態(tài)調(diào)度和動態(tài)調(diào)度

靜態(tài)調(diào)度：計算任務在初始運行時，分配計算資源時候的調(diào)度。一般來說，短期型的計算任務，通常只有靜態(tài)調(diào)度，也即僅調(diào)度一次，運行結(jié)束后就立刻釋放計算資源。

動態(tài)調(diào)度：計算任務在運行的過程中，受計算資源的各類情況變化的影響，計算任務需要（重新）調(diào)度到其他計算資源，也即我們通常理解的業(yè)務遷移。常駐型的計算任務通常會遇到這樣的情況。

這里舉一個動態(tài)調(diào)度的案例——跨云邊端的高階自動駕駛汽車：

初始的時候，車輛由駕駛員駕駛。此刻，其他乘車人員，可以在車上玩游戲、看電影、聽音樂、刷短視頻等等。這些計算任務都運行在車輛終端本地。

當開啟自動駕駛時，本地算力不夠。游戲、電影、音樂、短視頻等計算任務，由于優(yōu)先級較低，統(tǒng)一調(diào)度到邊緣側(cè)甚至云側(cè)。而自動駕駛的計算任務，由于尺寸較大，通常也是由解構(gòu)的若干微服務組成。其中優(yōu)先級較高的少量微服務，運行在車輛終端本地；而優(yōu)先級較低的大部分微服務，也和游戲等其他計算任務一樣，運行在邊緣側(cè)甚至云側(cè)。

解除自動駕駛后，自動駕駛相關微服務（計算任務）退出，并且釋放本地和邊緣、云端的算力資源。而游戲等其他計算任務再從邊緣、云端，重新調(diào)度（遷移）到車輛終端本地。

3.2 問題二：任務的狀態(tài)

無狀態(tài)計算任務

如果是無狀態(tài)的計算任務，的確可以隨便調(diào)度。

但一個計算任務至少有兩個狀態(tài)，一個是計算任務的輸入，一個是計算任務的輸出。因此，任務調(diào)度會受輸入源和輸出目的的約束——不管調(diào)度到哪里，都需要能訪問源數(shù)據(jù)和寫入結(jié)果數(shù)據(jù)。

有狀態(tài)計算任務

如果是有狀態(tài)的計算任務，那么在運行的過程中，一方面是盡可能提高運行平臺的高可用性，盡量減少調(diào)度；另一方面則當不得不調(diào)度的時候，運行現(xiàn)場需要和計算任務一起調(diào)度。

3.3 任務間的關聯(lián)性

大任務拆分成小任務（巨服務微服務化），這些小任務間必然需要相互訪問。那么在調(diào)度的時候，就需要考慮這一層約束：凡是有關聯(lián)的計算任務，只能在一個集群（可網(wǎng)絡訪問）內(nèi)調(diào)度。如果是跨集群，或者跨數(shù)據(jù)中心和云邊端的計算任務，則需要考慮網(wǎng)絡打通、訪問延遲、訪問權限等方面的問題。事情遠不是理想化的算力調(diào)度那么簡單！

因此，算力調(diào)度，此刻應該有兩層：

第一層，是全局算力調(diào)度。為這個大任務，或者用戶的若干大任務分配一個獨立的計算集群，可以是跨數(shù)據(jù)中心、跨云邊端的算力資源所組成的“虛擬”的集群。

另一層，則是用戶在自己的集群內(nèi)部，進行業(yè)務層次的算力再調(diào)度。

3.4 任務的計算平臺要求

計算平臺由如下部分組成：

CPU處理器。CPU是圖靈完備的，可以自運行。

內(nèi)存。計算數(shù)據(jù)暫存和數(shù)據(jù)共享的區(qū)域。

存儲I/O。本地的存儲通過片間總線，如PCIe；遠程的存儲需要通過網(wǎng)絡。

網(wǎng)絡I/O。網(wǎng)絡主要用于外部通信。在集群計算和計算存儲分離的場景下，網(wǎng)絡的功能主主要是三個：

訪問內(nèi)網(wǎng)，東西向網(wǎng)絡，作為集群內(nèi)部不同節(jié)點間的網(wǎng)絡通信，目前主要是IB；

訪問遠程存儲，目前主要使用RoCEv2；

訪問外網(wǎng)，南北向網(wǎng)絡，作為集群外部的訪問端口，目前主要是Ethernet。

一個或多個加速處理器：

從整個架構(gòu)看，加速處理器是和CPU功能類似的計算部件。

其他加速處理器是非圖靈完備的，均需要組成CPU+xPU的異構(gòu)計算架構(gòu)。從CPU軟件視角看，加速處理器是跟網(wǎng)絡和存儲I/O類似的部件。

加速處理器，目前常用可以分為兩類：GPU，通用的并行計算加速平臺。DSA。領域?qū)Ｓ眉铀倨鳎珼SA是完全專用（ASIC）向通用可編程性的微調(diào)。

因此，計算任務，在不同計算平臺調(diào)度的時候，需要考慮平臺的差異性：

CPU架構(gòu)的差異性。CPU是x86、ARM還是其他架構(gòu)；

網(wǎng)絡和存儲接口是否一致；

加速處理器的類型和架構(gòu)是否一致。

目前，算力多樣性已經(jīng)成為困擾算力調(diào)度最大的問題。如何在多元異構(gòu)算力平臺上，實現(xiàn)統(tǒng)一調(diào)度，是目前算力中心發(fā)展要解決的重要問題之一。

4 宏觀視角：多租戶多系統(tǒng)的算力調(diào)度

計算的形態(tài)，從單機計算，走到了集群計算；并且，還在逐漸走進跨集群、跨數(shù)據(jù)中心、跨云邊端的協(xié)同計算，甚至融合計算。宏觀的看，一個計算系統(tǒng)，必然是數(shù)以萬計的租戶所擁有的數(shù)以百萬計的大計算任務（業(yè)務系統(tǒng)）共存。這里的每個大計算任務，又會拆分成數(shù)十個甚至上百個小計算任務（微服務）。也因此，宏觀的計算是：數(shù)以萬計租戶的數(shù)以億計的計算任務，并行不悖的交叉混合運行在數(shù)十個甚至上百個云算力中心、數(shù)以千計的邊緣數(shù)據(jù)中心，以及數(shù)以百萬計的終端計算節(jié)點上。 從算力的視角，全局存在一個統(tǒng)一的調(diào)度系統(tǒng)，所有的計算任務都是統(tǒng)一的調(diào)度的。調(diào)度系統(tǒng)能完全考慮并滿足所有計算任務的各種特性要求。 從業(yè)務的視角，調(diào)度通常是兩層：

業(yè)務從全局調(diào)度系統(tǒng)獲取自己的資源（第一層調(diào)度），組成自己的“虛擬”集群；

然后，業(yè)務的計算任務，在這“虛擬”集群里再進行調(diào)度。

全局調(diào)度為計算實例分配好資源之后，仍然可以動態(tài)調(diào)度（遷移），以保證計算實例的高可用。

業(yè)務從全局調(diào)度系統(tǒng)獲取資源也是動態(tài)的，可增加，可減少。

5 算力調(diào)度的分層

以容器和K8S容器管理為中心的云原生體系，越來越成熟，行業(yè)里出現(xiàn)了一個聲音：“是不是傳統(tǒng)IaaS虛擬化層就沒有存在的必要了？” 我們的觀點是：企業(yè)云場景，虛擬化的確沒有必要（企業(yè)云規(guī)模小，沒有必要那么復雜）；但超大規(guī)模多租戶的算力中心場景，IaaS層仍然非常有必要，也仍然非常有價值。 這樣，在硬件之上，業(yè)務之下，存在兩層抽象層：

第一層，資源抽象層。通過計算機虛擬化，對資源進行抽象和封裝，以及資源的池化和彈性切分。目前，業(yè)界一些先進的解決方案，可以通過DPU的加持，實現(xiàn)虛擬化的零損耗，以及裸機和虛擬機的統(tǒng)一，既有裸機的性能又有虛機的高可用和彈性。因此，裸機和虛擬主機的相關劣勢已經(jīng)“不復存在”。此外，通過虛擬化，可以實現(xiàn)接口的抽象統(tǒng)一，從而減少多元異構(gòu)算力帶來架構(gòu)/接口兼容性的問題。

第二層，算力調(diào)度層。容器化及云原生的核心優(yōu)勢，是以應用為中心：一次打包，到處運行。因此，通常是以容器為載體，以容器為基礎調(diào)度粒度，從而實現(xiàn)算力的高效調(diào)度。