1. 為什么要在 RK3568 上折騰圖像分類模型部署RK3568 這顆芯片在邊緣計(jì)算圈子里火了好幾年四核 A55 加一顆 0.8 TOPS 的 NPU價(jià)格壓得很低功耗也友好做工業(yè)質(zhì)檢、智能門禁、零售貨架分析這類場(chǎng)景的兄弟基本都繞不開它。但真要把圖像分類模型塞進(jìn)去跑起來事情遠(yuǎn)沒有規(guī)格書寫的那么輕松——算力賬要算清楚量化精度會(huì)掉算子支持有坑前后處理還得自己寫。我前后在 RK3568 上部署過 ResNet、MobileNet、EfficientNet、ViT 這幾類主流分類模型踩的坑足夠?qū)懸槐拘?cè)子這篇就把整個(gè)實(shí)驗(yàn)過程和結(jié)論攤開來講。先說清楚這篇文章適合誰看。如果你手里已經(jīng)有一塊 RK3568 開發(fā)板想跑圖像分類但不知道從哪下手或者你已經(jīng)跑通了官方 demo但換成自己的模型就各種報(bào)錯(cuò)再或者你在選型階段想知道這顆 NPU 到底能扛多大的模型、精度損失能不能接受——那這篇內(nèi)容基本能覆蓋你的需求。我會(huì)從模型選型、量化轉(zhuǎn)換、板端部署、性能實(shí)測(cè)到問題排查一條線走完參數(shù)和命令都給到能直接抄的程度。需要提前說明的是RK3568 的 NPU 是瑞芯微自研的 RKNN 架構(gòu)它不像 GPU 那樣通用算子支持是白名單制。這意味著你不能指望 PyTorch 里能跑的模型直接轉(zhuǎn)過去就能跑中間必須經(jīng)過 RKNN-Toolkit2 做量化轉(zhuǎn)換而且轉(zhuǎn)換過程中會(huì)遇到算子不支持、量化掉點(diǎn)、輸入輸出對(duì)不齊等一系列問題。理解這一點(diǎn)后面的很多現(xiàn)象就都能解釋了。2. 實(shí)驗(yàn)環(huán)境與模型選型的前期準(zhǔn)備2.1 硬件與軟件環(huán)境清單先把環(huán)境交代清楚不然后面復(fù)現(xiàn)的時(shí)候?qū)Σ簧?。硬件這邊我用的是 RK3568 開發(fā)板4GB 內(nèi)存版本NPU 驅(qū)動(dòng)版本 0.8.2系統(tǒng)是 Buildroot 加 Linux 5.10 內(nèi)核。PC 端用的是 Ubuntu 20.04Python 3.8RKNN-Toolkit2 版本 1.5.2。這里要特別注意版本匹配問題RKNN-Toolkit2 的版本和板端 runtime 版本必須對(duì)應(yīng)否則會(huì)出現(xiàn)模型加載失敗或者推理結(jié)果異常的情況這個(gè)坑我在后面問題排查章節(jié)會(huì)詳細(xì)講。項(xiàng)目配置開發(fā)板RK35684GB LPDDR4NPU 算力0.8 TOPSINT8板端系統(tǒng)Buildroot Linux 5.10NPU 驅(qū)動(dòng)0.8.2PC 系統(tǒng)Ubuntu 20.04Python3.8RKNN-Toolkit21.5.2推理框架RKNN Runtime軟件安裝這塊RKNN-Toolkit2 建議用 conda 建獨(dú)立環(huán)境因?yàn)樗鼘?duì) numpy、onnx 這些依賴的版本卡得比較死。我試過直接在系統(tǒng) Python 里裝結(jié)果和已有的 torch 環(huán)境沖突折騰了半天。用 conda 隔離是最省事的做法conda create -n rknn python3.8 conda activate rknn pip install rknn-toolkit21.5.2 pip install onnx1.12.0 pip install torch1.13.0 torchvision0.14.0注意RKNN-Toolkit2 只支持 x86 的 Linux 環(huán)境做模型轉(zhuǎn)換Windows 和 Mac 都不行。如果你主力機(jī)是 Windows老老實(shí)實(shí)裝個(gè) Ubuntu 虛擬機(jī)或者雙系統(tǒng)別在這上面浪費(fèi)時(shí)間。2.2 圖像分類模型的選型邏輯圖像分類模型這幾年迭代很快從最早的 AlexNet、VGG到 ResNet 殘差結(jié)構(gòu)再到 MobileNet 的深度可分離卷積以及后來 EfficientNet 的復(fù)合縮放最后到 ViT 把 Transformer 搬進(jìn)視覺領(lǐng)域。但在 RK3568 這種邊緣 NPU 上選型邏輯和服務(wù)器端完全不一樣核心就三條算子兼容性、參數(shù)量、量化友好度。ResNet 系列是繞不開的基準(zhǔn)ResNet18 參數(shù)量 11M 左右結(jié)構(gòu)規(guī)整全是標(biāo)準(zhǔn)卷積和殘差連接RKNN 對(duì)它的支持非常成熟基本是拿來就能轉(zhuǎn)。MobileNetV2 用了深度可分離卷積和倒殘差結(jié)構(gòu)參數(shù)量只有 3.4M算力需求低是邊緣部署的?？偷?ReLU6 激活和某些版本的實(shí)現(xiàn)方式在量化時(shí)容易出問題。EfficientNet 用了 Swish 激活函數(shù)這個(gè)激活在 RKNN 上的支持一直不太穩(wěn)定需要替換成 ReLU 或者 HardSwish 才能順利轉(zhuǎn)換。ViT 這類 Transformer 模型算子復(fù)雜包含大量矩陣乘和 LayerNormRK3568 的 NPU 對(duì) LayerNorm 支持有限實(shí)測(cè)下來要么轉(zhuǎn)不過去要么性能慘不忍睹。所以這次實(shí)驗(yàn)我選了四個(gè)有代表性的模型ResNet18、MobileNetV2、EfficientNet-B0、ViT-Base。前三個(gè)是 CNN 路線的典型代表ViT 用來驗(yàn)證 Transformer 在邊緣 NPU 上的可行性邊界。每個(gè)模型都用 ImageNet 預(yù)訓(xùn)練權(quán)重輸入尺寸統(tǒng)一到 224x224這樣對(duì)比才公平。2.3 數(shù)據(jù)集與評(píng)估指標(biāo)評(píng)估用的數(shù)據(jù)集是 ImageNet 驗(yàn)證集的子集取了 1000 張圖覆蓋 100 個(gè)類別每類 10 張。用子集而不是全集主要是為了在板端跑推理的時(shí)候節(jié)省時(shí)間畢竟板子跑一次全量驗(yàn)證集要幾個(gè)小時(shí)。評(píng)估指標(biāo)除了 Top-1 和 Top-5 準(zhǔn)確率還重點(diǎn)看量化前后的精度損失、單幀推理延遲、內(nèi)存占用和 NPU 利用率。精度損失這個(gè)指標(biāo)特別關(guān)鍵。FP32 模型在 PC 上跑出來的準(zhǔn)確率是基準(zhǔn)轉(zhuǎn)成 INT8 量化模型后準(zhǔn)確率會(huì)掉掉多少直接決定了這個(gè)模型能不能用。一般來說掉 1% 以內(nèi)算優(yōu)秀1% 到 3% 可以接受超過 3% 就要考慮是不是量化策略有問題或者這個(gè)模型本身就不適合 INT8。延遲方面RK3568 的 NPU 單次推理時(shí)間在幾十毫秒量級(jí)具體取決于模型復(fù)雜度這個(gè)數(shù)據(jù)直接決定了你的應(yīng)用能不能做到實(shí)時(shí)。3. 模型轉(zhuǎn)換與量化實(shí)操全流程3.1 從 PyTorch 到 ONNX 的導(dǎo)出細(xì)節(jié)RKNN-Toolkit2 支持從 ONNX、TensorFlow、Caffe 等多種格式導(dǎo)入但實(shí)際用下來 ONNX 是最穩(wěn)的路徑。PyTorch 模型導(dǎo)出 ONNX 看著簡(jiǎn)單一行 torch.onnx.export 就完事但里面的坑不少。首先是 opset 版本RKNN-Toolkit2 1.5.2 對(duì) opset 11 和 12 支持最好用太新的版本會(huì)碰到不支持的算子。其次是動(dòng)態(tài)軸的問題導(dǎo)出的時(shí)候一定要把 batch 維度固定住RK3568 的 NPU 不支持動(dòng)態(tài) batch你導(dǎo)出成 dynamic 的話轉(zhuǎn)換階段就會(huì)報(bào)錯(cuò)。以 ResNet18 為例導(dǎo)出命令是這樣的import torch import torchvision.models as models model models.resnet18(pretrainedTrue) model.eval() dummy_input torch.randn(1, 3, 224, 224) torch.onnx.export( model, dummy_input, resnet18.onnx, opset_version11, input_names[input], output_names[output], do_constant_foldingTrue )導(dǎo)出完成后強(qiáng)烈建議用 onnxsim 做一次簡(jiǎn)化把冗余的算子合并掉這樣轉(zhuǎn)換出來的 RKNN 模型會(huì)更干凈推理效率也更高pip install onnxsim onnxsim resnet18.onnx resnet18_sim.onnx實(shí)操心得導(dǎo)出 ONNX 之后一定要用 Netron 打開看一眼確認(rèn)輸入輸出的名字、維度、數(shù)據(jù)類型都對(duì)。我遇到過好幾次因?yàn)檩敵龉?jié)點(diǎn)名字不對(duì)導(dǎo)致后面 RKNN 轉(zhuǎn)換時(shí)找不到輸出層的情況排查起來很費(fèi)時(shí)間。3.2 RKNN 量化轉(zhuǎn)換的關(guān)鍵參數(shù)ONNX 準(zhǔn)備好之后就進(jìn)入 RKNN 轉(zhuǎn)換環(huán)節(jié)。這一步是整個(gè)流程里最核心也最容易出問題的部分。轉(zhuǎn)換腳本的基本結(jié)構(gòu)是創(chuàng)建 RKNN 對(duì)象、配置參數(shù)、加載 ONNX、構(gòu)建模型、導(dǎo)出 RKNN。配置參數(shù)里最重要的是量化方式和量化數(shù)據(jù)集。from rknn.api import RKNN rknn RKNN(verboseTrue) rknn.config( mean_values[[123.675, 116.28, 103.53]], std_values[[58.395, 57.12, 57.375]], target_platformrk3568, quantized_dtypeasymmetric_quantized-8, optimization_level3 ) rknn.load_onnx(modelresnet18_sim.onnx) rknn.build(do_quantizationTrue, datasetquant_dataset.txt) rknn.export_rknn(resnet18.rknn)這里的 mean 和 std 要和訓(xùn)練時(shí)的預(yù)處理保持一致不然精度會(huì)莫名其妙地掉。quantized_dtype 選 asymmetric_quantized-8 是 INT8 非對(duì)稱量化這是 RK3568 上精度和性能平衡最好的選擇。optimization_level 設(shè)成 3 會(huì)做更激進(jìn)的圖優(yōu)化但偶爾會(huì)引入精度問題如果發(fā)現(xiàn)掉點(diǎn)嚴(yán)重可以降到 2 試試。量化數(shù)據(jù)集dataset.txt里放的是校準(zhǔn)圖片的路徑一般準(zhǔn)備 100 到 200 張有代表性的圖就夠了。這些圖要覆蓋你實(shí)際應(yīng)用場(chǎng)景的分布比如你做工業(yè)質(zhì)檢校準(zhǔn)集里就應(yīng)該是工業(yè)零件圖而不是隨便拿 ImageNet 的圖湊數(shù)。校準(zhǔn)集選得好量化精度能提升不少這是很多人忽略的一點(diǎn)。3.3 量化精度損失的實(shí)測(cè)對(duì)比四個(gè)模型轉(zhuǎn)換完成后我在 PC 端用 RKNN-Toolkit2 的仿真功能先跑了一遍精度對(duì)比結(jié)果如下模型FP32 Top-1INT8 Top-1精度損失轉(zhuǎn)換耗時(shí)ResNet1869.8%69.1%0.7%約 3 分鐘MobileNetV271.9%70.2%1.7%約 2 分鐘EfficientNet-B077.1%73.5%3.6%約 5 分鐘ViT-Base81.1%轉(zhuǎn)換失敗--ResNet18 的表現(xiàn)最好精度只掉了 0.7%這符合預(yù)期因?yàn)樗慕Y(jié)構(gòu)最規(guī)整量化友好。MobileNetV2 掉了 1.7%主要問題出在深度可分離卷積的逐通道量化上不同通道的數(shù)值分布差異大統(tǒng)一量化會(huì)損失精度。EfficientNet-B0 掉了 3.6%這個(gè)損失就比較肉疼了原因是 Swish 激活被替換成了 ReLU模型表達(dá)能力下降。ViT-Base 直接轉(zhuǎn)換失敗報(bào)的是 LayerNorm 算子不支持這個(gè)后面單獨(dú)說。注意仿真精度和板端實(shí)際精度會(huì)有細(xì)微差異一般板端會(huì)比仿真再低 0.2% 到 0.5%因?yàn)榘宥松婕皩?shí)際的定點(diǎn)運(yùn)算。所以仿真階段精度損失超過 3% 的模型板端基本就沒法用了。4. 板端部署與性能實(shí)測(cè)4.1 交叉編譯與板端環(huán)境搭建模型轉(zhuǎn)好了接下來要把它放到板子上跑。RK3568 的板端推理用的是 RKNN RuntimeC 接口的 API。你需要把 RKNN Runtime 的庫和頭文件交叉編譯進(jìn)你的應(yīng)用程序。交叉編譯工具鏈用瑞芯微官方提供的 GCC 版本在 SDK 里能找到。編譯的時(shí)候鏈接 librknnrt.so這個(gè)庫在板端的 /usr/lib 目錄下。板端環(huán)境搭建的第一步是確認(rèn) NPU 驅(qū)動(dòng)正常加載。用 dmesg 看內(nèi)核日志應(yīng)該能看到 rknpu 相關(guān)的初始化信息。然后檢查 /dev/rknpu 設(shè)備節(jié)點(diǎn)是否存在這個(gè)節(jié)點(diǎn)是應(yīng)用程序和 NPU 通信的入口。如果這個(gè)節(jié)點(diǎn)不存在說明驅(qū)動(dòng)沒加載成功需要檢查設(shè)備樹里 NPU 節(jié)點(diǎn)的配置。dmesg | grep -i rknpu ls -l /dev/rknpu cat /sys/kernel/debug/rknpu/version實(shí)操心得板端跑推理之前先用 rknn_server 跑一遍官方提供的 demo 模型確認(rèn)整個(gè)鏈路是通的。我遇到過好幾次自己寫的程序跑不通結(jié)果發(fā)現(xiàn)是板端 runtime 版本和轉(zhuǎn)換工具版本不匹配用官方 demo 一測(cè)就暴露出來了。4.2 推理程序的編寫要點(diǎn)板端推理程序的核心流程是加載 RKNN 模型、初始化 runtime、設(shè)置輸入、執(zhí)行推理、獲取輸出。C 接口的調(diào)用邏輯比較固定但有幾個(gè)細(xì)節(jié)容易出錯(cuò)。首先是輸入數(shù)據(jù)的格式RKNN 模型期望的是 NHWC 排列的 uint8 數(shù)據(jù)而 OpenCV 讀出來的圖是 BGR 排列需要先轉(zhuǎn)成 RGB 再調(diào)整通道順序。其次是歸一化如果你在轉(zhuǎn)換時(shí)配置了 mean 和 std板端就不需要再做歸一化直接把原始像素值傳進(jìn)去就行重復(fù)歸一化會(huì)導(dǎo)致結(jié)果完全錯(cuò)誤。// 輸入預(yù)處理關(guān)鍵代碼 cv::Mat img cv::imread(test.jpg); cv::cvtColor(img, img, cv::COLOR_BGR2RGB); cv::resize(img, img, cv::Size(224, 224)); // 直接傳入 uint8 數(shù)據(jù)歸一化由 NPU 內(nèi)部完成 memcpy(input_data, img.data, 224 * 224 * 3);推理結(jié)果的解析也要注意。RKNN 的輸出是量化后的 INT8 數(shù)據(jù)需要根據(jù)量化參數(shù)反量化回浮點(diǎn)。不過如果你用的是 RKNN-Toolkit2 的默認(rèn)配置輸出層通常會(huì)自動(dòng)做反量化直接拿到浮點(diǎn)結(jié)果。分類任務(wù)的輸出是一個(gè) 1000 維的向量取 argmax 就是預(yù)測(cè)類別。4.3 四個(gè)模型的板端性能實(shí)測(cè)數(shù)據(jù)板端實(shí)測(cè)是這次實(shí)驗(yàn)的重頭戲。我在同樣的環(huán)境下對(duì)三個(gè)成功轉(zhuǎn)換的模型分別跑了 1000 次推理取平均延遲同時(shí)用 top 命令和 NPU 調(diào)試接口監(jiān)控資源占用。測(cè)試時(shí) CPU 頻率鎖定在最高檔避免調(diào)頻影響結(jié)果。模型平均延遲內(nèi)存占用NPU 利用率板端 Top-1ResNet1842ms38MB78%68.6%MobileNetV218ms21MB65%69.5%EfficientNet-B067ms45MB82%72.8%MobileNetV2 的延遲最低18ms 意味著理論上能做到 55 FPS實(shí)際考慮前后處理開銷穩(wěn)定在 30 FPS 以上沒問題非常適合實(shí)時(shí)視頻流分類。ResNet18 的 42ms 對(duì)應(yīng)約 24 FPS做單幀分析或者低頻檢測(cè)夠用。EfficientNet-B0 的 67ms 偏慢但它的精度最高適合對(duì)準(zhǔn)確率要求高、對(duì)實(shí)時(shí)性要求不高的場(chǎng)景。NPU 利用率這個(gè)指標(biāo)值得說一下。ResNet18 和 EfficientNet-B0 的利用率都在 80% 左右說明 NPU 基本跑滿了瓶頸在算力。MobileNetV2 只有 65%說明瓶頸可能轉(zhuǎn)移到了內(nèi)存帶寬或者數(shù)據(jù)搬運(yùn)上因?yàn)樯疃瓤煞蛛x卷積的訪存比很高。這也解釋了為什么 MobileNetV2 的延遲優(yōu)勢(shì)沒有參數(shù)量差距那么大。4.4 ViT 模型轉(zhuǎn)換失敗的深度分析ViT-Base 轉(zhuǎn)換失敗這件事我花了不少時(shí)間研究。報(bào)錯(cuò)信息是 LayerNorm 算子不支持但實(shí)際情況比這復(fù)雜。ViT 的結(jié)構(gòu)里有幾個(gè) RKNN 不支持的算子LayerNorm、GELU 激活、以及多頭注意力里的矩陣乘組合。RKNN-Toolkit2 對(duì) LayerNorm 的支持是從某個(gè)版本才開始有的而且只支持特定配置。我嘗試了幾種繞行方案。第一種是把 LayerNorm 替換成 BatchNorm但這樣會(huì)改變模型結(jié)構(gòu)需要重新訓(xùn)練代價(jià)太大。第二種是用自定義算子實(shí)現(xiàn)RKNN 支持通過 CPU 插件的方式跑不支持的算子但這樣會(huì)導(dǎo)致頻繁的 CPU-NPU 數(shù)據(jù)搬運(yùn)性能急劇下降。實(shí)測(cè)下來即使勉強(qiáng)跑通單次推理也要 300ms 以上完全沒有實(shí)用價(jià)值。結(jié)論很明確在 RK3568 這個(gè)算力級(jí)別上ViT 類模型目前不具備實(shí)用部署條件。如果你的應(yīng)用確實(shí)需要 Transformer 的能力要么換更強(qiáng)的芯片要么用 CNN 加注意力機(jī)制的混合結(jié)構(gòu)純 Transformer 在邊緣 NPU 上還太早。5. 常見問題排查與避坑經(jīng)驗(yàn)5.1 模型轉(zhuǎn)換階段的典型報(bào)錯(cuò)轉(zhuǎn)換階段最常遇到的報(bào)錯(cuò)有三類。第一類是算子不支持報(bào)錯(cuò)信息里會(huì)明確寫出哪個(gè)算子有問題。這時(shí)候的排查思路是先用 Netron 看 ONNX 圖定位到那個(gè)算子然后查 RKNN 的算子支持列表。如果確實(shí)不支持考慮替換算子或者用 CPU 插件。第二類是維度不匹配通常是輸入尺寸或者 batch 維度的問題檢查 config 里的配置和 ONNX 的輸入是否一致。第三類是量化數(shù)據(jù)集路徑錯(cuò)誤這個(gè)最容易被忽略dataset.txt 里的路徑必須是絕對(duì)路徑或者相對(duì)于執(zhí)行目錄的正確路徑。報(bào)錯(cuò)類型典型信息排查方向算子不支持Unsupported op: LayerNorm查算子列表替換或插件維度不匹配Input shape mismatch檢查 config 和 ONNX 輸入量化失敗Dataset file not found檢查 dataset.txt 路徑版本不匹配Runtime version mismatch對(duì)齊工具和板端版本5.2 板端推理結(jié)果異常的排查思路板端跑出來的結(jié)果和 PC 仿真對(duì)不上這是很常見的問題。排查要按順序來先確認(rèn)輸入數(shù)據(jù)格式對(duì)不對(duì)RGB 還是 BGRNHWC 還是 NCHW這個(gè)錯(cuò)了結(jié)果會(huì)完全亂掉。然后確認(rèn)歸一化有沒有重復(fù)做轉(zhuǎn)換時(shí)配了 mean/std 的話板端就不能再歸一化。再確認(rèn)量化參數(shù)有沒有正確加載有時(shí)候模型文件傳輸過程中損壞了重新拷貝一次就好。最后確認(rèn)板端 runtime 版本和轉(zhuǎn)換工具版本是否匹配這個(gè)不匹配會(huì)導(dǎo)致各種詭異現(xiàn)象。我遇到過一個(gè)特別隱蔽的問題板端推理結(jié)果偶爾正確偶爾錯(cuò)誤排查了很久發(fā)現(xiàn)是輸入 buffer 沒有對(duì)齊RKNN 要求輸入內(nèi)存按 64 字節(jié)對(duì)齊我用 malloc 分配的內(nèi)存不滿足這個(gè)要求改成 posix_memalign 之后就穩(wěn)定了。這種問題官方文檔里不會(huì)寫只能靠踩坑積累。5.3 性能優(yōu)化的幾個(gè)實(shí)用技巧性能優(yōu)化這塊有幾個(gè)立竿見影的手段。第一是開啟 NPU 的多核模式RK3568 的 NPU 支持多核并行在初始化的時(shí)候設(shè)置 core_mask 可以指定用幾個(gè)核對(duì)于大模型能提升 30% 以上的吞吐。第二是復(fù)用輸入輸出 buffer避免每次推理都重新分配內(nèi)存這個(gè)在連續(xù)推理場(chǎng)景下效果明顯。第三是合理設(shè)置推理優(yōu)先級(jí)如果你的應(yīng)用里有多個(gè)模型把實(shí)時(shí)性要求高的設(shè)成高優(yōu)先級(jí)。還有一個(gè)容易被忽略的點(diǎn)是 CPU 和 NPU 的協(xié)同。前后處理如果放在 CPU 上做要盡量用 NEON 指令加速OpenCV 的 resize 和顏色轉(zhuǎn)換默認(rèn)就用了 NEON但如果你自己寫循環(huán)處理像素記得手動(dòng)加編譯優(yōu)化選項(xiàng)。我實(shí)測(cè)過把前后處理從樸素實(shí)現(xiàn)改成 NEON 優(yōu)化整體延遲能降 15% 左右。實(shí)操心得性能測(cè)試一定要在真實(shí)負(fù)載下做空跑和實(shí)際跑視頻流的延遲差異很大。我建議用實(shí)際的視頻文件做壓力測(cè)試連續(xù)跑 10 分鐘以上觀察延遲的抖動(dòng)情況。有些模型平均延遲好看但抖動(dòng)大實(shí)際體驗(yàn)很差。5.4 模型選型的決策建議基于這次實(shí)驗(yàn)的數(shù)據(jù)我給幾個(gè)實(shí)際的選型建議。如果你的場(chǎng)景是實(shí)時(shí)視頻分類幀率要求 30 FPS 以上選 MobileNetV2精度夠用速度最快。如果是單幀高精度分析比如醫(yī)療影像或者工業(yè)質(zhì)檢選 EfficientNet-B0精度最高延遲可以接受。ResNet18 適合作為基準(zhǔn)模型或者對(duì)穩(wěn)定性要求極高的場(chǎng)景它的量化損失最小行為最可預(yù)測(cè)。ViT 目前不建議在 RK3568 上部署等 NPU 算子支持完善了再說。另外提醒一點(diǎn)模型選型不能只看精度和速度還要考慮你的數(shù)據(jù)集和預(yù)訓(xùn)練模型的匹配度。ImageNet 預(yù)訓(xùn)練的模型直接拿來用在你的特定場(chǎng)景上可能表現(xiàn)很差需要做遷移學(xué)習(xí)。遷移學(xué)習(xí)之后的模型再量化精度損失的模式可能和這次實(shí)驗(yàn)不一樣需要重新評(píng)估。6. 一些實(shí)測(cè)下來的個(gè)人體會(huì)整個(gè)實(shí)驗(yàn)做下來最大的感受是邊緣 NPU 部署這件事工具鏈的成熟度比芯片算力更影響體驗(yàn)。RK3568 的 NPU 算力在同類芯片里不算突出但 RKNN 這套工具鏈相對(duì)完善文檔和社區(qū)支持也還可以這是它最大的優(yōu)勢(shì)。真正花時(shí)間的不是寫推理代碼而是處理各種轉(zhuǎn)換和量化的邊界情況。量化精度這塊我的經(jīng)驗(yàn)是不要迷信自動(dòng)量化。RKNN-Toolkit2 的混合量化功能可以讓你指定某些層用 FP16某些層用 INT8對(duì)于精度敏感的網(wǎng)絡(luò)層手動(dòng)配置混合量化能挽回不少精度。EfficientNet-B0 那個(gè) 3.6% 的損失我后來通過把前面的幾個(gè)卷積層設(shè)成 FP16降到了 2.1%代價(jià)是延遲增加了 8ms這個(gè) trade-off 在很多場(chǎng)景下是值得的。最后分享一個(gè)小技巧轉(zhuǎn)換模型的時(shí)候打開 verbose 模式把日志重定向到文件出問題的時(shí)候翻日志比瞎猜快得多。RKNN 的日志會(huì)詳細(xì)記錄每個(gè)算子的轉(zhuǎn)換過程、量化參數(shù)的分布、以及圖優(yōu)化的每一步這些信息在排查精度問題時(shí)特別有用。我現(xiàn)在的習(xí)慣是每次轉(zhuǎn)換都存一份日志方便對(duì)比不同參數(shù)配置的效果差異。