TinyML-TVM是如何馴服Tiny的（下）

TinyML-TVM是如何馴服Tiny的（下）

Lazy Execution
實際上，隨著通訊開銷開始占主導地位，一旦使用者請求，就執行運算元的開銷變得非常昂貴。可以通過延遲評估直到使用者需要呼叫的結果來提高系統的吞吐量。
從實現的角度來看，現在需要在主機端積累函式呼叫後設資料，然後再將其重新整理到裝置，而不是急於序列化引數後設資料和UTVMTask資料。裝置runtime也需要一些改變：
（1）現在必須有一個UTVMTask的全域性陣列
（2）需要迴圈執行每個任務。
帶MicroTVM的AutoTVM
到目前為止，所描述的runtime對於模型部署似乎不是很有用，因為它非常依賴於主機。這是有意的，而runtime實際上是為另一個目標而設計的：AutoTVM支援。
一般來說，AutoTVM提出候選核心，在目標後端隨機輸入執行，然後使用計時結果來改進其搜尋過程。考慮到AutoTVM只關心單個運算元的執行，將runtime設計為面向運算元，而不是面向模型。但是，在µTVM的情況下，與裝置的通訊通常將支配執行時間。延遲執行允許多次執行同一個運算元，而不將控制權返回給主機，因此通訊成本在每次執行中分攤，可以更好地瞭解效能配置檔案。
由於AutoTVM需要在大量候選核心上進行快速迭代，因此µTVM基礎設施目前僅使用RAM。然而，對於自託管runtime，肯定需要同時使用快閃記憶體和RAM。
託管圖形runtime
雖然託管runtime是為AutoTVM設計的，但是仍然可以執行完整的模型（只要沒有任何控制流）。此功能僅通過使用TVM的graph runtime免費提供，但需要使用µTVM上下文。事實上，在執行圖時對主機的唯一依賴是用於張量分配和運算元排程（這只是依賴圖的一種拓撲型別）。
Evaluation
有了這一基礎架構，試圖回答以下問題：
µTVM真的不受裝置限制嗎？
使用µTVM進行優化實驗需要多少算力？
為了評估（1），對兩個目標進行了實驗：
Arm STM32F746NG開發板，具有Cortex-M7處理器
µTVM主機模擬裝置，它在主機上建立一個記憶體競技場，與主機介面，就好像它是一個裸機裝置一樣。
為了評估（2），將探索Arm板的優化，以使成本最大化。
作為比較，使用Arm從本教程中提取了一個量化的CIFAR-10cnn。CMSIS-NN（Arm專家高度優化的核心庫）被用作運算元庫，這使CNN成為完美的評估目標，因為現在可以在Arm板上直接比較µTVM和CMSIS-NN的結果。

Methodology

Arm-Specific Optimizations
使用了TVM from HEAD（提交9fa8341）、CMSIS-NN 5.7.0版（提交a65b7c9a）、STM32CubeF7的1.16.0版以及Arm GNU Tools for Arm嵌入式處理器9-2019-q4-major 9.2.1工具鏈（修訂版277599）中的GCC。在UbuntuW620X主機上執行UbuntuW620X主機和Ry299X核心執行的UbuntuW329X處理器。
特定於Arm的優化
對於CMSIS-NN，第一個卷積對映到RGB卷積實現（特別是用於輸入層），後兩個對映到 “快速”卷積實現。在之前的通用優化之後，覺得效能已經足夠接近RGB卷積，但是對於快速卷積結果卻不滿意。幸運的是，Arm釋出了一篇文章，描述了CMSIS-NN中使用的優化，發現從SIMD內部函式得到了大量的加速。本文提出了一個使用SIMD內部函式的矩陣乘法微核心（下圖）。雖然可以在TVM的程式碼生成設施中新增對內部函式的一流支援，但從長遠來看，這可能是TVM提供的一種“快速而骯髒”的支援SIMD的解決方案。

Diagram from CMSIS-NN paper showing a 2x2 matrix multiplication microkernel
CMSIS-NN論文中的圖表顯示了2x2矩陣乘法微核心
張量化的工作原理是定義一個可以插入TVM運算子最內層迴圈的微核心。使用這種機制，新增對Arm板的SIMD支援就像在C中定義一個微核心（在這裡找到）一樣簡單，反映了論文中的實現。定義了一個使用這個微核心（在這裡可以找到）的計劃，進行自動調整，然後得到“µTVM SIMD tuned”結果。
雖然能夠使用SIMD微核進行直接卷積，但CMSIS-NN使用稱之為“部分im2col”的實現策略，在效能和記憶體使用之間進行了權衡。部分im2col一次只生成幾個列，而不是一次顯示整個im2col矩陣。然後，對於每個批次，可以將矩陣傳送給SIMD matmul函式。
假設是，在其他優化中，可以通過自動調整找到最佳的批量大小。在實踐中，發現部分im2col比直接卷積實現慢得多，所以在剩下的結果中沒有包含它。
當然，還可以從CMSIS-NN中進行其他優化，以進一步縮小差距：
批量擴充套件int8權重到int16，以減少SIMD的重複擴充套件
將卷積拆分為3x3塊以減少填充檢查
本文目標是展示µTVM能做些什麼。甚至連程式碼庫都不能使用它，因為其他的程式碼庫也不能。
End-To-End CIFAR-10
在探索了卷積的優化之後，開始測量對端到端效能的影響。對於Arm板，收集了未調整的結果、未使用任何SIMD的結果、使用SIMD調整的結果以及使用CMSIS-NN的結果。對於模擬的主機裝置，只收集未調整的結果和通用的優化結果。
https://github.com/areusch/microtvm-blogpost-eval

int8-quantized CIFAR-10 CNN comparison on an Arm STM32F746NG (re-posted from above)

int8-quantized CIFAR-10 CNN comparison on µTVM’s emulated host device
在Arm STM32系列板上，效能比初始未調諧的操作員提高了約2倍，而且結果更接近CMSIS-NN。此外，還能夠顯著提高主機模擬裝置的效能。雖然x86的數字並不意味著什麼，表明可以使用相同的基礎架構（µTVM）在完全不同的體系結構上優化效能。
隨著將這種方法擴充套件到更廣泛的範圍，請繼續關注更多的端到端基準測試。
Self-Hosted Runtime: The Final Frontier

The envisioned µTVM optimization and deployment pipeline
雖然正如上面所演示的那樣，在當前runtime已經可以獲得端到端基準測試結果，但是以獨立的能力部署這些模型目前仍在路線圖上。差距在於面向AutoTVM的runtime，當前依賴於主機來分配張量和排程函式執行。為了在邊緣有用，需要一個通過µTVM的管道，它生成一個在裸機裝置上執行的二進位制檔案。然後，使用者將能夠通過在邊緣應用程式中包含這個二進位制檔案，輕鬆地將fastml整合到應用程式中。這條管道的每一個階段都已經準備好了，現在只是把它們粘在一起的問題，所以期待很快在這方面的更新。
Conclusion
用於單核優化的MicroTVM現在已經準備好了，並且是該用例的選擇。隨著現在構建自託管部署支援，希望也能將µTVM作為模型部署的選擇。然而，這不僅僅是一個旁觀者的運動-記住：這都是開源的！µTVM仍處於早期階段，因此每個個體都會對其軌跡產生很大影響。如果有興趣合作，檢視《TVM貢獻者指南》，或者直接進入TVM論壇討論想法。