基于分布式緩存加速容器化深度學習的優化方法

張凱，車漾

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

1 引言

最近10年，深度學習技術和應用發展風起云涌，百花齊放。尤其在機器視覺、自然語言理解、語音識別等領域，一大批成熟的人工智能模型和服務正落地應用于各行各業。越來越多的行業發掘出大量需求，需要利用企業日積月累的海量業務數據，高效便捷地訓練深度學習和機器學習模型。

與此同時，云計算在IaaS、PaaS和SaaS等層次已經發展得相當成熟，并逐步進入云原生時代。在云原生技術體系中，以Docker為代表的Linux容器技術和以Kubernetes為代表的容器編排管理技術在應用開發、交付、運維的生命周期中逐漸成為業界的事實標準。同時，應用微服務架構的自動化部署，運行時動態彈性伸縮，完善的日志、監控、告警等運維體系等，都成為現代軟件開發運維的基礎需求。

深度學習和人工智能應用往往需要使用大量GPU、張量處理器（tensor processing unit，TPU），甚至神經元處理器（neural processing unit，NPU）這類定制的高性能異構計算設備來迭代處理海量的訓練數據，最終得到滿足準確率和性能要求的模型。由于數據規模較大、模型復雜度較高，訓練過程一般較漫長。因此，優化GPU等異構計算設備的利用效率、加快訓練數據處理速度，成為提升深度學習和人工智能應用生產率和成本優化的關鍵因素。

Kubernetes容器編排管理技術對于GPU、TPU、NPU等高性能異構計算設備資源的支持日趨成熟。考慮到云計算在成本優化、資源規模和彈性伸縮方面的優勢，配合Docker容器技術擅長的輕量級和標準化應用交付能力，業界主流的生產人工智能模型和應用的技術方案會采用容器集群結合云計算平臺的GPU資源的架構，進行分布式深度學習模型訓練。

在“云上”執行訓練任務，通常會在帶有GPU設備的計算服務節點上進行。訓練數據會被存放在各種異構的云存儲服務中，如對象存儲服務、遠程文件系統服務等。這種典型的計算和存儲分離的分布式計算架構有利于增強計算和存儲的彈性擴展能力，但同時也會帶來數據訪問時延增大的問題。如果考慮數據敏感性、隱私保護和安全合規的要求，訓練數據通常也會被存放在私有數據中心中。這樣勢必要求深度學習模型訓練平臺采用混合云的架構，統一使用“云上”計算資源來訪問“云下”數據。而這種“本地存儲+云上計算”的訓練模式進一步增大了計算和存儲分離架構帶來的遠程數據訪問時延，進而導致深度學習模型訓練整體性能的顯著下降。

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

2 訪問訓練數據的典型方法

為了規避計算和存儲分離架構帶來的數據訪問時延，典型做法是在開始模型訓練之前，將訓練數據復制到GPU計算節點本地的磁盤存儲中，如普通機械硬盤或者NVMe SSD等高速存儲設備；或者將數據提前復制到部署在計算節點上的分布式存儲系統中，如Ceph、GlusterFS。隨后計算任務就相當于從本地讀取訓練數據，有效緩解了數據訪問時延對GPU計算性能的影響。然而，這種額外的數據遷移過程會面臨如下問題。

● 把訓練數據復制到GPU節點的方式低效且難以管理。如果是手動復制，非常容易出錯。

● 深度學習訓練數量很大，且可能持續增加。“云上”GPU計算節點配置的磁盤容量有限，經常出現無法存放全量訓練數據的情況。

● 將訓練數據存放在多個GPU計算節點上的分布式存儲系統內，可以解決數據容量問題，但分布式存儲系統自身的運維成本和難度都很大；并且，存儲系統與計算節點耦合，本身也會產生計算、網絡、I/O等本地資源的爭搶和干擾問題。

3 基于分布式緩存的容器化深度學習模型訓練系統

業界已經有一些工作通過基于緩存機制的方法[1-3]來解決上述復制訓練數據到計算節點方案存在的問題。與這些工作不同，本文設計并實現了一種Kubernetes容器編排技術和分布式緩存技術相結合的深度學習模型訓練系統。該系統架構可以滿足云計算環境下大規模容器化深度學習系統對訓練任務的加速要求。該系統的基礎架構如圖1所示。

圖1 基于容器和分布式緩存的深度學習模型訓練系統的基礎架構

基于容器和分布式緩存的深度學習模型訓練系統架構的核心模塊包括如下幾個。

● Kubernetes。Kubernetes是業界非常主流的容器集群管理和編排引擎。其系統架構和API已經成為容器平臺的事實標準。Kubernetes非常廣泛地用于構建深度學習訓練平臺。它提供了通過容器兼容不同深度學習計算框架的靈活性，動態調度訓練任務和按需擴展GPU資源的能力，以及完善的集群管理能力。Kubernetes中最重要的子模塊是Kube-scheduler。該子模塊負責在Kubernetes容器集群中統一調度深度學習訓練任務和分布式緩存系統。本文通過擴展Kube-scheduler，實現了TDCS方法。

● Kubeflow。Kubeflow是Kubernetes技術生態中最流行的支持機器學習和深度學習任務的開源項目。Kubeflow的目標是使機器學習、深度學習的完整工作流程在Kubernetes集群上能夠簡便地部署、高效地運行，并且使整個工作流可移植和可擴展。Kubeflow為主流的深度學習框架TensorFlow[4-5]的分布式訓練提供了兩種支持模式，分別是參數服務器模式和Ring Allreduce[6]模式。Kubeflow同時支持訓練任務使用CPU和GPU運行。

● 分布式緩存系統。分布式緩存系統設計的初衷是解決大數據處理流水線中，不同計算框架在通過磁盤文件系統（如HDFS）交換數據時，系統I/O操作方面的瓶頸[7]。業界已存在一些用于實現分布式緩存系統的技術。本文設計的深度學習訓練系統選擇使用Alluxio作為分布式緩存技術的具體實現。Alluxio是面向混合云環境的開源數據編排與緩存系統[8]。它利用多個計算節點本地的內存和磁盤資源構成統一的分布式緩存系統，從而為計算任務提供就近、可重用的數據訪問服務。

為了提升深度學習的訓練性能，本文先對Alluxio進行系統參數調優，獲得初步的訓練加速效果。為了繼續將緩存加速效果擴展到更大規模的訓練場景，本文結合Kubernetes容器集群的調度和彈性伸縮能力、Alluxio緩存引擎的部署和運行機制，提出了一種訓練任務與緩存數據互感知的協同調度方法TDCS，并在容器化深度學習系統中進行實現。

TDCS通過多層資源分配策略來感知任務與數據間的關聯性，從而實現訓練任務和緩存數據的雙向親和性調度。通過感知任務運行時拓撲，實現彈性伸縮緩存容量和數據分布策略。在經典的圖像分類模型訓練實驗中，TDCS可以實現2~3倍的訓練加速，并且隨著計算資源的增加，TDCS能夠持續加速訓練任務。本文對使用128塊GPU卡的訓練任務進行實驗，發現TDCS依然帶來了可觀的性能提升。

4 初步優化分布式緩存加速訓練

使用分布式緩存加速諸如深度學習的大規模數據處理任務，在獲得性能提升的同時，會產生其他方面的問題，如整體成本的上升[9]、加速效果的波動等。本文實現了基于Kubernetes容器編排技術和Alluxio分布式緩存技術的深度學習訓練系統。實驗發現，Alluxio分布式緩存可以在一定條件下加速訓練任務。但在擴大任務規模、增加參與計算的GPU資源后，緩存加速效果很快達到瓶頸，無法隨資源量的增加而持續提升。如果要實現資源量和訓練任務性能的線性加速，則需要對緩存系統進行優化。

下面首先介紹使用Alluxio加速深度學習訓練任務的實驗方法；然后對實驗結果進行分析，提出影響加速效果的原因和優化手段，并驗證初步優化的結果。

4.1 實驗環境

本文使用阿里云托管Kubernetes服務，部署含有多個GPU節點的Kubernetes容器集群作為實驗環境。使用4臺服務器，每臺服務器上有8塊NVIDIA Tesla V100 GPU卡，共提供32塊GPU卡的算力。訓練程序通過Alluxio提供的POSIX接口讀取遠程數據存儲，并緩存到本地Alluxio緩存中。每臺服務器可為Alluxio提供40 GB內存存儲，實驗環境共提供160 GB分布式緩存空間。

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

4.2 實驗結果

對實驗中模型精確度達到業界標準情況下的訓練速度結果進行評估。分別使用合成數據（即synthetic）和Alluxio緩存系統訪問存儲服務中的真實數據（即Alluxio）進行模型訓練，并對比性能結果，如圖2所示。橫軸表示任務使用GPU卡數量，縱軸表示訓練速度。合成數據是訓練程序在內存中生成的數據，節省了I/O開銷，可作為訓練性能的理論上限。

由圖2可以看出，使用1~2塊GPU卡訓練時，兩者性能差距在可以接受的范圍內；但當GPU卡增加到4塊時，二者性能差距比較明顯；當GPU卡數量達到8塊時，使用Alluxio緩存系統訪問存儲服務中的數據的訓練速度下降至使用合成數據的28.77%。通過監控觀測到GPU服務器的系統資源利用率并不高，這說明使用Alluxio默認配置實現的分布式緩存系統無法支持GPU訓練規模化擴展。這成為深度學習訓練平臺能力的瓶頸。

通過分析Alluxio的系統架構和實現方法，發現造成無法支撐訓練任務性能彈性擴展的主要原因有如下3個。

● Alluxio的文件操作需要進行多次遠程過程調用（remote procedure call，RPC）才能獲取到數據。

● 默認情況下，Alluxio優先將全量數據緩存在本地節點。當本地緩存容量飽和時，就會驅逐已緩存數據。如果被驅逐數據很快又被任務讀回，就會導致同一份數據頻繁寫入和刪除，形成數據震蕩。

● 緩存系統提供的用戶空間文件系統（filesystem in userspace，FUSE）接口雖然易于使用，但是讀寫性能并不理想。在深度學習訓練任務多線程高并發讀寫下，需要優化FUSE的配置參數。

4.3 優化Alluxio系統參數

在分析了上述性能瓶頸后，本文首先調整一系列Alluxio系統參數。實驗結果表明，Alluxio緩存系統的性能得到一定程度的提升。

4.3.1 優化FUSE文件系統參數

Linux系統上的FUSE實現分為兩層，包括運行在用戶態的libfuse和運行在內核態的FUSE模塊。本文分別進行調優。第一個優化手段是升級Linux內核版本。高版本Linux系統內核對FUSE模塊內置了許多優化，比如Linux Kernel 4.19版的FUSE讀性能比3.10版提升20%。第二個優化手段是調整libfuse的參數，包括如下兩種。

● 增大參數entry_timeout和attr_timeout的值，避免libfuse本地讀取文件的inode和dentry信息頻繁過期，導致大量讀文件操作穿透到Alluxio的遠程元數據管理節點。

● 適當調大libfuse線程池參數max_idle_threads的值（默認為10），避免訓練任務高并發訪問緩存數據時，libfuse可用線程頻繁地創建和銷毀，引入過多CPU開銷。

4.3.2 優化Alluxio參數

深度學習訓練任務讀取的訓練數據量往往很大，并發壓力也非常大。本文針對緩存數據驅逐策略、元數據操作效率和容器環境下客戶端讀取緩存數據的方法，進行多組Alluxio系統參數配置。

第一組是參數優化，避免Alluxio頻繁驅逐緩存數據，造成數據震蕩，包括如下3種。

● alluxio.user.ufs.block.read.location.policy。默認值為alluxio.client.block.policy.LocalFirstPolicy，表示優先將數據保存在Alluxio客戶端節點。本文設置為alluxio.client.block.policy.LocalFirstAvoidEvictionPolicy。同時設置alluxio.user.block.avoid.eviction.policy.reserved.size.bytes參數，保證在節點本地固定保留適量緩存數據不被驅逐。

● alluxio.user.file.passive.cache.enabled。默認值為true，導致Alluxio節點額外復制已經在其他節點上緩存過的數據。本文將該屬性置為false，避免多余的本地緩存副本。

● alluxio.user.file.readtype.default。默認值為CACHE_PROMOTE，會導致緩存數據在節點的各存儲層間（如內存與磁盤）遷移。本文將該參數值改為CACHE，避免數據遷移和數據加鎖開銷。

第二組也是參數優化，配置Alluxio客戶端緩存遠程文件元數據的策略。客戶端緩存元數據信息，可避免頻繁地對Alluxio服務端進行RPC訪問，具體包括如下4種。

● alluxio.user.metadata.cache.enabled，設置為true，表示開啟客戶端元數據緩存。

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

● alluxio.user.metadata.cache.expiration.time，設置客戶端元數據緩存的有效時間。

● alluxio.user.worker.list.refresh.interval，設置Alluxio服務端同步所有緩存節點狀態的時間間隔，本文設為2 min。

第三組是配置容器本地訪問Alluxio緩存系統的方法。容器環境下Alluxio支持兩種短路讀寫方式來實現本地訪問緩存數據，包括UNIX Socket和直接文件訪問。本文使用直接文件訪問方式，使Alluxio客戶端讀取本地緩存節點的性能更優。

4.3.3 優化Alluxio容器中的JVM參數

通過Kubernetes部署Java應用容器，如果不指定容器請求的CPU資源量，容器內Java虛擬機（Java virtual machine，JVM）識別到的可用CPU核數可能有誤，進而影響容器內的Alluxio可用線程數。本文將JVM參數-XX:ActiveProcessorCount設置為容器內Alluxio進程可使用的CPU資源數量。

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

4.4 優化結果分析

優化上述系統參數后，在一臺配置8塊GPU卡的服務器上再次訓練ResNet50模型。如圖3所示，訓練速度明顯加快，與使用合成數據的訓練速度僅相差3.3%左右。并且，這樣的加速效果可以接近線性地擴展到4臺服務器（共32塊GPU卡）的實驗中。

圖3 優化分布式緩存系統加速分布式訓練的實驗結果

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

5 任務與數據協同調度——TDCS

目前，典型分布式緩存技術實現多用靜態架構進行部署，比如Alluxio。在初始化部署之后，緩存系統的拓撲和容量就固定了。在運行過程中，Alluxio不會主動對緩存數據的訪問頻率和系統資源的使用情況進行動態擴展，無法降低系統壓力。Alluxio也不會感知上層訪問應用，無法做到根據不同應用狀態和數據訪問特點同步調整緩存系統的部署拓撲和緩存策略。因此，在前面的實驗中，盡管優化Alluxio系統的參數后，可以加速最多使用32塊GPU卡的訓練任務，但是，增加更多GPU卡參與計算后，受到緩存系統靜態部署的限制，以及訓練任務運行拓撲動態變化的干擾，加速效果再次遇到瓶頸。

經過分析深度學習訓練任務的特點發現，一方面，在單個任務運行周期內以及多個任務運行過程之間，都存在計算與數據的時間相關性；另一方面，對于一個訓練任務使用的計算資源，可能會按需進行彈性伸縮。例如，當集群資源空閑時，可通過擴展利用更多GPU資源，加快訓練任務的整體進程；當集群資源緊張時，對低優先級任務進行資源回收。分布式緩存系統會優先部署在計算發生的本地節點上，通過就近讀取，節省大量遠程數據I/O損耗。這使得計算與緩存數據之間還存在空間相關性。

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

圖4 使用TDCS分布式緩存的容器化深度學習訓練系統架構

5.1 訓練數據預加載策略

對于單個訓練任務，通常以多輪迭代方式執行。訓練任務在給定數據集上循環執行算法，不斷調整參數，使得算法提取和比對特征的準確率最終達到目標。這種迭代執行具有明顯的時序特征。由于每輪迭代執行都會讀取全量訓練數據，各輪之間會有大量數據需重復計算。因此，通過分布式緩存，將盡可能多的訓練數據保存在計算節點本地，之后就可以避免每輪計算都反復從遠程存儲系統讀取數據造成的損耗。然而，對于首次執行的任務，還存在“冷啟動”問題。第一輪迭代周期內尚未有任何數據被緩存，執行計算的同時必須從遠程存儲系統中拉取所有訓練數據，性能明顯低于后續迭代。

針對“冷啟動”，TDCS設計實現了訓練數據集Preloader，負責在任務計算開始之前，預先讀取部分或者全部訓練數據進入緩存系統。TDCS允許使用者指定是否啟用預加載功能，以及預加載的具體策略。策略包括啟動預加載的時間、預加載數據量或其占整個訓練數據集的比例，以及預加載特定部分的訓練數據（如僅加載遠程文件系統中特定路徑下的數據）。

訓練平臺的用戶可以提交針對某個訓練數據集的預加載指令，Preloader響應并依據預加載策略，在計算啟動之前就開始將部分或者全部訓練數據拉取到分布式緩存系統中。預加載數據過程與用戶提交的訓練任務的執行是解耦的，可以完全串行，也可以部分并行。TDCS通過Preloader解決了單個訓練任務的“冷啟動”問題，保證整個訓練過程沒有明顯的讀取數據時延。

5.2 多任務緩存數據共享策略

深度學習在很多領域取得了非常好的效果，如圖像分類、物體檢測、自然語言理解等領域。一個領域內經常會有多種深度學習算法在演進。而訓練同一類領域模型的多種算法經常會使用同樣的數據集。比如，在視覺識別領域，幾乎所有深度學習算法會將ImageNet作為訓練數據的基線。對于同一種算法模型，也需要多次提交任務，使用同一份訓練數據反復實驗。依據每個任務的實驗結果，不斷調整模型結構和參數，最終得到表現穩定的模型版本。因此，在深度學習訓練平臺上，會有很多任務重復使用相同數據進行訓練。根據這些任務提交的時序特征，可在任務之間共享緩存數據，從而提升多個相關任務的性能。

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

TDCS的任務調度器Scheduler為T2分配計算節點的算法流程如下。這樣可以最大限度地保證T2計算與本地緩存數據的親和性。

● Scheduler查詢CacheManager后，得知集群中已存在數據集D1的緩存數據D1＇，且D1＇部署在節點集合S1上。

● Scheduler根據T2的計算資源要求，在集群中找到符合執行任務條件的備選節點集合S2，假設為{M1,M2,M3,M4,M5}。

● Scheduler計算集合S1與S2的交集，得到高優先級備選節點集合S3。

● Scheduler使用貪心算法，總是更多地選擇S3中的節點，并將其分配給任務T2。

在實現多任務共享緩存數據調度策略時，會存在“緩存熱點”和“緩存清理”問題。

● 緩存熱點：考慮到在特定時期有大量類似T2的任務需要幾乎同時執行，如果多個任務同時訪問緩存數據D1＇，會導致S1內節點的訪問壓力過大，使這些節點成為“熱點”。

● 緩存清理：考慮到計算節點本地內存和磁盤存儲容量有限，緩存數據D1＇勢必會從S1節點上被逐步驅逐，或者徹底刪除。任務T2的提交時刻tj不確定，導致緩存數據的利用率不穩定。極端情況下，每次T2被提交的時候，D1＇都已被刪除，緩存完全無法被多任務共享。

為了解決這兩個問題，TDCS設計實現了緩存數據管理器CacheManager，負責根據用戶指定策略，管理對緩存數據的訪問和清理緩存數據。

首先，CacheManager控制緩存數據D1＇的并發訪問數上限。用戶可以選擇配置應對并發任務數超過限制的策略。不同于參考文獻[13]提出的優化緩存系統內部數據分布算法的方法，以及參考文獻[14]提出的利用存儲系統中數據塊間的關聯性指導Alluxio緩存策略CPR（cache prefet repace），TDCS避免侵入修改分布式緩存引擎，而選擇在其外部增加控制訪問緩存任務量和緩存供給量的邏輯，實現緩存負載穩定和均衡。由CacheManager與Scheduler配合，動態調整超限并發任務的資源分配，以及緩存數據副本數量。為此，CacheManager提供了Suspend和Clone兩種策略。

● Suspend：表示暫時掛起新任務對D1＇的訪問。此時，CacheManager會通知Scheduler，將超限任務放入等待隊列。當并發訪問D1＇的任務數量降到上限以內時，CacheManager會通知Scheduler將等待隊列中的任務移出隊伍，將其盡量調度到D1＇所在的節點上。

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

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

用戶可以根據計算節點的可用存儲資源量、任務提交計劃、多任務的相關性等因素，配置清理策略。例如，在特定時段，存在許多使用相同訓練數據的任務需要執行，為了保證總是有緩存數據用于加速訓練計算讀取，可以選擇不清理緩存，也可以選擇定時清理，具體時間間隔可以根據任務執行計劃和可用存儲資源量來設置。而對于集群中存在多個訓練數據集的緩存情況，可以選擇CacheManager按照LRU算法，優先清理最近最少訪問的緩存數據。還可以擴展CacheManager模塊，以支持更多復雜的緩存清理策略，比如參考文獻[15]提出的兼顧最近訪問時間和歷史訪問頻率的緩存替換策略等。

5.3 分布式緩存彈性策略

通常訓練平臺內會有很多任務同時運行，它們共享了集群計算資源，尤其是寶貴的GPU資源。為了提升GPU利用率，訓練平臺調度器會動態調整分配給任務的GPU資源。例如，回收低優先級任務占用的部分GPU節點，將其分配給高優先級任務。訓練過程中，任務需要具有彈性伸縮的能力。為高優先級任務動態分配更多計算節點時，若將分布式緩存系統彈性擴展到這些新增節點上，則可以擴大緩存總容量，進而支撐更大規模的并發讀取，提升任務整體的訓練性能。

TDCS設計了CacheScaler，負責彈性擴展、收縮分布式緩存系統，使緩存系統的部署位置與訓練任務的運行節點保持同步，保證計算所需緩存數據總是在本地就可讀取。CacheScaler可通過如下3種觸發方法來彈性伸縮分布式緩存系統。

● API觸發伸縮活動。用戶可以調用CacheScaler的API，主動觸發擴展和收縮緩存。

● 事件觸發伸縮活動。CacheScaler通過事件訂閱機制，發現、響應訓練任務的計算資源量變化事件，自動觸發擴展和收縮緩存。

● 監控觸發伸縮活動。本文的訓練平臺基于Kubernetes容器編排和管理技術構建。利用集群監控系統，根據監控指標的變化情況，調用Kubernetes的HPA（horizontal pod autoscaler）組件，主動伸縮緩存系統。典型的監控指標是緩存系統容量使用率。當緩存系統容量使用率（即緩存數據量的占比）達到給定閾值時，就會自動觸發擴展緩存；反之，當緩存系統容量使用率長期保持低水平時，可以選擇通過HPA觸發收縮緩存。

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

6 TDCS實驗結果

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

圖5 使用TDCS協同調度分布式緩存加速ResNet50模型訓練的實驗結果對比

配置1：不使用緩存，任務直接讀取遠程OSS數據。

配置2：使用默認配置Alluxio讀取OSS數據。

配置3：在配置2的基礎上增加TDCS訓練數據預加載策略。

配置4：在配置3的基礎上增加TDCS多任務緩存數據共享策略。

其中，使用配置3、4的實驗中，都使用了TDCS分布式緩存彈性策略。

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

7 結束語

本文針對云環境下，計算、存儲分離架構帶來的數據讀取性能瓶頸問題，提出基于分布式緩存結合Kubernetes容器技術加速深度學習訓練的方法和架構。在應用Alluxio分布式緩存系統，并進行Alluxio系統參數優化后，獲得初步的訓練加速效果。受限于Alluxio靜態部署的系統架構，加速效果無法擴展到大規模分布式訓練任務，進而提出TDCS訓練任務與緩存數據協同調度方法和其在Kubernetes容器集群架構下的系統實現。通過增加訓練數據預加載策略、多任務緩存數據共享策略以及分布式緩存彈性策略，TDCS可以保證在容器環境下給深度學習訓練任務帶來2~3倍的加速，并且加速效果可以擴展到使用128塊NVIDIA GPU卡的大規模分布式訓練場景。