摘要：近期大熱的圖像識別處理核賠技術，可應對剁手黨們衝動購物之後洶湧而至的退貨場景。那麼，這背後運用的技術原理是怎樣？ AI計算平臺又能否重構企業業務引擎呢？
隨着AI技術的挖掘與應用落地，也爲每一年的電商大促帶來了更多新鮮和驚喜。雙11、618等活動走到今天已經有十多年的時間了，從開始的價格戰到現如今的全方位的購物體驗的比拼，電商大促已不再是個單純的購物狂歡，更是對電商行業方方面面的一次全面“大閱兵”。
電商大促其中，有關計算機視覺技術的應用也是層出不窮。基於CV進行以圖搜圖的“拍照購”，用戶在互聯網或現實中看到了感興趣的商品，可以拍照或截圖，通過拍照購在電商平臺中搜索同款；電商大促節過後，隨之而來的則是“退貨潮”。針對這種情況，電商金融平臺將引入圖像識別技術處理核賠，以應對大批剁手黨衝動購物之後洶湧而至的退貨要求。那麼，這背後應用的技術運行的原理是怎樣的？ AI計算平臺能否滿足客戶的需求，重構企業業務引擎呢？
從卷積神經網絡中的矩陣乘法（GEMM）說起
說起AI業務，就不得不提最經典的AlexNet，AlexNet模型於2012年提出，其被認爲是計算機視覺領域最有影響力的模型之一。AlexNet網絡主要包含八層，前五層是卷積層，最後三層是全連接層。 配合pooling及norm運算，以下列出所有卷積層和全連接層的參數規模以及每層的浮點計算量，從圖中可以看出AlexNet網絡的參數規模達到了6千萬量級，計算量達到720MFlops。通過在橫向比較幾個經典的分類網絡，參數規模以及計算量都是巨大的。那麼從計算量的角度來看計算中99%以上都是卷積運算，本質都是矩陣運算。
在如此級別的規模參數及計算量下，矩陣運算如何加速，成爲了視覺計算領域亟需解決的問題。舉例：一個典型的16*16的兩個矩陣乘運算，在不同硬件上是如何進行計算的？
在CPU中矩陣乘需要做3個for循環，每一位依次進行乘加運算，理論上需要16*16*16*2的時鐘週期。
GPU中矩陣乘做了相關的優化，GPU是可以直接進行向量的乘加運算，那麼上述運算可以拆解爲16*16個乘加運算，即需要256個時鐘週期。
昇騰處理器提供專門的矩陣乘運算單元，一個時鐘週期就可以完成一次矩陣乘運算。其憑藉着在AI推理上的優異性能以及超低功耗，被應用於昇騰AI計算解決方案。
昇騰AI計算解決方案，力算雲上新視界
昇騰AI計算解決方案以極致算力，端邊雲融合、全棧創新，開放生態的硬核實力，助力行業客戶在圖片分類、目標檢測、人體檢測、人臉識別、車輛檢測等AI 視覺類計算領域取得亮眼的成績。
在IAAS層，昇騰AI計算解決方案可提供昇騰Ai推理實例——包括Ai1，KAi1，及可用於Ai訓練的裸機實例KAt1。Ai1正在熱賣中，點擊購買。
在算子層，昇騰AI計算解決方案可支持主流框架TensorFlow與Caffe的算子，以及自定義算子的能力。基於算子層還提供Matrix標準化接口，用戶可以通過基於Matrix標準化接口構建昇騰業務引擎。
同時，用戶還可以使用華爲昇騰Serving，對外提供RestFull API或gRPC請求，輕鬆解耦業務。上層再配合AI容器服務，輕鬆實現彈性伸縮，大大縮短業務部署週期。
如何用Matrix接口實現業務引擎
用戶可以使用標準的Matrix接口實現業務引擎，通過SDK方式對外釋放昇騰AI加速能力。
Matrix爲通用業務流程執行引擎，運行於操作系統之上，業務應用之下。可以屏蔽操作系統差異，爲應用提供統一的標準化接口，包括流程編排接口（支持C/C++語言、Python語言）和模型管家接口（支持C++語言）。
對於一個典型的業務流，通常包含數據讀取，數據的預處理（圖片的解碼，前處理），模型推理，數據後處理等過程。
那麼在Matrix框架中，可以把上述每個過程抽象爲一個engine，engine就是特定功能的計算引擎。若干engine構成Graph，Graph負責對engine進行管理。Matrix是一個通用的業務流程執行引擎，能夠管理Graph的生成，執行以及銷燬。
Matrix計算流程
關於Matrix的計算流程，我們從創建流程、執行流程、銷燬流程展開來看。
創建流程，如紅色箭頭所示：
根據Graph配置創建Graph對象。
上傳離線模型文件和配置文件到Device側。
初始化engine，推理Engine通過離線模型管家（AIModelManager）的Init接口加載模型。
執行流程，如灰色箭頭所示：
輸入數據
預處理Engine調用dvpp的api接口，進行數據預處理，例如對視頻/圖像進行編解碼、摳圖、縮放。
推理Engine調用離線模型管家（AIModelManager）的Process接口進行推理計算。
推理Engine調用Matrix提供的SendData接口將推理結果返回給DestEngine。DestEngine通過回調函數將推理結果返回給APP。
銷燬流程，如藍色箭頭所示：
結束程序，銷燬Graph對象。
Matrix數據流向和調用流程的雙BUFF加成
數據流“0”拷貝
我們可以看到，在Matrix框架中數據流的傳輸性能是至關重要的。
在框架中單獨提供了一套內存分配和釋放接口，包括HIAI_DMalloc/HIAI_DFree、 HIAI_DVPP_DMalloc/HIAI_DVPP_DFree，支持C/C++語言。
其中，
HIAI_DMalloc/HIAI_DFree接口主要用於申請內存，再配合SendData接口從Host側搬運數據到Device側；
HIAI_DVPP_DMalloc/HIAI_DVPP_DFree接口主要用於申請Device側DVPP使用的內存。
通過調用HIAI_DMalloc/HIAI_DFree、 HIAI_DVPP_DMalloc/HIAI_DVPP_DFree接口申請內存，能夠儘量少拷貝，減少流程處理時間。
HIAI_Dmalloc在跨側傳輸以及模型推理階段，性能最優，主要優勢體現在：
申請的內存是可以用於數據搬運對的，這樣可以避免Matrix與數據傳輸模塊間的數據拷貝。
申請的內存可以直接使能模型推理零拷貝機制，減少數據拷貝時間。
HIAI_DVPP_Dmalloc接口體現在：
申請的內存可以給DVPP使用，同時可以在DVPP使用完後透傳給模型推理時使用。
如果不需要做模型推理，申請的內存中的數據可以直接回傳給Host側。
對用戶友好的Host-Device的數據傳輸
在Host-Device間數據傳輸情況下，用HIAI_REGISTER_SERIALIZE_FUNC對自定義數據類型進行序列化/反序列化，可以實現高性能數據傳輸，節省傳輸時間。
Matrix通過“控制信息+數據信息”的形式描述要傳輸的數據，控制信息指用戶自定義的數據類型，數據信息指需要傳輸的數據內容。爲保證Host和Device之間的數據傳輸，Matrix提供如下機制：
在傳輸數據前，用戶可調用HIAI_REGISTER_SERIALIZE_FUNC宏註冊用戶自定義數據類型、用戶自定義序列化函數、用戶自定義反序列化函數。
用戶在本端調用SendData接口發送數據後，Matrix會做如下處理，處理流程如下：
調用用戶自定義的序列化函數對控制信息序列化，將序列化後的控制信息放入內存（ctrlBuf）。
通過DMA（Direct Memory Access）映射將控制信息拷貝一份存放到對端的內存中，並保持本端與對端之間控制信息的映射關係。 指向數據信息的內存（dataBuf）指針已通過SendData接口的入參傳入，dataBuf是由用戶調用HIAI_DMalloc/HIAI_DVPP_DMalloc接口申請的，申請該內存後系統將本端的數據信息通過DMA映射拷貝一份存放到對端的內存中，並保持本端與對端之間數據信息的映射關係。
拼裝消息發送給對端，主要將ctrlBuf的地址及大小、dataBuf的地址及大小發送到對端。
對端收到消息後，Matrix會調用用戶自定義的反序列化函數解析對端已獲取到的控制信息和數據信息，並將解析後的數據發送給對應的接收Engine進行處理。
對端解析數據後，控制信息已使用完成，因此可以釋放掉存放控制信息的內存（ctrlBuf），但由於存放控制消息的內存是在本端申請的，因此對端需要給本端發送釋放ctrlBuf的消息。
本端收到消息後，釋放ctrlBuf。
Engine在收到數據並完成所有處理後，便可以釋放dataBuf了，但由於Matrix並不知道用戶何時會使用完dataBuf，因此需要用戶在實現反序列化函數時，dataBuf以智能指針返回並綁定析構器hiai::Graph::ReleaseDataBuffer。當智能指針結束生命週期析構時，便會自動調用析構器給本端發送釋放dataBuf內存消息。
本端收到消息後，釋放dataBuf。
以上，我們詳細介紹瞭如何使用Matrix接口構建業務引擎，同時用戶還可以集成昇騰Serving對外提供標準RestFull API或者gRPC請求，提供解耦的標準推理接口能力。或者配合AI容器服務，提供彈性伸縮，易於部署的能力，模型熱替換的能力。
近期，618大戰如火如荼，各商家不僅是銷售額的比拼，更是技術間的較量。開發者關心的是什麼？華爲雲官方揭祕618背後的神祕黑科技：聊聊有哪些厲害的技術，能爲618大促保駕護航？能大大提高程序員的幸福感？歡迎點擊我們的黑科技攻略專題，也歡迎留下你的想法哦~~
點擊這裏，瞭解更多精彩內容