[[408914]]

一、Paddle Lite 和 PaddleSlim

目前在深度學(xué)習(xí)領(lǐng)域分類兩個派別，一派為學(xué)院派，研究強大、復(fù)雜的模型網(wǎng)絡(luò)和實驗方法，為了追求更高的性能；另一派為工程派，旨在將算法更穩(wěn)定、高效的落地在硬件平臺上，效率是其追求的目標。復(fù)雜的模型固然具有更好的性能，但是高額的存儲空間、計算資源消耗是使其難以有效的應(yīng)用在各硬件平臺上的重要原因。所以，卷積神經(jīng)網(wǎng)絡(luò)日益增長的深度和尺寸為深度學(xué)習(xí)在移動端的部署帶來了巨大的挑戰(zhàn)，深度學(xué)習(xí)模型壓縮與加速成為了學(xué)術(shù)界和工業(yè)界都重點關(guān)注的研究領(lǐng)域之一。

1. 端側(cè)推理引擎的背景

隨著深度學(xué)習(xí)的快速發(fā)展、特別是小型網(wǎng)絡(luò)模型的不斷成熟，原本應(yīng)用到云端的深度學(xué)習(xí)推理，就可以放到終端上來做，比如手機、手表、攝像頭、傳感器、音響，也就是端智能。此外，可用于深度學(xué)習(xí)計算的硬件也有井噴之勢，從 Intel 到 Nvidia、ARM、Mali、寒武紀等等。相比服務(wù)端智能，端智能具有延時低、節(jié)省資源、保護數(shù)據(jù)隱私等優(yōu)勢。目前已經(jīng)在 AI 攝像、視覺特效等場景廣泛應(yīng)用。

然而，深度學(xué)習(xí)推理場景中，多樣的平臺、不同的芯片對推理庫的能力提出了更高的要求。端側(cè)模型的推理經(jīng)常面臨算力和內(nèi)存的限制，加上日趨異構(gòu)化的硬件平臺和復(fù)雜的端側(cè)使用狀況，導(dǎo)致端側(cè)推理引擎的架構(gòu)能力頗受挑戰(zhàn)。端側(cè)推理引擎是端智能應(yīng)用的核心模塊，需要在有限算力、有限內(nèi)存等限制下，高效地利用資源，快速完成推理。因此，飛槳期望提供面向不同業(yè)務(wù)算法場景、不同訓(xùn)練框架、不同部署環(huán)境， 簡單、高效、安全的端側(cè)推理引擎。

2. Paddlelite 的特色

為了能夠完整地支持眾多的硬件架構(gòu)，實現(xiàn)在這些硬件之上的各種人工智能應(yīng)用的性能優(yōu)化，飛槳提供端側(cè)推理引擎 Paddle Lite。截止到現(xiàn)在，Paddle Lite 已廣泛應(yīng)用于搜索廣告、手機百度、百度地圖、全民小視頻等多個重要業(yè)務(wù)。

Paddle Lite 具備如下產(chǎn)品特色：

1） 移動端和嵌入端的模型部署工具，可使用其部署 PaddlePaddle、TensorFlow、Caffe、ONNX 等多種平臺的主流模型格式，包括 MobileNetV1、YoloV3、UNet、SqueezeNet 等主流模型。

2）多種語言的 API 接口：C++/Java/Python，便于嵌入各種業(yè)務(wù)程序。

3）豐富的端側(cè)模型：resnet、effcientnet、shufflenet、mobilenet、unet、facedetection、unet、ocr_attention 等。

4）支持豐富的移動和嵌入端芯片：ARM CPU、Mali GPU、Adreno GPU，昇騰 &麒麟 NPU，MTK NeuroPilot，RK NPU，寒武紀 NPU，X86 CPU，NVIDIA GPU，F(xiàn)PGA 等多種硬件平臺。

5）除了 Lite 本身提供的性能優(yōu)化策略外，還可以結(jié)合 PaddleSlim 可以對模型進行壓縮和量化，以達到更好的性能。

3. 架構(gòu)設(shè)計

架構(gòu)圖如上所示，Paddle-Lite 架構(gòu)側(cè)重多硬件、高性能的支持，其主要設(shè)計思想如下：

1）引入 Type system，強化多硬件、量化方法、data layout 的混合調(diào)度能力。

2）硬件細節(jié)隔離，通過不同編譯開關(guān)，對支持的任何硬件可以自由插拔。

3）引入 MIR(Machine IR) 的概念，強化待執(zhí)行環(huán)境下的優(yōu)化支持。

4）圖優(yōu)化模塊和執(zhí)行引擎實現(xiàn)了良好的解耦拆分，保證預(yù)測執(zhí)行階段的輕量和高效率。

二、AIOps 的思考

1. 背景

AIOps，最初的定義是 Algorithm IT Operations，是利用運維算法來實現(xiàn)運維的自動化，最終走向無人化運維。隨著技術(shù)成熟，逐步確定為 Artificial Intelligence for IT Operations——智能運維，將人工智能應(yīng)用于運維領(lǐng)域，基于已有的運維數(shù)據(jù)（日志、監(jiān)控信息、應(yīng)用信息等），通過機器學(xué)習(xí)的方式來進一步解決自動化運維無法解決的問題。

早期的運維工作大部分是由運維人員手工完成的，手工運維在互聯(lián)網(wǎng)業(yè)務(wù)快速擴張、人力成本高企的時代，難以維系。于是，自動化運維應(yīng)運而生，它主要通過可被自動觸發(fā)、預(yù)定義規(guī)則的腳本，來執(zhí)行常見、重復(fù)性的運維工作，從而減少人力成本，提高運維的效率?？偟膩碚f，自動化運維可以認為是一種基于行業(yè)領(lǐng)域知識和運維場景領(lǐng)域知識的專家系統(tǒng)。隨著整個互聯(lián)網(wǎng)業(yè)務(wù)急劇膨脹，以及服務(wù)類型的復(fù)雜多樣，“基于人為指定規(guī)則”的專家系統(tǒng)逐漸變得力不從心，自動化運維的不足，日益凸顯。

DevOps 的出現(xiàn)，部分解決了上述問題，它強調(diào)從價值交付的全局視角，但 DevOps 更強調(diào)橫向融合及打通，AIOps 則是 DevOps 在運維（技術(shù)運營）側(cè)的高階實現(xiàn)，兩者并不沖突。AIOps 不依賴于人為指定規(guī)則，主張由機器學(xué)習(xí)算法自動地從海量運維數(shù)據(jù)（包括事件本身以及運維人員的人工處理日志）中不斷地學(xué)習(xí)，不斷提煉并總結(jié)規(guī)則。AIOps 在自動化運維的基礎(chǔ)上，增加了一個基于機器學(xué)習(xí)的大腦，指揮監(jiān)測系統(tǒng)采集大腦決策所需的數(shù)據(jù)，做出分析、決策，并指揮自動化腳本去執(zhí)行大腦的決策，從而達到運維系統(tǒng)的整體目標。

下圖是百度運維發(fā)展歷程：

從 2014 年開始，從最開始的行業(yè)領(lǐng)域知識加上運維專家經(jīng)驗，到之后加上人工智能算法，演進成 AIOps，從數(shù)據(jù)建設(shè)和智能監(jiān)控場景入手，逐漸覆蓋到智能故障管理，變更管理，容量管理和服務(wù)咨詢。

綜上看，自動化運維水平是 AIOps 的重要基石，而 AIOps 將基于自動化運維，將 AI 和運維很好地結(jié)合起來，這個過程需要三方面的知識：

1）行業(yè)、業(yè)務(wù)領(lǐng)域知識，跟業(yè)務(wù)特點相關(guān)的知識經(jīng)驗積累，熟悉生產(chǎn)實踐中的難題。

2）運維領(lǐng)域知識，如指標監(jiān)控、異常檢測、故障發(fā)現(xiàn)、故障止損、成本優(yōu)化、容量規(guī)劃和性能調(diào)優(yōu)等。

3）算法、機器學(xué)習(xí)知識，把實際問題轉(zhuǎn)化為算法問題，常用算法包括如聚類、決策樹、卷積神經(jīng)網(wǎng)絡(luò)等。

百度的故障管理場景如圖所示，主要包括故障發(fā)現(xiàn)，故障止損，故障診斷智能預(yù)警等。

2. 故障發(fā)現(xiàn)

運維的黃金指標有請求數(shù)（流入狀態(tài)），成功率（流出狀態(tài)），響應(yīng)時間（用戶相應(yīng)感受），系統(tǒng)容量（系統(tǒng)并發(fā)負載）等。其預(yù)測難點在于基線預(yù)測算法在遇到節(jié)假日這種不規(guī)律的情況時不準確，另外在于配置上的，忙閑時間機器需求差異很大，容易造成資源浪費。

2.1 基線預(yù)測算法

基線預(yù)測算法主要采用魯棒回歸+周期數(shù)據(jù)多模式挖掘相結(jié)合的算法。魯棒回歸算法的思想是假設(shè)較小窗口內(nèi)符合線性趨勢變化，即局部符合線性。周期數(shù)據(jù)多模式的思想是對于不同的節(jié)假日，春節(jié)等特殊時期采用多種基線模型進行匹配。

3. 故障自愈

出現(xiàn)故障第一時間的原則是故障止損，而不是查明原因，甚至解決問題。先將損失止住，再進行分析。

傳統(tǒng)的人工故障止損有以下三個不足：相應(yīng)可能不夠迅速，決策可能不夠準確，操作可能出現(xiàn)失誤。AIOps 中的故障止損叫做故障自愈，相對人工智障止損的不足，它可以 7*24 小時快速相應(yīng)，全局一致性信息決策，程序自動化準確操作。

故障自愈的場景和止損方法如下：

4. 故障診斷

如下圖所示，為一個系統(tǒng)的運行流圖，G 節(jié)點此時出現(xiàn)故障。

人工故障針對的做法通常從兩個方向出發(fā)，一是找出 A 上的某故障跟 G 節(jié)點的關(guān)系，二是追查 G 節(jié)點異常的原因。這很大程度依賴人工歷史經(jīng)驗，不易準確快速定位原因。AIOps 的智能故障診斷方法的做法是利用黃金指標綜合進行，做法如下所示：

5. 智能預(yù)警

一個很重要的運維手段就是在故障發(fā)生之前進行預(yù)警，從而減少實際損失。人工的預(yù)警方法通常是根據(jù)經(jīng)驗，考慮的指標覆蓋范圍小，且閾值的設(shè)置較為困難，容易產(chǎn)生誤報和漏報。AIOps 的智能預(yù)警可以覆蓋上萬個指標，且通過機器學(xué)習(xí)自動學(xué)習(xí)到相應(yīng)閾值，而無需人工干預(yù)。智能預(yù)警如下圖所示：

三、快手推薦系統(tǒng) Dragonfly 架構(gòu)啟發(fā)

1. 背景

以推薦系統(tǒng)為例，通常在線推薦系統(tǒng)包括召回，排序，重排三個模塊。召回是利用如 ANN 檢索，倒排檢索算法，將候選項從千萬降到十萬的數(shù)量級；排序是利用 CTR，LTR 等指標，將候選項從十萬降到千的數(shù)量級；最后重排是利用多樣性打散，強插，混排技術(shù)將候選項從千降到十的數(shù)量級。

為了快速復(fù)用，采用的如上圖的分離的系統(tǒng)架構(gòu)，算法人員和架構(gòu)人員的代碼交織在一起，那幺如何將業(yè)務(wù)代碼和架構(gòu)代碼進行解耦呢？David Wheeler 說過，所有的計算機問題都可以通過增加一層抽象來解決。

2. 實現(xiàn)方法

快手架構(gòu)的基本思想是構(gòu)建了一種 DSL 語言 Dragonfly，讓算法人員用類 python 方式開發(fā)，而不用關(guān)注底層的實現(xiàn)，架構(gòu)人員專注于用 c++實現(xiàn)底層架構(gòu)。下圖右側(cè)的圖就是一個算法人員實現(xiàn)的例子，就是純 python 代碼，容易實現(xiàn)，易于閱讀。

具體解決方案是將算法都細分成算子的粒度，如下圖所示，所有的人工智能算法都是由各種算子進行組合搭建而成，架構(gòu)人員負責(zé)開發(fā)這些算子的實現(xiàn)，算法人員在封裝好的算子基礎(chǔ)上進行運用。因此算法人員不關(guān)注底層實現(xiàn)，專心關(guān)注與上層邏輯，去編寫 DSL 語言，然后提交配置即可；架構(gòu)人員不關(guān)注上層邏輯，只負責(zé)編寫底層算子。

在實現(xiàn)這種改進之后，最大的優(yōu)點就是新場景的接入成本從 7 人日縮減到 1 人日。這種利用算子話粒度解耦的思想是我們是可以借鑒的，我們在做算法開發(fā)時，很多代碼都交織在一起，不能抽取出來，導(dǎo)致很多重復(fù)性的工作。如果把這些算法進行一步步的切分，分成很小的算子粒度，就能夠方便進行解耦，是的算法人員可以任意組合拼接算子，實現(xiàn)業(yè)務(wù)算法。

參考文獻：

[1]《Paddle Lite 端側(cè)部署》作者：吳建明

https://www.cnblogs.com/wujianming-110117/p/14398502.html

[2]《架構(gòu)設(shè)計》Paddle-Lite

https://paddlepaddle.github.io/Paddle-Lite/v2.2.0/architecture/

[3]《故障管理場景 AIOps 實踐與探索》 作者：陳云

https://ppt.infoq.cn/slide/show?cid=83&pid=3355

[4]《Dragonfly 快手通用策略 DSL 在推薦系統(tǒng)架構(gòu)的應(yīng)用和演進》作者：方劍冰

https://ppt.infoq.cn/slide/show?cid=83&pid=3295

[5]《百度飛漿輕量化推理引擎 Paddle Lite 的實現(xiàn)和應(yīng)用》作者：嚴春偉

https://ppt.infoq.cn/slide/show?cid=83&pid=3273