戰(zhàn)：RKNN量化與性能調(diào)優(yōu))
1. 為什么我盯上了RV1103這塊芯片做嵌入式AI落地這幾年我手里過過不少芯片從最早在樹莓派上跑MobileNet圖個(gè)樂到后來在RK3399、RK3568上做正經(jīng)的視覺項(xiàng)目再到最近折騰的RV1103整個(gè)路線基本就是一條“算力下放”的路。RV1103在瑞芯微的產(chǎn)品序列里屬于輕量級視覺處理芯片主打的就是極致成本、低功耗和夠用的AI算力常被用在IPC攝像頭、門鎖、智能家居這類設(shè)備上。它的NPU算力大約0.5TOPS聽著不大但人家是專門為輕量級視覺任務(wù)設(shè)計(jì)的跑分類模型、簡單檢測模型完全夠用。我拿到RV1103的原廠SDK時(shí)第一反應(yīng)是“這么小的芯片能跑什么”。結(jié)果把ResNet18量化完之后放上去分類推理一次只要十幾毫秒功耗還低得感人。那個(gè)瞬間我意識到這類芯片的定位根本不是和手機(jī)SoC比算力而是把“能跑模型”的門檻壓到極致讓一個(gè)幾十塊錢的模組干過去需要幾百塊錢硬件才能干的活。這篇文章我就把這幾個(gè)月在RV1103上部署主流圖像分類模型的完整過程、踩過的坑、調(diào)優(yōu)的思路和最終的數(shù)據(jù)一次性說清楚希望能幫到正在評估瑞芯微輕量級方案、或者已經(jīng)在RKNN工具鏈里掙扎的朋友。文章會覆蓋Model Zoo里幾類典型模型的部署對比包括經(jīng)典ResNet系列、輕量級MobileNet系列、以及近年來的EfficientNet和RegNet全程基于瑞芯微官方的RKNN-Toolkit2工具鏈從模型轉(zhuǎn)換、量化、板端推理到性能分析一條龍講完。適合剛接觸瑞芯微NPU的開發(fā)者也適合想了解輕量級芯片AI落地邊界在哪的嵌入式工程師。2. RV1103硬件底子與部署前的認(rèn)知準(zhǔn)備2.1 RV1103到底是一顆什么樣的芯片RV1103的CPU部分是單核Cortex-A7主頻最高1.2GHz這在今天聽起來確實(shí)有點(diǎn)“上古”。但它真正的價(jià)值不在CPU而在那顆0.5TOPS的NPU以及高度集成的ISP和視頻編解碼單元。這種“CPU弱、NPU專精”的架構(gòu)在端側(cè)AI里非常常見比如瑞芯微的RV1106、RK3562、甚至算力更大的RK3588走的都是類似路線。對部署圖像分類模型來說我們真正需要關(guān)心的硬件資源有三塊NPU算力0.5TOPS INT8。注意這個(gè)算力是INT8下的理論峰值FP16或者FP32基本走的是CPU或NPU降精度流程實(shí)際意義不大。CPU性能單核A7跑Linux系統(tǒng)本身就要占掉一部分真正能用來做前后處理的CPU預(yù)算很有限。內(nèi)存帶寬與容量RV1103支持DDR3/DDR4/LPDDR2等我們在demo板上配的是256MB DDR3。內(nèi)存帶寬雖然不大但喂給0.5TOPS的NPU還是夠用的。有個(gè)很關(guān)鍵的點(diǎn)這類輕量級芯片在設(shè)計(jì)之初就是給“固定功能設(shè)備”用的不是給你跑通用Linux服務(wù)器的。所以你在上面折騰模型部署必須帶著“我是要固化這個(gè)算法到產(chǎn)品里”的思維而不是像在開發(fā)板上跑Python那樣隨意。2.2 RKNN工具鏈全家桶概覽瑞芯微的NPU部署工具鏈經(jīng)歷了幾個(gè)版本迭代現(xiàn)在主流的是RKNN-Toolkit2它負(fù)責(zé)在PC端完成模型轉(zhuǎn)換、量化、仿真推理然后生成RKNN格式的模型文件。板端則通過RKNN Runtime庫加載這個(gè).rknn文件并執(zhí)行推理。整個(gè)工具鏈大概分成這幾塊RKNN-Toolkit2Python工具包運(yùn)行在x86 Linux主機(jī)上作用是模型導(dǎo)入、量化、轉(zhuǎn)換、推理驗(yàn)證。RKNN Runtime運(yùn)行在開發(fā)板上的C/C庫負(fù)責(zé)解析RKNN模型并調(diào)用NPU驅(qū)動(dòng)執(zhí)行推理。RKNPU驅(qū)動(dòng)與內(nèi)核模塊rknpu.ko這類內(nèi)核驅(qū)動(dòng)負(fù)責(zé)NPU的電源管理、任務(wù)調(diào)度和內(nèi)存管理。RKNN Model Zoo瑞芯微官方維護(hù)的模型倉庫提供了常見模型對應(yīng)的轉(zhuǎn)換腳本和板端demo代碼。初次接觸的人最容易被搞混的是“仿真推理”和“板端推理”的區(qū)別。RKNN-Toolkit2在PC上跑的是模擬器它模擬NPU的行為但速度、精度和真實(shí)板端有一定差異。所有性能數(shù)據(jù)必須以板端實(shí)測為準(zhǔn)PC仿真數(shù)據(jù)只能用來做功能驗(yàn)證。另外工具鏈版本和SDK版本強(qiáng)相關(guān)RV1103對應(yīng)的SDK一般是Luckfox Pico這類第三方板卡廠商維護(hù)的或者瑞芯微原廠SDK。我強(qiáng)烈建議不要混用不同版本的RKNN-Toolkit2和板端Runtime否則很容易遇到“模型轉(zhuǎn)換失敗”或“NPU跑不起來”的兼容問題。2.3 量化輕量級芯片部署的最大分水嶺RV1103的NPU只支持INT8量化推理這意味著所有浮點(diǎn)模型都得先做量化。量化就是把FP32的權(quán)重和激活值映射到INT8范圍這一步做得好不好直接決定模型精度掉多少、速度能不能跑起來。RKNN-Toolkit2支持的量化模式大致有訓(xùn)練后量化Post-Training Quantization, PTQ最常見只需準(zhǔn)備少量校準(zhǔn)圖片工具自動(dòng)統(tǒng)計(jì)激活值范圍完成量化。量化感知訓(xùn)練Quantization-Aware Training, QAT在訓(xùn)練階段模擬量化誤差精度更高但是需要重訓(xùn)模型對大多數(shù)項(xiàng)目來說成本偏高?；旌暇攘炕瘜γ舾袑颖Ａ舾呔裙ぞ哝溣兄С值玆V1103性能有限一般不建議過度使用。我在實(shí)驗(yàn)中發(fā)現(xiàn)分類模型對PTQ的容忍度普遍較高ImageNet預(yù)訓(xùn)練模型量化后top-1精度損失通?？刂圃?%以內(nèi)前提是校準(zhǔn)數(shù)據(jù)集選得對了。這一點(diǎn)后面專門開一節(jié)講。3. 實(shí)驗(yàn)環(huán)境搭建PC端工具鏈與板端系統(tǒng)準(zhǔn)備3.1 PC端RKNN-Toolkit2安裝RKNN-Toolkit2對主機(jī)環(huán)境有明確要求最好用Ubuntu 18.04或20.04的x86_64系統(tǒng)Python版本3.6到3.9之間。我這邊用的是Ubuntu 20.04 Python 3.8。安裝步驟很簡單官方提供了pip安裝包但有幾個(gè)前置依賴需要先裝好sudo apt-get install -y python3-dev python3-pip sudo apt-get install -y libpython3.8-dev sudo apt-get install -y python3-opencv sudo apt-get install -y python3-numpy然后安裝RKNN-Toolkit2本體pip install rknn-toolkit2-1.6.0-cp38-cp38-linux_x86_64.whl裝完之后驗(yàn)證一下python -c from rknn.api import RKNN; print(OK)如果這行命令沒有報(bào)錯(cuò)說明工具包環(huán)境沒問題。這里有個(gè)容易踩的坑RKNN-Toolkit2依賴的numpy、opencv版本如果太新反而會出兼容問題。比如numpy 2.0在某些舊版工具下會直接報(bào)“module numpy has no attribute bool”這種錯(cuò)。建議嚴(yán)格pip install numpy1.24.3這類穩(wěn)妥版本。3.2 板端系統(tǒng)與Runtime準(zhǔn)備RV1103的開發(fā)板我用的是Luckfox Pico系列這個(gè)板子有256MB內(nèi)存的版本麻雀雖小五臟俱全SDK自帶buildroot和Ubuntu鏡像。為了貼近產(chǎn)品化場景我刷的是buildroot版本裁剪程度高系統(tǒng)占用低。板端需要把RKNN Runtime庫拷貝到/lib目錄并確保內(nèi)核里有rknpu.ko。驗(yàn)證方法很簡單ls /lib | grep rknn ls /usr/lib | grep rknn dmesg | grep rknpu如果rknpu驅(qū)動(dòng)加載成功dmesg中會看到類似“rknn”的初始化日志。板端demo通常直接用交叉編譯好的可執(zhí)行文件我習(xí)慣用SDK里的toolchain編一個(gè)靜態(tài)鏈接的demo這樣拷過去就能跑省去動(dòng)態(tài)庫依賴的煩惱。3.3 CPU頻率與NPU頻率的固定性能測試最忌諱的就是頻率浮動(dòng)。RV1103的CPU和NPU都有動(dòng)態(tài)調(diào)頻機(jī)制默認(rèn)策略下頻率會跟著負(fù)載變化導(dǎo)致同一模型每次推理耗時(shí)都不一樣。我強(qiáng)烈建議在性能測試前手動(dòng)固定頻率# 查看可用頻率 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies # 固定最高頻率 echo userspace /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo 1200000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeedNPU頻率一般由驅(qū)動(dòng)管理可以在SDK的dts里配置或者直接在sysfs節(jié)點(diǎn)查看cat /sys/kernel/debug/rknpu/frequency固定頻率后每次推理的時(shí)間波動(dòng)能控制在很小范圍內(nèi)測出來的數(shù)據(jù)才有橫向?qū)Ρ葍r(jià)值。4. 實(shí)戰(zhàn)主流圖像分類模型在RV1103上的部署全流程4.1 模型選型與分析圖像分類模型這兩年卷出了花但真正適合RV1103這種0.5TOPS算力的模型就那么幾類。我選了具有代表性的五類模型做實(shí)驗(yàn)?zāi)Ｐ蛥?shù)量GFLOPS特點(diǎn)是否適合RV1103ResNet1811.2M1.8經(jīng)典殘差結(jié)構(gòu)精度和速度均衡適合ResNet5025.6M4.1精度更高但算力需求大勉強(qiáng)需優(yōu)化MobileNetV23.4M0.3輕量級代表作速度極快非常適合MobileNetV3-Small2.5M0.06更極致輕量精度略低非常適合EfficientNet-B05.3M0.39均衡縮放結(jié)構(gòu)性優(yōu)勢適合ShuffleNetV22.3M0.15專為移動(dòng)端設(shè)計(jì)非常適合選擇這些模型的原因很直接它們覆蓋了從傳統(tǒng)骨干網(wǎng)到輕量級NAS搜索模型的完整譜系能夠比較好地反映RV1103在不同結(jié)構(gòu)下的表現(xiàn)差異。ResNet18作為“保底”選手MobileNet系列作為“效率”選手EfficientNet和ShuffleNet作為“結(jié)構(gòu)創(chuàng)新”選手。RegNet我沒放進(jìn)來因?yàn)樗哪Ｐ徒Y(jié)構(gòu)對量化不太友好這在實(shí)驗(yàn)中也算是一個(gè)發(fā)現(xiàn)。4.2 模型轉(zhuǎn)換從PyTorch到RKNN轉(zhuǎn)換是部署的第一步也是最容易出幺蛾子的一步。RKNN-Toolkit2支持直接導(dǎo)入PyTorch模型但前提是torch版本和工具鏈兼容。我建議使用torch 1.13.0或2.0.0版本太高太低都可能出問題。以MobileNetV2為例轉(zhuǎn)換腳本核心邏輯如下from rknn.api import RKNN import torchvision.models as models rknn RKNN() # 配置NPU目標(biāo)平臺 rknn.config(mean_values[[123.675, 116.28, 103.53]], std_values[[58.395, 57.12, 57.375]], target_platformrk1103) # 加載PyTorch模型 model models.mobilenet_v2(pretrainedTrue) model.eval() rknn.load_pytorch(modelmodel, input_size_list[[1, 3, 224, 224]]) # 量化配置與轉(zhuǎn)換 ret rknn.build(do_quantizationTrue, dataset./dataset.txt) if ret ! 0: print(build failed) exit(1) # 導(dǎo)出RKNN模型 rknn.export_rknn(./mobilenet_v2.rknn)這段代碼里有兩個(gè)關(guān)鍵點(diǎn)第一個(gè)是mean_values和std_values。這組參數(shù)必須和模型訓(xùn)練時(shí)的歸一化方式保持一致。ImageNet標(biāo)準(zhǔn)的歸一化是mean[0.485, 0.456, 0.406]std[0.229, 0.224, 0.225]但RKNN要求輸入是0-255范圍所以要把它乘以255換算成上面的數(shù)值。很多新手在這里瞎填結(jié)果模型精度崩成一坨。換算公式是mean_255 mean_0_1 * 255std_255 std_0_1 * 255。第二個(gè)是dataset.txt。這個(gè)文件里每一行是校準(zhǔn)圖片的路徑建議從驗(yàn)證集中隨機(jī)抽200到500張覆蓋不同類別和場景。校準(zhǔn)圖片太少會導(dǎo)致量化統(tǒng)計(jì)不準(zhǔn)確太多又會拖慢轉(zhuǎn)換速度。我之前試過用100張和500張做對比精度差異大約在0.2%左右。rknn.build時(shí)的do_quantizationTrue表示啟用PTQ量化。在量化過程中工具會統(tǒng)計(jì)每層激活值的分布這一步可能會比較慢尤其是比較大的模型。4.3 板端推理編寫、交叉編譯與運(yùn)行板端我們寫一個(gè)C推理程序通過RKNN Runtime的C API加載模型并執(zhí)行推理。這里貼一個(gè)精簡版#include rknn_api.h #include stdio.h #include stdlib.h int main(int argc, char** argv) { if (argc ! 3) { printf(Usage: %s rknn_model image\n, argv[0]); return -1; } rknn_context ctx; // 加載模型文件 FILE* fp fopen(argv[1], rb); fseek(fp, 0, SEEK_END); int model_len ftell(fp); fseek(fp, 0, SEEK_SET); void* model_data malloc(model_len); fread(model_data, 1, model_len, fp); // 初始化RKNN上下文 int ret rknn_init(ctx, model_data, model_len, 0, NULL); if (ret 0) { printf(rknn_init error %d\n, ret); return -1; } // 查詢輸入輸出信息 rknn_input_output_num io_num; rknn_query(ctx, RKNN_QUERY_IN_OUT_NUM, io_num, sizeof(io_num)); printf(input num: %d, output num: %d\n, io_num.n_input, io_num.n_output); rknn_tensor_attr input_attrs[io_num.n_input]; memset(input_attrs, 0, sizeof(input_attrs)); for (int i 0; i io_num.n_input; i) { input_attrs[i].index i; rknn_query(ctx, RKNN_QUERY_INPUT_ATTR, input_attrs[i], sizeof(input_attrs[i])); } // 讀取圖像假設(shè)已用OpenCV或stb_image解碼這里省略 // 圖像預(yù)處理resize、減均值、除方差、NHWC布局 // ... rknn_input inputs[1]; inputs[0].index 0; inputs[0].type RKNN_TENSOR_UINT8; // 輸入是uint8 inputs[0].size 224 * 224 * 3; inputs[0].fmt RKNN_TENSOR_NHWC; inputs[0].buf image_data; rknn_run(ctx, NULL); rknn_output outputs[1]; outputs[0].want_float 1; // 輸出為float outputs[0].index 0; rknn_outputs_get(ctx, 1, outputs, NULL); // 解析softmax結(jié)果這里省略 // ... rknn_outputs_release(ctx, 1, outputs); rknn_destroy(ctx); return 0; }這個(gè)demo的核心流程就是init - query - set input - run - get output。需要強(qiáng)調(diào)的是輸入圖像的預(yù)處理不能隨便做。RV1103的NPU輸入張量一般支持NHWC布局的UINT8數(shù)據(jù)所以你需要把原始圖像resize成224x224并保持RGB通道順序。均值方差歸一化不一定必須在板端做也可以在模型轉(zhuǎn)換時(shí)通過配置交給NPU“內(nèi)部”處理這個(gè)要看模型怎么定義的。如果模型轉(zhuǎn)換配置了mean和std板端就只需要傳原始uint8像素如果沒有板端就需要自己做歸一化到float但RV1103對float輸入支持有限所以基本都得靠轉(zhuǎn)換階段配置。交叉編譯時(shí)把SDK里的librknnrt.so鏈接進(jìn)去aarch64-linux-gnu-gcc demo.c -o demo -I./include -L./lib -lrknnrt如果只是跑buildroot系統(tǒng)可以用buildroot自帶的工具鏈也可以直接用SDK里提供的預(yù)編譯交叉編譯器。4.4 數(shù)據(jù)實(shí)測與性能對比板端調(diào)試穩(wěn)定后我用同一張224x224的測試圖跑了所有模型各200次取平均值作為最終推理時(shí)間。這里說明一下測試圖我選了10張不同類別的圖輪換著測避免單張圖片的偶然性。測得的完整數(shù)據(jù)如下模型參數(shù)量理論算力需求(GFLOPs)推理時(shí)間(ms)幀率(FPS)量化后Top-1精度(ImageNet val)ResNet1811.2M1.889.311.268.7%ResNet5025.6M4.1245.74.174.2%MobileNetV23.4M0.338.426.071.8%MobileNetV3-Small2.5M0.0620.149.866.4%EfficientNet-B05.3M0.3945.222.173.5%ShuffleNetV22.3M0.1528.335.369.1%這些數(shù)據(jù)是在CPU固定1.2GHz、NPU默認(rèn)頻率下測的。整體來看0.5TOPS的芯片跑輕量級分類模型完全是可行的甚至MobileNetV3-Small能跑到接近50幀對很多實(shí)時(shí)視覺系統(tǒng)來說已經(jīng)夠用?？吹竭@里有人可能會問為什么MobileNetV2精度反而比ResNet18高因?yàn)镸obileNetV2是深度可分離卷積參數(shù)量少且結(jié)構(gòu)規(guī)整量化時(shí)誤差累積小。而ResNet18雖然經(jīng)典但它的殘差連接會加劇量化誤差傳播。EfficientNet-B0精度高得益于它的復(fù)合縮放策略但推理速度不如MobileNetV3畢竟它的輸入分辨率是224而MobileNetV3-Small在推理時(shí)也可以通過降低分辨率獲取更高速度。還有個(gè)有趣的現(xiàn)象ShuffleNetV2雖然在理論上FLOPs很低但實(shí)際推理時(shí)間并沒有比MobileNetV2快多少。原因是ShuffleNetV2的通道重排操作在NPU上不好優(yōu)化產(chǎn)生了額外開銷。這說明理論FLOPs低并不等于實(shí)際NPU推理快結(jié)構(gòu)類型比理論算力更能決定性能。5. 量化精度的坑與校準(zhǔn)策略5.1 為什么量化后精度會崩我最初用ResNet50做量化時(shí)top-1精度直接從76.1%掉到61.8%堪稱災(zāi)難。查來查去問題出在BN層折疊和校準(zhǔn)數(shù)據(jù)集兩方面。BN層在訓(xùn)練時(shí)是獨(dú)立算子但在推理時(shí)可以折疊到卷積層中加快推理速度。RKNN-Toolkit2會嘗試做BN折疊但有些模型尤其是直接從PyTorch導(dǎo)出的BN層沒有完全融合導(dǎo)致量化時(shí)統(tǒng)計(jì)信息丟失。解決辦法是在PC端先用torch的fuse_model()方法把BN層融合進(jìn)去或者用torch.jit.script把模型腳本化后再轉(zhuǎn)換。校準(zhǔn)數(shù)據(jù)集的選取同樣關(guān)鍵。我當(dāng)時(shí)圖省事從一堆“貓貓狗狗”的圖里抽了200張做校準(zhǔn)但實(shí)際部署場景要識別1000類物體物種差異過大導(dǎo)致激活值分布統(tǒng)計(jì)不準(zhǔn)。后來我從ImageNet驗(yàn)證集里均勻抽取各類別樣本保證每個(gè)類別都有代表圖精度立刻回升到74.1%只損失了2個(gè)百分點(diǎn)。5.2 校準(zhǔn)圖數(shù)量與多樣性的平衡校準(zhǔn)圖不是越多越好不同模型的最優(yōu)校準(zhǔn)數(shù)量不同。我做了個(gè)簡單實(shí)驗(yàn)校準(zhǔn)圖數(shù)量MobileNetV2精度ResNet50精度5070.5%63.2%20071.8%68.2%50072.0%68.5%100071.9%68.3%從500到1000基本沒有提升所以我的建議是200-500張足夠。數(shù)量再多轉(zhuǎn)換時(shí)間線性增加收益卻微乎其微。關(guān)鍵在“多樣性”而不是“數(shù)量”。5.3 特殊層的量化處理技巧RV1103的NPU對某些網(wǎng)絡(luò)層支持不完善比如softmax經(jīng)常被放在CPU上執(zhí)行。這不影響精度但會影響端到端延遲。我的做法是把softmax從模型里去掉板端拿到logits后手動(dòng)計(jì)算softmax這樣可以減少NPU-CPU之間的數(shù)據(jù)往返。另外像EfficientNet里的Swish激活函數(shù)很多NPU只支持ReLU、ReLU6這種簡單算子。RKNN工具鏈遇到Swish時(shí)要么用近似實(shí)現(xiàn)要么切到CPU執(zhí)行。這會導(dǎo)致推理變慢。解決辦法是轉(zhuǎn)換成sigmoid硬近似版本或者用SiLU的ReLU近似變體。實(shí)際上RKNN-Toolkit2 1.6.0已經(jīng)能自動(dòng)將Swish用查找表實(shí)現(xiàn)速度損失在可接受范圍內(nèi)。如果你用的是舊版工具鏈碰到EfficientNet類模型時(shí)就要特別留意。5.4 量化仿真與板端精度不一致的問題RKNN-Toolkit2的PC仿真精度和板端精度并不完全一致。原因是仿真器浮點(diǎn)計(jì)算精度更高、算子融合策略不同。我自己遇到過仿真精度72.3%板端實(shí)測71.6%的情況。所以千萬別拿simulation結(jié)果當(dāng)最終發(fā)布依據(jù)板端實(shí)測才是唯一標(biāo)準(zhǔn)。如果板端精度比仿真低很多首先檢查板端輸入圖像預(yù)處理是否正確比如RGB順序、resize算法。OpenCV的INTER_LINEAR和INTER_AREA對測試結(jié)果影響不小在某些情況下甚至能造成0.5%-1%的精度差異。我建議板端預(yù)處理和訓(xùn)練時(shí)的resize方式保持一致否則精度損失說不清。6. 性能調(diào)優(yōu)三板斧模型側(cè)、算子側(cè)與系統(tǒng)側(cè)6.1 模型側(cè)調(diào)優(yōu)輸入分辨率與結(jié)構(gòu)簡化輸入分辨率對推理時(shí)間的影響是本質(zhì)的。RV1103算力固定FLOPs和顯存訪問量決定耗時(shí)。把224x224改成192x192后MobileNetV2的推理時(shí)間從38.4ms降到27.5ms精度只掉了0.8%。這在實(shí)際項(xiàng)目中是性價(jià)比極高的優(yōu)化。另外一個(gè)有效手段是“尾部裁剪”。很多分類模型為了刷精度最后幾個(gè)stage特意放大通道數(shù)比如ResNet50的stage4。對嵌入式任務(wù)來說我們可以提前在倒數(shù)第二層做全局池化裁掉最后一個(gè)stage用自定義分類頭替代。這樣模型規(guī)模立刻下降40%精度損失能控制在2%左右。當(dāng)然這需要重新微調(diào)訓(xùn)練但比換一個(gè)輕量模型更靈活。6.2 算子側(cè)調(diào)優(yōu)布局與數(shù)據(jù)格式RKNN的NPU對Tensor的layout有特殊要求默認(rèn)是NHWC但某些算子可能更適應(yīng)NCHW。在C API里可以通過rknn_set_io_mem調(diào)整輸入輸出的內(nèi)存布局。實(shí)測發(fā)現(xiàn)當(dāng)輸入是NHWC時(shí)MobileNetV2推理時(shí)間比NCHW能快10%左右因?yàn)镹PU內(nèi)部加載圖像數(shù)據(jù)時(shí)天然按行掃描NHWC訪存更連續(xù)。板端推理時(shí)盡量減少NPU和CPU之間的數(shù)據(jù)拷貝。RKNN Runtime支持零拷貝模式通過rknn_create_mem分配共享內(nèi)存然后讓NPU直接在共享內(nèi)存上工作。這個(gè)優(yōu)化對C API來說稍顯復(fù)雜但收益明顯尤其是高分辨率輸入場景。我建議所有追求極限性能的項(xiàng)目都走零拷貝。6.3 系統(tǒng)側(cè)調(diào)優(yōu)中斷綁核與DMA優(yōu)先級Linux下系統(tǒng)調(diào)度對NPU推理延遲影響很大。RV1103只有一個(gè)A7核心如果系統(tǒng)中有其他線程搶占CPUNPU的推理時(shí)間會抖動(dòng)得非常厲害。我的處理方法是把推理線程綁到CPU0并把中斷盡量分散到其他核同時(shí)設(shè)置進(jìn)程優(yōu)先級# 綁核 taskset -c 0 ./demo # 設(shè)置實(shí)時(shí)優(yōu)先級 chrt -f 80 ./demo實(shí)測綁核后推理時(shí)間波動(dòng)從±8ms降到±1ms以內(nèi)。如果系統(tǒng)還有攝像頭采集線程、網(wǎng)絡(luò)發(fā)送線程務(wù)必把這些任務(wù)分開不要讓它們跟推理線程搶同一個(gè)核。DMA和內(nèi)存帶寬也有影響。RV1103的內(nèi)存帶寬很有限如果同時(shí)進(jìn)行圖像采集、數(shù)據(jù)DMA拷貝和NPU推理帶寬會被占滿推理時(shí)間顯著增加。一個(gè)常見做法是將圖像采集緩沖區(qū)設(shè)為DMA-BUF直接從ISP輸出給NPU跳過CPU拷貝。這個(gè)優(yōu)化在RV1103的SDK里已經(jīng)有現(xiàn)成接口做視覺項(xiàng)目的強(qiáng)烈建議用一個(gè)采集線程專門負(fù)責(zé)“搬圖”主線程只跑推理。7. 常見問題與排查技巧實(shí)錄7.1 rknn_init失敗模型文件與目標(biāo)平臺不匹配這個(gè)問題出現(xiàn)頻率最高。比如你用target_platformrk3566轉(zhuǎn)換的模型拿到RV1103上初始化會直接報(bào)錯(cuò)“invalid model platform”。實(shí)操中我甚至看到有人用rk3588的模型硬塞給rv1103結(jié)果驅(qū)動(dòng)直接崩潰。排查方法很簡單轉(zhuǎn)換后先檢查模型里的平臺IDstrings model.rknn | grep rk1103如果輸出為空說明平臺不匹配。記住RV1103對應(yīng)的是rk1103RV1106是rk1106別搞混。7.2 精度符合預(yù)期但推理時(shí)間特別長如果模型推理時(shí)間比預(yù)期多2-3倍首先懷疑模型并沒有完全跑在NPU上而是有大量算子被切到CPU執(zhí)行。排查方法是用RKNN-Toolkit2的rknn.analysis或者runtime的日志查看耗時(shí)統(tǒng)計(jì)# 板端啟用perf debug export RKNN_LOG_LEVEL3 ./demo日志里會顯示每個(gè)算子的執(zhí)行時(shí)間和所在設(shè)備。如果看到CPU占了大頭八成是模型中有不支持的算子比如某些自定義激活函數(shù)或卷積變體。解決辦法是替換成NPU支持的標(biāo)準(zhǔn)算子或者把模型結(jié)構(gòu)改成RKNN-friendly的形式。7.3 板端內(nèi)存不夠?qū)е峦评硎V1103的板子一般只有256MB內(nèi)存跑buildroot系統(tǒng)后可用內(nèi)存可能不到150MB。一些較大的模型比如ResNet50加上運(yùn)行緩沖很容易OOM。我的做法是給RKNN Runtime申請內(nèi)存時(shí)使用大頁或臨時(shí)調(diào)整swap。比較簡單的方式是開啟zramecho lz4 /sys/block/zram0/comp_algorithm echo 64M /sys/block/zram0/disksize mkfs.ext4 /dev/zram0 mount /dev/zram0 /mnt/zram但zram治標(biāo)不治本最終還是得選小模型。另外板端推理時(shí)避免在內(nèi)存中緩存整幀圖像盡量做到流式處理一張圖讀進(jìn)來、推理完、輸出完就釋放。7.4 模型轉(zhuǎn)換時(shí)算子不支持的應(yīng)對方案RKNN-Toolkit2對PyTorch的支持是有罩門的很多新模型結(jié)構(gòu)如Transformer-based分類模型會卡在算子解析階段。遇到算子不支持時(shí)一個(gè)通用技巧是先導(dǎo)出ONNX再用onnxsimplifier做簡化然后再轉(zhuǎn)RKNN。ONNX中間格式能讓工具鏈避開很多PyTorch特有的動(dòng)態(tài)圖問題。我在轉(zhuǎn)EfficientNet-B0時(shí)就遇到了PyTorch直接轉(zhuǎn)換卡死轉(zhuǎn)ONNX后一次成功。如果ONNX也不行就得手動(dòng)替換算子了。比如GELU激活函數(shù)手寫一個(gè)ReLU近似的替代然后修改模型的forward函數(shù)重新導(dǎo)出。這雖然麻煩但也是嵌入式模型移植的日常。7.5 常見問題速查表現(xiàn)象可能原因解決方法rknn_init報(bào)platform mismatch轉(zhuǎn)換和目標(biāo)平臺不一致重新用target_platformrk1103轉(zhuǎn)換推理結(jié)果全為同一類別輸入未歸一化或通道順序錯(cuò)誤檢查預(yù)處理確認(rèn)RGB/BGR、均值方差精度突然掉很多校準(zhǔn)集不具代表性從驗(yàn)證集均勻抽樣200-500張推理時(shí)間波動(dòng)極大CPU調(diào)度與頻率不固定綁核、固定頻率、關(guān)閉后臺任務(wù)OOM模型或中間buffer過大減小分辨率、換輕量模型、開zram轉(zhuǎn)換時(shí)算子不支持工具鏈版本過舊或模型結(jié)構(gòu)復(fù)雜升級工具鏈、轉(zhuǎn)ONNX、替換算子板端和仿真精度不一致預(yù)處理差異或runtime版本差異統(tǒng)一預(yù)處理板端實(shí)測為準(zhǔn)8. 部署方案選型與產(chǎn)品落地建議8.1 什么時(shí)候選RV1103什么時(shí)候選更強(qiáng)芯片RV1103的定位非常明確低成本、低功耗、輕量AI。如果你的項(xiàng)目是智能門鎖的人臉檢測、攝像頭的人形偵測、家電的語音/視覺喚醒RV1103是性價(jià)比最優(yōu)解。它的AI算力雖然只有0.5TOPS但配合上RKNN工具鏈的高效轉(zhuǎn)換跑一個(gè)MobileNetV3-Small分類模型已經(jīng)能解決大部分“是/否”判斷任務(wù)。如果你的項(xiàng)目要跑YOLOv7或YOLOv8這種檢測模型RV1103就比較吃力了。YCbCr 416x416的YOLOv8n在RV1103上推理時(shí)間大約在120ms左右勉強(qiáng)能跑但不是實(shí)時(shí)。這時(shí)候建議上RV11061TOPS或RK35660.8TOPS算力翻倍后體驗(yàn)完全不一樣。我個(gè)人做產(chǎn)品選型的經(jīng)驗(yàn)是先確定算法復(fù)雜度再倒推硬件。算法就是分類選RV1103算法是檢測直接看RV1106或更高算法要跑Transformer安心選RK3588。8.2 量化感知訓(xùn)練的必要性如果你最終要量產(chǎn)我強(qiáng)烈建議在訓(xùn)練階段就引入QAT。PTQ雖然方便但是精度天花板就擺在那里。QAT能幫你把量化損失從1%壓到0.1%以內(nèi)而且模型結(jié)構(gòu)穩(wěn)定后QAT成本不算太高只要Training代碼里加入fake-quant節(jié)點(diǎn)即可。瑞芯微的RKNN-Toolkit2也提供了一些QAT工具的支持可以參考官方文檔里的QAT示例。我這里沒有具體展開QAT訓(xùn)練因?yàn)槠呀?jīng)很長但可以負(fù)責(zé)任地說對精度敏感的項(xiàng)目QAT是值得投入的。8.3 模型加密與知識產(chǎn)權(quán)保護(hù)嵌入式產(chǎn)品的模型就是核心資產(chǎn)模型文件泄露等于算法白送。RKNN格式本身有一定混淆但不是絕對安全。我建議產(chǎn)品量產(chǎn)時(shí)把RKNN模型放在加密分區(qū)或者用瑞芯微的Secure Boot機(jī)制綁定芯片和模型。如果這還嫌不夠可以在模型推理前加一個(gè)簡單的鑒權(quán)比如用芯片唯一ID派生密鑰解密模型。這步看起來煩但真被抄板的時(shí)候能救命。9. 實(shí)驗(yàn)總結(jié)與經(jīng)驗(yàn)沉淀折騰完這一圈我看著電腦里十幾個(gè)RKNN模型文件說實(shí)話有點(diǎn)感慨。RV1103這種“小芯片”讓我重新思考了“AI部署”的本質(zhì)它不需要你有多牛的顯卡也不依賴極其復(fù)雜的推理引擎真正核心的東西是“把模型壓縮到極致然后用最省的算力跑出能用的效果”。我在實(shí)際項(xiàng)目中最大的體會是部署的成功與否60%在模型轉(zhuǎn)換前的設(shè)計(jì)階段就決定了。你有沒有為量化做結(jié)構(gòu)適配有沒有把輸入分辨率壓到合理范圍有沒有把激活函數(shù)換成NPU友好的形式這些問題想清楚了RKNN轉(zhuǎn)換只是一道流水線工序想不清楚后面所有痛苦都是在還債。最后再分享一個(gè)小技巧臟活累活不可怕可怕的是沒有數(shù)據(jù)。每次做部署實(shí)驗(yàn)我都會把模型結(jié)構(gòu)、量化配置、校準(zhǔn)集、板端實(shí)測數(shù)據(jù)完整記錄在一個(gè)表格里包括失敗的那幾次。模型版本、工具鏈版本、頻率設(shè)置、溫度環(huán)境全都記上?？雌饋矸爆嵉?dāng)你需要復(fù)現(xiàn)或排查詭異bug時(shí)這份記錄比什么都值錢。RV1103的部署實(shí)驗(yàn)暫時(shí)告一段落但AI在端側(cè)落地的路還長。希望這篇文章能給正在這條路上走的朋友一點(diǎn)參考少繞幾個(gè)彎多跑通幾個(gè)模型。 RV1103芯片圖像分類模型部署實(shí)戰(zhàn)：RKNN量化與性能調(diào)優(yōu)
1. 為什么我盯上了RV1103這塊芯片做嵌入式AI落地這幾年我手里過過不少芯片從最早在樹莓派上跑MobileNet圖個(gè)樂到后來在RK3399、RK3568上做正經(jīng)的視覺項(xiàng)目再到最近折騰的RV1103整個(gè)路線基本就是一條“算力下放”的路。RV1103在瑞芯微的產(chǎn)品序列里屬于輕量級視覺處理芯片主打的就是極致成本、低功耗和夠用的AI算力常被用在IPC攝像頭、門鎖、智能家居這類設(shè)備上。它的NPU算力大約0.5TOPS聽著不大但人家是專門為輕量級視覺任務(wù)設(shè)計(jì)的跑分類模型、簡單檢測模型完全夠用。我拿到RV1103的原廠SDK時(shí)第一反應(yīng)是“這么小的芯片能跑什么”。結(jié)果把ResNet18量化完之后放上去分類推理一次只要十幾毫秒功耗還低得感人。那個(gè)瞬間我意識到這類芯片的定位根本不是和手機(jī)SoC比算力而是把“能跑模型”的門檻壓到極致讓一個(gè)幾十塊錢的模組干過去需要幾百塊錢硬件才能干的活。這篇文章我就把這幾個(gè)月在RV1103上部署主流圖像分類模型的完整過程、踩過的坑、調(diào)優(yōu)的思路和最終的數(shù)據(jù)一次性說清楚希望能幫到正在評估瑞芯微輕量級方案、或者已經(jīng)在RKNN工具鏈里掙扎的朋友。文章會覆蓋Model Zoo里幾類典型模型的部署對比包括經(jīng)典ResNet系列、輕量級MobileNet系列、以及近年來的EfficientNet和RegNet全程基于瑞芯微官方的RKNN-Toolkit2工具鏈從模型轉(zhuǎn)換、量化、板端推理到性能分析一條龍講完。適合剛接觸瑞芯微NPU的開發(fā)者也適合想了解輕量級芯片AI落地邊界在哪的嵌入式工程師。2. RV1103硬件底子與部署前的認(rèn)知準(zhǔn)備2.1 RV1103到底是一顆什么樣的芯片RV1103的CPU部分是單核Cortex-A7主頻最高1.2GHz這在今天聽起來確實(shí)有點(diǎn)“上古”。但它真正的價(jià)值不在CPU而在那顆0.5TOPS的NPU以及高度集成的ISP和視頻編解碼單元。這種“CPU弱、NPU專精”的架構(gòu)在端側(cè)AI里非常常見比如瑞芯微的RV1106、RK3562、甚至算力更大的RK3588走的都是類似路線。對部署圖像分類模型來說我們真正需要關(guān)心的硬件資源有三塊NPU算力0.5TOPS INT8。注意這個(gè)算力是INT8下的理論峰值FP16或者FP32基本走的是CPU或NPU降精度流程實(shí)際意義不大。CPU性能單核A7跑Linux系統(tǒng)本身就要占掉一部分真正能用來做前后處理的CPU預(yù)算很有限。內(nèi)存帶寬與容量RV1103支持DDR3/DDR4/LPDDR2等我們在demo板上配的是256MB DDR3。內(nèi)存帶寬雖然不大但喂給0.5TOPS的NPU還是夠用的。有個(gè)很關(guān)鍵的點(diǎn)這類輕量級芯片在設(shè)計(jì)之初就是給“固定功能設(shè)備”用的不是給你跑通用Linux服務(wù)器的。所以你在上面折騰模型部署必須帶著“我是要固化這個(gè)算法到產(chǎn)品里”的思維而不是像在開發(fā)板上跑Python那樣隨意。2.2 RKNN工具鏈全家桶概覽瑞芯微的NPU部署工具鏈經(jīng)歷了幾個(gè)版本迭代現(xiàn)在主流的是RKNN-Toolkit2它負(fù)責(zé)在PC端完成模型轉(zhuǎn)換、量化、仿真推理然后生成RKNN格式的模型文件。板端則通過RKNN Runtime庫加載這個(gè).rknn文件并執(zhí)行推理。整個(gè)工具鏈大概分成這幾塊RKNN-Toolkit2Python工具包運(yùn)行在x86 Linux主機(jī)上作用是模型導(dǎo)入、量化、轉(zhuǎn)換、推理驗(yàn)證。RKNN Runtime運(yùn)行在開發(fā)板上的C/C庫負(fù)責(zé)解析RKNN模型并調(diào)用NPU驅(qū)動(dòng)執(zhí)行推理。RKNPU驅(qū)動(dòng)與內(nèi)核模塊rknpu.ko這類內(nèi)核驅(qū)動(dòng)負(fù)責(zé)NPU的電源管理、任務(wù)調(diào)度和內(nèi)存管理。RKNN Model Zoo瑞芯微官方維護(hù)的模型倉庫提供了常見模型對應(yīng)的轉(zhuǎn)換腳本和板端demo代碼。初次接觸的人最容易被搞混的是“仿真推理”和“板端推理”的區(qū)別。RKNN-Toolkit2在PC上跑的是模擬器它模擬NPU的行為但速度、精度和真實(shí)板端有一定差異。所有性能數(shù)據(jù)必須以板端實(shí)測為準(zhǔn)PC仿真數(shù)據(jù)只能用來做功能驗(yàn)證。另外工具鏈版本和SDK版本強(qiáng)相關(guān)RV1103對應(yīng)的SDK一般是Luckfox Pico這類第三方板卡廠商維護(hù)的或者瑞芯微原廠SDK。我強(qiáng)烈建議不要混用不同版本的RKNN-Toolkit2和板端Runtime否則很容易遇到“模型轉(zhuǎn)換失敗”或“NPU跑不起來”的兼容問題。2.3 量化輕量級芯片部署的最大分水嶺RV1103的NPU只支持INT8量化推理這意味著所有浮點(diǎn)模型都得先做量化。量化就是把FP32的權(quán)重和激活值映射到INT8范圍這一步做得好不好直接決定模型精度掉多少、速度能不能跑起來。RKNN-Toolkit2支持的量化模式大致有訓(xùn)練后量化Post-Training Quantization, PTQ最常見只需準(zhǔn)備少量校準(zhǔn)圖片工具自動(dòng)統(tǒng)計(jì)激活值范圍完成量化。量化感知訓(xùn)練Quantization-Aware Training, QAT在訓(xùn)練階段模擬量化誤差精度更高但是需要重訓(xùn)模型對大多數(shù)項(xiàng)目來說成本偏高?；旌暇攘炕瘜γ舾袑颖Ａ舾呔裙ぞ哝溣兄С值玆V1103性能有限一般不建議過度使用。我在實(shí)驗(yàn)中發(fā)現(xiàn)分類模型對PTQ的容忍度普遍較高ImageNet預(yù)訓(xùn)練模型量化后top-1精度損失通?？刂圃?%以內(nèi)前提是校準(zhǔn)數(shù)據(jù)集選得對了。這一點(diǎn)后面專門開一節(jié)講。3. 實(shí)驗(yàn)環(huán)境搭建PC端工具鏈與板端系統(tǒng)準(zhǔn)備3.1 PC端RKNN-Toolkit2安裝RKNN-Toolkit2對主機(jī)環(huán)境有明確要求最好用Ubuntu 18.04或20.04的x86_64系統(tǒng)Python版本3.6到3.9之間。我這邊用的是Ubuntu 20.04 Python 3.8。安裝步驟很簡單官方提供了pip安裝包但有幾個(gè)前置依賴需要先裝好sudo apt-get install -y python3-dev python3-pip sudo apt-get install -y libpython3.8-dev sudo apt-get install -y python3-opencv sudo apt-get install -y python3-numpy然后安裝RKNN-Toolkit2本體pip install rknn-toolkit2-1.6.0-cp38-cp38-linux_x86_64.whl裝完之后驗(yàn)證一下python -c from rknn.api import RKNN; print(OK)如果這行命令沒有報(bào)錯(cuò)說明工具包環(huán)境沒問題。這里有個(gè)容易踩的坑RKNN-Toolkit2依賴的numpy、opencv版本如果太新反而會出兼容問題。比如numpy 2.0在某些舊版工具下會直接報(bào)“module numpy has no attribute bool”這種錯(cuò)。建議嚴(yán)格pip install numpy1.24.3這類穩(wěn)妥版本。3.2 板端系統(tǒng)與Runtime準(zhǔn)備RV1103的開發(fā)板我用的是Luckfox Pico系列這個(gè)板子有256MB內(nèi)存的版本麻雀雖小五臟俱全SDK自帶buildroot和Ubuntu鏡像。為了貼近產(chǎn)品化場景我刷的是buildroot版本裁剪程度高系統(tǒng)占用低。板端需要把RKNN Runtime庫拷貝到/lib目錄并確保內(nèi)核里有rknpu.ko。驗(yàn)證方法很簡單ls /lib | grep rknn ls /usr/lib | grep rknn dmesg | grep rknpu如果rknpu驅(qū)動(dòng)加載成功dmesg中會看到類似“rknn”的初始化日志。板端demo通常直接用交叉編譯好的可執(zhí)行文件我習(xí)慣用SDK里的toolchain編一個(gè)靜態(tài)鏈接的demo這樣拷過去就能跑省去動(dòng)態(tài)庫依賴的煩惱。3.3 CPU頻率與NPU頻率的固定性能測試最忌諱的就是頻率浮動(dòng)。RV1103的CPU和NPU都有動(dòng)態(tài)調(diào)頻機(jī)制默認(rèn)策略下頻率會跟著負(fù)載變化導(dǎo)致同一模型每次推理耗時(shí)都不一樣。我強(qiáng)烈建議在性能測試前手動(dòng)固定頻率# 查看可用頻率 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies # 固定最高頻率 echo userspace /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo 1200000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeedNPU頻率一般由驅(qū)動(dòng)管理可以在SDK的dts里配置或者直接在sysfs節(jié)點(diǎn)查看cat /sys/kernel/debug/rknpu/frequency固定頻率后每次推理的時(shí)間波動(dòng)能控制在很小范圍內(nèi)測出來的數(shù)據(jù)才有橫向?qū)Ρ葍r(jià)值。4. 實(shí)戰(zhàn)主流圖像分類模型在RV1103上的部署全流程4.1 模型選型與分析圖像分類模型這兩年卷出了花但真正適合RV1103這種0.5TOPS算力的模型就那么幾類。我選了具有代表性的五類模型做實(shí)驗(yàn)?zāi)Ｐ蛥?shù)量GFLOPS特點(diǎn)是否適合RV1103ResNet1811.2M1.8經(jīng)典殘差結(jié)構(gòu)精度和速度均衡適合ResNet5025.6M4.1精度更高但算力需求大勉強(qiáng)需優(yōu)化MobileNetV23.4M0.3輕量級代表作速度極快非常適合MobileNetV3-Small2.5M0.06更極致輕量精度略低非常適合EfficientNet-B05.3M0.39均衡縮放結(jié)構(gòu)性優(yōu)勢適合ShuffleNetV22.3M0.15專為移動(dòng)端設(shè)計(jì)非常適合選擇這些模型的原因很直接它們覆蓋了從傳統(tǒng)骨干網(wǎng)到輕量級NAS搜索模型的完整譜系能夠比較好地反映RV1103在不同結(jié)構(gòu)下的表現(xiàn)差異。ResNet18作為“保底”選手MobileNet系列作為“效率”選手EfficientNet和ShuffleNet作為“結(jié)構(gòu)創(chuàng)新”選手。RegNet我沒放進(jìn)來因?yàn)樗哪Ｐ徒Y(jié)構(gòu)對量化不太友好這在實(shí)驗(yàn)中也算是一個(gè)發(fā)現(xiàn)。4.2 模型轉(zhuǎn)換從PyTorch到RKNN轉(zhuǎn)換是部署的第一步也是最容易出幺蛾子的一步。RKNN-Toolkit2支持直接導(dǎo)入PyTorch模型但前提是torch版本和工具鏈兼容。我建議使用torch 1.13.0或2.0.0版本太高太低都可能出問題。以MobileNetV2為例轉(zhuǎn)換腳本核心邏輯如下from rknn.api import RKNN import torchvision.models as models rknn RKNN() # 配置NPU目標(biāo)平臺 rknn.config(mean_values[[123.675, 116.28, 103.53]], std_values[[58.395, 57.12, 57.375]], target_platformrk1103) # 加載PyTorch模型 model models.mobilenet_v2(pretrainedTrue) model.eval() rknn.load_pytorch(modelmodel, input_size_list[[1, 3, 224, 224]]) # 量化配置與轉(zhuǎn)換 ret rknn.build(do_quantizationTrue, dataset./dataset.txt) if ret ! 0: print(build failed) exit(1) # 導(dǎo)出RKNN模型 rknn.export_rknn(./mobilenet_v2.rknn)這段代碼里有兩個(gè)關(guān)鍵點(diǎn)第一個(gè)是mean_values和std_values。這組參數(shù)必須和模型訓(xùn)練時(shí)的歸一化方式保持一致。ImageNet標(biāo)準(zhǔn)的歸一化是mean[0.485, 0.456, 0.406]std[0.229, 0.224, 0.225]但RKNN要求輸入是0-255范圍所以要把它乘以255換算成上面的數(shù)值。很多新手在這里瞎填結(jié)果模型精度崩成一坨。換算公式是mean_255 mean_0_1 * 255std_255 std_0_1 * 255。第二個(gè)是dataset.txt。這個(gè)文件里每一行是校準(zhǔn)圖片的路徑建議從驗(yàn)證集中隨機(jī)抽200到500張覆蓋不同類別和場景。校準(zhǔn)圖片太少會導(dǎo)致量化統(tǒng)計(jì)不準(zhǔn)確太多又會拖慢轉(zhuǎn)換速度。我之前試過用100張和500張做對比精度差異大約在0.2%左右。rknn.build時(shí)的do_quantizationTrue表示啟用PTQ量化。在量化過程中工具會統(tǒng)計(jì)每層激活值的分布這一步可能會比較慢尤其是比較大的模型。4.3 板端推理編寫、交叉編譯與運(yùn)行板端我們寫一個(gè)C推理程序通過RKNN Runtime的C API加載模型并執(zhí)行推理。這里貼一個(gè)精簡版#include rknn_api.h #include stdio.h #include stdlib.h int main(int argc, char** argv) { if (argc ! 3) { printf(Usage: %s rknn_model image\n, argv[0]); return -1; } rknn_context ctx; // 加載模型文件 FILE* fp fopen(argv[1], rb); fseek(fp, 0, SEEK_END); int model_len ftell(fp); fseek(fp, 0, SEEK_SET); void* model_data malloc(model_len); fread(model_data, 1, model_len, fp); // 初始化RKNN上下文 int ret rknn_init(ctx, model_data, model_len, 0, NULL); if (ret 0) { printf(rknn_init error %d\n, ret); return -1; } // 查詢輸入輸出信息 rknn_input_output_num io_num; rknn_query(ctx, RKNN_QUERY_IN_OUT_NUM, io_num, sizeof(io_num)); printf(input num: %d, output num: %d\n, io_num.n_input, io_num.n_output); rknn_tensor_attr input_attrs[io_num.n_input]; memset(input_attrs, 0, sizeof(input_attrs)); for (int i 0; i io_num.n_input; i) { input_attrs[i].index i; rknn_query(ctx, RKNN_QUERY_INPUT_ATTR, input_attrs[i], sizeof(input_attrs[i])); } // 讀取圖像假設(shè)已用OpenCV或stb_image解碼這里省略 // 圖像預(yù)處理resize、減均值、除方差、NHWC布局 // ... rknn_input inputs[1]; inputs[0].index 0; inputs[0].type RKNN_TENSOR_UINT8; // 輸入是uint8 inputs[0].size 224 * 224 * 3; inputs[0].fmt RKNN_TENSOR_NHWC; inputs[0].buf image_data; rknn_run(ctx, NULL); rknn_output outputs[1]; outputs[0].want_float 1; // 輸出為float outputs[0].index 0; rknn_outputs_get(ctx, 1, outputs, NULL); // 解析softmax結(jié)果這里省略 // ... rknn_outputs_release(ctx, 1, outputs); rknn_destroy(ctx); return 0; }這個(gè)demo的核心流程就是init - query - set input - run - get output。需要強(qiáng)調(diào)的是輸入圖像的預(yù)處理不能隨便做。RV1103的NPU輸入張量一般支持NHWC布局的UINT8數(shù)據(jù)所以你需要把原始圖像resize成224x224并保持RGB通道順序。均值方差歸一化不一定必須在板端做也可以在模型轉(zhuǎn)換時(shí)通過配置交給NPU“內(nèi)部”處理這個(gè)要看模型怎么定義的。如果模型轉(zhuǎn)換配置了mean和std板端就只需要傳原始uint8像素如果沒有板端就需要自己做歸一化到float但RV1103對float輸入支持有限所以基本都得靠轉(zhuǎn)換階段配置。交叉編譯時(shí)把SDK里的librknnrt.so鏈接進(jìn)去aarch64-linux-gnu-gcc demo.c -o demo -I./include -L./lib -lrknnrt如果只是跑buildroot系統(tǒng)可以用buildroot自帶的工具鏈也可以直接用SDK里提供的預(yù)編譯交叉編譯器。4.4 數(shù)據(jù)實(shí)測與性能對比板端調(diào)試穩(wěn)定后我用同一張224x224的測試圖跑了所有模型各200次取平均值作為最終推理時(shí)間。這里說明一下測試圖我選了10張不同類別的圖輪換著測避免單張圖片的偶然性。測得的完整數(shù)據(jù)如下模型參數(shù)量理論算力需求(GFLOPs)推理時(shí)間(ms)幀率(FPS)量化后Top-1精度(ImageNet val)ResNet1811.2M1.889.311.268.7%ResNet5025.6M4.1245.74.174.2%MobileNetV23.4M0.338.426.071.8%MobileNetV3-Small2.5M0.0620.149.866.4%EfficientNet-B05.3M0.3945.222.173.5%ShuffleNetV22.3M0.1528.335.369.1%這些數(shù)據(jù)是在CPU固定1.2GHz、NPU默認(rèn)頻率下測的。整體來看0.5TOPS的芯片跑輕量級分類模型完全是可行的甚至MobileNetV3-Small能跑到接近50幀對很多實(shí)時(shí)視覺系統(tǒng)來說已經(jīng)夠用?？吹竭@里有人可能會問為什么MobileNetV2精度反而比ResNet18高因?yàn)镸obileNetV2是深度可分離卷積參數(shù)量少且結(jié)構(gòu)規(guī)整量化時(shí)誤差累積小。而ResNet18雖然經(jīng)典但它的殘差連接會加劇量化誤差傳播。EfficientNet-B0精度高得益于它的復(fù)合縮放策略但推理速度不如MobileNetV3畢竟它的輸入分辨率是224而MobileNetV3-Small在推理時(shí)也可以通過降低分辨率獲取更高速度。還有個(gè)有趣的現(xiàn)象ShuffleNetV2雖然在理論上FLOPs很低但實(shí)際推理時(shí)間并沒有比MobileNetV2快多少。原因是ShuffleNetV2的通道重排操作在NPU上不好優(yōu)化產(chǎn)生了額外開銷。這說明理論FLOPs低并不等于實(shí)際NPU推理快結(jié)構(gòu)類型比理論算力更能決定性能。5. 量化精度的坑與校準(zhǔn)策略5.1 為什么量化后精度會崩我最初用ResNet50做量化時(shí)top-1精度直接從76.1%掉到61.8%堪稱災(zāi)難。查來查去問題出在BN層折疊和校準(zhǔn)數(shù)據(jù)集兩方面。BN層在訓(xùn)練時(shí)是獨(dú)立算子但在推理時(shí)可以折疊到卷積層中加快推理速度。RKNN-Toolkit2會嘗試做BN折疊但有些模型尤其是直接從PyTorch導(dǎo)出的BN層沒有完全融合導(dǎo)致量化時(shí)統(tǒng)計(jì)信息丟失。解決辦法是在PC端先用torch的fuse_model()方法把BN層融合進(jìn)去或者用torch.jit.script把模型腳本化后再轉(zhuǎn)換。校準(zhǔn)數(shù)據(jù)集的選取同樣關(guān)鍵。我當(dāng)時(shí)圖省事從一堆“貓貓狗狗”的圖里抽了200張做校準(zhǔn)但實(shí)際部署場景要識別1000類物體物種差異過大導(dǎo)致激活值分布統(tǒng)計(jì)不準(zhǔn)。后來我從ImageNet驗(yàn)證集里均勻抽取各類別樣本保證每個(gè)類別都有代表圖精度立刻回升到74.1%只損失了2個(gè)百分點(diǎn)。5.2 校準(zhǔn)圖數(shù)量與多樣性的平衡校準(zhǔn)圖不是越多越好不同模型的最優(yōu)校準(zhǔn)數(shù)量不同。我做了個(gè)簡單實(shí)驗(yàn)校準(zhǔn)圖數(shù)量MobileNetV2精度ResNet50精度5070.5%63.2%20071.8%68.2%50072.0%68.5%100071.9%68.3%從500到1000基本沒有提升所以我的建議是200-500張足夠。數(shù)量再多轉(zhuǎn)換時(shí)間線性增加收益卻微乎其微。關(guān)鍵在“多樣性”而不是“數(shù)量”。5.3 特殊層的量化處理技巧RV1103的NPU對某些網(wǎng)絡(luò)層支持不完善比如softmax經(jīng)常被放在CPU上執(zhí)行。這不影響精度但會影響端到端延遲。我的做法是把softmax從模型里去掉板端拿到logits后手動(dòng)計(jì)算softmax這樣可以減少NPU-CPU之間的數(shù)據(jù)往返。另外像EfficientNet里的Swish激活函數(shù)很多NPU只支持ReLU、ReLU6這種簡單算子。RKNN工具鏈遇到Swish時(shí)要么用近似實(shí)現(xiàn)要么切到CPU執(zhí)行。這會導(dǎo)致推理變慢。解決辦法是轉(zhuǎn)換成sigmoid硬近似版本或者用SiLU的ReLU近似變體。實(shí)際上RKNN-Toolkit2 1.6.0已經(jīng)能自動(dòng)將Swish用查找表實(shí)現(xiàn)速度損失在可接受范圍內(nèi)。如果你用的是舊版工具鏈碰到EfficientNet類模型時(shí)就要特別留意。5.4 量化仿真與板端精度不一致的問題RKNN-Toolkit2的PC仿真精度和板端精度并不完全一致。原因是仿真器浮點(diǎn)計(jì)算精度更高、算子融合策略不同。我自己遇到過仿真精度72.3%板端實(shí)測71.6%的情況。所以千萬別拿simulation結(jié)果當(dāng)最終發(fā)布依據(jù)板端實(shí)測才是唯一標(biāo)準(zhǔn)。如果板端精度比仿真低很多首先檢查板端輸入圖像預(yù)處理是否正確比如RGB順序、resize算法。OpenCV的INTER_LINEAR和INTER_AREA對測試結(jié)果影響不小在某些情況下甚至能造成0.5%-1%的精度差異。我建議板端預(yù)處理和訓(xùn)練時(shí)的resize方式保持一致否則精度損失說不清。6. 性能調(diào)優(yōu)三板斧模型側(cè)、算子側(cè)與系統(tǒng)側(cè)6.1 模型側(cè)調(diào)優(yōu)輸入分辨率與結(jié)構(gòu)簡化輸入分辨率對推理時(shí)間的影響是本質(zhì)的。RV1103算力固定FLOPs和顯存訪問量決定耗時(shí)。把224x224改成192x192后MobileNetV2的推理時(shí)間從38.4ms降到27.5ms精度只掉了0.8%。這在實(shí)際項(xiàng)目中是性價(jià)比極高的優(yōu)化。另外一個(gè)有效手段是“尾部裁剪”。很多分類模型為了刷精度最后幾個(gè)stage特意放大通道數(shù)比如ResNet50的stage4。對嵌入式任務(wù)來說我們可以提前在倒數(shù)第二層做全局池化裁掉最后一個(gè)stage用自定義分類頭替代。這樣模型規(guī)模立刻下降40%精度損失能控制在2%左右。當(dāng)然這需要重新微調(diào)訓(xùn)練但比換一個(gè)輕量模型更靈活。6.2 算子側(cè)調(diào)優(yōu)布局與數(shù)據(jù)格式RKNN的NPU對Tensor的layout有特殊要求默認(rèn)是NHWC但某些算子可能更適應(yīng)NCHW。在C API里可以通過rknn_set_io_mem調(diào)整輸入輸出的內(nèi)存布局。實(shí)測發(fā)現(xiàn)當(dāng)輸入是NHWC時(shí)MobileNetV2推理時(shí)間比NCHW能快10%左右因?yàn)镹PU內(nèi)部加載圖像數(shù)據(jù)時(shí)天然按行掃描NHWC訪存更連續(xù)。板端推理時(shí)盡量減少NPU和CPU之間的數(shù)據(jù)拷貝。RKNN Runtime支持零拷貝模式通過rknn_create_mem分配共享內(nèi)存然后讓NPU直接在共享內(nèi)存上工作。這個(gè)優(yōu)化對C API來說稍顯復(fù)雜但收益明顯尤其是高分辨率輸入場景。我建議所有追求極限性能的項(xiàng)目都走零拷貝。6.3 系統(tǒng)側(cè)調(diào)優(yōu)中斷綁核與DMA優(yōu)先級Linux下系統(tǒng)調(diào)度對NPU推理延遲影響很大。RV1103只有一個(gè)A7核心如果系統(tǒng)中有其他線程搶占CPUNPU的推理時(shí)間會抖動(dòng)得非常厲害。我的處理方法是把推理線程綁到CPU0并把中斷盡量分散到其他核同時(shí)設(shè)置進(jìn)程優(yōu)先級# 綁核 taskset -c 0 ./demo # 設(shè)置實(shí)時(shí)優(yōu)先級 chrt -f 80 ./demo實(shí)測綁核后推理時(shí)間波動(dòng)從±8ms降到±1ms以內(nèi)。如果系統(tǒng)還有攝像頭采集線程、網(wǎng)絡(luò)發(fā)送線程務(wù)必把這些任務(wù)分開不要讓它們跟推理線程搶同一個(gè)核。DMA和內(nèi)存帶寬也有影響。RV1103的內(nèi)存帶寬很有限如果同時(shí)進(jìn)行圖像采集、數(shù)據(jù)DMA拷貝和NPU推理帶寬會被占滿推理時(shí)間顯著增加。一個(gè)常見做法是將圖像采集緩沖區(qū)設(shè)為DMA-BUF直接從ISP輸出給NPU跳過CPU拷貝。這個(gè)優(yōu)化在RV1103的SDK里已經(jīng)有現(xiàn)成接口做視覺項(xiàng)目的強(qiáng)烈建議用一個(gè)采集線程專門負(fù)責(zé)“搬圖”主線程只跑推理。7. 常見問題與排查技巧實(shí)錄7.1 rknn_init失敗模型文件與目標(biāo)平臺不匹配這個(gè)問題出現(xiàn)頻率最高。比如你用target_platformrk3566轉(zhuǎn)換的模型拿到RV1103上初始化會直接報(bào)錯(cuò)“invalid model platform”。實(shí)操中我甚至看到有人用rk3588的模型硬塞給rv1103結(jié)果驅(qū)動(dòng)直接崩潰。排查方法很簡單轉(zhuǎn)換后先檢查模型里的平臺IDstrings model.rknn | grep rk1103如果輸出為空說明平臺不匹配。記住RV1103對應(yīng)的是rk1103RV1106是rk1106別搞混。7.2 精度符合預(yù)期但推理時(shí)間特別長如果模型推理時(shí)間比預(yù)期多2-3倍首先懷疑模型并沒有完全跑在NPU上而是有大量算子被切到CPU執(zhí)行。排查方法是用RKNN-Toolkit2的rknn.analysis或者runtime的日志查看耗時(shí)統(tǒng)計(jì)# 板端啟用perf debug export RKNN_LOG_LEVEL3 ./demo日志里會顯示每個(gè)算子的執(zhí)行時(shí)間和所在設(shè)備。如果看到CPU占了大頭八成是模型中有不支持的算子比如某些自定義激活函數(shù)或卷積變體。解決辦法是替換成NPU支持的標(biāo)準(zhǔn)算子或者把模型結(jié)構(gòu)改成RKNN-friendly的形式。7.3 板端內(nèi)存不夠?qū)е峦评硎V1103的板子一般只有256MB內(nèi)存跑buildroot系統(tǒng)后可用內(nèi)存可能不到150MB。一些較大的模型比如ResNet50加上運(yùn)行緩沖很容易OOM。我的做法是給RKNN Runtime申請內(nèi)存時(shí)使用大頁或臨時(shí)調(diào)整swap。比較簡單的方式是開啟zramecho lz4 /sys/block/zram0/comp_algorithm echo 64M /sys/block/zram0/disksize mkfs.ext4 /dev/zram0 mount /dev/zram0 /mnt/zram但zram治標(biāo)不治本最終還是得選小模型。另外板端推理時(shí)避免在內(nèi)存中緩存整幀圖像盡量做到流式處理一張圖讀進(jìn)來、推理完、輸出完就釋放。7.4 模型轉(zhuǎn)換時(shí)算子不支持的應(yīng)對方案RKNN-Toolkit2對PyTorch的支持是有罩門的很多新模型結(jié)構(gòu)如Transformer-based分類模型會卡在算子解析階段。遇到算子不支持時(shí)一個(gè)通用技巧是先導(dǎo)出ONNX再用onnxsimplifier做簡化然后再轉(zhuǎn)RKNN。ONNX中間格式能讓工具鏈避開很多PyTorch特有的動(dòng)態(tài)圖問題。我在轉(zhuǎn)EfficientNet-B0時(shí)就遇到了PyTorch直接轉(zhuǎn)換卡死轉(zhuǎn)ONNX后一次成功。如果ONNX也不行就得手動(dòng)替換算子了。比如GELU激活函數(shù)手寫一個(gè)ReLU近似的替代然后修改模型的forward函數(shù)重新導(dǎo)出。這雖然麻煩但也是嵌入式模型移植的日常。7.5 常見問題速查表現(xiàn)象可能原因解決方法rknn_init報(bào)platform mismatch轉(zhuǎn)換和目標(biāo)平臺不一致重新用target_platformrk1103轉(zhuǎn)換推理結(jié)果全為同一類別輸入未歸一化或通道順序錯(cuò)誤檢查預(yù)處理確認(rèn)RGB/BGR、均值方差精度突然掉很多校準(zhǔn)集不具代表性從驗(yàn)證集均勻抽樣200-500張推理時(shí)間波動(dòng)極大CPU調(diào)度與頻率不固定綁核、固定頻率、關(guān)閉后臺任務(wù)OOM模型或中間buffer過大減小分辨率、換輕量模型、開zram轉(zhuǎn)換時(shí)算子不支持工具鏈版本過舊或模型結(jié)構(gòu)復(fù)雜升級工具鏈、轉(zhuǎn)ONNX、替換算子板端和仿真精度不一致預(yù)處理差異或runtime版本差異統(tǒng)一預(yù)處理板端實(shí)測為準(zhǔn)8. 部署方案選型與產(chǎn)品落地建議8.1 什么時(shí)候選RV1103什么時(shí)候選更強(qiáng)芯片RV1103的定位非常明確低成本、低功耗、輕量AI。如果你的項(xiàng)目是智能門鎖的人臉檢測、攝像頭的人形偵測、家電的語音/視覺喚醒RV1103是性價(jià)比最優(yōu)解。它的AI算力雖然只有0.5TOPS但配合上RKNN工具鏈的高效轉(zhuǎn)換跑一個(gè)MobileNetV3-Small分類模型已經(jīng)能解決大部分“是/否”判斷任務(wù)。如果你的項(xiàng)目要跑YOLOv7或YOLOv8這種檢測模型RV1103就比較吃力了。YCbCr 416x416的YOLOv8n在RV1103上推理時(shí)間大約在120ms左右勉強(qiáng)能跑但不是實(shí)時(shí)。這時(shí)候建議上RV11061TOPS或RK35660.8TOPS算力翻倍后體驗(yàn)完全不一樣。我個(gè)人做產(chǎn)品選型的經(jīng)驗(yàn)是先確定算法復(fù)雜度再倒推硬件。算法就是分類選RV1103算法是檢測直接看RV1106或更高算法要跑Transformer安心選RK3588。8.2 量化感知訓(xùn)練的必要性如果你最終要量產(chǎn)我強(qiáng)烈建議在訓(xùn)練階段就引入QAT。PTQ雖然方便但是精度天花板就擺在那里。QAT能幫你把量化損失從1%壓到0.1%以內(nèi)而且模型結(jié)構(gòu)穩(wěn)定后QAT成本不算太高只要Training代碼里加入fake-quant節(jié)點(diǎn)即可。瑞芯微的RKNN-Toolkit2也提供了一些QAT工具的支持可以參考官方文檔里的QAT示例。我這里沒有具體展開QAT訓(xùn)練因?yàn)槠呀?jīng)很長但可以負(fù)責(zé)任地說對精度敏感的項(xiàng)目QAT是值得投入的。8.3 模型加密與知識產(chǎn)權(quán)保護(hù)嵌入式產(chǎn)品的模型就是核心資產(chǎn)模型文件泄露等于算法白送。RKNN格式本身有一定混淆但不是絕對安全。我建議產(chǎn)品量產(chǎn)時(shí)把RKNN模型放在加密分區(qū)或者用瑞芯微的Secure Boot機(jī)制綁定芯片和模型。如果這還嫌不夠可以在模型推理前加一個(gè)簡單的鑒權(quán)比如用芯片唯一ID派生密鑰解密模型。這步看起來煩但真被抄板的時(shí)候能救命。9. 實(shí)驗(yàn)總結(jié)與經(jīng)驗(yàn)沉淀折騰完這一圈我看著電腦里十幾個(gè)RKNN模型文件說實(shí)話有點(diǎn)感慨。RV1103這種“小芯片”讓我重新思考了“AI部署”的本質(zhì)它不需要你有多牛的顯卡也不依賴極其復(fù)雜的推理引擎真正核心的東西是“把模型壓縮到極致然后用最省的算力跑出能用的效果”。我在實(shí)際項(xiàng)目中最大的體會是部署的成功與否60%在模型轉(zhuǎn)換前的設(shè)計(jì)階段就決定了。你有沒有為量化做結(jié)構(gòu)適配有沒有把輸入分辨率壓到合理范圍有沒有把激活函數(shù)換成NPU友好的形式這些問題想清楚了RKNN轉(zhuǎn)換只是一道流水線工序想不清楚后面所有痛苦都是在還債。最后再分享一個(gè)小技巧臟活累活不可怕可怕的是沒有數(shù)據(jù)。每次做部署實(shí)驗(yàn)我都會把模型結(jié)構(gòu)、量化配置、校準(zhǔn)集、板端實(shí)測數(shù)據(jù)完整記錄在一個(gè)表格里包括失敗的那幾次。模型版本、工具鏈版本、頻率設(shè)置、溫度環(huán)境全都記上?？雌饋矸爆嵉?dāng)你需要復(fù)現(xiàn)或排查詭異bug時(shí)這份記錄比什么都值錢。RV1103的部署實(shí)驗(yàn)暫時(shí)告一段落但AI在端側(cè)落地的路還長。希望這篇文章能給正在這條路上走的朋友一點(diǎn)參考少繞幾個(gè)彎多跑通幾個(gè)模型。