深度學(xué)習(xí)的GPU共享工作

當(dāng)前機(jī)器學(xué)習(xí)訓(xùn)練中，使用GPU提供算力已經(jīng)非常普遍，對(duì)于GPU-based AI system的研究也如火如荼。在這些研究中，以提高資源利用率為主要目標(biāo)的GPU共享(GPU sharing)是當(dāng)下研究的熱點(diǎn)之一。 本篇文章希望能提供一個(gè)對(duì)GPU共享工作的分享，希望能和相關(guān)領(lǐng)域的研究者們共同討論。 GPU共享，是指在同一張GPU卡上同時(shí)運(yùn)行多個(gè)任務(wù)。優(yōu)勢(shì)在于：

（1）集群中可以運(yùn)行更多任務(wù)，減少搶占。
（2）資源利用率（GPU/顯存/e.t.c.）提高；GPU共享后，總利用率接近運(yùn)行任務(wù)利用率之和，減少了資源浪費(fèi)。
（3）可以增強(qiáng)公平性，因?yàn)槎鄠€(gè)任務(wù)可以同時(shí)開(kāi)始享受資源；也可以單獨(dú)保證某一個(gè)任務(wù)的QoS。
（4）減少任務(wù)排隊(duì)時(shí)間。
（5）總?cè)蝿?wù)結(jié)束時(shí)間下降；假設(shè)兩個(gè)任務(wù)結(jié)束時(shí)間分別是x,y，通過(guò)GPU共享，兩個(gè)任務(wù)全部結(jié)束的時(shí)間小于x+y。

想要實(shí)現(xiàn)GPU共享，需要完成的主要工作有：
（1）資源隔離，是指共享組件有能力限制任務(wù)占據(jù)算力（線程/SM）及顯存的比例，更進(jìn)一步地，可以限制總線帶寬。
（2）并行模式，主要指時(shí)間片模式和MPS模式。 資源隔離資源隔離是指共享組件有能力限制任務(wù)占據(jù)算力/顯存的比例。限制的方法就是劫持調(diào)用。圖一是在Nvidia GPU上，機(jī)器學(xué)習(xí)自上而下的視圖。由于Cuda和Driver不開(kāi)源，因此資源隔離層一般處在用戶態(tài)。 在內(nèi)核態(tài)做隔離的困難較大，但也有一些工作。順帶一提，Intel的Driver是開(kāi)源的，在driver層的共享和熱遷移方面有一些上海交大和Intel合作的工作。

圖一/使用Nvidia GPU機(jī)器學(xué)習(xí)自上而下視圖 來(lái)自騰訊的Gaia(ISPA'18)[1]共享層在Cuda driver API之上，它通過(guò)劫持對(duì)Cuda driver API的調(diào)用來(lái)做到資源隔離。劫持的調(diào)用如圖二所示。 具體實(shí)現(xiàn)方式也較為直接，在調(diào)用相應(yīng)API時(shí)檢查： （1）對(duì)于顯存，一旦該任務(wù)申請(qǐng)顯存后占用的顯存大小大于config中的設(shè)置，就報(bào)錯(cuò)。（2）對(duì)于計(jì)算資源，存在硬隔離和軟隔離兩種方式，共同點(diǎn)是當(dāng)任務(wù)使用的GPU SM利用率超出資源上限，則暫緩下發(fā)API調(diào)用。 不同點(diǎn)是如果有資源空閑，軟隔離允許任務(wù)超過(guò)設(shè)置，動(dòng)態(tài)計(jì)算資源上限。而硬隔離則不允許超出設(shè)置量。該項(xiàng)目代碼開(kāi)源在[2]。 實(shí)測(cè)即使只跑一個(gè)任務(wù)也會(huì)有較大JCT影響，可能是因?yàn)閷?duì)資源的限制及守護(hù)程序的資源占用問(wèn)題。KubeShare（HPDC '20）[3]的在資源隔離方面也是類(lèi)似的方案。

圖二/ Gaia限制的CUDA driver API 發(fā)了44篇論文（截止2020年3月）的rCuda[4]和Gaia有相似之處，他們都是在Cuda driver API之上，通過(guò)劫持調(diào)用來(lái)做資源隔離。 不同的是，rCuda除了資源隔離，最主要的目標(biāo)是支持池化。池化簡(jiǎn)單來(lái)講就是使用遠(yuǎn)程訪問(wèn)的形式使用GPU資源，任務(wù)使用本機(jī)的CPU和另一臺(tái)機(jī)器的GPU，兩者通過(guò)網(wǎng)絡(luò)進(jìn)行通信。也是因?yàn)檫@個(gè)原因，共享模塊需要將CPU和GPU的調(diào)用分開(kāi)。 然而正常情況下混合編譯的程序會(huì)插入一些沒(méi)有開(kāi)源的Cuda API，因此需要使用作者提供的cuda，分別編譯程序的CPU和GPU部分。 圖三顯示了rCuda的架構(gòu)。如果使用該產(chǎn)品，用戶需要重新編譯，對(duì)用戶有一定的影響。該項(xiàng)目代碼不開(kāi)源。 另外vCUDA（TC '12）[5]和qCUDA(CloudCom '19)[18]也采用了和rCuda相似的技術(shù)。

圖三/rCuda架構(gòu) GPUShare（IPDPSW' 16）[6]也是劫持的方式，但不同的是,它采用預(yù)測(cè)執(zhí)行時(shí)間的方式來(lái)實(shí)現(xiàn)計(jì)算資源的公平性。 作者認(rèn)為比切換周期還小的短kernel不會(huì)影響公平使用，因此只限制了較大的kernel。 來(lái)自阿里的cGPU[7]，其共享模塊在Nvidia driver層之上，也就是內(nèi)核態(tài)。由于是在公有云使用，相對(duì)于用戶態(tài)的共享會(huì)更加安全。 它也是通過(guò)劫持對(duì)driver的調(diào)用完成資源隔離的，通過(guò)設(shè)置任務(wù)占用時(shí)間片長(zhǎng)度來(lái)分配任務(wù)占用算力，但不清楚使用何種方式精準(zhǔn)地控制上下文切換的時(shí)間。 值得一提的是，由于Nvidia driver是不開(kāi)源的，因此需要一些逆向工程才可以獲得driver的相關(guān)method的name和ioctl參數(shù)的結(jié)構(gòu)。 該方案在使用上對(duì)用戶可以做到無(wú)感知，當(dāng)然JCT是有影響的。代碼沒(méi)有開(kāi)源，也沒(méi)有論文。圖四是cGPU的架構(gòu)圖。

圖四/cgpu架構(gòu)圖 來(lái)自Nvidia的vGPU[8]其共享模塊在Nvidia driver里面。vGPU通過(guò)vfio-mdev提供了一個(gè)隔離性非常高的的硬件環(huán)境，主要面向的是虛擬機(jī)產(chǎn)品，無(wú)法動(dòng)態(tài)調(diào)整資源比例。 來(lái)自Nvidia的產(chǎn)品當(dāng)然沒(méi)有開(kāi)源。圖五是vGPU的架構(gòu)圖。

圖五/vGPU架構(gòu)圖 Fractional GPU（RTAS' 19）[9]是一篇基于MPS的資源隔離方案。其共享模塊在Nvidia driver里面。該方案的隔離非常硬，核心就是綁定。 在計(jì)算隔離方面，它通過(guò)給任務(wù)綁定一定比例的可使用SM，就可以天然地實(shí)現(xiàn)計(jì)算隔離。MPS的計(jì)算隔離是通過(guò)限制任務(wù)的thread數(shù)，相較于Fractional GPU會(huì)限制地更加不準(zhǔn)確。 在顯存隔離方面，作者深入地研究Nvidia GPU內(nèi)存架構(gòu)（包括一些逆向工程）圖六是Fractional GPU通過(guò)逆向得到的Nvidia GPU GTX 970的存儲(chǔ)體系架構(gòu)。 通過(guò)頁(yè)面著色（Page Coloring）來(lái)完成顯存隔離。頁(yè)面著色的思想也是將特定的物理頁(yè)分配給GPU SM分區(qū)，以限制分區(qū)間互相搶占的問(wèn)題。 該隔離方案整體上來(lái)說(shuō)有一定損耗，而且只能使用規(guī)定好的資源比例，不能夠靈活地檢測(cè)和使用全部空閑資源。另外使用該方案需要修改用戶代碼。代碼開(kāi)源在[10]。

圖六/Fractional GPU通過(guò)逆向得到的Nvidia GPU GTX 970的存儲(chǔ)體系架構(gòu) Mig（ MULTI-INSTANCE GPU）[21]是今年A100機(jī)器支持的資源隔離方案，Nvidia在最底層硬件上對(duì)資源進(jìn)行了隔離，可以完全地做到計(jì)算/通信/配置/錯(cuò)誤的隔離。 它將SM和顯存均勻地分給GPU instance，最多支持將SM分7份（一份14個(gè)），顯存分8份（1份5GB）。順帶一提A100有SM108個(gè)，剩下的10個(gè)將無(wú)法用上。它可選的配置也是有限制的，如圖七所示。

圖七/Mig GPU Instance配置 并行模式并行模式指任務(wù)是以何種方式在同一個(gè)GPU上運(yùn)行的。目前有兩種方式：

（1）分時(shí)復(fù)用。指劃分時(shí)間片，讓不同的任務(wù)占據(jù)一個(gè)獨(dú)立的時(shí)間片，需要進(jìn)行上下文切換。在這種模式下，任務(wù)實(shí)際上是并發(fā)的，而不是并行的，因?yàn)橥粫r(shí)間只有一個(gè)任務(wù)在跑。

（2）合并共享。指將多個(gè)任務(wù)合并成一個(gè)上下文，因此可以同時(shí)跑多個(gè)任務(wù)，是真正意義上的并行。在生產(chǎn)環(huán)境中，更多使用分時(shí)復(fù)用的方式。 分時(shí)復(fù)用分時(shí)復(fù)用的模式大家都較為熟悉，CPU程序的時(shí)間片共享已經(jīng)非常常見(jiàn)和易用，但在GPU領(lǐng)域還有一些工作要做。 如果在Nvidia GPU上直接啟動(dòng)兩個(gè)任務(wù)，使用的就是時(shí)間片共享的方式。

但該模式存在多任務(wù)干擾問(wèn)題：即使兩個(gè)機(jī)器學(xué)習(xí)任務(wù)的GPU利用率和顯存利用率之和遠(yuǎn)小于1，單個(gè)任務(wù)的JCT也會(huì)高出很多。究其原因，是因?yàn)橛?jì)算碰撞，通信碰撞，以及GPU的上下文切換較慢。 計(jì)算碰撞很好理解，如果切換給另一個(gè)任務(wù)的時(shí)候，本任務(wù)正好在做CPU計(jì)算/IO/通信，而需要GPU計(jì)算時(shí)，時(shí)間片就切回給本任務(wù)，那么就不會(huì)有JCT的影響。但兩個(gè)任務(wù)往往同時(shí)需要使用GPU資源。 通信碰撞，是指任務(wù)同時(shí)需要使用顯存帶寬，在主機(jī)內(nèi)存和設(shè)備顯存之間傳輸數(shù)據(jù)。GPU上下文切換慢，是相對(duì)CPU而言的。 CPU上下文切換的速度是微秒級(jí)別，而GPU的切換在毫秒級(jí)別。在此處也會(huì)有一定的損耗。圖八是分時(shí)復(fù)用模式的常見(jiàn)架構(gòu)。

圖八/分時(shí)復(fù)用架構(gòu)圖 上文提到的Gaia，KubeShare，rCuda，vCuda，qCuda，cGPU，vGPU均為分時(shí)復(fù)用的模式。 由于上文所述的問(wèn)題，他們的單個(gè)任務(wù)完成時(shí)間（JCT）都會(huì)受到較大的影響。V100測(cè)試環(huán)境下，兩個(gè)任務(wù)同時(shí)運(yùn)行，其JCT是單個(gè)任務(wù)運(yùn)行時(shí)的1.4倍以上。 因此在生產(chǎn)環(huán)境下，我們需要考慮如何減少任務(wù)之間互相影響的問(wèn)題。上述方案都沒(méi)有考慮機(jī)器學(xué)習(xí)的特性，只要共享層接收到kernel下發(fā)，檢查沒(méi)有超過(guò)設(shè)置上限，就會(huì)繼續(xù)向下傳遞。 另外也限制任務(wù)顯存的使用不能超過(guò)設(shè)置上限，不具備彈性。因此針對(duì)特定的生產(chǎn)場(chǎng)景，有一些工作結(jié)合機(jī)器學(xué)習(xí)任務(wù)的特性，進(jìn)行了資源的限制及優(yōu)化。

服務(wù)質(zhì)量（QoS）保障在生產(chǎn)環(huán)境的GPU集群中常會(huì)有兩類(lèi)任務(wù)，代稱為高優(yōu)先級(jí)任務(wù)和低優(yōu)先級(jí)任務(wù)。高優(yōu)任務(wù)是時(shí)間敏感的，在它需要資源時(shí)需要立刻提供給它。 而低優(yōu)任務(wù)是時(shí)間不敏感的，當(dāng)集群有資源沒(méi)被使用時(shí)，就可以安排它填充資源縫隙以提高集群利用率。因此共享模塊需要優(yōu)先保障高優(yōu)先級(jí)任務(wù)的JCT不受影響，以限制低優(yōu)任務(wù)資源占用的方式。 Baymax（ASPLOS '16）[11]通過(guò)任務(wù)重排序保障了高優(yōu)任務(wù)的QoS。Baymax作者認(rèn)為多任務(wù)之間的性能干擾通常是由排隊(duì)延遲和PCI-e帶寬爭(zhēng)用引起的。 也就是說(shuō)，當(dāng)高優(yōu)任務(wù)需要計(jì)算或IO通信時(shí)，如果有低優(yōu)的任務(wù)排在它前面，高優(yōu)任務(wù)就需要等待，因此QoS無(wú)法保障。針對(duì)這兩點(diǎn)Baymax分別做了一些限制：

（1）在排隊(duì)延遲方面，Baymax利用KNN/LR模型來(lái)預(yù)測(cè)持續(xù)時(shí)間。然后Baymax對(duì)發(fā)給GPU的請(qǐng)求進(jìn)行重新排序。 簡(jiǎn)單來(lái)說(shuō)，就是共享模塊預(yù)測(cè)了每個(gè)請(qǐng)求的執(zhí)行時(shí)間，當(dāng)它認(rèn)為發(fā)下去的請(qǐng)求GPU還沒(méi)執(zhí)行完時(shí)，新下發(fā)的請(qǐng)求就先進(jìn)入隊(duì)列里。 同時(shí)將位于隊(duì)列中的任務(wù)重排序，當(dāng)需要下發(fā)請(qǐng)求時(shí)，先下發(fā)隊(duì)列中的高優(yōu)任務(wù)請(qǐng)求。

（2）在PCI-e帶寬爭(zhēng)用方面，Baymax限制了并發(fā)數(shù)據(jù)傳輸任務(wù)的數(shù)量。Baymax作者在第二年發(fā)表了Prophet（ASPLOS '17）[12]，用于預(yù)測(cè)多任務(wù)共置時(shí)QoS的影響程度。 在論文最后提到的實(shí)驗(yàn)中，表示如果預(yù)測(cè)到多個(gè)任務(wù)不會(huì)影響QoS，就將其共置，但此處共置使用的是MPS，也就是沒(méi)有使用分時(shí)復(fù)用的模式了。 在該研究中，預(yù)測(cè)是核心。預(yù)測(cè)準(zhǔn)確性是否能適應(yīng)復(fù)雜的生產(chǎn)環(huán)境，預(yù)測(cè)的機(jī)器負(fù)載是否較大，還暫不清楚。 來(lái)自阿里的AntMan（OSDI '20）[13]也認(rèn)為排隊(duì)延遲和帶寬爭(zhēng)用是干擾的原因，不同的是，它從DL模型的特點(diǎn)切入，來(lái)區(qū)分切換的時(shí)機(jī)。

在算力限制方面，AntMan通過(guò)限制低優(yōu)任務(wù)的kernel launch保證了高優(yōu)任務(wù)的QoS。圖九是AntMan算力共享機(jī)制的對(duì)比。 AntMan算力調(diào)度最小單元，在論文中描述似乎有些模糊，應(yīng)該是Op（Operator），AntMan“會(huì)持續(xù)分析GPU運(yùn)算符的執(zhí)行時(shí)間“，并在空隙時(shí)插入另一個(gè)任務(wù)的Op。 但如何持續(xù)分析，論文中并沒(méi)有詳細(xì)描述。在顯存隔離方面，AntMan沒(méi)有限制顯存的大小，而是盡力讓兩個(gè)任務(wù)都能運(yùn)行在機(jī)器上。但兩個(gè)或多個(gè)任務(wù)的顯存申請(qǐng)量可能會(huì)造成顯存溢出，因此AntMan做了很多顯存方面的工作。 首先需要了解任務(wù)在顯存中保存的內(nèi)容：首先是模型，該數(shù)據(jù)是大小穩(wěn)定的，當(dāng)它在顯存中時(shí)，iteration才可以開(kāi)始計(jì)算。

論文中表示90%的任務(wù)模型使用500mb以內(nèi)的顯存。其次是iteration開(kāi)始時(shí)申請(qǐng)的臨時(shí)顯存，這部分顯存理論上來(lái)說(shuō)，在iteration結(jié)束后就會(huì)釋放。 但使用的機(jī)器學(xué)習(xí)框架有緩存機(jī)制，申請(qǐng)的顯存不會(huì)退回，該特性保障了速度，但犧牲了共享的可能性。 因此AntMan做了一些顯存方面最核心的機(jī)制是，當(dāng)顯存放不下時(shí)，就轉(zhuǎn)到內(nèi)存上。在此處論文還做了很多工作，不再盡述。 論文描述稱AntMan可以規(guī)避總線帶寬爭(zhēng)用問(wèn)題，但似乎從機(jī)制上來(lái)說(shuō)無(wú)法避免。 除此之外，按照Op為粒度進(jìn)行算力隔離是否會(huì)需要大量調(diào)度負(fù)載也是一個(gè)疑問(wèn)，另外Op執(zhí)行時(shí)間的差異性較大，尤其是開(kāi)啟XLA之后，這也可能帶來(lái)一些不確定性。該方案需要修改機(jī)器學(xué)習(xí)框架（Tensorflow和Pytorch），對(duì)用戶有一定的影響。 代碼開(kāi)源在[20]，目前還是WIP項(xiàng)目（截止2020/11/18），核心部分（local-coordinator）還沒(méi)能開(kāi)源。

圖九/AntMan算力共享機(jī)制的對(duì)比 如果最小調(diào)度單元是iteration，則會(huì)更加簡(jiǎn)單。首先需要了解一下DL訓(xùn)練的特征：訓(xùn)練時(shí)的最小迭代是一個(gè)iteration，分為四個(gè)過(guò)程： IO，進(jìn)行數(shù)據(jù)讀取存儲(chǔ)以及一些臨時(shí)變量的申請(qǐng)等；前向，在此過(guò)程中會(huì)有密集的GPU kernel。NLP任務(wù)在此處也會(huì)有CPU負(fù)載。后向，計(jì)算梯度更新，需要下發(fā)GPU kernel；更新，如果非一機(jī)一卡的任務(wù)，會(huì)有通信的過(guò)程。之后更新合并后的梯度，需要一小段GPU時(shí)間。 可以看出前向后向和通信之后的更新過(guò)程，是需要使用GPU的，通信和IO不需要。

因此可以在此處插入一些來(lái)自其他任務(wù)的kernel，同時(shí)還可以保證被插入任務(wù)的QoS。更簡(jiǎn)單的方式是，通過(guò)在iteration前后插入另一個(gè)任務(wù)的iteration來(lái)完成共享。 當(dāng)然這樣就無(wú)法考慮通信的空隙，可以被理解是一種tradeoff。另外也因?yàn)閕teration是最小調(diào)度單元，避免了計(jì)算資源和顯存帶寬爭(zhēng)用問(wèn)題。 另外，如果不考慮高優(yōu)任務(wù)，實(shí)現(xiàn)一個(gè)退化版本，貪心地放置iteration而不加以限制?？梢愿?jiǎn)單地提高集群利用率，也可以讓任務(wù)的JCT/排隊(duì)時(shí)間減小。 針對(duì)推理的上下文切換在上文中描述了分時(shí)復(fù)用的三個(gè)問(wèn)題，其中上下文切換是一個(gè)耗時(shí)點(diǎn)。

來(lái)自字節(jié)跳動(dòng)的PipeSwitch（OSDI '20）[14]針對(duì)推理場(chǎng)景的上下文切換進(jìn)行了優(yōu)化。具體生產(chǎn)場(chǎng)景是這樣的：訓(xùn)練推理任務(wù)共享一張卡，大多數(shù)時(shí)候訓(xùn)練使用資源。當(dāng)推理請(qǐng)求下發(fā)，上下文需要立刻切換到推理任務(wù)。 如果模型數(shù)據(jù)已經(jīng)在顯存中，切換會(huì)很快，但生產(chǎn)環(huán)境中模型一般較大，訓(xùn)練和推理的模型不能同時(shí)加載到顯存中，當(dāng)切換到推理時(shí)，需要先傳輸整個(gè)模型，因此速度較慢。

在該場(chǎng)景下，GPU上下文切換的開(kāi)銷(xiāo)有： （1）任務(wù)清理，指釋放顯存。（2）任務(wù)初始化，指啟動(dòng)進(jìn)程，初始化Cuda context等。（3）Malloc。（4）模型傳輸，從內(nèi)存?zhèn)鞯斤@存。

在模型傳輸方面，PipeSwitch作者觀察到，和訓(xùn)練不同的是推理只有前向過(guò)程，因此只需要知道上一層的輸出及本層的參數(shù)就可以開(kāi)始計(jì)算本層。 目前的加載方式是，將模型數(shù)據(jù)全部加載到顯存后，才會(huì)開(kāi)始進(jìn)行計(jì)算，但實(shí)際上如果對(duì)IO和計(jì)算做pipeline，只加載一層就開(kāi)始計(jì)算該層，就會(huì)加快整體速度。當(dāng)然直接使用層為最小粒度可能會(huì)帶來(lái)較大開(kāi)銷(xiāo)，因此進(jìn)行了grouping合并操作。 圖十顯示了pipeline的對(duì)比。在任務(wù)清理和初始化方面，設(shè)置了一些常駐進(jìn)程來(lái)避免開(kāi)銷(xiāo)。最后在Malloc方面也使用了統(tǒng)一的內(nèi)存管理來(lái)降低開(kāi)銷(xiāo)。 可以說(shuō)做的非常全面。由于需要獲知層級(jí)結(jié)構(gòu)，因此需要對(duì)Pytorch框架進(jìn)行修改，對(duì)用戶有一定影響。代碼開(kāi)源在[19].

圖十/PipeSwitch pipeline的對(duì)比 合并共享合并共享是指，多個(gè)任務(wù)合并成一個(gè)上下文，因此可以共享GPU資源，同時(shí)發(fā)送kernel到GPU上，也共同使用顯存。最具有代表性的是Nvidia的MPS[15]。 該模式的好處是顯而易見(jiàn)的，當(dāng)任務(wù)使用的資源可以同時(shí)被滿足時(shí)，其JCT就基本沒(méi)有影響，性能可以說(shuō)是最好的?？梢猿浞掷肎PU資源。 但壞處也是致命的：錯(cuò)誤會(huì)互相影響，如果一個(gè)任務(wù)錯(cuò)誤退出（包括被kill），如果該任務(wù)正在執(zhí)行kernel，那么和該任務(wù)共同share IPC和UVM的任務(wù)也會(huì)一同出錯(cuò)退出。 目前還沒(méi)有工作能夠解決這一問(wèn)題，Nvidia官方也推薦使用MPS的任務(wù)需要能夠接受錯(cuò)誤影響，比如MPI程序。 因此無(wú)法在生產(chǎn)場(chǎng)景上大規(guī)模使用。另外，有報(bào)告稱其不能支持所有DL框架的所有版本。 在資源隔離方面，MPS沒(méi)有顯存隔離，可以通過(guò)限制同時(shí)下發(fā)的thread數(shù)粗略地限制計(jì)算資源。它位于Nvidia Driver之上。圖十一是MPS的架構(gòu)圖。

圖十一/MPS架構(gòu)圖 Salus（MLSys '20）[16]也采取了合并共享的方式，作者通過(guò)Adaptor將GPU請(qǐng)求合并到同一個(gè)context下，去掉了上下文切換。 當(dāng)然，和MPS一樣會(huì)發(fā)生錯(cuò)誤傳播，論文中也沒(méi)有要解決這一問(wèn)題，因此無(wú)法在生產(chǎn)環(huán)境中使用。 但筆者認(rèn)為這篇論文中更大的價(jià)值在顯存和調(diào)度方面，它的很多見(jiàn)解在AntMan和PipeSwitch中也有體現(xiàn)。調(diào)度方面，以iteration為最小粒度，并且詮釋了原因：使用kernel為粒度，可以進(jìn)一步利用資源，但會(huì)增加調(diào)度服務(wù)的開(kāi)銷(xiāo)。 因此折中選擇了iteration，可以實(shí)現(xiàn)性能最大化。

顯存方面，一些觀察和AntMan是一致的：顯存變化具有周期性；永久性顯存（模型）較小，只要模型在顯存中就可以開(kāi)始計(jì)算；臨時(shí)性顯存在iteration結(jié)束后就應(yīng)該釋放。 也描述了機(jī)器學(xué)習(xí)框架緩存機(jī)制的死鎖問(wèn)題。不過(guò)Salus實(shí)現(xiàn)上需要兩個(gè)任務(wù)所需的顯存都放到GPU顯存里，沒(méi)有置換的操作。 論文中也提到了推理場(chǎng)景下的切換問(wèn)題：切換后理論上模型傳輸時(shí)間比推理延遲本身長(zhǎng)幾倍。 除此之外論文中也有一些其他的觀察點(diǎn)，值得一看。圖十二展示了Salus架構(gòu)。該項(xiàng)目代碼開(kāi)源在[17]。Salus也需要修改DL框架。作者也開(kāi)源了修改后的tensorflow代碼。

圖十二/Salus架構(gòu)圖 如果在合并共享模塊之上做分時(shí)復(fù)用，應(yīng)可以繞過(guò)硬件的限制，精準(zhǔn)地控制時(shí)間片和切換的時(shí)機(jī)，也可以去除上下文切換的開(kāi)銷(xiāo)。但在這種情況下是否還會(huì)有錯(cuò)誤影響，還需要進(jìn)一步驗(yàn)證。 場(chǎng)景展望目前GPU共享已經(jīng)逐漸開(kāi)始進(jìn)入工業(yè)落地的階段了，若需要更好地滿足用戶對(duì)使用場(chǎng)景的期待，除了更高的性能，筆者認(rèn)為以下幾點(diǎn)也需要注意。 1、能夠提供穩(wěn)定的服務(wù)，運(yùn)維便捷。比如MPS的錯(cuò)誤影響是不能被接受的，另外對(duì)于帶有預(yù)測(cè)的實(shí)現(xiàn)，也需要更高的穩(wěn)定性。共享工作負(fù)載盡量降低。 2、更低的JCT時(shí)延，最好具有保障部分任務(wù)QoS的能力。對(duì)于一個(gè)已有的GPU集群進(jìn)行改造時(shí)，需要盡量減少對(duì)已有的用戶和任務(wù)的影響。 3、不打擾用戶，盡量不對(duì)用戶的代碼和框架等做修改，另外也需要考慮框架和其他庫(kù)的更新問(wèn)題。 參考資料：

[1]J. Gu, S. Song, Y. Li and H. Luo, "GaiaGPU: Sharing GPUs in Container Clouds," 2018 IEEE Intl Conf on Parallel & Distributed Processing with Applications, Ubiquitous Computing & Communications, Big Data & Cloud Computing, Social Computing & Networking, Sustainable Computing & Communications (ISPA/IUCC/BDCloud/SocialCom/SustainCom), Melbourne, Australia, 2018, pp. 469-476, doi: 10.1109/BDCloud.2018.00077.

[2]github.com/tkestack/vcu

[3]Ting-An Yeh, Hung-Hsin Chen, and Jerry Chou. 2020. KubeShare: A Framework to Manage GPUs as First-Class and Shared Resources in Container Cloud. In Proceedings of the 29th International Symposium on High-Performance Parallel and Distributed Computing (HPDC '20). Association for Computing Machinery, New York, NY, USA, 173–184. DOI:doi.org/10.1145/3369583

[4]José Duato, Francisco D. Igual, Rafael Mayo, Antonio J. Pe?a, Enrique S. Quintana-Ortí, and Federico Silla. An efficient implementation of GPU virtualization in high performance clusters. In Euro-Par 2009, Parallel Processing - Workshops, volume 6043 of Lecture Notes in Computer Science, pages 385-394. Springer-Verlag, 2010.

[5]L. Shi, H. Chen, J. Sun and K. Li, "vCUDA: GPU-Accelerated High-Performance Computing in Virtual Machines," in IEEE Transactions on Computers, vol. 61, no. 6, pp. 804-816, June 2012, doi: 10.1109/TC.2011.112.

[6]A. Goswami et al., "GPUShare: Fair-Sharing Middleware for GPU Clouds," 2016 IEEE International Parallel and Distributed Processing Symposium Workshops (IPDPSW), Chicago, IL, 2016, pp. 1769-1776, doi: 10.1109/IPDPSW.2016.94.

[7]alibabacloud.com/help/z

[8]docs.nvidia.com/grid/10

[9]S. Jain, I. Baek, S. Wang and R. Rajkumar, "Fractional GPUs: Software-Based Compute and Memory Bandwidth Reservation for GPUs," 2019 IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS), Montreal, QC, Canada, 2019, pp. 29-41, doi: 10.1109/RTAS.2019.00011.

[10]github.com/sakjain92/Fr

[11]Quan Chen, Hailong Yang, Jason Mars, and Lingjia Tang. 2016. Baymax: QoS Awareness and Increased Utilization for Non-Preemptive Accelerators in Warehouse Scale Computers. In Proceedings of the Twenty-First International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS '16). Association for Computing Machinery, New York, NY, USA, 681–696. DOI:doi.org/10.1145/2872362

[12]Quan Chen, Hailong Yang, Minyi Guo, Ram Srivatsa Kannan, Jason Mars, and Lingjia Tang. 2017. Prophet: Precise QoS Prediction on Non-Preemptive Accelerators to Improve Utilization in Warehouse-Scale Computers. In Proceedings of the Twenty-Second International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS '17). Association for Computing Machinery, New York, NY, USA, 17–32. DOI:doi.org/10.1145/3037697

[13]Xiao, Wencong, et al. "AntMan: Dynamic Scaling on {GPU} Clusters for Deep Learning." 14th {USENIX} Symposium on Operating Systems Design and Implementation ({OSDI} 20). 2020.

[14]Bai, Zhihao, et al. "PipeSwitch: Fast Pipelined Context Switching for Deep Learning Applications." 14th {USENIX} Symposium on Operating Systems Design and Implementation ({OSDI} 20). 2020.

[15]docs.nvidia.com/deploy/

[16]Yu, Peifeng, and Mosharaf Chowdhury. "Salus: Fine-grained gpu sharing primitives for deep learning applications." arXiv preprint arXiv:1902.04610 (2019).

[17]github.com/SymbioticLab

[18]Y. Lin, C. Lin, C. Lee and Y. Chung, "qCUDA: GPGPU Virtualization for High Bandwidth Efficiency," 2019 IEEE International Conference on Cloud Computing Technology and Science (CloudCom), Sydney, Australia, 2019, pp. 95-102, doi: 10.1109/CloudCom.2019.00025.

[19]netx-repo/PipeSwitch

[20]alibaba/GPU-scheduler-for-deep-learning

[21]NVIDIA Multi-Instance GPU User Guide

責(zé)任編輯：xj

原文標(biāo)題：深度剖析：針對(duì)深度學(xué)習(xí)的GPU共享

文章出處：【微信公眾號(hào)：新機(jī)器視覺(jué)】歡迎添加關(guān)注！文章轉(zhuǎn)載請(qǐng)注明出處。