【社區分享】從零開始學習 TinyML，建立 TensorFlow 深度學習模型（技術優化篇）

TinyML是什么？如何從零開始入門學習？本系列上一篇教程中，我們復習了 TinyML 的概念，完成了一個最簡單的 ML 模型與微控制器運行，今天，本教程將與你探討如何在實際的工程應用中對已建立的模型進行技術優化，

本文來自社區投稿與征集，作者王玉成，ML&IoT Google Developers Expert，溫州大學智能鎖具研究院總工程師，了解更多：https://blog.csdn.net/wfing

5. 優化

TinyML 這本書也詳細的向我們介紹了優化的一些方法，以及用這些方法可以達到什么樣的效果，通過優化，工程的執行效率會獲得很大的提升，

我們先不要急于去看這本書到底介紹了哪些優化方法，我們仔細回顧一下，在之前的專案中，我們接觸的工程中包括了優化的哪些方面？

5.1 優化角度

從工程角度來看整個流程，優化涉及到的部分，包括以下幾個階段：

1. 需求分析及產品設計：定位產品的使用范圍，產品方向的輸入和輸出的約定將會極大的影響產品的性能，當產品的需求完全定下來之后，我們便要分析輸入和輸出的具體內容，這些輸入和輸出將會造成什么樣的影響？資料輸入及輸出影響著嵌入式硬體選型和 ML 模型選型，在工程設計的前期都必須要充分考慮這些因素，

2. ML 模型：解決了輸入輸出的問題之后，接下來便是模型的建立及優化，這一部分的內容是機器學習中老生常談的問題，但是在每個具體的專案實施中間又是必須考慮的問題，對嵌入式系統中的人工智能模型的優化，已經有了量化，移動優化解釋器，硬體加速等方法，這部分內容在手機相關的模型優化中間已經做了很多作業，但是在微控制器的模型優化中又提出了一些新的方法，這一部分方法也是我們討論的主要方向，

3. 基于低功耗的硬體去開發任何系統，首要考慮的問題是功耗，不同的硬體配置以及片上系統的運行特性，對功耗會產生完全不同的影響，特別需要指出的是，低功耗的設計本身會帶來性能的損失，那么我們最優化的一些辦法一定是從功耗和性能綜合來考慮的，這是工程上面最典型的優化場景，不同的實作會帶來完全不同的結果，

4. 由于低功耗微控制器本身的存盤容量特別小，不斷減小模型的尺寸，也是優化的一個方向，加入了這些限制條件之后，就不得不從系統限制，記憶體，存盤，運行效率等各個方面去評價這個模型是不是最優化的，類似場景的模型優化的評價方法是一直需要不斷探討的，沒有最好，只有更好，

通過上面的要素分析，我們會發現工程的優化并不僅僅只是提供一個運行效率最快的模型，還涉及到許多許多其它方面的考慮，那么我們這一次的閱讀會重點關注是低功耗的微控制器上如何去做優化，

由于整本書優化的方向比較多，我們就分兩個大的部分來討論優化的具體內容，模型優化主要講述如何確定產品需求，到最后實作整個模型優化所采取的一些主要方法；工程優化主要討論當模型匯入到低功耗微控制器之后如何去運行所考慮的一些問題，

5.2 模型優化

5.2.1 產品設計優化

產品設計方面的優化從嚴格意義上來說，并不是技術優化的范圍，但是他卻直接影響著整個工程運行效率的高低，這一部分內容沒辦法用特別好的技術方法去做模型上的評估，但是在不同產品的工程需求捕獲階段，確確實實存在很大的差異性，

由于現在人工智能的重點，仍然在影像領域，聲音領域和資料采樣領域，那么我們就以這個方向為重點，來看一下產品需求中間需要討論的問題，

• 影像：TinyML 的應用領域是在低功耗的微控制器上，但是如果我們加上攝像頭去采集資料，功耗將是一個重要的考慮方向，攝像頭的啟動時間最快也要幾秒，攝像頭啟動的時候會帶來特別大的瞬時電流，而且攝像頭又不能處于常開的模式，攝像頭本身長期的開和關的切換會帶來很大的功耗損失，攝像頭在運行程序中間，不同的解析度去采集圖片，功耗又會不同，采樣頻率的設定方式不同，對功耗影響也比較大，從這個意義上來說，攝像頭的選取就直接決定了優化了方向，

• 聲音：聲音相關的硬體和影像硬體有著類似的問題，但是我們需要注意的是，隨著麥克風陣列的加入，雖然從模型上來說，能夠更好的進行原始聲音資料的分析，但是從硬體的使用角度來考慮，功耗會更大，

• 資料：這兒所理解的資料是一些傳感器的資料上報，由于傳感器的功耗已經做得非常非常低了，所以優化方向仍然與采樣頻率相關，如何在合適的時間使模型推斷運行的最好？

這樣看來，如果是我們需要主導一款低功耗嵌入式人工智能產品的設計研發，需要考慮到微控制器的性能、資料采集終端、采樣時間及采樣頻率的限制，并且從以上的限制條件中，再去定制人工智能模型，

5.2.2 模型改進

以往的人工智能模型設計我們會用最多的資源，最好的環境去研發出最優的模型，但是基于低功耗的微控制器模型的運行環境，并不再強調模型一定是最好的，而在于運行的速度和效率的一個折中，只要最后的推理結果在我們認可的范圍內就可以了，

當我們把模型調整優化好了之后，需要對 ML 模型的延遲進行評估，由于低功耗微控制器上面沒有浮點運算單元的硬體支撐，那么，評估 ML 模型中浮點操作的次數，用量化的方法去減少浮點運算的執行時間，最終在微控制器上運行量化過的 ML 模型進行推理，成為一個比較好的方法，由于現在神經網路中的大部分計算是矩陣的乘法運算，那么可以用一次推理運行所需的浮點操作 (或 FLOP) 的數量來近似估算，例如，完全連接的層需要的 FLOP 數量等于輸入向量的大小，再乘以輸出向量的大小，我們也可以從模型架構討論的論文中間去估計 FLOP 的值，通過這樣的方法，我們就可以完全估計出浮點運算，或者量化之后運算所產生的時間損耗，然后再去優化最耗時的代碼，獲得更低的延遲，

5.3 工程優化

5.3.1 量化

最近幾年，對于 TensorFlow 在嵌入式處理器上的應用，已經有很多的優化作業的成果，TensorFlow Lite 針對 TensorFlow 的優化大概包括以下幾個方面的內容：量化、FlatBuffer、移動優化解釋器和硬體加速，對于 TinyML 來說，主要以軟體方式的優化為主，

我們以量化為例，量化的核心在于利用精度的損失來換取運行速度，那么如何平衡精度與效率之間的關系，就成為量化優化中最核心的問題，由于量化的程序是在整個模型已經建立完成之后去換算的，對于權重來說，可以用正確的縮放系數來進行轉換，但是對于激活來說比較棘手，因為通過模型引數和連接層檢查，并不清楚每層輸出的實際范圍是什么，如果選擇的范圍太小，輸出將被裁剪為最小值或最大值，但是如果選擇的范圍太大，則輸出的精度將小于其可能的精度，并且冒著使總體結果失去準確性的風險，現在轉換器中提供了一個 representative_dataset() 函式，這是一個 Python 函式，可產生激活范圍估計程序所需的輸入，能夠得到更好的優化，

針對于不同的硬體，甚至有時候我還會專門去看硬體指令所能帶來的一些優化方法，這種方法雖沒有通用性，但是對于單個產品的模型加速仍然比較重要，但麻煩的問題在于：既需要了解 CPU 是否有特殊功能的支持，還需要了解編譯器是否對這些指令做了專門的優化，甚至有可能出現最難以預料的方式，加入行內匯編去支持，這已經超出常規的優化范圍了，

從這一類方法可以看出，基于微控制器的優化更強調硬體個體有沒有優化的空間，

5.3.2 硬體優化

硬體選擇性問題，盡量的去選擇 TinyML 支持的硬體，這樣硬體驅動會有一個完善的支持，而且對開發版的優化已經做的比較充足了，

低功耗的微控制器通常使用的是電池作為電源，休眠是一個重要的因素，合理的設計會極大的延長電池使用時間，我們可以用硬體占空比來設計休眠、喚醒時間，傳感器采樣頻率、時間、功耗等因素，在產品設計優化部分已經闡述，同時也需要做許多折中的選擇，但是他們同時也是硬體優化的范圍，

級聯設計是另一個比較好的考慮角度，與傳統的程序編程相比，機器學習的一大優勢在于，它可以輕松擴展或縮減所需的計算和存盤資源數量，并且準確性通常會適度降低，這意味著可以創建模型級聯，比如說我們有一個多級的模型，當第 1 級的硬體計算能力達不到我們的要求時，我們會主動啟動第 2 級開銷，這樣的話我們可以運用更短的時間得到精確的結果，

5.3.3 基于硬體的軟體行為優化

無論選擇哪種平臺，閃存 (Flash) 和記憶體 (RAM) 都可能非常有限，大多數基于微控制器的系統在閃存中只有不到 1 MB 的只讀存盤，最小的幾十 KB，RAM 也是如此：很少有超過 512 KB 的靜態 RAM (SRAM)，針對微控制器的 TinyML 可以低于 20 KB 的閃存和 4 KB 的 SRAM 進行作業，但是您將需要仔細設計應用程式并進行工程設計，以保持較低的占用空間，

大多數嵌入式系統都具有一種體系結構，其中程式和其他只讀資料存盤在 Flash 中，僅在加載新的可執行檔案時才將其寫入，作為可以讀寫的記憶體使用，此技術與大型 CPU 上的快取使用的技術相同，它可以快速訪問以降低功耗，但尺寸有限，更高級的微控制器可以使用耗電較大但可擴展的技術，例如動態 RAM(DRAM) 來提供第二層可讀寫的記憶體，那么，外設讀寫操作次數的多少，直接影響到運行效率，

Flash 的使用率也是一個考慮的因素，分析 ELF 檔案中各段的使用效率，以及無用代碼的優化，預編譯優化，將會節省大量的 Flash 空間，

RAM 優化，主要包括程式在編譯時以及運行時的一些考慮，ML 框架的核心運行時應用并不需要大的記憶體，并且其資料結構在 SRAM 中的空間不應超過幾千位元組，這些是作為解釋器使用的類的一部分進行分配的，因此，無論您的應用程式代碼將它們創建為全域物件還是本地物件，都將決定它們是在堆疊中還是在通用記憶體中，我們通常建議將它們創建為全域或靜態物件，因為空間不足通常會在鏈接時引起錯誤，而堆疊分配的本地變數可能會導致運行時崩潰，所以程式編譯之前，堆疊的設計，以及程式的記憶體駐留空間，需要有一個比較好的設計方案，

二進制大小的優化，TensorFlow Lite 占用了多少空間是空間優化的一個重要內容，測最簡單方法是注釋掉對框架的所有呼叫（包括創建 OpResolvers 和解釋器之類的物件），然后查看二進制檔案變小了多少，如果沒有看到類似的內容，則應再次檢查是否已捕獲所有參考，有沒有不必要的參考，由于聯結器會洗掉永遠不會呼叫的所有代碼，并將其從封裝中洗掉，降低代碼的耦合度，規范的編程，會影響到最終生成的二進制檔案的大小，

這一部分的討論涉及到了硬體的選型問題，硬體上的各種引數的限制問題，從編譯方向出發，特別是從編譯階段，鏈接階段以及代碼運行階段可以優化的一些方向，這一部分優化的程序就是量身打造利器的程序，

5.4 總結

到此為止，這一系列的文章，都已經完全分享完了，我們從這一系列文章中，了解了 TinyML 的作用，并參照專案示例中的原始碼，實作了一個基于 TinyML 的專案工程，最后，通過剖析專案開發的流程以及關注點，學習了工程優化方法，但是，TinyML 這本書介紹的內容遠不止于此，書中還包含一些更復雜的示例以及剖析，包括一些優化方法的原理性解釋，如果對于這個方向感興趣，那就趕快買這本書來閱讀吧，

復習 TinyML 基礎原理和模型應用相關內容，點擊 TinyML 第一集（基礎原理篇），TinyML 第二集（模型應用篇），

如果你對本文中提到的一些知識點存在疑問，歡迎移步“問答”版塊發帖提問，你的問題有機會得到 CSDN 百大熱門技術博主、資深社區作者或者 TensorFlow 資深開發者的解答哦！同時，我們也歡迎你積極地在這個版塊里，回答其他小伙伴提出的問題，成為 CSDN 社區貢獻者，邁出出道第一步！馬上開始討論吧！

想了解更多大神的經驗分享？掃碼關注TensorFlow官方微信公眾號（TensorFlow_official)，產品更新、課程教學、技術實踐、應用實體等精彩內容一網打盡！