MODNet 剪枝再思考: 优化计算量的实验历程分享

目录

1 写在前面

2 模型分析

3 遇到问题

4 探索实验一

4.1 第一部分

4.2 第二部分

Error 1

Error 2

4.3 实验结果

①参数量与计算量

②模型大小

③推理时延

5 探索实验二

5.1 LR Branch

5.2 HR Branch

5.2.1 初步分析

5.2.2 第一部分 enc2x

5.2.3 第二部分 enc4x

5.2.4 第三部分 hr4x

5.2.5 第四部分 hr2x

5.2.6 第五部分

5.3 f_branch

6 总结与思考


1 写在前面

在前面两篇文章《对MODNet 主干网络 MobileNetV2的剪枝探索》《对 MODNet 其他模块的剪枝探索》中,笔者已成功对 MobileNet V2 进行剪枝并嵌入至 MODNet,其余部分也采用键值对赋值的方式成功完成了替换,得到了 MODNet 剪枝版本一代,我们简称为“V1”。V1代在推理测试中发现:模型大小、参数量的确减小了一半,但推理时延从 240ms --> 192ms 尽管降低了20%,但下降力度还不够大,既然来到了模型压缩领域,那我们就应当尽可能“压榨”深度模型!

再一次观察 MODNet 剪枝前、后的变化情况,可以发现:FLOPs在剪枝后仅减小了原来的 1/5

考虑到相对参数量,计算复杂度 FLOPs 对推理速度的影响更大,因此,接下来对 MODNet 中 FLOPs 占比较高的层进行剪枝。

2 模型分析

从目前情况来看,下面两部分的 FLOPs 占比较高:

3 遇到问题

分析问题:网络需要的输入通道为16,但目前只获得了8个通道;

于是,通过调试,确定了权重矩阵的位置,进行修改:32 --> 16.

但这里一直存在着一个疑问:input 是如何来的?😅

按照往常的想法,上一层的输出作为下一层的输入,但这里由于正好是两个模块的交界点,因此无法满足这样的条件。所以,接下来需要找到 input 来源。(这也正是后续剪枝的基础)


通过 debug 可知,index57 的 input 源自 enc2x,如下:

接下来,寻找 enc2x 的来源。

MODNet 定义处,通过 LR Branch 得到:

来到 LR Branch 定义处,发现是源自 backbone 的forward:

debug 得 enc2x shape [1,16,256,256],正是 backbone 中 feature1 的输出:

那么,在对 backbone 剪枝过后,feature1 的 output 变为 [1,8,256,256],故 enc2x 的输入也就变为了该 tensor。

也就是说,对 backbone 的某些 channel 裁剪后,hr branch 中的 channel 也就必须调整!

辩证法的一大特性就是联系!

既然如此,如何调整?

方式包括直接修改权重 channel、裁剪 output channel。但由于这里 input 在 backbone 裁剪后已经确定,因此直接修改权重的 channel,也就有了先前将 enc_channels 中的16---->8。

目前关于 input 的源头已确定,也就明确了对 backbone 的剪枝会决定 hr branch 中的输入!

因此,对 hr branch 中网络层的剪枝也就分为 input 以及weight:

(1)针对 input 部分

方法:直接裁剪 backbone 中对应的部分

存在的问题:需要顾及其内部的倍数关系,以及 channel 为8的倍数(倒置残差块)

(2)针对 weight 部分

方法:直接修改enc_channels

存在的问题:考虑output与下一层输入的匹配情况

4 探索实验一

✨开展思路:修改结构----->匹配结构----->模型剪枝----->参数嵌入------>模型推理

4.1 第一部分

关系:lr_branch input channel <------ Linear <-------- backbone.feature.18 (1280)

方法:按照剪枝的稀疏情况直接修改网络,满足网络层与层之间相互匹配的同时,降低FLOPs。然后,利用 NNI 对子模块中的相关层进行剪枝。


首先,将 backbone last layer 1280 --> 640,但遇到了一个问题:

先前也遇到过,为了满足上下网络层的关系匹配,又恢复到了1280。

由于相关层 FLOPs 较高,因此直接修改关联层 channels 为640。


MODNet 模型剪枝前、后的情况为:

参数量:3.36 M --> 1.87 M;

计算量:15315.94 M --> 14502.68 M

我们发现:params 大幅下降,但 FLOPs 变化不大!

4.2 第二部分

由于对 input 不能直接裁剪,因此对 weight output channel 进行裁剪。

在观察 hr branch 时,联想到了先前 MobileNet V2 部分的 interverted_residual:

在原先结构中是递增状态,因此这里遵循先前的规则,调换位置。

Error 1

由于先前已经明确了hr branch每一层的input,因此定位到相应部修改即可。

wrapper:24 --> 16

结果是计算量仅仅只是有了轻微的减少趋势:

参数量 :1.88 M;

计算量:14480.74 M


观察 hr branch 的 weight output channel,与预定义的 channels 有关:

方法:直接修改channels:32 --> 24


Error 2

修改:

计算量相比先前的轻微减少有了明显的改进,目前达到了 8976.64 M,减小了一半:

至此,我们将该模型作为 MODNet 剪枝版本二代,简称V2

4.3 实验结果

整体改动情况:

  • backbone中的last channel、wrapper、interverted_residual;
  • MODNet hr_channels;
  • HR Branch中的conv_hr4x;
①参数量与计算量

情况一:原模型

情况二:对 backbone 剪枝后的模型;

情况三:修改 backbone 最后一层 channel 以及 hr branch 中的 weight channel后的模型;

情况一情况二情况三
参数量6.45 M3.36 M1.76 M
计算量18117.07 M15315.94 M8976.64 M
②模型大小
模型模型大小
原模型25641 K
V113256 K
V27213 K
③推理时延
序号原模型V1V2
10.850.670.54
20.880.670.56
30.840.650.54

5 探索实验二

由于 backbone 通道的剪枝会决定 HR branch,因此调整思路,先将 backbone 中的倒置残差块恢复到原先的情况。

5.1 LR Branch

backbone 部分修剪 last channel 1280 --> 640。

se_block、conv_lr16x,其余排除。

config 加入 Linear,将 se_block 以及 lrx 作为整体,与 backbone 剪枝。

变化如下:

读取 pth,并修改结构,验证是否可以成功加载:

加载失败,原因是涉及到了 Conv 中的 BN 层,如下:

解决方案:修改 IBNorm 定义即可。

于是,成功加载,且完成 lr_branch 的模拟推理,如下:

接下来,将 lr_branch 的参数嵌入到 MODNet,但在打印键时发现缺少了 running mean,尽管与inference 无关,但与 retrain 有关。换句话说,虽然可以成功嵌入,但对后续重训练精度的恢复有影响!

再次打印 lr_branch 参数,发现该键是存在的,但由于 model.named_parameters() 并没有获取到,因此这里采用 model.state_dict() 的方式重新嵌入。打印方式如下:

for name, params in model.state_dict().items():   
    print(name)

总共有751个键值对,注意 backbone 和 lr 中的 backbone,参数一致:

5.2 HR Branch

5.2.1 初步分析

将 HR Branch 划分为 5 个部分:

分析:3、4、5 部分 channel 有着明显的上、下层衔接关系;

而1、2部分从channel上看不出联系;

因此,接下来将对该 model 的5个部分分别处理,进而合并成 new branch。

5.2.2 第一部分 enc2x

利用 sequential 连接,剪枝:

无法绝对匹配,剪枝失败,源代码定义如下:

所以无法合并,考虑分层剪枝,但又存在两个问题

  • 无法对权重的input channel修改(16、35)
  • 下一层的input channel(35)无法匹配

解决方案:手动剪枝

明确目标:

✨开展思路:

  1. 获取第57层,先使用 0.25 稀疏度剪枝,然后执行剪枝脚本将 input channel16 --> 8,参数保存,注意参数名 MODNet 内一致

  2. 获取58层同上,操作同上;

  3. 利用 sequential 连接 tohr 与 conv;

  4. 按照结构内的参数名,将 tohr 与 conv 参数连接,形成一个 ordereddict 格式;

  5. 将参数嵌入结构,形成第一个part;

剪枝后的参数名虽然和结构中相差了 hr,且一一对应,但填入结构仍然出现了参数初始化的情况。如下:

strict=false:

因此,这里采用键值替换进行修改。(结构不变,修改参数中的键名)

但这样的键名不利于下面的合并。

于是,笔者重新构建字典,修改键名,代码如下:

tohr_enc2x_ckpt = OrderedDict(
    [(k.replace(k, 'hr_branch.tohr_enc2x.' + k), v) for k, v in tohr_enc2x.state_dict().items()])

后来想想,这一参数(填入结构并修改参数名)和剪枝过后的是一致的,验证代码与结果如下:

for key in pruned_tohr_enc2x.keys():
    if tohr_enc2x_ckpt[key].equal(pruned_tohr_enc2x[key]):
        print("Match")

因此,这一操作意义不大。因为初心是为了与参数嵌入时命名一致,但实际上因为这一操作导致的中间过程较为繁琐。此外,剪枝过后的 pruned_tohr_enc2x 已经达到了目标状态,即shape:[24,8,1,1]

所以,第一部分两个 layer 没有连接的必要!

5.2.3 第二部分 enc4x

调整思路:NNI 剪枝 + 自定义通道剪枝 + 键名替换 + 参数嵌入

剪枝前:

剪枝后:

因此,这一部分成功嵌入!

5.2.4 第三部分 hr4x

首先,channel 83 并不合理,与模型定义时产生了冲突,因此先前仅仅是为了满足模型结构做的微调。通过剪枝,除了layer 1 的weight channel,其他都可以实现。


如何将 weight 从(24,16,1,1)的尺寸裁剪为(24,8,1,1)?🥲🥲🥲

✨开展思路:

  1. 获取该层的参数,打印shape测试;

  2. 计算每一个输入通道的权重和,并排序;

  3. 将较小的8个通道去除;

  4. 创建去除后的tensor,进行参数替换;

于是,LeNet 它又来了!笔者很喜欢在 LeNet 上做一些测试。🌝

核心思想:编号 --> 排序 --> 去除通道 --> 重新编号 --> 参数替换

注意事项:①bias由 output channel 决定;②网络层类型为 OrderedDict()

测试:将输入 weight 由[6,3,3,3] -----> [4,3,3,3]

局限性:缺少稀疏度分析 + 单一层剪枝


针对 hr_branch 的第一个 layer channel(16---->8)成功剪枝!

针对第三部分 channel 99 ------->83,成功剪枝:

然后修改键名,与 MODNet 匹配,嵌入成功。

5.2.5 第四部分 hr2x

剪枝前:

剪枝后:

因此,这一部分成功嵌入!

5.2.6 第五部分

剪枝前:

剪枝后:

同样,这一部分成功嵌入!

5.3 f_branch

剪枝前:

剪枝后:

同时,也完成了模型嵌入,但遇到了下列问题:

💥问题一:保存的 hr branch 参数 bias 都为0、1,影响到了再训练的精度;


💥问题二:剪枝脚本仅仅针对 Conv 的 weight 以及 bias,尚未对包含于 Conv 块中的 BN 层进行处理,有待改进。

修改:针对input channel,BN层不被影响,因此直接添加如 dict 即可。


💥问题三:剪枝脚本执行后返回的网络层的名字没有和原先的匹配,这里有待处理。

修改:按照MODNet中的layer name修改,利用键值进行替换

OrderedDict([(k.replace(k, 'hr_branch.tohr_enc2x.' + k), v) for k, v in model.state_dict().items()])

6 总结与思考

通过再一次分析 MODNet 网络结构,笔者发现 V1 代的剪枝版本在计算量上处理得不够好,于是,本文从计算量的角度分析,对 MODNet 网络结构中计算量占比较大的部分重新进行剪枝处理,并进行参数替换。实验结果表明,剪枝后的模型相比原模型降低了一半的计算量,推理时延也有了明显的改进,然而,模型精度并不好!

因此,关于模型剪枝后retrain精度较低的问题,笔者做了下列思考🤔🤔🤔:

(1)从剪枝本身考虑

  1. 相同情况下,大 sparse 导致更多的特征提取层无法提取到必要的特征,破坏了核心结构;

  2. 固定整体剪枝比例存在漏洞,导致有些模块去除了重要程度较高的通道;

  3. 缺少 BN 层中的 running mean 、var ,影响了再训练时的精度恢复;

解决方案:

①采用 少量剪枝---->微调---->少量剪枝------微调 的策略;

②不再采用固定整体比例剪枝,而是对特定的模块具体问题具体分析

(2)从再训练考虑

  1. 由于参数的初始化以及算法的随机性,导致单一的训练无法得到较理想的效果?
  2. 如何准确设置超参?训练得到原模型的超参组合与剪枝后重训练的超参一样吗?
  3. 关于 learning rate,剪枝后,模型减小,参数减少,寻找最优解时的步长应当减小。反之,可能错过最优解。
  4. 是否可以设置动态参数?随着 epoch 的增加而变化?

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:/a/345486.html

如若内容造成侵权/违法违规/事实不符,请联系我们进行投诉反馈qq邮箱809451989@qq.com,一经查实,立即删除!

相关文章

C++逆向分析--多态的本质

这篇我们延续上次的虚函数分析&#xff0c;来研究下多态的本质。 虚函数逆向分析的博客&#xff1a;C逆向分析--虚函数&#xff08;多态的前置&#xff09;-CSDN博客 有了上篇虚函数的知识&#xff0c;我们在正向开发学习的时候知道&#xff0c;多态的发生需要存在继承关系&a…

创意飞轮

创业初期最难的是确定好的创业方向&#xff0c;创意飞轮就是一种用来寻找、判断创业想法的心智模型。原文: The Ideation Flywheel 想出好的创业点子是很困难的&#xff0c;伟大的想法和完全糟糕的想法往往在一开始很难区分&#xff0c;糟糕的想法也许看起来会很诱人&#xff0…

深入探讨Python JSON库:兼容性与高级应用【第34篇—python:JSON库】

文章目录 深入探讨Python中的JSON处理技术引言官方json库进阶用法多说一句 第三方json库DemjsonOrjson Demjson库详解Orjson库的高级选项Python JSON库的兼容性考虑JSON类型映射兼容性处理解码时使用object_hook处理中文字符编码 多版本兼容 结语 深入探讨Python中的JSON处理技…

1.8 万 Star!这款 Nginx 可视化配置工具太强了

NginxConfig简介 Nginx Config 是一个强大的 Nginx 配置文件生成器&#xff0c;号称配置 Nginx 服务器所需的唯一工具。 正因为 Nginx 功能强大&#xff0c;所以针对其各个功能的配置项会显得特别多&#xff0c;对于我们来说要记住那么多配置是一件十分头疼的事&#xff0c;甚…

Springboot+vue的校园疫情防控系统(有报告),Javaee项目,springboot vue前后端分离项目。

演示视频&#xff1a; Springbootvue的校园疫情防控系统&#xff08;有报告&#xff09;&#xff0c;Javaee项目&#xff0c;springboot vue前后端分离项目。 项目介绍&#xff1a; 本文设计了一个基于Springbootvue的前后端分离的校园疫情防控系统&#xff0c;采用M&#xff…

网络原理-初识(1)

目录 网络发展史 独立模式 网络互连 局域网LAN 广域网WAN 网络通信基础 IP地址 概念 格式 端口 概念 格式 认识协议 概念 作用 五元组 网络发展史 独立模式 独立模式:计算机之间相互独立; 网络互连 随着时代的发展,越来越需要计算机之间相互通信,共享软件和数…

【计算机网络】UDP协议与TCP协议

文章目录 一、端口号1.什么是端口号2.端口号范围划分3.认识知名端口号(Well-Know Port Number)4.netstat5.pidof 二、UDP协议1.UDP协议端格式2.UDP的特点3.面向数据报4.UDP的缓冲区5.UDP使用注意事项6.基于UDP的应用层协议 三、TCP协议1.TCP协议段格式1.1理解封装解包和分用1.2…

代码随想录算法训练营第14天 | 二叉树的前序、中序、后序遍历(递归+迭代法)

二叉树的理论基础&#xff1a;&#xff08;二叉树的种类&#xff0c;存储方式&#xff0c;遍历方式 以及二叉树的定义&#xff09; https://programmercarl.com/%E4%BA%8C%E5%8F%89%E6%A0%91%E7%90%86%E8%AE%BA%E5%9F%BA%E7%A1%80.html 二叉树的递归遍历 Leetcode对应的三道习…

使用骨传导耳机对人体有没有伤害?一文读懂骨传导耳机有什么危害?

不能说骨传导耳机对人体没有一点伤害&#xff0c;只能说骨传导耳机可以最大程度的减少对人体的伤害&#xff0c;首先就是骨传导耳机不用入耳&#xff0c;可以减少耳道内细菌的滋生&#xff0c;避免中耳炎等耳部疾病&#xff1b;其次就是骨传导的声音传播方式是通过骨骼直接进入…

Spring Boot 学习之——@SpringBootApplication注解(自动注解原理)

SpringBootApplication注解 springboot是基于spring的新型的轻量级框架&#xff0c;最厉害的地方当属**自动配置。**那我们就可以根据启动流程和相关原理来看看&#xff0c;如何实现传奇的自动配置 SpringBootApplication//标注在某个类上&#xff0c;表示这个类是SpringBoot…

thinkphp5向数据表插入数据并且获得id

$id db(数据表名)->insertGetId([status>1]); 直接...打印$id就是这条插入的数据的id了

数据采集与预处理01: 项目1 数据采集与预处理准备

数据采集与预处理01&#xff1a; 项目1 数据采集与预处理准备 任务1 认识数据采集技术&#xff0c;熟悉数据采集平台 数据采集&#xff1a;足够的数据量是企业大数据战略建设的基础&#xff0c;因此数据采集成为大数据分析的前站。数据采集是大数据价值挖掘中重要的一环&#…

python-分享篇-养老金数据统计

代码 import matplotlib.pyplot as plt import numpy as np # 为柱状图添加标注 def label(bars):for bar in bars:height bar.get_height()plt.text(bar.get_x()bar.get_width()/2.- 0.2, 1.03*height, %s % int(height))plt.rcParams[font.sans-serif] [SimHei] # 显示中文…

【数据结构】 顺序表的基本操作 (C语言版)

一、顺序表 1、顺序表的定义&#xff1a; 线性表的顺序存储结构&#xff0c;即将表中的结点按逻辑顺序依次存放在一组地址连续的存储单元里。这种存储方式使得在逻辑结构上相邻的数据元素在物理存储上也是相邻的&#xff0c;可以通过数据元素的物理存储位置来反映其逻辑关系。…

基于Springboot的大学生心理健康管理系统(有报告)。Javaee项目,springboot项目。

演示视频&#xff1a; 基于Springboot的大学生心理健康管理系统&#xff08;有报告&#xff09;。Javaee项目&#xff0c;springboot项目。 项目介绍&#xff1a; 采用M&#xff08;model&#xff09;V&#xff08;view&#xff09;C&#xff08;controller&#xff09;三层体…

【吃灰开发板复活】DIY全志V3s随身终端屏幕适配,LVGL以及各种外设驱动移植教程

在上周的文章中介绍了一款因作者想要学习Linux而动手DIY的终端设备V3S-PI&#xff0c; 《梦回2004&#xff01;我用全志V3s做了个成本100元&#xff0c;功能媲美MP4的随身终端》&#xff1a;梦回2004&#xff01;我用全志V3s做了个成本100元&#xff0c;功能媲美MP4的随身终端…

微信小程序如何获取当前日期时间

Hello大家好&#xff01;我是咕噜铁蛋&#xff0c;获取当前日期时间是小程序中经常会用到的一个功能。因此&#xff0c;在本文中&#xff0c;我通过科技手段给大家收集整理了下&#xff0c;今天我将向大家介绍如何在微信小程序中获取当前日期时间的方法&#xff0c;并分享一些实…

HubSpot在线客户互动:建立强大数字连接的关键一步

HubSpot在线客户互动为企业带来了多方面的具体业务优势&#xff0c;其中一些关键点包括&#xff1a; 提高销售转化率&#xff1a; 通过实时在线聊天、个性化推荐等互动方式&#xff0c;HubSpot使企业能够更主动地接触潜在客户&#xff0c;解答其疑问&#xff0c;提供定制化的…

RabbitMQ——高级篇

目录 一、MQ的常见问题 二、消息可靠性问题 生产者消息确认 消息持久化 消费者消息确认 失败重试机制 三、死信交换机 简介死信交换机 TTL超时机制 延迟队列 四、惰性队列 消息堆积问题 惰性队列 一、MQ的常见问题 消息可靠性问题&#xff1a;如何确保发送的…

解决 Git:ssh: connect to host github.com port 22: Connection timed out 问题的三种方案

1、问题描述&#xff1a; 其一、整体提示为&#xff1a; ssh: connect to host github.com port 22: Connection timed out fatal: Could not read from remote repository. 中文为&#xff1a; ssh&#xff1a;连接到主机 github.com 端口 22&#xff1a;连接超时 fatal&a…