作者：字節跳動技術——白昆侖
AI 技術現在已經覆蓋到了互聯網的方方面面，在云端的應用已經非常廣泛和成熟。為了追隨人工智能的浪潮，各大廠商也在不斷加強移動設備的 AI 能力，主要體現在以下方面：
通過專門為 AI 能力定制的 Soc，提供更好的計算能力
輕量級推理引擎技術的成熟（例如：TensorFlow Lite），對算力有限的移動設備更加友好
模型壓縮技術使得模型體積大大降低，使得其部署在移動設備上成為了可能
經過這幾年的飛速發展，在終端部署 AI 能力漸漸步入了大眾的視野，端智能的概念應運而生，旨在提供在終端設備上使用 AI 能力的完整框架。相比云端，端智能具備以下優勢：
低延遲：節省了網絡請求的延遲
安全性：更好的保護用戶隱私數據
定制化：根據用戶習慣進行本地訓練，逐步迭代優化，真正做到用戶定制
更豐富的特征：可獲取更加豐富的用戶特征，提高預測的準確率
節約云端資源：與云端推理結合，在終端進行預處理，從而降低對云端算力的壓力
更豐富的使用場景：人臉識別、手勢識別、翻譯、興趣預測、圖像搜索等智能場景已被廣泛使用，更多的應用場景也在不斷涌現。
在端智能的應用方面，Google、Facebook、Apple 等巨頭已經走在了前列。Google 提出了 Recommendation Android App 的概念，根據用戶興趣進行內容推薦。Apple 的 Face ID、Siri 推薦也都是端智能應用的代表。
圖 1-1 Recommendation Android App
在國內，阿里、騰訊等企業也先后進行了端智能的嘗試。阿里在手淘中寶貝列表重排、智能刷新、跳失點預測、智能 Push、拍立淘（以圖搜圖）等多個場景實現了端智能的落地，并推出了 MNN 神經網絡深度學習框架。騰訊則推出自研的 NCNN 框架，并在醫療、翻譯、游戲、智能音箱等領域廣泛應用端智能技術。
圖 1-2 典型端智能開發流程示意圖
一個典型的端智能開發流程如圖 1-2 所示。首先在云端利用收集的數據進行算法設計和模型訓練，并輸出模型。此時的模型并不適用于移動設備，需通過模型轉換和壓縮轉換為移動端推理引擎所支持的格式。最后通過云端配置，將算法和模型動態部署到目標設備上。在終端設備上，在合適的使用場景和時機觸發推理流程，根據模型進行輸入數據的整理并傳遞至推理引擎，獲取并解析推理結果后進行相應的邏輯調整和反饋。
在移動設備部署端智能并非易事，現階段的開發流程存在諸多的問題需要我們一一解決。
開發效率
按照典型的端智能開發流程，首先需要算法工程師在云端訓練和輸出模型，模型決定了數據的輸入、輸出格式。下一階段，客戶端工程師需進行端側的開發來適配當前模型，包括輸入數據的收集和整理、輸出數據的解析等。開發完畢后，再交由測試工程師進行后續的質量保障。這期間需要多個角色的協同和溝通，整體開發鏈路冗長且低效。
靈活性
正如上面所提到的，一旦模型確定后，其輸入輸出就遵循固定的格式。如果模型想調整輸入數據的策略，就一定要同時修改客戶端邏輯。因此，線上驗證與功能迭代的靈活性受到了極大的限制，無形中拉長了整個功能上線周期。此外，不同端智能應用場景（CV、推薦等）也存在著較大的需求差異，如何滿足不同的業務場景需求也是需要解決的頭部問題。
端上環境復雜性
構建一套完整的端智能運行環境并非易事，除了在云端進行模型的訓練和下發，還需要在客戶端進行數據的收集、存儲、處理，硬件資源的評估與調度，推理引擎的選擇，操作系統的兼容，推理任務的管理與調度等等。這些問題無形之中提高了端智能應用的門檻，如何能夠屏蔽這些復雜的端上環境也是端智能目前面臨重要挑戰。
為了解決上面的問題，Pitaya 與 MLX 團隊進行了深度合作，共建了一套從端（云端）到端（終端）的全鏈路動態部署方案。MLX 是云端的模型訓練開發平臺，提供模型訓練、轉化、調試、發布、A/B 等能力。客戶端 Pitaya SDK 則提供特征工程、推理引擎、算法包管理、任務管理、監控等端上能力。兩者深度整合，覆蓋了端智能流程的各個環節，大大降低端智能的應用門檻。
Pitaya-MLX深度能力融合
在介紹 Pitaya 前，先著重介紹一下 MLX 平臺。在進行模型訓練的過程中，我們會碰到很多的環境差異，比如不同的數據源的存儲方結構、數據格式，不同的機器學習框架，以及不同操作系統環境和基礎設施能力的搭建。MLX 平臺就是為了解決上面的問題而誕生的。它提供了一個在云端實現模型訓練、轉換并將其最終產品化的服務平臺，通過廣泛接入了各類計算框架和服務平臺，省去了復雜的環境搭建工作。
圖 3-1-1 MLX 架構示意圖
MLX 的架構如圖 3-1-1 所示：
Base Infra：提供了諸多基礎設施能力支撐上層功能。
ML：提供對各類機器學習框架的支持，主要分為 Scheduler、Model Training、Model Serving 三部分，是模型訓練和轉換的核心能力。
Core：開發人員直接接觸的主要功能，在算法開發環節 MLX 提供 Notebook、Web Studio 等在線 IDE 編輯環境，支持 DAG Designer 的拖拽模式的工作流控制，更加簡單易用。在模型產品化的流程中，覆蓋了訓練、任務管理、導出、發布等整個鏈路環節。
Scene：在以上基礎能力的支撐下，MLX 平臺上可以搭建不同的智能場景任務，例如：NLP、CV、GDBT，而 Pitaya 就是其中的新成員。
Pitaya 將自身的工作流與 MLX 平臺特性進行了深度的整合，如下圖所示。在傳統的端智能開發流程中，云端僅負責模型的輸出，能夠動態部署下模型。而在 Pitaya 工作流中，“算法包”是一個完整資源的集合。“算法包”包括推理過程中使用到的模型，也包括算法邏輯及其依賴庫信息，這些所有的內容被統一打包成為“算法包”。如果客戶端同步了算法包內容，且具備算法包運行所需的各項能力，那么就可以在運行該算法包，實現一個完整的推理流程。
圖 3-2-1 Pitaya 與 MLX 協同工作示意圖
算法包的開發過程中，可以臨時生成測試算法包。通過掃碼將宿主 App 與 Pitaya-MLX 平臺建立數據通道，推送測試算法包到客戶端，通過真機運行和調試算法包，輸出的日志信息也會在 MLX 的 IDE 環境展示，從而實現云端調試的完整體驗。得益于 Pitaya 與 MLX 深度融合，算法工程師不再依賴客戶端工程師進行任何開發，就可以獨立完成算法在端上的運行與調試，極大的提升了算法開發的效率。
圖 3-2-2 Pitaya-MLX 平臺調試流程示意圖
當算法工程師完成算法包的調試后就可以將當前項目打包成一個算法包。每個業務場景都有一個當前 App 下的唯一 Business 標識，算法包與 Business 綁定。在 Pitaya-MLX 發布平臺可針對某一 Business 業務，從 App、App 版本、OS 版本、渠道等多個維度對算法包的下發進行配置與管理。發布平臺還與 A/B 平臺實現了數據打通，可以實現無縫的線上實驗對比，大大加快業務線上效果的驗證。
除了上面提到的常規配置能力，Pitaya-MLX 發布平臺還支持對當前設備機型進行性能打分，根據打分的結果來進行算法包的差異化下發。這種部署方式可以更加細粒度的對線上設備性能進行劃分，針對高性能或支持某些 AI 加速的設備下發精度更高的模型，而針對性能較弱的設備為了追求更好的使用體驗，則部署相對精簡的模型。
Pitaya 中一個核心能力就是“特征工程”。端上推理一般需要從原始數據生成輸入到模型中的特征，再由模型推理得到結果。如果需要業務方自行收集和保存原始數據，其工作量是巨大的。特征工程的作用就是幫助業務方無侵入式的收集端上的用戶特征數據，用于后續的推理預測。Pitaya 特征工程與 Applog SDK（事件統計 SDK）打通，支持在算法包中對推理過程中需要使用到的的 Applog Event 進行配置，當算法包在本地生效時，Pitaya 就可以根據算法包的配置收集數據。同時，Pitaya 也提供定制化的接口，用于關聯用戶行為上下文，例如：點擊、曝光、滑動等。在算法包運行過程中，可以通過特征工程的能力獲取用戶的原始數據，通過數據的處理生成模型需要的輸入數據。這種數據收集的方式較傳統鏈路具備更好的動態性和靈活性，讓業務方從繁重的數據處理工作中解放了出來。
此外，特征工程還支持上傳指定的數據至 MLX 平臺，用于云端的模型訓練，形成一個完整的數據閉環，如圖 3-2-1。
當一個算法包同步到了終端設備后，觸發算法包的運行可以有兩種方式。
Applog Event 觸發：通過算法包配置可以觸發運行的 Applog Event，當有監控到有對應 Applog Event 事件時，則會間接觸發該算法包的運行。該觸發方式是提供給業務方一個通過 Applog Event 觸發算法包執行的時機，可在算法包中進行特征數據的提取與預處理等操作。
主動觸發：業務方在合適的場景和時機下主動調用 Pitaya 的接口（下圖所示為 Objective-C 上的調用接口），可自定義輸入數據和任務配置，在回調中獲取推理結果。
- (void)runBusiness:(NSString *)business input:(PTYInput *_Nullable)input config:(PTYTaskConfig *_Nullable)config taskCallback:(PTYTaskCallback _Nullable)taskCallback;每觸發一個算法包的運行實際上就相當于創建了一個任務（Task），Pitaya 內部的任務管理模塊會對任務進行統一的接管與處理。算法包是在 Pitaya 的運行容器中執行的，該容器為每一個任務提供獨立的運行環境，并通過 Pitaya 提供的接口來進行特征工程數據的存取和模型推理等。Pitaya 對推理流程和接口進行了高度的抽象，支持不同類型的推理引擎的集成（ByteNN、ByteDT、TFLite），最大程度上的滿足了不同業務方的使用需求，降低項目遷移到 Pitaya 框架的成本。
為了實現一鍵集成的使用體驗，Pitaya 內部打造了一套對任務進行全面、細致的監控體系。監控內容涵蓋以下幾個方面：
指標監控：任務 PV/UV、成功/失敗、算法包下載成功率/覆蓋率
性能監控：內存、各個鏈路階段耗時、初始化耗時
異常監控：任務卡死、失敗原因、網絡請求失敗
Pitaya SDK 將以上指標進行了分類整理，依托于 Slardar 平臺的數據展現能力，每個集成業務方都可以一鍵復制模板，在宿主 App 內建立完善的數據看板，真正做到開箱即用。
圖 3-2-3 Pitaya 監控數據示意圖
Pitaya 是專門為移動端打造的端智能一體化方案，與傳統方案相比，具備以下優勢：
降低了端智能使用成本，方便業務快速集成，拿到業務收益
完善的動態化能力，支持模型的快速迭代與效果驗證
提升多方協作的效率，讓算法工程師深入參與客戶端場景中
算法、模型高度復用，可以快速推廣已經驗證的方案
目前，字節跳動內已經有抖音、頭條、西瓜等眾多產品線基于 Pitaya 開始了端智能的實踐和探索，在此過程中我們也與業務方持續溝通，不斷打磨產品和使用體驗，并對未來 Pitaya 的發展方向進行如下規劃：
特征工程：強化特征工程能力，充分利用端側特有信息，結合云端數據，提供更加豐富和準確的數據。
模型自衍化：端智能的最大使用場景就是根據用戶自身的行為特征進行不斷的學習，從而更加符合使用者的習慣。為了達到這種效果，需要解決本地訓練數據、模型本地訓練的問題，以及建立一套對模型準確率評估和回退的管理機制。
通用 AI 能力建設：針對通用性的使用場景（網絡狀態預測等），Pitaya 可內置相關能力，快速推廣至業務方。
