機器之心報導
項目作者：RangiLyu
如何把 anchor-free 模型移植到移動端或嵌入式設備？這個項目對單階段檢測模型三大模塊（Head、Neck、Backbone）進行輕量化，得到模型大小僅 1.8m、速度超快的輕量級模型 NanoDet-m。
目標檢測一直是計算機視覺領域的一大難題，其目標是找出圖像中的所有感興趣區域，並確定這些區域的位置和類別。目標檢測中的深度學習方法已經發展了很多年，並出現了不同類型的檢測方法。
目前，深度學習目標檢測方法主要分為兩大類，分別是兩階段式和單階段式目標檢測算法。兩階段式目標檢測框架首先生成候選區域，然後將其分類成不同的目標類別，代表模型有 R-CNN、Fast R-CNN 等；單階段式目標檢測框架將目標檢測任務視為一個統一的端到端回歸問題，代表模型有 MultiBox、YOLO、SSD 等。這類框架通常結構更簡單，檢測速度也更快。
深度學習目標檢測方法還可劃分為 Anchor-base 和 Anchor-free 兩大類，今年又出現了將Transformer 用於目標檢測的嘗試，各種方法百花齊放。但是，在移動端目標檢測算法上，YOLO 系列和 SSD 等 Anchor-base 的模型一直佔據主導地位。
近日，GitHub 上出現了一個項目 nanodet，它開源了一個移動端實時的 Anchor-free 檢測模型，希望能夠提供不亞於 YOLO 系列的性能，而且同樣方便訓練和移植。該項目上線僅兩天，Star 量已經超過 200。
項目地址：https://github.com/RangiLyu/nanodet
NanoDet 模型介紹
NanoDet 是一個速度超快和輕量級的移動端 Anchor-free 目標檢測模型。該模型具備以下優勢：
超輕量級：模型文件大小僅 1.8m；
速度超快：在移動 ARM CPU 上的速度達到 97fps（10.23ms）；
訓練友好：GPU 內存成本比其他模型低得多。GTX1060 6G 上的 Batch-size 為 80 即可運行；
方便部署：提供了基於 ncnn 推理框架的 C++ 實現和 Android demo。
模型性能
目前開源的 NanoDet-m 模型在 320x320 輸入解析度的情況下，整個模型的 Flops 只有 0.72B，而 yolov4-tiny 則有 6.96B，小了將近十倍。模型的參數量也只有 0.95M，權重文件在使用 ncnn optimize 進行 16 位存儲之後，只有 1.8mb。
儘管模型非常的輕量，但是它的性能不容小覷。在與其他模型進行比較時，項目作者選擇使用 COCO mAP (0.5:0.95) 作為評估指標，兼顧檢測和定位的精度，在 COCO val 5000 張圖片上測試，並且沒有使用 Testing-Time-Augmentation。在這種設置下，320 解析度輸入能夠達到 20.6 的 mAP，比 tiny-yolov3 高 4 分，只比 yolov4-tiny 低 1 個百分點。在將輸入解析度與 YOLO 保持一致，都使用 416 輸入的情況下，NanoDet 與 yolov4-tiny 得分持平。具體結果如下表所示：
以上性能基於 ncnn 和麒麟 980 (4xA76+4xA55) ARM CPU 獲得。
此外，項目作者將 ncnn 部署到手機（基於 ARM 架構的 CPU 麒麟 980，4 個 A76 核心和 4 個 A55 核心）上之後跑了一下 benchmark，模型前向計算時間只要 10 毫秒左右，而 yolov3 和 v4 tiny 均在 30 毫秒的量級。在安卓攝像頭 demo app 上，算上圖片預處理、檢測框後處理以及繪製檢測框的時間，NanoDet 也能輕鬆跑到 40+FPS。
NanoDet 和 yolov4-tiny 的性能對比。
最後，該項目提供了 Android demo、C++ demo 和 Python demo。NanoDet 在安卓端的目標檢測結果如下所示：
NanoDet 方法
NanoDet 是一種 FCOS 式的單階段 anchor-free 目標檢測模型，它使用 ATSS 進行目標採樣，使用 Generalized Focal Loss 損失函數執行分類和邊框回歸（box regression）。
據項目作者介紹，該項目的主要目的是希望開源一個移動端實時的 Anchor-free 檢測模型，能夠提供不亞於 YOLO 系列的性能，並且方便訓練和移植。為此，他參考了以下研究：
最終得到的 NanoDet 模型架構如下：
損失函數
項目作者想要實現一個 FCOS 式的 anchor-free 目標檢測模型，但將 FCOS 輕量化處理時，由於 FCOS 的 centerness 分支在輕量級的模型上很難收斂，模型效果不如預期。
最終，NanoDet 使用了李翔等人提出的 Generalized Focal Loss 損失函數。該函數能夠去掉 FCOS 的 Centerness 分支，省去這一分支上的大量卷積，從而減少檢測頭的計算開銷，非常適合移動端的輕量化部署。
圖源：https://arxiv.org/pdf/2006.04388.pdf
檢測頭輕量化
找到合適的損失函數後，如何使其在輕量級模型上發揮作用呢？
首先需要優化的是檢測頭。
FCOS 系列使用了共享權重的檢測頭，即對 FPN 出來的多尺度 Feature Map 使用同一組卷積預測檢測框，然後每一層使用一個可學習的 Scale 值作為係數，對預測出來的框進行縮放。
圖源：https://openaccess.thecvf.com/content_ICCV_2019/papers/Tian_FCOS_Fully_Convolutional_One-Stage_Object_Detection_ICCV_2019_paper.pdf
這麼做的好處是能夠將檢測頭的參數量降低為不共享權重狀態下的 1/5。這對於光是檢測頭就擁有數百通道卷積的大模型來說非常有用，但是對於輕量化模型來說，共享權重檢測頭並沒有很大的意義。由於移動端模型推理由 CPU 執行計算，共享權重並不會帶來推理過程的加速，而且在檢測頭非常輕量的情況下，共享權重使其檢測能力進一步下降，因此項目作者認為選擇對每一層特徵使用一組卷積比較合適。
同時，FCOS 系列在檢測頭上使用了 Group Normalization（GN）作為歸一化方式，GN 對比 BN（Batch Normalization）有很多好處，但是卻有一個缺點：BN 在推理時能夠將其歸一化的參數直接融合進卷積中，可以省去這一步計算，而 GN 則不行。為了能夠節省歸一化操作的時間，項目作者選擇將 GN 替換為 BN。
FCOS 的檢測頭使用了 4 個 256 通道的卷積作為一個分支，也就是說在邊框回歸和分類兩個分支上一共有 8 個 c=256 的卷積，計算量非常大。為了將其輕量化，項目作者首先選擇用深度可分離卷積替換普通卷積，並且將卷積堆疊的數量從 4 個減少為 2 組。在通道數上，將 256 維壓縮至 96 維，之所以選擇 96，是因為需要將通道數保持為 8 或 16 的倍數，能夠享受到大部分推理框架的並行加速。
最後，項目作者借鑑了 YOLO 系列的做法，將邊框回歸和分類使用同一組卷積進行計算，然後 split 成兩份。最終得到的輕量化檢測頭如下圖所示：
FPN 層改進
目前針對 FPN 的改進有許多，如 EfficientDet 使用了 BiFPN，YOLO v4 和 v5 使用了 PAN，除此之外還有 BalancedFPN 等等。BiFPN 雖然性能強大，但是堆疊的特徵融合操作會導致運行速度降低，而 PAN 只有自上而下和自下而上兩條通路，非常簡潔，是輕量級模型特徵融合的好選擇。
原版的 PAN 和 YOLO 系列中的 PAN 都使用了 stride=2 的卷積進行大尺度 Feature Map 到小尺度的縮放。而該項目出於輕量化的考慮，選擇完全去掉 PAN 中的所有卷積，只保留從骨幹網絡特徵提取後的 1x1 卷積來進行特徵通道維度的對齊，上採樣和下採樣均使用插值來完成。與 YOLO 使用的 concatenate 操作不同，項目作者選擇將多尺度的 Feature Map 直接相加，使整個特徵融合模塊的計算量變得非常小。
最終得到的極小版 PAN 結構非常簡單：
NanoDet 使用的超輕量 PAN（圖源：https://zhuanlan.zhihu.com/p/306530300）
骨幹網絡
項目作者選擇使用 ShuffleNetV2 1.0x 作為骨幹網絡，他去掉了該網絡的最後一層卷積，並且抽取 8、16、32 倍下採樣的特徵輸入到 PAN 中做多尺度的特徵融合。整個骨幹模型使用了 Torchvision 提供的代碼，能夠直接加載 Torchvision 上提供的 imagenet 預訓練權重，對加快模型收斂起到很大幫助。
目前，項目作者已將 Pytorch 訓練代碼、基於 NCNN 的 Linux 和 Windows C++ 部署代碼以及 Android 攝像頭 Demo 全部開源，並在 Readme 中提供了詳細教程，參見項目 GitHub 主頁。
知乎連結：https://zhuanlan.zhihu.com/p/306530300