如何使用CNN推理機在IoT設備上實現深度學習

近年來，越來越多的物聯網產品出現在市場上，它們採集周圍的環境數據，並使用傳統的機器學習技術理解這些數據。一個例子是Google的Nest恆溫器，採用結構化的方式記錄溫度數據，並通過算法來掌握用戶的溫度偏好和時間表。然而，其對於非結構化的多媒體數據，例如音頻信號和視覺圖像則顯得無能為力。

新興的物聯網設備採用了更加複雜的深度學習技術，通過神經網絡來探索其所處環境。例如，Amazon Echo可以理解人的語音指令，通過語音識別，將音頻信號轉換成單詞串，然後使用這些單詞來搜索相關信息。最近，微軟的Windows物聯網團隊發布了一個基於面部識別的安全系統，利用到了深度學習技術，當識別到用戶面部時能夠自動解開門鎖。

物聯網設備上的深度學習應用通常具有苛刻的實時性要求。例如，基於物體識別的安全攝像機為了能及時響應房屋內出現的陌生人，通常需要小於500毫秒的檢測延遲來捕獲和處理目標事件。消費級的物聯網設備通常採用雲服務來提供某種智能，然而其所依賴的優質互聯網連接，僅僅在部分範圍內可用，並且往往需要較高的成本，這對設備能否滿足實時性要求提出了挑戰。與之相比，直接在物聯網設備上實現深度學習或許是一個更好的選擇，這樣就可以免受連接質量的影響。

然而，直接在嵌入式設備上實現深度學習是困難的。事實上，低功耗是移動物聯網設備的主要特徵，而這通常意味著計算能力受限，內存容量較小。在軟件方面，為了減少內存佔用，應用程序通常直接運行在裸機上，或者在包含極少量第三方庫的輕量級操作系統上。而與之相反，深度學習意味著高性能計算，並伴隨著高功耗。此外，現有的深度學習庫通常需要調用許多第三方庫，而這些庫很難遷移到物聯網設備。

在深度學習任務中，最廣泛使用的神經網絡是卷積神經網絡（CNNs），它能夠將非結構化的圖像數據轉換成結構化的對象標籤數據。一般來說，CNNs的工作流程如下：首先，卷積層掃描輸入圖像以生成特徵向量；第二步，激活層確定在圖像推理過程中哪些特徵向量應該被激活使用；第三步，使用池化層降低特徵向量的大小；最後，使用全連接層將池化層的所有輸出和輸出層相連。

在本文中，我們將討論如何使用CNN推理機在物聯網設備上實現深度學習。

將服務遷移到雲端

對於低功耗的物聯網設備，問題在於是否存在一個可靠的解決方案，能夠將深度學習部署在雲端，同時滿足功耗和性能的要求。為了回答這個問題，我們在一塊Nvidia Jetson TX1設備上實現了基於CNN的物體推理，並將其性能、功耗與將這些服務遷移到雲端后的情況進行對比。

為了確定將服務遷移到雲端后，是否可以降低功耗並滿足對物體識別任務的實時性要求，我們將圖像發送到雲端，然後等待雲端將結果返回。研究表明，對於物體識別任務，本地執行的功耗為7 W，而遷移到雲端后功耗降低為2W。這說明將服務遷移到雲端確實是降低功耗的有效途徑。

然而，遷移到雲端會導致至少2秒的延遲，甚至可能高達5秒，這不能滿足我們500ms的實時性要求。此外，延遲的劇烈抖動使得服務非常不可靠（作為對比，我們在美國和中國分別運行這些實驗進行觀察）。通過這些實驗我們得出結論，在當前的網絡環境下，將實時性深度學習任務遷移到雲端是一個尚未可行的解決方案。

移植深度學習平台到嵌入式設備

相比遷移到雲端的不切實際，一個選擇是將現有的深度學習平台移植到物聯網設備。為此，我們選擇移植由Google開發並開源的深度學習平台TesnsorFlow來建立具有物體推理能力的物聯網設備Zuluko——PerceptIn的裸機ARM片上系統。Zuluko由四個運行在1 GHz的ARM v7內核和512 MB RAM組成，峰值功耗約為3W。根據我們的研究，在基於ARM-Linux的片上系統上，TensorFlow能夠提供最佳性能，這也是我們選擇它的原因。

我們預計能夠在幾天內完成移植工作，然而，移植TensorFlow並不容易，它依賴於許多第三方庫（見圖1）。為了減少資源消耗，大多數物聯網設備都運行在裸機上，因此移植所有依賴項可以說是一項艱鉅的任務。我們花了一個星期的精力才使得TensorFlow得以在Zuluko上運行。此次經驗也使我們重新思考，相比移植一個現有的平台，是否從頭開始構建一個新平台更值得。然而缺乏諸如卷積算子等基本的構建塊，從頭開始構建並不容易。此外，從頭開始構建的推理機也很難比一個久經測試的深度學習框架表現更優。

圖1 TensorFlow對第三方庫的依賴。因為依賴於許多第三方庫，將現有的深度學習平台（如TensorFlow）移植到物聯網設備並不是一個簡單的過程。

從頭開始構建推理機

ARM最近宣布推出其計算庫（ACL，developer.arm.com/technologies/compute-library），為ARM Cortex-A系列CPU處理器和ARM Mali系列GPU實現了軟件功能的綜合集成。具體而言，ACL為CNNs提供了基本的構建模塊，包括激活、卷積、全連接和局部連接、規範化、池化和softmax功能。這些功能正是我們建立推理機所需要的。

我們使用ACL構建塊構建了一個具有SqueezeNet架構的CNN推理機，其內存佔用空間小，適合於嵌入式設備。SqueezeNet在保持相似的推理精度的同時，使用1×1卷積核來減少3×3卷積層的輸入大小。然後，我們將SqueezeNet推理機的性能與Zuluko上的TensorFlow進行比較。為了確保比較的公平性，我們啟用了TensorFlow中的ARM NEON向量計算優化，並在創建SqueezeNet引擎時使用了支持NEON的構建塊。確保兩個引擎都使用了NEON向量計算，這樣任何性能差異將僅由平臺本身引起。如圖2所示，平均來言，TensorFlow處理227×227像素的RGB圖像需要420 ms，而SqueezeNet將處理相同圖像的時間縮短到320ms，加速了25％。

圖2 在TensorFlow上運行的SqueezeNet推理機與使用ARM Compute Library（ACL）構建的SqueezeNet推理機的性能。從頭開始構建簡單的推理引擎不僅需要較少的開發時間，而且相比現有的深度學習引擎，如TensorFlow，表現更加優秀。

為了更好地了解性能增益的來源，我們將執行過程分為兩部分：第一部分包括卷積、ReLU（線性整流函數）激活和級聯；第二部分包括池化和softmax功能。圖2所示的分析表明，SqueezeNet在第一部分中的性能相比TensorFlow提高23％，在第二部分中提高110％。考慮資源利用率，當在TensorFlow上運行時，平均CPU使用率為75％，平均內存使用量為9MB;當在SqueezeNet上運行時，平均CPU使用率為90％，平均內存使用量約為10MB。兩個原因帶來了性能的提升：首先，SqueezeNet提供了更好的NEON優化，所有ACL運算符都是使用NEON提供的運算符直接開發的，而TensorFlow則依靠ARM編譯器來提供NEON優化。其次，TensorFlow平臺本身可能會引起一些額外的性能開銷。

接下來，我們希望能夠從TensorFlow中榨出更多的性能，看看它是否能勝過我們構建的SqueezeNet推理機。一種常用的技術是使用矢量量化，使用8位權重以精度來換取性能。8位權重的使用，使得我們可以通過向量操作，只需一個指令便可計算多個數據單元。然而，這種優化是有代價的：它引入了重新量化和去量化操作。我們在TensorFlow中實現了這個優化，圖3比較了有無優化的性能。使用矢量量化將捲積性能提高了25％，但由於去量化和重新量化操作，也顯著地增加了開銷。總體而言，它將整個推理過程減慢了超過100毫秒。

圖3 有無矢量量化的TensorFlow性能。手動優化現有的深度學習平台（如TensorFlow）很困難，可能不會帶來顯著的性能提升。

網絡連接是易失的，因此我們想要確保能夠在本地設備上實現某種形式的智能，使其能夠在ISP或網絡故障的情況下繼續運行。然而要想實現它，需要較高的計算性能和功耗。

儘管將服務遷移到雲端能夠減少物聯網設備的功耗，但很難滿足實時性要求。而且現有的深度學習平台是為了通用性任務而設計開發的，同時適用於訓練和推理任務，這意味著這些引擎未針對嵌入式推理任務進行優化。並且它們還依賴於裸機嵌入式系統上不易獲得的其他第三方庫，這些都使其非常難以移植。

通過使用ACL構建塊來建立嵌入式CNN推理引擎，我們可以充分利用SoC的異構計算資源獲得高性能。因此，問題變為是選擇移植現有引擎，還是從零開始構建它們更容易。我們的經驗表明，如果模型很簡單，相比之下從頭開始構建它們容易得多。而隨著模型越來越複雜，在某些情況下，可能我們遷移現有引擎相對更加高效。然而，考慮到嵌入式設備實際運行的任務，不大可能會需要用到復雜的模型。因此我們得出結論，從頭開始構建一個嵌入式推理引擎或許是向物聯網設備提供深度學習能力的可行方法。

更進一步

相比從頭開始手動構建模型，我們需要一種更方便的方式來在物聯網設備上提供深度學習能力。一個解決方案是實現一個深度學習的模型編譯器，可以將給定的模型經過優化，編譯為目標平台上的可執行代碼。如圖4中間的圖所示，這種編譯器的前端可以從主要的深度學習平台（包括MXNet、Caffe、TensorFlow等）解析模型。然後，優化器可以執行額外的優化，包括模型修剪，量化和異構執行。優化後，由代碼生成器生成目標平台上可執行代碼，可以是ACL（用於ARM設備），TensorRT（用於Nvidia GPU）或其他ASIC設備。

圖4 物聯網設備服務架構。我們需要一個新的系統架構來實現物聯網設備上的深度學習：首先，我們需要直接編譯和優化深度學習模型生成目標設備上的可執行代碼; 其次，我們需要一個非常輕量級的操作系統，以實現多任務及其間的高效通信。IMU：慣性測量單元。

NNVM項目（github.com/dmlc/nnvm）是邁向這一目標的第一步。我們已經成功地擴展了NNVM來生成代碼，以便我們可以使用ACL來加速ARM設備上的深度學習操作。這種方法的另一個好處是，即使模型變得更加複雜，我們仍然可以輕鬆地在物聯網設備上實現它們。

當前的物聯網設備通常由於計算資源的限製而執行單個任務。然而，我們預計很快將有能夠執行多個任務的低功耗物聯網設備（例如，我們的Zuluko設備就包含了四個內核）。為了使用這些設備，我們需要一個非常輕量級的消息傳遞協議來連接不同的服務。

如圖4所示，物聯網設備的基本服務包括傳感，感知和決策。傳感節點涉及處理來自例如攝像機，慣性測量單元和車輪測距的原始傳感器數據。感知節點使用已處理的傳感器數據，並對所捕獲的信息進行解釋，例如對象標籤和設備位置。動作節點包含一組規則，用於確定在檢測到特定事件時如何響應，例如在檢測到所有者的臉部時解鎖門，或者當檢測到障礙物時調整機器人的運動路徑。Nanomsg（nanomsg.org）是一個非常輕量級的消息傳遞框架，非常適合類似的任務。另一個選擇是機器人操作系統，儘管我們發現對於物聯網設備來說，其在內存佔用和計算資源需求方面顯得太重了。

為了有效地將深度學習與物聯網設備集成，我們開發了自己的操作系統，包括用於消費級傳感器輸入的傳感器接口，基於NNVM的編譯器，將現有的深度學習模型編譯並優化為可執行代碼，以及基於Nanomsg的消息傳輸框架來連接所有的節點。
筆者希望本文將激勵研究人員和開發人員，在比以往更小的嵌入式設備中設計更加智能的物聯網系統。

轉貼自： 36 大數據