做了這么多年嵌入式我明顯感覺到圈子里的話風(fēng)變了。以前聊AI總覺得那是云端那群人的事跟單片機八竿子打不著。直到這幾年越來越多產(chǎn)品開始要求“本地智能”大家才慢慢反應(yīng)過來AI嵌入式并不是把大模型硬塞進(jìn)板子而是把模型壓縮到足夠小部署到邊緣端去解決實際問題。這個方向業(yè)內(nèi)叫TinyML也就是邊緣微型機器學(xué)習(xí)。這篇文章想講清楚一件事在典型單片機上TinyML到底能做什么。我不打算列一堆理論而是拆三個自己實際接觸過的典型用例來聊——離線語音喚醒、旋轉(zhuǎn)機械的振動異常監(jiān)測、低功耗圖像識別。每一個都會從場景取舍、數(shù)據(jù)怎么處理、模型怎么訓(xùn)練一路聊到部署到MCU上會踩哪些坑。適合正在做智能硬件、物聯(lián)網(wǎng)產(chǎn)品想給設(shè)備端加“判斷力”的嵌入式工程師。1. 先把“單片機跑大模型”這件事說透1.1 為什么一定要把模型放到邊緣很多人第一反應(yīng)是數(shù)據(jù)傳云端不是挺好嗎服務(wù)器性能強什么模型都能跑何必為難單片機這個想法放在十年前沒錯可放到真實的物聯(lián)網(wǎng)場景里就會撞上四堵墻。第一堵墻是實時性。語音喚醒這種交互從喊出喚醒詞到設(shè)備響應(yīng)延遲超過幾百毫秒人就會覺得“卡”。工業(yè)設(shè)備做故障保護(hù)要求在幾十毫秒內(nèi)對異常振動做出判斷把原始波形發(fā)到云端再等推理結(jié)果回來黃花菜都涼了。第二堵墻是帶寬和成本。一個振動監(jiān)測節(jié)點以2kHz采樣一秒鐘就產(chǎn)生幾千字節(jié)的原始數(shù)據(jù)?，F(xiàn)場布幾十個節(jié)點連續(xù)上傳的話通信流量很快爆炸云端的存儲和計算費用也跟著漲。邊緣推理只需要把“正?！被颉爱惓！边@種結(jié)果傳出去數(shù)據(jù)量從KB級降到Byte級。第三堵墻是功耗。無線節(jié)點如果每時每刻都在采樣上傳電池壽命只能按天算。換到邊緣推理后MCU大部分時間處于睡眠狀態(tài)只有檢測到事件才醒來跑模型功耗能直接降兩個數(shù)量級。第四堵墻是隱私。麥克風(fēng)采集的語音、攝像頭拍到的畫面、振動數(shù)據(jù)背后反映的設(shè)備狀態(tài)這些數(shù)據(jù)很多用戶并不希望傳到外部服務(wù)器。本地推理意味著原始數(shù)據(jù)不出設(shè)備只輸出結(jié)論產(chǎn)品在合規(guī)和信任上的壓力都會小很多。你會發(fā)現(xiàn)這四個約束只要占兩條以上TinyML就是比“云端”更合理的架構(gòu)。1.2 你以為的“大模型”和MCU上的模型不是一回事每次看到“單片機上部署大模型”這種說法總有人抬杠單片機連個像樣的操作系統(tǒng)都跑不動跑大模型不是在開玩笑嗎這里的“大模型”確實不是指在MCU上直接跑出參數(shù)量百億的大模型。它指的是“從大模型技術(shù)棧壓縮下來、能夠在邊緣運行的模型”。具體做法是先在服務(wù)器上訓(xùn)練一個表達(dá)能力強的模型——可能是幾千萬甚至上億參數(shù)——然后用蒸餾、剪枝、量化三步把模型壓成幾十KB到幾百KB的INT8定點模型再部署到MCU上。打個比方總部的大專家團(tuán)隊把所有場景研究透然后從里面提煉出一套適合嵌入式硬件的小技能交給精簡后的學(xué)生模型繼承。學(xué)生模型體積小了千萬倍但在特定任務(wù)上能力保留得還不錯。所以TinyML長期被誤解本質(zhì)上是很多人把“訓(xùn)練”和“推理”混為一談了。大模型負(fù)責(zé)訓(xùn)練階段的高成本高精度MCU只負(fù)責(zé)推理階段的低功耗低成本。明白了這一點后面很多選型決策就順了。1.3 三個硬指標(biāo)決定模型能不能跑在MCU上做AI選型之前先算三筆賬也就是三個硬指標(biāo)。硬指標(biāo)常見量級影響Flash存儲256KB~1MB決定模型參數(shù)和代碼能否放得下RAM內(nèi)存64KB~256KB決定中間特征圖能不能裝下是最大瓶頸算力幾十MHz~幾百MHz決定推理延遲和能否做連續(xù)推理功耗預(yù)算待機uA級推理mA級決定推理頻率和傳感器策略從經(jīng)驗上看振動監(jiān)測這類信號維度低、模型參數(shù)少對RAM和算力最友好語音喚醒次之卷積網(wǎng)絡(luò)參數(shù)量中等但特征圖不算大視覺識別最難激活緩沖區(qū)隨輸入分辨率快速膨脹RAM常常成為壓死項目的最后一根稻草。所以真正動手之前先畫一張“算力—內(nèi)存—存儲”的三角表能篩掉一半不切實際的方案。2. 第一類用例離線關(guān)鍵詞喚醒2.1 場景與為什么必須本地響應(yīng)智能音箱的“你好某助手”、智能門鎖的語音開門、兒童玩具的語音指令這類產(chǎn)品幾乎都有同一個要求喚醒詞必須本地響應(yīng)。原因很簡單如果連喚醒都要聯(lián)網(wǎng)設(shè)備斷網(wǎng)就成了廢鐵而且喚醒這種高頻操作如果每次都走云端延遲和流量都受不了。語音數(shù)據(jù)本身也敏感很多用戶不愿意自己的錄音被傳出去做分析。把喚醒詞模型放在MCU上語音信號從麥克風(fēng)到模型推理全在本地完成產(chǎn)品在隱私層面會更有說服力。這些因素疊加在一起讓“離線關(guān)鍵詞喚醒”成了TinyML落地最成熟的用例之一。2.2 從麥克風(fēng)信號到模型輸入從聲音到模型輸入中間有一條完整的信號鏈。先說采樣喚醒詞場景通常用16kHz采樣率、16bit位深這對人類語音來說足夠也不會給MCU帶來過大的數(shù)據(jù)壓力。拿到原始PCM數(shù)據(jù)之后要做的是分幀加窗。一般取25~30毫秒作為一幀相鄰幀之間重疊10~20毫秒保證特征不丟失。每一幀先乘一個窗函數(shù)然后做FFT再把頻譜用梅爾濾波器組映射到梅爾刻度取對數(shù)后做離散余弦變換得到MFCC特征。常見做法是每幀提取10~13維MFCC系數(shù)。把連續(xù)20~40幀的MFCC拼在一起就構(gòu)成了一張二維的“時頻圖”。對模型來說它看到的不是聲音波形而是這張圖。為什么選CNN而不是RNN來處理這種輸入原因很簡單CNN在MCU上沒有時序依賴推理路徑固定量化也更友好RNN的循環(huán)狀態(tài)在定點運算里很容易積累誤差處理起來麻煩得多。實際項目里常用的結(jié)構(gòu)是兩層普通卷積或深度可分離卷積再接一個全連接層輸出喚醒詞和非喚醒詞的概率。參數(shù)量通常只有一兩萬INT8量化之后模型體積在25KB左右非常契合MCU的Flash空間。2.3 部署實測與兩級喚醒架構(gòu)我拿一個模擬項目的數(shù)據(jù)做個參考這個項目用的是常見M內(nèi)核MCU主頻約80MHz。項目數(shù)值輸入40幀 × 13維MFCC模型大小INT8量化后約25KB激活RAM約14KB單次推理耗時約10ms喚醒前平均功耗幾百uA~幾mA量級這里有個特別值得說的設(shè)計兩級喚醒。系統(tǒng)平時只跑一個極小的語音活動檢測模型它的任務(wù)不是識別喚醒詞而是判斷當(dāng)前有沒有人在說話。一旦小模型檢測到語音活動再啟動完整的喚醒詞識別模型。兩級喚醒的價值在于小模型更小、更快可以一直掛機運行功耗極低大模型只在需要時才被喚醒整個系統(tǒng)的平均功耗被壓得很低。這個邏輯在MCU上用狀態(tài)機很容易實現(xiàn)是目前低功耗語音產(chǎn)品的主流做法。2.4 這個用例最容易踩的三個坑第一個坑是特征計算不一致。訓(xùn)練環(huán)境里用的MFCC參數(shù)比如幀長、幀移、濾波器個數(shù)必須和MCU端C代碼實現(xiàn)完全一致。很多人在PC上跑模型效果很好部署到板子上一塌糊涂查到最后發(fā)現(xiàn)是特征代碼的窗函數(shù)類型不同。第二個坑是麥克風(fēng)增益和噪聲。不同板子上的麥克風(fēng)模擬增益不一樣同一顆芯片在不同PCB上的底噪也不同。模型訓(xùn)練時一定要加入環(huán)境噪聲增強、不同音量增強最好是拿真機錄一段數(shù)據(jù)回灌訓(xùn)練集否則實際誤喚醒率會高到你懷疑人生。第三個坑是誤喚醒抑制。單幀模型的輸出概率容易有毛刺一秒前的噪聲可能突然觸發(fā)一個高概率輸出。工程上至少要做連續(xù)兩幀概率都超過閾值才觸發(fā)再加上一次短時靜默檢查誤喚醒率才能壓到可用水平。3. 第二類用例振動與聲音異常檢測3.1 為什么預(yù)測性維護(hù)是非主流但回報極高的TinyML場景相比語音喚醒振動監(jiān)測在消費電子產(chǎn)品里沒那么顯眼但在工業(yè)場景里回報極高。電機、泵、皮帶機這類旋轉(zhuǎn)設(shè)備發(fā)生故障之前振動波形會先出現(xiàn)微妙變化。如果能提前捕捉就能避免停機檢修和產(chǎn)線損失。傳統(tǒng)做法是布網(wǎng)關(guān)把振動數(shù)據(jù)集中上傳做分析。這種方案在廠區(qū)里施工成本高、維護(hù)麻煩而且很多老舊產(chǎn)線根本沒有穩(wěn)定的網(wǎng)絡(luò)環(huán)境。TinyML的好處在于每個傳感器節(jié)點本身就是一個判斷單元正常時靜默工作異常時本地產(chǎn)生告警事件遠(yuǎn)端只接收少量告警信息。數(shù)據(jù)不出現(xiàn)場模型不依賴網(wǎng)絡(luò)部署和運維都簡單得多。3.2 數(shù)據(jù)切片、頻域特征與自編碼器振動監(jiān)測的模型設(shè)計和語音喚醒完全不同。語音是“判斷這是什么詞”振動監(jiān)測更多是“判斷這個狀態(tài)正不正常”。數(shù)據(jù)層面加速度計或麥克風(fēng)以1kHz~20kHz采樣每次取1024或2048個采樣點作為一片窗口。窗口加窗后做FFT把時域信號變換到頻域。為什么一定要轉(zhuǎn)頻域因為頻域?qū)ο辔黄?、基線漂移不敏感而且旋轉(zhuǎn)設(shè)備的異常往往集中出現(xiàn)在特定頻段頻域特征更穩(wěn)定。接下來把關(guān)注的頻段劃分成幾十個區(qū)間比如0~2kHz分成48個頻帶統(tǒng)計每個頻帶的能量作為模型的輸入向量。模型結(jié)構(gòu)我推薦用自編碼器而不是傳統(tǒng)的分類網(wǎng)絡(luò)。自編碼器是一個“輸入—編碼—解碼—重建”的結(jié)構(gòu)。訓(xùn)練時只用正常數(shù)據(jù)目標(biāo)是在輸出端重建出和輸入一致的向量。推理時如果輸入數(shù)據(jù)偏離正常分布重建誤差就會變大。誤差超過閾值就認(rèn)為設(shè)備狀態(tài)異常。為什么選自編碼器因為故障樣本太稀有故障類型又千奇百怪很難收集到足夠的故障數(shù)據(jù)去練一個分類器。自編碼器只需要正常樣本就能學(xué)到“正常長什么樣”這是它在工業(yè)場景里最實用的原因。這個模型的參數(shù)量通常只有幾KINT8量化之后不到20KB。3.3 部署行為設(shè)計每一次推理都要算能耗振動監(jiān)測節(jié)點在現(xiàn)場往往是電池供電所以部署時的核心原則是周期性采集按需推理絕不連續(xù)跑。實際的狀態(tài)機大概是這樣節(jié)點進(jìn)入低功耗睡眠定時器按設(shè)定周期喚醒喚醒后給傳感器供電采集一個窗口的數(shù)據(jù)DMA搬運完成MCU用幾十毫秒做完FFT和模型推理輸出結(jié)果之后立刻再次進(jìn)入休眠。推理頻率不需要過高。旋轉(zhuǎn)機械的故障發(fā)展時間尺度通常以分鐘計每5秒采一次數(shù)據(jù)、跑一次模型已經(jīng)能捕捉絕大多數(shù)早期故障。把這個頻率降到每5秒一次節(jié)點平均電流能做到1mA量級電池壽命從“月拋”變成“季拋”甚至“年拋”。告警邏輯也值得單獨設(shè)計。單次推理的重建誤差超過閾值不代表設(shè)備立即壞了可能的偶發(fā)干擾也會觸發(fā)。工程上我會加一個防抖連續(xù)3個周期都超過閾值才上報告警。寧可晚幾秒不能頻繁誤報。3.4 這個用例的坑基線漂移和傅里葉前端這個場景最容易翻車的地方不在模型本身而在數(shù)據(jù)分布。第一個坑是傳感器安裝位置。同一個設(shè)備軸承座頂上和側(cè)面殼體上采集到的振動頻譜差別非常大。模型訓(xùn)練數(shù)據(jù)必須覆蓋實際安裝位置否則現(xiàn)場很可能一片誤報。第二個坑是設(shè)備之間的基線差異。同型號電機新出廠和運行五年的正常狀態(tài)下的頻譜能量都不一樣。自編碼器的重建閾值不能跨設(shè)備硬套部署后需要在每臺設(shè)備上做一段正常數(shù)據(jù)采集用本地數(shù)據(jù)重新標(biāo)定閾值。第三個坑是FFT前端。MCU上通常用定點FFT實現(xiàn)浮點模擬和定點實現(xiàn)之間的數(shù)值誤差雖然小但在某些頻帶能量很低的場景會被放大。建議在板子上寫一個自檢程序把FFT輸出和PC端對數(shù)看兩者之間的誤差是否在可接受范圍避免把工具鏈的數(shù)值問題當(dāng)成模型問題排查。4. 第三類用例低功耗視覺識別4.1 視覺上MCU的適用邊界如果說前兩類用例是“TinyML的舒適區(qū)”視覺識別就是“挑戰(zhàn)區(qū)”。MCU上的視覺能做的事包括圖像分類、物體存在性判斷、簡單場景識別不適合做高幀率連續(xù)檢測、復(fù)雜目標(biāo)分割。適合MCU的視覺場景有共同點目標(biāo)相對靜止、識別頻率低、環(huán)境可控。比如智能門鎖的攝像頭判斷有沒有人靠近、電表箱里的表盤讀數(shù)識別、野外昆蟲監(jiān)測相機等。這些場景的共同策略是“事件觸發(fā)”平時CPU和攝像頭都休眠被傳感器喚醒后抓拍一幀推理完馬上又睡。4.2 網(wǎng)絡(luò)結(jié)構(gòu)怎么壓縮才能塞進(jìn)去視覺模型不能在MCU上照搬MobileNet全家桶哪怕MobileNet已經(jīng)算輕量直接跑M內(nèi)核MCU也扛不住。要主動做結(jié)構(gòu)裁剪。第一步降分辨率。輸入圖像從224x224降到64x64~160x160通常優(yōu)先用灰度或單通道輸入。80x80灰度圖比224x224彩色圖的數(shù)據(jù)量小一個數(shù)量級識別精度在受限場景里依然夠用。第二步替換卷積結(jié)構(gòu)。用深度可分離卷積替代普通卷積把計算量降一個量級。第三步盡早下采樣。網(wǎng)絡(luò)前兩層就做池化把特征圖快速縮小。我常用的一種輕量結(jié)構(gòu)大概長這樣層輸出尺寸說明輸入80×80×1灰度圖Conv 3×3, 1680×80×16激活緩沖約25.6KB池化40×40×16DepthwiseConv 3240×40×32池化20×20×32DepthwiseConv 6420×20×64池化10×10×64全局平均池化64替代全連接省參數(shù)全連接輸出10類這里最關(guān)鍵的一點是把尾部全連接層替換成全局平均池化。全連接層的參數(shù)量巨大但換成GAP之后模型權(quán)重能小一個量級對精度的影響卻很小。4.3 事件驅(qū)動架構(gòu)與實測數(shù)據(jù)MCU視覺的功耗大頭往往不是推理本身而是攝像頭和補光燈。一片圖像傳感器的功耗可能是MCU跑模型的幾倍甚至幾十倍所以視覺系統(tǒng)的架構(gòu)必須是事件驅(qū)動的人體紅外傳感器或振動傳感器先判斷“有沒有目標(biāo)”確認(rèn)有目標(biāo)后才給攝像頭供電拍一幀圖像通過DMA轉(zhuǎn)入SRAM然后MCU才跑推理。推理結(jié)束立刻斷電回到睡眠狀態(tài)。我跑過的一個視覺分類Demo輸入80×80灰度圖INT8量化模型權(quán)重幾十KB單幀推理耗時約1到2秒。這個延遲對門鎖、表計這類場景完全可接受因為用戶感知等待的時間主要來自門鎖機械結(jié)構(gòu)而不是識別本身。4.4 視覺用例最大的坑視覺是三類用例里坑最多的我按出現(xiàn)頻率排個序。第一是光照。真實世界的亮度變化極大同一件物體在白天和夜間拍出來在模型眼里可能是兩種東西。訓(xùn)練數(shù)據(jù)必須做亮度擾動、對比度擾動最好直接把真實場景不同時間段拍攝的圖像放進(jìn)去否則現(xiàn)場效果會慘不忍睹。第二是量化敏感。視覺特征的激活分布往往帶有長尾PTQ量化后精度回退比語音場景明顯。遇到這種情況要轉(zhuǎn)QAT也就是在訓(xùn)練過程中引入偽量化算子讓模型適應(yīng)低精度表示。第三是圖像質(zhì)量。很多團(tuán)隊把精力都花在調(diào)模型精度卻忽略了攝像頭對焦、鏡頭臟污、紅外濾光片帶來的偏色。這些圖像前端的問題靠模型根本“救”不回來排查時要先懷疑成像鏈路。第四是目標(biāo)檢測場景。MCU上不要跑NMS這類復(fù)雜后處理直接在圖像上用滑窗方式跑分類模型輸出各個窗口的類別概率和位置把原始結(jié)果交給上位機去做框選。省內(nèi)存又省算力實際效果還不錯。5. 從模型到MCU完整落地流程與工程工具鏈5.1 實踐下來的五步流水線很多初次接觸TinyML的人以為模型訓(xùn)練完直接用工具轉(zhuǎn)換就行。實際項目里我一般按這五步走第一步在通用深度學(xué)習(xí)框架里訓(xùn)練一個盡量準(zhǔn)的浮點模型。這個階段的目標(biāo)是驗證任務(wù)本身的可行性數(shù)據(jù)夠不夠、特征表達(dá)夠不夠、結(jié)構(gòu)能不能收斂。第二步做模型極小化。用剪枝把不重要的通道去掉再用蒸餾把大模型的知識遷移到小模型把參數(shù)量壓到目標(biāo)范圍。第三步轉(zhuǎn)換并且校驗。用芯片原廠的MCU工具鏈把模型轉(zhuǎn)換成INT8定點格式。這一步要特別注意算子支持情況某些結(jié)構(gòu)在原廠工具鏈里不支持會直接報錯。第四步工程集成。寫設(shè)備驅(qū)動、特征計算、推理運行時調(diào)用、電源管理邏輯把模型真正嵌進(jìn)嵌入式工程。第五步真機回測。在板子上批量跑真機采集的數(shù)據(jù)把浮點模型在PC上的輸出、定點模型在板子上的輸出逐條對比。這一步能發(fā)現(xiàn)很多工具鏈報告不出來的問題。這一步看著多但每一步都不難難的是堅持把每步做扎實尤其是最后一步。5.2 PTQ與QAT怎么選量化是TinyML繞不開的話題INT8定點量化可以把模型體積壓縮到原來的四分之一推理速度也能提升不少。PTQ也就是訓(xùn)練后量化流程很簡單模型浮點訓(xùn)練好之后收集200到500條有代表性的校準(zhǔn)數(shù)據(jù)統(tǒng)計每層激活值的分布范圍算出縮放因子把權(quán)重和激活都轉(zhuǎn)成INT8。這種方法時間成本低多數(shù)場景下夠用。QAT也就是量化感知訓(xùn)練是在訓(xùn)練過程中就加入偽量化算子讓模型提前適應(yīng)低精度的“粗糙感”。它會允許梯度和參數(shù)一點點修正量化誤差精度明顯更穩(wěn)代價是訓(xùn)練時間和調(diào)參成本上來了。我的建議是先做PTQ拿一個及格版本如果精度掉點超標(biāo)再對敏感層做QAT或者混合精度。校準(zhǔn)集的選擇比量化方法本身更重要它必須覆蓋真實場景的分布比如現(xiàn)場噪聲、不同光照條件而不是隨便拿訓(xùn)練集里的幾百張圖糊弄。5.3 內(nèi)存的工程經(jīng)驗內(nèi)存是MCU上跑模型最大的硬約束這里有幾條實戰(zhàn)經(jīng)驗值得分享。第一模型參數(shù)一定要放到Flash常量區(qū)不要放在RAM里。有些工具鏈默認(rèn)把模型數(shù)據(jù)放到可讀寫段RAM水漲船高改一下段屬性就能省出十幾KB。第二優(yōu)先選擇支持共享激活緩沖區(qū)的推理運行時。早期很多方案是每層動態(tài)分配內(nèi)存激活緩沖區(qū)一個疊一個RAM占用按倍數(shù)膨脹。改成共享緩沖之后所有層復(fù)用一塊內(nèi)存RAM占用能降到原來的三分之一。第三如果模型實在太大有一個技巧把模型放在外部SPI Flash里推理時按層把權(quán)重搬到內(nèi)部RAM再計算算完一層就釋放。雖然會慢一些但理論上可以跑比內(nèi)部Flash大得多的模型。第四大工程建議用一個內(nèi)存映射表格把每個緩沖區(qū)、每個模型的段地址都登記清楚。這個習(xí)慣在排查問題時能節(jié)省大量時間比臨時用調(diào)試器看變量靠譜得多。5.4 部署后精度變差先查什么模型轉(zhuǎn)換完上板精度回退是家常便飯。這時候不要急著懷疑量化先按這個清單排查預(yù)處理和特征提取的數(shù)值類型是否一致。固定點數(shù)格式、均值方差歸一化參數(shù)是否原樣搬到了C代碼里。數(shù)據(jù)通路是否丟幀或錯位。DMA緩沖是否覆蓋了一整幀數(shù)據(jù)中斷搶占了其他內(nèi)存會不會污染輸入。校準(zhǔn)集分布是否偏離真實場景。校準(zhǔn)用的是白噪聲真機上是空調(diào)噪聲怎么量化都會掉點。算子映射是否存在隱式替換。原廠工具鏈可能把一個算子映射成精度稍低的實現(xiàn)需要查看轉(zhuǎn)換日志。中斷和任務(wù)的并發(fā)問題。推理時數(shù)據(jù)被另一個任務(wù)改寫這種問題日志根本看不出只能靠代碼審查。我的經(jīng)驗是大多數(shù)TinyML項目部署后精度下降根本輪不到INT8量化背鍋八成是前后處理沒對齊。把這條清單走一遍往往能找到真兇。6. 三類用例之外我更想提醒大家的幾件事6.1 先回答“為什么是TinyML”看完三類用例你會發(fā)現(xiàn)TinyML并不是萬能的。如果產(chǎn)品網(wǎng)絡(luò)穩(wěn)定、數(shù)據(jù)不敏感、功耗沒有極端的約束云端方案其實更靈活模型可以隨便換、隨時升級。TinyML的價值集中在五個約束上延遲、帶寬、成本、功耗、隱私。只有當(dāng)其中至少兩條成為產(chǎn)品的硬需求時才值得把AI挪到MCU上。這聽起來像在勸退但實際上是在幫你做取舍。拿著“別人都在做邊緣AI”這樣的理由立項項目大概率會中途返工。拿著真實的延遲和功耗需求去立項每一行代碼才有方向。6.2 模型小不等于工程簡單“喚醒模型只有25KB”“視覺權(quán)重只有幾十KB”聽起來很輕巧但背后是音頻前端的聯(lián)調(diào)、圖像鏈路的校準(zhǔn)、量產(chǎn)一致性的驗證。模型壓縮只是整個項目的一小段真正的工程量在傳感器、驅(qū)動和現(xiàn)場環(huán)境適配。我見過太多團(tuán)隊在模型結(jié)構(gòu)上死磕卻在工程集成階段被一個DMA緩沖對齊問題卡兩周。模型小只代表算力門檻低不代表系統(tǒng)復(fù)雜度低。6.3 給正在入坑的人三個執(zhí)行建議第一從“端到端最小切片”開始。哪怕精度一般也要先讓數(shù)據(jù)從傳感器流到模型再流到輸出。這條鏈路一斷后面每一步都會踩坑。第二盡早建立回測工具。在板子上寫一個自動化腳本批量輸入驗證集數(shù)據(jù)同時輸出模型推理結(jié)果和PC端結(jié)果對比。沒有回測工具你根本無法判斷一次改動是變好了還是變差了。第三提前對原廠工具鏈做算子測試。把自己的網(wǎng)絡(luò)結(jié)構(gòu)拆成最小算子逐個驗證不要等部署時才發(fā)現(xiàn)某個常用操作不被支持。至少在我接手過的幾個項目里只要把這三條放在最前面踩坑密度能下降一半以上。