可一鍵快速部署到私有化集群。

文章包括以下幾大部分：

一站式工程化

分布式加速

推理閉環

邊緣計算

01一站式工程化

在沒有端到端的機器學習平臺之前，流程比較復雜繁瑣。

開發一套完整地機器學習流程，需要人工介入很多問題：

向運維申請機器

評估cpu和gpu資源

對大數據量場景申請分布式存儲

存儲膨脹，持續向運維申請更源

算法開發環境，大多用自己熟悉的框架版本

代碼開發會綁定機器，則機器故障或裁撤時很棘手

遷移或離職交接難

打標、自動化處理等任務占據cpu時間且資源不共享，導致gpu利用率不高

任務編排，通過不同同學間的共享文檔或存儲交互，寫shell腳本執行

很多團隊缺乏算法后臺工程師，不具備高性能部署、在線運維等能力

針對這些問題，我們提出了一套完整的云原生的一站式解決方案，能夠方便地進行私有化部署，適用于推廣搜、音視圖文本等場景訓練和推理。

其中平臺底層統籌算力，不需要用戶關注，支持用戶自定義資源，支持共有和私有資源控制，存儲也是類似，進行統一規劃，同時并支持用戶私有資源或平臺公有資源。

在基礎能力層，平臺或用戶可以自己封裝分布式框架（例如分布式訓練框架），訓練框架之上是直接接觸用戶的一站式端到端的功能，包括在線開發、參數調優、模型編排、模型部署、分布式能力以模型市場的形式開放給用戶開發和使用。

1. 平臺核心能力介紹統籌算力

平臺基于云原生建設，linux內核進行標準化。內核版本低會導致容器之間的帶寬效率低，而分布式訓練對內核的通信要求比較高，故對內核進行了升級和標準化，容器帶寬達到了20Gb/s。cpu采用大核心的配置，方便調度pod資源。gpu是異構的，需要結合用戶需求選擇，但不建議在訓練中使用vgpu，不然容易出現算力零散的問題。界面操作支持自定義私有docker倉庫，用戶可以自行配置。

多集群部署

部署方面，涉及訓練、調試、服務化等集群資源分配問題，也涉及多項目部署/多區域部署的資源分配問題，同時還有公有資源和私有資源共存的問題，全部這些管理需求在平臺ui端通過項目選擇進行管理，平臺控制和用戶控制相結合的管理方式，像訓練/調試部署至各自集群由平臺控制，用戶需要使用私有資源，則可在項目組中配置該組對應的資源池。

分布式存儲

開發、訓練、存儲使用統一的分布式存儲，用戶不需要感知數據在哪里。只要在平臺啟動容器，則/mnt/username指定目錄下就是個人數據，用戶之間數據是隔離屏蔽的，互相不可見。對音視頻領域的數據在組內共享的問題，此場景下不同用戶間的數據需要可見，對此也支持組模式的存儲共享。

另外，平臺支持自帶存儲資源或使用平臺公有資源的不同服務形式，公有資源建議使用高性能的ssd ceph，對接外部存儲使用性價比高的cfs進行鏈路打通。

在線開發

開源版本集成了jupyter、vscode等開發工具，可以創建多個cpu/gpu實例。開發者可在notebook鏡像中集成公司內部常規linux開發工具（git/spark客戶端等）。使用在線開發的切換成本相對低很多，針對特殊場景開發者可以加入類似tesnorboard/pandas等插件，制作定制化notebook，進一步提升使用效率。

cube同時集成在線開發鏡像構建功能，對Dockerfile進行包裝，屏蔽實現細節，對算法同學，僅執行命令行即可實現鏡像打包。

Pipeline編排

直接使用airflow/argo等調度組件，但沒有編排界面，直接編輯yaml也很麻煩。所以我們單獨開發了模板市場和pipeline編排工具，并在開源中提供多種分布式模板。例如分布式的tf/pytorch/mxnet/kaldi/horovod分布式訓練，ray/volcano分布式數據處理或nni分布式超參搜索。用戶通過拖拉拽方式編排pipeline，配置執行參數后就可運行。

模板開發

模板市場的模板是注冊進去的，用戶和平臺都可操作。流程比較簡單：準備鏡像，標注清楚該鏡像的參數、類型、限制條件、用戶提示等，使用標準化的注冊流程注冊至平臺后，平臺用戶就可使用該模板。模板開發者多為平臺方或使用方組織架構內特定工程人員。

單任務調試

Pipeline的調試多集中于單task的調試，每個task可能是單機或分布式task，對于單機task可以進入命令行直接運行，對于分布式task，可以直接查看全部日志的聚合結果，而不必逐個pod查看，同時可以查看每個task的資源使用情況。在音視頻領域，因數據量大，資源利用率的優化對整體耗時的提升有明顯幫助。

Pipeline調試

使用kubeflow的任務流調試查看，支持任務流重試，運行狀態，實時/離線日志等。

定時調度

重新開發定時調度，支持模板命令、補錄、重試、忽略、依賴、并發限制。

超參搜索

nni超參搜索需要用戶編寫侵入性上報代碼。

```

#上報當前迭代目標值

nni.report_intermediate_result(test_acc)

#上報最終目標值

nni.report_final_result(test_acc)

#接收超參數為輸入參數

parser.add_argumen(‘—batch_size’, type=int)

```

katlib超參搜索是Kubeflow自帶的，要求按照規范上報日志，分析每次訓練的變化。

通過上面的方案，整個ml流程操作簡單，通過模板，使用可視化托拉拽的方式構建ML任務流，支持數據拉取、處理、訓練、校驗、部署，快速搭建流程。

但是搭建好后會發現雖然編排流程簡化了，但是運行時間并沒有減少，耗時主要集中在數據處理和訓練上。數據處理分為結構化和非結構化數據處理，對于結構化數據處理，像sql等形式目前還是采用公司已有的大數據spark平臺，對于非結構化數據處理/訓練以及結構化數據的訓練部分的耗時，考慮使用分布式的加速方式。

02分布式加速

分布式加速存在以下問題：

分布式框架選擇多，如果封裝一套標準的分布式框架，則用戶側的遷移成本高，且訓練邏輯脫離平臺后可能不通用。從算法角度看，算法同學手里的算法很多是直接參考其他開源算法，梳理代碼已經比較耗時，再去適配平臺封裝的分布式框架是很困難的，并且開源的項目里面很多已經攜帶了分布式的代碼。

1. 分布式框架

平臺底層以k8s為核心調度部署各種類型的分布式集群；

在此外面封裝了一層框架層分布式，將用戶常用的分布式框架例如分布式sklearn-lib、tf、pytorch、volcano、ray、spark、mxnet、kaldi、nni等分布式框架均集成進來；

更外一層是算法/功能層面，將音視頻圖像分布式文件處理、傳統機器學習分布式、推薦算法分布式、音視頻文本算法分布式、多模態算法分布式等集成進來，對于沒有的算法，用戶側也可以將自己實現的分布式方案以模板化的形式注冊進來。

2. 存儲+通信

解決了分布式框架問題之后，性能不一定會加速。

直面的第一個問題就是存儲io。平臺側封裝的模板可以定向優化，部分通用性模板開放性較高，不對用戶邏輯做限制，僅對用戶提供分布式能力，此類模板用戶的訓練性能可能存在io瓶頸，很難將io優化全部下放至用戶代碼層進行優化，所以我們在io層做了一層全局優化。從cfs切換到ssd ceph，最終性能達到G級別的寫入和7-8G級別的讀取，滿足大部分訓練需求。

隨后發現cpu使用率明顯上升，但此時網絡索引問題成為下一個需要的解決的問題，特別是音視頻領域。在推薦場景下，一般是csv格式的大文件（10G+），數量相對少，但是在音視頻文本領域，存在上千萬的大量小文件，容易卡在高頻率的網絡請求上。平臺的文件存儲在遠端的分布式存儲中，但是計算集群可能是不同網絡的私有集群。在當前網段新建ssd ceph，抵消網絡異地或者跨網段時延。定向優化后，訓練性能在GPU上再提升3倍以上。

在此基礎上支持用戶私有資源的使用能力，我們開放給用戶配置使用私有存儲，打通標注平臺（ceph類的對象存儲或者cfs存儲），允許用戶直接掛載過來，這樣與外部數據標注或者數據集平臺聯動。

經過存儲優化后，可以看到io的耗時占比在鏈路中明顯下降，但是通信時延占比超過總耗時的55%，排查之后發現是linux的tcp內核bug，使用高版本linux 4.14+已修復，容器間帶寬提升至20Gb/s，則通信問題也降級為次要問題。

3. 資源利用率

對cpu分布式任務，用戶可自己借助多進程、協程提升單個pod的cpu利用率。此部分傾向于讓用戶申請更多worker數提升性能。對于用戶沒有主動優化cpu利用的情況，支持通過系統的監控和智能調整優化方案將該任務的資源申請值調整至合理的范圍，進而提升cpu使用率。

gpu比較特殊，平臺在訓練過程中對gpu的占用為整卡占用的方式，因為在訓練中使用vgpu非常容易出現卡零碎浪費的情況，并且即使使用vgpu，并處理好零碎卡的問題，提升了平臺整體gpu利用率，但任務耗時沒有降低。故平臺方傾向于提升用戶占用的gpu卡的單卡利用率，進而提升單個分布式任務的運行效率。

gpu利用率低的核心問題是gpu等待時間太長，可能cpu處理或io等操作，包括優化磁盤存儲、數據加載、網絡通信、預處理、cpu上的模型保存。

對用戶完全自行開發的代碼，平臺方會根據監控配合用戶進行針對性優化，提升gpu的利用率。例如對臨時性的高頻文件使用內存映射磁盤（libariry庫）；訓練框架io加載的并行參數優化；計算和數據同域分布；音視頻的小文件合并成大文件；專用并行io庫；cpu數據處理和gpu計算分隔成兩個任務處理，降低cpu和gpu切換開銷；使用gpu來進行處理；batchsize調整把gpu打滿。實際實踐中，wenet分布式音頻提升30-50倍的效果（200h音頻文件單卡訓練3天，現在1.8萬h音頻22v100，4天訓練時長）。

4. 共享GPU

對于一些場景，平臺或用戶不能投入人力定向優化，比如推薦中cpu & gpu混合任務場景，更傾向于使用共享gpu的方案。

在云原生多機多卡訓練中，大部分框架每個worker默認會占用卡的全部顯存。但是因為代碼處理可能并不能將單卡的核全部利用起來，這種場景可以配置單個卡上跑更多worker，對應的整個環境變量的配置跟隨變動，例如pytorch的WORLD_SIZE，RANK，LOCAL_RANK。

至于每張卡上啟動多少個進程來共享同一張卡，需要結合最先達到瓶頸的資源，考慮cpu和gpu的配比情況來看，比如對推薦場景，一般是cpu先達到瓶頸。gpu機器設備上cpu資源相對少的特性（3個純cpu機器算力有200多核，但4卡gpu機器只有60個核cpu），cpu和gpu是一個相對匹配的算力。在共享gpu的方案中，根據哪一個資源（cpu/gpu）優先達到瓶頸，就可結束進程增加。

另外一些分布式多機多卡訓練，本身就是共享gpu卡的，比如在Kaldi語音識別中，默認顯存占用率為50%，移植到k8s中后，修改從申請50%顯存調整至20%，則并發數就可以增加，利用率直線上升。

5. Scheduler調度

解決cpu和gpu使用率問題后，下面需要解決多個分布式任務之間，或者一個分布式任務不同的pod之間能夠跑得更穩定，降低相互影響的概率。調度層是由k8s的過濾和打分策略來決定，能讓用戶在使用時充分利用資源。

首先是批調度能力，針對分布式任務間的資源競爭死鎖問題，加入kube-batch的gang。

調度能力，只有當一個分布式任務所需資源全部滿足時才開始調度，避免死鎖。

另外是親密度和調度算法的調整：對cpu型任務傾向于把不同的任務分配到不同的cpu機器上避免單機瓶頸；對gpu任務，多個任務盡量分配到同一個gpu機器上，減少網絡通信消耗；對同一pipeline中的不同任務，盡量部署到不同的機器上，避免存在相似任務任務達到單機瓶頸，因為有些任務受機器白名單限制等；對于不同的pipeline，放到算力相對空閑的機器上，平衡集群使用率。

6. 資源組均衡

因為gpu機器資源比較昂貴，直接新采購一批gpu，讓算法同學遷移，成本是比較高的，并且現存的gpu是保存在各個業務線自己的手里面，所以平臺支持多集群多項目的資源池管理。對資源的管理分為公有項目組和私有項目組，項目組的資源可分為可共享資源和不可共享資源。在資源緊張時，將可共享資源共享出來供其他項目組使用，用完之后再歸還，以此應對某個項目組突發訓練大任務的情況。

7. 數據傾斜

分布式訓練結構這里分為三類。

無狀態的分發任務（計算到當前步驟時現場進行任務分發），這種情況不存在數據傾斜問題。

有序的無狀態任務（提前分配好任務，申請多少worker，每個worker分配什么任務，會在訓練前進行分配），會存在任務傾斜問題。

分角色有序任務（提前分配好任務，但到達特定步驟時，worker之間會相互通信信息），這種情況也會存在數據傾斜，但此類問題較難調整，會涉及到算法的變動，容易影響算法準確率。

這里僅說一下有序的無狀態任務。例如一個任務提前分布好每個worker的內容，當數據分配不均勻和部分worker受其他機器worker影響時，性能會下降，此時每個worker剩余任務數量就不一樣，導致用戶任務遲遲不能完成，不能推進其他事情。部分用戶強制終止，重新分配剩余任務。

對于參數可共享的任務，通過共享內存將內容直接放到遠端處理。對于參數不可共享的任務，例如tf加載模型，模型變量無法共享（很多線程鎖存在，導致模型參數不能序列化到其他機器），這種情況建議使用隊列方式，消費者根據當前gpu資源彈性伸縮，并且可以在單卡上啟動多個消費者，保證gpu的利用率。

8. 優化方案總結

綜上，平臺對分布式訓練的優化，分成四塊：

在用戶代碼層面，深入進程內部進行優化；

在數據層面，避免數據傾斜、優化數據加載；

物理層面，優化大文件、帶寬問題；

在此之上，使用共享gpu提升使用率，動態cpu算力調整，上層優化任務調度，親密性，多項目組的資源共享等。

03推理閉環

1. 數據鏈路實時閉環

開源平臺不包含數據部分，主要是因為公司內部存在很多標注平臺、特征平臺等。引入這些平臺，直接進行模型訓練，執行剛才提到的pipeline流程，大模型、分布式、多集群的調度、優化gpu利用率。模型上線后，在線推理部分包括工具化管理、加速、hpa、服務pipeline，通過流量復制做音視頻在線數據直接回到標注平臺進行新數據打標，重新導入模型訓練。

2. 模型服務化分層

模型推理部分平臺構建了一套模型管理的工具，通過服務網格做分流和復制，服務內部使用http框架，服務切分為模型前/后置處理和推理。模型推理使用tensorrt做橫向和縱向的gpu加速，同時支持tf、onnx、pytorch、用戶自定義鏡像。用戶自定義一般是用戶的算法工程人員將組內模型封裝成鏡像，而不是使用平臺的鏡像封裝。平臺方更多是提供零代碼發布的能力。服務管理主要是模型管理、代碼管理、鏡像管理，云原生服務的hpa能力，除了自帶的cpu和內存指標，平臺支持prometheus adapter，根據gpu利用率、時延等可以采集的指標做資源彈性伸縮，同時開放接口給到用戶，可對接用戶外部平臺，進行性能和資源分析。

3. 稀疏embedding大模型實時訓練

部分場景有實時訓練的需求，自研的TMEPS，對接流式數據，用戶需要將加工好的實時特征上報至實時隊列中，平臺將訂閱隊列，對大規模稀疏模型集成tfra，這里有兩個主要功能：

將embedding模型參數放到kv中，訓練集群ps內存僅保留dense部分。

動態參數準入準出，可以大幅壓縮模型體積。dense部分熱更的方式更新到推理端，稀疏embedding部分，推理服務接收推理請求時，現場lookup 讀取kv數據庫，同時整個模型會使用離線模型進行日更處理，這一部分也逐漸開源到github。

04邊緣計算

通過邊緣集群的形式，在中心節點部署平臺，并將邊緣節點加入調度，每個私有網用戶，通過項目組，將notebook, pipeline, service部署在邊緣節點：

避免數據到中心節點的帶寬傳輸

避免中心節點的算力成本，充分利用邊緣節點算力

避免邊緣節點的運維成本