通過深度學習技術，物聯網（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的消息傳輸框架來連接所有的節點。