導讀 本文将介紹阿裡巴巴手機淘寶 Meta 技術團隊曆經四年研發的端到端、通用型、規模化産業應用的端雲協同機器學習系統 Walle。Walle 的名字來源于電影《機器人總動員》。電影中 Walle 作為地球上最後一個機器人，負責對地球上的垃圾進行清理、變廢為寶。我們的系統設計也秉持着相似的初衷，希望所設計和搭建的端雲協同系統能夠有效地利用數以十億計移動端裝置上的資料，充分釋放其被忽略的價值，為使用者提供更好、更便捷的智能化服務。
文章将包含以下幾大部分：
1. Background & Motivation
2. Overall Goal & Architecture
3. Walle – Compute Container
4. Walle – Data Pipeline
5. Walle – Deployment Platform
6. Evaluation Results
7. Summary
8. Q&A
分享嘉賓｜牛超越博士 阿裡巴巴 學術合作實習生
編輯整理｜晏世千
出品社群｜DataFun
01
Background & Motivation
首先介紹一下設計和搭建 Walle 系統的背景和動機。
随着移動端裝置軟硬體能力的進步，以及機器學習和深度學習技術的發展，如今使用者已經可以在其手機、平闆等終端裝置上享用多種多樣的智能化服務，例如語音識别、推薦等等。
為了保證使用者在實時互動中的良好體驗，通常要求視覺、語音和推薦的延時在幾百毫秒甚至幾十毫秒的量級。同時這些應用需要處理來自大規模移動端使用者的海量資料。
使用者原始資料還會設計到很多敏感隐私資訊，可能會引起使用者的安全隐私顧慮。例如在視覺應用場景中，通常會涉及人臉、人體姿勢、觀看曆史等敏感資訊；在語音導航場景中會涉及使用者運動軌迹；在推薦場景中會用到使用者個人資訊，以及商品的點選、收藏、購買等行為資料。針對資料安全隐私問題，國内外出台了很多相關法律法規。大陸于 2021 年開始實施資料保護法，網際網路公司需要嚴格保護使用者隐私。
阿裡有 30+ 個 APP, 日活使用者達到億級，在用戶端有300多種機器學習任務，CV、NLP 和推薦的占比分别為 30%、10% 和 60%，每日運作次數分别為 10 億次、10 億次和千億次左右。
目前為移動端使用者提供智能服務的架構是基于雲服務端的。在使用者端基于雲服務端的資料送出請求，包含使用者的原始資料，雲伺服器在經過資料預處理、模型執行的操作以後，傳回結果，可以看出雲伺服器幾乎承擔了所有的計算負載，而移動端僅作為使用者互動的界面，在雲端計算完成後，傳回結果。在實際應用中，基于雲端的機器學習任務也面臨着延遲高、機器學習成本和負載高以及隐私安全風險高等瓶頸。具體而言:
1.高延遲主要由端雲互動以及在雲上處理，數以百萬計數以億計的實時請求。
2.高成本和高負載，是由于傳輸、存儲以及利用機器學習算法處理海量資料造成的通訊存儲和計算開銷。
3.隐私風險主要展現在上傳敏感隐私的原始使用者資料，并在雲上存儲和處理資料。
存在上述瓶頸的根源在于，忽視了移動端裝置經過近 10 年的發展，目前已經能執行适量的資料處理和模型執行任務。
為了打破基于雲機器學習架構的瓶頸，學術界和産業界開始探索端雲協同的新範式。核心的理念是，做機器學習不僅可以在雲上執行，也可以在移動端裝置上執行，而非單純的依靠雲伺服器。換句話來說，一個機器學習的部分階段，可以從雲上解除安裝到機器學習裝置上。
端和雲協同完成該機器學習任務，在機器學習任務執行過程中，移動端裝置可以作為雲伺服器的一個計算中繼，同時雲伺服器也可以作為移動端裝置的一個計算中繼。具體選擇雲還是端來執行機器學習任務的哪一個階段，是相對靈活的。重點需要考慮該機器學習的實際需求，例如實時性，任務的複雜性等一些需求，以及雲和端各自的一個優勢。例如，資料的前處理階段，選擇端或者雲，本質上是看誰更接近資料源。端雲協同的新範式可以充分利用移動端靠近使用者資料源的天然優勢，進而降低延時，削減開銷，降低雲上負載。同時支援使用者原始資料，始終不離開裝置本地，實作隐私保護。
上圖是我們對端雲協同機器學習的一個粗略的分層，從底向上分别是硬體層、系統層、算法層和應用層。已有相關工作主要處于算法層和應用層，針對特定的應用場景，例如視訊分析、文本處理或推薦，并針對機器學習任務執行的某個階段，比如模型訓練或者推理，涉及一個定制化的算法解決方案。主要考慮算法層面的一些問題，例如端雲如何配置設定任務，端雲如何互動，以及端雲的一些協同機制，多個端和雲還是單個端和雲等等。在産業界應用中通常會涉及視覺、語音、推薦等多種類型的任務而非單種任務，并且涉及任務全鍊路的執行而非單個階段，要支援上億個裝置，而非少量的移動終端，是以如何将端雲協同推向規模化産業應用的通用性系統成為了一個實際需求。
--
02
Overall Goal & Architecture
基于上述背景，我們設計搭建了 Walle 系統。先來介紹一下 Walle 的整體目标和架構。
Walle 遵循端到端、通用型、可規模化産業應用的設計原則，支援在機器學習任意階段在端側和雲側交換任意必要的資訊，例如交換資料、樣本、特征和模型，以及模型更新或者中間計算結果。
Walle 遵從了端到端的架構設計，從開發者視角，覆寫了機器學習任務的研發期、部署期和運作時，并且支援在端側和雲側運作時的每個階段，包括模型的前處理、模型訓練、模型推理和模型後處理。
Walle 還遵循了通用型的系統設計，而非內建了大量特定應用的定制化方案。是以Walle 可以作為機器學習的基礎設施，向開發者透露出統一的标準接口。向下抹平端雲裝置軟硬體的差異性，并保證移動APP的輕量化；向上則支撐多種機器學習任務的大規模産業應用。
Walle 的整體系統架構如上圖所示。一個機器學習任務主要包括腳本（python 機器學習三個階段的實作），資源檔案（資料，模型和依賴庫）和配置檔案（什麼時候觸發什麼機器學習任務）
Walle 的核心系統子產品包括：部署平台，資料管道和計算容器，分别負責機器學習的管理和部署，輸入的準備，以及任務的執行。
- 計算容器為具有标準輸入的多種機器學習任務提供了跨平台、高性能和輕量化的執行環境，同時支援機器學習算法頻繁的實驗和部署，進而滿足實際任務“天”級疊代的實際需求。
- 資料管道，涉及到機器學習的前處理階段，為端側和雲側提供任務輸入。Walle 主要關注了使用者與移動端 APP 互動過程中産生的使用者行為資料，包括時間和頁面事件的行為序列。使用者行為資料無法被資料管道中的資料庫直接處理。
- 部署平台主要是面向億級的移動端裝置，以時效性和魯棒性強的方式進行釋出管理，并部署到大規模的機器學習任務。同時兼顧機器學習的一些需求，裝置資源可用性的一些特點，以及任務失敗的一些案例。
--
03
Walle-Computer Container
1. 計算容器的設計挑戰和細節
在搭建計算容器的過程中，我們遇到了如下挑戰：
第一個挑戰：較長的疊代周期，大部分 APP 以周為計時方式來更新的軟體需要每天疊代機器學習任務。需要頻繁的部署，以驗證機器學習算法和模型的有效性，找到最優特征組合或者超參設定。
第二個挑戰：異構後端。雲伺服器和移動端裝置在體系架構（CPU，GPU，NPU）、記憶體等硬體層面以及作業系統（Andriod，IOS，Windows，Linux 等）等軟體層面存在較大的差異性。移動端裝置内部軟硬體碎片化更為嚴重。
第三個挑戰：機器學習任務的多樣化，涉及視覺、文本、推薦任務，并且用多種神經網絡結構（CNN，RNN，Transformer，GAN，VAE，DIN 等），前處理和後處理涉及很多資料的不同處理方法。
第四個挑戰：APP 資源限制，每一個 APP 通常隻有一個程序。對于手淘運作的 APP 最大就 200M，同時包大小不能超過 300M。
2. 計算容器架構的整體架構
在頂層選擇了 python 作為機器學習開發語言，python 廣泛應用于開發機器學習算法，同時是一種動态型的剪枝語言。為了在不同平台上支援機器學習腳本，如機器學習受限的移動端裝置。通過裁剪，虛拟改造，Cpython 實作資源受限的移動端裝置，虛拟機。改造分為兩方面，首先是任務集，多線程的并發；另外面向 APP 端的實際需求進行了一個裁剪。
- Python Thread-Level VM
這是業界首個基于 python 的虛拟機設定。賦予了容器一個動态任務下發的能力。進而實作一個機器學習任務天級别疊代的需求。并且與 APP 天級别或者月級别疊代解偶。
- Data Processing & Model Execution Libraries
MNN 語言主要基于天級别來實作設計的（詳見 https://github.com/alibaba/MNN or https://www.mnn.zone/）
整體來說 MNN 采用了端雲一體的方式來設計。覆寫了矩陣運算，圖像處理，模型訓練，模型推理等功能子產品。與已有的（Numpy, OpenCV, PyTorch, Tensorflow, TensorflowLight）架構不同，MNN 通過全新的一體化設計，能夠将底層計算引擎的極緻性能優化透出給上面不同的庫，進而縮減針對異構後端每個庫定制優化的工作量，同時保證包的輕量化。進一步，我們将 MNN 的功能透出到 python 虛拟機中，形成标準的接口，支援了标準機器學習的整條鍊路。
3. 機器學習容器關鍵子產品的設計
- Tensor Compute Engine
從形變算子中提取了一個形變原算子，叫做 raster 算子，是以所有算子都可以拆解為原子算子，并且隻有原子算子需要對硬體後端進行手工優化，包括算法實作、SIMD 向量化、記憶體優化以及彙編等層面。
在資料處理和模型計算圖層面，主要引入了半自動搜尋機制，運作時能最快的找到搜尋方案。相比于手動搜尋（即給每一個算子實作算法的常用參數，做了一個 case by case 的優化），半自動搜尋不僅能大幅削減工作量，還能夠提升找到最優參數的可能性。至于不使用 TVM 全自動搜尋機制的原因是，TVM 在算子優化方面會利用人工優化經驗，算子優化會存在一個較大的優化空間，較長的編譯優化時間。進而支援模型以普通檔案下發，是以 TVM 的算子必須連結進 APP，導緻更新的實際時間為周級别或者月級别，進而不能實作天級别的快速疊代。TVM 在快速疊代的産業級的場景中是不可行的，例如需要更新部署的深度學習模型。
異構後端算子的手工優化，大幅縮減半自動搜尋的空間，進而支援模型以普通檔案形式動态下發。并進一步支援運作時的優化，以及在 Python 虛拟機中以天級快速的疊代。
另一個優勢，長期看來，随着越來越多的機器學習的部署，移動端的包大小，并不會随着張量而增加。
4. 幾何計算或者半自動計算的優化流程
首先計算圖中的形變算子和複合算子會被拆解為原子算子和 raster 算子。拆解後的一些 raster 算子可以合并，以提升性能。然後應用半自動搜尋機制，找到計算圖在移動端裝置或者雲伺服器上開銷最低的可用後端。
5. 形變算子的基本原理
從幾何構圖的角度，一個元素由起點坐标轉化到另一個起點坐标。
從資料拷貝的角度，一個起點的記憶體位址穿到另一個終點的記憶體位址。記憶體位址和坐标存線上性的映射關系，也稱為 view，由 Stride 和 offset 來指定。進一步的給定一個形變算子以後，公式将會給定，有了輸入和輸出，通常會給定一個坐标（該元素的一個 Index），起點記憶體位址和終點記憶體位址也可以被确定。Raster 算子是根據起點的記憶體位址在輸入和輸出的 tensor 之間，通過周遊坐标範圍，實作形變算子的一個功能。
在具體的 raster 算子實作的過程中引入了“區域”（region）的概念。包括起始的 views 元素坐标與資訊位址之間的參數，搬運過程中的位址的一個周遊範圍，也稱為 size,以及輸入 tensor。
6. 通過轉置算子來進行一個簡單的介紹
A 中的某個元素，記為行索引和列索引。該元素在轉置後的坐标記為 和 。
是以，，此外給定這個記憶體相對坐标和位址，周遊 A 的坐标範圍的話，raster 算子從起點矩陣 A 中搬運到終點矩陣 B 中。
更為便利的是周遊終點 B 矩陣的坐标範圍。
在算子拆解之後，一些 raster 算子可以被合并優化。一種政策是垂直合并，主要處理連續的 raster 算子；另一種政策是水準合并，主要合并兩個具有相同 region 的平行的 raster 算子。
半自動搜尋的設計，全局目标是找到開銷最小的可用後端，每個後端的開銷由每個算子在最優實作下的開銷累加得到。為了找到某個後端的最優實作，需要找到每個算子實作算法的最優參數設定。
該優化問題可以被快速的求解。
python 的虛拟機 cpython，是 python 官方應用最廣泛的編譯器和解釋器。
cpython 的移植過程中，主要考慮資源受限的移動端裝置，考慮兩個問題，一個是包大小的問題，對于移動 APP 備援的功能和子產品。第二個問題是 cpython 無法支援任務級的多線程并發。cpython 本身是不能支援并發程式設計的，并通過引入了 GIL 鎖來引入多程序。但是 GIL 隻允許一個程序單次處理單個程序， 每個移動 APP 是單程序進行的，不支援多程序。進一步考慮到機器學習任務執行的實際特點，即同時會觸發多個學習任務，并且任務之間通常是互相獨立的，以及單個任務中不同階段是順序執行的。如何建構 python 虛拟機成為一個實際需求。為了削減包大小，我們進行了一個功能性的裁剪：
首先将 python 代碼編譯成位元組碼，然後解釋位元組碼執行，通過将編譯階段放在雲上，位元組碼放在端上執行。可以删除所有的編譯子產品。另一方面，出于對 APP 的實際考慮，對庫和子產品進行一個裁剪，最後實作了首個端側的 python 解釋器。例如在 ARM64 架構上的 10MB+ 的記憶體削減為 1.3MB。
為了支援任務級多線程執行，我們舍棄了全局解釋器鎖 GIL，并将每個機器學習任務與一個線程綁定，最後進行了線程隔離。
上表中列出了 MNN 中一些跨平台的資料和模型運作庫。
對于前處理和後處理，矩陣運算的 API 和圖像處理的 API 是和 NumPy 與 OpenCV 的保持一緻的，進而便利開發者。對于模型推理和訓練，主要透露了一些采樣接口。包括資料加載模型，加載和儲存。設限了加載和執行，超參設計和損失函數計算。
--
04
Walle - Data Pipeline
接下來介紹 Walle 中的資料管道。
傳統的資料管道模式下，所有資料都會被上傳到遠離資料源的雲上，并利用 flink 流處理架構進行處理。然而端雲之間需要傳輸大量備援的資料，以及雲上需要計算和存儲，數以百萬或者數以億計的聚合資料，傳統的資料管道存在備援高，資源消耗大，隐私風險高等瓶頸。
在 Walle 全新的資料管道中搭建了一個全新的端側資料流處理架構，使得使用者行為資料可以在近資料源處被高效處理。架構的關鍵是如何高效地組織和管理面向多個特征生成任務的觸發條件。為了将端側新産生的特征低延時地傳輸到雲上進行消費，我們還搭建了實時通道，在 500 毫秒内傳輸 30KB 的資料。在實作上，實時通道主要是基于長連結通訊，通過優化 SSL 協定，以削減連結建立，加解密的一個耗時。資料在傳輸前進行壓縮，并在接收後進行解壓縮。為了應付高吞吐，雲上采用了全異步的一個架構，并采用了多地部署的部署方案，使得每個移動端可以連接配接最近的節點，進而降低延時。
端側流處理架構的設計，關鍵的設計原則和目标是，在單台資源受限的裝置支援針對無線資料流的有狀态的計算。一個使用者在移動端 APP 被記錄的帶有準确時間戳的一個行為資料，會構成資料流，使用者的行為資料處理是有狀态的。中間的處理結果會被緩存到記憶體中或被存儲在本地，以便後續使用。單台移動端裝置的資源是受限的，也意味着多個使用者的流處理資料流條件，需要被高效的組織和管理。
在具體的流程方面，一個使用者的資料首先被記錄在具有時間次元的時間序列，并聚合同一頁面上的事件形成在頁面次元的事件序列。此外一個端側流處理的觸發條件可以用事件辨別或者頁面辨別的序列來指定。為了支援多個相關流處理事件的批量觸發，在事件序列上比對多個觸發條件，模組化成一個存在多個通配符，規則的字元串比對的問題，并提出了字典樹管理觸發條件的設計，使得當端側一個新事件産生的時候，所有被觸發的任務都被挑選出來進行執行。當一個任務被觸發時，該任務的腳本将在計算容器中執行處理相關事件，除了計算容器透出的标準資料處理和模型之間的一些接口，為了支援從事件序列中提取出一些相關的事件，以及處理事件的一些内容，我們還實作了一些常用流處理的算子，包括 KeyBy, TimeWindow, Filter, Map 等等。考慮一個流處理任務在面對源源不斷的事件序列時可能被頻繁的觸發，同時單次輸出的量是比較少的。是以封裝了批量存儲的接口，以削減寫的頻率。
--
05
Walle - Deployment Platform
下面介紹 Walle 的部署平台。
首先，頻繁的實驗部署，要支援天級别的任務疊代，對部署平台的實時性提出了要求。其次是大規模多粒度的部署要求。在阿裡，端側活躍的機器學習任務有幾百個，需要覆寫的移動端裝置最多會達到億級别。此外，每個任務的釋出需要考慮移動 APP 的版本，裝置和使用者的分組。面對這些需求，我們遇到了一些挑戰：
- 首先是移動裝置和 APP 的間斷可用性。移動裝置通常采用無線連接配接，并且隻允許前台運作一個 APP，而使用者會喜歡頻繁的切換不同的 APP，是以從 APP 角度看，每台移動端裝置的可用性是動态的。這也意味着傳統的基于推拉的部署方式無法保證良好的時效性，并會在雲上産生較高的負載。
- 其次是潛在的任務失敗。一個移動 APP 是以單程序來運作的，一個任務的失敗會影響整個 APP 的運作，嚴重影響使用者體驗。由于大規模機器學習部署需求，在所有機型測試每一個預發任務是不現實不可行的。
在部署平台的細節方面，對于機器學習任務的管理主要通過 GIT 實作的多個任務的隔離，以及對每個任務的版本控制。同時支援多人的協作開發和權限管理。每一個任務管理作為一個給 Git Group，每個場景對應一個 GIT 倉庫，場景中每個機器學習任務對應一個分支，而任務的每個版本對應一個 Tag。
任務相關的檔案也被機器化管理。主要分為兩類，一類是可共享的檔案，該類型的檔案可被大量移動端裝置共享，例如使用特定 APP 版本的集合；另一種是獨占型裝置，隻能被少量移動端裝置，甚至單個裝置所使用。這些檔案可以通過 CDN 或者 CEN 被請求。
任務檔案的分類進一步支援統一和個性化的部署政策：
統一政策：支援通過 APP 版本對裝置進行分組，進行任務釋出。
個性化部署政策：支援通過移動端裝置資訊，如作業系統及其版本、裝置性能，以及使用者側資訊，例如年齡、喜好進行分組釋出。根據組中裝置數量，粗粒度的統一的任務部署通常隻涉及到共享檔案，而細粒度的個性優化任務，還會涉及到獨占檔案。
在極緻個性化的場景中，還支援特定的使用者定制化，獨占性的機器學習任務，部署到某台移動端機器學習任務上。為了保證機器學習部署的時效性，我們提出了基于短連接配接，先推後拉的部署方案。其中推的功能主要複用了端側業務 HTTP 請求，而拉的功能主要通過 CDN 和 CEN 來實作。此外為了提升任務部署的魯棒性，在任務釋出前我們基于雲測計算容器，引入了任務模拟測試環節。在任務釋出中強制分步釋出，并在任務失敗時，支援任務的復原。
--
06
Evaluation Results
接下來介紹一些實驗結果。
1. Practical Performance in E-Commerce Scenarios
首先，介紹 Walle 系統子產品在阿裡電商場景的實際性能。
上圖展示了在智能看點任務中的性能。淘寶直播場景中，智能看點任務是指通過機器學習方法，自動定位出主播講解商品的看點的一個時間點，從未提升使用者體驗。在傳統基于雲服務的鍊路下，雲上的負載非常高，以緻于隻能分析部分的直播視訊流以及視訊流中采樣出的部分幀。為了突破上述瓶頸，我們将輕量化的小模型部署到每個直播組的移動端裝置上，如果端側模型能夠以較高的置信度識别出直播視訊流中的看點，那麼這些看點在後處理以後，會展示給使用者。隻有識别置信度比較低的一些視訊流，約占視訊流的 20% 左右，才需要上傳到雲上，利用大模型進行處理。相比以前的純雲的鍊路，引入 Walle 之後的新鍊路，将雲側負載降低了 87%，将覆寫的視訊流數量提升了 123%，并将機關雲算力産出的看點增加了 74%，并且在部分真機測試中開銷小于 150ms。
上述結果凸顯了端雲協同的學習架構的實用性，以及 Walle 的高性能。
上圖是電商推薦的資料管道。
商品頁面浏覽特征，記錄了使用者在某些特定商品詳情頁面的具體行為。該特征對于推薦模型起到了特别重要的作用。雲側原有的 IPV 生産鍊路，需要将所有的使用者原始資料上傳。生産每一個特征的時間在 30 秒左右，并且需要消耗大量計算、通信、存儲資源，并且存在 0.7% 的錯誤率。相比之下，Walle 新的資料管道，可以在端側完成 IPV 特征的生産，整個流程上圖左側所示。平均每條 IPV 生産的端側延時僅為 44.16 毫秒，同時縮減了超過 90% 的資料量，并且保證了特征的準确率。這些結果表明，相比主流基于雲的資料管道，Walle 端雲協同的資料管道大幅提升了特征生産和消費的時效性和正确性。
為了測試 Walle 部署平台的時效性和規模化，我們随機挑選了一個線上的機器學習任務，并監控了其部署到目标裝置上的整個流程。在保證任務穩定性的前提下，Walle 部署平台成功覆寫了 700 萬台線上裝置，并且隻用了 7 分鐘；而覆寫全部 2200 萬台裝置，需要 19 分鐘。
2. Extensive Micro-Benchmark Testing Results
除了實際業務應用的性能測試以外，我們還對 MNN python 虛拟機以及實時通道進行了廣泛的基準測試。
我們在安卓和 IOS 移動端裝置，以及 Linux 伺服器主流硬體後端，對 MNN、TensorFlow（Lite）和 PyTorch（Mobile）進行了對比測試。測試采用了自然語言了解在推薦領域常用的七個模型。結果表明，MNN 在幾乎所有測試樣例中的性能都超過了其它深度學習架構。除了高性能外，MNN 還支援所有移動端、硬體後端，每一個模型的運作，而 TensorFlow（Lite）和 PyTorch 則無法支援某些硬體後端或模型，是以 MNN 在端側的通用性是更好的。
此外我們還對 MNN 和 TVM 進行了對比測試。實驗表明，一方面 TVM 的自動調優和編譯大約需要耗費幾千秒，而 MNN 在運作時的半自動搜尋隻需要幾百毫秒。結合 MNN 和 TVM 在設計和實際部署上的差別，可以得出，MNN 能夠支援涉及大規模異構硬體後端并需要任務頻繁疊代的産業化場景，TVM 則相對是不可行的。另一個方面，在每一個硬體後端上，每個模型的推理時間方面，MNN 也是低于 TVM 的，尤其是在 GPU 伺服器上，這主要是 MNN 的手工算子優化的功效。
我們還對 Python 線程級虛拟機和 Cpython 進行了對比測試。通過對 3000 萬次的線上執行任務資料進行統計，我們發現在涉及不同計算量的三種任務上，python 線程級虛拟機性能是大幅提升的。主要是由于 python 線程級虛拟機解除了 GIL 的限制，并支援了任務級的多線程并發。最後是關于實時通道的延時。通過對 3.6 億次資料上傳任務的統計，發現超過 90% 的上傳量小于 3kb，平均延時低于 250 毫秒，而僅僅有千分之一的上傳量達到了 30kb，平均延時也僅 400 多毫秒。
--
07
Summary
最後，對 Walle 相關工作進行一下簡單的總結。
- Walle 是第一個端到端、通用型、規模化産業應用的端雲協同系統。
- 計算容器包括 MNN 深度學習架構，它引入幾何計算以大幅減人工優化的工作量，以及半自動搜尋以确定運作時優化的最佳後端；還包括 Python 虛拟機，它是第一個解除 GIL 限制，并支援任務級多線程的虛拟機，也是第一個移植到移動裝置的虛拟機。
- Walle 新的資料管道，通過引入全新的端側流處理架構，并且通過基于 trie 的任務觸發管理機制，實作了端側多個流處理任務的批量觸發。我們還在端雲之間建立了實時的傳輸通道，以支援資料百毫秒級别的上傳下載下傳。
- Walle 部署平台支援細粒度、分布式的任務管理，采取推拉結合、多批次任務釋出的方式，保證了時效性和穩定性。同時支援統一和定制化的多粒度任務部署政策。
- 通過電商直播和推薦場景的實測，以及廣泛的基準測試，證明了 Walle 的優越性。
- Walle 一直在阿裡巴巴大規模使用，并且 MNN 已經開源并在社群中具有廣泛影響。
--
08
問答環節
Q1：這套系統對阿裡的名額影響有哪些？
A1：推薦的話在端上重排的業務，也是廣泛落地的。另一塊是直播這一塊。
Q2：walle 是基于 MNN 打造的嗎？是否開源？
A2：Walle 中的計算容器是基于 MNN2.0 打造的，這一塊是開源的，其他部分是不開源的。
Q3：walle 是否屬于橫向聯邦學習的範疇？
A3：在聯邦學習中，從任務配置設定來看，端側負責訓練任務，雲側負責模型聚合任務；從互動機制來看，采用多端對雲的架構，單這些都屬于算法協同機制的事情。Walle 則面向一般化的端雲協同，并且屬于系統層面。
Q4：可以講一下 python 綁定虛拟機的一些方法嗎？
A4：看一下論文的一些細節。
Q5：推薦模型更新是怎麼做的？
A5：在端上探索基于 finetune 或者增量式學習，儲存不同的模型版本。然後在推理的時候做加載。雲上的更新周期比較慢一些。
Q6：通過 walle 部署了多少個模型？
A6：通過 walle 累計部署了超過 1000 個，現在統計有 300 個。
今天的就分享就到這裡，謝謝大家。
｜分享嘉賓｜
牛超越 博士
阿裡巴巴 淘寶Meta技術團隊 學術合作實習生
牛超越于2021年在上海交通大學計算機科學與工程系取得博士學位，曾獲中國計算機學會（CCF）優秀博士學位論文獎，目前擔任博士後研究員。同時，自2018年起在阿裡巴巴淘寶Meta技術團隊做學術合作實習生，作為team leader承擔了聯邦學習、端雲協同學習、移動端個性化推薦系統等項目。
｜《資料智能知識地圖》下載下傳｜
上下滑動⬆️⬇️，檢視《資料智能知識地圖》全景圖，高清版請關注公衆号“大話數智”下載下傳
｜DataFun新媒體矩陣｜
｜關于DataFun｜
專注于大資料、人工智能技術應用的分享與交流。發起于2017年，在北京、上海、深圳、杭州等城市舉辦超過100+線下和100+線上沙龍、論壇及峰會，已邀請超過2000位專家和學者參與分享。其公衆号 DataFunTalk 累計生産原創文章900+，百萬+閱讀，16萬+精準粉絲。