如何评价FAIR最新开源的Detectron2目标检测框架？

基于PyTorch的Detectron2框架已开源于：https://github.com/facebookresearch/detectron2.

专业回答

作者：bearbee

https://www.zhihu.com/question/350117858/answer/854376239

最近在做产品相关，发现和之前做的Research差别真的大，几个较好的开源检测框架都尝试过，做个个人主观小结233333。

按照时间线来说，从Detectron到maskrcnn-benchmark到mmdetection到detectron2。Detectron是基于caffe2写的，其余都是Pytorch。作为17年入坑的小白，曾被tf以及旷视的megbrain虐得死去过来的人，当时暗自决定这辈子一定不碰Caffe了，故直接弃了Detectron。(然而这是一个flag，最终部署的时候很多情况还是离不开caffe的)。剩下的三个框架，从速度，显存，性能以及代码丰富程度来看，各有各的优势。。就从我自己的几条主线来讲吧。

• Detectron 链接：https://github.com/facebookresearch/Detectron；
• maskrcnn-benchmark 链接：https://github.com/facebookresearch/maskrcnn-benchmark；
• mmdetection 链接：https://github.com/open-mmlab/mmdetection；
• detectron2 链接：https://github.com/facebookresearch/detectron2。

如果是做研究或者打比赛，那我推荐mmdetection。在这一年，商汤的检测可谓是大爆发，论文发到手软，其中很多篇还是很有意义的，开源框架火遍det圈，star数蹭蹭蹭往上长。在这个趋势下，越来越多做research的人认可了mmdetection，再加上商汤那边免费提供GPU来复现论文，可谓良心了，现在mmdetection是目前开源检测框架中包含论文数最多的，这也就给比赛带来了巨大的好处，基本搞搞数据集，就可以近零成本尝试各种各样的新鲜tricks。。因此也经常看到很多比赛的冠军方案都是基于mmdetection搞的，一些大厂垄断比赛冠军的时代一去不复返了。。。曾经我也参加了ICCV19的wider face比赛，处理了下数据集+数据增强+修bug+尝试各种tricks+模型融合，在val集取得不错的成绩(当然也可能是大佬们都没有把最好结果放出来，最终事实也是如此)，但是在比赛快结束时候，遇到很多不可抗因素(公司的服务器崩了>.<，再加上产品压力太大，最终比赛弃掉了，没有提交test榜。)

好像有点跑题了orz... 接下来说重点吧，如果做产品的话，推荐选择maskrcnn-benchmark。接下来就要从产品部署上讲下怎么选择，当然所有的部署都是要考虑需求和场景的。如果是在云端服务器上跑，对吞吐和延时要求都不高的话，几个框架没啥区别，反正就是跑跑demo玩玩。而如果在云端服务器上跑，同时对吞吐和延时要求都很高的话，这个时候就必须考虑用TensorRT或者TVM来加速inference，而这些框架目前又需要把Pytorch模型转成ONNX，这个转的过程可谓极其痛苦。推荐maskrcnn-benchmark主要原因是有很多不错的branch，踩点小坑就基本可以完成one stage/two stage/mask rcnn的onnx转换。而mmdetection目前相关branch较少，有的还需要大量修改代码，再加上mmdetection的读数据方式(img+img_meta)，而ONNX仅能读入img，这都给直接转换到ONNX带来了一些阻碍。。就在刚刚看mmdetection的issue时，看到了kai chen自己提的一个branch[onnx-export]， 不过目前更新较少，只能支持SSD。当然这些框架转ONNX的共同难点就是Pytorch的锅。目前Pytorch很多operator并不支持转ONNX，例如upsampling(当然固定上采样size也是可以转的)。。再接着上面的部署场景来说，如果在终端设备上跑(IOS, Android等手机)，成功转成ONNX仅仅是第一步，下面就得考虑如何进一步转成Caffe以及做模型量化等，最后再通过一些移动端深度学习框架来转，例如腾讯的ncnn, 阿里的MNN, 小米的mace, Facebook的QNNPACK等等。

• onnx-export 链接：https://github.com/hellock/mmdetection/tree/onnx-export ；
• ncnn 链接：https://github.com/Tencent/ncnn ；
• MNN 链接：https://github.com/alibaba/MNN ；
• mace 链接：https://github.com/XiaoMi/mace ；
• QNNPACK 链接：https://github.com/pytorch/QNNPACK ；

再说到模型量化这一步，上面的方案是Pytorch -- ONNX -- Caffe -- Quantization，而通过这个流程转的Caffe网络是没有反传过程的，因此不支持训练量化，所以量化采用的方案是post quantization，大致就是过一批图片，统计输入的范围，从而确定对输入的量化scale。然而这种方案在遇到小模型，尤其是MobileNetV1这种设计本身就有点小问题的网络，精度会大大损失(MobileNetV2做后处理量化感觉掉点没那么严重)。这个时候一般就采用16bit量化。。而如果你就是想让模型8bit量化甚至更低，怎么办呢？当然也有办法解决，但是更加复杂，对上面的这几个检测框架修改更多。可以采用谷歌CVPR18的论文Quantization and Training of Neural Networks for Efficient Integer-Arithmetic-Only Inference, 在训练时引入simulated quantization，采用浮点训练，但在训练的前向传播中模拟量化带来的损失，反向传播保持不变，这个方法普遍在一些小模型上能取得不错的收益，但是需要注意的是，前期不要对Activation做量化。

另外一篇极其类似的论文来自商汤CVPR19，Fully Quantized Network for Object Detection, 方法基本和谷歌这篇类似，任务变成检测了，文中提到的一些注意点确实也是检测这个任务特有的，只是希望作者能学学谷歌吧，这种工程论文不开源其实意义不大。个人觉得这种Training-Aware Quantization是未来做量化的一个趋势，而上面的这些检测框架想把这个加进去难度不小，尝试了下，然后放弃了。。。最终选择自己写一个RetinaNet检测框架，可以更加方便的转ONNX以及支持Training-Aware Quantization。。果然轮子还是自己造的香233333，因为在公司做的，目前不会考虑开源。

昨天刚有消息，Pytorch已经更新到了1.3，这个版本的最大的一个特点就是开始更加关注部署问题了，这也是Pytorch一直被产品诟病的原因。Detectron2也是伴随这次更新提到的，因此希望Detectron2更加偏向于模型部署吧，不然上面几个框架还真没啥本质区别。。另外值得一提的是Pytorch也出了eager模式的8bit量化，真香23333，看了下官方的API( 链接：https://pytorch.org/docs/master/quantization.html)，已经支持了大部分的量化op，包括simulated quantization。

最后总结下来，如果Detectron2可以做到对模型部署更友好，或者有计划把Pytorch1.3的FakeQuantization融合进去，建议大家可以放心食用23333……