小叽導讀：在 AI 領域，晶片如果沒有足夠的計算能力，就無法支撐無人駕駛、可穿戴裝置的實際落地。本文介紹了ACE（AILabs Compute Engine），一個邊緣端的異構計算引擎。它支援端雲一體的模型管理，支援 GPU、DSP 和 VPU 等異構加速晶片，引入了 Google UINT8量化方案、FaceBook QNNPACK 加速庫等最新的技術。在自研硬體上，和晶片廠商深度合作針對中低端晶片做出了特例優化，落地了手勢識别、寵物檢測和筆尖檢測等業務。
一、背景
1.1 無晶片不 AI
人工智能産業得以快速發展，無論是算法的實作、海量資料的擷取和存儲還是計算能力的展現都離不開目前唯一的實體基礎——晶片，是否有符合市場業務需求的 AI 晶片是至關重要的。
針對目标應用是“訓練”還是“推斷”，是在“雲端”還是“終端”，可以把 AI 晶片分為四個象限，如上圖所示。
雲端訓練：深度神經網絡大多在雲端完成訓練，針對這一市場，NVIDIA 系列GPU晶片是使用最廣泛的。
雲端推理：與模型訓練不同，很多公司都針對雲端推理這一場景推出了專用晶片，包括 google 的 TPU 晶片、英特爾的 Nervana 系列晶片和寒武紀的MLU100 晶片等，平頭哥準備今年推出的第一款 AI 晶片 Ali-NPU 就是用于雲端推理的。
邊緣端推理：與雲端相比，邊緣端目前主要以推理為主，将 AI 算力注入邊緣，賦能邊緣智能是大勢所趨，越來越多的 AI 應用開始在邊緣裝置上開發和部署。
邊緣端訓練：同時，随着 google 提出 Federated Learning (FL) 和推出首個商用級邊緣端分布式機器學習系統，在邊緣和嵌入式裝置上進行學習訓練也變得越來越重要。與雲端的訓練相比，在邊緣裝置上進行訓練有着保護使用者隐私和提供更加個性化服務的巨大優勢，讓模型更聰明，讓使用者最快速地體驗到更新後的模型。
1.2 為什麼一定要邊緣計算？
因為邊緣計算（Edge computing）有延遲低、節省帶寬、離線可用和保護隐私等特點，有很多應用更适合在邊緣裝置上進行推理，智能将會下沉到終端裝置，智能邊緣計算将會崛起。比如，視訊監控任務，幾百萬高清攝像頭的資料完全由雲端來處理會對網絡造成巨大的壓力，再比如無人駕駛的推理則更不能由雲端來運作，否則如果網絡出現問題，很可能會出現災難性的後果。
1.3 為什麼自研算法引擎？
邊緣裝置也遠遠不止是攝像頭和手機，從對計算力有極大需求的無人駕駛到多傳感器融合的送餐機器人，再到對功耗和成本比較敏感的可穿戴裝置等，其應用場景五花八門。在目前的 AI 應用場景中，邊緣裝置主要執行推理計算，這就要求邊緣裝置的晶片有足夠的計算能力。但是，目前邊緣處理器晶片的計算能力比較有限，更好的利用這有限的計算能力，屏蔽底層的硬體細節，快速把業務落地就是作為引擎的責任。
ACE(AI Labs Compute Engine) 就是我們端雲一體化中，在邊緣裝置端的支援CPU、GPU、DSP 和專用 AI 晶片等異構計算方式的計算引擎。我們針對自研硬體，從主晶片和資料處理晶片的選型開始，與晶片廠商深度合作，從驅動層到 HAL 層到系統層，進行深度定制優化，打造針對專有自研硬體的算法引擎，支撐上層業務更好的運作。
以天貓精靈為例子，我們和算法同學深度合作，針對我們采用的某款低端晶片結合實際業務進行了定制化優化，通過 ACE 成功落地了像手勢識别這一類對實時計算力要求比較高的算法。
二、架構總覽
計算引擎 ：
計算層：采用了模型量化、異構計算、記憶體友好和彙編優化等手段進行算法加速；
接入層：以計算圖的方式編排算法業務，并提供常用的算子，縮短開發周期。
模型管理：
雲端：對接 AutoAI 平台，生成移動端模型；
邊緣端：接收雲端的指令、主動推送資訊。
三、計算引擎
3.1 計算層
人工智能不是隻能存在于昂貴的企業服務中，我們還要把 AI 的快樂帶到千家萬戶，注入到像智能電視、物聯網和智能音箱等衆多智能裝置當中，讓更多使用者體驗到 AI 所帶來的改變。因為這些終端智能裝置的計算能力普遍有限，是以我們采用了模型量化、異構計算、記憶體友好和彙編優化等手段對算法進行加速。
■ 模型量化
在我們最初把手勢算法落地到采用某低端算力晶片的産品上時，用于雲端的檢測模型是 float32 的模型，有幾百毫秒的耗時，經過算法同學的裁剪優化，該模型 CPU 單核心耗時降低到了130ms，但距離20幀/S的理想速度還有一定的差距。
我們采取模型量化的方式進行進一步的加速，量化後的定點計算比浮點計算要節省計算資源和記憶體，然後我們對量化後的推理過程做了深度的優化。
量化後，單核心耗時降低為59ms，檢測幀率能夠達到17幀/S，其速度已經超過4核心 float32 的模型了。
為了取得更好的量化加速效果，我們采用了記憶體友好和彙編優化等正常手段進行加速，并引入了 QNNPACK 加速庫。該庫是專門為模型量化加速設計的，采用和 TFLite 相同的量化原理。最終，我們将手勢模型單核心耗時縮短到了41ms，總計取得了3.17倍的加速效果，節省了74%的模型記憶體。
以标準 mobilenet_v2_1.0_224 模型為例，單核心量化加速效果能達到2.2倍。
針對多線程場景，我們還提高了 kernel 的并行程度，兩核心加速效果在3倍左右。
■ 異構加速
因為 CPU 上還運作着很多其他業務，是以能用來計算的 CPU 資源相對空缺，而且通用處理器 CPU 性能再無法按照摩爾定律進行增長。與此相對，資料增長對計算性能的要求卻超過了按“摩爾定律”增長的速度，算力需求和實際性能之間出現了巨大的缺口，一種主流的解決方案就是異構計算。
與追求普适性的通用計算不同，專用計算，就是對一些特定場合進行優化，性能/功耗等名額通常比通用 CPU 有數量級的提高，但是應用場景有限。通用和專用的關系就如同什麼都懂一些但是基本上什麼都不精的“通才”，和在個别領域鑽研極深但是其他領域幾乎一無所知的“偏才”。而異構計算一般就是 CPU+專用裝置（GPU、DSP、VPU和FPGA等）這些使用不同類型指令集、不同的體系架構的計算單元，組成的一個混合的系統，進行協同計算。
以某款晶片上的業務為例，大量的業務在使用 CPU 而 GPU 相對空閑。這個時候，在 CPU 上運作筆尖檢測算法時，4線程耗時260ms，CPU 消耗超過240%，對其它業務造成了較大的影響。而采用 CPU+GPU 異構計算的方式，耗時為150ms，CPU的消耗從245%降低到了50%，更好的使用了整體資源。
在該晶片上，異構計算資源除了 GPU 之外，還有定點運算加速器 VPU，把筆尖檢測模型量化之後就可以使用 VPU 進行加速。量化版的筆尖檢測模型使用4個 CPU 線程進行計算時，耗時約76ms，比起 float32的260ms有着極大的提升，但是吃掉了所有的 CPU 的計算資源，導緻其它業務不能正常運作。而使用 CPU+VPU 異構計算的方式，耗時僅為51ms，且節省了大部分 CPU 資源，并降低了整體的功耗。
3.2 接入層
接入層的作用是簡化算法開發流程，提高調試和維護的效率，最終實作業務的快速落地，我們主要通過以下幾種手段來達到這個目的：
對接 AutoAI 一站式解決方案，打通模型訓練、計算圖建構、模型管理整個流程；
聯合算法團隊開發常用的 High Level & Low Level 算子，打造子產品化的算子庫；
API/UI 簡化計算圖的建構，支援将計算圖、模型、配置等資源打包為單個檔案，降低管理難度；
支援深度學習、傳統算法混合的圖計算，減少工程代碼開發量，并提供性能分析、問題定位、算法評估等功能，降低調試難度，加快業務落地速度 。
四、模型管理
模型管理是 ACE 的一個重要功能，它由雲端和邊緣端兩部分組成，能夠靈活地對模型和業務兩個次元進行管理。原來，邊緣端必須通過系統軟體更新的方式來更新模型，這就意味着新模型的上線釋出和灰階測試都需要随着軟體更新的節奏走。但有時候我們想小範圍快速地灰階測試新模型，這個時候就需要模型管理系統來支援這個功能。
4.1 雲端模型管理
模型管理系統準确地說是一個管理邊緣端上各個算法模型的雲端背景系統，其核心在雲端。雲端模型管理系統結構如上圖所示，背景界面上可以操作服務端對端上進行控制，目前支援對端上的操作有：
查詢（Query）：查詢某台裝置上的模型詳細資訊；
下載下傳（Download）：将某個模型下載下傳到端上；
重載（Reload）：切換端上的某個模型/業務；
重置（Reset）：将端上模型重置為初始狀态（僅在緊急情況下使用）。
4.2 邊緣端模型管理
一般來說，模型管理是僅基于模型次元的管理，即模型與模型之間沒有耦合。但在某些情況下，這是不合理的，我們以視訊内的寵物檢測和手勢為例來說明模型耦合的情況。
如上圖所示，為了節省端上的存儲空間以及計算量，寵物和手勢兩個業務共用了一個模型，是以，僅僅依靠基于模型的單緯度的管理已經不能滿足需求。
為了解決這個問題，我們在模型次元的基礎上增加了業務次元。業務是在模型之上的一個抽象，業務與模型是多對多的關系，且業務之間可能會共享同一個模型，這樣就很好地解決了耦合問題。
五、展望未來
ACE 的使命是使算法能快速準确地落地到天貓精靈和機器人等自研邊緣裝置上，良好的支撐相關的上層業務。雖然目前還有很多的不足，但是我們會在後續的開發過程中繼續完善其易用性，做好底層的優化加速，并與廠商更加深度的合作，做到軟硬體結合，合理的利用端上有限的計算資源。
參考文獻：
[1]
https://arxiv.org/abs/1712.05877[2]
http://speak.clsp.jhu.edu/uploads/publications/papers/1048_pdf.pdf[3]
https://code.fb.com/ml-applications/qnnpack/[4]
https://arxiv.org/pdf/1902.01046.pdf[5]
https://arxiv.org/abs/1603.05279[6]
https://cloud.tsinghua.edu.cn/f/a0785cec353a4cd18d7d/[7]
https://www.leiphone.com/news/201809/ICs9ETzP7gPDEAkJ.html