直接在手機(jī)上跑大模型在攝像頭里做實(shí)時識別在耳機(jī)里做降噪——這些場景背后有個共同的名字端側(cè)部署。過去兩年我一直在折騰把AI模型從服務(wù)器搬到各種邊緣設(shè)備上踩坑無數(shù)也積累了一些實(shí)戰(zhàn)經(jīng)驗(yàn)。這篇東西不聊概念直接講清端側(cè)部署和優(yōu)化到底在做什么、怎么做以及那些文檔里永遠(yuǎn)不會寫的坑。這個內(nèi)容適合誰三類人一是做AI應(yīng)用但模型只在云端跑、想降低成本或提升響應(yīng)速度的工程師二是嵌入式或移動端開發(fā)要往現(xiàn)有產(chǎn)品里塞AI能力三是剛?cè)腴T想搞明白“模型是怎么從訓(xùn)練環(huán)境跑進(jìn)真機(jī)的”的初學(xué)者。不管哪一類讀完都可以直接拿里面的參數(shù)和流程去試。一個核心觀點(diǎn)先放前面端側(cè)部署不是簡單地模型轉(zhuǎn)換而是算力、內(nèi)存、功耗、延遲四個約束下的系統(tǒng)工程。1. 端側(cè)AI部署到底在解決什么問題1.1 云端推理和端側(cè)推理的博弈先想一個常見場景手機(jī)上的拍照翻譯。你把相機(jī)對準(zhǔn)路牌App把圖像傳到服務(wù)器服務(wù)器跑完OCR把結(jié)果返回手機(jī)。這流程技術(shù)上完全可行但會遇到幾個讓人頭疼的事網(wǎng)絡(luò)一抖結(jié)果就延遲地鐵里信號滿格但帶寬不足識別要等好幾秒更麻煩的是隱私——每張照片都上傳用戶心理上就過不去。而端側(cè)部署是把模型直接放進(jìn)設(shè)備本地圖像識別全部在手機(jī)內(nèi)部完成網(wǎng)絡(luò)斷了也能用。云端推理的優(yōu)勢是算力無限想上多大模型就上多大但代價是傳輸延遲、帶寬成本、隱私合規(guī)。端側(cè)推理的優(yōu)勢是零延遲本地執(zhí)行、低成本不用租GPU、隱私安全數(shù)據(jù)不出設(shè)備但代價是算力捉襟見肘。這兩年模型壓縮技術(shù)的發(fā)展讓以前必須在云端跑的模型也能在設(shè)備上跑得有模有樣。這背后的平衡很大程度上決定了產(chǎn)品架構(gòu)怎么設(shè)計(jì)。1.2 端側(cè)部署的四個核心約束算力、內(nèi)存、功耗、延遲端側(cè)設(shè)備和服務(wù)器最大的區(qū)別在于算力。服務(wù)器顯卡動輒幾百TOPS手機(jī)上NPU可能只有幾TOPS到幾十TOPS嵌入式設(shè)備更可憐可能只有0.5TOPS甚至更低。算力直接決定模型能有多大的計(jì)算量也就是FLOPs浮點(diǎn)運(yùn)算次數(shù)。一個簡單的參考10MB左右的MobileNet V3模型在一顆中等算力的邊緣NPU上跑一次推理大概需要10到30毫秒但同樣算力的設(shè)備跑ResNet-50就要100毫秒往上這就是為什么端側(cè)常用輕量級模型。內(nèi)存是第二個坑。模型文件本身要占存儲推理時中間特征圖要占運(yùn)行內(nèi)存。一個300MB的大模型在只有1GB RAM的嵌入式板子上光加載就夠嗆。我見過最典型的翻車現(xiàn)場模型量化都做了但輸入分辨率沒降一張1080P的圖直接把內(nèi)存撐爆進(jìn)程被殺。功耗做端側(cè)的人很少第一時間關(guān)注但等產(chǎn)品做出來就傻眼了。手機(jī)還好電池大撐得住換成IoT設(shè)備或智能門鎖電池可能要撐一年。NPU跑一次推理的功耗和CPU完全不同實(shí)測下來同一模型在CPU上要2.5W在NPU上只要0.8W——這個差距決定你的設(shè)備能連續(xù)用幾天還是幾個月。延遲在端側(cè)其實(shí)是雙刃劍。端到端延遲短是端側(cè)帶來的優(yōu)勢但模型本身計(jì)算慢又會把優(yōu)勢吃掉。目標(biāo)是讓單次推理延遲盡量小同時省電。這里有一個常見誤區(qū)不是所有場景都要幾十毫秒級延遲連續(xù)幀檢測每秒跑5幀就夠反而把功耗降下來更重要。所以技術(shù)選型前先定指標(biāo)延遲要求多少毫秒內(nèi)存占用多少M(fèi)B功耗預(yù)算多少瓦指標(biāo)定了技術(shù)路線才好選。1.3 什么樣的模型適合端側(cè)部署不是所有模型都能塞進(jìn)設(shè)備通常要滿足幾個條件一是參數(shù)量可控百萬到千萬級別比較好二是支持算子兼容Transformer的某些固定算子如果設(shè)備不支持就很麻煩三是激活值和中間張量不能太夸張否則內(nèi)存直接爆炸。判斷模型能不能端側(cè)跑有個簡單粗暴的公式模型文件大小乘以2到3估算出峰值內(nèi)存占用看設(shè)備是否吃得住。比如10MB的模型理論上運(yùn)行內(nèi)存占用可能在20MB到30MB左右如果設(shè)備可用內(nèi)存只有十幾MB就得重新設(shè)計(jì)或量化。還有一個經(jīng)驗(yàn)先跑一遍ONNX Runtime在CPU上的基準(zhǔn)再評估是否值得上NPU別一上來就搞硬件加速。2. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)2.1 模型壓縮三板斧量化、剪枝、蒸餾做端側(cè)部署前第一件事是縮小模型。縮放模型有三種主流方式量化、剪枝、蒸餾聽起來高大上其實(shí)思路都不復(fù)雜。量化是這三板斧里見效最快、成本最低的一種。原理是把FP32浮點(diǎn)權(quán)重映射到INT8甚至INT4整型表示。FP32每個參數(shù)占4字節(jié)INT8只占1字節(jié)參數(shù)體積直接縮水75%。以YOLOv5s為例原始FP32權(quán)重約14MB轉(zhuǎn)成INT8后約3.8MB體積壓縮到27%左右。這不僅僅省存儲推理速度也能提升。因?yàn)榇蠖鄶?shù)硬件的整數(shù)運(yùn)算單元比浮點(diǎn)運(yùn)算單元多而且?guī)拤毫ψ冃∷愕镁涂?。量化的?shí)現(xiàn)方式分兩種訓(xùn)練后量化PTQ和量化感知訓(xùn)練QAT。PTQ是最省事的模型訓(xùn)練完之后直接轉(zhuǎn)但精度可能會掉QAT是在訓(xùn)練過程中模擬量化誤差讓模型適應(yīng)低精度表達(dá)精度保持更好但需要重新訓(xùn)練模型。對新手來說先做PTQ精度不行了再用QAT補(bǔ)救。量化的過程本質(zhì)上是在做信息壓縮最核心的就是校準(zhǔn)——用一個小的校準(zhǔn)數(shù)據(jù)集跑一遍模型統(tǒng)計(jì)激活值的分布范圍然后確定量化參數(shù)。校準(zhǔn)數(shù)據(jù)集選得好不好直接影響量化后的精度。剪枝是另一條路思路是刪除模型中對輸出貢獻(xiàn)不大的權(quán)重或通道。剪枝分為結(jié)構(gòu)化剪枝和非結(jié)構(gòu)化剪枝非結(jié)構(gòu)化剪枝把某些權(quán)重置為零模型是稀疏了但實(shí)際加速有限結(jié)構(gòu)化剪枝把一整個通道或卷積核砍掉能真正減少計(jì)算量。實(shí)操中結(jié)構(gòu)化剪枝配合稀疏訓(xùn)練一起做效果更穩(wěn)。剪枝比例一般從20%起步最大不建議超過60%剪太多了精度會斷崖式下跌。剪完后通常要做一次微調(diào)恢復(fù)精度這是一個繞不開的步驟。知識蒸餾思路完全不同。用一個大的Teacher模型老師指導(dǎo)一個小Student模型學(xué)生學(xué)習(xí)。學(xué)生模型的結(jié)構(gòu)可以比老師小很多但訓(xùn)練目標(biāo)除了真實(shí)標(biāo)簽外還加上模擬老師的輸出分布。一句話理解就是大模型考完試把解題思路也傳給小模型。蒸餾出來的學(xué)生模型體積小但往往能在小體積下保持比直接訓(xùn)練更接近大模型的精度?，F(xiàn)在很多輕量模型比如MobileNet系列、EfficientNet-Lite本身就用類似思想設(shè)計(jì)過配合蒸餾還能繼續(xù)榨出潛力。2.2 量化中的參數(shù)選擇與精度損失分析量化不是直接把數(shù)字從FP32變成INT8就行背后幾個關(guān)鍵參數(shù)需要認(rèn)真對待。第一個是對稱量化和非對稱量化。對稱量化把權(quán)重范圍看成對稱區(qū)間[-127, 127]做起來簡單但低位利用率低非對稱量化允許正負(fù)范圍不同能更精確表達(dá)分布不對稱的數(shù)值。實(shí)踐中權(quán)重一般用對稱量化激活值因?yàn)榻?jīng)過ReLU等函數(shù)后基本為非負(fù)分布用非對稱量化效果更好。第二個是校準(zhǔn)方法。PTQ量化確定激活值范圍依賴校準(zhǔn)數(shù)據(jù)集常見方法有MinMax和Percentile。MinMax取實(shí)際出現(xiàn)的最大最小值簡單但容易被離群點(diǎn)干擾Percentile是取百分之99.99這種分位點(diǎn)能避開離群點(diǎn)更穩(wěn)。我實(shí)測下來Percentile結(jié)合幾個典型輸入圖像做校準(zhǔn)比MinMax穩(wěn)定很多。數(shù)據(jù)校準(zhǔn)集通常選100到1000個樣本就夠核心原則是分布要接近真實(shí)場景而不是隨便拿一堆訓(xùn)練集圖片。量化后精度損失怎么評估有一個核心指標(biāo)叫相對精度損失量化前后模型在驗(yàn)證集上的mAP或ACC之差除以原始精度。一般來說圖像分類任務(wù)從FP32到INT8損失在0.5%以內(nèi)是完全正常的超過1%就需要調(diào)整了。檢測任務(wù)敏感一些我常用語義分割和檢測模型INT8后調(diào)參調(diào)得好損失可以控制在1%以內(nèi)。如果損失過大第一反應(yīng)是換校準(zhǔn)數(shù)據(jù)集和校準(zhǔn)方法別急著上QATQAT訓(xùn)練時間成本和復(fù)雜度都高得多能通過PTQ解決的問題就不上重武器。2.3 針對NPU的算子融合與內(nèi)存布局優(yōu)化模型轉(zhuǎn)換到NPU上跑不等于把每個算子平移過去就行。NPU的調(diào)度單元和GPU、CPU完全不同很多情況下優(yōu)化重心在算子融合和內(nèi)存布局上。算子融合簡單說是把多個連續(xù)的小算子合并成一個大算子。最典型的是ConvBNReLU融合。訓(xùn)練時BatchNorm對每個通道做歸一化推理時這三個操作完全可以合并進(jìn)卷積層。RNN里的LSTM門控計(jì)算也可以做類似融合。融合后的好處是減少中間張量的讀寫減少Kernel啟動的開銷。以ARM平臺CPU為例ConvBNReLU三算子融合后性能可能提升30%甚至50%。而在NPU上算子融合更重要因?yàn)槊看螁右粋€NPU算子都有固定開銷算子數(shù)量直接減少調(diào)度開銷就省下來了。內(nèi)存布局方面?zhèn)鹘y(tǒng)CPU上數(shù)據(jù)是按NCHW排的NPU或GPU卻通常偏好NHWC。不說原理直接說結(jié)論如果你的模型在CPU上跑得好轉(zhuǎn)到NPU后如果算子不支持或性能不達(dá)標(biāo)第一件事就是把數(shù)據(jù)布局調(diào)整為NHWC很多時候性能立刻改善。另一個經(jīng)驗(yàn)是內(nèi)存復(fù)用。NPU跑Transformer結(jié)構(gòu)時中間激活值會反復(fù)后覆蓋如果計(jì)算圖分配內(nèi)存時不注意復(fù)用內(nèi)存峰值會上得很快。推理框架一般會做內(nèi)存池優(yōu)化但如果自定義算子很多就得手動規(guī)劃中間緩沖區(qū)。2.4 編譯器優(yōu)化在端側(cè)AI中的作用編譯器優(yōu)化在端側(cè)部署中是個容易被忽視但影響很大的環(huán)節(jié)。模型代碼不會直接一行一行解釋執(zhí)行而是要經(jīng)過編譯器的調(diào)度、向量化、寄存器分配等一系列優(yōu)化。很多情況下同樣的模型在不同編譯器版本下性能差幾倍。在端側(cè)AI領(lǐng)域編譯器優(yōu)化有幾個方向。一是循環(huán)平鋪和循環(huán)重排。矩陣乘法或卷積本質(zhì)是嵌套循環(huán)編譯器通過重新排列循環(huán)順序提高緩存命中率。如果模型運(yùn)行在CPU上GCC或Clang的O2和O3優(yōu)化級別不同性能差異就能到30%。二是自動向量化。現(xiàn)代CPU都有NEON等SIMD指令編譯器如果能自動把標(biāo)量運(yùn)算轉(zhuǎn)換成向量運(yùn)算推理速度會大幅提升。三是算子級別的融合優(yōu)化。TFLite和ONNX Runtime都會在編譯期將多個算子融合成性能更優(yōu)的組合。我做RKNN部署時尤其有體會。RKNN-Toolkit本身會將模型編譯成NPU能跑的指令但不同版本的編譯器對同一個模型的優(yōu)化結(jié)果差很多。有時候轉(zhuǎn)出來跑一遍benchmark算子耗時沒有明顯改善換個工具版本后性能直接翻倍。所以工具鏈版本管理要嚴(yán)格別追新也別守著舊版以實(shí)際benchmark為準(zhǔn)。3. 推理框架與硬件加速工具鏈選型3.1 端側(cè)推理框架橫向?qū)Ρ冗x框架是整個環(huán)節(jié)中最讓人糾結(jié)的。每個框架都有自己的限制和優(yōu)勢選錯了就是災(zāi)難。我這幾年的使用經(jīng)驗(yàn)列一張表方便對照框架適用硬件優(yōu)點(diǎn)局限TensorFlow LiteAndroid/iOS/嵌入式生態(tài)成熟支持模型廣對有自定義算子的模型支持一般ONNX Runtime跨平臺格式開放算子覆蓋廣NPU加速需要自己接EP工作量稍大OpenVINOIntel CPU/GPU/NPUIntel硬件優(yōu)化極強(qiáng)綁定Intel生態(tài)RKNNRockchip NPU瑞芯微平臺部署首選僅支持自家芯片算子兼容性要驗(yàn)證NCNN移動端CPU輕量純C對NPU加速支持有限MNN移動端/嵌入式性能好阿里巴巴維護(hù)社區(qū)資料相對TFLite少選型邏輯其實(shí)很直接先定硬件再定框架。硬件決定上限框架決定可行性。如果你的設(shè)備是瑞芯微芯片直接用RKNN是最省事的如果是高通開發(fā)板那就得看高通Snapdragon Neural Processing Engine或者直接走TFLite。OpenVINO在Intel平臺上是神器但出了Intel生態(tài)就麻煩了。NCNN適合純CPU推理尤其老設(shè)備因?yàn)橐蕾嚇O少。硬件平臺算力典型值推薦框架典型部署方案手機(jī)中高端10-30 TOPSTFLite/ONNX Runtime用NNAPI或CoreML加速邊緣盒子RK35886 TOPSRKNNNPU推理CPU做前后處理樹莓派1 TOPSTFLite/ONNX RuntimeCPU推理模型盡量精簡Intel NUC依賴集顯OpenVINOGPU/NPU加速很多人在框架上翻車其實(shí)問題不在框架本身而是沒有想清楚運(yùn)行設(shè)備。舉個例子我之前做過一個工業(yè)質(zhì)檢項(xiàng)目客戶指定用某品牌工控機(jī)國產(chǎn)芯片加專用NPU。TFLite根本不支持那個NPU最后只能繞道走廠商的私有推理引擎還得手動改模型格式。如果一開始就摸清硬件底細(xì)根本不用浪費(fèi)那兩星期。3.2 工具鏈中的模型轉(zhuǎn)換與算子兼容性模型轉(zhuǎn)換是整個流程里最繁瑣的一環(huán)。無論是轉(zhuǎn)TFLite、OpenVINO還是RKNN流程都是訓(xùn)練出PyTorch模型先轉(zhuǎn)成ONNX再從ONNX轉(zhuǎn)到目標(biāo)框架的格式。這一步最怕的坑是算子不支持。某個自定義算子目標(biāo)框架沒有對應(yīng)實(shí)現(xiàn)整個轉(zhuǎn)換就卡住了。轉(zhuǎn)換時最實(shí)用的技能是算子替換。以RKNN為例其對Transformer類模型的算子支持一直不如CNN那么好。遇到不支持的算子有兩條路一是改模型結(jié)構(gòu)用等價操作替換比如把某個自定義上采樣換成ResizeConv的組合二是把不支持的部分留在CPU上跑模型切分成NPU部分和CPU部分配合Unity進(jìn)行混合運(yùn)行。這里強(qiáng)調(diào)一下切分模型是家常便飯別覺得分裂模型就丟人它反而能發(fā)揮各自的優(yōu)勢。另一個常見坑是動態(tài)維度問題。端側(cè)模型盡量固定輸入尺寸。RKNN對動態(tài)shape的支持現(xiàn)在有所改善但動態(tài)shape帶來的性能損失很大還要開啟額外的選項(xiàng)。生產(chǎn)環(huán)境中最簡單粗暴的方法是固定輸入分辨率比如224x224或640x640能避免一大半轉(zhuǎn)換問題。如果需要不同分辨率盡量轉(zhuǎn)換成多個模型運(yùn)行時按需選擇。3.3 環(huán)境依賴與交叉編譯實(shí)戰(zhàn)端側(cè)部署的另一個核心問題是環(huán)境搭建。我早期做RKNN部署時最頭疼的就是環(huán)境配置。模型轉(zhuǎn)換工具鏈的Python版本、依賴庫版本、交叉編譯器版本任何一個不匹配就會報(bào)各種看不懂的鏈接錯誤。以RKNN-Toolkit為例官方推薦Python版本和Ubuntu版本都有明確要求如果不匹配首先會出現(xiàn)“GLIBC版本太低”這類莫名其妙的問題。這種問題不出意外都是系統(tǒng)依賴版本不對不是程序運(yùn)行邏輯的問題。實(shí)際操作流程是在主機(jī)PC上用Python轉(zhuǎn)換并仿真模型驗(yàn)證OK之后再交叉編譯到ARM設(shè)備上跑。這個流程拆開來看主機(jī)PC只負(fù)責(zé)運(yùn)行RKNN-Toolkit做模型轉(zhuǎn)換和精度驗(yàn)證設(shè)備端只運(yùn)行RKNN Runtime和NPU驅(qū)動負(fù)責(zé)推理部署時通過ADB或SFTP把.rknn模型文件和可執(zhí)行程序上傳到設(shè)備然后運(yùn)行測試。我在這個環(huán)節(jié)里學(xué)到的最重要一課先花時間把構(gòu)建環(huán)境做成Docker鏡像或腳本固化下來。我一開始在裸系統(tǒng)上直接裝依賴結(jié)果半年后要復(fù)現(xiàn)一個老項(xiàng)目環(huán)境全亂了等于重新踩一遍坑。后來我把環(huán)境固化成Docker鏡像換電腦部署項(xiàng)目時直接加載鏡像半小時就能開始干活。4. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)以RK3588平臺部署目標(biāo)檢測模型為例4.1 從YOLOv8訓(xùn)練到ONNX導(dǎo)出的細(xì)節(jié)前面說了不少理論這里帶大家完整走一遍流程。用最常見的YOLOv8n做目標(biāo)檢測模型部署到瑞芯微RK3588平臺6TOPS NPU。整體流程訓(xùn)練檢查點(diǎn)轉(zhuǎn)ONNXONNX轉(zhuǎn)RKNN量化NPU編譯然后在板端運(yùn)行。模型用YOLOv8n輸入尺寸定成640x640訓(xùn)練數(shù)據(jù)集是自采的工業(yè)零件圖。FP32模型權(quán)重約6MB這量級在端側(cè)算是友好。但6TOPS算力限制下不做量化YOLOv8n一次推理在NPU上約30ms轉(zhuǎn)INT8后可以壓到15ms以內(nèi)。這個差距在實(shí)時場景下非常明顯比如30fps視頻流35ms延遲意味著每幀處理剛好卡在30fps邊緣壓到15ms后余量就很大了。從PyTorch導(dǎo)出ONNX時有幾個參數(shù)要特別留意python export.py --weights yolov8n.pt --opset 12 --simplify --include onnx用--simplify非常關(guān)鍵它會將計(jì)算圖中的冗余節(jié)點(diǎn)去除。我見過沒加simplify的ONNX文件包含大量Identity和Cast節(jié)點(diǎn)轉(zhuǎn)到RKNN后算子數(shù)翻倍NPU上性能下降明顯。ONNX的opset選12即可太高或太低都可能碰到兼容問題。另外輸入維度要固定不設(shè)置動態(tài)尺寸。4.2 RKNN模型轉(zhuǎn)換與INT8量化調(diào)優(yōu)接下來用RKNN-Toolkit做轉(zhuǎn)換。量化這一步是整個端側(cè)優(yōu)化中最講究的。from rknn.api import RKNN rknn RKNN() rknn.config( mean_values[[0, 0, 0]], std_values[[255, 255, 255]], target_platformrk3588 ) rknn.load_onnx(modelyolov8n.onnx) rknn.build(do_quantizationTrue, datasetdataset.txt) rknn.export_rknn(yolov8n_int8.rknn)dataset.txt里放的是一批校準(zhǔn)圖片路徑這個校準(zhǔn)集不是隨便選的。我踩過坑之后總結(jié)了一個原則校準(zhǔn)集要覆蓋推理場景中的典型情況每個類別至少十幾張并且光照、角度、遮擋情況盡量多樣化。比如質(zhì)檢項(xiàng)目里的正常品、次品、半遮擋品都需要有。不要拿全訓(xùn)練集去做校準(zhǔn)幾百張足以太多了不會明顯提升精度反而拖慢構(gòu)建時間。量化完之后一定要做精度驗(yàn)證不能只看轉(zhuǎn)換成功就完事。RKNN-Toolkit提供accuracy_analysis功能會輸出每一層量化后的精度對比一般關(guān)注mAP和關(guān)鍵層誤差。之前有一個掉點(diǎn)嚴(yán)重的案例排查一圈發(fā)現(xiàn)是模型里某個大通道層用MinMax校準(zhǔn)把范圍拉得太寬導(dǎo)致整體精度損失到3%。后來改成Percentile 99.99%校準(zhǔn)損失直接降到0.8%。這個調(diào)參過程就像打靶不是一次就能調(diào)到位的。還有一個很影響精度的小細(xì)節(jié)模型里如果有Batchnorm層一定要在導(dǎo)出ONNX時把它融合進(jìn)去。YOLOv8導(dǎo)出ONNX時默認(rèn)會做這一步。如果沒有融合量化時BN層前的激活值分布就很難看導(dǎo)致誤差累加后期怎么調(diào)校準(zhǔn)集都救不回來。4.3 板端部署與性能調(diào)試的完整流程模型轉(zhuǎn)好之后要寫板端推理程序。下面是Python推理部分的示例from rknnlite.api import RKNNLite rknn_lite RKNNLite() rknn_lite.load_rknn(yolov8n_int8.rknn) rknn_lite.init_runtime(core_maskRKNNLite.NPU_CORE_0) # 推理 outputs rknn_lite.inference(inputs[img])你可能注意到我在init_runtime里指定了NPU_CORE_0。RK3588有3個NPU核心理論上可以設(shè)置成NPU_CORE_AUTO讓NPU自動調(diào)度。但實(shí)測下來在某些模型上AUTO模式反而會引入額外的調(diào)度開銷在低負(fù)載場景不如固定單核穩(wěn)定。如果追求最高吞吐可以開雙核或三核但功耗也會上去。這個要配合實(shí)際場景測試不能只看理論。部署時還有幾個容易忽視的性能點(diǎn)如果輸入圖像是BGRRKNN默認(rèn)也期望BGR。顏色通道順序搞錯推理結(jié)果會完全廢掉。預(yù)處理不要用Python一層層循環(huán)。numpy的resize、reshape操作要寫成向量化形式用opencv替代Pillow。如果做視頻流處理要把前后處理放到單獨(dú)的線程不要讓預(yù)處理阻塞NPU推理形成流水線結(jié)構(gòu)這樣總吞吐才能上去。我做過一組對比測試同樣的YOLOv8n INT8模型在RK3588上單核NPU推理約15ms用三核跑約8ms但CPU前后處理如果沒優(yōu)化整體延遲反而被拖到35ms。所以瓶頸往往不在NPU而在數(shù)據(jù)搬運(yùn)和前后處理。解決思路是把preprocess和postprocess合理分配到CPU核上并利用多線程與NPU并行最終端到端延遲能穩(wěn)定在20ms左右。性能測量也要專業(yè)。不要在完整芯片上簡單打點(diǎn)第一次推理第一次推理往往會包含模型加載和內(nèi)存初始化不能代表真實(shí)性能。正確做法是預(yù)熱幾十次之后多測幾十次求平均。我通常會寫個基準(zhǔn)測試腳本測三個指標(biāo)最小延遲、平均延遲、P95延遲。P95性能對交互式應(yīng)用來說更有參考價值它代表大多數(shù)用戶能感知到的性能水平。4.4 精度評估量化后必須做的驗(yàn)證量化之后模型精度到底會不會掉不是猜出來的得認(rèn)真評估。有一個誤區(qū)有些人只比較量化前后在單張測試圖上的輸出覺得差不多就完事。這完全不夠。正確做法是準(zhǔn)備一個和場景匹配的測試集統(tǒng)計(jì)量化前后模型的預(yù)測結(jié)果差異。對于目標(biāo)檢測任務(wù)至少看mAP的絕對值變化和每類AP的變化。如果某個類別的AP從0.85掉到0.6即使整體mAP看起來還好這個類別仍然有問題需要重點(diǎn)分析。檢查過程我常用這幾步對掉點(diǎn)嚴(yán)重的類別找到量化前后預(yù)測結(jié)果不一致的樣本可視化看是漏檢還是誤檢將這些失敗樣本加入校準(zhǔn)集重新PTQ量化一次如果還存在問題考慮降低該類別相關(guān)層的量化敏感性或切換敏感層到FP16混合精度?；旌暇仁莻€好選擇。RKNN支持部分層用FP16這能大幅減少精度損失代價是推理速度稍有下降。具體做法是先用量化分析工具找出對精度最敏感的層只把這些層切成FP16其余保持INT8。實(shí)測下來通常只需要把最敏感的幾百層里的十到幾十層切成FP16就能把mAP損失從1.5%拉回到0.3%速度損失只有5%到8%非常劃算。5. 常見問題與排查技巧實(shí)錄這部分是我被問得最多的內(nèi)容我把這幾年高頻踩坑整理成一個速查表現(xiàn)象可能原因排查與解決轉(zhuǎn)換ONNX時報(bào)算子不支持模型用了自定義算子或opset版本過高先用Netron可視化模型定位不支持節(jié)點(diǎn)換等價算子替代或把該部分留在CPU運(yùn)行RKNN量化后精度暴跌校準(zhǔn)集分布不匹配、使用MinMax校準(zhǔn)、BN未融合重新選校準(zhǔn)集改用Percentile校準(zhǔn)確認(rèn)導(dǎo)出時已融合BN層部署時進(jìn)程被OOM殺掉中間激活值過大、內(nèi)存池未復(fù)用減小輸入分辨率、量化模型、開啟框架層的內(nèi)存池優(yōu)化NPU推理速度比預(yù)期慢很多算子未完全下沉NPU部分算子走了CPU查看工具鏈日志中算子分配結(jié)果把不支持的算子替換掉或手動分模型同一模型在設(shè)備和PC上結(jié)果不一致輸入預(yù)處理不同顏色通道、歸一化方式確保PC端和設(shè)備端的預(yù)處理嚴(yán)格一致用同一張圖做對比驗(yàn)證模型加載耗時很長模型較大且從Flash讀取可考慮把模型放在更快存儲或用系統(tǒng)緩存機(jī)制減少重復(fù)加載有一個看起來很小但很坑的問題設(shè)備端圖片縮放算法不一致。PC上用OpenCV的INTER_LINEAR縮放圖像但部署程序里用Pillow的默認(rèn)縮法結(jié)果時特征分布完全不同了。模型對輸入的數(shù)值范圍非常敏感一個小小的預(yù)處理差異就能讓精度雪崩。解決方法是寫一個輸入對比腳本將PC端預(yù)處理后的數(shù)組和設(shè)備端預(yù)處理后的跑一下推理在幾個關(guān)鍵層對比數(shù)值是否接近能快速定位預(yù)處理不一致的問題。還有一個經(jīng)驗(yàn)是一定要有日志和可觀測性。端側(cè)設(shè)備上出了問題特別是在現(xiàn)場沒有屏幕沒有鍵盤只能靠日志。我習(xí)慣在代碼關(guān)鍵節(jié)點(diǎn)打印耗時和內(nèi)存占用用環(huán)形緩沖記在內(nèi)存中崩潰后自動dump。不要小看這個有一次客戶現(xiàn)場模型頻繁崩潰通過dump拿到日志才定位到是JPEG解碼庫的內(nèi)存泄漏。另一個坑是老生常談的精度與速度的糾纏。有人把INT8當(dāng)萬能藥結(jié)果發(fā)現(xiàn)量化后延遲反而變高。這種情況通常出現(xiàn)在模型FLOPs很小或內(nèi)存帶寬已經(jīng)飽和時INT8的加速紅利被額外的反量化開銷吃掉了。所以做量化之前先跑一遍原始模型的性能基線如果FP32已經(jīng)很快且算力不是瓶頸INT8可能沒多大收益這時該做的是優(yōu)化前后處理流程或減少算子數(shù)量而不是盲目量化。關(guān)于散熱和功耗的排查我多說一句。長時間運(yùn)行NPU推理設(shè)備溫度一旦過高芯片會強(qiáng)制降頻性能大幅下降。我在一個戶外設(shè)備上遇到延遲從15ms突然漲到60ms排查了一圈發(fā)現(xiàn)是散熱不良導(dǎo)致NPU降頻。后來在設(shè)備里加了導(dǎo)熱硅脂問題立刻消失。端側(cè)部署不光是軟件問題硬件散熱、電源供電都會直接影響性能表現(xiàn)做現(xiàn)場部署一定別忘了這些非AI因素。6. 從工程角度談端側(cè)AI的落地節(jié)奏最后聊點(diǎn)工程管理上的體會。端側(cè)部署項(xiàng)目如果做成了純移植項(xiàng)目那真是最糟糕的狀態(tài)。很多團(tuán)隊(duì)拿到模型第一反應(yīng)就是把它轉(zhuǎn)過去跑起來結(jié)果轉(zhuǎn)換、調(diào)試、精度調(diào)優(yōu)來回折騰好幾周。我的建議是先建立性能基線和精度基線再開始動手。具體做法是先用原始FP32模型在目標(biāo)設(shè)備CPU上運(yùn)行記錄準(zhǔn)確率和延遲然后用量化模型跑一遍對比。這看起來多花了一天時間但能直接告訴你量化是否有效、設(shè)備算力是否達(dá)標(biāo)避免在錯誤方向上浪費(fèi)大量時間。先把基線定了再逐步優(yōu)化算子、調(diào)整內(nèi)存參數(shù)這樣每一步的收益都是可量化的。模型的選擇也要提前打磨不要訓(xùn)練完再壓縮。如果產(chǎn)品J明確要端側(cè)部署訓(xùn)練時就該考慮模型規(guī)模。我的經(jīng)驗(yàn)是目標(biāo)硬件確定后按設(shè)備算力和內(nèi)存上限倒推模型大小再按這個約束選擇模型架構(gòu)和輸入分辨率。這樣訓(xùn)練完基本可以直接部署方案還特別穩(wěn)。端側(cè)AI目前還在快速演進(jìn)新的NPU硬件、新的推理框架、新的壓縮算法層出不窮。但核心思路一直沒變在有限的資源里榨出最好的效果。掌握了量化的原理、算子的兼容性、前后處理的優(yōu)化思路換個硬件平臺也照樣能快速上手。這些底層的判斷能力比背一百個工具命令都要值錢。最后分享一個小小的技巧在做資源受限設(shè)備的模型選型時千萬不要只看參數(shù)量和FLOPs建議把模型實(shí)際跑一次測出真實(shí)延遲和內(nèi)存峰值再判斷。我遇到過很多模型理論計(jì)算量很小但實(shí)際跑起來內(nèi)存暴漲的案例原因就在于中間激活值太多。紙上談兵的評估遠(yuǎn)不如設(shè)備上的一次數(shù)值來得靠譜。