先讲一个真实的工作场景某项目需要在低算力的嵌入式设备上部署一个图像分类模型一开始直接搬了标准卷积网络帧率惨不忍睹。后来负责人说换成MobileNet试试果真快了不少但奇怪的是测出来的FLOPs降了接近一个数量级帧率却只提升了两三倍。并不是MobileNet不香而是“FLOPs下降”和“端到端延迟下降”之间隔着内存访问、算子调度、并行粒度这一大堆工程问题。这件事让我后来养成了一个习惯聊轻量模型不能只看FLOPs表得把结构设计和真实部署环境放在一起看。这篇文章就把MobileNet及其变体重点带上ShuffleNet为什么会变快、在什么条件下会失效讲透。适合正在做模型轻量化、端侧部署、边缘设备推理的开发者也适合面试前想系统梳理轻量网络设计逻辑的朋友。1. 从FLOPs说起MobileNet到底把计算量省在了哪里要理解MobileNet为什么快得先看它动刀的地方标准卷积的计算方式。这个基础如果不清楚后面看V1、V2、V3的改动都会觉得是在记公式而不是理解设计意图。1.1 标准卷积到底有多贵假设输入特征图是 H×W×C输出特征图是 H′×W′×N卷积核大小是 K×K。标准卷积的计算量大约是K × K × C × N × H′ × W′这个式子的含义很直白输出特征图上的每一个点都要用一个 K×K 的卷积核在输入的所有 C 个通道上做滑窗乘加。所以计算量是“卷积核的空间尺寸 × 输入通道数 × 输出通道数 × 输出特征图大小”四者的乘积。问题出在“输入通道数 × 输出通道数”这一项。假设 C 和 N 都是256K3那么一个3×3卷积就要做 3×3×256×256也就是约59万次乘加输出特征图上每个点都要来一遍。通道数一上去计算量直接失控。1.2 深度可分离卷积把一个卷积拆成两次MobileNetV1的核心改动是把标准卷积拆成两步深度卷积Depthwise Convolution简称DW卷积和逐点卷积Pointwise Convolution简称PW卷积本质是1×1卷积。第一步深度卷积每个通道单独用一个 K×K 卷积核做卷积。也就是说输入有多少个通道就用多少个卷积核每个卷积核只管一个通道。这一步的计算量是K × K × C × H′ × W′注意这里没有“输出通道数 N”这一项。第二步逐点卷积用 1×1 卷积把前面得到的特征图在通道维度上融合输出 N 个通道。计算量是C × N × H′ × W′两步加起来K × K × C × H′ × W′ C × N × H′ × W′对比标准卷积 K×K×C×N×H′×W′计算量比值大约是1/N 1/K²当 N256、K3 时这个比值大概是 1/256 1/9约等于 0.115。也就是说深度可分离卷积只需要标准卷积大约九分之一到十分之一的计算量。我最早看这个公式时觉得没什么等到真的在设备上跑起来才发现计算量少了确实直接反映在能耗和发热上。同样的任务用标准卷积跑到后面设备烫手换成MobileNet之后温度明显降下来。对于用电池的设备来说这比单纯看延迟数字还重要。1.3 两组超参宽度乘子与分辨率乘子MobileNetV1还引入了两个可调超参数用来进一步缩放模型宽度乘子 α作用于通道数。输入通道变成 αC输出通道变成 αN。计算量会变成原来的 α² 倍。分辨率乘子 ρ作用于输入图像分辨率特征图尺寸同步变化。计算量会变成原来的 ρ² 倍。这两个超参的意义在于MobileNet能给出一组“精度—计算量”的取舍曲线方便在具体硬件上做适配。实际使用中α 的取值在0.25到1.0之间比较常见低于0.25时精度掉得很快因为通道数太少了特征表达空间被压缩到极限。ρ 则一般取整数缩放比如224、192、160、128很少做非整数缩放因为底层图像缩放库对非标准尺寸支持不一定好。1.4 FLOPs下降带来的直接效果从纯理论角度MobileNetV1的FLOPs比同分辨率下的标准卷积网络少一个量级左右。如果只看FLOPs会得出一个结论推理速度应该提升接近10倍。但真实设备上测通常只能感受到2到5倍的加速。原因是FLOPs只统计了乘加运算量没有统计内存搬运、数据读写、算子调度、分支跳转这些开销。一个极端的例子是1×1卷积它的FLOPs看起来不高但如果特征图很大逐点卷积的数据搬运量非常大跑起来并不像FLOPs数字那么轻松。所以把MobileNet理解成“降低了理论乘加量”比“提升了实际速度”更准确。2. MobileNet变体演进V1、V2、V3各自动了哪些手术MobileNet不是一个单独模型而是一个家族。V1到V3每一代都在改结构设计ShuffleNet又是另一条思路。把它们放在一起看才能明白轻量网络设计的主流套路。2.1 V1把“拆分”做到极致V1的贡献不只是在算法上把标准卷积拆成DW和PW更重要的是它提出了一种可复用的设计模式第一层仍然用标准卷积因为输入通道数只有3用DW卷积反而省不了多少从第二层开始全部用深度可分离卷积块。每个块后面接BN和ReLU。V1的结构本身不复杂但它确立了一个原则在轻量模型里3×3卷积不再是“标配”而是要拆开用的。这个思想后来被几乎所有轻量模型继承。2.2 V2线性瓶颈与倒残差结构V1存在一个明显问题DW卷积的参数和计算量虽然少但可学习的表达能力也弱了直接堆叠效果不好。V2针对这个问题做了两个关键改动。第一个改动是线性瓶颈。V2在DW卷积之前先做一个1×1卷积把通道数扩展开然后在block的最后一层1×1卷积之后不再接ReLU而是直接输出。原因是ReLU在低维空间会造成信息丢失而在高维空间这种丢失会减弱。简单说先升维再ReLU最后降维输出时不加激活函数避免把信息压掉。第二个改动是倒残差结构。传统残差结构是“先降维再升维”倒残差是“先升维再降维”。这个顺序看着违反直觉但在轻量模型里很合理因为DW卷积本身表达能力弱需要更多通道提供冗余信息。我在实际项目中对比过V1和V2的同一部署平台表现V2在ImageNet分类精度上明显高于V1推理耗时只增加了一点点。这说明V2的改动花得值。2.3 V3工具链升级搜出来的结构V3不是纯手工设计而是用了神经网络结构搜索技术在V2的基础上做了几件事激活函数方面引入了swish激活函数考虑到移动端计算sigmoid开销大又改成h-swish用ReLU6拼接来近似。注意力方面在部分block里加入了SE模块也就是通道注意力用少量额外计算换取精度提升。结构搜索方面用NAS搜索出每个block的通道数和是否使用SE模块。整体结构不再是一层层均匀堆叠而是呈现出两头大、中间窄的形态。V3的实测特点是在同精度目标下延迟比V2进一步降低。但它对推理框架的算子支持要求更高SE模块和h-swish在早期推理框架上可能没有优化实现直接部署反而会变慢。这也是一个典型的结构先进性和工程落地之间的冲突。2.4 ShuffleNet分组卷积与通道混洗ShuffleNet走了另一条路不拆卷积而是把标准卷积变成分组卷积然后通过通道混洗解决组间信息不流通的问题。分组卷积就是把输入通道分成多个组每个组各自做卷积。好处是计算量直接除以组数但坏处是组与组之间没有信息交流精度会明显下降。ShuffleNet的做法是在每个分组卷积之前把通道重新排列打散让每个组都能看到前一个组的部分通道。ShuffleNetV2还提出了一个非常实用的设计原则不能只看FLOPs还要考虑内存访问成本。论文里给出了一条著名结论FLOPs相同的情况下模型不一定有相同速度因为内存访问成本不同。基于这个原则ShuffleNetV2做了几个结构决策比如输入输出通道保持相同、分组数不宜过多、避免碎片化操作、减少逐元素运算。这条原则含金量很高。我第一次读到ShuffleNetV2时印象最深的不是某个block结构而是它把“内存访问成本”这个工程指标正式引入到网络设计评价体系里。从那以后我自己再做结构选型都会同时估算FLOPs和内存访问量两个指标。3. 模型变快背后的真实代价延迟并不等于FLOPs这一章是全文的骨架。很多人把MobileNet理解成“低FLOPs 低延迟”这是错的。FLOPs只是理论计算量端到端延迟还要看内存、并行、算子、访存带宽这些硬件维度。3.1 内存访问成本为什么致命ShuffleNetV2提到过内存访问成本可以用一个公式估算MAC h × w × c_in h × w × c_out k × k × c_in × c_out这个公式的含义是读输入特征图需要搬一次数据写输出特征图需要搬一次数据读卷积核参数也需要搬一次数据。搬运时间在真实硬件上不可忽略。举个例子一个 56×56×256 的中间特征图如果是float32每个特征图大约有 56×56×256×4 字节也就是约3.2MB。在内存带宽有限的设备上读一次、写一次就是6.4MB的搬运量。MobileNetV1整体结构虽然FLOPs低但中间特征图的分辨率和通道数并不小内存搬运开销一直存在。深度可分离卷积还有一个隐藏问题DW卷积的每个通道都是独立卷积计算密度非常低。在CPU上这意味着要频繁地从内存取数据但每次取完数据只做很少的乘加运算容易造成访存瓶颈。我做过一个简单的测量对比同一设备上纯3×3标准卷积的算力利用率能做到60%到70%但深度可分离卷积里的DW卷积部分算力利用率经常只有20%到30%。不是CPU不行而是DW卷积本身太“散”了访存比例过高。3.2 并行度与GPU效率GPU是为大规模并行计算设计的它喜欢的是“很多线程同时做同样的计算”。标准卷积恰好是这种形态同一个卷积核应用到所有空间位置和通道并行度极高。深度可分离卷积在GPU上却不那么友好。DW卷积的每个通道是独立的计算量不大但并行任务的数量取决于通道数。如果通道数不够多GPU的很多计算单元会闲置。1×1卷积倒是并行友好但整个网络里频繁的大数据量读入写出也让GPU的向量化优势打了折扣。这也是为什么MobileNet在CPU和嵌入式设备上收益明显但在高端GPU上有时反而跑不过一个优化良好的标准ResNetGPU对FLOPs的耐受度远高于CPU但访存和共享内存带宽的瓶颈并没有消失。3.3 算子碎片化与推理引擎适配MobileNetV1和V2的落地相对顺利因为结构规整主要就是DW、PW、BN、ReLU几种算子。V3加入SE模块后结构开始碎片化有全局池化、有全连接、有逐元素乘法、有h-swish。ShuffleNet的通道混洗需要专门的算子支持。推理框架对算子的支持程度决定了实际速度。很多框架对3×3或1×1卷积优化得很到位但对DW卷积或通道混洗可能走的是通用算子路径效率差得不是一点半点。部署前如果发现模型里的某个算子在小批量下耗时占比异常高多半就是这个算子没有针对性优化。另外一个因素是算子融合。手工设计网络时经常有“卷积—BN—ReLU”三段推理阶段可以把这三段融合成一个算子省掉中间特征图的读写。MobileNetV2的倒残差结构里BN和ReLU的位置比较规整融合起来容易。但V3里h-swish夹在卷积之间融合链路变长反而更容易出现中间缓存反复读写的场景。3.4 量化友好度的差异轻量模型在端侧部署基本都要做量化把float32模型转成int8。MobileNet的量化友好度其实一般原因是DW卷积的数值分布和标准卷积不完全一样。DW卷积每个通道只有一个卷积核输入通道和输出通道一一对应批量归一化后不同通道的数值分布差异可能很大。int8量化通常用的是逐张量的统一缩放因子遇到数值分布差异大的通道量化误差就会放大。实际踩坑经验一个MobileNetV2模型在float32下的精度损失不大但int8量化后精度下降比标准卷积网络更明显。解决办法之一是做逐通道量化让每个通道有自己的缩放因子。另一个办法是量化感知训练在训练阶段模拟量化误差让模型自适应。所以MobileNet变快了但“快”是有条件的它需要推理框架成熟、算子融合到位、量化策略合适。如果这三个条件不满足理论上少的FLOPs根本换不来实际速度。4. 什么时候受限MobileNet类结构不适用的典型场景了解了延迟不等于FLOPs之后就能解释为什么有些场景下MobileNet类结构会失效。以下四种情况是我在实际工作中比较常见的。4.1 高算力GPU上的收益变小部署目标如果是A100这种级别的GPU且批量较大MobileNet的优势会被大幅削弱。原因前面说过GPU不喜欢碎片化的卷积和频繁的访存而MobileNet恰恰在这两个维度上“牺牲”得比较多。高算力场景下标准卷积的算力利用率很高3×3卷积在GPU上有极成熟的高性能实现。相比之下Deep可分离卷积反而难以打满算力。再加上高端GPU的内存带宽远高于CPUMobileNet最引以为傲的“低FLOPs”优势在高吞吐任务里完全体现不出来。如果你的目标是最大化GPU吞吐MobileNet不是首选。高算力平台上更合适的是标准卷积配合剪枝或蒸馏而不是直接换轻量网络。4.2 实时性要求极高且批处理大的场合实时视频流处理场景比如视频结构化分析要求单帧延迟极低。MobileNet的延迟比标准卷积低但它每一层的特征图尺寸都很大中间层的访存时间会形成一个“地板”。在大批量场景GPU可以利用批量维度做并行优化把一次访存服务多个样本的收益放大。MobileNet设计时主要考虑的是单样本低延迟批量维度利用率天然不如标准卷积。实际测试中batch size增大到一定程度后MobileNet每样本耗时下降的比例可能低于标准卷积因为它的瓶颈已经从计算转移到了访存。4.3 精度敏感型任务轻量网络做分类、检测、分割都有对应版本但精度上限是它们绕不过去的坎。尤其在高精度目标检测或语义分割任务里MobileNet作为骨干网络提取语义信息的能力比不过强大的标准卷积骨干。这一点在特征金字塔结构里特别明显。MobileNet的浅层特征图分辨率较高但通道数少语义信息不足。如果检测头需要多尺度特征融合浅层特征的容量会成为瓶颈。我也试过用MobileNet做超分任务效果比标准残差网络差了不止一截。原因不复杂超分需要保留高频细节但MobileNet的深度可分离卷积相当于对空间信息做了一次“压缩”高频细节在低维空间里很难保住。4.4 内存带宽成为瓶颈的浅层网络一个容易被忽略的场景是网络层数很浅、输入分辨率很高时MobileNet的收益会显著下降。因为浅层网络里前几层的特征图尺寸特别大内存访问成本占比很高FLOPs优势被访存开销稀释了。比如直接拿MobileNetV1的第一层标准卷积做高分辨率输入比如512×512这层的输出特征图大概是512×512×32每个特征图约32MB输入输出搬运就有64MB左右的访问量。相比之下这层的FLOPs并不高。极端情况下推理时间可能主要花在读写特征图上计算单元反而在等待数据。遇到这种场景不能简单堆MobileNet而是要考虑裁剪输入分辨率、减少初始通道数或者用下采样尽早缩小特征图尺寸。5. 实操经验与常见问题排查技术文章讲完原理最后还是回到实操。这一章写一些部署和评估MobileNet类模型时的经验包括踩过的坑和排查思路。5.1 部署MobileNet时最容易踩的坑第一个坑是把FLOPs当延迟预算。选型阶段看FLOPs没问题但定了模型之后一定要上真机实测延迟。同一个MobileNetV3在不同推理框架上的耗时差距可能达到两倍以上因为SE模块和h-swish的算子支持程度完全不同。第二个坑是忽略BN融合。很多框架在推理时会自动把BN融合进卷积层但如果你手工部署或者使用自定义算子BN没有融合的话中间特征图要多读写一次速度立刻掉下来。建议在训练导出时直接做BN折叠保证部署图里没有BN节点。第三个坑是动态形状输入。推理框架为了性能通常会对固定形状做图优化比如算子融合、内存复用。如果输入尺寸每次都变框架只能退回到通用路径性能会下降很多。边缘设备部署时尽量resize到固定尺寸。第四个坑是int8量化后精度崩了。前面说过MobileNet对量化不友好建议用逐通道量化不要用逐张量量化。如果逐通道量化后精度还不行考虑用量化感知训练。5.2 如何判断该不该用MobileNet我自己的判断流程一般是这样的先明确部署目标。目标是CPU、边缘端、移动端MobileNet和ShuffleNet都是优先候选目标是高端GPU需要测吞吐优先考虑标准卷积网络或裁剪后的标准网络。再测访存比例。框架里开profiler看每层的耗时分布如果DW卷积层的耗时占比超过预期说明访存是瓶颈这时候单纯换更轻量的block意义不大更要紧的是减输入分辨率或减中间通道数。再看算子支持。如果是自定义算子或较冷门的推理框架先确认模型里的算子都支持良好。有一次我在某嵌入式平台部署时发现ShuffleNet的通道混洗算子没有优化实现耗时占比极高最后只好转成等价卷积实现效果才好一些。5.3 性能对比时需要看哪些指标很多评测文章只报FLOPs和Params这两个指标对选型有帮助但不能代替延迟测试。建议至少记录以下几项单次推理延迟中位数看尾部或均值容易受干扰峰值内存占用尤其移动端和嵌入式设备功耗或温度电池设备上比延迟更敏感框架版本和线程数配置量化前后精度差对比速度时要注意控制变量同一推理框架、同一批输入、同一线程数、同一输入尺寸否则数字没有可比性。5.4 现场调优的几个小技巧如果MobileNet部署后速度不符合预期按以下顺序排查先确认输入分辨率是否过大。从224降到192或者从192降到160速度提升往往很明显精度影响可能在可接受范围。再确认线程数设置。CPU上线程数过少不能发挥多核能力线程数过多线程间同步开销变大。一般来说根据CPU核心数设置线程数并开启CPU自动调度。然后检查是否开启FP16或int8。移动端CPU支持FP16的话能有效降低访存带宽压力。如果只支持int8优先做逐通道量化。最后检查小算子耗时。用profiler找出耗时Top10的算子看是否有池化、拼接、通道混洗这类非卷积算子它们在轻量网络里的耗时占比往往被低估。如果占比过高可以考虑修改结构比如减少拼接操作或者把几个小算子合并起来。根据个人经验MobileNet这类模型不是“装上就能快”它在工程上需要配套的推理优化才能兑现理论优势。调整输入分辨率、算子融合、量化这三个环节往往比更换模型结构更有效。6. 写在最后关于MobileNet和ShuffleNet我个人的体会是轻量网络的设计确实带来了理论计算量的大幅下降但它解决的只是问题的一部分。真实部署时决定最终体验的往往是那些论文里不会写细节的工程环节——内存带宽、算子支持、量化误差、线程调度。如果让我给一个最朴素的建议拿到任何轻量网络第一步不是看它的FLOPs数字而是先上真机跑一版profiler看看每个算子的耗时分布。很多看似不应该慢的地方正是轻量模型发挥不出真正实力时的隐藏瓶颈。另外结构选型时给自己留一条后路如果MobileNet系列在目标设备上效果不达预期ShuffleNetV2是一个不错的备选它的设计原则更贴近真实硬件访存特点。两条路都试跑一遍用统一配置下的延迟和精度数据说话比看论文里的对比表更有价值。
先讲一个真实的工作场景某项目需要在低算力的嵌入式设备上部署一个图像分类模型一开始直接搬了标准卷积网络帧率惨不忍睹。后来负责人说换成MobileNet试试果真快了不少但奇怪的是测出来的FLOPs降了接近一个数量级帧率却只提升了两三倍。并不是MobileNet不香而是“FLOPs下降”和“端到端延迟下降”之间隔着内存访问、算子调度、并行粒度这一大堆工程问题。这件事让我后来养成了一个习惯聊轻量模型不能只看FLOPs表得把结构设计和真实部署环境放在一起看。这篇文章就把MobileNet及其变体重点带上ShuffleNet为什么会变快、在什么条件下会失效讲透。适合正在做模型轻量化、端侧部署、边缘设备推理的开发者也适合面试前想系统梳理轻量网络设计逻辑的朋友。1. 从FLOPs说起MobileNet到底把计算量省在了哪里要理解MobileNet为什么快得先看它动刀的地方标准卷积的计算方式。这个基础如果不清楚后面看V1、V2、V3的改动都会觉得是在记公式而不是理解设计意图。1.1 标准卷积到底有多贵假设输入特征图是 H×W×C输出特征图是 H′×W′×N卷积核大小是 K×K。标准卷积的计算量大约是K × K × C × N × H′ × W′这个式子的含义很直白输出特征图上的每一个点都要用一个 K×K 的卷积核在输入的所有 C 个通道上做滑窗乘加。所以计算量是“卷积核的空间尺寸 × 输入通道数 × 输出通道数 × 输出特征图大小”四者的乘积。问题出在“输入通道数 × 输出通道数”这一项。假设 C 和 N 都是256K3那么一个3×3卷积就要做 3×3×256×256也就是约59万次乘加输出特征图上每个点都要来一遍。通道数一上去计算量直接失控。1.2 深度可分离卷积把一个卷积拆成两次MobileNetV1的核心改动是把标准卷积拆成两步深度卷积Depthwise Convolution简称DW卷积和逐点卷积Pointwise Convolution简称PW卷积本质是1×1卷积。第一步深度卷积每个通道单独用一个 K×K 卷积核做卷积。也就是说输入有多少个通道就用多少个卷积核每个卷积核只管一个通道。这一步的计算量是K × K × C × H′ × W′注意这里没有“输出通道数 N”这一项。第二步逐点卷积用 1×1 卷积把前面得到的特征图在通道维度上融合输出 N 个通道。计算量是C × N × H′ × W′两步加起来K × K × C × H′ × W′ C × N × H′ × W′对比标准卷积 K×K×C×N×H′×W′计算量比值大约是1/N 1/K²当 N256、K3 时这个比值大概是 1/256 1/9约等于 0.115。也就是说深度可分离卷积只需要标准卷积大约九分之一到十分之一的计算量。我最早看这个公式时觉得没什么等到真的在设备上跑起来才发现计算量少了确实直接反映在能耗和发热上。同样的任务用标准卷积跑到后面设备烫手换成MobileNet之后温度明显降下来。对于用电池的设备来说这比单纯看延迟数字还重要。1.3 两组超参宽度乘子与分辨率乘子MobileNetV1还引入了两个可调超参数用来进一步缩放模型宽度乘子 α作用于通道数。输入通道变成 αC输出通道变成 αN。计算量会变成原来的 α² 倍。分辨率乘子 ρ作用于输入图像分辨率特征图尺寸同步变化。计算量会变成原来的 ρ² 倍。这两个超参的意义在于MobileNet能给出一组“精度—计算量”的取舍曲线方便在具体硬件上做适配。实际使用中α 的取值在0.25到1.0之间比较常见低于0.25时精度掉得很快因为通道数太少了特征表达空间被压缩到极限。ρ 则一般取整数缩放比如224、192、160、128很少做非整数缩放因为底层图像缩放库对非标准尺寸支持不一定好。1.4 FLOPs下降带来的直接效果从纯理论角度MobileNetV1的FLOPs比同分辨率下的标准卷积网络少一个量级左右。如果只看FLOPs会得出一个结论推理速度应该提升接近10倍。但真实设备上测通常只能感受到2到5倍的加速。原因是FLOPs只统计了乘加运算量没有统计内存搬运、数据读写、算子调度、分支跳转这些开销。一个极端的例子是1×1卷积它的FLOPs看起来不高但如果特征图很大逐点卷积的数据搬运量非常大跑起来并不像FLOPs数字那么轻松。所以把MobileNet理解成“降低了理论乘加量”比“提升了实际速度”更准确。2. MobileNet变体演进V1、V2、V3各自动了哪些手术MobileNet不是一个单独模型而是一个家族。V1到V3每一代都在改结构设计ShuffleNet又是另一条思路。把它们放在一起看才能明白轻量网络设计的主流套路。2.1 V1把“拆分”做到极致V1的贡献不只是在算法上把标准卷积拆成DW和PW更重要的是它提出了一种可复用的设计模式第一层仍然用标准卷积因为输入通道数只有3用DW卷积反而省不了多少从第二层开始全部用深度可分离卷积块。每个块后面接BN和ReLU。V1的结构本身不复杂但它确立了一个原则在轻量模型里3×3卷积不再是“标配”而是要拆开用的。这个思想后来被几乎所有轻量模型继承。2.2 V2线性瓶颈与倒残差结构V1存在一个明显问题DW卷积的参数和计算量虽然少但可学习的表达能力也弱了直接堆叠效果不好。V2针对这个问题做了两个关键改动。第一个改动是线性瓶颈。V2在DW卷积之前先做一个1×1卷积把通道数扩展开然后在block的最后一层1×1卷积之后不再接ReLU而是直接输出。原因是ReLU在低维空间会造成信息丢失而在高维空间这种丢失会减弱。简单说先升维再ReLU最后降维输出时不加激活函数避免把信息压掉。第二个改动是倒残差结构。传统残差结构是“先降维再升维”倒残差是“先升维再降维”。这个顺序看着违反直觉但在轻量模型里很合理因为DW卷积本身表达能力弱需要更多通道提供冗余信息。我在实际项目中对比过V1和V2的同一部署平台表现V2在ImageNet分类精度上明显高于V1推理耗时只增加了一点点。这说明V2的改动花得值。2.3 V3工具链升级搜出来的结构V3不是纯手工设计而是用了神经网络结构搜索技术在V2的基础上做了几件事激活函数方面引入了swish激活函数考虑到移动端计算sigmoid开销大又改成h-swish用ReLU6拼接来近似。注意力方面在部分block里加入了SE模块也就是通道注意力用少量额外计算换取精度提升。结构搜索方面用NAS搜索出每个block的通道数和是否使用SE模块。整体结构不再是一层层均匀堆叠而是呈现出两头大、中间窄的形态。V3的实测特点是在同精度目标下延迟比V2进一步降低。但它对推理框架的算子支持要求更高SE模块和h-swish在早期推理框架上可能没有优化实现直接部署反而会变慢。这也是一个典型的结构先进性和工程落地之间的冲突。2.4 ShuffleNet分组卷积与通道混洗ShuffleNet走了另一条路不拆卷积而是把标准卷积变成分组卷积然后通过通道混洗解决组间信息不流通的问题。分组卷积就是把输入通道分成多个组每个组各自做卷积。好处是计算量直接除以组数但坏处是组与组之间没有信息交流精度会明显下降。ShuffleNet的做法是在每个分组卷积之前把通道重新排列打散让每个组都能看到前一个组的部分通道。ShuffleNetV2还提出了一个非常实用的设计原则不能只看FLOPs还要考虑内存访问成本。论文里给出了一条著名结论FLOPs相同的情况下模型不一定有相同速度因为内存访问成本不同。基于这个原则ShuffleNetV2做了几个结构决策比如输入输出通道保持相同、分组数不宜过多、避免碎片化操作、减少逐元素运算。这条原则含金量很高。我第一次读到ShuffleNetV2时印象最深的不是某个block结构而是它把“内存访问成本”这个工程指标正式引入到网络设计评价体系里。从那以后我自己再做结构选型都会同时估算FLOPs和内存访问量两个指标。3. 模型变快背后的真实代价延迟并不等于FLOPs这一章是全文的骨架。很多人把MobileNet理解成“低FLOPs 低延迟”这是错的。FLOPs只是理论计算量端到端延迟还要看内存、并行、算子、访存带宽这些硬件维度。3.1 内存访问成本为什么致命ShuffleNetV2提到过内存访问成本可以用一个公式估算MAC h × w × c_in h × w × c_out k × k × c_in × c_out这个公式的含义是读输入特征图需要搬一次数据写输出特征图需要搬一次数据读卷积核参数也需要搬一次数据。搬运时间在真实硬件上不可忽略。举个例子一个 56×56×256 的中间特征图如果是float32每个特征图大约有 56×56×256×4 字节也就是约3.2MB。在内存带宽有限的设备上读一次、写一次就是6.4MB的搬运量。MobileNetV1整体结构虽然FLOPs低但中间特征图的分辨率和通道数并不小内存搬运开销一直存在。深度可分离卷积还有一个隐藏问题DW卷积的每个通道都是独立卷积计算密度非常低。在CPU上这意味着要频繁地从内存取数据但每次取完数据只做很少的乘加运算容易造成访存瓶颈。我做过一个简单的测量对比同一设备上纯3×3标准卷积的算力利用率能做到60%到70%但深度可分离卷积里的DW卷积部分算力利用率经常只有20%到30%。不是CPU不行而是DW卷积本身太“散”了访存比例过高。3.2 并行度与GPU效率GPU是为大规模并行计算设计的它喜欢的是“很多线程同时做同样的计算”。标准卷积恰好是这种形态同一个卷积核应用到所有空间位置和通道并行度极高。深度可分离卷积在GPU上却不那么友好。DW卷积的每个通道是独立的计算量不大但并行任务的数量取决于通道数。如果通道数不够多GPU的很多计算单元会闲置。1×1卷积倒是并行友好但整个网络里频繁的大数据量读入写出也让GPU的向量化优势打了折扣。这也是为什么MobileNet在CPU和嵌入式设备上收益明显但在高端GPU上有时反而跑不过一个优化良好的标准ResNetGPU对FLOPs的耐受度远高于CPU但访存和共享内存带宽的瓶颈并没有消失。3.3 算子碎片化与推理引擎适配MobileNetV1和V2的落地相对顺利因为结构规整主要就是DW、PW、BN、ReLU几种算子。V3加入SE模块后结构开始碎片化有全局池化、有全连接、有逐元素乘法、有h-swish。ShuffleNet的通道混洗需要专门的算子支持。推理框架对算子的支持程度决定了实际速度。很多框架对3×3或1×1卷积优化得很到位但对DW卷积或通道混洗可能走的是通用算子路径效率差得不是一点半点。部署前如果发现模型里的某个算子在小批量下耗时占比异常高多半就是这个算子没有针对性优化。另外一个因素是算子融合。手工设计网络时经常有“卷积—BN—ReLU”三段推理阶段可以把这三段融合成一个算子省掉中间特征图的读写。MobileNetV2的倒残差结构里BN和ReLU的位置比较规整融合起来容易。但V3里h-swish夹在卷积之间融合链路变长反而更容易出现中间缓存反复读写的场景。3.4 量化友好度的差异轻量模型在端侧部署基本都要做量化把float32模型转成int8。MobileNet的量化友好度其实一般原因是DW卷积的数值分布和标准卷积不完全一样。DW卷积每个通道只有一个卷积核输入通道和输出通道一一对应批量归一化后不同通道的数值分布差异可能很大。int8量化通常用的是逐张量的统一缩放因子遇到数值分布差异大的通道量化误差就会放大。实际踩坑经验一个MobileNetV2模型在float32下的精度损失不大但int8量化后精度下降比标准卷积网络更明显。解决办法之一是做逐通道量化让每个通道有自己的缩放因子。另一个办法是量化感知训练在训练阶段模拟量化误差让模型自适应。所以MobileNet变快了但“快”是有条件的它需要推理框架成熟、算子融合到位、量化策略合适。如果这三个条件不满足理论上少的FLOPs根本换不来实际速度。4. 什么时候受限MobileNet类结构不适用的典型场景了解了延迟不等于FLOPs之后就能解释为什么有些场景下MobileNet类结构会失效。以下四种情况是我在实际工作中比较常见的。4.1 高算力GPU上的收益变小部署目标如果是A100这种级别的GPU且批量较大MobileNet的优势会被大幅削弱。原因前面说过GPU不喜欢碎片化的卷积和频繁的访存而MobileNet恰恰在这两个维度上“牺牲”得比较多。高算力场景下标准卷积的算力利用率很高3×3卷积在GPU上有极成熟的高性能实现。相比之下Deep可分离卷积反而难以打满算力。再加上高端GPU的内存带宽远高于CPUMobileNet最引以为傲的“低FLOPs”优势在高吞吐任务里完全体现不出来。如果你的目标是最大化GPU吞吐MobileNet不是首选。高算力平台上更合适的是标准卷积配合剪枝或蒸馏而不是直接换轻量网络。4.2 实时性要求极高且批处理大的场合实时视频流处理场景比如视频结构化分析要求单帧延迟极低。MobileNet的延迟比标准卷积低但它每一层的特征图尺寸都很大中间层的访存时间会形成一个“地板”。在大批量场景GPU可以利用批量维度做并行优化把一次访存服务多个样本的收益放大。MobileNet设计时主要考虑的是单样本低延迟批量维度利用率天然不如标准卷积。实际测试中batch size增大到一定程度后MobileNet每样本耗时下降的比例可能低于标准卷积因为它的瓶颈已经从计算转移到了访存。4.3 精度敏感型任务轻量网络做分类、检测、分割都有对应版本但精度上限是它们绕不过去的坎。尤其在高精度目标检测或语义分割任务里MobileNet作为骨干网络提取语义信息的能力比不过强大的标准卷积骨干。这一点在特征金字塔结构里特别明显。MobileNet的浅层特征图分辨率较高但通道数少语义信息不足。如果检测头需要多尺度特征融合浅层特征的容量会成为瓶颈。我也试过用MobileNet做超分任务效果比标准残差网络差了不止一截。原因不复杂超分需要保留高频细节但MobileNet的深度可分离卷积相当于对空间信息做了一次“压缩”高频细节在低维空间里很难保住。4.4 内存带宽成为瓶颈的浅层网络一个容易被忽略的场景是网络层数很浅、输入分辨率很高时MobileNet的收益会显著下降。因为浅层网络里前几层的特征图尺寸特别大内存访问成本占比很高FLOPs优势被访存开销稀释了。比如直接拿MobileNetV1的第一层标准卷积做高分辨率输入比如512×512这层的输出特征图大概是512×512×32每个特征图约32MB输入输出搬运就有64MB左右的访问量。相比之下这层的FLOPs并不高。极端情况下推理时间可能主要花在读写特征图上计算单元反而在等待数据。遇到这种场景不能简单堆MobileNet而是要考虑裁剪输入分辨率、减少初始通道数或者用下采样尽早缩小特征图尺寸。5. 实操经验与常见问题排查技术文章讲完原理最后还是回到实操。这一章写一些部署和评估MobileNet类模型时的经验包括踩过的坑和排查思路。5.1 部署MobileNet时最容易踩的坑第一个坑是把FLOPs当延迟预算。选型阶段看FLOPs没问题但定了模型之后一定要上真机实测延迟。同一个MobileNetV3在不同推理框架上的耗时差距可能达到两倍以上因为SE模块和h-swish的算子支持程度完全不同。第二个坑是忽略BN融合。很多框架在推理时会自动把BN融合进卷积层但如果你手工部署或者使用自定义算子BN没有融合的话中间特征图要多读写一次速度立刻掉下来。建议在训练导出时直接做BN折叠保证部署图里没有BN节点。第三个坑是动态形状输入。推理框架为了性能通常会对固定形状做图优化比如算子融合、内存复用。如果输入尺寸每次都变框架只能退回到通用路径性能会下降很多。边缘设备部署时尽量resize到固定尺寸。第四个坑是int8量化后精度崩了。前面说过MobileNet对量化不友好建议用逐通道量化不要用逐张量量化。如果逐通道量化后精度还不行考虑用量化感知训练。5.2 如何判断该不该用MobileNet我自己的判断流程一般是这样的先明确部署目标。目标是CPU、边缘端、移动端MobileNet和ShuffleNet都是优先候选目标是高端GPU需要测吞吐优先考虑标准卷积网络或裁剪后的标准网络。再测访存比例。框架里开profiler看每层的耗时分布如果DW卷积层的耗时占比超过预期说明访存是瓶颈这时候单纯换更轻量的block意义不大更要紧的是减输入分辨率或减中间通道数。再看算子支持。如果是自定义算子或较冷门的推理框架先确认模型里的算子都支持良好。有一次我在某嵌入式平台部署时发现ShuffleNet的通道混洗算子没有优化实现耗时占比极高最后只好转成等价卷积实现效果才好一些。5.3 性能对比时需要看哪些指标很多评测文章只报FLOPs和Params这两个指标对选型有帮助但不能代替延迟测试。建议至少记录以下几项单次推理延迟中位数看尾部或均值容易受干扰峰值内存占用尤其移动端和嵌入式设备功耗或温度电池设备上比延迟更敏感框架版本和线程数配置量化前后精度差对比速度时要注意控制变量同一推理框架、同一批输入、同一线程数、同一输入尺寸否则数字没有可比性。5.4 现场调优的几个小技巧如果MobileNet部署后速度不符合预期按以下顺序排查先确认输入分辨率是否过大。从224降到192或者从192降到160速度提升往往很明显精度影响可能在可接受范围。再确认线程数设置。CPU上线程数过少不能发挥多核能力线程数过多线程间同步开销变大。一般来说根据CPU核心数设置线程数并开启CPU自动调度。然后检查是否开启FP16或int8。移动端CPU支持FP16的话能有效降低访存带宽压力。如果只支持int8优先做逐通道量化。最后检查小算子耗时。用profiler找出耗时Top10的算子看是否有池化、拼接、通道混洗这类非卷积算子它们在轻量网络里的耗时占比往往被低估。如果占比过高可以考虑修改结构比如减少拼接操作或者把几个小算子合并起来。根据个人经验MobileNet这类模型不是“装上就能快”它在工程上需要配套的推理优化才能兑现理论优势。调整输入分辨率、算子融合、量化这三个环节往往比更换模型结构更有效。6. 写在最后关于MobileNet和ShuffleNet我个人的体会是轻量网络的设计确实带来了理论计算量的大幅下降但它解决的只是问题的一部分。真实部署时决定最终体验的往往是那些论文里不会写细节的工程环节——内存带宽、算子支持、量化误差、线程调度。如果让我给一个最朴素的建议拿到任何轻量网络第一步不是看它的FLOPs数字而是先上真机跑一版profiler看看每个算子的耗时分布。很多看似不应该慢的地方正是轻量模型发挥不出真正实力时的隐藏瓶颈。另外结构选型时给自己留一条后路如果MobileNet系列在目标设备上效果不达预期ShuffleNetV2是一个不错的备选它的设计原则更贴近真实硬件访存特点。两条路都试跑一遍用统一配置下的延迟和精度数据说话比看论文里的对比表更有价值。
