1. 為什么要在 RK3568 上折騰圖像分類模型RK3568 這顆芯片在邊緣計(jì)算圈子里熱度一直不低。四核 Cortex-A55 加一顆 0.8 TOPS 的 NPU支持 INT8 量化推理功耗控制在幾瓦級(jí)別價(jià)格又相對(duì)友好做智能門禁、工業(yè)質(zhì)檢、零售貨柜這類場(chǎng)景的開發(fā)者基本都會(huì)把它列入候選。但真到落地階段問題就來了手頭訓(xùn)好的圖像分類模型五花八門ResNet、MobileNet、EfficientNet、ViT 各有各的結(jié)構(gòu)到底哪個(gè)能在 RK3568 上跑得又快又準(zhǔn)官方文檔給的數(shù)據(jù)往往只覆蓋少數(shù)幾個(gè)經(jīng)典網(wǎng)絡(luò)實(shí)際選型時(shí)還是得自己動(dòng)手測(cè)一遍。我最近花了大概兩周時(shí)間把手上常見的幾類圖像分類模型在 RK3568 上完整跑了一輪部署實(shí)驗(yàn)從模型轉(zhuǎn)換、量化、板端推理到精度和速度對(duì)比踩了不少坑也積累了一些官方文檔里不會(huì)寫的經(jīng)驗(yàn)。這篇文章就是把整個(gè)實(shí)驗(yàn)過程、數(shù)據(jù)結(jié)果和實(shí)操心得整理出來給正在做類似選型的同行一個(gè)參考。不管你是剛接觸 RKNN 工具鏈的新手還是已經(jīng)用過 RK3588 想了解 RK3568 差異的老手應(yīng)該都能從中找到有用的東西。需要提前說明的是實(shí)驗(yàn)平臺(tái)是一塊標(biāo)準(zhǔn)的 RK3568 開發(fā)板4GB 內(nèi)存版本系統(tǒng)是官方 Ubuntu 20.04 固件RKNN-Toolkit2 用的是 1.6.0 版本NPU 驅(qū)動(dòng)版本 0.8.2。不同固件和工具鏈版本可能會(huì)有差異具體數(shù)據(jù)僅供參考但方法論是通用的。2. 實(shí)驗(yàn)整體設(shè)計(jì)與模型選型思路2.1 為什么選這幾類模型圖像分類模型發(fā)展到今天大致可以分成幾個(gè)流派。一類是以 ResNet 為代表的經(jīng)典卷積網(wǎng)絡(luò)結(jié)構(gòu)規(guī)整、算子標(biāo)準(zhǔn)對(duì) NPU 友好一類是以 MobileNet、ShuffleNet 為代表的輕量級(jí)網(wǎng)絡(luò)專為移動(dòng)端設(shè)計(jì)參數(shù)量和計(jì)算量都?jí)旱煤艿瓦€有一類是以 EfficientNet 為代表的復(fù)合縮放網(wǎng)絡(luò)用 NAS 思路平衡深度、寬度和分辨率最后是近兩年火起來的 ViT 系列基于注意力機(jī)制精度高但對(duì)算力和內(nèi)存帶寬要求也高。我選型的邏輯是每個(gè)流派挑一到兩個(gè)有代表性的模型覆蓋不同的參數(shù)量級(jí)和計(jì)算量級(jí)這樣對(duì)比出來的結(jié)論才有參考價(jià)值。具體清單如下模型參數(shù)量輸入尺寸流派選它的理由ResNet1811.7M224x224經(jīng)典卷積結(jié)構(gòu)標(biāo)準(zhǔn)作為基準(zhǔn)線ResNet5025.6M224x224經(jīng)典卷積大模型在 NPU 上的表現(xiàn)MobileNetV23.4M224x224輕量級(jí)移動(dòng)端經(jīng)典部署廣泛MobileNetV3-Small2.5M224x224輕量級(jí)更極致的輕量化ShuffleNetV22.3M224x224輕量級(jí)通道混洗算子的兼容性EfficientNet-B05.3M224x224復(fù)合縮放NAS 結(jié)構(gòu)的部署難度ViT-B/1686M224x224注意力機(jī)制驗(yàn)證 Transformer 可行性這個(gè)組合基本能覆蓋大多數(shù)實(shí)際項(xiàng)目會(huì)遇到的模型類型。如果你手頭的模型不在這個(gè)列表里也可以參照這個(gè)分類找到最接近的參考對(duì)象。2.2 實(shí)驗(yàn)要回答的三個(gè)核心問題整個(gè)實(shí)驗(yàn)圍繞三個(gè)問題展開。第一是精度損失模型經(jīng)過 INT8 量化后Top-1 準(zhǔn)確率會(huì)掉多少不同結(jié)構(gòu)的模型對(duì)量化的敏感度是否一樣第二是推理速度單幀推理耗時(shí)多少毫秒能否滿足實(shí)時(shí)性要求比如 30fps 需要單幀低于 33ms第三是部署難度模型轉(zhuǎn)換過程中會(huì)遇到哪些算子不支持的問題需要多少手工干預(yù)這三個(gè)問題對(duì)應(yīng)了實(shí)際選型時(shí)最關(guān)心的三個(gè)維度。精度決定能不能用速度決定好不好用部署難度決定要花多少人力。很多網(wǎng)上的評(píng)測(cè)只講速度不講精度或者只講精度不講部署成本參考價(jià)值有限。我這次盡量把三個(gè)維度都量化出來。2.3 測(cè)試數(shù)據(jù)集和評(píng)價(jià)標(biāo)準(zhǔn)精度測(cè)試用的是 ImageNet 驗(yàn)證集的子集5000 張圖片覆蓋 1000 個(gè)類別。之所以不用完整 50000 張是因?yàn)榘宥送评硭俣扔邢尥暾芤槐闀r(shí)間太長(zhǎng)。5000 張的采樣保證了每個(gè)類別至少 5 張統(tǒng)計(jì)上足夠反映精度趨勢(shì)。評(píng)價(jià)指標(biāo)用 Top-1 和 Top-5 準(zhǔn)確率對(duì)比三個(gè)階段的數(shù)值PyTorch 原始模型、ONNX 轉(zhuǎn)換后模型、RKNN INT8 量化后模型。這樣能清楚看到精度損失發(fā)生在哪個(gè)環(huán)節(jié)。速度測(cè)試用板端 NPU 推理預(yù)熱 10 次后取 100 次推理的平均耗時(shí)排除首次加載和緩存的影響。3. 部署環(huán)境搭建與工具鏈配置3.1 PC 端環(huán)境準(zhǔn)備RKNN 工具鏈分兩部分PC 端的 RKNN-Toolkit2 負(fù)責(zé)模型轉(zhuǎn)換和量化板端的 RKNPU2 運(yùn)行時(shí)負(fù)責(zé)實(shí)際推理。PC 端建議用 Ubuntu 20.04 或 22.04Python 版本 3.8 到 3.10 之間。我一開始在 Windows 上試過工具鏈支持不完整量化功能經(jīng)常報(bào)錯(cuò)后來換到 Ubuntu 才順利。安裝命令如下conda create -n rknn python3.9 conda activate rknn pip install rknn-toolkit21.6.0 pip install onnx1.14.0 pip install torch2.0.0 torchvision0.15.0這里有個(gè)坑要注意rknn-toolkit2 對(duì) numpy 版本有要求如果環(huán)境里裝了 numpy 2.x 會(huì)報(bào)兼容性錯(cuò)誤需要降到 1.24 以下。另外 onnx 版本也不能太新1.15 以上某些算子解析會(huì)出問題我實(shí)測(cè) 1.14.0 最穩(wěn)。板端環(huán)境相對(duì)簡(jiǎn)單官方固件已經(jīng)帶了 RKNPU2 運(yùn)行時(shí)只需要確認(rèn)驅(qū)動(dòng)版本cat /sys/kernel/debug/rknpu/version如果輸出類似RKNPU2: 0.8.2就說明驅(qū)動(dòng)正常。如果版本太老建議刷最新固件老驅(qū)動(dòng)對(duì)新算子的支持不全。3.2 模型導(dǎo)出與 ONNX 轉(zhuǎn)換PyTorch 模型轉(zhuǎn) ONNX 是第一步。以 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, input_names[input], output_names[output], opset_version11, dynamic_axesNone )opset_version 建議用 11這是 RKNN 工具鏈支持最完整的版本。用 12 或 13 有時(shí)會(huì)遇到算子映射問題。dynamic_axes 設(shè)為 None 是因?yàn)榘宥送评磔斎氤叽绻潭▌?dòng)態(tài)軸反而會(huì)增加轉(zhuǎn)換復(fù)雜度。導(dǎo)出后建議用 onnxsim 做一次簡(jiǎn)化去掉冗余算子pip install onnxsim onnxsim resnet18.onnx resnet18_sim.onnx這一步能減少后續(xù)量化時(shí)的算子數(shù)量提升轉(zhuǎn)換成功率。我測(cè)過幾個(gè)模型簡(jiǎn)化后 ONNX 文件大小平均減少 15% 左右轉(zhuǎn)換時(shí)間也短一些。3.3 RKNN 模型轉(zhuǎn)換與量化配置轉(zhuǎn)換腳本的核心是量化配置。RKNN 支持兩種量化方式一是用校準(zhǔn)數(shù)據(jù)集做 PTQ訓(xùn)練后量化二是加載量化感知訓(xùn)練后的模型。實(shí)際項(xiàng)目里 PTQ 用得最多因?yàn)椴恍枰匦掠?xùn)練。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, datasetcalibration.txt) rknn.export_rknn(resnet18.rknn)這里的 mean 和 std 必須和訓(xùn)練時(shí)用的預(yù)處理參數(shù)一致否則精度會(huì)掉得莫名其妙。校準(zhǔn)數(shù)據(jù)集準(zhǔn)備 200 到 500 張圖片就夠從訓(xùn)練集里隨機(jī)采樣要覆蓋所有類別。我試過只用 50 張量化后精度掉了 3 個(gè)點(diǎn)加到 300 張后只掉 0.8 個(gè)點(diǎn)。optimization_level3是最高優(yōu)化級(jí)別會(huì)做一些算子融合和內(nèi)存優(yōu)化但偶爾會(huì)導(dǎo)致轉(zhuǎn)換失敗。如果遇到問題可以降到 2 試試。4. 各模型部署實(shí)操與精度速度實(shí)測(cè)4.1 經(jīng)典卷積網(wǎng)絡(luò)ResNet 系列ResNet18 和 ResNet50 的轉(zhuǎn)換過程最順利所有算子都被原生支持沒有遇到任何需要手工干預(yù)的地方。這得益于 ResNet 結(jié)構(gòu)規(guī)整主要是 Conv、BN、ReLU、MaxPool、GlobalAvgPool 和全連接這些都是 NPU 的標(biāo)準(zhǔn)算子。精度方面ResNet18 原始 PyTorch 模型 Top-1 是 69.8%轉(zhuǎn) ONNX 后 69.7%基本無損INT8 量化后 68.9%掉了 0.9 個(gè)點(diǎn)。ResNet50 原始 76.1%量化后 75.2%掉了 0.9 個(gè)點(diǎn)。這個(gè)損失幅度在可接受范圍內(nèi)說明 ResNet 系列對(duì) INT8 量化不敏感。速度方面ResNet18 單幀推理 12.3msResNet50 是 31.7ms。ResNet18 能輕松跑到 30fps 以上ResNet50 剛好卡在 30fps 邊緣。如果對(duì)幀率要求高ResNet50 需要降輸入分辨率或者做模型剪枝。注意ResNet 的 BN 層在量化時(shí)會(huì)被融合進(jìn) Conv這是自動(dòng)完成的不需要手動(dòng)處理。但如果你的模型里有自定義 BN 變體可能需要檢查融合是否正確。4.2 輕量級(jí)網(wǎng)絡(luò)MobileNet 與 ShuffleNetMobileNetV2 的轉(zhuǎn)換也很順利深度可分離卷積在 RK3568 NPU 上有專門優(yōu)化。精度從原始的 71.9% 掉到 70.8%損失 1.1 個(gè)點(diǎn)。速度是亮點(diǎn)單幀只要 6.8ms能跑到 140fps 以上非常適合高幀率場(chǎng)景。MobileNetV3-Small 參數(shù)量更小但精度只有 67.4%量化后 66.2%。速度 4.2ms非?？?。這個(gè)模型適合對(duì)精度要求不高但幀率要求極高的場(chǎng)景比如簡(jiǎn)單的有無檢測(cè)。ShuffleNetV2 遇到了點(diǎn)麻煩。通道混洗Channel Shuffle算子在 ONNX 里是用 Reshape Transpose Reshape 組合實(shí)現(xiàn)的RKNN 工具鏈在量化時(shí)對(duì) Transpose 的處理有點(diǎn)問題第一次轉(zhuǎn)換報(bào)錯(cuò)。解決辦法是在轉(zhuǎn)換前用 onnx-simplifier 把這三個(gè)算子融合成一個(gè)自定義算子或者手動(dòng)改寫模型結(jié)構(gòu)用等效的 1x1 卷積替代。我用了前者融合后轉(zhuǎn)換成功。精度從 69.4% 掉到 67.8%損失 1.6 個(gè)點(diǎn)比 MobileNet 系列敏感一些。模型原始 Top-1量化后 Top-1精度損失單幀耗時(shí)幀率ResNet1869.8%68.9%-0.9%12.3ms81fpsResNet5076.1%75.2%-0.9%31.7ms31fpsMobileNetV271.9%70.8%-1.1%6.8ms147fpsMobileNetV3-Small67.4%66.2%-1.2%4.2ms238fpsShuffleNetV269.4%67.8%-1.6%5.9ms169fps4.3 復(fù)合縮放網(wǎng)絡(luò)EfficientNet-B0EfficientNet-B0 的轉(zhuǎn)換遇到了 Swish 激活函數(shù)的問題。Swish 是 x * sigmoid(x)ONNX 里拆成了 Sigmoid 和 Mul 兩個(gè)算子。RKNN 對(duì) Sigmoid 的支持沒問題但量化時(shí) Sigmoid 的輸出范圍不好確定導(dǎo)致精度損失偏大。第一次轉(zhuǎn)換后精度從 77.1% 掉到 73.5%損失 3.6 個(gè)點(diǎn)明顯比其他模型差。后來我查了 RKNN 的文檔發(fā)現(xiàn)可以在 config 里指定quantized_algorithmmmse用最小均方誤差算法做量化比默認(rèn)的normal算法更適合有 Sigmoid 的網(wǎng)絡(luò)。改完后精度恢復(fù)到 75.8%損失 1.3 個(gè)點(diǎn)和其他模型差不多了。速度方面EfficientNet-B0 單幀 18.5ms約 54fps。這個(gè)速度中規(guī)中矩但考慮到它的精度比 ResNet18 高不少性價(jià)比還是不錯(cuò)的。實(shí)操心得遇到精度損失異常大的模型先別急著換模型試試調(diào)整量化算法。mmse算法對(duì)包含 Sigmoid、Tanh 這類飽和激活函數(shù)的網(wǎng)絡(luò)效果明顯更好代價(jià)是量化時(shí)間會(huì)長(zhǎng)一些。4.4 注意力機(jī)制ViT-B/16ViT 的部署是最折騰的。首先是模型太大86M 參數(shù)ONNX 文件 330MBRKNN 轉(zhuǎn)換時(shí)內(nèi)存占用很高我的 PC 有 16GB 內(nèi)存都差點(diǎn)不夠用。其次是結(jié)構(gòu)問題ViT 的核心是 Multi-Head Attention涉及大量的 MatMul 和 Softmax這些算子在 NPU 上的效率遠(yuǎn)不如卷積。轉(zhuǎn)換過程倒沒有報(bào)錯(cuò)但量化后精度從 81.8% 掉到 76.2%損失 5.6 個(gè)點(diǎn)是所有模型里最嚴(yán)重的。分析原因主要是 Attention 里的 Softmax 輸出分布比較集中INT8 量化后分辨率不夠?qū)е伦⒁饬?quán)重失真。速度更是慘不忍睹單幀 187ms只有 5fps 左右。這個(gè)速度基本沒法做實(shí)時(shí)推理只能用于離線批處理場(chǎng)景。模型原始 Top-1量化后 Top-1精度損失單幀耗時(shí)幀率EfficientNet-B077.1%75.8%-1.3%18.5ms54fpsViT-B/1681.8%76.2%-5.6%187ms5fpsViT 在 RK3568 上的表現(xiàn)說明Transformer 類模型目前還不適合這類邊緣 NPU。除非你有極致的精度需求且能接受離線推理否則還是老老實(shí)實(shí)用卷積網(wǎng)絡(luò)。5. 常見問題排查與避坑經(jīng)驗(yàn)5.1 模型轉(zhuǎn)換失敗的高頻原因轉(zhuǎn)換失敗是最常見的問題我整理了一個(gè)排查表報(bào)錯(cuò)信息原因解決辦法Unsupported op: XXX算子不支持用 onnx-simplifier 融合或改寫模型Quantize failed校準(zhǔn)數(shù)據(jù)不足增加到 300 張以上覆蓋所有類別Out of memory模型太大增加 PC 內(nèi)存或分塊轉(zhuǎn)換Shape mismatch輸入尺寸不匹配檢查 config 里的輸入尺寸設(shè)置Mean/std error預(yù)處理參數(shù)錯(cuò)誤核對(duì)訓(xùn)練時(shí)的歸一化參數(shù)其中算子不支持是最頭疼的。RKNN 1.6.0 支持的算子列表在官方文檔里有但實(shí)際轉(zhuǎn)換時(shí)經(jīng)常遇到列表里有但量化失敗的算子。我的經(jīng)驗(yàn)是遇到問題先試 onnx-simplifier能解決 80% 的情況。剩下的 20% 需要手動(dòng)改寫模型把不支持的算子用等效的支持算子替換。5.2 精度損失過大的調(diào)試思路精度損失超過 2 個(gè)點(diǎn)就需要排查了。我的調(diào)試順序是先確認(rèn) ONNX 模型本身的精度是否正常排除導(dǎo)出問題再檢查預(yù)處理參數(shù)是否一致然后嘗試不同的量化算法最后考慮增加校準(zhǔn)數(shù)據(jù)量。有一個(gè)容易被忽略的點(diǎn)是校準(zhǔn)數(shù)據(jù)的分布。如果你用 ImageNet 的圖片做校準(zhǔn)但實(shí)際部署場(chǎng)景是工業(yè)相機(jī)拍的灰度圖量化后的精度在實(shí)際場(chǎng)景里會(huì)掉得很厲害。校準(zhǔn)數(shù)據(jù)一定要貼近實(shí)際部署場(chǎng)景這是很多教程不會(huì)強(qiáng)調(diào)的。5.3 板端推理性能優(yōu)化技巧板端推理速度除了模型本身還受幾個(gè)因素影響。一是 CPU 頻率RK3568 默認(rèn)是動(dòng)態(tài)調(diào)頻推理時(shí)會(huì)自動(dòng)升頻但如果散熱不好會(huì)降頻。建議加個(gè)散熱片實(shí)測(cè)能穩(wěn)定提升 10% 左右的幀率。二是內(nèi)存帶寬多個(gè)模型同時(shí)加載會(huì)爭(zhēng)搶帶寬建議串行推理。三是 NPU 核心數(shù)RK3568 只有一個(gè) NPU 核心沒法像 RK3588 那樣多核并行。還有一個(gè)技巧是用 RKNN 的零拷貝接口避免數(shù)據(jù)在 CPU 和 NPU 之間來回拷貝。這個(gè)在官方例程里有示范能省 1 到 2ms 的拷貝時(shí)間對(duì)小模型來說占比不小。# 零拷貝推理示例 outputs rknn.inference(inputs[img], data_formatnhwc)用data_formatnhwc可以避免額外的格式轉(zhuǎn)換前提是你的輸入數(shù)據(jù)本來就是 NHWC 排列。5.4 模型選型的實(shí)戰(zhàn)建議根據(jù)這次實(shí)驗(yàn)的數(shù)據(jù)我給幾個(gè)場(chǎng)景的選型建議。高幀率簡(jiǎn)單場(chǎng)景選 MobileNetV3-Small4.2ms 的延遲基本沒有對(duì)手。精度和速度平衡選 MobileNetV2 或 EfficientNet-B0前者更快后者更準(zhǔn)。需要高精度且能接受 30fps 選 ResNet50。ShuffleNetV2 部署麻煩除非有特殊需求否則不推薦。ViT 系列目前不建議在 RK3568 上做實(shí)時(shí)推理。另外提醒一點(diǎn)這些數(shù)據(jù)是在 224x224 輸入下測(cè)的。如果你把輸入分辨率提高到 320x320 或 416x416推理時(shí)間會(huì)按面積比例增加。比如 MobileNetV2 從 224 提到 320耗時(shí)大概從 6.8ms 漲到 13ms 左右。選型時(shí)要把分辨率因素考慮進(jìn)去。6. 實(shí)驗(yàn)數(shù)據(jù)匯總與橫向?qū)Ρ劝阉袛?shù)據(jù)匯總到一張表里方便橫向?qū)Ρ饶Ｐ蛥?shù)量原始 Top-1量化 Top-1精度損失耗時(shí)幀率部署難度MobileNetV3-Small2.5M67.4%66.2%-1.2%4.2ms238fps低ShuffleNetV22.3M69.4%67.8%-1.6%5.9ms169fps中MobileNetV23.4M71.9%70.8%-1.1%6.8ms147fps低ResNet1811.7M69.8%68.9%-0.9%12.3ms81fps低EfficientNet-B05.3M77.1%75.8%-1.3%18.5ms54fps中ResNet5025.6M76.1%75.2%-0.9%31.7ms31fps低ViT-B/1686M81.8%76.2%-5.6%187ms5fps高從這張表能看出幾個(gè)規(guī)律。輕量級(jí)網(wǎng)絡(luò)的精度損失普遍比大模型略高因?yàn)樗鼈兊奶卣鞅磉_(dá)能力本來就弱量化進(jìn)一步壓縮了信息量。ResNet 系列對(duì)量化最魯棒損失都在 1 個(gè)點(diǎn)以內(nèi)。EfficientNet 需要調(diào)量化算法才能達(dá)到同等水平。ViT 是特例精度損失和速度都不理想。性價(jià)比最高的幾個(gè)選擇追求速度選 MobileNetV3-Small追求平衡選 MobileNetV2 或 EfficientNet-B0追求精度選 ResNet50。ResNet18 有點(diǎn)尷尬精度不如 EfficientNet-B0速度不如 MobileNetV2除非你的項(xiàng)目已經(jīng)在用 ResNet18 且不想換模型否則新項(xiàng)目不太推薦。7. 一些補(bǔ)充的實(shí)操細(xì)節(jié)校準(zhǔn)數(shù)據(jù)集的制作有個(gè)小技巧。不要直接把圖片路徑寫進(jìn) txt 文件而是先用腳本把圖片統(tǒng)一 resize 到模型輸入尺寸并保存這樣轉(zhuǎn)換時(shí)不用反復(fù)解碼速度快很多。我一開始用原始圖片300 張校準(zhǔn)花了 8 分鐘預(yù)處理后只要 2 分鐘。import cv2 import os for img_name in os.listdir(calib_images): img cv2.imread(fcalib_images/{img_name}) img cv2.resize(img, (224, 224)) cv2.imwrite(fcalib_resized/{img_name}, img)板端部署時(shí)建議把 RKNN 模型文件放在 eMMC 而不是 SD 卡上加載速度快 3 倍左右。RK3568 的 eMMC 讀取速度能到 200MB/s 以上SD 卡通常只有 40MB/s。模型文件雖然不大但加載時(shí)間也影響啟動(dòng)速度。還有一點(diǎn)是關(guān)于多線程的。RK3568 的 NPU 是單核的多個(gè)線程同時(shí)調(diào)用 NPU 不會(huì)提升吞吐量反而會(huì)因?yàn)樯舷挛那袚Q增加延遲。正確的做法是用一個(gè)推理線程加一個(gè)預(yù)處理線程預(yù)處理和推理流水線化這樣能提升整體吞吐。我實(shí)測(cè)這種流水線方式比單線程串行快 20% 左右。最后說下溫度問題。RK3568 滿載推理時(shí)芯片溫度能到 70 度以上如果不加散熱會(huì)觸發(fā)降頻幀率掉 30% 都有可能。我加了一個(gè) 20x20mm 的鋁散熱片溫度穩(wěn)定在 55 度左右?guī)什▌?dòng)很小。這個(gè)成本不到兩塊錢但效果立竿見影強(qiáng)烈建議加上。關(guān)于模型量化后的精度驗(yàn)證不要只看整體 Top-1還要看混淆矩陣。有些模型整體精度掉得不多但某些類別掉得很厲害如果這些類別恰好是你關(guān)心的那整體指標(biāo)就有誤導(dǎo)性。我在測(cè)試時(shí)發(fā)現(xiàn) MobileNetV3-Small 在細(xì)粒度類別比如不同品種的狗上掉點(diǎn)明顯比粗粒度類別多如果你的應(yīng)用場(chǎng)景是細(xì)粒度分類選型時(shí)要特別注意。