CSL-YOLO
CSL-YOLO copied to clipboard
D0352276
请教网络设计问题
您好，因为自己是非科班，老师也没经验，自己研究进度缓慢。最近一直在优化yolov4-tiny，关于网络设计方面，想请教几个问题： （1）如何快速验证网络结构是否更优？我一般用VOC2007训练看结果，但也需要训练五六个小时，感觉试错成本太高 （2）网络在CPU和GPU上运行是有区别的，在CPU上更关注低Flpos和少分支结构，这个理解对吗？ （3）因为网络backbone得到了大量简化，所以yolo-head要采用更多的scale，而不是原始yolov4-tiny的2层scale，这个理解对吗？ （4）yolov4-tiny用最简单的结构实现了很好的效果，而我们人工设计的结构感觉都是在反复试错，您认为呢？ Sincerely, Best wishes
-
我原先也在Pascal VOC上面做，不過後來發現在COCO的AP嚴苛標準下與VOC的mAP非全然的正相關，但如果你受限於硬體問題，在VOC上測試也不失為一個好選擇，另外，五六個小時的實驗週期已然很短了，如果想進一步縮短試誤時間，可先將模型的輸入尺度縮小，例如從416縮至224，這個加速會十分顯著，也可採取更快的收斂策略，例如將SGD換成Adam，目的是減少整體的epochs，簡而言之，可以從縮小模型及減少epochs下手。
-
這個理解不全然正確，FLOPs(每秒浮點數次數)是理論的速度指標，學術論文上相當常見，理論上良好的實作及環境可以在GPU及CPU體現出相對應的FPS，但是實務上經常不是如此，舉例來說我們都知道ReLU相對於Sigmoid更利於GPU加速，但是這兩者在FLOPs的數字上是無法區別的，GPU有CUDA Core的硬體實現方式也有CUDA框架的軟體邏輯問題，因此不同的實作及設備環境在同等FLOPs下仍然會表現出差異極大的FPS，至於為什麼CPU的差距較小？是因為CPU架構本身就難同GPU般大量的平行運算，也極少軟硬體針對CNN模型在CPU上的加速(可能有但不多)，可以說我們在CPU跑模型通常都是裸奔狀態，所以在CPU上更容易測出與FLOPs成正比的FPS。
-
我一部分想法如你所說沒錯，為彌補模型過小的問題採取更多尺度來增強他的性能，另一方面我也認為更細緻的sclae分佈能應對更多樣的物件尺寸，我想這個觀點是不限於小模型的。
-
反覆試錯是肯定的，我只能跟你分享我一貫的方法，我會讀相關論文嘗試把他們提出的思路整合進模型然後試錯，有時後會靈光一閃想到較細節的問題，例如我論文提到的anchor約束方法，然後還是試錯，直到把有效的方案全部整合起來，其實並不聰明但能有效推進模型的改善，供你參考。
非常感谢您详细的解答，给我提供了很好的加速模型优化的思路~~ （1）当我把transformer中的多头注意力机制Multi-head attention放入yolov4-tiny时，并对结构进一步改进，使用pytorch打印网络参数，发现Flops和MAdd均降低40%左右，COCO上的mAP增加1.5%左右，但在CPU上的fps却没有提高，反而下降，我怀疑是多头注意力的多分支结构有关。 Sincerely, Best wishes
transformer中的attention使用了大量的sigmoid多少會拖慢速度，就算在CPU上都有影響，只是沒GPU顯著而已，不過如果純粹做理論模型，FLOPs降低仍然可以視作貢獻。
再次向您请教个问题，看您论文中的Table-2, MobileNetv2 的MFLOPs只有75，我找的MobileNetv2网络，用pytorch查看结果如下： from torchstat import stat model = MobileNetV2(10) stat(model, (3, 32, 32))
Total params: 2237770 Total MAdd: 607.89 MMAdd Total Flops: 306.09MFlops
请问和您的有什么不同吗？
我不太確定pytorch是怎麼計算FLOPs，不過MobileNetv2在輸入為224x224時大概是300 MFLOP，詳細數據可以參見GhostNet的論文，所以在輸入為32x32時MobileNetv2肯定要遠小於這個數字