我很长一段时间一直都在做自动驾驶的物体检测性能调优,所以想总结整理一些小网络和检测框架的经验。
文章会分成三个部分:
第一部分将参照知乎@YaqiLYU 对小网络(经典网络)的分析并且结合的自己的理解。
第二部分详细介绍目前state-of-art的主流检测框架。
第三部分介绍了目标检测的问题及解决方案,目标检测在其他领域的拓展应用
---------------------------------------------------------------------------------------------------------------------------
第一部分 经典小网络性能分析
---------------------------------------------------------------------------------------------
对于早期经典模型SqueezeNet, MobileNet(V1), 和CVPR 2018最新模型ShuffleNet, IGCV2, MobileNetV2, 探究短小精悍的秘密,学习设计理念和技术。
问题:
通过一张ncnn框架的高端ARM高通820和低端ARM海思3519硬件实测速度对比。ImageNet上的top-1准确率 vs 理论计算量 vs 模型大小的对比提出
1 MobileNetV2到底优化了什么,能做到比MobileNetV1既好又快?
2 为什么理论计算很高的SqueezeNet反而非常快?为什么ShuffleNet要比架构技术接近的MobileNetV1和MobileNetV2快那么多?
背景介绍:
首先介绍CNN中不同层的参数数量和理论计算量,简单起见小写代表下标,卷积核Kh*Kw,输入通道数Cin,输出通道数Cout,输出特征图的分辨率为宽H高W。
参数数量:用params表示,关系到模型大小,单位通常为M,通常参数用float32表示,所以模型大小是参数数量的4倍。
理论计算量:用FLOPs或者M-Adds表示,这里用FLOPs写起来简单,关系到算法速度,大模型的单位通常为G,小模型通道为M。注意两点:
- 理论计算量通常只考虑乘加操作(Multi-Adds)的数量,而且只考虑CONV和FC等参数层的计算量,忽略BatchNorm和PReLU等等。一般情况,CONV和FC层也会忽略仅纯加操作的计算量,如bias偏置加和shotcut残差加等,目前技术有BN的CNN可以不加bias。
- 理论计算量通常和实际ARM实测速度会有不一致,主要是理论计算量太过理论化,没有考虑不同硬件IO速度和计算力差异,最重要的是inference framework部署框架优化水平和程度差异,不同框架的优化的关注点不一样,同一框架对不同层的优化程度也不一样。Inference Framework以的ncnn为代表。
CONV标准卷积层:
- #params:
,没有bias为
- #FLOPs:
FC全连接层,卷积核k=1:
- #params:
,没有bias为
- #FLOPs:
*H*W
CONV和FC是经典CNN架构(如VGGNet和ResNet)中最重要的组件,CONV一般位于前面,作用类似特征提取,FC位于后面,作用类似分类决策。我们还需要两个卷积的变种。
首先在比较流行的高效卷积核(GCONV和DWCONV)上做个对比
GCONV分组(Group)卷积层,输入按通道数划分为g组,每小组独立分别卷积,结果联结到一起作为输出,如图中上面部分,Output channels作为GCONV的输入,分了3组分别CONV3x3,组内有信息流通,但不同分组之间没有信息流通。
- #params:
- #FLOPs:
(Xception版本)DWCONV深度分离(DepthWise)卷积层,是GCONV的极端情况,分组数量等于输入通道数量,即每个通道作为一个小组分别进行卷积,结果联结作为输出,Cin = Cout = g,没有bias项,如图中上面部分,Output channels作为DWCONV的输入,划分了输入通道数量相等的分组,通道之间完全没有信息流通。
- #params:
- #FLOPs:
- 注意:Xception的DW组织方式和MobileNet的设计稍微不同,这里会首先将1x1的卷积提到depthwise convolution之前。
综合对比:
- CONV层主要贡献了计算量,如VGGNet第二个CONV层贡献了1.85G的计算量,参数数量仅37k
- FC层主要贡献了参数数量,如VGGNet第一个FC层25088-4096就有接近98M参数,贡献模型大小392M,计算量仅103M
- GCONV和DWCONV层参数量和计算量都非常小,GCONV参数数量减少g倍,计算量降低g倍,g越大压缩加速越明显;DWCONV是g=Cin的极端情况,压缩加速比是Cin倍,如MobileNet中第一个DWCONV层参数数量不到0.3k,计算量仅3.2M,这两者是高效CNN的核心构成要素。
Block分析:设计CNN目前都采用堆block的方式,后面对每个模型只集中分析其block的设计。堆Block简化了网络设计问题:只要设计好block结构,对于典型224x224输入,设计CNN只需要考虑112x112、56x56、28x28、14x14、7x7 这5个分辨率阶段(stage)的block数量和通道数量就可以了。
CNN加深度一般都选择14x14这个分辨率阶段,多堆几个block,这一层的参数数量和计算量占比最大,所以我们选这一层作为特例分析每种block的参数数量和计算量,量化说明选择14x14x该层通道数的输入和输出情况。
传统网络分析:
NIN(net in network)
最早的的小网络要从Network in Network说起,NiN是Shuicheng Yan组ICLR 2014的论文,提出在CONV3x3中插入CONV1x1层,和Global Average Pooling (GAP)层,虽然论文并没有强调这两个组件对减小CNN体积的作用,但它们确实成为CNN压缩加速的核心:
- 同等输入CONV1x1比CONV3x3参数数量少9倍,理论计算量降低9倍(可以去看1*1卷积核对于减少参数量的作用,升维,降维,跨通道的信息融合等等)
- GAP层没有参数,计算量可以忽略不计,是压缩模型的关键技术
GoogLeNet
就大量使用层和GAP,与同时期性能相近的VGG-19相比,22层GoogLeNet模型参数少20倍以上,速度快10倍以上。GoogLeNet是最早的高效小网络,Inception系列沿袭这一架构理念,在均衡网络深度和模型大小方面都比较优秀。
(提问:截止2018.5.27,VGGNet论文的引用量是11499,GoogLeNet的应用量是7440次,同一时期的两个经典结构,看起来明显更好的GoogLeNet影响力为何反而不如VGGNet?早期检测、跟踪和分割等方向的经典方法,如SSD, C-COT, FCN,骨架网络BackBone默认都是VGGNet,为什么都没有选更小更快的GoogLeNet?)
(模型的推理速度也就是计算量其实不仅仅和参数量有关,计算次数,还和MAC内存带宽的交互,以及GPU的底层支持的友好程度都相关,再其次更深的网络在imagenet上的训练效果会更好一些)
Resnet:
除了conv1*1 和GAP,ResNet还采用了另一项常用技术:
- 用CONV/s2(步进2的卷积)代替CONV+MaxPool,将Pool层合并到上一个CONV层,近似减少一半参数数量和计算量
综合以上技术,即使152层的ResNet,也比VGGNet小7倍,快12倍以上。目标检测的YOLO系列中,YOLOv2中提出的DarkNet-19采用了CONV1x1和GAP设计,YOLOv3的DarkNet-53加入了CONV/s2设计,两个CNN都是以上压缩加速技术的实例。
SqueezeNet
论文非常的标题党:同等精度比AlexNet小50倍,<0.5M的模型大小。SqueezeNet的核心设计理念是模型可以不快但一定要小,分析三个设计策略:
- 用CONV1x1代替CONV3x3,大量CONV3x3被替换,大幅减少参数和计算量
- 用squeeze层减少输入到CONV3x3的通道数,继续减少剩余CONV3x3层的参数数量和计算量
- 延迟下采样,保持激活的分辨率较大,同等参数数量效果更好,但这样会严重增加计算量
此外,保证conv10的通道数是1000,这样GAP后直接是1000个输出,这样连接到输出的最后一个FC层也省了,仅0.5M参数就完成了收尾部分,简直丧心病狂,但这种做法非常低效,仅conv10这一层的计算量就有100M。
SqueezeNet共8个Fire Module,2个CONV和4个POOL,没有BN,最终模型4.8M,在ImageNet上top-1 acc 57.5%, top-5 acc 80.3%,性能是AlexNet水平,经过DeepCompression进一步压缩后模型大小可以达到逆天的0.47M,但DeepCompression方法也是仅关心压缩不关心加速的。最后实验还测试了shotcut,证明类似ResNet那样最简单的shotcut最好,top-1和top-5分别提升2.9%和2.2%,性能提升明显且不会增加参数数量,几乎不会影响计算量 (ResNet赛高)
论文描述的模型是SqueezeNet v1.0,后来代码又更新了SqueezeNet v1.1,模型大小和性能不变的情况下快了2.4倍:
主要修改了第一层的卷积核大小和通道数,把下采样提前了,即抛弃了策略3。
SqueezeNet的计算量在MobileNet论文中是1700M,在ShuffleNet论文中是833,根据最新论文结果,SqueezeNet v1.0的理论计算量是837M,SqueezeNet v1.1的理论计算量是352M,ncnn-benchmark中所用测试模型就是SqueezeNet v1.1,所以在benchmark中SqueezeNet确实应该比MobileNet和AlexNet快。
stage的通道数量:【128 256 384-512 0】
stage的block数量:【2 2 4 0】
Block分析:加shotcut的一个典型SqueezeNet block,即论文中的Fire module
- #params:
- #FLOPs:
- (C*C/8*1*1 + C/8*C/2*3*3 + C/8 * C/2 * 1*1 ) = 3/4 * C^2
第一个CONV1x1将输入通道数压缩(squeeze)到1/8送给CONV3x3,上下两路CONV扩展(expand)四倍后联结,还原输入通道数量。block中CONV1x1和CONV3x3的参数数量之比是1:3,计算量之比也是1:3。
SqueezeNet中虽然大量使用CONV1x1,但CONV3x3占比依然在75%以上,inferece framework中CONV3x3的优化对速度影响更大。
在part2 中会介绍作者最新的SqueezeDet
MobileNet
MobileNet是第一个面向移动端的小网络,设计兼顾模型小和速度快,提出了Depthwise Separable Convolution深度分离卷积,由DWCONV3x3 + CONV1x1组成,DWCONV3x3将CONV3x3的计算量降低到恐怖程度,后面的CONV1x1帮助信息在通道之间流通。这种结构非常高效,代替CONV后性能微小下降换取速度数倍提升。
MobileNet参数数量4.2M,计算量569M,top-1 70.6%,性能是GoogLeNet和VGG16水平,比最庞大的VGG16模型小32倍,计算量低27倍,比设计高效的GoogLeNet模型更小,计算量低2.5倍。
第一层是CONV,之后堆叠DWCONV3x3 + CONV1x1, 每层都加BN没有shotcut,DWCONV/S2方式下采样,GAP后连FC到1000个分类输出,仅这个1024-1000的FC层就有1M参数。
论文提供了两个用户定制参数:
- Width Multiplier宽度乘子:所有层的通道数乘
,即CNN变瘦,模型大小近似下降
倍,计算量下降
倍
- Resolution Multiplier分辨率乘子:输入分辨率乘
,等价于所有层的分辨率乘
,模型大小不变,计算量下降
倍
减少网络的层数也可以减少模型大小和计算量,即CNN变浅,实验给出同等参数和计算量,变浅比边瘦性能要差很多,强烈建议不要减深度!
(提问:很多论文都证明,同等参数和计算量,深度模型比宽度模型更好,深度也是一种正则方式?)
论文统计了不同类型层的计算量和参数数量,仅一个CONV一个FC,计算量可以忽略,前面也提到FC层参数占比较大,重点关注,大量使用的DWCONV33计算量仅3%,参数数量仅1%,其貌不扬的CONV1x1竟然是罪魁祸首,CONV1x1计算量占95%,参数数量占75%,所以MobileNet速度快不快,与inferece framework中CONV1x1的优化程度密切相关(其实是因为depthwise的3*3卷积只计算一次,而pointwise层会疯狂的计算Cout次和sequeezenet 不同,seq虽然1*1卷积核很多,但本质还是由于3*3与1*1的占比所导致)。
Block分析:MobileNet虽然没有明确指出,Depthwise Separable Convolution也可以看做block
- #params:
- #FLOPs:
DWCONV3x3以极低代价卷积产生特征,CONV1x1辅助通道信息流通,两者完美配合。block中CONV1x1和DWCONV3x3的计算量、参数数量比例是C:9,以疯狂加深度层14x14x512为例,二者比例是512:9=56.89,依然很震惊有木有,SqueezeNet中核心压缩加速手段CONV1x1,在MobileNet中反倒成了开销大户。
进一步优化MobileNet,降低CONV1x1的占比是关键,在mobilenetV2中针对于conv1*1的占比进行了优化。
DWCONV-bottleneck block
MobileNet的结构是类似VGGNet的直筒形式,目前ResNet已经取代了VGGNet,我们是不是按照ResNet中比较高效的bottleneck block构建更先进的DWCONV-bottleneck block呢?当然很简单,按照ResNet论文,CONV3x3换成DWCONV3x3就完成了。
- #params:
- #FLOPs:
ResNet代替VGGNet的历史告诉我们,这样做一定比MobileNet更好,要试一试吗?别着急,仔细看参数数量和计算量都增加了数倍(约8倍),block中CONV1x1和DWCONV3x3的计算量、参数数量比例是8C:9,还是以深度层14x14x512为例,二者比例高达8*512:9=455.11,再次震惊,这样做性能是上去了,但模型大小和速度都严重下降了,对于移动端这是我们最不愿看到的结果。
ShuffleNet
继MobileNet挂出来之后三个月,旷世科技挂出了ShuffleNet:解决了DWCONV-bottleneck block中CONV1x1占比高、计算量大的问题;但是并没有开源代码。
类似DWCONV-bottleneck block中DWCONV3x3代替CONV3x3,其中的CONV1x1是标准卷积,这部分是否也能通过分组卷积或深度分离卷积来加速压缩呢?ShuffleNet第一步就是把block中的CONV1x1变成了分组卷积GCONV1x1降低计算量和参数数量,按照分组数量(g=2,3,4,8)加速g倍。但这带来一个很严重的问题,通道之间信息不能流通:DWCONV3x3没有通道间信息流通,而GCONV1x1信息只在分组内部流通,会严重影响性能。ShuffleNet给出解决方案,就是题目中'Shuffle'代表的Channel Shuffle操作,交错重排,混叠通道以辅助(强制)信息流通。
从理论计算量的公式可以看出,feature map的分辨率对计算量影响非常大,所以一般CNN结构都有输入图像快速降维模块,常用CONV3x3s2+CONV3x3s2阶梯降维,或CONV7x7s2 + MaxPools2,实现输入图像快速降维4倍。在ShuffleNet中采用了非常非常激进的CONV3x3s2 + MaxPools2结构,虽然这样参数更少速度更快,但CONV3x3的感受野不足以支撑4倍降维,会造成信息丢失(猜测这可能是ShuffleNet难以复现的原因之一)。
ShuffleNet发现深度分离卷积虽然参数数量和计算量都很低,但与其他密集操作相比计算/内存访问比很差,在实际硬件上较难优化,所以采用了大量GCONV1x1加少量DWCONV3x3的设计方式,后面MobileNetV2中会看到截然不同的处理方式。
分组数量g越大,对应压缩加速比率越大,论文增加通道数量以保持不同g设置的计算量接近,公平对比性能;用户定制参数仅通道乘子s,压缩加速 倍。常用两个版本是ShuffleNetx1g8和ShuffleNetx2g3:
- ShuffleNetx1g8版本参数数量1.4M(?),计算量140M,top-1 67.6%,优于0.5-MobileNet-224,仅比GoogLeNet低1.1%但快10倍以上
- ShuffleNetx2g3版本(2**2=4,大约是x1g8的4倍) 参数数量5.4M,计算量524M,top-1 73.7%,优于1.0MobileNet-224,计算量低45M,性能超出3.1%
- ShuffleNet还尝试了最新技术,与同为CVPR 2018 SENet中的SE modules结合,在几乎不影响理论计算量的同时能大幅提升性能,但,实测在移动设备上减速了25%~40%,这就很可怕了
(提问:还有哪些类似SE的“黑科技”,能在基本保持理论计算量不变的情况下能大幅提升性能,表面上看起来非常“便宜”,但实际上大幅降低了部署速度)
ncnn-benchmark中ShuffleNet是x1g8版本,理论计算量140,当然比理论计算量352M的SqueezeNet v1.1和理论计算量569M的MobileNet更快。
为保持公平比较,接下来分析x2g3版本:
每个stage的通道数量:【0 480 960 1920】
每个stage的block数量:【0 4 8 4】
Block分析:shuffle block即论文中的ShuffleNet Unit,非stride=2版本
- #params:
- #FLOPs:
block中CONV1x1和DWCONV3x3的计算量、参数数量比例是8/3C:9,以深度层14x14x960 (c=240)为例,二者比例8/3*240:9=71.11,比DWCONV-bottleneck block中的455.11,GCONV1x1依然是主力但占比已经降低很多很多了。与MobileNet相比,DWCONV3x3的通道数少了很多(猜测是难以复现的原因之二),但GCONV1x1通道数多了很多,所以上面4C-C-C4的通道数表示不一定客观。
其他需要注意的:ShuffleNet Unit中,仅第一个GCONV1x1后面加了Channel Shuffle,DWCONV3x3后面没有ReLU,stride=2版本用联结输入AVGPools2的方式实现通道翻倍。
(HELP:有能完美复现CVPR版本ShuffleNet论文结果的同学,欢迎慷慨分享你的模型和训练方式,功德无量!)
IGCV2
看到这个很多同学第一时间都会想:这个和Channel Shuffle好像啊,而且是今年4月才挂出来。。其核心部分的交错分组卷积Interleaved Group Convolutions发表在ICCV 2017,所以是ShuffleNet同时期的工作(或更早)。交错分组卷积IGC,把CONV1x1变成分组卷积,然后加上交错重排操作Permutation,作用类似Channel Shuffle。
IGCV2在MobileNet的基础上改进,两个GCONV1x1中间加Permutation,分组数量g=8,每层的通道数量都翻倍,这样参数数量和计算量都基本保持不变(更胖)。IGCV2和MobileNet对比,1.0版本的参数、计算量和性能都非常相似,但0.5和0.25版本IGCV2优势非常明显。
每个stage的通道数量:【256 512 1024 2048】
每个stage的block数量:【2 2 6 2】
Block分析:IGCV2 block,类似MobileNet没有加shotcut
- #params:
- #FLOPs:
block中CONV1x1和DWCONV3x3的计算量、参数数量比例是1/4C:9,以深度层14x14x1024为例,二者比例1/4*1024:9=28.44,比MobileNet block中的56.89的占比降低。网络设计方面,IGCV2只在MobileNet的基础上改进,验证了IGC的可行性,没有太大的结构变动。
MobileNetV2
降低DWCONV-bottleneck block中CONV1x1的占比,除了ShuffleNet和IGCV2用GCONV+shuffle/permutation方法,还有其他好办法吗?MobileNet采用了两种新技术来解决这个问题,按照论文来说:
- Inverted Residuals 逆残差:把原来两头大中间小的bottleneck block变成两头小中间大的形式,强行降低了CONV1x1与DWCONV3x3的比例,这里有个超参数expansion factor扩展因子t,推荐是5~10,参数设置小网络小一点,大网络大一点,V2中是t=6。
- Linear Bottlenecks 线性瓶颈:去掉了第二个CONV1x1后面的ReLU,改为线性神经元,其实就是没有非线性激活函数,论文解释是在低维度空间ReLU会破坏信息。
没有分组卷积,那MobileNetV2到底优化了什么?观察网络发现,bottleneck的输出通道数非常小[24 32 64-96 160-320],这在以前的结构中容量是远远不够的。再来看经expand layer扩展以后的DWCONV3x3层,baseline版本通道数是[144 192 384-576 960-1920],比较接近ShuffleNetx2的配置,略高于V1,从这个角度来看,MobileNetV2设计上是保持DWCONV3x3层通道数基本不变或轻微增加,将bottleneck的输入和输出通道数直接减小t倍,扩展因子其实更像是压缩因子,将CONV1x1层的参数数量和计算量直接减小t倍,轻微增加DWCONV3x3的通道数以保证的网络容量。ShuffleNet中标准卷积更多、深度分离卷积更少的优化思路完全相反,MobileNetV2中标准卷积更少、深度分离卷积更多(相对的,计算量占比CONV1x1依然绝对优势)。
- baseline版本MobileNetV2,参数数量3.4M,计算量300M,top-1 72%,这个理论计算量与SqueezeNet是同一等级,比MobileNetV1更好更小更快
- MobileNetV2-1.4版本(1.4**2=1.96,大约是baseline的2倍)参数数量6.9M,计算量585M,top-1 74.7%,这个计算量与1.0-MobileNet-224和ShuffleNetx2g3同一等级,性能超过ShuffleNet 1%
- 甚至超过了NASNet,是目前最好的高效小网络结构,更重要的是开源了模型和代码,github上有各个平台的模型复现
(温馨提示:由于论文arXiv第一版有几处笔误,导致之前github上复现的模型结构都或多或少有错误,请仔细对照tensorflow官方代码和模型结构。比如:
发现第一个t=1的bottleneck结构实际上是dwconv3x3-conv1x1,没有前面expansion layer的conv1x1,对照代码验证确实如此)
结构方面,每个bottleneck里面两个ReLU6,方便量化;输入图像以s2方式逐阶平滑降维;用户定制依然是宽度乘子和分辨率乘子,同MobileNetV1;通道数量分布前期少后期多,在14x14和7x7阶段通道数量额外增加了一次,分别上升50%和100%。
ncnn-benchmark中MobileNetV2是caffe复现的baseline,但由于标准卷积比深度分离卷积优化更好,且CONV3x3比CONV1x1优化更好,导致部分ARM上MobileNetV2与MobileNet速度接近,但性能差距还是存在的,期待进一步优化后能接近SqueezeNetv1.1速度。
每个stage的通道数量:【24 32 64-96 160-320】*6
每个stage的block数量:【2 3 7 4】
Block分析:MobileNetV2 block,类似MobileNet没有加shotcut
- #params:
- #FLOPs:
block中CONV1x1和DWCONV3x3的计算量、参数数量比例是C:27,以深度层14x14x64(C=384)或14x14x96(C=576)为例,二者比例为14.22或21.33 ,这个占比是目前最低的,所以MobileNetV2是目前能看到的最好的小网络结构。
IGCV3
MobileNetV2中直接压缩CONV1x1的方法与前面GCONV+Shuffle/Permutation的方法能否结合优化呢?IGCV3在MobileNetV2的基础上改进,block中两个GCONV1x1后面都加了Permutation,分组数量g=2,通道数量保持不变,但深度大幅增加,多了15个block(更高)。
1.0和1.4版本IGCV3都比同样条件复现的MobileNetV2分别高了接近0.9%和0.8%,但如果与论文中MobileNetV2结果相比,优势就不明显了。消融实验表明,同等参数,加深度版本的性能比加宽度版本更好(同等质量,高比胖要好。。恍然大悟),block中仅在DWCONV3x3后面加ReLU更好。
每个stage的通道数量:【24 32 64-96 160-320】
每个stage的block数量:【4 6 14 7】
block分析略,g=2的block非常相似,主要变化是增加了深度。
SqueezeNext
DWCONV这种压缩加速“大杀器”在某些移动设备上很难优化,并不总是像理论上那么高效,SqueezeNext延续SqueezeNet模型小的优良传统,但这次更加注重硬件部署速度,采用两级sqeeze+分解CONV3x3的方式压缩加速,两级CONV1x1压缩输入通道数,类似Inception-v3将CONV3x3分解为CONV3x1和CONV1x3,加了ResNet类型的shotcut(避开了DenseNet类型连接,会增加通道数和需要费时耗能的联结激活)。最后通过硬件模拟找到瓶颈,优化调整网络结构。
硬件模拟的结果很有参考价值:降维模块中CONV7x7的计算量占比非常高,即使改成了5x5后总计算量仍然比14x14这一深度层14个block的总计算量还高;分组卷积可以进一步减少模型参数,但会损失性能;同样21个block,不同分布[6 6 8 1], [4 8 8 1], [2 10 8 1], [2 4 14 1]计算量和参数数量非常接近,实验结果表明[2 4 14 1]这种在14x14深度层加block的方式性能最好、更快更节能,符合以前所有模型的设计趋势(加深度层名副其实,我不是乱叫的)。
(提问:DWCONV已证明确实是不好优化,但非对称卷积CONV1x3和CONV3x1就很好优化吗?)
- 最小版本1.0-G-SqNxt-23是23个block,CONV1x1加分组卷积优化的结构,仅0.54M参数,top-1 56.88%, top-5 80.83%,接近AlexNet水平,这次比 AlexNet小112倍(上一版SqueezeNet小51倍)
- baseline版本1.0-SqNxt-23v5仅0.94M参数,228M计算量,top-1 59.24%,比AlexNet高2%,比SqueezeNetv1.1更好更小更快
- 加宽版本2.0-SqNxt-23v5是3.23M参数,708M计算量,top-1 67.44%,接近复现版本的MobileNet(论文模型是70.6%),模型小1M但优势不明显。
每个stage的通道数量:【32 64 128 256】
每个stage的block数量:【2 4 14 1】
Block分析:
- #params:
- #FLOPs:
block中CONV1x1和CONV3x1+CONV1x3的计算量、参数数量比例是1:1。总体上,通道数较少,体积小是优势,但性能水平不高,且部署速度还需要良好优化的CONV3x1和CONV1x3支撑。
未完待续--