文章轉(zhuǎn)載于:知乎
作者:RangiLyu

上來(lái)先貼一下性能對(duì)比：

華為P30上用NCNN移植跑benchmark，每幀僅需10.23毫秒，比yolov4-tiny快3倍，參數(shù)量小6倍，COCO mAP(0.5:0.95)能夠達(dá)到20.6 。而且模型權(quán)重文件只有1.8mb，對(duì)比動(dòng)輒數(shù)十兆的模型，可以說(shuō)是相當(dāng)友好了~

Android Demo

項(xiàng)目地址（提供訓(xùn)練代碼到安卓部署一站式解決方案）：

RangiLyu/nanodet: ?Super fast and lightweight anchor-free object detection model. Only 1.8mb and run 97FPS on cellphone (github.com)?github.com

前言

深度學(xué)習(xí)目標(biāo)檢測(cè)已經(jīng)發(fā)展了許多年，從Two-stage到One-stage，從Anchor-base到Anchor-free，再到今年的用Transformer做目標(biāo)檢測(cè)，各種方法百花齊放，但是在移動(dòng)端目標(biāo)檢測(cè)算法上，yolo系列和SSD等Anchor-base的模型一直占據(jù)著主導(dǎo)地位。這個(gè)項(xiàng)目的主要目的是希望能夠開(kāi)源一個(gè)移動(dòng)端實(shí)時(shí)的Anchor-free檢測(cè)模型，能夠提供不亞于yolo系列的性能，而且同樣方便訓(xùn)練和移植。
其實(shí)從去年大量anchor-free的論文發(fā)表之后，我就一直想把a(bǔ)nchor free的模型移植到移動(dòng)端或者是嵌入式設(shè)備上。當(dāng)時(shí)嘗試過(guò)把FCOS輕量化的實(shí)驗(yàn)，奈何效果并不如mobilenet+yolov3，也就暫時(shí)擱置了。分析下來(lái)，主要還是因?yàn)镕COS的centerness分支在輕量級(jí)的模型上很難收斂，之后發(fā)表的一些在FCOS上面進(jìn)行改進(jìn)的論文也都沒(méi)有解決這一問(wèn)題。

直到今年年中的時(shí)候刷arxiv突然刷到了

@李翔

老師的論文Generalized Focal Loss: Learning Qualified and Distributed Bounding Boxes for Dense Object Detection，論文中提出的GFocalLoss完美去掉了FCOS系列的Centerness分支，而且在coco數(shù)據(jù)集上漲點(diǎn)顯著，這么好的文章怎么能不點(diǎn)贊呢？GFL的出現(xiàn)不僅去掉了難以訓(xùn)練的Centerness，而且還省去了這一分支上的大量卷積，減少了檢測(cè)頭的計(jì)算開(kāi)銷(xiāo)，非常適合移動(dòng)端的輕量化部署。
貼一下李翔老師關(guān)于GFocal Loss的解讀：

李翔：大白話(huà) Generalized Focal Loss?zhuanlan.zhihu.com

檢測(cè)頭輕量化

在找到了合適的損失函數(shù)之后，接下來(lái)的關(guān)鍵就是如何使其在輕量化模型上發(fā)揮作用了。首先需要對(duì)移動(dòng)端進(jìn)行優(yōu)化的就是檢測(cè)頭：FCOS系列使用了共享權(quán)重的檢測(cè)頭，即對(duì)FPN出來(lái)的多尺度Feature Map使用同一組卷積預(yù)測(cè)檢測(cè)框，然后每一層使用一個(gè)可學(xué)習(xí)的Scale值作為系數(shù)，對(duì)預(yù)測(cè)出來(lái)的框進(jìn)行縮放。

FCOS模型架構(gòu)

這么做的好處是能夠?qū)z測(cè)頭的參數(shù)量降低為不共享權(quán)重狀態(tài)下的1/5。這對(duì)于光是檢測(cè)頭就擁有數(shù)百通道的卷積的大模型來(lái)說(shuō)非常有用，但是對(duì)于輕量化模型來(lái)說(shuō)，共享權(quán)重檢測(cè)頭并沒(méi)有很大的意義。由于移動(dòng)端模型推理由CPU進(jìn)行計(jì)算，共享權(quán)重并不會(huì)對(duì)推理過(guò)程進(jìn)行加速，而且在檢測(cè)頭非常輕量的情況下，共享權(quán)重使得其檢測(cè)能力進(jìn)一步下降，因此還是選擇每一層特征使用一組卷積比較合適。
同時(shí)，F(xiàn)COS系列在檢測(cè)頭上使用了Group Normalization作為歸一化的方式，GN對(duì)比BN有很多好處，但是卻有一個(gè)缺點(diǎn)：BN在推理時(shí)能夠?qū)⑵錃w一化的參數(shù)直接融合進(jìn)卷積中，可以省去這一步計(jì)算，而GN則不行。為了能夠節(jié)省下歸一化操作的時(shí)間，我選擇將GN替換為BN。
FCOS的檢測(cè)頭使用了4個(gè)256通道的卷積作為一個(gè)分支，也就是說(shuō)在邊框回歸和分類(lèi)兩個(gè)分支上一共有8個(gè)c=256的卷積，計(jì)算量非常大。為了將其輕量化，我首先選擇使用深度可分離卷積替換普通卷積，并且將卷積堆疊的數(shù)量從4個(gè)減少為2組。在通道數(shù)上，將256維壓縮至96維，之所以選擇96，是因?yàn)樾枰獙⑼ǖ罃?shù)保持為8或16的倍數(shù)，這樣能夠享受到大部分推理框架的并行加速。最后，借鑒了yolo系列的做法，將邊框回歸和分類(lèi)使用同一組卷積進(jìn)行計(jì)算，然后split成兩份。下圖就是最終得到的輕量化檢測(cè)頭的結(jié)構(gòu)，非常的小巧：

NanoDet檢測(cè)頭

FPN層改進(jìn)

目前針對(duì)FPN的改進(jìn)有許多，如EfficientDet使用了BiFPN，yolo v4和yolo v5使用了PAN，除此之外還有BalancedFPN等等。BiFPN雖然性能強(qiáng)大，但是堆疊的特征融合操作勢(shì)必會(huì)帶來(lái)運(yùn)行速度的降低，而PAN只有自上而下和自下而上兩條通路，非常的簡(jiǎn)潔，是輕量級(jí)模型特征融合的好選擇。
原版的PAN和yolo中的PAN，都使用了stride=2的卷積進(jìn)行大尺度Feature Map到小尺度的縮放。我為了輕量化的原則，選擇完全去掉PAN中的所有卷積，只保留從骨干網(wǎng)絡(luò)特征提取后的1x1卷積來(lái)進(jìn)行特征通道維度的對(duì)齊，上采樣和下采樣均使用插值來(lái)完成。與yolo使用的concatenate操作不同，我選擇將多尺度的Feature Map直接相加，使得整個(gè)特征融合模塊的計(jì)算量變得非常非常小。
最終的極小版PAN的結(jié)構(gòu)也是非常簡(jiǎn)單：

超輕量的PAN

Backbone的選擇

原本有考慮過(guò)自己魔改一個(gè)輕量級(jí)的backbone出來(lái)，但是最后評(píng)估了一下感覺(jué)工作量太大了（在家訓(xùn)練模型電費(fèi)太貴），就打算選擇使用現(xiàn)有的一些輕量級(jí)骨干網(wǎng)絡(luò)。最開(kāi)始的選擇有MobileNet系列，GhostNet，ShuffleNet，還有最近的EfficientNet。在評(píng)估了參數(shù)量、計(jì)算量以及權(quán)重大小之后，還是選擇了ShuffleNetV2作為骨干網(wǎng)絡(luò)，因?yàn)樗沁@些模型里面在相似精度下體積最小的，而且對(duì)移動(dòng)端CPU推理也比較友好。
最終我選擇使用ShuffleNetV2 1.0x作為backbone，去掉了最后一層卷積，并且抽取8、16、32倍下采樣的特征輸入進(jìn)PAN做多尺度的特征融合。整個(gè)骨干模型使用了Torchvision提供的代碼，能夠直接加載Torchvision上提供的imagenet預(yù)訓(xùn)練權(quán)重，對(duì)加快模型收斂有很大的幫助。順便一提，最近有些論文指出使用分類(lèi)的預(yù)訓(xùn)練權(quán)重初始化模型對(duì)檢測(cè)任務(wù)的效果不如隨機(jī)初始化的好，不過(guò)這要付出訓(xùn)練更多步數(shù)的代價(jià)，我還沒(méi)有測(cè)試過(guò)，歡迎大家嘗試~

NanoDet整體模型結(jié)構(gòu)

模型性能

在經(jīng)過(guò)對(duì)one-stage檢測(cè)模型三大模塊（Head、Neck、Backbone）都進(jìn)行輕量化之后，得到了目前開(kāi)源的NanoDet-m模型，在320x320輸入分辨率的情況下，整個(gè)模型的Flops只有0.72B，而yolov4-tiny則有6.96B，小了將近十倍！模型的參數(shù)量也只有0.95M，權(quán)重文件在使用ncnn optimize進(jìn)行16位存儲(chǔ)之后，只有1.8mb，非常適合在移動(dòng)端部署，能夠有效減少APP體積，同時(shí)也對(duì)更低端的嵌入式設(shè)備更加友好。
盡管模型非常的輕量，但是性能卻依舊強(qiáng)勁。對(duì)于小模型，往往選擇使用AP50這種比較寬容的評(píng)價(jià)指標(biāo)進(jìn)行對(duì)比，這里我選擇用更嚴(yán)格一點(diǎn)的COCO mAP(0.5:0.95)作為評(píng)估指標(biāo)，同時(shí)兼顧檢測(cè)和定位的精度。在COCO val 5000張圖片上測(cè)試，并沒(méi)有使用Testing-Time-Augmentation的情況下，320分辨率輸入能夠達(dá)到20.6的mAP，比tiny-yolov3高4分，只比yolov4-tiny低1個(gè)百分點(diǎn)，而將輸入分辨率與yolo保持一致，都使用416輸入的情況下，得分持平。
最后用ncnn部署到手機(jī)上之后跑了一下benchmark，模型前向計(jì)算時(shí)間只要10毫秒左右，對(duì)比yolov3和v4 tiny，均在30毫秒的量級(jí)。在安卓攝像頭demo app上，算上圖片預(yù)處理，檢測(cè)框后處理以及繪制檢測(cè)框的時(shí)間，也能輕松跑到40+FPS~。（關(guān)于模型從pytorch到安卓的部署，以及如何用C++實(shí)現(xiàn)GFL檢測(cè)框的后處理，我會(huì)再專(zhuān)門(mén)發(fā)一遍文章詳細(xì)介紹）

ncnn 安卓benchmark對(duì)比

總結(jié)

NanoDet總體而言沒(méi)有特別多的創(chuàng)新點(diǎn)，是一個(gè)純工程化的項(xiàng)目，主要的工作就是將目前學(xué)術(shù)界的一些優(yōu)秀論文，落地到移動(dòng)端的輕量級(jí)模型上。最后通過(guò)這些論文的組合，得到了一個(gè)兼顧精度、速度和體積的檢測(cè)模型。
為了讓大家能夠快速使用NanoDet，方便訓(xùn)練和部署，我已經(jīng)把Pytorch的訓(xùn)練代碼、基于NCNN的Linux和windowsC++部署代碼以及Android攝像頭Demo全部開(kāi)源，同時(shí)在Readme中也包含了非常詳細(xì)的教程，歡迎大家使用，歡迎提issue~
順便提一句，NanoDet訓(xùn)練并沒(méi)有用到很多數(shù)據(jù)增強(qiáng)的技巧，模型結(jié)構(gòu)也非常簡(jiǎn)單，也就是說(shuō)mAP應(yīng)該還有很大的提升空間，如果有小伙伴愿意魔改一下再漲幾個(gè)點(diǎn)那就再好不過(guò)了（嘻嘻）。
最后的最后，Github求Star?。?！

RangiLyu/nanodet: ?Super fast and lightweight anchor-free object detection model. Only 1.8mb and run 97FPS on cellphone (github.com)?github.com

/=======================================================

11月25日更新：

大家都太熱情了！NanoDet僅開(kāi)源三天Github就已經(jīng)突破900star，并且登上了Github趨勢(shì)榜！

感謝各位大佬的支持，特別感謝李翔老師的論文給NanoDet模型的啟發(fā)，以及ncnn作者nihui在項(xiàng)目初期的推廣~大家快去給ncnn和GFocalLoss點(diǎn)star??！

Tencent/ncnn: ncnn is a high-performance neural network inference framework optimized for the mobile platform (github.com)?github.comimplus/GFocal: Generalized Focal Loss: Learning Qualified and Distributed Bounding Boxes for Dense Object Detection (github.com)?github.com

之前一直在ncnn群里面討論NanoDet，感覺(jué)不太合適，所以專(zhuān)門(mén)建了一個(gè)討論群：908606542 (進(jìn)群答案：煉丹) 歡迎大家來(lái)討論~

推薦閱讀

• AI編譯優(yōu)化--業(yè)務(wù)實(shí)踐
• 如何在OpenCV DNN模塊中添加Tengine后端？

更多Tengine相關(guān)內(nèi)容請(qǐng)關(guān)注Tengine-邊緣AI推理框架專(zhuān)欄。

審核編輯：符乾江