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