深度學(xué)習(xí)云服務(wù)適配問題研究

林健 謝冬鳴 余波

摘要：深度學(xué)習(xí)技術(shù)是支撐眾多人工智能應(yīng)用的基礎(chǔ)，云服務(wù)是當(dāng)今主流的計算能力供給模式。以云服務(wù)方式提供深度學(xué)習(xí)能力廣受關(guān)注，構(gòu)建這類服務(wù)的關(guān)鍵在于深度學(xué)習(xí)業(yè)務(wù)向云服務(wù)模式適配，具體涉及作業(yè)調(diào)度、存儲接入和資源管理等方面的兼容性問題與適配型特性研發(fā)。OMAI深度學(xué)習(xí)平臺將深度學(xué)習(xí)業(yè)務(wù)云服務(wù)化，通過作業(yè)調(diào)度中間層抽象、異構(gòu)存儲容器內(nèi)掛載、資源表達(dá)式匹配等機制，有效解決了深度學(xué)習(xí)業(yè)務(wù)的云服務(wù)適配問題.OMAI為人工智能云服務(wù)研發(fā)提供指導(dǎo)思路。

關(guān)鍵詞：深度學(xué)習(xí);人工智能;云服務(wù);高性能計算;平臺軟件

DOI：10.11907/rjdk.201139開放科學(xué)（資源服務(wù)）標(biāo)識碼（OSID）：

中圖分類號：TP301文獻(xiàn)標(biāo)識碼：A 文章編號：1672-7800（2020）006-0001-08

0 引言

深度學(xué)習(xí)技術(shù)作為人工智能領(lǐng)域的基礎(chǔ)性技術(shù)，為互聯(lián)網(wǎng)、金融、安全、教育、醫(yī)療等領(lǐng)域的眾多應(yīng)用提供技術(shù)支撐。近年來，深度學(xué)習(xí)云服務(wù)開始在各大云計算平臺涌現(xiàn)，這是因為云服務(wù)模式能夠解決深度學(xué)習(xí)技術(shù)門檻高、資源消耗多、需求波動大等問題，同時也體現(xiàn)出深度學(xué)習(xí)的業(yè)務(wù)需求具有一定的共通性和迫切性。然而，深度學(xué)習(xí)和云計算兩個領(lǐng)域有其各自的發(fā)展軌跡，將深度學(xué)習(xí)平臺作為一種云服務(wù)運行于云計算環(huán)境，勢必遇到一系列有待適配的技術(shù)缺口及需要解決的工程問題。

公有云或私有云平臺研發(fā)者已經(jīng)或多或少地注意到這些問題并提出了解決方案，多種深度學(xué)習(xí)云服務(wù)的出現(xiàn)就是例證。然而，多數(shù)云服務(wù)由商業(yè)巨頭開發(fā)，且存在軟件架構(gòu)遷就市場需求等現(xiàn)實問題，因此深度學(xué)習(xí)業(yè)務(wù)的云服務(wù)適配問題并沒有系統(tǒng)地梳理和總結(jié)。本文基于對現(xiàn)有深度學(xué)習(xí)平臺的分析，闡述了深度學(xué)習(xí)在云服務(wù)適配時可能遇到的問題，并對現(xiàn)有解決方案進(jìn)行歸納整理，期望這些工作對未來深度學(xué)習(xí)云服務(wù)的研發(fā)提供有益啟發(fā)及幫助。

本文提出OMAI（Oriental Mind Artificial Intelligence）深度學(xué)習(xí)平臺。OMAI深度學(xué)習(xí)平臺是一套以高性能計算（High Performance Computing，HPC）為特色，涵蓋人工智能業(yè)務(wù)全流程的一站式平臺軟件，支持一體機、局域網(wǎng)、私有云與公有云部署。針對云服務(wù)適配，OMAI平臺提出了作業(yè)調(diào)度中間層抽象、異構(gòu)存儲容器內(nèi)掛載、資源表達(dá)式匹配等諸多機制，解決作業(yè)調(diào)度、存儲接人和資源管理等不同的技術(shù)問題，構(gòu)建一套系統(tǒng)化解決方案。

1 深度學(xué)習(xí)業(yè)務(wù)及其云服務(wù)特點

本文從深度學(xué)習(xí)運行時特征、服務(wù)化模式和云服務(wù)現(xiàn)狀等角度介紹深度學(xué)習(xí)業(yè)務(wù)及其云服務(wù)特點。

1.1 深度學(xué)習(xí)運行時特征

深度學(xué)習(xí)業(yè)務(wù)分為研發(fā)層業(yè)務(wù)與應(yīng)用層業(yè)務(wù)。前者指面向神經(jīng)網(wǎng)絡(luò)算法或人工智能應(yīng)用的研發(fā)人員提供硬件、軟件、算法、算力等基礎(chǔ)設(shè)施服務(wù)的業(yè)務(wù);后者指面向大眾消費者或特定行業(yè)技術(shù)人員等最終用戶，提供端到端應(yīng)用服務(wù)的業(yè)務(wù)。研發(fā)層業(yè)務(wù)全生命周期包括算法開發(fā)、模型訓(xùn)練、訓(xùn)練過程可視化、模型驗證、服務(wù)發(fā)布、數(shù)據(jù)推理等環(huán)節(jié);應(yīng)用層業(yè)務(wù)的全生命周期則以數(shù)據(jù)推理為核心，輔以模型增量訓(xùn)練等可選環(huán)節(jié)，以及前端界面、模型市場等周邊服務(wù)。研發(fā)層業(yè)務(wù)的云服務(wù)適配問題，本質(zhì)上是深度學(xué)習(xí)平臺軟件的上云問題，其涉及技術(shù)面廣、代表性強，能夠涵蓋應(yīng)用層業(yè)務(wù)的核心環(huán)節(jié)，因此本文的研究對象以研發(fā)層業(yè)務(wù)為主。

深度學(xué)習(xí)業(yè)務(wù)特征可從不同維度進(jìn)行分類。考慮云服務(wù)場景的分類標(biāo)準(zhǔn)是業(yè)務(wù)的運行時特征，即運行模式。云計算環(huán)境中最常見的兩種運行模式是微服務(wù)與批處理作業(yè)。表1給出深度學(xué)習(xí)業(yè)務(wù)各個環(huán)節(jié)的運行實體本質(zhì)及歸屬運行模式，前述流程中的服務(wù)發(fā)布環(huán)節(jié)屬于微服務(wù)的創(chuàng)建過程，無須分類單列。

（1）微服務(wù)模式。算法開發(fā)、訓(xùn)練過程可視化、在線模型驗證和數(shù)據(jù)推理屬于微服務(wù)模式，本質(zhì)上是Web、REST或RPC服務(wù)，一般具有無狀態(tài)特征，抑或是將狀態(tài)持久化保存于外部存儲器件。其生命周期長度取決于用戶的主觀需求，理論上可以無限長。盡管微服務(wù)可通過自包含或中間件方式獨立運行，然而為了可管理性、可伸縮性和容錯性等目標(biāo)，實際場景下通常使用基于虛擬機、容器或無服務(wù)器（Serveless）技術(shù)的微服務(wù)調(diào)度與編排軟件進(jìn)行管理。

（2）批處理作業(yè)模式。模型訓(xùn)練、離線模型驗證和數(shù)據(jù)推理屬于批處理作業(yè)模式。它們本質(zhì)上是普通進(jìn)程，或為原生（native）進(jìn)程，或基于Python等語言解釋器;一般帶有狀態(tài)，在內(nèi)存或顯存中維護當(dāng)前階段的運行時信息。其生命周期長度取決于算法、算力、數(shù)據(jù)集大小等因素，一般情況為有限長，除非人為控制。盡管普通進(jìn)程可以獨立運行，然而為了可管理性、執(zhí)行效率、資源利用率等目標(biāo)，實際場景下通常使用批處理作業(yè)調(diào)度軟件管理，這也是“批處理作業(yè)”模式名稱的由來。

1.2 深度學(xué)習(xí)服務(wù)化模式

當(dāng)一個組織內(nèi)部的基礎(chǔ)設(shè)施、應(yīng)用與用戶數(shù)量日益增長，或者打算提供對外服務(wù)時，軟件的服務(wù)化就不可避免。深度學(xué)習(xí)業(yè)務(wù)的兩種運行模式均可采用多種不同的服務(wù)化模式。微服務(wù)天然是為服務(wù)化設(shè)計的，傳統(tǒng)上為Web應(yīng)用或SOA（Services Oriented Architecture）中間件設(shè)計微服務(wù)調(diào)度編排軟件，對深度學(xué)習(xí)業(yè)務(wù)中的微服務(wù)環(huán)節(jié)也適用。盡管不同的調(diào)度編排軟件及運行環(huán)境（虛擬機、容器或無服務(wù)器架構(gòu)）在云服務(wù)適配開發(fā)方面存在差異，但研發(fā)層業(yè)務(wù)用戶可見的只是Web、REST或RPC接口，上述軟件和環(huán)境對用戶完全透明，其選型基本不影響服務(wù)體驗。因此，微服務(wù)的服務(wù)化模式不是研究重點，這里不展開說明。

相比之下，批處理作業(yè)的服務(wù)化問題較為復(fù)雜。其核心原因在于：多數(shù)深度學(xué)習(xí)引擎以開發(fā)庫（library）的形式發(fā)布，將運行時的控制權(quán)完全交給上層開發(fā)者，不提供面向服務(wù)化的運行時控制框架（調(diào)度框架）。這使得批處理作業(yè)的服務(wù)化工作必須補齊運行時控制的短板。運行時控制框架的設(shè)計或選型，既影響深度學(xué)習(xí)云服務(wù)的整體架構(gòu)，又在一定程度上對研發(fā)層業(yè)務(wù)相關(guān)，因此成為深度學(xué)習(xí)服務(wù)化模式研究的重點。表2給出深度學(xué)習(xí)批處理作業(yè)中常見服務(wù)化模式所使用的調(diào)度框架及主要適用場景。

（1）大數(shù)據(jù)調(diào)度框架。大數(shù)據(jù)調(diào)度框架以Apache生態(tài)中的MapReduce、YARN調(diào)度框架為代表，其特點在于生態(tài)成熟，與大數(shù)據(jù)組件的交互性好，易于構(gòu)建以數(shù)據(jù)為中心的工作流;可伸縮性和容錯性設(shè)計較為完善，適合在已有的大數(shù)據(jù)集群上部署?；谶@類框架的深度學(xué)習(xí)典型案例包括Yahoo！開源的TensorFlowOnSpark、Databricks發(fā)布的Spark Deep Learning，以及多種商業(yè)數(shù)據(jù)分析平臺軟件中的深度學(xué)習(xí)功能。

（2）高性能調(diào)度框架。以HPC生態(tài)中常見的Slurm、PBS調(diào)度器為代表。它們與高性能計算、通信及存儲組件的交互性好，貼合深度學(xué)習(xí)訓(xùn)練對大規(guī)模矩陣運算及分布式通信的需求，特別適合基于MPI優(yōu)化的深度學(xué)習(xí)引擎。其穩(wěn)定性和可擴展性在大規(guī)模超算環(huán)境下得以驗證，適合在已有的超算基礎(chǔ)設(shè)施上部署。包括Amazon高性能計算服務(wù)（AWS HPC）、中國科技云人工智能平臺在內(nèi)的超算服務(wù)，均提供基于此類框架的深度學(xué)習(xí)解決方案。

（3）容器化調(diào)度框架。容器化調(diào)度框架以踐行“云原生”（cloud native）理念的Kubernetes、Mesos DC/OS平臺軟件為代表。這類框架專門針對云服務(wù)的需求和特點設(shè)計，與云服務(wù)基礎(chǔ)設(shè)施的交互性好，為業(yè)務(wù)上云帶來很大便利。資源彈性與容錯性是其主要優(yōu)勢，適合在已有的云計算環(huán)境中部署。這類框架的代表性深度學(xué)習(xí)解決方案有Kubeflow、Volcano等開源項目，多數(shù)公有云深度學(xué)習(xí)服務(wù)也選擇了容器化路線。

1.3 深度學(xué)習(xí)云服務(wù)現(xiàn)狀

近年來，人工智能的發(fā)展，催生了大量面向研發(fā)層業(yè)務(wù)的深度學(xué)習(xí)平臺軟件，部分軟件支持云服務(wù)工作方式。為了歸納云服務(wù)特點以及分析深度學(xué)習(xí)業(yè)務(wù)的云服務(wù)適配問題，有必要對它們加以分類總結(jié)。本文采用云服務(wù)形態(tài)及定位兩種分類維度。形態(tài)依服務(wù)受眾可分為公有云服務(wù)和私有云服務(wù)，定位則與該服務(wù)的產(chǎn)品設(shè)計及發(fā)展歷程相關(guān)。表3為在此標(biāo)準(zhǔn)下各類深度學(xué)習(xí)云服務(wù)的典型代表。

（1）公有云服務(wù)。公有云服務(wù)通過互聯(lián)網(wǎng)面向公眾提供服務(wù)。深度學(xué)習(xí)服務(wù)在公有云上一般處于SaaS層（開發(fā)工具）和PaaS層（能力集成）。深度學(xué)習(xí)公有云服務(wù)除面臨多租戶安全隔離、彈性伸縮與成本控制等公有云通用問題外，還需要解決專用硬件接人和復(fù)用等特有問題。

（2）私有云服務(wù)。私有云服務(wù)部署在組織內(nèi)部，面向特定群體提供服務(wù)。深度學(xué)習(xí)服務(wù)在私有云中的安全性要求一般低于公有云，網(wǎng)絡(luò)管理策略也相對簡單。然而，私有云的資源限制導(dǎo)致其具有接人外部資源、構(gòu)建混合云的需求，同時私有云往往涉及適配企業(yè)特有的組織構(gòu)架與工作流程。

（3）以深度學(xué)習(xí)為核心的專業(yè)化人工智能服務(wù)。此類服務(wù)聚焦深度學(xué)習(xí)領(lǐng)域，在覆蓋深度學(xué)習(xí)業(yè)務(wù)全流程的同時力圖將局部技術(shù)點（如自動學(xué)習(xí)、算法模型庫）做深做精。盡管其也支持傳統(tǒng)機器學(xué)習(xí)及一定的數(shù)據(jù)處理功能，但往往不作為重點。此類服務(wù)一般以作業(yè)表單或RES了接口方式與用戶交互，通常為用戶提供較高的自由度，支持訓(xùn)練和部署自定義的算法模型。

（4）帶有深度學(xué)習(xí)能力的綜合型人工智能服務(wù)。此類服務(wù)更關(guān)注業(yè)務(wù)覆蓋的廣度，力圖滿足應(yīng)用對人工智能技術(shù)的全方位需求，因此還包含傳統(tǒng)機器學(xué)習(xí)、數(shù)據(jù)處理、服務(wù)編排、DevOps流程等服務(wù)。此類服務(wù)的用戶交互形式比較多樣化，以便適應(yīng)人工智能領(lǐng)域不同細(xì)分業(yè)務(wù)特點。前兩類人工智能服務(wù)大多屬于獨立規(guī)劃與演進(jìn)的產(chǎn)品。

（5）帶有深度學(xué)習(xí)能力的數(shù)據(jù)分析服務(wù)。此類服務(wù)通常在數(shù)據(jù)分析平臺基礎(chǔ)上發(fā)展而來。傳統(tǒng)的數(shù)據(jù)分析平臺一般支持統(tǒng)計分析或機器學(xué)習(xí)方法。深度學(xué)習(xí)技術(shù)在補充其分析能力的同時，也具備一定的獨立工作能力。此類服務(wù)往往繼承了數(shù)據(jù)分析平臺的工作流拖拽或筆記本交互使用模式，其算法模型一般以平臺預(yù)置為主，對自定義程序的支持相對較弱。

（6）帶有深度學(xué)習(xí)能力的高性能計算服務(wù)。此類服務(wù)通常是在高性能計算作業(yè)管理軟件基礎(chǔ)上發(fā)展而來。相比前幾類覆蓋深度學(xué)習(xí)業(yè)務(wù)多環(huán)節(jié)的服務(wù)，高性能計算服務(wù)一般只聚焦模型訓(xùn)練環(huán)節(jié)，以便充分利用超算硬件資源。此類服務(wù)普遍會繼承高性能計算領(lǐng)域以作業(yè)腳本或表單為主的交互方式，支持用戶提交自定義程序，且有較為嚴(yán)格的安全約束。

2 深度學(xué)習(xí)業(yè)務(wù)的云服務(wù)適配問題

從深度學(xué)習(xí)業(yè)務(wù)特點可以看出，并非所有業(yè)務(wù)環(huán)節(jié)均能精確適配云服務(wù)。深度學(xué)習(xí)的典型服務(wù)化模式也表明，并非所有服務(wù)化場景均具有“云原生”特征。從現(xiàn)有深度學(xué)習(xí)云服務(wù)實踐可知，每款產(chǎn)品均有其設(shè)計取舍。因此，深度學(xué)習(xí)業(yè)務(wù)的云服務(wù)適配是一類綜合性問題，尚不存在完美的解決方案。本文對這類問題進(jìn)行系統(tǒng)性梳理，總結(jié)出其中3個主要問題——作業(yè)調(diào)度、存儲接人和資源管理，并對問題的本質(zhì)及相關(guān)研究成果進(jìn)行綜述。

2.1 作業(yè)調(diào)度問題

作業(yè)調(diào)度問題同批處理作業(yè)特性以及Python或原生進(jìn)程的需求相關(guān)，這里分為運行模式適配和運行環(huán)境依賴兩個子問題加以討論。

2.1.1 運行模式適配

深度學(xué)習(xí)模型訓(xùn)練等核心環(huán)節(jié)的運行模式是批處理作業(yè)，典型的進(jìn)程形態(tài)是Python或原生進(jìn)程。然而，經(jīng)典的云服務(wù)不能完全滿足其需求，具體表現(xiàn)在：①彈性Ma-pReduce等大數(shù)據(jù)服務(wù)（如AWS EMR）雖然支持批處理作業(yè)調(diào)度，但主要服務(wù)于Java組件，存在安全沙箱等限制PY-thon或原生進(jìn)程的設(shè)計;②容器實例或容器集群服務(wù)（如阿里云ECI）雖然與一些深度學(xué)習(xí)引擎主推的容器化運行模式一致，但它們?yōu)闊o狀態(tài)的微服務(wù)設(shè)計，不支持群調(diào)度（gang-scheduling）等批處理專有特性，因而無法滿足分布式訓(xùn)練需求;③基于容器的批處理服務(wù)（如Azure Batch）最大程度上滿足了容器化與批處理兩大需求，但仍存在分布式命令行參數(shù)配置復(fù)雜、進(jìn)程行為控制語義薄弱等細(xì)節(jié)問題。

2017年以前，多數(shù)廠商選擇自研深度學(xué)習(xí)批處理作業(yè)調(diào)度機制，如IBM PowerAI等脫胎于大數(shù)據(jù)系統(tǒng)的產(chǎn)品選擇在Spark等大數(shù)據(jù)框架基礎(chǔ)上構(gòu)建深度學(xué)習(xí)支持能力，而大多數(shù)公有云深度學(xué)習(xí)服務(wù)選擇在Kubernetes等容器平臺上開發(fā)批處理作業(yè)調(diào)度。2017年以后，隨著Kubeflow和Volcano兩個開源項目的發(fā)布，容器化與批處理結(jié)合領(lǐng)域有了公認(rèn)的解決方案，二者均通過Kubernetes的operator機制實現(xiàn)批處理作業(yè)的封裝和抽象，并通過scheduler機制實現(xiàn)群調(diào)度等運行時的行為控制。主要不同點在于：Kubeflow傾向于提供高層次封裝，且面向深度學(xué)習(xí)全流程設(shè)計;Volcano傾向于提供細(xì)粒度工具，且針對多種批處理調(diào)度場景設(shè)計。

相對于基于大數(shù)據(jù)和容器化框架的運行模式適配機制，基于高性能框架的工作比較小眾。這與超算環(huán)境受眾面小、從業(yè)人員動手能力較強有關(guān)。AWS HPC和中國科技云提供的深度學(xué)習(xí)能力，本質(zhì)上是幫助用戶自動創(chuàng)建批處理腳本，但后續(xù)操作仍需要使用傳統(tǒng)作業(yè)管理命令或界面。隨著人工智能業(yè)務(wù)的增長以及高性能計算技術(shù)向深度學(xué)習(xí)的滲透，高性能調(diào)度框架在深度學(xué)習(xí)領(lǐng)域的應(yīng)用價值逐漸顯現(xiàn)，這一趨勢值得云服務(wù)開發(fā)者關(guān)注。

2.1.2 運行時環(huán)境依賴

深度學(xué)習(xí)領(lǐng)域的快速發(fā)展導(dǎo)致深度學(xué)習(xí)引擎、算法開發(fā)庫的演進(jìn)迅速，依賴關(guān)系復(fù)雜多變，它們對操作系統(tǒng)、編程語言及系統(tǒng)開發(fā)庫的依賴也瞬息萬變。深度學(xué)習(xí)的3種服務(wù)化模式普遍選擇使用容器技術(shù)（Docker和Singularity）解決。容器使得作業(yè)進(jìn)程包含上下文環(huán)境，避免管理復(fù)雜的環(huán)境依賴項。然而容器技術(shù)并非萬能，考慮云服務(wù)下的作業(yè)動態(tài)調(diào)度場景，簡單使用容器存在以下問題：

（1）開發(fā)庫與驅(qū)動程序耦合。并非所有開發(fā)庫都可通過容器實現(xiàn)與宿主環(huán)境的完全解耦，如CUDA、OFED等面向特定硬件的開發(fā)庫就與宿主環(huán)境中的驅(qū)動程序存在版本依賴。以CUDA為例，NVIDIA GPU Cloud發(fā)布的鏡像一般內(nèi)置CUDA，通過定期升級宿主環(huán)境驅(qū)動程序的方法確保對新版CUDA兼容，同時逐步放棄舊版支持;另有一些公有云將不同版本的CUDA同時安裝于宿主環(huán)境，由容器選擇性掛載。兩種方案在解決耦合問題時沒有本質(zhì)區(qū)別，區(qū)別只在于問題的歸屬者。

（2）鏡像體積與拉取性能權(quán)衡。將更多的運行時依賴項置于容器鏡像內(nèi)部，就意味著作業(yè)調(diào)度時需要拉取更大的文件，這將對作業(yè)啟動性能造成顯著影響。除了對CUDA等體積較大、演進(jìn)穩(wěn)定的開發(fā)庫實施上述掛載方案外，業(yè)界常用的優(yōu)化方案還包括定期在宿主節(jié)點上拉取常用基礎(chǔ)鏡像或鏡像的公共層，以及P2P等優(yōu)化傳輸方案。

（3）作業(yè)內(nèi)進(jìn)程間依賴項的差異。同一分布式作業(yè)的不同進(jìn)程（容器）間存在環(huán)境依賴項差異。以MXNet引擎的典型分布式作業(yè)為例，Master進(jìn)程只需要最簡單的PYthon環(huán)境，Server進(jìn)程依賴更多Python開發(fā)庫，Worker進(jìn)程在此基礎(chǔ)上還依賴CUDA。對3種進(jìn)程統(tǒng)一使用完整的鏡像勢必造成資源浪費和性能損失。業(yè)界常用的優(yōu)化方案包括為每種進(jìn)程開發(fā)不同的鏡像，或是將不同進(jìn)程按特定規(guī)則合并到同一容器中執(zhí)行。

2.2 存儲接入問題

存儲接人問題來源于深度學(xué)習(xí)作業(yè)對算法、模型、數(shù)據(jù)集等云上數(shù)據(jù)資產(chǎn)的訪問，這里分為存儲類型匹配和存儲跨域訪問兩個子問題討論。

2.2.1 存儲類型匹配

深度學(xué)習(xí)作業(yè)要訪問云上的數(shù)據(jù)資產(chǎn)，其前提是深度學(xué)習(xí)引擎、運行時控制框架以及云存儲服務(wù)三者支持的存儲類型存在交集。存儲類型按接口類型劃分，包括POSIX存儲（如本地文件系統(tǒng)、網(wǎng)絡(luò)文件系統(tǒng)）、對象存儲（如AWS S3）、專有接口存儲（如HDFS）等。

（1）深度學(xué)習(xí)引擎方面，TensorFlow通過通用的I/O中間層支持多種存儲類型，而PyTorch對非POSIX存儲支持有限，需要借助第三方庫實現(xiàn)。

（2）運行時控制框架方面，大數(shù)據(jù)調(diào)度框架一般不干涉存儲，而由應(yīng)用直接訪問存儲;容器化調(diào)度框架則普遍提供對特定類型存儲的容器內(nèi)掛載機制。

（3）云存儲服務(wù)方面，基于POSIX接口的本地文件系統(tǒng)、網(wǎng)絡(luò)文件系統(tǒng)以及類AWS S3接口的對象存儲幾乎是云平臺標(biāo)配，專有接口存儲也在部分大數(shù)據(jù)云服務(wù)中常見。

深度學(xué)習(xí)云服務(wù)開發(fā)者必須合理抉擇上述三者的交集，才能讓作業(yè)訪問云存儲變得可行和高效。幾類備選存儲的特征分析如下：①本地文件系統(tǒng)。它是必然可行的選擇，也是線下環(huán)境的首選。然而在容器化環(huán)境中，本地文件系統(tǒng)的生命周期與容器相同，外部交互依賴于消耗時間空間的上傳下載操作。同時，云服務(wù)也強調(diào)以數(shù)據(jù)為中心的交互，本地文件系統(tǒng)會割裂數(shù)據(jù)在服務(wù)間的復(fù)用;②網(wǎng)絡(luò)文件系統(tǒng)（Network File System，NFS）。其可行性取決于運行時控制框架的支持程度，以Kubernetes為代表的容器化調(diào)度框架支持NFS掛載。但NFS在云環(huán)境中存在續(xù)跨域訪問問題，需要開發(fā)者注意;③對象存儲系統(tǒng)。REST接口的對象存儲系統(tǒng)無須掛載即可使用，因此其可行性與運行控制框架無關(guān)，主要取決于深度學(xué)習(xí)引擎。不同于語義完備的POSIX存儲，對象存儲一般只支持順序訪問。這對其適用的數(shù)據(jù)資產(chǎn)類型造成限制，好在深度學(xué)習(xí)業(yè)務(wù)的常見資產(chǎn)訪問操作不會超越順序訪問;④HDFS。其最大優(yōu)勢在于與Apache生態(tài)的大數(shù)據(jù)服務(wù)交互性好。HDFS的REST接口和順序訪問語義使其優(yōu)缺點與對象存儲類似，但亦存在跨域訪問問題。

在當(dāng)前公有云深度學(xué)習(xí)服務(wù)中，對象存儲系統(tǒng)是主流。針對不支持對象存儲的深度學(xué)習(xí)引擎，業(yè)界常用的解決方案包括在算法代碼中調(diào)用第三方客戶端、在深度學(xué)習(xí)引擎中添加訪問支持，或在運行時控制框架層面實現(xiàn)文件系統(tǒng)掛載。在一些由數(shù)據(jù)分析平臺演進(jìn)而來的深度學(xué)習(xí)服務(wù)中，HDFS是主流，它們也常使用上述3種方法解決接口匹配問題。而在基于高性能計算集群的深度學(xué)習(xí)服務(wù)中，NFS及其它兼容POSIX接口的全局文件系統(tǒng)是主流，這與其固有的軟件生態(tài)相適應(yīng)。

2.2.2 存儲跨域訪問

深度學(xué)習(xí)業(yè)務(wù)訪問存儲服務(wù)時，需要考慮網(wǎng)絡(luò)互通性。在單一局域網(wǎng)環(huán)境下，用戶和開發(fā)者往往體會不到網(wǎng)絡(luò)互通性對存儲服務(wù)的影響，但在云服務(wù)環(huán)境下這一問題突顯。私有云通常將用戶和服務(wù)所在的局域網(wǎng)分設(shè)，用戶需通過網(wǎng)關(guān)訪問包括存儲在內(nèi)的服務(wù)。公有云的情況更為復(fù)雜，服務(wù)基礎(chǔ)設(shè)施一般會按功能、地域和安全級別劃分為多個局域網(wǎng)，網(wǎng)間路由與安全策略各異。網(wǎng)關(guān)機制不僅存在于用戶與服務(wù)之間，還存在于各個服務(wù)組件之間。無論公有云還是私有云，用戶的業(yè)務(wù)一般運行在名為“虛擬專有云”（Virtual Private Cloud，VPC）的局域網(wǎng)中，進(jìn)一步增加了網(wǎng)絡(luò)環(huán)境的復(fù)雜性。深度學(xué)習(xí)服務(wù)與存儲服務(wù)在這種跨多網(wǎng)絡(luò)環(huán)境下的交互，即構(gòu)成存儲跨域訪問。

多數(shù)公有云的對象存儲系統(tǒng)已經(jīng)隱式解決了存儲跨域訪問問題，其實現(xiàn)原理是在云環(huán)境內(nèi)部不同局域網(wǎng)及互聯(lián)網(wǎng)的DNS服務(wù)器上為對象存儲系統(tǒng)的域名設(shè)置不同的解析目標(biāo)，使其指向本域可達(dá)的網(wǎng)關(guān)服務(wù)器。由于對象存儲一般基于REST接口，普通的Web網(wǎng)關(guān)即可實現(xiàn)此功能。深度學(xué)習(xí)云服務(wù)組件可以從云環(huán)境內(nèi)部的任意局域網(wǎng)、VPC或者互聯(lián)網(wǎng)直接訪問對象存儲，簡化了服務(wù)開發(fā)，故其是多數(shù)深度學(xué)習(xí)云服務(wù)優(yōu)先支持對象存儲的原因。不過，在公有云中使用對象存儲系統(tǒng)還需要注意地域（region）概念，并非所有的公有云都支持地域無關(guān)的統(tǒng)一訪問人口及跨地域的數(shù)據(jù)訪問，深度學(xué)習(xí)云服務(wù)在這類公有云中一般要求為每地域一實例。

NFS、HDFS及其它面向局域網(wǎng)設(shè)計的全局文件系統(tǒng)在云環(huán)境下需要綁定到特定VPC，不支持隱式跨域訪問。在實現(xiàn)深度學(xué)習(xí)云服務(wù)時對服務(wù)組件（運行于服務(wù)VPC內(nèi)的主機）訪問用戶數(shù)據(jù)（位于用戶VPC內(nèi)的存儲）帶來了障礙。為解決這一問題，可以采取VPC對等連接或其它等價方式，實現(xiàn)跨VPC網(wǎng)絡(luò)互通。同時，用戶的VPC一般無法從互聯(lián)網(wǎng)直接訪問，這就需要云服務(wù)顯式設(shè)計存儲訪問機制，將存儲請求通過層層網(wǎng)關(guān)轉(zhuǎn)發(fā)到用戶的VPC中。此類設(shè)計對用戶暴露的概念和操作相對復(fù)雜，在企業(yè)級定制產(chǎn)品中較為常見，在面向公眾的產(chǎn)品中卻不普遍。

2.3 資源管理問題

資源管理問題是云計算的共性問題，因為大多數(shù)云服務(wù)本質(zhì)上體現(xiàn)了為用戶管理軟硬件資源的復(fù)雜性。這里將深度學(xué)習(xí)業(yè)務(wù)的資源管理問題分為應(yīng)用對資源耦合及高性能資源復(fù)用兩個子問題予以討論。

2.3.1 應(yīng)用對資源耦合

云計算環(huán)境為了實現(xiàn)高資源利用率及高靈活性，有將資源與應(yīng)用解耦的傾向，這種設(shè)計對資源請求同構(gòu)性強的應(yīng)用友好。然而，深度學(xué)習(xí)業(yè)務(wù)不同環(huán)節(jié)、不同作業(yè)的資源請求差異性大。例如算法開發(fā)環(huán)境一般只需要CPU，模型訓(xùn)練需要使用訓(xùn)練型GPU（如NVIDIA V100），而數(shù)據(jù)推理需要使用推理型GPU（如NVIDIA T4）或FPGA;對于分布式作業(yè)，還需要選擇性地使用高速以太網(wǎng)或InfiniBand網(wǎng)絡(luò)。為所有宿主環(huán)境配齊各類資源顯然是不經(jīng)濟的選擇，這就需要運行時控制框架具有資源感知的調(diào)度能力，為不同的作業(yè)選擇最合適的宿主節(jié)點。

仍以容器化調(diào)度框架為例說明。Kubernetes支持以量化請求方式申請CPU、內(nèi)存等通用資源，以及GPU等通過插件接人的擴展資源，并支持以節(jié)點標(biāo)簽及其選擇器（se1ector）方式描述量化請求不能表達(dá)的額外信息，例如GPU型號。這種機制在不涉及包含同類異構(gòu)硬件的宿主節(jié)點的云計算環(huán)境中能較好地滿足資源感知的作業(yè)調(diào)度需求。針對包含同類異構(gòu)硬件的情況（如單機內(nèi)有兩種不同型號的GPU），亦有第三方開發(fā)者提出了ExtendedRe.source、ResourceClass等細(xì)粒度資源匹配機制。這些機制在硬件組成復(fù)雜的開發(fā)與實驗環(huán)境中比較有用。但對于真實生產(chǎn)環(huán)境，考慮到硬件資源及軟件版本的易維護性，應(yīng)當(dāng)盡可能避免同類異構(gòu)硬件組合的復(fù)雜情況。

除GPU型號這種定性的資源感知指標(biāo)外，在深度學(xué)習(xí)云服務(wù)中還需要注意諸如顯存這樣的定量指標(biāo)。不同于支持時間片輪轉(zhuǎn)的CPU資源和支持頁面交換的內(nèi)存資源，顯存等資源數(shù)量不足并非只會影響執(zhí)行效率，而是會直接導(dǎo)致作業(yè)失敗。這一問題可以在容器化調(diào)度框架和算法程序兩個層面解決。在框架層面，對于不涉及資源復(fù)用的情況，可以簡單地將定量指標(biāo)當(dāng)作定性標(biāo)簽用于資源匹配。涉及資源復(fù)用時，上述ResourceClass機制及后續(xù)介紹的復(fù)用插件機制亦能提供支持。在算法層面，對于服務(wù)預(yù)置的算法可以采取資源感知的自適應(yīng)設(shè)計，最大限度利用資源而不引發(fā)作業(yè)失敗。

2.3.2 高性能資源復(fù)用

深度學(xué)習(xí)業(yè)務(wù)經(jīng)常會使用高性能計算、通信與存儲設(shè)備提升訓(xùn)練或推理效率。在多作業(yè)共享宿主環(huán)境的情況下，為提升資源利用率、降低服務(wù)成本，需要實現(xiàn)資源復(fù)用。并非每一種高性能資源都默認(rèn)支持透明復(fù)用模式。資源復(fù)用需要考慮可行性、可用性、安全隔離及性能隔離等層面問題。某些ASIC和FPGA設(shè)備不提供多作業(yè)復(fù)用能力，這屬于可行性問題;GPU雖然可被多作業(yè)復(fù)用，但顯存總量有物理約束且默認(rèn)不支持換出到硬盤，因此無法使瞬時內(nèi)存超限的多個作業(yè)穩(wěn)定并存，這屬于可用性問題;GPU被復(fù)用時，多作業(yè)均可訪問其虛擬設(shè)備文件，存在顯存數(shù)據(jù)泄露風(fēng)險，這屬于安全隔離問題;InfiniBand網(wǎng)卡在被多作業(yè)直接復(fù)用時，每個作業(yè)的帶寬無法得到保證，這屬于性能隔離問題。在InfiniBand網(wǎng)卡上啟用帶有QoS支持的虛擬功能（Virtual Functions，VF）后，資源復(fù)用的多種問題可以得到解決。

僅在設(shè)備層面支持資源復(fù)用是不夠的。深度學(xué)習(xí)云服務(wù)還需要在運行時控制框架層面以合理的方式應(yīng)用這些底層機制，才能實現(xiàn)安全和性能有保障的資源復(fù)用。以Kubernetes場景為例，為了可用性與安全性目標(biāo)，NVIDIA提供的GPU插件選擇不開放GPU原有的復(fù)用能力，只允許一個GPU分配給一個容器組。阿里云開源的GPU共享插件開放了GPU復(fù)用能力，但不支持安全隔離和性能隔離，其適用于多個可信應(yīng)用復(fù)用GPU，且在算法程序中自行保證資源用量的場景。騰訊設(shè)計的GaiaGPU機制”）No通過系統(tǒng)開發(fā)庫攔截GPU訪問請求，在GPU復(fù)用的基礎(chǔ)上實現(xiàn)了資源配額控制，從而滿足多作業(yè)運行的可用性與性能隔離需求。

由于容器機制的弱隔離性，資源復(fù)用機制即使能夠保證設(shè)備本身的安全隔離，仍有可能在其它方面具有安全風(fēng)險。例如，部分資源復(fù)用機制依賴操作系統(tǒng)或容器的特權(quán)選項，使得從容器內(nèi)部實施攻擊更加容易。解決這類問題的思路是將用戶身份感知的調(diào)度策略與資源復(fù)用機制相結(jié)合，避免互不可信的作業(yè)運行于同一宿主節(jié)點。此外，高性能生態(tài)中的Singularity非特權(quán)容器技術(shù)，以及基于輕量級虛擬機的Kata安全容器技術(shù)，也是實現(xiàn)高性能資源安全復(fù)用的可選方案，它們已在部分超算中心的高性能計算服務(wù)以及公有云的容器實例服務(wù)中實現(xiàn)，值得深度學(xué)習(xí)云服務(wù)參考。

3.4.1 資源表達(dá)式匹配機制

在對接多種調(diào)度框架的公共抽象層中，應(yīng)用所依賴的資源需求是作業(yè)抽象的重要組成部分。OMAI采用一種基于JSON語言支持?jǐn)U展字段的資源需求表示方法，以及與之配套的資源表達(dá)式匹配機制。使用JSON表示資源需求，方便對不同的集群驅(qū)動進(jìn)行解析;擴展字段機制則適應(yīng)了調(diào)度框架以插件方式接人和復(fù)用高性能資源的設(shè)計。資源表達(dá)式匹配機制相比傳統(tǒng)的標(biāo)簽匹配機制，增加了算術(shù)、字符串和集合運算能力，有助于對定量指標(biāo)以及復(fù)雜條件實施匹配。以匹配GPU資源為例，本機制可以按GPU型號、顯存容量、類別（訓(xùn)練或推理）等條件組合實施匹配。

相比Kubernetes生態(tài)中第三方提出的ExtendedResoHree、ResoureeClass等細(xì)粒度資源匹配機制，本機制實現(xiàn)的是節(jié)點級匹配而非設(shè)備級匹配，因而不適用單節(jié)點包含同類異構(gòu)硬件的情況。該權(quán)衡是值得的，因為OMAI需要實現(xiàn)跨多類調(diào)度框架的通用性，并非每一類調(diào)度框架都支持涉及設(shè)備細(xì)節(jié)信息的細(xì)粒度調(diào)度，同時真實生產(chǎn)環(huán)境中也較少存在這種復(fù)雜的硬件組成情況。

3.4.2 增強型插件機制

針對云計算環(huán)境中最常用的Kubernetes調(diào)度框架，OMAI團隊研發(fā)了具有增強特性的資源接人和調(diào)度插件。以GPU復(fù)用插件為例，相比阿里云開源、面向推理服務(wù)、以顯存為資源選擇依據(jù)的GPU共享插件，OMAI的GPU復(fù)用插件支持“毫GPU”等更多靈活易用的資源單位，也支持面向訓(xùn)練作業(yè)的單容器多GPU分配。在性能隔離方面，本插件參考了GaiaGPU設(shè)計。在安全隔離方面，出于對容器弱隔離性問題的整體規(guī)避，OMAI采取了用戶身份感知的反親和性調(diào)度策略。此外，通過集群驅(qū)動中的相關(guān)設(shè)計避免了同類插件經(jīng)常存在的、源于與NVIDIA GPU插件互不感知的資源沖突問題。

增強型資源插件亦是OMAl支持其它高性能硬件、實現(xiàn)高性能計算特色的途徑之一。這類插件使得高端硬件能力可以透明且安全地強化深度學(xué)習(xí)應(yīng)用。

3.5 應(yīng)用場景

OMAI現(xiàn)已服務(wù)于多種應(yīng)用場景，其公有云服務(wù)已經(jīng)上線并對公眾開放使用，私有云服務(wù)也已支撐了某科研院所的遙感圖像分析、某上市公司的數(shù)據(jù)處理平臺等生產(chǎn)性業(yè)務(wù)。OMAI團隊及客戶在此基礎(chǔ)上研發(fā)的應(yīng)用涉及圖像分類、圖像增強、數(shù)據(jù)分析、數(shù)據(jù)預(yù)測、自然語言處理等領(lǐng)域。相比直接使用深度學(xué)習(xí)引擎或傳統(tǒng)平臺軟件，OMAI為上述應(yīng)用提供的核心價值在于云服務(wù)化，特色價值在于高性能，目標(biāo)是使用戶以低成本、高效率上線人工智能業(yè)務(wù)。

OMAI目前仍在繼續(xù)開發(fā)演進(jìn)，期望其設(shè)計思路能夠?qū)Ρ绢I(lǐng)域的技術(shù)研究和產(chǎn)品研發(fā)帶來啟發(fā)，從而促進(jìn)人工智能系統(tǒng)與應(yīng)用的長足發(fā)展。

4 結(jié)語

深度學(xué)習(xí)技術(shù)是支撐人工智能應(yīng)用的基礎(chǔ)，以云服務(wù)方式提供深度學(xué)習(xí)能力是業(yè)界的主流趨勢。深度學(xué)習(xí)業(yè)務(wù)實現(xiàn)具有微服務(wù)和批處理作業(yè)兩種典型模式。業(yè)界通常采用大數(shù)據(jù)、高性能或容器化調(diào)度框架構(gòu)建面向不同場景的深度學(xué)習(xí)云服務(wù)。對現(xiàn)有平臺軟件的分析表明，深度學(xué)習(xí)業(yè)務(wù)的云服務(wù)適配過程需要解決運行模式適配和運行時環(huán)境依賴等作業(yè)調(diào)度問題、存儲類型匹配和存儲跨域訪問等存儲接人問題，以及資源耦合與高性能資源復(fù)用等資源管理問題。業(yè)界現(xiàn)有的云服務(wù)針對不同問題提出了多種解決方案，在一定程度上滿足了特定場景對深度學(xué)習(xí)業(yè)務(wù)云服務(wù)化的需求。OMAI深度學(xué)習(xí)平臺是在系統(tǒng)分析上述問題的基礎(chǔ)上，面向全流程、一站式、高性能目標(biāo)設(shè)計研發(fā)的深度學(xué)習(xí)云服務(wù)軟件。它具有作業(yè)調(diào)度中間層抽象、異構(gòu)存儲容器內(nèi)掛載、資源表達(dá)式匹配等機制，解決了作業(yè)調(diào)度、存儲接人和資源管理等層面的技術(shù)問題。OMAI的設(shè)計思路和研究實踐可用于指導(dǎo)本領(lǐng)域研發(fā)工作。