張凱，車漾

阿里巴巴科技（北京）有限公司，北京 100102

1 引言

最近10年，深度學(xué)習(xí)技術(shù)和應(yīng)用發(fā)展風(fēng)起云涌，百花齊放。尤其在機(jī)器視覺(jué)、自然語(yǔ)言理解、語(yǔ)音識(shí)別等領(lǐng)域，一大批成熟的人工智能模型和服務(wù)正落地應(yīng)用于各行各業(yè)。越來(lái)越多的行業(yè)發(fā)掘出大量需求，需要利用企業(yè)日積月累的海量業(yè)務(wù)數(shù)據(jù)，高效便捷地訓(xùn)練深度學(xué)習(xí)和機(jī)器學(xué)習(xí)模型。

與此同時(shí)，云計(jì)算在IaaS、PaaS和SaaS等層次已經(jīng)發(fā)展得相當(dāng)成熟，并逐步進(jìn)入云原生時(shí)代。在云原生技術(shù)體系中，以Docker為代表的Linux容器技術(shù)和以Kubernetes為代表的容器編排管理技術(shù)在應(yīng)用開(kāi)發(fā)、交付、運(yùn)維的生命周期中逐漸成為業(yè)界的事實(shí)標(biāo)準(zhǔn)。同時(shí)，應(yīng)用微服務(wù)架構(gòu)的自動(dòng)化部署，運(yùn)行時(shí)動(dòng)態(tài)彈性伸縮，完善的日志、監(jiān)控、告警等運(yùn)維體系等，都成為現(xiàn)代軟件開(kāi)發(fā)運(yùn)維的基礎(chǔ)需求。

深度學(xué)習(xí)和人工智能應(yīng)用往往需要使用大量GPU、張量處理器（tensor processing unit，TPU），甚至神經(jīng)元處理器（neural processing unit，NPU）這類定制的高性能異構(gòu)計(jì)算設(shè)備來(lái)迭代處理海量的訓(xùn)練數(shù)據(jù)，最終得到滿足準(zhǔn)確率和性能要求的模型。由于數(shù)據(jù)規(guī)模較大、模型復(fù)雜度較高，訓(xùn)練過(guò)程一般較漫長(zhǎng)。因此，優(yōu)化GPU等異構(gòu)計(jì)算設(shè)備的利用效率、加快訓(xùn)練數(shù)據(jù)處理速度，成為提升深度學(xué)習(xí)和人工智能應(yīng)用生產(chǎn)率和成本優(yōu)化的關(guān)鍵因素。

Kubernetes容器編排管理技術(shù)對(duì)于GPU、TPU、NPU等高性能異構(gòu)計(jì)算設(shè)備資源的支持日趨成熟?？紤]到云計(jì)算在成本優(yōu)化、資源規(guī)模和彈性伸縮方面的優(yōu)勢(shì)，配合Docker容器技術(shù)擅長(zhǎng)的輕量級(jí)和標(biāo)準(zhǔn)化應(yīng)用交付能力，業(yè)界主流的生產(chǎn)人工智能模型和應(yīng)用的技術(shù)方案會(huì)采用容器集群結(jié)合云計(jì)算平臺(tái)的GPU資源的架構(gòu)，進(jìn)行分布式深度學(xué)習(xí)模型訓(xùn)練。

在“云上”執(zhí)行訓(xùn)練任務(wù)，通常會(huì)在帶有GPU設(shè)備的計(jì)算服務(wù)節(jié)點(diǎn)上進(jìn)行。訓(xùn)練數(shù)據(jù)會(huì)被存放在各種異構(gòu)的云存儲(chǔ)服務(wù)中，如對(duì)象存儲(chǔ)服務(wù)、遠(yuǎn)程文件系統(tǒng)服務(wù)等。這種典型的計(jì)算和存儲(chǔ)分離的分布式計(jì)算架構(gòu)有利于增強(qiáng)計(jì)算和存儲(chǔ)的彈性擴(kuò)展能力，但同時(shí)也會(huì)帶來(lái)數(shù)據(jù)訪問(wèn)時(shí)延增大的問(wèn)題。如果考慮數(shù)據(jù)敏感性、隱私保護(hù)和安全合規(guī)的要求，訓(xùn)練數(shù)據(jù)通常也會(huì)被存放在私有數(shù)據(jù)中心中。這樣勢(shì)必要求深度學(xué)習(xí)模型訓(xùn)練平臺(tái)采用混合云的架構(gòu)，統(tǒng)一使用“云上”計(jì)算資源來(lái)訪問(wèn)“云下”數(shù)據(jù)。而這種“本地存儲(chǔ)+云上計(jì)算”的訓(xùn)練模式進(jìn)一步增大了計(jì)算和存儲(chǔ)分離架構(gòu)帶來(lái)的遠(yuǎn)程數(shù)據(jù)訪問(wèn)時(shí)延，進(jìn)而導(dǎo)致深度學(xué)習(xí)模型訓(xùn)練整體性能的顯著下降。

本文首先概述深度學(xué)習(xí)訓(xùn)練系統(tǒng)中典型的數(shù)據(jù)訪問(wèn)方法；然后提出基于容器和分布式緩存技術(shù)的深度學(xué)習(xí)訓(xùn)練系統(tǒng)架構(gòu)，以及訓(xùn)練任務(wù)與緩存數(shù)據(jù)互感知的協(xié)同調(diào)度方法TDCS（task and data co-located scheduling）；之后介紹使用Alluxio加速訓(xùn)練的實(shí)驗(yàn)結(jié)果和性能瓶頸，并針對(duì)Alluxio進(jìn)行參數(shù)調(diào)優(yōu)，獲得了初步性能提升；筆者還提出TDCS任務(wù)與數(shù)據(jù)協(xié)同調(diào)度方法，并給出TDCS的具體策略設(shè)計(jì)和實(shí)現(xiàn)細(xì)節(jié)；最后提供多組實(shí)驗(yàn)數(shù)據(jù)驗(yàn)證TDCS的效果，實(shí)驗(yàn)表明TDCS有效增強(qiáng)了容器環(huán)境下分布式緩存系統(tǒng)的可擴(kuò)展性，可以顯著加速深度學(xué)習(xí)訓(xùn)練。

2 訪問(wèn)訓(xùn)練數(shù)據(jù)的典型方法

為了規(guī)避計(jì)算和存儲(chǔ)分離架構(gòu)帶來(lái)的數(shù)據(jù)訪問(wèn)時(shí)延，典型做法是在開(kāi)始模型訓(xùn)練之前，將訓(xùn)練數(shù)據(jù)復(fù)制到GPU計(jì)算節(jié)點(diǎn)本地的磁盤存儲(chǔ)中，如普通機(jī)械硬盤或者NVMe SSD等高速存儲(chǔ)設(shè)備；或者將數(shù)據(jù)提前復(fù)制到部署在計(jì)算節(jié)點(diǎn)上的分布式存儲(chǔ)系統(tǒng)中，如Ceph、GlusterFS。隨后計(jì)算任務(wù)就相當(dāng)于從本地讀取訓(xùn)練數(shù)據(jù)，有效緩解了數(shù)據(jù)訪問(wèn)時(shí)延對(duì)GPU計(jì)算性能的影響。然而，這種額外的數(shù)據(jù)遷移過(guò)程會(huì)面臨如下問(wèn)題。

● 把訓(xùn)練數(shù)據(jù)復(fù)制到GPU節(jié)點(diǎn)的方式低效且難以管理。如果是手動(dòng)復(fù)制，非常容易出錯(cuò)。

● 深度學(xué)習(xí)訓(xùn)練數(shù)量很大，且可能持續(xù)增加?！霸粕稀盙PU計(jì)算節(jié)點(diǎn)配置的磁盤容量有限，經(jīng)常出現(xiàn)無(wú)法存放全量訓(xùn)練數(shù)據(jù)的情況。

● 將訓(xùn)練數(shù)據(jù)存放在多個(gè)GPU計(jì)算節(jié)點(diǎn)上的分布式存儲(chǔ)系統(tǒng)內(nèi)，可以解決數(shù)據(jù)容量問(wèn)題，但分布式存儲(chǔ)系統(tǒng)自身的運(yùn)維成本和難度都很大；并且，存儲(chǔ)系統(tǒng)與計(jì)算節(jié)點(diǎn)耦合，本身也會(huì)產(chǎn)生計(jì)算、網(wǎng)絡(luò)、I/O等本地資源的爭(zhēng)搶和干擾問(wèn)題。

3 基于分布式緩存的容器化深度學(xué)習(xí)模型訓(xùn)練系統(tǒng)

業(yè)界已經(jīng)有一些工作通過(guò)基于緩存機(jī)制的方法[1-3]來(lái)解決上述復(fù)制訓(xùn)練數(shù)據(jù)到計(jì)算節(jié)點(diǎn)方案存在的問(wèn)題。與這些工作不同，本文設(shè)計(jì)并實(shí)現(xiàn)了一種Kubernetes容器編排技術(shù)和分布式緩存技術(shù)相結(jié)合的深度學(xué)習(xí)模型訓(xùn)練系統(tǒng)。該系統(tǒng)架構(gòu)可以滿足云計(jì)算環(huán)境下大規(guī)模容器化深度學(xué)習(xí)系統(tǒng)對(duì)訓(xùn)練任務(wù)的加速要求。該系統(tǒng)的基礎(chǔ)架構(gòu)如圖1所示。

圖1 基于容器和分布式緩存的深度學(xué)習(xí)模型訓(xùn)練系統(tǒng)的基礎(chǔ)架構(gòu)

基于容器和分布式緩存的深度學(xué)習(xí)模型訓(xùn)練系統(tǒng)架構(gòu)的核心模塊包括如下幾個(gè)。

● Kubernetes。Kubernetes是業(yè)界非常主流的容器集群管理和編排引擎。其系統(tǒng)架構(gòu)和API已經(jīng)成為容器平臺(tái)的事實(shí)標(biāo)準(zhǔn)。Kubernetes非常廣泛地用于構(gòu)建深度學(xué)習(xí)訓(xùn)練平臺(tái)。它提供了通過(guò)容器兼容不同深度學(xué)習(xí)計(jì)算框架的靈活性，動(dòng)態(tài)調(diào)度訓(xùn)練任務(wù)和按需擴(kuò)展GPU資源的能力，以及完善的集群管理能力。Kubernetes中最重要的子模塊是Kube-scheduler。該子模塊負(fù)責(zé)在Kubernetes容器集群中統(tǒng)一調(diào)度深度學(xué)習(xí)訓(xùn)練任務(wù)和分布式緩存系統(tǒng)。本文通過(guò)擴(kuò)展Kube-scheduler，實(shí)現(xiàn)了TDCS方法。

● Kubeflow。Kubeflow是Kubernetes技術(shù)生態(tài)中最流行的支持機(jī)器學(xué)習(xí)和深度學(xué)習(xí)任務(wù)的開(kāi)源項(xiàng)目。Kubeflow的目標(biāo)是使機(jī)器學(xué)習(xí)、深度學(xué)習(xí)的完整工作流程在Kubernetes集群上能夠簡(jiǎn)便地部署、高效地運(yùn)行，并且使整個(gè)工作流可移植和可擴(kuò)展。Kubeflow為主流的深度學(xué)習(xí)框架TensorFlow[4-5]的分布式訓(xùn)練提供了兩種支持模式，分別是參數(shù)服務(wù)器模式和Ring Allreduce[6]模式。Kubeflow同時(shí)支持訓(xùn)練任務(wù)使用CPU和GPU運(yùn)行。

● 分布式緩存系統(tǒng)。分布式緩存系統(tǒng)設(shè)計(jì)的初衷是解決大數(shù)據(jù)處理流水線中，不同計(jì)算框架在通過(guò)磁盤文件系統(tǒng)（如HDFS）交換數(shù)據(jù)時(shí)，系統(tǒng)I/O操作方面的瓶頸[7]。業(yè)界已存在一些用于實(shí)現(xiàn)分布式緩存系統(tǒng)的技術(shù)。本文設(shè)計(jì)的深度學(xué)習(xí)訓(xùn)練系統(tǒng)選擇使用Alluxio作為分布式緩存技術(shù)的具體實(shí)現(xiàn)。Alluxio是面向混合云環(huán)境的開(kāi)源數(shù)據(jù)編排與緩存系統(tǒng)[8]。它利用多個(gè)計(jì)算節(jié)點(diǎn)本地的內(nèi)存和磁盤資源構(gòu)成統(tǒng)一的分布式緩存系統(tǒng)，從而為計(jì)算任務(wù)提供就近、可重用的數(shù)據(jù)訪問(wèn)服務(wù)。

為了提升深度學(xué)習(xí)的訓(xùn)練性能，本文先對(duì)Alluxio進(jìn)行系統(tǒng)參數(shù)調(diào)優(yōu)，獲得初步的訓(xùn)練加速效果。為了繼續(xù)將緩存加速效果擴(kuò)展到更大規(guī)模的訓(xùn)練場(chǎng)景，本文結(jié)合Kubernetes容器集群的調(diào)度和彈性伸縮能力、Alluxio緩存引擎的部署和運(yùn)行機(jī)制，提出了一種訓(xùn)練任務(wù)與緩存數(shù)據(jù)互感知的協(xié)同調(diào)度方法TDCS，并在容器化深度學(xué)習(xí)系統(tǒng)中進(jìn)行實(shí)現(xiàn)。

TDCS通過(guò)多層資源分配策略來(lái)感知任務(wù)與數(shù)據(jù)間的關(guān)聯(lián)性，從而實(shí)現(xiàn)訓(xùn)練任務(wù)和緩存數(shù)據(jù)的雙向親和性調(diào)度。通過(guò)感知任務(wù)運(yùn)行時(shí)拓?fù)?，?shí)現(xiàn)彈性伸縮緩存容量和數(shù)據(jù)分布策略。在經(jīng)典的圖像分類模型訓(xùn)練實(shí)驗(yàn)中，TDCS可以實(shí)現(xiàn)2~3倍的訓(xùn)練加速，并且隨著計(jì)算資源的增加，TDCS能夠持續(xù)加速訓(xùn)練任務(wù)。本文對(duì)使用128塊GPU卡的訓(xùn)練任務(wù)進(jìn)行實(shí)驗(yàn)，發(fā)現(xiàn)TDCS依然帶來(lái)了可觀的性能提升。

4 初步優(yōu)化分布式緩存加速訓(xùn)練

使用分布式緩存加速諸如深度學(xué)習(xí)的大規(guī)模數(shù)據(jù)處理任務(wù)，在獲得性能提升的同時(shí)，會(huì)產(chǎn)生其他方面的問(wèn)題，如整體成本的上升[9]、加速效果的波動(dòng)等。本文實(shí)現(xiàn)了基于Kubernetes容器編排技術(shù)和Alluxio分布式緩存技術(shù)的深度學(xué)習(xí)訓(xùn)練系統(tǒng)。實(shí)驗(yàn)發(fā)現(xiàn)，Alluxio分布式緩存可以在一定條件下加速訓(xùn)練任務(wù)。但在擴(kuò)大任務(wù)規(guī)模、增加參與計(jì)算的GPU資源后，緩存加速效果很快達(dá)到瓶頸，無(wú)法隨資源量的增加而持續(xù)提升。如果要實(shí)現(xiàn)資源量和訓(xùn)練任務(wù)性能的線性加速，則需要對(duì)緩存系統(tǒng)進(jìn)行優(yōu)化。

下面首先介紹使用Alluxio加速深度學(xué)習(xí)訓(xùn)練任務(wù)的實(shí)驗(yàn)方法；然后對(duì)實(shí)驗(yàn)結(jié)果進(jìn)行分析，提出影響加速效果的原因和優(yōu)化手段，并驗(yàn)證初步優(yōu)化的結(jié)果。

4.1 實(shí)驗(yàn)環(huán)境

本文使用阿里云托管Kubernetes服務(wù)，部署含有多個(gè)GPU節(jié)點(diǎn)的Kubernetes容器集群作為實(shí)驗(yàn)環(huán)境。使用4臺(tái)服務(wù)器，每臺(tái)服務(wù)器上有8塊NVIDIA Tesla V100 GPU卡，共提供32塊GPU卡的算力。訓(xùn)練程序通過(guò)Alluxio提供的POSIX接口讀取遠(yuǎn)程數(shù)據(jù)存儲(chǔ)，并緩存到本地Alluxio緩存中。每臺(tái)服務(wù)器可為Alluxio提供40 GB內(nèi)存存儲(chǔ)，實(shí)驗(yàn)環(huán)境共提供160 GB分布式緩存空間。

使用圖像分類模型ResNet50[10]與圖像識(shí)別數(shù)據(jù)集ImageNet[11]進(jìn)行模型訓(xùn)練實(shí)驗(yàn)。ImageNet數(shù)據(jù)集包含128萬(wàn)余張圖片及其標(biāo)注數(shù)據(jù)，總數(shù)據(jù)量約為144 GB。使用TensorFlow作為深度學(xué)習(xí)訓(xùn)練框架，Horovod[12]作為分布式訓(xùn)練通信框架。每塊GPU卡處理訓(xùn)練數(shù)據(jù)的batch_size為256。訓(xùn)練任務(wù)執(zhí)行標(biāo)準(zhǔn)TensorFlow benchmark測(cè)試程序，當(dāng)達(dá)到預(yù)定訓(xùn)練輪數(shù)時(shí)，任務(wù)自動(dòng)停止，同時(shí)檢查訓(xùn)練所得模型的圖像分類精確度以及訓(xùn)練速度（每秒處理圖片數(shù)）。

4.2 實(shí)驗(yàn)結(jié)果

對(duì)實(shí)驗(yàn)中模型精確度達(dá)到業(yè)界標(biāo)準(zhǔn)情況下的訓(xùn)練速度結(jié)果進(jìn)行評(píng)估。分別使用合成數(shù)據(jù)（即synthetic）和Alluxio緩存系統(tǒng)訪問(wèn)存儲(chǔ)服務(wù)中的真實(shí)數(shù)據(jù)（即Alluxio）進(jìn)行模型訓(xùn)練，并對(duì)比性能結(jié)果，如圖2所示。橫軸表示任務(wù)使用GPU卡數(shù)量，縱軸表示訓(xùn)練速度。合成數(shù)據(jù)是訓(xùn)練程序在內(nèi)存中生成的數(shù)據(jù)，節(jié)省了I/O開(kāi)銷，可作為訓(xùn)練性能的理論上限。

由圖2可以看出，使用1~2塊GPU卡訓(xùn)練時(shí)，兩者性能差距在可以接受的范圍內(nèi)；但當(dāng)GPU卡增加到4塊時(shí)，二者性能差距比較明顯；當(dāng)GPU卡數(shù)量達(dá)到8塊時(shí)，使用Alluxio緩存系統(tǒng)訪問(wèn)存儲(chǔ)服務(wù)中的數(shù)據(jù)的訓(xùn)練速度下降至使用合成數(shù)據(jù)的28.77%。通過(guò)監(jiān)控觀測(cè)到GPU服務(wù)器的系統(tǒng)資源利用率并不高，這說(shuō)明使用Alluxio默認(rèn)配置實(shí)現(xiàn)的分布式緩存系統(tǒng)無(wú)法支持GPU訓(xùn)練規(guī)?；瘮U(kuò)展。這成為深度學(xué)習(xí)訓(xùn)練平臺(tái)能力的瓶頸。

通過(guò)分析Alluxio的系統(tǒng)架構(gòu)和實(shí)現(xiàn)方法，發(fā)現(xiàn)造成無(wú)法支撐訓(xùn)練任務(wù)性能彈性擴(kuò)展的主要原因有如下3個(gè)。

● Alluxio的文件操作需要進(jìn)行多次遠(yuǎn)程過(guò)程調(diào)用（remote procedure call，RPC）才能獲取到數(shù)據(jù)。

● 默認(rèn)情況下，Alluxio優(yōu)先將全量數(shù)據(jù)緩存在本地節(jié)點(diǎn)。當(dāng)本地緩存容量飽和時(shí)，就會(huì)驅(qū)逐已緩存數(shù)據(jù)。如果被驅(qū)逐數(shù)據(jù)很快又被任務(wù)讀回，就會(huì)導(dǎo)致同一份數(shù)據(jù)頻繁寫入和刪除，形成數(shù)據(jù)震蕩。

● 緩存系統(tǒng)提供的用戶空間文件系統(tǒng)（filesystem in userspace，F(xiàn)USE）接口雖然易于使用，但是讀寫性能并不理想。在深度學(xué)習(xí)訓(xùn)練任務(wù)多線程高并發(fā)讀寫下，需要優(yōu)化FUSE的配置參數(shù)。

4.3 優(yōu)化Alluxio系統(tǒng)參數(shù)

在分析了上述性能瓶頸后，本文首先調(diào)整一系列Alluxio系統(tǒng)參數(shù)。實(shí)驗(yàn)結(jié)果表明，Alluxio緩存系統(tǒng)的性能得到一定程度的提升。

4.3.1 優(yōu)化FUSE文件系統(tǒng)參數(shù)

Linux系統(tǒng)上的FUSE實(shí)現(xiàn)分為兩層，包括運(yùn)行在用戶態(tài)的libfuse和運(yùn)行在內(nèi)核態(tài)的FUSE模塊。本文分別進(jìn)行調(diào)優(yōu)。第一個(gè)優(yōu)化手段是升級(jí)Linux內(nèi)核版本。高版本Linux系統(tǒng)內(nèi)核對(duì)FUSE模塊內(nèi)置了許多優(yōu)化，比如Linux Kernel 4.19版的FUSE讀性能比3.10版提升20%。第二個(gè)優(yōu)化手段是調(diào)整libfuse的參數(shù)，包括如下兩種。

● 增大參數(shù)entry_timeout和attr_timeout的值，避免libfuse本地讀取文件的inode和dentry信息頻繁過(guò)期，導(dǎo)致大量讀文件操作穿透到Alluxio的遠(yuǎn)程元數(shù)據(jù)管理節(jié)點(diǎn)。

● 適當(dāng)調(diào)大libfuse線程池參數(shù)max_idle_threads的值（默認(rèn)為10），避免訓(xùn)練任務(wù)高并發(fā)訪問(wèn)緩存數(shù)據(jù)時(shí)，libfuse可用線程頻繁地創(chuàng)建和銷毀，引入過(guò)多CPU開(kāi)銷。

4.3.2 優(yōu)化Alluxio參數(shù)

深度學(xué)習(xí)訓(xùn)練任務(wù)讀取的訓(xùn)練數(shù)據(jù)量往往很大，并發(fā)壓力也非常大。本文針對(duì)緩存數(shù)據(jù)驅(qū)逐策略、元數(shù)據(jù)操作效率和容器環(huán)境下客戶端讀取緩存數(shù)據(jù)的方法，進(jìn)行多組Alluxio系統(tǒng)參數(shù)配置。

第一組是參數(shù)優(yōu)化，避免Alluxio頻繁驅(qū)逐緩存數(shù)據(jù)，造成數(shù)據(jù)震蕩，包括如下3種。

● alluxio.user.ufs.block.read.location.policy。默認(rèn)值為alluxio.client.block.policy.LocalFirstPolicy，表示優(yōu)先將數(shù)據(jù)保存在Alluxio客戶端節(jié)點(diǎn)。本文設(shè)置為alluxio.client.block.policy.LocalFirstAvoidEvictionPolicy。同時(shí)設(shè)置alluxio.user.block.avoid.eviction.policy.reserved.size.bytes參數(shù)，保證在節(jié)點(diǎn)本地固定保留適量緩存數(shù)據(jù)不被驅(qū)逐。

● alluxio.user.file.passive.cache.enabled。默認(rèn)值為true，導(dǎo)致Alluxio節(jié)點(diǎn)額外復(fù)制已經(jīng)在其他節(jié)點(diǎn)上緩存過(guò)的數(shù)據(jù)。本文將該屬性置為false，避免多余的本地緩存副本。

● alluxio.user.file.readtype.default。默認(rèn)值為CACHE_PROMOTE，會(huì)導(dǎo)致緩存數(shù)據(jù)在節(jié)點(diǎn)的各存儲(chǔ)層間（如內(nèi)存與磁盤）遷移。本文將該參數(shù)值改為CACHE，避免數(shù)據(jù)遷移和數(shù)據(jù)加鎖開(kāi)銷。

第二組也是參數(shù)優(yōu)化，配置Alluxio客戶端緩存遠(yuǎn)程文件元數(shù)據(jù)的策略?？蛻舳司彺嬖獢?shù)據(jù)信息，可避免頻繁地對(duì)Alluxio服務(wù)端進(jìn)行RPC訪問(wèn)，具體包括如下4種。

● alluxio.user.metadata.cache.enabled，設(shè)置為true，表示開(kāi)啟客戶端元數(shù)據(jù)緩存。

● alluxio.user.metadata.cache.max.size，設(shè)置客戶端可緩存元數(shù)據(jù)的最大值。

● alluxio.user.metadata.cache.expiration.time，設(shè)置客戶端元數(shù)據(jù)緩存的有效時(shí)間。

● alluxio.user.worker.list.refresh.interval，設(shè)置Alluxio服務(wù)端同步所有緩存節(jié)點(diǎn)狀態(tài)的時(shí)間間隔，本文設(shè)為2 min。

第三組是配置容器本地訪問(wèn)Alluxio緩存系統(tǒng)的方法。容器環(huán)境下Alluxio支持兩種短路讀寫方式來(lái)實(shí)現(xiàn)本地訪問(wèn)緩存數(shù)據(jù)，包括UNIX Socket和直接文件訪問(wèn)。本文使用直接文件訪問(wèn)方式，使Alluxio客戶端讀取本地緩存節(jié)點(diǎn)的性能更優(yōu)。

4.3.3 優(yōu)化Alluxio容器中的JVM參數(shù)

通過(guò)Kubernetes部署Java應(yīng)用容器，如果不指定容器請(qǐng)求的CPU資源量，容器內(nèi)Java虛擬機(jī)（Java virtual machine，JVM）識(shí)別到的可用CPU核數(shù)可能有誤，進(jìn)而影響容器內(nèi)的Alluxio可用線程數(shù)。本文將JVM參數(shù)-XX:ActiveProcessorCount設(shè)置為容器內(nèi)Alluxio進(jìn)程可使用的CPU資源數(shù)量。

本文還調(diào)整了JVM垃圾回收（JVM garbage collection，JVM GC）和JIT（just in time）相關(guān)參數(shù)，包括-XX:ParallelGCThreads、-XX: ConcGCThreads和-XX:CICompilerCount，將其設(shè)置為較小值，避免線程頻繁切換，影響Alluxio進(jìn)程的性能。

4.4 優(yōu)化結(jié)果分析

優(yōu)化上述系統(tǒng)參數(shù)后，在一臺(tái)配置8塊GPU卡的服務(wù)器上再次訓(xùn)練ResNet50模型。如圖3所示，訓(xùn)練速度明顯加快，與使用合成數(shù)據(jù)的訓(xùn)練速度僅相差3.3%左右。并且，這樣的加速效果可以接近線性地?cái)U(kuò)展到4臺(tái)服務(wù)器（共32塊GPU卡）的實(shí)驗(yàn)中。

圖3 優(yōu)化分布式緩存系統(tǒng)加速分布式訓(xùn)練的實(shí)驗(yàn)結(jié)果

然而，實(shí)驗(yàn)中發(fā)現(xiàn)，繼續(xù)增加GPU資源后，緩存加速的擴(kuò)展性瓶頸再次出現(xiàn)。這使得優(yōu)化Alluxio系統(tǒng)參數(shù)的方法只能對(duì)使用少于32塊GPU卡的ResNet50訓(xùn)練任務(wù)產(chǎn)生良好的加速效果。同時(shí)，本文前述實(shí)驗(yàn)都使用阿里云SSD云盤作為數(shù)據(jù)存儲(chǔ)。雖然SSD云盤可以提供300 MB/s以上的I/O吞吐性能，但是單塊云盤容量有限，且成本較高。如果在更大量級(jí)的訓(xùn)練數(shù)據(jù)集上執(zhí)行更大規(guī)模的分布式訓(xùn)練任務(wù)，SSD云盤并不是最佳選擇。實(shí)際上，在大規(guī)模分布式訓(xùn)練場(chǎng)景中，使用具有較高性價(jià)比的阿里云對(duì)象存儲(chǔ)服務(wù)（object store service，OSS）是更常用的方案。本文后續(xù)實(shí)驗(yàn)也將采用OSS作為訓(xùn)練數(shù)據(jù)集的存儲(chǔ)方案。

5 任務(wù)與數(shù)據(jù)協(xié)同調(diào)度——TDCS

目前，典型分布式緩存技術(shù)實(shí)現(xiàn)多用靜態(tài)架構(gòu)進(jìn)行部署，比如Alluxio。在初始化部署之后，緩存系統(tǒng)的拓?fù)浜腿萘烤凸潭?。在運(yùn)行過(guò)程中，Alluxio不會(huì)主動(dòng)對(duì)緩存數(shù)據(jù)的訪問(wèn)頻率和系統(tǒng)資源的使用情況進(jìn)行動(dòng)態(tài)擴(kuò)展，無(wú)法降低系統(tǒng)壓力。Alluxio也不會(huì)感知上層訪問(wèn)應(yīng)用，無(wú)法做到根據(jù)不同應(yīng)用狀態(tài)和數(shù)據(jù)訪問(wèn)特點(diǎn)同步調(diào)整緩存系統(tǒng)的部署拓?fù)浜途彺娌呗浴Ｒ虼?，在前面的?shí)驗(yàn)中，盡管優(yōu)化Alluxio系統(tǒng)的參數(shù)后，可以加速最多使用32塊GPU卡的訓(xùn)練任務(wù)，但是，增加更多GPU卡參與計(jì)算后，受到緩存系統(tǒng)靜態(tài)部署的限制，以及訓(xùn)練任務(wù)運(yùn)行拓?fù)鋭?dòng)態(tài)變化的干擾，加速效果再次遇到瓶頸。

經(jīng)過(guò)分析深度學(xué)習(xí)訓(xùn)練任務(wù)的特點(diǎn)發(fā)現(xiàn)，一方面，在單個(gè)任務(wù)運(yùn)行周期內(nèi)以及多個(gè)任務(wù)運(yùn)行過(guò)程之間，都存在計(jì)算與數(shù)據(jù)的時(shí)間相關(guān)性；另一方面，對(duì)于一個(gè)訓(xùn)練任務(wù)使用的計(jì)算資源，可能會(huì)按需進(jìn)行彈性伸縮。例如，當(dāng)集群資源空閑時(shí)，可通過(guò)擴(kuò)展利用更多GPU資源，加快訓(xùn)練任務(wù)的整體進(jìn)程；當(dāng)集群資源緊張時(shí)，對(duì)低優(yōu)先級(jí)任務(wù)進(jìn)行資源回收。分布式緩存系統(tǒng)會(huì)優(yōu)先部署在計(jì)算發(fā)生的本地節(jié)點(diǎn)上，通過(guò)就近讀取，節(jié)省大量遠(yuǎn)程數(shù)據(jù)I/O損耗。這使得計(jì)算與緩存數(shù)據(jù)之間還存在空間相關(guān)性。

利用計(jì)算與緩存數(shù)據(jù)的時(shí)間和空間相關(guān)性，本文設(shè)計(jì)了深度學(xué)習(xí)訓(xùn)練任務(wù)與分布式緩存數(shù)據(jù)互相感知的協(xié)同調(diào)度方法TDCS。TDCS分別針對(duì)單任務(wù)、多任務(wù)和彈性伸縮任務(wù)，實(shí)現(xiàn)了多維度的統(tǒng)一管理和調(diào)度策略，具體包括訓(xùn)練數(shù)據(jù)預(yù)加載策略、多任務(wù)緩存數(shù)據(jù)共享策略、分布式緩存彈性策略等。筆者在前文所述基于Kubernetes容器和分布式緩存的深度學(xué)習(xí)模型訓(xùn)練系統(tǒng)之上，實(shí)現(xiàn)了TDCS方法。通過(guò)增加預(yù)加載控制器Preloader、緩存數(shù)據(jù)管理器CacheManager、彈性伸縮控制器CacheScaler等組件，完成訓(xùn)練任務(wù)和分布式緩存系統(tǒng)的統(tǒng)一管理和調(diào)度。支持TDCS方法的完整系統(tǒng)架構(gòu)如圖4所示。

圖4 使用TDCS分布式緩存的容器化深度學(xué)習(xí)訓(xùn)練系統(tǒng)架構(gòu)

5.1 訓(xùn)練數(shù)據(jù)預(yù)加載策略

對(duì)于單個(gè)訓(xùn)練任務(wù)，通常以多輪迭代方式執(zhí)行。訓(xùn)練任務(wù)在給定數(shù)據(jù)集上循環(huán)執(zhí)行算法，不斷調(diào)整參數(shù)，使得算法提取和比對(duì)特征的準(zhǔn)確率最終達(dá)到目標(biāo)。這種迭代執(zhí)行具有明顯的時(shí)序特征。由于每輪迭代執(zhí)行都會(huì)讀取全量訓(xùn)練數(shù)據(jù)，各輪之間會(huì)有大量數(shù)據(jù)需重復(fù)計(jì)算。因此，通過(guò)分布式緩存，將盡可能多的訓(xùn)練數(shù)據(jù)保存在計(jì)算節(jié)點(diǎn)本地，之后就可以避免每輪計(jì)算都反復(fù)從遠(yuǎn)程存儲(chǔ)系統(tǒng)讀取數(shù)據(jù)造成的損耗。然而，對(duì)于首次執(zhí)行的任務(wù)，還存在“冷啟動(dòng)”問(wèn)題。第一輪迭代周期內(nèi)尚未有任何數(shù)據(jù)被緩存，執(zhí)行計(jì)算的同時(shí)必須從遠(yuǎn)程存儲(chǔ)系統(tǒng)中拉取所有訓(xùn)練數(shù)據(jù)，性能明顯低于后續(xù)迭代。

針對(duì)“冷啟動(dòng)”，TDCS設(shè)計(jì)實(shí)現(xiàn)了訓(xùn)練數(shù)據(jù)集Preloader，負(fù)責(zé)在任務(wù)計(jì)算開(kāi)始之前，預(yù)先讀取部分或者全部訓(xùn)練數(shù)據(jù)進(jìn)入緩存系統(tǒng)。TDCS允許使用者指定是否啟用預(yù)加載功能，以及預(yù)加載的具體策略。策略包括啟動(dòng)預(yù)加載的時(shí)間、預(yù)加載數(shù)據(jù)量或其占整個(gè)訓(xùn)練數(shù)據(jù)集的比例，以及預(yù)加載特定部分的訓(xùn)練數(shù)據(jù)（如僅加載遠(yuǎn)程文件系統(tǒng)中特定路徑下的數(shù)據(jù)）。

訓(xùn)練平臺(tái)的用戶可以提交針對(duì)某個(gè)訓(xùn)練數(shù)據(jù)集的預(yù)加載指令，Preloader響應(yīng)并依據(jù)預(yù)加載策略，在計(jì)算啟動(dòng)之前就開(kāi)始將部分或者全部訓(xùn)練數(shù)據(jù)拉取到分布式緩存系統(tǒng)中。預(yù)加載數(shù)據(jù)過(guò)程與用戶提交的訓(xùn)練任務(wù)的執(zhí)行是解耦的，可以完全串行，也可以部分并行。TDCS通過(guò)Preloader解決了單個(gè)訓(xùn)練任務(wù)的“冷啟動(dòng)”問(wèn)題，保證整個(gè)訓(xùn)練過(guò)程沒(méi)有明顯的讀取數(shù)據(jù)時(shí)延。

5.2 多任務(wù)緩存數(shù)據(jù)共享策略

深度學(xué)習(xí)在很多領(lǐng)域取得了非常好的效果，如圖像分類、物體檢測(cè)、自然語(yǔ)言理解等領(lǐng)域。一個(gè)領(lǐng)域內(nèi)經(jīng)常會(huì)有多種深度學(xué)習(xí)算法在演進(jìn)。而訓(xùn)練同一類領(lǐng)域模型的多種算法經(jīng)常會(huì)使用同樣的數(shù)據(jù)集。比如，在視覺(jué)識(shí)別領(lǐng)域，幾乎所有深度學(xué)習(xí)算法會(huì)將ImageNet作為訓(xùn)練數(shù)據(jù)的基線。對(duì)于同一種算法模型，也需要多次提交任務(wù)，使用同一份訓(xùn)練數(shù)據(jù)反復(fù)實(shí)驗(yàn)。依據(jù)每個(gè)任務(wù)的實(shí)驗(yàn)結(jié)果，不斷調(diào)整模型結(jié)構(gòu)和參數(shù)，最終得到表現(xiàn)穩(wěn)定的模型版本。因此，在深度學(xué)習(xí)訓(xùn)練平臺(tái)上，會(huì)有很多任務(wù)重復(fù)使用相同數(shù)據(jù)進(jìn)行訓(xùn)練。根據(jù)這些任務(wù)提交的時(shí)序特征，可在任務(wù)之間共享緩存數(shù)據(jù)，從而提升多個(gè)相關(guān)任務(wù)的性能。

TDCS利用多任務(wù)間的時(shí)序特征，設(shè)計(jì)了任務(wù)與緩存數(shù)據(jù)的親和性調(diào)度策略，即把后序提交的任務(wù)分配到已緩存其目標(biāo)數(shù)據(jù)的計(jì)算節(jié)點(diǎn)上，保證后序任務(wù)可以直接重用本地緩存數(shù)據(jù)。具體地，如果在ti時(shí)刻提交任務(wù)T1，使用數(shù)據(jù)集D1訓(xùn)練。假設(shè)訓(xùn)練平臺(tái)調(diào)度器Scheduler為T1分配了計(jì)算節(jié)點(diǎn)集合S1={N1,N2,N3}，緩存系統(tǒng)會(huì)在節(jié)點(diǎn)集合S1上保存D1的緩存D1＇。在tj（j≥i）時(shí)刻，提交任務(wù)T2，也使用數(shù)據(jù)集D1進(jìn)行訓(xùn)練。

TDCS的任務(wù)調(diào)度器Scheduler為T2分配計(jì)算節(jié)點(diǎn)的算法流程如下。這樣可以最大限度地保證T2計(jì)算與本地緩存數(shù)據(jù)的親和性。

● Scheduler查詢CacheManager后，得知集群中已存在數(shù)據(jù)集D1的緩存數(shù)據(jù)D1＇，且D1＇部署在節(jié)點(diǎn)集合S1上。

● Scheduler根據(jù)T2的計(jì)算資源要求，在集群中找到符合執(zhí)行任務(wù)條件的備選節(jié)點(diǎn)集合S2，假設(shè)為{M1,M2,M3,M4,M5}。

● Scheduler計(jì)算集合S1與S2的交集，得到高優(yōu)先級(jí)備選節(jié)點(diǎn)集合S3。

● Scheduler使用貪心算法，總是更多地選擇S3中的節(jié)點(diǎn)，并將其分配給任務(wù)T2。

在實(shí)現(xiàn)多任務(wù)共享緩存數(shù)據(jù)調(diào)度策略時(shí)，會(huì)存在“緩存熱點(diǎn)”和“緩存清理”問(wèn)題。

● 緩存熱點(diǎn)：考慮到在特定時(shí)期有大量類似T2的任務(wù)需要幾乎同時(shí)執(zhí)行，如果多個(gè)任務(wù)同時(shí)訪問(wèn)緩存數(shù)據(jù)D1＇，會(huì)導(dǎo)致S1內(nèi)節(jié)點(diǎn)的訪問(wèn)壓力過(guò)大，使這些節(jié)點(diǎn)成為“熱點(diǎn)”。

● 緩存清理：考慮到計(jì)算節(jié)點(diǎn)本地內(nèi)存和磁盤存儲(chǔ)容量有限，緩存數(shù)據(jù)D1＇勢(shì)必會(huì)從S1節(jié)點(diǎn)上被逐步驅(qū)逐，或者徹底刪除。任務(wù)T2的提交時(shí)刻tj不確定，導(dǎo)致緩存數(shù)據(jù)的利用率不穩(wěn)定。極端情況下，每次T2被提交的時(shí)候，D1＇都已被刪除，緩存完全無(wú)法被多任務(wù)共享。

為了解決這兩個(gè)問(wèn)題，TDCS設(shè)計(jì)實(shí)現(xiàn)了緩存數(shù)據(jù)管理器CacheManager，負(fù)責(zé)根據(jù)用戶指定策略，管理對(duì)緩存數(shù)據(jù)的訪問(wèn)和清理緩存數(shù)據(jù)。

首先，CacheManager控制緩存數(shù)據(jù)D1＇的并發(fā)訪問(wèn)數(shù)上限。用戶可以選擇配置應(yīng)對(duì)并發(fā)任務(wù)數(shù)超過(guò)限制的策略。不同于參考文獻(xiàn)[13]提出的優(yōu)化緩存系統(tǒng)內(nèi)部數(shù)據(jù)分布算法的方法，以及參考文獻(xiàn)[14]提出的利用存儲(chǔ)系統(tǒng)中數(shù)據(jù)塊間的關(guān)聯(lián)性指導(dǎo)Alluxio緩存策略CPR（cache prefet repace），TDCS避免侵入修改分布式緩存引擎，而選擇在其外部增加控制訪問(wèn)緩存任務(wù)量和緩存供給量的邏輯，實(shí)現(xiàn)緩存負(fù)載穩(wěn)定和均衡。由CacheManager與Scheduler配合，動(dòng)態(tài)調(diào)整超限并發(fā)任務(wù)的資源分配，以及緩存數(shù)據(jù)副本數(shù)量。為此，CacheManager提供了Suspend和Clone兩種策略。

● Suspend：表示暫時(shí)掛起新任務(wù)對(duì)D1＇的訪問(wèn)。此時(shí)，CacheManager會(huì)通知Scheduler，將超限任務(wù)放入等待隊(duì)列。當(dāng)并發(fā)訪問(wèn)D1＇的任務(wù)數(shù)量降到上限以內(nèi)時(shí)，CacheManager會(huì)通知Scheduler將等待隊(duì)列中的任務(wù)移出隊(duì)伍，將其盡量調(diào)度到D1＇所在的節(jié)點(diǎn)上。

● Clone：表示CacheManager在集群中復(fù)制一份新的緩存數(shù)據(jù)D1＇＇，供新任務(wù)讀取。Scheduler查詢CacheManager后，得到D1存在可被訪問(wèn)的緩存數(shù)據(jù)D1＇＇及其所處節(jié)點(diǎn)集合Si。根據(jù)最大限度地保證計(jì)算與緩存數(shù)據(jù)親和性的原則，新任務(wù)會(huì)被盡可能多地調(diào)度到Si的節(jié)點(diǎn)上，避免出現(xiàn)緩存熱點(diǎn)。

其次，CacheManager支持3種緩存清理策略，包括：鎖定資源，不清理緩存；定時(shí)清理；最近最少使用（least recently used，LRU）清理。

用戶可以根據(jù)計(jì)算節(jié)點(diǎn)的可用存儲(chǔ)資源量、任務(wù)提交計(jì)劃、多任務(wù)的相關(guān)性等因素，配置清理策略。例如，在特定時(shí)段，存在許多使用相同訓(xùn)練數(shù)據(jù)的任務(wù)需要執(zhí)行，為了保證總是有緩存數(shù)據(jù)用于加速訓(xùn)練計(jì)算讀取，可以選擇不清理緩存，也可以選擇定時(shí)清理，具體時(shí)間間隔可以根據(jù)任務(wù)執(zhí)行計(jì)劃和可用存儲(chǔ)資源量來(lái)設(shè)置。而對(duì)于集群中存在多個(gè)訓(xùn)練數(shù)據(jù)集的緩存情況，可以選擇CacheManager按照LRU算法，優(yōu)先清理最近最少訪問(wèn)的緩存數(shù)據(jù)。還可以擴(kuò)展CacheManager模塊，以支持更多復(fù)雜的緩存清理策略，比如參考文獻(xiàn)[15]提出的兼顧最近訪問(wèn)時(shí)間和歷史訪問(wèn)頻率的緩存替換策略等。

5.3 分布式緩存彈性策略

通常訓(xùn)練平臺(tái)內(nèi)會(huì)有很多任務(wù)同時(shí)運(yùn)行，它們共享了集群計(jì)算資源，尤其是寶貴的GPU資源。為了提升GPU利用率，訓(xùn)練平臺(tái)調(diào)度器會(huì)動(dòng)態(tài)調(diào)整分配給任務(wù)的GPU資源。例如，回收低優(yōu)先級(jí)任務(wù)占用的部分GPU節(jié)點(diǎn)，將其分配給高優(yōu)先級(jí)任務(wù)。訓(xùn)練過(guò)程中，任務(wù)需要具有彈性伸縮的能力。為高優(yōu)先級(jí)任務(wù)動(dòng)態(tài)分配更多計(jì)算節(jié)點(diǎn)時(shí)，若將分布式緩存系統(tǒng)彈性擴(kuò)展到這些新增節(jié)點(diǎn)上，則可以擴(kuò)大緩存總?cè)萘?，進(jìn)而支撐更大規(guī)模的并發(fā)讀取，提升任務(wù)整體的訓(xùn)練性能。

TDCS設(shè)計(jì)了CacheScaler，負(fù)責(zé)彈性擴(kuò)展、收縮分布式緩存系統(tǒng)，使緩存系統(tǒng)的部署位置與訓(xùn)練任務(wù)的運(yùn)行節(jié)點(diǎn)保持同步，保證計(jì)算所需緩存數(shù)據(jù)總是在本地就可讀取。CacheScaler可通過(guò)如下3種觸發(fā)方法來(lái)彈性伸縮分布式緩存系統(tǒng)。

● API觸發(fā)伸縮活動(dòng)。用戶可以調(diào)用CacheScaler的API，主動(dòng)觸發(fā)擴(kuò)展和收縮緩存。

● 事件觸發(fā)伸縮活動(dòng)。CacheScaler通過(guò)事件訂閱機(jī)制，發(fā)現(xiàn)、響應(yīng)訓(xùn)練任務(wù)的計(jì)算資源量變化事件，自動(dòng)觸發(fā)擴(kuò)展和收縮緩存。

● 監(jiān)控觸發(fā)伸縮活動(dòng)。本文的訓(xùn)練平臺(tái)基于Kubernetes容器編排和管理技術(shù)構(gòu)建。利用集群監(jiān)控系統(tǒng)，根據(jù)監(jiān)控指標(biāo)的變化情況，調(diào)用Kubernetes的HPA（horizontal pod autoscaler）組件，主動(dòng)伸縮緩存系統(tǒng)。典型的監(jiān)控指標(biāo)是緩存系統(tǒng)容量使用率。當(dāng)緩存系統(tǒng)容量使用率（即緩存數(shù)據(jù)量的占比）達(dá)到給定閾值時(shí)，就會(huì)自動(dòng)觸發(fā)擴(kuò)展緩存；反之，當(dāng)緩存系統(tǒng)容量使用率長(zhǎng)期保持低水平時(shí)，可以選擇通過(guò)HPA觸發(fā)收縮緩存。

TDCS通過(guò)CacheScaler、Kubernetes集群監(jiān)控和HPA等組件支持分布式緩存的彈性策略，使緩存數(shù)據(jù)能夠更靈活地配合訓(xùn)練任務(wù)彈性伸縮，既提供了高訓(xùn)練性能，也保證了較高的資源利用率。實(shí)驗(yàn)表明，TDCS幫助Alluxio支持從使用8塊NVIDIA V100 GPU卡計(jì)算的深度學(xué)習(xí)訓(xùn)練任務(wù)擴(kuò)展到使用128塊NVIDIA V100 GPU卡的任務(wù)。

6 TDCS實(shí)驗(yàn)結(jié)果

為了在前文實(shí)驗(yàn)基礎(chǔ)之上，驗(yàn)證TDCS進(jìn)一步提升訓(xùn)練任務(wù)性能的效果，本文使用相同的ResNet50圖像分類模型和ImageNet圖像識(shí)別數(shù)據(jù)集，在不同數(shù)量的GPU資源上測(cè)試了多組分布式訓(xùn)練任務(wù)。如圖5所示，4組實(shí)驗(yàn)數(shù)據(jù)分別使用8、32、64、128塊NVIDIA Tesla V100 GPU卡進(jìn)行分布式訓(xùn)練。每組實(shí)驗(yàn)都對(duì)比了使用4種不同緩存配置的訓(xùn)練速度。

圖5 使用TDCS協(xié)同調(diào)度分布式緩存加速ResNet50模型訓(xùn)練的實(shí)驗(yàn)結(jié)果對(duì)比

配置1：不使用緩存，任務(wù)直接讀取遠(yuǎn)程OSS數(shù)據(jù)。

配置2：使用默認(rèn)配置Alluxio讀取OSS數(shù)據(jù)。

配置3：在配置2的基礎(chǔ)上增加TDCS訓(xùn)練數(shù)據(jù)預(yù)加載策略。

配置4：在配置3的基礎(chǔ)上增加TDCS多任務(wù)緩存數(shù)據(jù)共享策略。

其中，使用配置3、4的實(shí)驗(yàn)中，都使用了TDCS分布式緩存彈性策略。

總體來(lái)看，使用TDCS協(xié)同調(diào)度增強(qiáng)的分布式緩存之后，實(shí)驗(yàn)任務(wù)的訓(xùn)練速度能達(dá)到直接讀取OSS數(shù)據(jù)的任務(wù)速度的2.2~3.7倍。在所有實(shí)驗(yàn)中，使用默認(rèn)配置的Alluxio讀取訓(xùn)練數(shù)據(jù)后，都會(huì)比不使用緩存的訓(xùn)練速度有大幅提升，加速比范圍為25%~200%。在增加使用TDCS訓(xùn)練數(shù)據(jù)預(yù)加載策略后，相比僅使用默認(rèn)Alluxio的加速比會(huì)提升7%~102%。在繼續(xù)增加使用TDCS多任務(wù)共享緩存調(diào)度策略后，訓(xùn)練速度依然還有4%~7%的提升。特別地，當(dāng)使用默認(rèn)配置的Alluxio加速8塊GPU卡上的訓(xùn)練任務(wù)時(shí)，由于計(jì)算資源不足，已經(jīng)出現(xiàn)瓶頸，繼續(xù)增加使用TDCS的協(xié)同調(diào)度策略并不能進(jìn)一步明顯地提升訓(xùn)練性能。

7 結(jié)束語(yǔ)

本文針對(duì)云環(huán)境下，計(jì)算、存儲(chǔ)分離架構(gòu)帶來(lái)的數(shù)據(jù)讀取性能瓶頸問(wèn)題，提出基于分布式緩存結(jié)合Kubernetes容器技術(shù)加速深度學(xué)習(xí)訓(xùn)練的方法和架構(gòu)。在應(yīng)用Alluxio分布式緩存系統(tǒng)，并進(jìn)行Alluxio系統(tǒng)參數(shù)優(yōu)化后，獲得初步的訓(xùn)練加速效果。受限于Alluxio靜態(tài)部署的系統(tǒng)架構(gòu)，加速效果無(wú)法擴(kuò)展到大規(guī)模分布式訓(xùn)練任務(wù)，進(jìn)而提出TDCS訓(xùn)練任務(wù)與緩存數(shù)據(jù)協(xié)同調(diào)度方法和其在Kubernetes容器集群架構(gòu)下的系統(tǒng)實(shí)現(xiàn)。通過(guò)增加訓(xùn)練數(shù)據(jù)預(yù)加載策略、多任務(wù)緩存數(shù)據(jù)共享策略以及分布式緩存彈性策略，TDCS可以保證在容器環(huán)境下給深度學(xué)習(xí)訓(xùn)練任務(wù)帶來(lái)2~3倍的加速，并且加速效果可以擴(kuò)展到使用128塊NVIDIA GPU卡的大規(guī)模分布式訓(xùn)練場(chǎng)景。