如果對深度學習有所了解的小伙伴們想必都知道，深度學習需要使用強大的服務器、加速嵌入式平臺(如NVIDIA的Jetson)來運行深度學習算法，然而這也同樣意味著不菲的開支。

那么問題來了，如果你想你想用樹莓派來做一個目標跟蹤器，為你看家守院，這可以實現(xiàn)嗎？換句話說，如果你需要在不帶加速器的ARM CPU上運行卷積神經(jīng)網(wǎng)絡了怎么辦？

如何優(yōu)化推理時間？

本文將嘗試回答一個簡單的問題：什么庫/工具包/框架可以幫助我們優(yōu)化訓練模型的推理時間？本文只討論已為ARM架構(gòu)芯片提供C / C ++接口的工具包和庫（由于嵌入式設備上使用 ，我們很少Lua 或 Python），限于文章篇幅，不闡述另外一種加速神經(jīng)網(wǎng)絡推理的方法，即修改網(wǎng)絡架構(gòu)，從SqeezeNet架構(gòu)可看出，修改網(wǎng)絡架構(gòu)是一個可行的方案。基于上述原因，本文涉及的實驗只涉及使用Caffe，TensorFlow和MXNet這3個開源的深度學習框架。

加速神經(jīng)網(wǎng)絡模型在硬件平臺計算速度，兩個主要有大的策略：

1）修改神經(jīng)網(wǎng)絡的模型；

2）加快框架運行速度。

當然，將這兩個策略結(jié)合起來使用，也是一種不錯的思路。

修改神經(jīng)網(wǎng)絡模型有兩種方法，一是通過降低權(quán)重精度實現(xiàn)，即降低特征量化的精度，二是通過權(quán)重剪枝來實現(xiàn)，權(quán)重剪枝的背后的思想是降低系統(tǒng)參數(shù)的冗余。降低權(quán)重低精度通常采用（用定點數(shù)或動態(tài)定點數(shù)表示浮點數(shù)的方法，支持這種做法的原理是：推理過程并不需要高精度，因為在運算過程中，計算的線性性質(zhì)和非線性的動態(tài)范圍壓縮，使得量化誤差僅在子線性地（sub-linearly）范圍內(nèi)傳遞，從而不會引起數(shù)值的劇烈變動。更進一步，我們可以使用低精度乘法來訓練神經(jīng)網(wǎng)絡模型。結(jié)合 SIMD 指令集，比如 SSE3，可以使特征量化過程可以更為高效，從而加速訓練過程。然而，目前我們還很難找到同時使用了這兩者的解決方案。比如使用Ristretto框架可以執(zhí)行有限精度的自動量化，但它卻并沒有降低計算負載。TensorFlow 也可以執(zhí)行量化，但其推理時間實際上卻增加了 5 到 20 倍，因為TensorFlow還引入了輔助量化/去量化的計算節(jié)點。因此在實際操作中，我們只把量化作為壓縮網(wǎng)絡權(quán)重的方法，當存儲空間有限時可以這樣操作，至少這已經(jīng)是當前最先進的技術(shù)。

從另外一個角度看，我們可采用加快框架的執(zhí)行時間的方法，這種方法不會影響到模型的參數(shù)。這種策略主要上采用優(yōu)化矩陣之間的乘法（GEMM）類的通用計算技巧，從而同時影響卷積層（其計算通常是 im2col+ GEMM）和全連接層。除此之外，可以使用神經(jīng)網(wǎng)絡的加速包NNPACK，就個人理解，NNPACK的核心思路是使用快速傅里葉變換將時間域中的卷積運算轉(zhuǎn)換成了頻域中的乘法運算。

加快框架執(zhí)行速度另一種方法是將網(wǎng)絡模型和權(quán)重配置轉(zhuǎn)換成針對目標平臺代碼，并對代碼進行優(yōu)化，而不是讓它們直接在某一個框架內(nèi)運行。這種方法的典型案例是 TensorRT。還有 CaffePresso， 可以將 Caffe中prototxt類型的文件定制成適用于各種不同硬件平臺的低規(guī)格版本。然而，TensorRT的運行需要CUDA，而且只能在 NVIDIA的 GPU中才能使用，而 CaffePresso 也需要某種硬件加速器（DSP、FPGA或NoC）上述內(nèi)容仔細地評估現(xiàn)有的解決辦法后，我發(fā)現(xiàn)以下幾種方法能夠加速當前流行的可用模型的推理：

如果你的框架中使用了 OpenBLAS（基礎線性代數(shù)程序集的開源實現(xiàn)），你可以嘗試使用其為深度學習進行過優(yōu)化的分支： https://github.com/xianyi/OpenBLAS/tree/optimized_for_deeplearning

NNPACK 能和其他一些框架（包括 Torch、Caffe 和 MXNet）聯(lián)合使用：http://github.com/Maratyszcza/NNPACK

將TensorFlow編譯為在樹莓派平臺的目標代碼時，你可以使用一些編譯優(yōu)化標志，從而充分利用NEON 指令集加速目標代碼的執(zhí)行速度：http://github.com/tensorflow/tensorflow/tree/master/tensorflow/contrib/makefile#raspberry-pi

基于以上3種方法，我概括出以下調(diào)測配置：

1. 使用以 OpenBLAS為后端的Caffe 主分支(caffe-openblas)；

2. 使用以 OpenBLAS為后端OpenBLAS 且為深度學習優(yōu)化過的Caffe分支版本(caffe-openblas-dl)；

3. 編譯TensorFlow時，使用優(yōu)化編譯標志 OPTFLAGS="-Os" (tf-vanilla)

4. 編譯TensorFlow時，使用優(yōu)化編譯標志 OPTFLAGS="-Os -mfpu=neon-vfpv4 -funsafe-math-optimizations -ftree-vectorize" (tf-neon-vfpv4)

5. 使用以OpenBLAS實現(xiàn)基礎線性代數(shù)程序集的Vanilla MXNet

6. 使用帶有 OpenBLAS 、且為深度學習優(yōu)化過MXNet 分支版本(mxnet-openblas-dl)。

你可能會疑惑：配置中怎么沒有 NNPACK？這確實有點復雜，由 ajtulloch 創(chuàng)建的 Caffe 分支提供了最直接的使用 NNPACK方法。然而自從它被集成進去以后，NNPACK 的API接口 就已經(jīng)改變了，并且目前我無法編譯它。Caffe2 對 NNPACK 有原生支持，但我不會考慮 Caffe2，因為它處于實驗性階段并且?guī)缀鯇affe進行了尚未文檔化的重構(gòu)。另外一個選項就是使用Maratyszcza的caffe-nnpack分支，但該分支比較老舊且已經(jīng)停止維護。

另外一個問題就是出于NNPACK本身。它只提供了Android/ARM平臺的交叉編譯配置，并不提供在 Linux/ARM 平臺上的交叉編譯配置。結(jié)合MXNet，我嘗試編譯目標平臺代碼，但結(jié)果無法在目標平臺上正常運行。我只能在臺式電腦上運行它，但是我并沒有看到比 OpenBLAS 會有更好的性能。由于我的目標是評估已經(jīng)可用的解決方法，所以我只能推遲NNPACK 的實驗了。

以上所有的這些方法都是在四核 1.3 GHz CPU 和 1 GB RAM 的樹莓派 3 上執(zhí)行。操作系統(tǒng)是 32 位的 Raspbian，所以檢測到的 CPU 不是 ARMv8 架構(gòu)，而是 ARMv7 架構(gòu)。硬件規(guī)格如下：

model name : ARMv7 Processor rev 4 (v7l)

BogoMIPS : 38.40

Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32

CPU implementer : 0x41

CPU architecture: 7

CPU variant : 0x0

CPU part : 0xd03

CPU revision : 4

為了評估上述每個測試配置的性能，我制定的測試方案如下：使用相同的神經(jīng)網(wǎng)絡。也就是一個有 3 個卷積層和2個全連接層且在頂層帶有Softmax的小型卷積神經(jīng)網(wǎng)絡：

conv1: 16@7x7

relu1pool1: MAX POOL 2x2conv2: 48@6x6

relu2pool2: MAX POOL 3x3conv3: 96@5x5

relu3fc1: 128 unitsfc2: 848 units

softmax

該卷積神經(jīng)網(wǎng)絡有 1039744 個參數(shù)。雖然非常小，但它已經(jīng)足夠強大了，可以用來處理許多計算機視覺算法。該網(wǎng)絡使用 Caffe 進行訓練人臉識別任務，并將其轉(zhuǎn)換為 TensorFlow 和 MXNet 格式，從而使用這些框架進行評估。批量執(zhí)行次數(shù)對性能有很大的影響，為了測量前向通過時間（forward pass time），我們將批量執(zhí)行的次數(shù)設置為 1 到 256。在不同次數(shù)的批量執(zhí)行中，我們每次執(zhí)行 100 次前向通過，并計算了每一張圖像的平均處理時間。

評估結(jié)果和討論

在下面的表格中，列出了平均前向通過的時間。其中，A 是 caffe-openblas, B 是 caffe-openblas-dl, C 代表 tf-vanilla, D 是 tf-neon-vfpv4, E 是 mxnet-openblas, F 是 mxnet-openblas-dl。

表1 不同測試配置在不同的批處理次數(shù)下的性能表現(xiàn)

圖1 線性尺度下不同配置的前向通過時間比較

在對數(shù)尺度尺度上我們再來看一下：

圖2 對數(shù)尺度下不同配置的前向通過時間比較

測試結(jié)果讓我大吃一驚。首先，我沒有預料到在 CPU 上運行 MXNet的性能會這么差。但這看起來已經(jīng)是一個眾所周知的問題。此外，受限于存儲空間，它無法運行 256 張圖片的批處理。第二個驚奇是優(yōu)化過的 TensorFlow 竟有如此好的性能。它甚至比 Caffe 的表現(xiàn)還好（批處理次數(shù)超過2時），光從原始框架上看是很難預料這個結(jié)果的。需要注意的是，上述測試配置中的優(yōu)化標志并不是在任意 ARM 芯片上都可以使用的。

Caffe因速度非?？旌退悸藩毜蕉?a target="_blank">知名。如果你需要連續(xù)地處理圖片，可以選擇使用優(yōu)化過的OpenBLAS的Caffe，可得到最好的處理性能。如果想提升10ms 的性能，你所要做的就只是簡單的輸入以下指令：

cd OpenBLAS

git checkout optimized_for_deeplearning

為了將我的研究轉(zhuǎn)變成正式的東西，我仍需要做大量的工作：評估更多的模型，最終集成 NNPACK，以及研究更多結(jié)合了BLAS 后端的框架。