摘要：前言阿里巴巴機器智能實驗室線下智能團(tuán)隊從年底開始涉及線下智能領(lǐng)域，從算法工程產(chǎn)品化業(yè)務(wù)落地多個方面入手，與合作伙伴們一起取得了一些小小的成績。目前，該套工具作為推薦的量化工具廣泛應(yīng)用在阿里集團(tuán)內(nèi)多個線下業(yè)務(wù)場景中。

阿里妹導(dǎo)讀：AI 技術(shù)已經(jīng)從互聯(lián)網(wǎng)走向零售、汽車、銀行等傳統(tǒng)行業(yè)。受限于延時、成本、安全等多方面的限制，單一的云解決方案往往不能滿足場景需求。線下智能方案逐步成為了智能化過程中重要的一環(huán)，今天，我們就一起來了解這一環(huán)，希望這些內(nèi)容可以讓同學(xué)了解線下智能的前景和其中待解決的技術(shù)點。

阿里巴巴機器智能實驗室線下智能團(tuán)隊從16年底開始涉及線下智能領(lǐng)域，從算法、工程、產(chǎn)品化、業(yè)務(wù)落地多個方面入手，與合作伙伴們一起取得了一些小小的成績。算法方面，我們提出了自主研發(fā)的模型壓縮方法，新型模型結(jié)構(gòu)和目標(biāo)檢測框架；工程方面，我們研發(fā)出一套非數(shù)據(jù)依賴的量化訓(xùn)練工具，并且針對不同硬件平臺，研發(fā)了高效推理計算庫；同時我們也和服務(wù)器研發(fā)團(tuán)隊一起抽象出了一套軟硬件產(chǎn)品化方案，以服務(wù)多樣的業(yè)務(wù)形式，并在真實業(yè)務(wù)場景中實驗落地。

在后面的篇幅中，我們主要會從算法探索、訓(xùn)練工具、推理框架、產(chǎn)品化和業(yè)務(wù)模式等方面對之前的工作做一個總結(jié)和分享。

基于 ADMM 的低比特量化

低比特量化是模型壓縮( ModelCompression )和推理加速( Inference Acceleration )中一個核心的問題，目的是將神經(jīng)網(wǎng)絡(luò)中原有的浮點型參數(shù)量化成 1-8Bits 的定點參數(shù)，從而減小模型大小和計算資源消耗。為了解決這個問題，我們提出了基于 ADMM（Alternating Direction Method ofMultipliers）的低比特量化方案。在公開數(shù)據(jù)集 ImageNet 上，我們在 Alexnet，ResNet-18，Resnet-50 等經(jīng)典 CNN 網(wǎng)絡(luò)結(jié)構(gòu)上做了實驗，無論是精度上還是速度上均超過了目前已知的算法。我們可以在 3-bit 上面做到幾乎無損壓縮。目前該方法已經(jīng)被廣泛應(yīng)用到各種端上目標(biāo)檢測和圖像識別的實際項目中。相關(guān)成果已經(jīng)在 AAAI 2018 上發(fā)表。

統(tǒng)一量化稀疏框架

量化技術(shù)可以通過簡化計算單元（浮點計算單元->定點計算單元）提升推理速度。 稀疏化( Pruning ) 技術(shù)則是通過對神經(jīng)網(wǎng)絡(luò)中的通路進(jìn)行裁剪來減少真實計算量。我們很自然的將這兩個技術(shù)融合到了一起，來獲取極限的理論加速比。在剪枝過程中，我們采用了漸進(jìn)式的訓(xùn)練方法，并結(jié)合梯度信息決定網(wǎng)絡(luò)中路徑的重要程度。在 ResNet 結(jié)構(gòu)上，我們可以做到90%稀疏度下的近似無損壓縮。

在稀疏化研究過程中，我們發(fā)現(xiàn)了一個問題，更細(xì)粒度的裁剪往往會獲得更高的精度，但是代價是犧牲了硬件友好性，很難在實際應(yīng)用中獲得理論加速比。在后面的章節(jié)中，我們會通過兩個角度來解決這個問題：

軟硬件協(xié)同設(shè)計，從軟硬件角度同時出發(fā)解決問題；

新型輕量級網(wǎng)絡(luò)，從軟件角度設(shè)計適合更適合現(xiàn)有硬件的結(jié)構(gòu)。

軟硬件協(xié)同網(wǎng)絡(luò)結(jié)構(gòu)

通過量化和稀疏技術(shù)，我們可以獲得一個理論計算量足夠低，所需計算單元足夠簡單的深度網(wǎng)絡(luò)模型。下一個要解決的問題就是我們?nèi)绾螌⑵滢D(zhuǎn)換成一個真實推理延時低的算法服務(wù)。為了挑戰(zhàn)極限的推理加速效果，我們和服務(wù)器研發(fā)團(tuán)隊一起，從軟硬件聯(lián)合設(shè)計出發(fā)解決該問題。在該項目中，我們提出了以下幾個創(chuàng)新點，其中包括：

軟硬件協(xié)同設(shè)計方面，我們針對硬件物理特性提出了異構(gòu)并行分支結(jié)構(gòu)，最大化并行效率。

算法方面，我們利用量化、稀疏、知識蒸餾等技術(shù)，將理論計算量壓縮到原始模型的18%。

硬件方面，我們通過算子填充技術(shù)解決稀疏計算帶來的帶寬問題，利用算子重排技術(shù)平衡PE負(fù)載。

通過上述方案，我們只需要 0.174ms 的 latency 就可以完成 resnet-18 復(fù)雜程度的模型推理，達(dá)到業(yè)內(nèi)最佳水平。該方案在對 latency 敏感的領(lǐng)域具有極大的優(yōu)勢。相關(guān)成果已經(jīng)在 HotChips 30 上展出。

新型輕量級網(wǎng)絡(luò)

軟硬件協(xié)同設(shè)計是一個非常好的推理解決方案，但是改方案的開發(fā)成本和硬件成本都很高。某些特定的場景對于 latency 和 accuracy 的容忍度比較高(例如人臉抓拍)。為了解決這類需求，我們提出了一種多聯(lián)合復(fù)用網(wǎng)絡(luò) (Multi-Layer Feature Federation Network, MuffNet) ，該結(jié)構(gòu)同時具有3個特點：

稀疏的拓?fù)浣Y(jié)構(gòu)，同時更容易獲取高頻響應(yīng)；

密集的計算節(jié)點，保證硬件友好性；

針對低成本硬件充分優(yōu)化，小計算量下精度提升更明顯；

我們提出的新型網(wǎng)絡(luò)由于每個單元的計算比較密集，并不存在過多的碎片操作，是非常適合在通用硬件上運行的。在公開數(shù)據(jù)集 ImageNet 上，我們在 40MFLops 計算量上相比目前業(yè)內(nèi)最優(yōu)的 shufflenetv2 結(jié)構(gòu)，準(zhǔn)確度絕對提升了2%。

端上目標(biāo)檢測框架

相比圖像識別類任務(wù)，目標(biāo)檢測類任務(wù)的適用場景更廣泛。高效的目標(biāo)檢測框架具有很高的研究價值。針對端上場景，我們提出了一個 LRSSD 框架( light refine single short multiboxdetector )， 該框架包括以下幾個特點：

簡化 SSD HEAD，采用共享預(yù)測層 設(shè)計特征融合模塊；

融合不同尺度下信息 級聯(lián)形式的 bbox 回歸；

對檢測模型做全量化處理。

如上表所示，相同 backbone 網(wǎng)絡(luò)的情況下，我們提出的 LRSSD 在減少 SSD HEAD 計算量的同時，mAP 可以穩(wěn)定提升3%-4% 。從另一個角度來看，在保證檢測精度不變的情況下，我們的方法可以將模型復(fù)雜度減少到原來的50%左右。如果再考慮到量化帶來的速度加成，在相同精度下，相比原有全精度模型，我們可以獲得總共約2-3倍的真實速度提升。

小結(jié)

上文給出了我們近2年內(nèi)在線下智能—模型壓縮領(lǐng)域所做的一些技術(shù)積累。歸納起來如下：

量化方面：我們可以做到 3-bit 量化幾乎無損壓縮！

稀疏方面：對于傳統(tǒng)網(wǎng)絡(luò)結(jié)構(gòu)，我們可以做到90%稀疏度下的幾乎無損壓縮！

軟硬件協(xié)同設(shè)計方面：我們聯(lián)合服務(wù)器研發(fā)團(tuán)隊，達(dá)到0.174ms/張的resnet18 極限推理速度，目前已知業(yè)內(nèi)最佳效果！

輕量級網(wǎng)絡(luò)設(shè)計方面：我們在 40MFlops 計算量下，相對目前業(yè)內(nèi)最好結(jié)構(gòu)，在 ImageNet 數(shù)據(jù)集上絕對提升2%！

端上目標(biāo)檢測方面，我們在保證精度不變的情況下，速度提升約2-3倍！

在技術(shù)探索的同時，我們也在積極的將上述技術(shù)應(yīng)用到實際的業(yè)務(wù)中。在這一過程中我們發(fā)現(xiàn)了下列幾個問題：

易用性： 業(yè)務(wù)場景往往需要快速的迭代能力和靈活方便的部署能力，因此非標(biāo)準(zhǔn)化的方案很難被廣泛應(yīng)用。

理論速度 vs 真實速度： 除了算法和硬件以外，真實的模型推理速度是需要一個高效的工程實現(xiàn)作為支撐的。

集成化 ：線下智能需要同時考驗團(tuán)隊在硬件和軟件方面兩方面的實力，這對業(yè)務(wù)而言往往太過沉重。

在本文后半部分，我們首先會針對上述的幾個問題介紹我們已經(jīng)做過的嘗試和沉淀出的解決方案。最后，我們列出了一些實例，展示如何在具體的業(yè)務(wù)場景中應(yīng)用線下智能技術(shù)，希望可以給各位同學(xué)一個更直觀的認(rèn)識。

在實際業(yè)務(wù)推廣過程中，我們遇到的第一個問題是易用性問題：

不同業(yè)務(wù)往往使用的深度學(xué)習(xí)庫多種多樣，例如 Caffe, Tensorflow, Mxnet 等等；

不同業(yè)務(wù)使用的基礎(chǔ)技術(shù)差異比較大，有分類識別、檢測、分割、語音等等；

不同業(yè)務(wù)的數(shù)據(jù)安全級別差異比較大，有些可以公開，有些則需要完全物理隔離；

為了讓更多的場景都可以用上我們的服務(wù)，獲得 AI 的紅利，我們提出了一套標(biāo)準(zhǔn)化的量化訓(xùn)練工具。

如上圖所示，首先，我們的工具輸入支持多種模型格式( TensorFlow，Caffe，Mxnet 等)。其次，我們提供了兩種不同的模型量化方法，一種是支持不同任務(wù)(分類，檢測，分割等)的數(shù)據(jù)依賴型壓縮方法( Data Dependent Compression ) , 適用于對數(shù)據(jù)安全要求不是很高，希望追求精度最大化的業(yè)務(wù)；另一種是數(shù)據(jù)非依賴壓縮方法( Data Independent Compression )，適用于對數(shù)據(jù)安全要求高，或者業(yè)務(wù)邏輯不是特別復(fù)雜的場景。

最后，在量化工作完成后，我們的工具會自動完成推理圖的優(yōu)化和模型加密，生成可以實際部署的模型文件。配合對應(yīng)的推理加速庫即可在端上運行。從易用性和數(shù)據(jù)安全性角度出發(fā)，我們推薦使用數(shù)據(jù)非依賴性的壓縮方法。

目前，該套工具作為MNN推薦的量化工具廣泛應(yīng)用在阿里集團(tuán)內(nèi)多個線下業(yè)務(wù)場景中。

實際中遇到的第二個問題就是真實推理速度問題，畢竟光有易用性是不夠的，實打?qū)嵉臉I(yè)務(wù)效果才是業(yè)務(wù)最想要的。這里我們使用阿里集團(tuán)其他的兄弟團(tuán)隊提供的推理框架：

ARM 架構(gòu)： 我們采用淘系技術(shù)團(tuán)隊研發(fā)的 MNN 作為推理框架；

GPU 架構(gòu)： 我們采用機器智能技術(shù)團(tuán)隊研發(fā)的 falcon_conv 卷積庫作為推理框架；

FPGA 架構(gòu)：我們采用服務(wù)器研發(fā)團(tuán)隊研發(fā)的推理框架。

MNN

MNN 是一個輕量級的深度學(xué)習(xí)端側(cè)推理引擎，核心解決深度神經(jīng)網(wǎng)絡(luò)模型在端側(cè)推理運行問題，涵蓋深度神經(jīng)網(wǎng)絡(luò)模型的優(yōu)化、轉(zhuǎn)換和推理。目前，MNN已經(jīng)在手淘、手貓、優(yōu)酷、聚劃算、UC、飛豬、千牛等 20 多個 App 中使用。選用常見的深度神經(jīng)網(wǎng)絡(luò)模型 MobileNet V2 和 SqueezeNet V1.1 作為測試樣本：Android 方面，以小米6為例，MNN 在 CPU 和 GPU 上領(lǐng)先業(yè)界至少30%；iOS 方面，以iPhone 7為例，MNN 在 CPU 和 GPU 上領(lǐng)先業(yè)界至少15%。

FPGA

FPGA 上的推理框架由服務(wù)器研發(fā)團(tuán)隊完成。ResNet18 網(wǎng)絡(luò)的推理時間只需要0.174ms，目前已知業(yè)內(nèi)最佳性能。在邊緣計算產(chǎn)品 alibabaedge 上，基于硬件實現(xiàn)的高效算子，推理速度為邊緣 GPU 的兩倍。在后面，我們會結(jié)合產(chǎn)品形態(tài)整體的介紹這一方案。

GPU

falcon_conv 是機器智能技術(shù)團(tuán)隊開發(fā)的一款由 CUDA C++編寫，在 Nvidia GPU 上運行的低精度卷積庫，它接受2份低精度( INT8 )張量作為輸入，將卷積結(jié)果以float/int32 數(shù)據(jù)輸出，同時支持卷積后一些常規(guī)操作( scale,batchnorm,relu… )的合并。我們在單張 Tesla P4 GPU 上，對 falcon_conv 的性能與 Nvidia 官方計算庫Cudnn v7.1 做了比較，如圖所示。幾乎所有情況 falcon_conv 都優(yōu)于 Cudnn ，個別用例有高至5倍的提升，用例選自 RESNET 和 VGG 中耗時較多的卷積參數(shù)。

在業(yè)務(wù)支持過程中我們遇到的第三個問題是集成化，產(chǎn)品化問題。除了手機類場景外，其他線下業(yè)務(wù)均需要額外的硬件平臺作為支撐。在早先時候，我們更多的是依賴第三方提供的硬件設(shè)備，這時候成本，穩(wěn)定性，可擴展性 成為制約線下項目拓展的幾個主要問題。為了解決這些問題，我們根據(jù)以往的項目經(jīng)驗，對硬件設(shè)備進(jìn)行歸納，沉淀出兩類比較通用的線下產(chǎn)品化方案：智能盒子和一體化相機。每類產(chǎn)品均包含不同型號，以適應(yīng)不同需求的場景。

智能盒子

我們提供的第一個方案為智能盒子方案。我們可以簡單的把智能盒子當(dāng)作一個適合于中小型場景的邊緣服務(wù)器。盒子本身提供了多種接口，可以外接 usb/ip 相機，語音模塊等傳感器。直接本地部署，數(shù)據(jù)安全性高。我們針對業(yè)務(wù)特點提供了高低兩個版本的智能盒子。其中，高端版本采用阿里巴巴自研的邊緣計算產(chǎn)品 Alibaba Edge 。除了完善的硬件設(shè)計和高效的推理框架，該盒子還包含完善的編譯器支持，具有非常好的易用性。 低端版本則為純 ARM 的盒子。下面表格給出這兩種盒子在性能，成本和適用場景的一個對比。

在這里我們著重介紹一下阿里巴巴自研的邊緣計算產(chǎn)品 Alibaba Edge，該產(chǎn)品除了具有高達(dá) 3TGFlops 的AI計算能力外，相對邊緣 GPU 方案有大幅的價格優(yōu)勢，同時具有云端一體化部署功能，產(chǎn)品平臺化，可快速上線，支持大規(guī)模運維。

在下面的表格中，我們對比了 LRSSD300+MobileNetV2 的不同硬件設(shè)備上的運行時間，希望可以給大家一個更直觀的認(rèn)識。

一體化相機

我們提供的另一個集成方案為一體化相機。一體化相機特別適合云+端的部署模式：線下做相對比較簡單的處理功能，云端則深度處理線下傳回的信息。達(dá)到節(jié)約帶寬，降低云成本的作用。同時，一體化相機具有方便部署，批量化生產(chǎn)后成本優(yōu)勢高的特點。目前一體化相機已經(jīng)作為一個重要的載體形式被應(yīng)用到我們所承接的對集團(tuán)外合作項目中。

在過去的2年間，我們嘗試過多種不同的業(yè)務(wù)模式。在這里我們會列出主要幾個不同形式的實例。

菜鳥未來園區(qū)

在菜鳥未來園區(qū)項目中，我們主要負(fù)責(zé)基礎(chǔ)視覺類算法的輸出，由菜鳥智慧園區(qū)團(tuán)隊同學(xué)負(fù)責(zé)業(yè)務(wù)算法和工程服務(wù)研發(fā)工作。經(jīng)過半年的共同努力，我們先后完成了離崗睡崗檢測，消防通道異常檢測，車位占用檢測，行人越界檢測，入口計數(shù)檢測等多個功能。

在項目合作的過程中，我們發(fā)現(xiàn)計算單元成本高是制約算法大范圍推廣的一個主要原因。為了解決這個問題，我們聯(lián)合了服務(wù)器研發(fā)團(tuán)隊，開發(fā)出一版定制化軟硬件解決方案：該方案的硬件平臺為我們在上文中提到的邊緣計算產(chǎn)品 Alibaba Edge，同時配備特別定制的高效模型結(jié)構(gòu)和自研的快速檢測算法。新版方案在檢測精度幾乎無損的情況下，推理速度提升了4-5倍，成本相比邊緣 GPU 方案下降了1/2。

模型壓縮加速

我們協(xié)助阿里集團(tuán)不同業(yè)務(wù)同學(xué)完成對已有算法模型的量化瘦身與加速工作。例如：手機端 OCR 識別、手機端物體檢測、手淘實人認(rèn)證和刷臉登錄/驗證、菜鳥自提柜、阿里體育賽事刷臉入場、神州鷹人臉識別云相冊等。

經(jīng)過近兩年的努力，機器智能技術(shù)實驗室線下智能團(tuán)隊深耕線下智能領(lǐng)域。算法方面：我們在低比特量化、稀疏化、軟硬件協(xié)同設(shè)計、輕量級網(wǎng)絡(luò)設(shè)計、端上目標(biāo)檢測等多個方面取得了一定的積累，多項指標(biāo)達(dá)到了業(yè)內(nèi)最佳水平。工程方面：我們積累出了一套 高靈活性，高數(shù)據(jù)安全性 的訓(xùn)練工具 ; 并在合伙伙伴的幫助下，在ARM，F(xiàn)PGA，GPU 等多個平臺下達(dá)到了業(yè)內(nèi)最佳的推理性能。產(chǎn)品化方面：我們與合作伙伴一起，研發(fā)出適合于不同業(yè)務(wù)場景的智能盒子與一體化相機。最后，我們很幸運可以在集團(tuán)內(nèi)外多個不同形式的業(yè)務(wù)場景內(nèi)打磨我們的技術(shù)。

閱讀原文

本文來自云棲社區(qū)合作伙伴“阿里技術(shù)”，如需轉(zhuǎn)載請聯(lián)系原作者。