https://mp.weixin.qq.com/s/ECQ_J_GWpLFCFAO7Emb0xw
https://zhuanlan.zhihu.com/p/400474142
YOLO-FastestV2項目鏈接：
https://github.com/dog-qiuqiu/Yolo-FastestV2
貼圖先和yolo-fastest-1.1對比下:
是的，這次我沒有優化精度，這次優化的是速度，畢竟追求的是fastest..，不過，用0.3%的精度損失換取30%推理速度的提升以及25%的參數量的減少，至少我覺得還是挺值，與其說追求的速度，其實更加注重的是算法效果與推理效率的性價比。
先說說Yolo-Fastest的初衷吧，其實早期輕量的目標檢測大家多是用的Mobilenet-SSD，其實在實際測試中，在常用的ARM設備上是很難達到實時的，只有在一些高端手機大核全開勉強達到實時，更別說工業界常用的"性能強悍的"RK3399等ARM CPU呢，達到實時基本是不可能的。包括后來自己用mobilenet對yolov3進行輕量級的優化，用1.8BFlops的計算量在Kirin 990性能上大核全開達到～55fps，雖然能在高端手機上達到很好的速度，但是在一些低端的手機CPU以及工業界常用的高端芯片RK3399，還是沒法滿足實時的。其次，在實際的應用中，考慮功耗，系統資源占用，一般也不會多核全開去推理模型，畢竟還得留些資源給其他應用，所以我一般部署模型只會設置單核，最多也是雙核。尤其在手機上，功耗問題特別嚴重，假如模型推理時CPU占用過高的話，會引起過熱降頻，反而會適得其反，其次還有續航的減少。
所以，不光只單單看模型的推理耗時，還得着重關注模型推理所消耗的系統資源，內存，CPU占用等，例如兩個模型都可以在cpu上達到30fps，但是模型A是在單核的情況下達到實時，cpu占用才20%，模型B是在4核全開的情況下達到實時，cpu占用可能100%，但是模型B效果可能要好一些，這種情況下需要權衡利弊。
Yolo-Fastest注重的就是單核的實時推理性能，在滿足實時的條件下的低CPU占用，不單單只是能在手機移動端達到實時，還要在RK3399，樹莓派4以及多種Cortex-A53低成本低功耗設備上滿足一定實時性，畢竟這些嵌入式的設備相比與移動端手機要弱很多，但是使用更加廣泛，成本更加低廉。
先說這一版的改進吧，首先模型的backbone替換為了shufflenetV2，相比原先的backbone，訪存減少了一些，更加輕量，其次Anchor的匹配機制，參考的YOLOV5，其實YOLOV5與Darknet的官版YOLOV4在Anchor的匹配機制的區別還是挺大的，這點不細講了，網上解析一大堆，其次是檢測頭的解耦合，這個也是參考YOLOX的，將檢測框的回歸，前景背景的分類以及檢測類別的分類有yolo的一個特征圖解耦成3個不同的特征圖，其中前景背景的分類以及檢測類別的分類采用同一網絡分支參數共享。最后將檢測類別分類的loss由sigmoid替換為softmax。對了，這次還是只有輸出11x11和22x22兩個尺度的檢測頭，因為發現在coco上三個檢測頭（11x11，22x22，44x44）和兩個檢測頭（11x11，22x22）的精度無太大差異，個人感覺原因如下:
-
backbone對應44x44分辨率的特征圖太少
-
正負anchor的嚴重不平衡
-
小物體屬於難樣本對於模型學習能力要求高
Yolo-FastestV2檢測頭
最后，大家可能關心的是和yolox和nanoDet的對比，精度肯定比不過啊, 不過速度應該會快個兩三倍，那體積只有 1.3M 的 PP-YOLO Tiny（"比 YOLO-Fastest 更輕、更快?"）呢，Emmm...用int8的量化后體積和yolo-fastest的fp32的體積比，有點虧...YOLO-FastestV2 int8可是僅僅只有250kb哦，雖然我沒跑過PP-YOLO Tiny，但是應該還是比他快。所以，模型的選擇還是看大家需求哦。
RK3399和樹莓派4搭配ncnn bf16s，YOLO-FastestV2 是可以實時的哦
模型的最終實測效果:
YOLO-FastestV2項目鏈接：
https://github.com/dog-qiuqiu/Yolo-FastestV2
YOLO-FastestV2代碼下載