如今各行各業(yè)似乎都傍上了AI，物聯(lián)網(wǎng)也不例外。但AIoT的進(jìn)程也已經(jīng)開啟了好幾年，除了智能音箱、智能機(jī)器人這樣的產(chǎn)品以外，似乎也沒有冒出任何爆款，反倒是手機(jī)憑借著龐大的應(yīng)用生態(tài)，Killer App頻出。可無論是芯片原廠，還是下游廠商仍在不遺余力地宣傳AI功能，這讓人百思不得其解了，物聯(lián)網(wǎng)真的抱穩(wěn)了AI這條大腿嗎？我們不妨從物聯(lián)網(wǎng)上實(shí)現(xiàn)AI的幾種方式來分析一下。

AIoT芯片

隨著邊緣端對AI需求的增加，其實(shí)不少廠商在不改變芯片架構(gòu)的情況下，也為邊緣AI開發(fā)提供了一系列工具。就拿意法半導(dǎo)體為例，他們旗下的STM32產(chǎn)品就全部兼容NanoEdge生態(tài)，支持生成異常檢測、異常值檢測、分類和回歸四種ML庫，可以完成常見的能源管理和壽命預(yù)測等工作。

至于對性能要求更高的深度學(xué)習(xí)應(yīng)用，就得用到他們的STM32Cube.AI了，對MCU的要求也提升至Cortex-M33以上的內(nèi)核。這種方式對于芯片原廠來說，無需對設(shè)計(jì)做出大改，也有助于建立起自己的AI開發(fā)工具鏈生態(tài)，還可以針對不同芯片的性能進(jìn)行調(diào)整。

也有的廠商開始在芯片上添加AI加速單元，比如Silicon Labs的BG24和MG24兩個SoC，就加入了AI/ML硬件加速器，為Cortex-M33卸載處理機(jī)器學(xué)習(xí)算法的工作。從其規(guī)格書上來看，該加速器是一個矩陣矢量處理器，所以更適合用于密集的矩陣浮點(diǎn)乘加運(yùn)算，比如BG24這種藍(lán)牙無線SoC，就可以更輕松地完成藍(lán)牙AoA的室內(nèi)定位工作。

這種方案與當(dāng)下數(shù)據(jù)中心、HPC市場的做法并無二致，對于AI/ML這種專用性極強(qiáng)的負(fù)載來說，確實(shí)不該拿來拖累通用計(jì)算的性能，而且這一思路也考慮到了對不同AI框架的兼容性。未來很有可能會出現(xiàn)更多的異構(gòu)方案，比如在集成Arm NPU的同時(shí)，加入各種硬件加速器內(nèi)核。

但無論是在原有芯片基礎(chǔ)上加入AI算法，還是集成AI加速器，除了存在建立生態(tài)系統(tǒng)的挑戰(zhàn)外，也都會帶來不可忽視的功耗增加，這對于一些持續(xù)供電的IoT產(chǎn)品的影響可以忽略，但對于可穿戴產(chǎn)品來說無疑意味著續(xù)航的降低。像蘋果的一系列產(chǎn)品就秉承著類似的設(shè)計(jì)，諸如Airpods、Apple Watch都是在以功能性作為最高優(yōu)先級，續(xù)航普遍不高。

當(dāng)然了，這里提到的引入AI降低續(xù)航都是以IoT產(chǎn)品的功能性和高品質(zhì)服務(wù)作為優(yōu)先，畢竟如果你從功耗上發(fā)力AI功能的話，還是能大大改善續(xù)航的。就拿華為的智能音箱Sound Joy為例，在藍(lán)牙模式下播放音樂就更加省電，但若是切換成支持語音控制的智能模式后，續(xù)航就會變短，所以華為也利用了動態(tài)調(diào)壓節(jié)能的算法進(jìn)一步提升續(xù)航。因此對于這類功能繁多的IoT產(chǎn)品來說，如何利用AI來完成功能的開關(guān)和功耗調(diào)整，才是未來增加續(xù)航的大方向。

輕量級AI框架

不僅是芯片廠商，AI框架的開發(fā)者們也注意到了IoT龐大的邊緣AI市場，紛紛在推出輕量化或可擴(kuò)展性強(qiáng)的框架，比如TensorFlow Lite、Caffe2等。這類框架可以在內(nèi)存極小的設(shè)備上運(yùn)行ML模型，也不需要任何操作系統(tǒng)、庫的支持。由于走了輕量化的路線，所以與工作站或數(shù)據(jù)中心這種場景跑的AI框架還是存在差異的，但也足以完成常見的對象檢測、手勢識別、超分辨率等工作，TinyML已經(jīng)成了每個物聯(lián)網(wǎng)公司研究的方向。

而且這些框架的開發(fā)者也會預(yù)先給到優(yōu)化后的模型，同時(shí)還能根據(jù)部署場景，完成不同模型之間的轉(zhuǎn)換，比如將Tensorflow轉(zhuǎn)換成TensorFlow Lite、TensorFlow Lite Micro部署在移動端或邊緣端等等。雖然這類輕量級模型已經(jīng)解決了運(yùn)行的問題，但后續(xù)的重新訓(xùn)練、優(yōu)化還是需要廠商自己去完成的。至于性能上的差異，不同的芯片之間勢必會存在偏差，比如手機(jī)上運(yùn)行這些AI模型肯定會比尋常的嵌入式設(shè)備要快得多。

好在大部分這些輕量化AI框架都是開源的，所以廠商也得以對其做出專門的優(yōu)化，并對現(xiàn)有的一些流行的AI模型進(jìn)行移植，同時(shí)也能在這個過程中打造其專有框架和工具鏈，做好差異化。這些輕量化AI框架面臨的挑戰(zhàn)也不是沒有，比如支持?jǐn)?shù)據(jù)類型少、不支持模型訓(xùn)練等，也都是限制了它們產(chǎn)出爆款應(yīng)用的因素。

傳感器AI

大家都知道，一旦將數(shù)據(jù)處理盡可能放在靠前的流程中，不僅能降低功耗和延遲，也能極大地提升AI運(yùn)算的效率，省去交給云端處理這一繁瑣的步驟。在大部分IoT場景中，數(shù)據(jù)傳輸流程的頭部往往都是傳感器，所以無論是何種傳感器，制造商們都開始探討集成AI的方案。

比如，意法半導(dǎo)體就推出內(nèi)嵌智能傳感器處理單元（ISPU）的MEMS傳感器，直接將AI處理單元集成在傳感器上，打造一個智能傳感器。這樣的傳感器本身定制化程度也高，可直接對ISPU進(jìn)行C語言編程，也支持運(yùn)行多個AI算法。

更重要的是，這類將AI集成在傳感器方案顯著降低了功耗，在計(jì)算完成后才將有效的數(shù)據(jù)傳給待機(jī)狀態(tài)的MCU處理，真正實(shí)現(xiàn)了在MCU之前的數(shù)據(jù)智能處理。而且這種傳感器的設(shè)計(jì)也可以用上哈佛架構(gòu)，甚至可以直接進(jìn)行模擬運(yùn)算，再轉(zhuǎn)換成數(shù)字信號，實(shí)現(xiàn)更高的效率，最后再讓馮諾依曼架構(gòu)的CPU來完成工作。

寫在最后

我們自然也不能忽視掉在云端進(jìn)行AI處理的方案，固然這是一種將性能放大到極致的路線?？扇绻麑⑽唇?jīng)處理的數(shù)據(jù)一股腦交給云端處理的話，徒增上云成本不說，延遲也會大大增加；全部交給端測來完成AI計(jì)算的話，功耗續(xù)航都得做出讓步，甚至還是難以跑出可觀的性能。

這也就是為何亞馬遜、阿里巴巴等廠商紛紛部署IoT的邊緣計(jì)算的原因，即便邊緣端接手了主要的AI計(jì)算工作，卻依然可以將數(shù)據(jù)交給云端進(jìn)行管理、存儲和分析，而且這不一定是一個實(shí)時(shí)連接的過程，只需間歇性的同步也能完成任務(wù)。

更何況功能、固件升級這樣的任務(wù)主要還是交給云端來實(shí)現(xiàn)的，在有效的分析和訓(xùn)練下，云端可以將優(yōu)化過后的模型傳給邊緣端。所以由此看來，物聯(lián)網(wǎng)要想真正跨入AI時(shí)代，端云協(xié)同才是最佳方案。