低功耗AI芯片的明爭暗斗

隨著物聯(lián)網(wǎng)和下一代智能設備的普及，低功耗電子設備和芯片正在越來越多地進入千家萬戶，低功耗設計也在變得越來越重要。物聯(lián)網(wǎng)和智能設備一方面對于設備尺寸有限制，另一方面對于成本也有很高的需求，此外在一些使用場景中對于電池的更換和充電周期有需求（例如需要每個月或更長的電池更換周期），因此對于電池的容量有很高的限制，這要求芯片能使用低功耗設計。

另一方面，物聯(lián)網(wǎng)和智能設備正在越來越多地加入人工智能的特性。人工智能可以為物聯(lián)網(wǎng)和智能設備提供重要的新特性，例如語音類人工智能可以提供喚醒詞識別，語音指令識別等，而機器視覺類人工智能可以提供人臉檢測，事件檢測等等。如前所述，物聯(lián)網(wǎng)和智能設備對于低功耗有需求，因此人工智能特性的加入也需要是低功耗人工智能。

目前，人工智能芯片已經(jīng)在云端和智能設備終端普及，例如在云端以Nvidia和AMD為代表的GPU和以Intel/Habana為代表的人工智能加速芯片；而在終端智能設備則主要是在SoC上的人工智能加速IP，但是無論是GPU和SoC上的人工智能加速IP，都沒有考慮到低功耗的需求，因此在未來的物聯(lián)網(wǎng)和智能設備中的人工智能都需要有新的低功耗相關的設計。

                                                                                          傳感器計算：低功耗AI的重要技術路徑

在智能設備和物聯(lián)網(wǎng)應用中的低功耗人工智能需要把功耗降到非常低，從而能實現(xiàn)實時在線（always-on）的人工智能服務。這里所謂的always-on，指的就是人工智能需要永遠可用，而不需要用戶主動打開后才工作。這一方面需要相關的傳感器要一直打開從而實時檢測相關模態(tài)的信號，另一方面也需要人工智能能做到低功耗。

傳統(tǒng)設計中，傳感器的功能就是負責高性能信號采集，并且把采集到的信號傳輸?shù)教幚砥鳎⊿oC或者MCU）上去做進一步計算和處理，而傳感器本身并沒有計算能力。然而，傳統(tǒng)設計的假設是傳感器在打開時相關的處理器就要同時打開，而這并不能滿足always-on AI的需求，因為SoC和MCU如果一直在運行AI算法的話對于電池的消耗很大。另一方面，從實際角度來看，這類always-on人工智能應用主要是希望人工智能一直運行從而一旦重要的相關事件發(fā)生時可以實時響應（例如IMU檢測到用戶在開車則把智能設備的推送通知關掉等），但是事實上這類相關事件的發(fā)生頻率并不會很高，如果一直把SoC或者MCU的人工智能模塊打開，絕大多數(shù)時候AI模型的輸出都是“未檢測到事件”。

結(jié)合這兩點，運行在傳感器端的計算就在變得越來越得到重視。首先，在always-on的低功耗人工智能中，無論如何傳感器是需要一直打開的，因此如果傳感器能有人工智能計算能力，那么可以讓人工智能模型運行在傳感器端，而無需一直打開SoC或者MCU上面的人工智能模塊。另外，在傳感器端運行人工智能也可以避免傳感器和SoC/MCU之間一直傳輸數(shù)據(jù)，從而進一步降低功耗。最后，在傳感器端的人工智能模塊可以做到為傳感器量身定制而無需考慮通用性，因此可以為最適合傳感器的人工智能算法做定制化優(yōu)化，從而實現(xiàn)非常高的能效比。

當然，傳感器端的人工智能也有其自己的局限。一方面從性能和成本上來說，通常傳感器端的計算和存儲空間都較小，人工智能模塊無法做到支持大模型，因此模型的性能會比較有限。另一方面，如前所述傳感器端的人工智能也很難做到支持通用模型，而往往只會支持一些特定的算子和模型結(jié)構(gòu)。

綜上所述，傳感器端的人工智能可以做到低功耗，但是其模型性能也較為有限；但是另一方面低功耗人工智能場景中，真正需要處理的相關事件的發(fā)生頻率也并不高。結(jié)合這兩點，傳感器端人工智能最適合運行一些較為專用的小模型，用于過濾掉絕大多數(shù)的無關事件；而在傳感器端人工智能檢測到相關事件后，傳感器可以喚醒SoC或MCU上的人工智能進行下一步的確認，從而同時滿足低功耗和always-on的需求。

在圖像傳感器領域，Sony已經(jīng)推出了IMX500系列傳感器，其中把傳感器芯片和集成了人工智能計算能力的邏輯芯片做了堆疊，從而可以把像素信號傳輸給邏輯芯片上的人工智能計算引擎，從而傳感器的輸出可以是圖像，可以是人工智能模型的輸出，或者是兩者的結(jié)合。這樣一來，就可以讓傳感器運行在低功耗always-on狀態(tài)，而僅僅當其模型輸出符合某些特定條件（例如檢測到人臉）時才去喚醒MCU或者SoC做下一步動作。我們預計，Sony將會在接下來的傳感器芯片中進一步加強其人工智能能力，從而增強在這個領域的領先地位。

傳感器和人工智能結(jié)合的另一個例子是ST推出的IMU系列產(chǎn)品。ST在擁有相關人工智能特性的IMU中集成了機器學習核（Machine Learning Core）和有限狀態(tài)機（Finite State Machine），從而可以用非常高效的方式支持IMU上直接進行人工智能計算。ST目前支持的人工智能算法主要是決策樹算法，并且可以支持IMU信號的一些重要特征提?。ɡ缧盘柗龋盘柗讲畹龋?，從而能在IMU上直接實現(xiàn)用戶活動分類（例如靜止，行走，騎車，駕駛汽車等等分類），這樣能在檢測到相關事件時喚醒MCU/SoC進行下一步操作。根據(jù)ST公布的資料，MLC的功耗僅僅在微瓦數(shù)量級，從而能很好地支持always-on需求。當然，另一方面我們也看到?jīng)Q策樹算法事實上的能力有限，難以對于復雜的活動進行建模，因此如同我們之前討論的，這里的IMU傳感器內(nèi)人工智能適合完成事件的初篩來過濾掉無關事件，而更復雜的分類和確認可以通過運行在MCU或者SoC上的模型來完成。

                                                                                              低功耗人工智能MCU

除了傳感器內(nèi)人工智能之外，另一個重要的低功耗人工智能技術路徑是運行在MCU內(nèi)的人工智能。無論是物聯(lián)網(wǎng)還是智能設備，都離不開低功耗MCU作為最關鍵的控制單元，而通常來說MCU的功耗會比SoC要低一到兩個數(shù)量級。通過在MCU上集成人工智能，我們可以把運行人工智能的任務放到MCU上，從而無需喚醒SoC；或者在一些低成本應用中，成本考量使得無法集成SoC，這時候如果需要人工智能的話，擁有人工智能能力的MCU就是一個重要選項了。

值得注意的是，MCU上的人工智能和傳感器端的人工智能并不矛盾。如前所述，傳感器里的人工智能通常能運行的模型種類的復雜度都會比較有限，同時一個傳感器里的模型顯然只能使用該傳感器的信號作為輸入。另一方面，MCU上的人工智能模塊通?？梢灾С州^為通用的人工智能模型，同時也有機會做到使用多個傳感器的信號作為模型輸入。當然，MCU上的人工智能模塊的能效比通常會略遜于傳感器端的人工智能模塊，因此，在一個系統(tǒng)中可以把具有人工智能能力的傳感器和具有人工智能能力的MCU聯(lián)用，在傳感器端運行較為專用的第一級較為簡單的模型初篩事件，在需要的時候喚醒MCU上的 人工智能模塊去執(zhí)行較為通用的模型去進行事件確認。

目前，MCU芯片市場上已經(jīng)有一些相關的產(chǎn)品，例如NXP的RT600 MCU，該產(chǎn)品在ARM M33核之外，還集成了Tensilica HiFi 4 DSP并且擁有4.5 MB的片上存儲，從而可以加速通用人工智能模型。除了NXP之外，ADI的MAX78000 MCU集成了ARM M4和RISC-V核心，還集成了CNN加速器用來實現(xiàn)人工智能加速。我們認為，未來會有越來越多的低功耗MCU加入人工智能能力從而滿足物聯(lián)網(wǎng)和智能設備的需求。

                                                                                               低功耗人工智能的市場格局

如我們之前所討論的，低功耗人工智能更多并非創(chuàng)造一種新的芯片品類，而是在現(xiàn)有的芯片中加入人工智能能力，從而創(chuàng)造一定的差異化競爭優(yōu)勢。我們目前看到，無論是在傳感器端還是在MCU端，都有市場中處于領先地位的企業(yè)（例如傳感器領域的Sony，ST；MCU領域的NXP，ADI等等）在積極加入人工智能功能，未來可望會有越來越多的公司的產(chǎn)品也會在人工智能方面進行投入。

對于中國半導體企業(yè)來說，傳感器和MCU方面的人工智能也是一個值得重視的方向。目前來看，加入人工智能更多的是一個產(chǎn)品定位和集成度問題（即如何把握好產(chǎn)品對應的市場，并且去集成最合適的人工智能模塊），但是在未來隨著技術的進步，相關的技術積累也會逐漸加深，因此中國半導體廠商如果能在這個領域從目前就開始布局，可以加深自己在這方面的技術實力并且增加產(chǎn)品在未來智能物聯(lián)網(wǎng)和下一代智能設備里的競爭力。

轉(zhuǎn)載微信公眾號：半導體行業(yè)觀察

聲明：本文版權歸原作者所有，轉(zhuǎn)發(fā)僅為更大范圍傳播，若有異議請聯(lián)系我們修改或刪除：zhangkai@cgbtek.com