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