機器學習(ML)系統性能測試基準MLPerf的幕後推手、產業聯盟MLCommons近日發表了專為TinyML系統設計的新性能指標，同時也公佈了第一次使用該MLPerf Tiny指標進行的推論系統跑分結果。

MLPerf已經為高性能運算(HPC)系統、資料中心以及行動裝置等級的系統提供性能測試基準，新的TinyML系統性能基準，則是專為那些在資源極度受限環境中執行機器學習工作負載的裝置所設計。MLCommons執行總監David Kanter表示，現在MLPerf基準可涵蓋「微瓦(microwatts)到千瓩(megawatts)等級的機器學習系統。

他指出：「如果你檢視一些我們的訓練以及HPC性能測試基準，HPC基準可在全球最大超級電腦上的1萬6,000個節點上執行；在Tiny基準方面，則是關於我們如何量測那些最小、最低功耗的裝置(參考下圖)。」

MLPerf性能測試基準的涵蓋範圍從TinyML裝置到大型資料中心設備。

(圖片來源：MLCommons)

通常TinyML系統意味著以嵌入式微控制器/處理器在感測器節點執行感測器資料推論的系統，可能是來自麥克風、攝影機等感測裝置的資料。一個這種等級的典型神經網路裝置可能資料量只有100kB或更少，而且受限於電池電量。

儘管TinyML並沒有明確的定義，該名詞通常是指以微控制器為基礎的系統；MLPerf已經將之延伸了一點點，因此也涵蓋包括Raspberry Pi在內的系統。MLPerf Tiny推論性能測試基準工作小組主席、美國哈佛大學(Harvard University)教授Vijay Janapa Reddi則表示，開發這個領域的性能測試基準是一項挑戰。

「任何推論系統都有複雜的堆疊，但在TinyML，所有的東西都是與感測器資料──音訊、視覺、慣性量測單元(IMU)──有關，生態系統特別複雜；」Janapa Reddi表示：「在嵌入式領域特別具挑戰性，是因為大多數的硬體有其客製化工具鏈…這使得性能基準測試極具挑戰。我們必須從頭特製很多基礎架構，那不是能輕易從MLPerf推論性能基準借用的。」

他補充指出，有鑑於該堆疊的所有部分都有廣泛的創新，要定義一個固定的性能測試基準以有效展現那些硬體、軟體、工具以及演算法的創新，在TinyML領域是特別大的挑戰。

工作負載選擇

MLPerf工作小組是與嵌入式微處理器性能測試基準聯盟(Embedded Microprocessor Benchmark Consortium，EEMBC)合作開發TinyML的性能測試基準，利用了EEMBC的測試工具(EnergyRunner框架)，MLPerf工作小組則是定義工作負載、規則以及性能測試基準。

與其他的MLPerf性能測試基準一樣，各組織能提交執行一個或多個不同工作負載的硬體與軟體系統跑分結果，但TinyML性能基準要支援多樣性的應用案例，讓系統可選擇工作負載來呈現常見的應用會特別困難。為此，MLPerf Tiny推論工作小組將之縮小為四種工作負載：

• 關鍵字識別(Keyword spotting)──利用Google的語音指令資料集(Speech Commands Dataset)，以DS-CNN模型進行有限詞彙的語音識別。
• 異常偵測(Anomaly detection)──利用機器以Deep Autoencoder模型運作ToyADMOS聲音資料集，進行音訊時間序列異常偵測。
• 視覺喚醒詞(Visual wake words)──這是一個兩類別影像分類的工作負載，影像被區分為「人」或「非人」，利用MobileNetV1 0.25X模型執行視覺喚醒詞資料集(Visual Wake Words Dataset )。
• 影像分類(Image classification)──以ResNet-8模型進行CIFAR10資料集的多類別(10類)影像分類。

如同其他MLPerf性能測試基準，MLPerf Tiny推論基準也有「封閉」與「開放」兩種賽程(division)，以嘗試提供相似系統的可比性，還有展示創新方法的靈活性；此外，也讓提交者展示其附加價值，無論他們要聚焦在堆疊的哪一個部份。由MLPerf工作小組定案的性能指標是既定預測準確度下的延遲性，以及既定預測準確度下的功耗。

該基準的延遲性分數是必選項，功耗量測則是可選的。但因為TinyML系統通常會在功耗與性能之間有謹慎的平衡折衷，我們是否真的能在不同時看到兩種指標的情況下，得到一個清晰的系統性能評分結果？

對此，MLCommons的Kanter表示：「我們把這個版本的測試基準叫做0.5版，有部份原因是因為這是我們第一次的MLPerf Tiny推論跑分結果。取得結果、訂定規則以及打造性能測試基準套件實際上是非常重要的任務，而在其上產生功耗/能耗結果又添加了一層複雜性…」

「我堅信要先學爬、再學會走路，然後才能跑，要讓事情開始、動起來，然後再最佳化、或者添加一些額外的能耗/功耗量測複雜性；」他接著指出：「我想，在我們下一輪的跑分結果中，應該會看到更多能耗量測。」

Janapa Reddi也同意以上觀點，補充指出該TinyML測試基準將會隨著產業進展更進一步提供清晰度；「這是一個還在萌芽的領域，正嘗試找到立足點。我們可以等個三年讓它成熟，因為在不同地方都會有大量的TOPS以及每瓦TOPS數字；然後我們可以嘗試進行某種程度的標準化，或者從一開始就與產業界合作，協助他們設定一個合理的方向…」

他表示：「對我來說，這與確切的數字或系統無關，更多是關於為這個社群提供清晰度與能見度，讓他們能加速進展。」

TinyML系統的技術堆疊相當複雜。

(圖片來源：MLCommons)

TinyML領域廠商情況與資料中心系統業者迥異，有更多新創公司以及中小型企業。MLPerf的TinyML工作小組共同主席Colby Banbury表示，他們也將這個特性納入了考量；「我們在設計測試基準的一開始就想到這個，因此特別著重參考實例並嘗試構建出來。我認為其重要性程度在先前幾代的MLPerf推論基準中不一定存在，因為沒有那麼多需求。」

由工作小組提供的參考實例是一組所有工作負載都是在意法半導體(ST) Nucleo-L4R5ZI開發板上執行的延遲性與功耗跑分；選擇該開發板是因為其開放平台、廣泛可取得性以及成本可負擔性。該開發板採用STM32 Arm Cortex-M4微控制器，如果有需要，完整的實例能提供未來提交者使用，作為他們自己的系統的起跑點。

Banbury舉例指出，理論上，一家軟體供應商能採用該參考實例堆疊，更換為他們自己特定的零組件並相當容易地執行。

第一輪跑分結果

MLPerf Tiny推論性能測試基準的第一輪跑分結果，在封閉賽程中有4套系統提交分數(包括參考系統)，開放賽程則是有一套系統提交份數。在封閉賽程中，美國軟體開發商Latent AI提供了執行在Raspberry Pi的兩套純軟體解決方案，該公司不挑硬體的Latent AI Efficient Inference Platform (LEIP)軟體開發套件能用以最佳化運算、能耗與記憶體效率。

Latent AI提交的4種工作負載延遲性分數都分別以FP32與INT8精度模型來跑分，執行關鍵字識別工作負載的延遲性結果為0.39 ms (FP32模型)或0.42 ms (INT8模型)，而參考系統的結果是181.92 ms。中國的一家研究機構鵬城實驗室(Peng Cheng Laboratory)所提交的系統，是將4種工作負載的跑分作為其TinyML應用自製RISC-V微控制器元件的概念驗證，該系統的關鍵字識別執行結果為325.63 ms，參考實例則為181.92 ms。

另一家美國業者Syntiant所提交的系統是唯一使用了硬體加速器的，在執行關鍵字識別任務的延遲為5.95 ms (參考實例系統的延遲為181.92 ms)。該公司的NDP120系統單晶片就是為了關鍵字識別所設計，採用Arm Cortex-M0處理器CPU核心，加上Syntiant的Core 2加速器。

在開放賽程只有hls4ml一個提交系統；hls4ml實際上是一個神經網路最佳化工作流程，是為了歐洲核子研究組織(CERN)的大型強子對撞機(Large Hadron Collider)所開發，現在則是由一個科研社群Fast Machine Learning for Science負責開發。hls4ml最佳化模型以雙核心的Arm Cortex-A9處理器以及Xilinx FPGA加速器執行，在影像分類工作負載的延遲為7.9 ms，準確度77%；同樣的系統執行異常偵測工作負載的延遲為0.096 ms，準確度82%。

除了參考實例，MLCommons公佈的第一輪TinyML系統性能測試不包含能耗表現，完整的跑分結果請參考此連結。

編譯：Judith Cheng

(參考原文：MLPerf Launches TinyML Benchmark for Smallest AI Systems，by Sally Ward-Foxton)

活動簡介

從無線連接、更快的處理和運算、網路安全機制、更複雜的虛擬實境(VR)到人工智慧(AI)等技術，都將在未來的每一個嵌入式系統中發揮更關鍵功能。「嵌入式系統設計研討會」將全面涵蓋在電子產業最受熱議的「智慧」、「互連」、「安全」與「運算」等系統之相關硬體和軟體設計。

會中將邀請來自嵌入式設計相關領域的研究人員、代表廠商以及專家，透過專題演講、產品展示與互動交流，從元件、模組到系統，從概念設計到開發工具，深入介紹嵌入式系統設計領域的最新趨勢、創新和關注重點，並深入分享關於嵌入式系統設計的經驗、成果以及遇到的實際挑戰及其解決方案。

贊助廠商

立即報名