作者：字節(jié)跳動技術(shù)——白昆侖

一、什么是端智能？

AI 技術(shù)現(xiàn)在已經(jīng)覆蓋到了互聯(lián)網(wǎng)的方方面面，在云端的應(yīng)用已經(jīng)非常廣泛和成熟。為了追隨人工智能的浪潮，各大廠商也在不斷加強移動設(shè)備的 AI 能力，主要體現(xiàn)在以下方面：

1. 通過專門為 AI 能力定制的 Soc，提供更好的計算能力

2. 輕量級推理引擎技術(shù)的成熟（例如：TensorFlow Lite），對算力有限的移動設(shè)備更加友好

3. 模型壓縮技術(shù)使得模型體積大大降低，使得其部署在移動設(shè)備上成為了可能

經(jīng)過這幾年的飛速發(fā)展，在終端部署 AI 能力漸漸步入了大眾的視野，端智能的概念應(yīng)運而生，旨在提供在終端設(shè)備上使用 AI 能力的完整框架。相比云端，端智能具備以下優(yōu)勢：

1. 低延遲：節(jié)省了網(wǎng)絡(luò)請求的延遲

2. 安全性：更好的保護(hù)用戶隱私數(shù)據(jù)

3. 定制化：根據(jù)用戶習(xí)慣進(jìn)行本地訓(xùn)練，逐步迭代優(yōu)化，真正做到用戶定制

4. 更豐富的特征：可獲取更加豐富的用戶特征，提高預(yù)測的準(zhǔn)確率

5. 節(jié)約云端資源：與云端推理結(jié)合，在終端進(jìn)行預(yù)處理，從而降低對云端算力的壓力

6. 更豐富的使用場景：人臉識別、手勢識別、翻譯、興趣預(yù)測、圖像搜索等智能場景已被廣泛使用，更多的應(yīng)用場景也在不斷涌現(xiàn)。

在端智能的應(yīng)用方面，Google、Facebook、Apple 等巨頭已經(jīng)走在了前列。Google 提出了 Recommendation Android App 的概念，根據(jù)用戶興趣進(jìn)行內(nèi)容推薦。Apple 的 Face ID、Siri 推薦也都是端智能應(yīng)用的代表。

圖 1-1 Recommendation Android App

在國內(nèi)，阿里、騰訊等企業(yè)也先后進(jìn)行了端智能的嘗試。阿里在手淘中寶貝列表重排、智能刷新、跳失點預(yù)測、智能 Push、拍立淘（以圖搜圖）等多個場景實現(xiàn)了端智能的落地，并推出了 MNN 神經(jīng)網(wǎng)絡(luò)深度學(xué)習(xí)框架。騰訊則推出自研的 NCNN 框架，并在醫(yī)療、翻譯、游戲、智能音箱等領(lǐng)域廣泛應(yīng)用端智能技術(shù)。

圖 1-2 典型端智能開發(fā)流程示意圖

一個典型的端智能開發(fā)流程如圖 1-2 所示。首先在云端利用收集的數(shù)據(jù)進(jìn)行算法設(shè)計和模型訓(xùn)練，并輸出模型。此時的模型并不適用于移動設(shè)備，需通過模型轉(zhuǎn)換和壓縮轉(zhuǎn)換為移動端推理引擎所支持的格式。最后通過云端配置，將算法和模型動態(tài)部署到目標(biāo)設(shè)備上。在終端設(shè)備上，在合適的使用場景和時機(jī)觸發(fā)推理流程，根據(jù)模型進(jìn)行輸入數(shù)據(jù)的整理并傳遞至推理引擎，獲取并解析推理結(jié)果后進(jìn)行相應(yīng)的邏輯調(diào)整和反饋。

二、端智能面臨的挑戰(zhàn)

在移動設(shè)備部署端智能并非易事，現(xiàn)階段的開發(fā)流程存在諸多的問題需要我們一一解決。

1. 開發(fā)效率

按照典型的端智能開發(fā)流程，首先需要算法工程師在云端訓(xùn)練和輸出模型，模型決定了數(shù)據(jù)的輸入、輸出格式。下一階段，客戶端工程師需進(jìn)行端側(cè)的開發(fā)來適配當(dāng)前模型，包括輸入數(shù)據(jù)的收集和整理、輸出數(shù)據(jù)的解析等。開發(fā)完畢后，再交由測試工程師進(jìn)行后續(xù)的質(zhì)量保障。這期間需要多個角色的協(xié)同和溝通，整體開發(fā)鏈路冗長且低效。

1. 靈活性

正如上面所提到的，一旦模型確定后，其輸入輸出就遵循固定的格式。如果模型想調(diào)整輸入數(shù)據(jù)的策略，就一定要同時修改客戶端邏輯。因此，線上驗證與功能迭代的靈活性受到了極大的限制，無形中拉長了整個功能上線周期。此外，不同端智能應(yīng)用場景（CV、推薦等）也存在著較大的需求差異，如何滿足不同的業(yè)務(wù)場景需求也是需要解決的頭部問題。

1. 端上環(huán)境復(fù)雜性

構(gòu)建一套完整的端智能運行環(huán)境并非易事，除了在云端進(jìn)行模型的訓(xùn)練和下發(fā)，還需要在客戶端進(jìn)行數(shù)據(jù)的收集、存儲、處理，硬件資源的評估與調(diào)度，推理引擎的選擇，操作系統(tǒng)的兼容，推理任務(wù)的管理與調(diào)度等等。這些問題無形之中提高了端智能應(yīng)用的門檻，如何能夠屏蔽這些復(fù)雜的端上環(huán)境也是端智能目前面臨重要挑戰(zhàn)。

三、Pitaya 端智能一體化解決方案

為了解決上面的問題，Pitaya 與 MLX 團(tuán)隊進(jìn)行了深度合作，共建了一套從端（云端）到端（終端）的全鏈路動態(tài)部署方案。MLX 是云端的模型訓(xùn)練開發(fā)平臺，提供模型訓(xùn)練、轉(zhuǎn)化、調(diào)試、發(fā)布、A/B 等能力?？蛻舳?Pitaya SDK 則提供特征工程、推理引擎、算法包管理、任務(wù)管理、監(jiān)控等端上能力。兩者深度整合，覆蓋了端智能流程的各個環(huán)節(jié)，大大降低端智能的應(yīng)用門檻。

Pitaya-MLX深度能力融合

1. MLX 平臺

在介紹 Pitaya 前，先著重介紹一下 MLX 平臺。在進(jìn)行模型訓(xùn)練的過程中，我們會碰到很多的環(huán)境差異，比如不同的數(shù)據(jù)源的存儲方結(jié)構(gòu)、數(shù)據(jù)格式，不同的機(jī)器學(xué)習(xí)框架，以及不同操作系統(tǒng)環(huán)境和基礎(chǔ)設(shè)施能力的搭建。MLX 平臺就是為了解決上面的問題而誕生的。它提供了一個在云端實現(xiàn)模型訓(xùn)練、轉(zhuǎn)換并將其最終產(chǎn)品化的服務(wù)平臺，通過廣泛接入了各類計算框架和服務(wù)平臺，省去了復(fù)雜的環(huán)境搭建工作。

圖 3-1-1 MLX 架構(gòu)示意圖

MLX 的架構(gòu)如圖 3-1-1 所示：

• Base Infra：提供了諸多基礎(chǔ)設(shè)施能力支撐上層功能。

• ML：提供對各類機(jī)器學(xué)習(xí)框架的支持，主要分為 Scheduler、Model Training、Model Serving 三部分，是模型訓(xùn)練和轉(zhuǎn)換的核心能力。

• Core：開發(fā)人員直接接觸的主要功能，在算法開發(fā)環(huán)節(jié) MLX 提供 Notebook、Web Studio 等在線 IDE 編輯環(huán)境，支持 DAG Designer 的拖拽模式的工作流控制，更加簡單易用。在模型產(chǎn)品化的流程中，覆蓋了訓(xùn)練、任務(wù)管理、導(dǎo)出、發(fā)布等整個鏈路環(huán)節(jié)。

• Scene：在以上基礎(chǔ)能力的支撐下，MLX 平臺上可以搭建不同的智能場景任務(wù)，例如：NLP、CV、GDBT，而 Pitaya 就是其中的新成員。

2. Pitaya

2.1 算法包

Pitaya 將自身的工作流與 MLX 平臺特性進(jìn)行了深度的整合，如下圖所示。在傳統(tǒng)的端智能開發(fā)流程中，云端僅負(fù)責(zé)模型的輸出，能夠動態(tài)部署下模型。而在 Pitaya 工作流中，“算法包”是一個完整資源的集合?！八惴ò卑ㄍ评磉^程中使用到的模型，也包括算法邏輯及其依賴庫信息，這些所有的內(nèi)容被統(tǒng)一打包成為“算法包”。如果客戶端同步了算法包內(nèi)容，且具備算法包運行所需的各項能力，那么就可以在運行該算法包，實現(xiàn)一個完整的推理流程。

圖 3-2-1 Pitaya 與 MLX 協(xié)同工作示意圖

2.2 開發(fā)與調(diào)試

算法包的開發(fā)過程中，可以臨時生成測試算法包。通過掃碼將宿主 App 與 Pitaya-MLX 平臺建立數(shù)據(jù)通道，推送測試算法包到客戶端，通過真機(jī)運行和調(diào)試算法包，輸出的日志信息也會在 MLX 的 IDE 環(huán)境展示，從而實現(xiàn)云端調(diào)試的完整體驗。得益于 Pitaya 與 MLX 深度融合，算法工程師不再依賴客戶端工程師進(jìn)行任何開發(fā)，就可以獨立完成算法在端上的運行與調(diào)試，極大的提升了算法開發(fā)的效率。

圖 3-2-2 Pitaya-MLX 平臺調(diào)試流程示意圖

2.3 動態(tài)部署

當(dāng)算法工程師完成算法包的調(diào)試后就可以將當(dāng)前項目打包成一個算法包。每個業(yè)務(wù)場景都有一個當(dāng)前 App 下的唯一 Business 標(biāo)識，算法包與 Business 綁定。在 Pitaya-MLX 發(fā)布平臺可針對某一 Business 業(yè)務(wù)，從 App、App 版本、OS 版本、渠道等多個維度對算法包的下發(fā)進(jìn)行配置與管理。發(fā)布平臺還與 A/B 平臺實現(xiàn)了數(shù)據(jù)打通，可以實現(xiàn)無縫的線上實驗對比，大大加快業(yè)務(wù)線上效果的驗證。

除了上面提到的常規(guī)配置能力，Pitaya-MLX 發(fā)布平臺還支持對當(dāng)前設(shè)備機(jī)型進(jìn)行性能打分，根據(jù)打分的結(jié)果來進(jìn)行算法包的差異化下發(fā)。這種部署方式可以更加細(xì)粒度的對線上設(shè)備性能進(jìn)行劃分，針對高性能或支持某些 AI 加速的設(shè)備下發(fā)精度更高的模型，而針對性能較弱的設(shè)備為了追求更好的使用體驗，則部署相對精簡的模型。

2.4 特征工程

Pitaya 中一個核心能力就是“特征工程”。端上推理一般需要從原始數(shù)據(jù)生成輸入到模型中的特征，再由模型推理得到結(jié)果。如果需要業(yè)務(wù)方自行收集和保存原始數(shù)據(jù)，其工作量是巨大的。特征工程的作用就是幫助業(yè)務(wù)方無侵入式的收集端上的用戶特征數(shù)據(jù)，用于后續(xù)的推理預(yù)測。Pitaya 特征工程與 Applog SDK（事件統(tǒng)計 SDK）打通，支持在算法包中對推理過程中需要使用到的的 Applog Event 進(jìn)行配置，當(dāng)算法包在本地生效時，Pitaya 就可以根據(jù)算法包的配置收集數(shù)據(jù)。同時，Pitaya 也提供定制化的接口，用于關(guān)聯(lián)用戶行為上下文，例如：點擊、曝光、滑動等。在算法包運行過程中，可以通過特征工程的能力獲取用戶的原始數(shù)據(jù)，通過數(shù)據(jù)的處理生成模型需要的輸入數(shù)據(jù)。這種數(shù)據(jù)收集的方式較傳統(tǒng)鏈路具備更好的動態(tài)性和靈活性，讓業(yè)務(wù)方從繁重的數(shù)據(jù)處理工作中解放了出來。

此外，特征工程還支持上傳指定的數(shù)據(jù)至 MLX 平臺，用于云端的模型訓(xùn)練，形成一個完整的數(shù)據(jù)閉環(huán)，如圖 3-2-1。

2.5 算法包的運行

當(dāng)一個算法包同步到了終端設(shè)備后，觸發(fā)算法包的運行可以有兩種方式。

1. Applog Event 觸發(fā)：通過算法包配置可以觸發(fā)運行的 Applog Event，當(dāng)有監(jiān)控到有對應(yīng) Applog Event 事件時，則會間接觸發(fā)該算法包的運行。該觸發(fā)方式是提供給業(yè)務(wù)方一個通過 Applog Event 觸發(fā)算法包執(zhí)行的時機(jī)，可在算法包中進(jìn)行特征數(shù)據(jù)的提取與預(yù)處理等操作。

2. 主動觸發(fā)：業(yè)務(wù)方在合適的場景和時機(jī)下主動調(diào)用 Pitaya 的接口（下圖所示為 Objective-C 上的調(diào)用接口），可自定義輸入數(shù)據(jù)和任務(wù)配置，在回調(diào)中獲取推理結(jié)果。

每觸發(fā)一個算法包的運行實際上就相當(dāng)于創(chuàng)建了一個任務(wù)（Task），Pitaya 內(nèi)部的任務(wù)管理模塊會對任務(wù)進(jìn)行統(tǒng)一的接管與處理。算法包是在 Pitaya 的運行容器中執(zhí)行的，該容器為每一個任務(wù)提供獨立的運行環(huán)境，并通過 Pitaya 提供的接口來進(jìn)行特征工程數(shù)據(jù)的存取和模型推理等。Pitaya 對推理流程和接口進(jìn)行了高度的抽象，支持不同類型的推理引擎的集成（ByteNN、ByteDT、TFLite），最大程度上的滿足了不同業(yè)務(wù)方的使用需求，降低項目遷移到 Pitaya 框架的成本。

2.6 任務(wù)監(jiān)控

為了實現(xiàn)一鍵集成的使用體驗，Pitaya 內(nèi)部打造了一套對任務(wù)進(jìn)行全面、細(xì)致的監(jiān)控體系。監(jiān)控內(nèi)容涵蓋以下幾個方面：

• 指標(biāo)監(jiān)控：任務(wù) PV/UV、成功/失敗、算法包下載成功率/覆蓋率

• 性能監(jiān)控：內(nèi)存、各個鏈路階段耗時、初始化耗時

• 異常監(jiān)控：任務(wù)卡死、失敗原因、網(wǎng)絡(luò)請求失敗

Pitaya SDK 將以上指標(biāo)進(jìn)行了分類整理，依托于 Slardar 平臺的數(shù)據(jù)展現(xiàn)能力，每個集成業(yè)務(wù)方都可以一鍵復(fù)制模板，在宿主 App 內(nèi)建立完善的數(shù)據(jù)看板，真正做到開箱即用。

圖 3-2-3 Pitaya 監(jiān)控數(shù)據(jù)示意圖

四、總結(jié)與展望

Pitaya 是專門為移動端打造的端智能一體化方案，與傳統(tǒng)方案相比，具備以下優(yōu)勢：

1. 降低了端智能使用成本，方便業(yè)務(wù)快速集成，拿到業(yè)務(wù)收益

2. 完善的動態(tài)化能力，支持模型的快速迭代與效果驗證

3. 提升多方協(xié)作的效率，讓算法工程師深入?yún)⑴c客戶端場景中

4. 算法、模型高度復(fù)用，可以快速推廣已經(jīng)驗證的方案

目前，字節(jié)跳動內(nèi)已經(jīng)有抖音、頭條、西瓜等眾多產(chǎn)品線基于 Pitaya 開始了端智能的實踐和探索，在此過程中我們也與業(yè)務(wù)方持續(xù)溝通，不斷打磨產(chǎn)品和使用體驗，并對未來 Pitaya 的發(fā)展方向進(jìn)行如下規(guī)劃：

1. 特征工程：強化特征工程能力，充分利用端側(cè)特有信息，結(jié)合云端數(shù)據(jù)，提供更加豐富和準(zhǔn)確的數(shù)據(jù)。

2. 模型自衍化：端智能的最大使用場景就是根據(jù)用戶自身的行為特征進(jìn)行不斷的學(xué)習(xí)，從而更加符合使用者的習(xí)慣。為了達(dá)到這種效果，需要解決本地訓(xùn)練數(shù)據(jù)、模型本地訓(xùn)練的問題，以及建立一套對模型準(zhǔn)確率評估和回退的管理機(jī)制。

3. 通用 AI 能力建設(shè)：針對通用性的使用場景（網(wǎng)絡(luò)狀態(tài)預(yù)測等），Pitaya 可內(nèi)置相關(guān)能力，快速推廣至業(yè)務(wù)方。