目錄
1 引言
1.1 MODNet 原理
1.2 MODNet 模型分析
2 MobileNetV2 剪枝
2.1 剪枝過程
2.2 剪枝結(jié)果
2.2.1 網(wǎng)絡(luò)結(jié)構(gòu)
2.2.2 推理時延
2.3 實驗結(jié)論
3 模型嵌入
3.1 模型保存與加載
法一：保存整個模型
法二：僅保存模型的參數(shù)
小試牛刀
小結(jié)
3.2 修改 MobileNetV2 中的 block
階段一
階段二
總結(jié)
3.2 MobileNetv2 參數(shù)嵌入 v1
3.2.1 遇到問題
3.2.2 解決方案
3.2.3 探索過程
階段一
階段二
階段三
3.2.4 結(jié)論
3.3 MobileNetV2 參數(shù)嵌入 v2
3.3.1 開展思路?
3.3.2 探索過程
階段一
ERROR1
ERROR 2
階段二
階段三
模擬推理
ERROR 1
ERROR 2
階段四
ERROR 1
ERROR 2
實驗結(jié)果
1 引言
1.1 MODNet 原理
基于卷積神經(jīng)網(wǎng)絡(luò)擅長處理單一任務(wù)的特性，MODNet 將人像摳圖分解成了三個相關(guān)的子任務(wù)：語義估計(Semantic Estimation)、細(xì)節(jié)預(yù)測(Detail Prediction)、語義-細(xì)節(jié)融合(Semantic-Detail Fusion)，分別對應(yīng)著模型結(jié)構(gòu)中 Low-Resolution Branch(LR-Branch)、High-Resolution Branch(HR-Branch)、Fusion Branch(F-Branch) 三個分支。其中，LR-Branch 用于人像整體輪廓的預(yù)測，HR-Branch 用于前景人像與背景過渡區(qū)域的細(xì)節(jié)預(yù)測， Fusion Branch 負(fù)責(zé)將前兩部分預(yù)測得到的輪廓與邊緣細(xì)節(jié)融合。語義估計部分是獨立的分支，依賴于細(xì)節(jié)預(yù)測、語義-細(xì)節(jié)融合兩個分支。
MODNet論文地址：https://arxiv.org/pdf/2011.11961.pdf
1.2 MODNet 模型分析
作為輕量化模型，MODNet 參數(shù)量僅6.45MB，但作為底層視覺任務(wù)，MODNet輸入、輸出分辨率一致，計算復(fù)雜度較高。筆者利用 NNI 分析了 MODNet 三個分支的參數(shù)量與計算量：
| MODNet分支 | 參數(shù)量(MB) | 計算量(GFLOPs) |
|---|---|---|
| LR-Branch | 6.16 | 5.03 |
| HR-Branch | 0.24 | 10.58 |
| F-Branch | 0.05 | 2.71 |
從計算量來看，MODNet 三個分支 LR-Branch、HR-Branch、F-Branch 分別占整個網(wǎng)絡(luò)的27.7%、58.2%、14.1%。HR-Branch 作為高分辨率分支，相比其它兩個分支的計算量較高，是剪枝重點關(guān)注的部分。
在實際剪枝時，由于 MODNet 內(nèi)部包含了三個分支，直接剪枝較為復(fù)雜，因此對結(jié)構(gòu)進(jìn)行拆分。
接下來，是筆者對主干網(wǎng)絡(luò) MobileNetV2 部分的探索實驗。
2 MobileNetV2 剪枝
2.1 剪枝過程
確定待剪枝的對象：
- Cov2d layer
- BatchNorm2d
- Linear
?剪枝策略：基于L1范數(shù)結(jié)構(gòu)化剪枝
model = MobileNetV2(3)
config_list = [{'sparsity': 0.8, 'op_types': ['Conv2d']}]
pruner = L1NormPruner(model, config_list)
_, masks = pruner.compress()
pruner._unwrap_model()
ModelSpeedup(model, torch.rand(1, 3, 512, 512), masks).speedup_model()
2.2 剪枝結(jié)果
參數(shù)量：3.5M → 309.76k
復(fù)雜度：1.67 GMac → 41.54 MMac
從參數(shù)量和計算復(fù)雜度來看，對MobileNetV2的剪枝可以明顯壓縮模型，下面具體來看網(wǎng)絡(luò)結(jié)構(gòu)、推理時延與精度。
2.2.1 網(wǎng)絡(luò)結(jié)構(gòu)
分別展示三組，A組、B組、C組分別代表MobileNetV2第0~15層、第16~32層、第33~52層。
A組剪枝前：
A組剪枝后：
B組剪枝前：
B組剪枝后：
C組剪枝前：
C組剪枝后：
可以發(fā)現(xiàn)，不論是靠近模型輸入端，還是輸出端，卷積層都有大幅度的裁剪。
2.2.2 推理時延
使用PyTorch框架，分別在GPU與CPU上測試，結(jié)果如下。
GPU上
| 剪枝前 | 剪枝后 | |
|---|---|---|
| 1 | 0.9339 | 0.8370 |
| 2 | 0.9144 | 0.7980 |
| 3 | 0.9530 | 0.8759 |
CPU：
| 剪枝前 | 剪枝后 | |
|---|---|---|
| 1 | 0.3529 | 0.0609 |
| 2 | 0.3906 | 0.0549 |
| 3 | 0.3600 | 0.0520 |
第一次觀察剪枝前、后的推理時延時，發(fā)現(xiàn)差距并不大。正在此時，筆者聯(lián)想到前一秒的數(shù)據(jù)類型不一的報錯：由于 dummy_input 轉(zhuǎn)到了 CUDA 上，而 model 還是 CPU上 的 model，導(dǎo)致無法 run。于是筆者把 model 轉(zhuǎn)到了cuda上。也正是在這個時候，筆者想到了推理硬件的問題：如果數(shù)據(jù)量本身就不大的時候，在 CUDA 上運行速度不一定比 CPU 快。數(shù)據(jù)如果要利用 GPU 計算，就需要從內(nèi)存轉(zhuǎn)移到顯存上，數(shù)據(jù)傳輸具有很大開銷，對于小規(guī)模數(shù)據(jù)來說，傳輸時間已經(jīng)超過了 CPU 直接計算的時間。因此，規(guī)模小無法體現(xiàn)出 GPU 的優(yōu)勢，而大規(guī)模神經(jīng)網(wǎng)絡(luò)采用 GPU 加速意義較大，推理同樣如此。
通過對MobileNetV2剪枝，我們可以發(fā)現(xiàn)：剪枝前、后的模型在 CPU 上的推理狀況已經(jīng)有了明顯的差距，推理時延的降低達(dá)到了預(yù)期！??！
仔細(xì)看推理，dummy_input 初始化時涉及了batch，上述實驗都是基于batch=1的情況。因此，接下來對剪枝前、后的模型，在不同的batch、在不同的硬件上推理進(jìn)行對比。
CPU：
| batch | 剪枝前 | 剪枝后 |
|---|---|---|
| 1 | 0.30 | 0.07 |
| 2 | 0.64 | 0.07 |
| 4 | 1.14 | 0.18 |
| 8 | 2.22 | 0.25 |
| 16 | 4.33 | 0.39 |
| 32 | 11.76 | 0.78 |
| 64 | 66.45 | 1.49 |
GPU：
| batch | 剪枝前 | 剪枝后 |
|---|---|---|
| 1 | 0.81 | 0.77 |
| 2 | 0.90 | 0.79 |
| 4 | 0.95 | 0.76 |
| 8 | xxx | 0.83 |
| 16 | xxx | 0.91 |
| 32 | xxx | 0.97 |
| 64 | xxx | xxx |
2.3 實驗結(jié)論
回首LeNet，不論是pth格式的PyTorch模擬推理還是實際推理，以及 ONNX、OpenVINO 推理，剪枝前、后的模型在 CPU 上的推理速度差異不明顯就可以解釋了，同時也驗證了先前的猜想：LeNet 本身屬于小規(guī)模網(wǎng)絡(luò)，結(jié)構(gòu)簡單，推理速度已經(jīng)很快了。因此，不論如何壓縮模型，在batch較小的時候都無法有效降低推理時延。
另外，筆者總結(jié)了下列結(jié)論??：
當(dāng)網(wǎng)絡(luò)規(guī)模并非很大時，在CPU上推理比GPU更適合；（規(guī)模的閾值沒有明確界限，需要嘗試）
當(dāng) batch 逐漸增大時，剪枝后的模型推理速度占有絕對優(yōu)勢，且大模型優(yōu)于小模型；
若要進(jìn)行實時推理，保證較低的推理時延，batch 可以考慮設(shè)置為1；
相較于小模型，大模型剪枝在實際推理中更有意義；（LeNet剪枝前后batch為1時延不變，而mobilenetv2差異較大）
不僅僅是模型大小，數(shù)據(jù)本身也會影響推理速度；（推理小數(shù)據(jù)負(fù)擔(dān)較小，所以在做模型壓縮時，是否可以考慮前處理，例如圖像壓縮）
3 模型嵌入
3.1 模型保存與加載
PyTorch 模型的保存與讀取方式有兩種，接下來還是以 LeNet 為例，結(jié)構(gòu)定義如下：
class LeNet(nn.Module):
def __init__(self):
super(LeNet, self).__init__()
self.conv1 = nn.Conv2d(1, 6, 3)
self.conv2 = nn.Conv2d(6, 16, 3)
self.fc1 = nn.Linear(16 * 5 * 5, 120)
self.fc2 = nn.Linear(120, 84)
self.fc3 = nn.Linear(84, 10)
def forward(self, x):
x = F.max_pool2d(F.relu(self.conv1(x)), (2, 2))
x = F.max_pool2d(F.relu(self.conv2(x)), 2)
x = x.view(-1, int(x.nelement() / x.shape[0]))
x = F.relu(self.fc1(x))
x = F.relu(self.fc2(x))
x = self.fc3(x)
return x法一：保存整個模型
model = LeNet()
torch.save(model,PATH)
# 直接加載，得到網(wǎng)絡(luò)結(jié)構(gòu)：
model = torch.load(PATH)
??注意：參數(shù)可以通過 model.named_parameters() 獲取。
法二：僅保存模型的參數(shù)
torch.save(model.state_dict(),PATH)
# 直接加載，得到權(quán)重參數(shù)：
model = torch.load(PATH)
若要將參數(shù)加載到網(wǎng)絡(luò)中，需要獲取網(wǎng)絡(luò)結(jié)構(gòu)，也就是初始化model：
model = LeNet()
model.load_state_dict(torch.load('model2.pth'))
print(model)
??注意：參數(shù)和網(wǎng)絡(luò)結(jié)構(gòu)應(yīng)當(dāng)相匹配，否則參數(shù)無法傳入。
這里做個示范：將第二個全連接層的輸出通道以及第三個全連接層的輸入通道都改為94，繼續(xù)load，則：
因此，在對網(wǎng)絡(luò)結(jié)構(gòu)裁剪后，利用 state_dict 讀取參數(shù)前需要相應(yīng)修改網(wǎng)絡(luò)結(jié)構(gòu)，可以參考裁剪后的模型通道數(shù)以及卷積核的變化情況。
小試????
以 LeNet 為例，由于之前都是直接保存整個結(jié)構(gòu)，因此沒有涉及到結(jié)構(gòu)的修改問題，接下來只保存模型參數(shù)。
剪枝后的網(wǎng)絡(luò)結(jié)構(gòu)為：
加載剪枝后的模型：
model = LeNet()
path = 'new_model.pth'
model.load_state_dict(torch.load(path))
print(model)
所以，如果直接加載則會產(chǎn)生參數(shù)與結(jié)構(gòu)不匹配的錯誤，因此修改如下：
class LeNet(nn.Module):
def __init__(self):
super(LeNet, self).__init__()
self.conv1 = nn.Conv2d(1, 2, 3)
self.conv2 = nn.Conv2d(2, 4, 3)
self.fc1 = nn.Linear(4 * 5 * 5, 120)
self.fc2 = nn.Linear(120, 84)
self.fc3 = nn.Linear(84, 10)
def forward(self, x):
x = F.max_pool2d(F.relu(self.conv1(x)), (2, 2))
x = F.max_pool2d(F.relu(self.conv2(x)), 2)
x = x.view(-1, int(x.nelement() / x.shape[0]))
x = F.relu(self.fc1(x))
x = F.relu(self.fc2(x))
x = self.fc3(x)
return x
小結(jié)
模型保存時只保存參數(shù)，相對保存整個模型而言，不需要在加載時與結(jié)構(gòu)的定義在同一腳本中；此外僅保存模型的參數(shù)占用較少的內(nèi)存，且節(jié)省時間，所以一般情況下只保存參數(shù)的做法更常用。
3.2 修改 MobileNetV2 中的 block
階段一
修改前、后對比：
# 修改前
interverted_residual_setting = [
# t, c, n, s
[1, 16, 1, 1],
[expansion, 24, 2, 2],
[expansion, 32, 3, 2],
[expansion, 64, 4, 2],
[expansion, 96, 3, 1],
[expansion, 160, 3, 2],
[expansion, 320, 1, 1],
]
# 修改后：
interverted_residual_setting = [
# t, c, n, s
[1, 4, 1, 1],
[expansion, 8, 2, 2],
[expansion, 18, 3, 2],
[expansion, 39, 4, 2],
[expansion, 45, 3, 1],
[expansion, 77, 3, 2],
[expansion, 64, 1, 1],
]然而，由于裁剪后通道數(shù)沒有保持8的整數(shù)倍，加載失敗也在預(yù)料之中。
??解決方案：
- 利用_make_divisible對NNI剪枝源碼進(jìn)行修改；?
- 修改裁剪比例?
初步探索：
①將根據(jù)稀疏比例設(shè)定位0.2進(jìn)行裁剪，保留80%的成分，但又由于浮點數(shù)問題的取整問題也無法保證是8的倍數(shù)。
②再次觀察通道數(shù)，只要將第二個殘差塊的out_channels（24）保留，剩下的裁剪50%即可保證。但通過實驗發(fā)現(xiàn)，NNI的API在根據(jù)預(yù)先設(shè)定的稀疏度裁剪時存在誤差，在對于MobileNetv2這樣的倒置殘差塊結(jié)構(gòu)來說，無法達(dá)到理想的效果。
③通過查看源碼，發(fā)現(xiàn)了剪枝時的mode選項：當(dāng)設(shè)置為“dependency_aware”時，剪枝器將強制具有依賴關(guān)系的卷積層剪枝相同的通道。因此，一方面可以保證準(zhǔn)確的稀疏度；另一方面，加速模塊可以更好地從剪枝模型中獲得速度優(yōu)勢。
剪枝配置如下：
config_list = [{'sparsity': 0.5,
'op_types': ['Conv2d']},
{'exclude': True,
'op_names': ['features.0.0','features.2.conv.6']
}]這里加入了first layer的conv，如果不排除，也會導(dǎo)致channel不是8的倍數(shù)。
這一次達(dá)到了預(yù)期效果，但加在模型參數(shù)時依然提示do not match。
這里思考了很久，再一看模型，發(fā)現(xiàn)實際上筆者一直在關(guān)注channel是否為8的倍數(shù)，而忽略了interverted_residual_block中的擴(kuò)展因子，每次擴(kuò)展都會將低維乘6。因此，block內(nèi)部的維度擴(kuò)展在剪枝過后不再滿足要求，如下圖：
階段二
??解決方案：
- 修改block層的expansion系數(shù)；
- 排除每一個block“低維--->高維”時的第一層進(jìn)行剪枝；
首先，將低維擴(kuò)展后的第一個高維conv進(jìn)行保留測試，剪枝后的shape如下：
按照這樣的思路，將其余block的第一個擴(kuò)展層進(jìn)行排除，配置如下：
config_list = [{'sparsity': 0.5,
'op_types': ['Conv2d']},
{'exclude': True,
'op_names': ['features.0.0', 'features.2.conv.6', 'features.2.conv.0', 'features.3.conv.0',
'features.4.conv.0', 'features.5.conv.0', 'features.6.conv.0', 'features.7.conv.0',
'features.8.conv.0', 'features.9.conv.0', 'features.10.conv.0', 'features.11.conv.0',
'features.12.conv.0', 'features.13.conv.0', 'features.14.conv.0', 'features.15.conv.0',
'features.16.conv.0', 'features.17.conv.0']
}]
整體上達(dá)到了理想效果，僅有一個block層不符合expansion，隨之修改對應(yīng)block層的expansion以及each block setting。
由于該層會重復(fù)執(zhí)行兩次，在將expansion修改為3以后，第二次執(zhí)行就不再符合條件。這里根據(jù)通道變化情況針對執(zhí)行次數(shù)單獨控制，如下：
interverted_residual_setting = [
# t, c, n, s
[1, 8, 1, 1],
[6, 24, 2, 2], # 1. 8-->24 2. 24-->24,expansion=3(modify)
[6, 16, 3, 2], # 1. 24-->16(modify) 2. 16-->96
[expansion, 32, 4, 2],
[expansion, 48, 3, 1],
[expansion, 80, 3, 2],
[expansion, 160, 1, 1],
]
成功加載：
mobilenet = MobileNetV2(3)
mobilenet.load_state_dict(torch.load('modified_mobilenet_3.pth'))
print(mobilenet)
接下來，針對MODNet預(yù)訓(xùn)練模型中的MobileNetV2部分進(jìn)行裁剪。
第一次剪枝下來有個別層的通道有誤，同時，個別通道沒有滿足預(yù)設(shè)的expansion，比如：
小結(jié)
考慮到計算機處理器單元架構(gòu)的問題，通道數(shù)保持8的倍數(shù)能夠較快計算，因此，剪枝也應(yīng)當(dāng)遵循這個原則；
考慮到每一個block內(nèi)部的擴(kuò)展因子expansion，因此，排除這些層中的第一個連接層以滿足倍數(shù)關(guān)系；
對仍不滿足要求的層特殊處理，對相同blcok不同執(zhí)行次數(shù)時的expansion控制；
3.2 MobileNetv2 參數(shù)嵌入 v1
3.2.1 遇到問題
將MobileNetV2結(jié)構(gòu)嵌入 MODNet 并不困難，難點在于基于MODNet預(yù)訓(xùn)練模型參數(shù)裁剪后的嵌入、進(jìn)而推理。
在將裁剪后的MobileNetV2模型結(jié)構(gòu)直接嵌入MODNet，開始訓(xùn)練時，提示通道數(shù)不匹配的error，原因在于MobileNetV2只是MODNet中的一部分。
因此，針對這樣的問題，筆者考慮了下列四種方案。
3.2.2 解決方案
方案一：保留 MobileNetV2 模型的 input 以及 output channel，重新裁剪；
方案二：修改 MobileNetV2 前、后模型的關(guān)聯(lián)通道數(shù)；
方案三：將裁剪后的預(yù)訓(xùn)練模型參數(shù)加載到修改后的 MobileNetV2，將其余參數(shù)正常加載到其余三個子模塊，最后合并；
方案四：直接對 MODNet 進(jìn)行裁剪；
3.2.3 探索過程
階段一
易由于已經(jīng)對 MODNet 預(yù)訓(xùn)練參數(shù)中的 MobileNetV2 參數(shù)部分進(jìn)行了裁剪，同時也修改了 MobileNetV2 結(jié)構(gòu)，在單獨對這一子模塊進(jìn)行測試時可以成功嵌入。基于這樣的情況，首先采用方案三。
參數(shù)合并具體作法：通過對象訪問類的成員，即lr_branch、hr_branch、f_branch，在獲取其結(jié)構(gòu)后，從MODNet預(yù)訓(xùn)練參數(shù)中l(wèi)oad對應(yīng)部分的參數(shù)，再結(jié)合已有的backbone，分別替換原來MODNet中的四個子模塊。
替換 backbone 部分：
mobilenet2 = my_mobilenetv2_v2.MobileNetV2(3)
mobilenet2.load_state_dict(torch.load('my_mobilenetv2_2.pth'), strict=False)
modnet.MODNet().backbone = mobilenet2
print(modnet.MODNet().backbone)實際上，該方法是無效的。通過比對替換前后的MODNet中的backbone參數(shù)，可以發(fā)現(xiàn)并非理想的數(shù)值。
階段二
因此，筆者開始尋找有效的參數(shù)替換方法，參考這位博主。
接下來，在LeNet上進(jìn)行實驗。
按照博客上的代碼跑下來出現(xiàn)了一個bug，即缺乏 state_dict 屬性，原因在于只保存了模型參數(shù)，而非整個模型。只有完整的模型才擁有狀態(tài)字典。如下：
由于本次剪枝是針對MODNet預(yù)訓(xùn)練模型參數(shù)，因此，這里按照博客的思路重新調(diào)整語句，如下：
model0 = LeNet()
model1 = LeNet()
# 同一結(jié)構(gòu)，不同參數(shù)
path0 = 'new_model.pth'
path1 = 'new_model1.pth'
params0 = torch.load(path0)
params1 = torch.load(path1)
new_param = {}
for name, params in model0.named_parameters():
new_param[name] = params0[name] + params1[name]
torch.save(new_param, 'new.pth')
model0.load_state_dict(torch.load('new.pth'))
print(list(model0.named_parameters()))params0：
params1：
new_params：(+)
結(jié)果是將兩個同一結(jié)構(gòu)、不同參數(shù)的模型，進(jìn)行求和運算，得到新模型，或者說，實現(xiàn)了參數(shù)修改。
??注意：模型結(jié)構(gòu)不變，只有參數(shù)在變化。
基于此，回到MODNet，繼續(xù)實現(xiàn)。
此時又意識到了一個問題：MODNet中的子結(jié)構(gòu)發(fā)生了變化，也就是說，不僅僅是參數(shù)的替換。
這里有一種方案：
1、根據(jù)剪枝后的情況修改網(wǎng)絡(luò)結(jié)構(gòu)，得到新結(jié)構(gòu)，并保存隨機參數(shù)；
2、將新結(jié)構(gòu)中不含backbone部分的參數(shù)用預(yù)訓(xùn)練模型中的參數(shù)替換，backbone部分使用裁剪后的參數(shù)；
3、保存，得到新結(jié)構(gòu)、新參數(shù)
在實驗過程中遇到了一個error：加載預(yù)訓(xùn)練模型以后，每一次打印的參數(shù)不一致。
相關(guān)代碼如下：
modnet = modnet.MODNet(backbone_pretrained=False)
pretrained_ckpt = torch.load('modnet_photographic_portrait_matting.ckpt')
modnet.load_state_dict(pretrained_ckpt, strict=False)
print(list(modnet.parameters()))這與筆者當(dāng)時的認(rèn)知產(chǎn)生了沖突，通過在LeNet上進(jìn)行實驗，證明了原來的想法是正確的：如果只是初始化對象，此時獲得的模型參數(shù)是隨機的；但當(dāng)加載保存的參數(shù)后，填入網(wǎng)絡(luò)結(jié)構(gòu)的參數(shù)已經(jīng)被固定了下來。
雖然并未找到相同的問題，但有一個相似的問題值得關(guān)注：這里。
其中談?wù)摰膯栴}本質(zhì)在于，采用了多塊GPU并行計算：
model = torch.nn.DataParallel(model)回到MODNet，在作者提供的trainer中，也出現(xiàn)了并行計算的語句。于是，按照這樣的方式修改讀取語句，如下：
modnet = modnet.MODNet(backbone_pretrained=False)
modnet = torch.nn.DataParallel(modnet)
pretrained_ckpt = torch.load('modnet_photographic_portrait_matting.ckpt')
modnet.load_state_dict(pretrained_ckpt, strict=False)
print(list(modnet.parameters()))此時，打印出來的參數(shù)便和預(yù)期的一致了。
不過，在利用對象訪問的形式獲取模型中的子模塊參數(shù)時，依舊是參數(shù)不一致問題。
mobilenet = modnet.MODNet(backbone_pretrained=False).mobilenet猜想其中的原因在于參數(shù)與結(jié)構(gòu)沒有絕對匹配，即這里的mobilenet結(jié)構(gòu)只是ckpt參數(shù)的一部分，雖然沒有出現(xiàn)size mismatch的bug，但還是無法滿足需求。
因此，該方案也就宣布了失??！同時，這也表明最初基于MODNet預(yù)訓(xùn)練模型參數(shù)的裁剪是錯誤的！
階段三
采用方案四，即直接對MODNet模型裁剪。
通過打印輸出可發(fā)現(xiàn)，MODNet總共有72個卷積層，2個全連接層。由于兩個全連接層權(quán)重以及輸入尺寸較大，因此占有較多的參數(shù)，同時，與第二個卷積層相連接的卷積層也有著巨大的參數(shù)量。如下：
而這一卷積層的參數(shù)量將近整個MODNet的1/2，因此，對該層的裁剪不容忽視。
首先排除剪枝時無法被NNI支持的算子：
算子排除有問題，偶然間看到了新版NNI，安裝以后對官方代碼進(jìn)行測試：
雖然NNI2.8 的確可以成功 run 帶有 expand_as 的算子，但從問題本身來看，該算子沒有進(jìn)行處理，即只是官方在源碼中對該算子進(jìn)行了排除，并非如 aten_relu 算子般檢測到以后使用 torch.relu() 進(jìn)行操作。
3.2.4 結(jié)論
雖然 MobileNetV2 只是 MODNet 的一部分，在裁剪時也是針對這部分進(jìn)行了操作，但在修改 MobileNetV2 結(jié)構(gòu)以后，從整個 MODNet 結(jié)構(gòu)來看，與 MobileNetV2 相鄰的結(jié)構(gòu)也相應(yīng)產(chǎn)生了變化，也正表明：剛開始的方案三，針對MobileNetV2以及其余子模塊分別處理的不合理性，而方案一和二也就沒有了必要。
參數(shù)修改的有效辦法并非簡單進(jìn)行結(jié)構(gòu)賦值，而是通過 state_dict 根據(jù)鍵值對替換；
在利用多塊 GPU 并行計算時，需要利用 DataParallel，在保存參數(shù)時需要使用 model.module.state_dict()，而非像往常一樣的 model.state_dict()。雖然后者不會報錯，但需要通過指定 load 時 strict 為 false，才可以將參數(shù)名匹配。當(dāng)然，如果采用前者保存，一方面不需要在 load 時指定 strict，同時也能保證加載到模型的參數(shù)名保持一致。
aten:expand_as 算子在新版的 NNI 源碼中被排除；
對 MODNet 子模塊剪枝較容易，但難以將參數(shù)嵌入；
3.3 MobileNetV2 參數(shù)嵌入 v2
獲取網(wǎng)絡(luò)塊，在將 MODNet 參數(shù)加載到結(jié)構(gòu)后，通過對象訪問獲取 MobileNetv2，參數(shù)可以保持一致。
model = modnet.MODNet(backbone_pretrained=False)
pretrained_ckpt = 'modnet_photographic_portrait_matting.ckpt'
model.load_state_dict({k.replace('module.', ''): v for k, v in torch.load(pretrained_ckpt).items()})
model = model.backbone # 獲取主干網(wǎng)絡(luò)：mobilenet V2
3.3.1 開展思路?
-
按照先前的 config 設(shè)定進(jìn)行剪枝，并對 MobileNetV2 網(wǎng)絡(luò)進(jìn)行修改；
-
將修改后的 MobileNet V2 嵌入 MODNet，得到新的 MODNet，保存一份帶有隨機初始化參數(shù)的模型；
-
按照上述獲取 MobileNet V2 參數(shù)的方式，獲取其余三個子模塊的參數(shù)，保存；
-
讀取2中保存的模型，用3得到的權(quán)重參數(shù)進(jìn)行替換；
-
保存新模型；
3.3.2 探索過程
階段一
ERROR1
分析原因：網(wǎng)絡(luò)結(jié)構(gòu)中backbone外面包裹著model，而模型參數(shù)保存時缺少，因此參數(shù)不匹配。
解決方案：可以通過指定strict = False，當(dāng)然從根源上來看，修改模型保存時的指令（類似多卡訓(xùn)練保存！）
# 將 torch.save(model.state_dict(), PATH)替換為下列語句：
torch.save(model.model.state_dict(), PATH)ERROR 2
分析原因：classifier層的參數(shù)缺失，因此保存參數(shù)時也就缺少了這一部分的權(quán)重參數(shù)。
實際上，先前剪枝同樣遇到了這樣的問題，但在加載時通過指定strict = False，對齊了參數(shù)名以及結(jié)構(gòu)。
解決方案：暫時先以同樣的方式對齊，解決了該問題。
與此同時，證明了這一結(jié)論：如果模型僅保存了部分參數(shù)，當(dāng)加載到網(wǎng)絡(luò)中時，部分參數(shù)可以正常填入，而剩余的部分會隨機初始化。
進(jìn)一步觀察網(wǎng)絡(luò)結(jié)構(gòu)可以發(fā)現(xiàn)，MobileNet V2 中包含 classifier 層，但由于該層用于分類任務(wù)，因此在 MODNet 使用時將其去除，這也就成了剪枝后 classifier 參數(shù)無法對應(yīng)填入的原因。
解決方案：修改MobileNet V2網(wǎng)絡(luò)結(jié)構(gòu)，去除 classifier 的定義。
實驗結(jié)果：
在去除分類層以后，參數(shù)與結(jié)構(gòu)一一對應(yīng)，因此也就不存在上述假設(shè)的問題了。
至此，MobileNet V2 的剪枝、結(jié)構(gòu)修改都已完成。
階段二
先將裁剪后的 MobileNet V2 的參數(shù)替換至 MODNet MobileNet V2 的隨機初始化參數(shù)：
import torch
from src.models.modnet import MODNet
model = MODNet(backbone_pretrained=False)
model_params = torch.load("pruned_backbone_state.pth")
new_params = {}
for name, params in model.named_parameters(): # 隨機初始化參數(shù)，將整個MODNet中的層都打印了出來
if 'backbone' in name: # 將裁剪后的參數(shù)成功填入
new_name = name.replace('backbone.model.', '')
new_params[name] = model_params[new_name]
else:
new_params[name] = params
# print(list(model.named_parameters()))
torch.save(new_params, 'new_substitution_model.pth')替換前后對比如下：
替換前MODNet頭部：
MobileNet V2頭部：
替換以后MODNet頭部：
此時，新模型除了MobileNet V2以外，其他參數(shù)都是隨機的。
接下來，利用新結(jié)構(gòu)加載該模型參數(shù)。
這里的bug讓筆者覺得奇怪，在原先查看權(quán)值參數(shù)時，每一個layer僅僅只有weight與bias，但這里卻出現(xiàn)了其他屬性。
檢查MODNet所有的參數(shù)名并檢查替換后的state_dict：
model = MODNet(backbone_pretrained=False)
d = {name: param for name, param in model.named_parameters()}
print(d.keys())
print(list(new_params.keys()))通過比對兩者參數(shù)，可以發(fā)現(xiàn)：數(shù)量與參數(shù)名都一致。
有一個值得考慮的地方：在參數(shù)替換時利用了 named_parameters() 獲取模型參數(shù)，因此檢驗兩者固然相同。但是，named_parameters() 本身是否真的獲取到了模型所有參數(shù)呢？
查閱資料可知：named_parameters() 對于獲取BN layer來說，只有兩個可學(xué)習(xí)參數(shù)alpha、belta，而running_mean以及running_var，作為兩個不可學(xué)習(xí)的統(tǒng)計量只有在model.state_dict()的時候輸出。其作用在于作為訓(xùn)練過程對batch的數(shù)據(jù)統(tǒng)計。
基于此，由于這些參數(shù)對實際推理不起作用，直接用規(guī)定strict進(jìn)行加載。
階段三
模擬推理
import torch
from src.models.modnet import MODNet
from time import time
model = MODNet(backbone_pretrained=False)
model.load_state_dict(torch.load('new_substitution_model.pth'), strict=False)
print(list(model.named_parameters()))
# inference
dummy_input = torch.randn([1, 3, 512, 512]).to('cpu')
t1 = time()
a = model(dummy_input)
t2 = time()
print("Infer time: ", t2 - t1)ERROR 1
分析原因：在對mobilenet v2裁剪后，其最后一層的output channel從1280-->640，無法去下一個模塊的input channel 匹配。
解決方案：排除mobilenet v2最后一層，保留1280的channels，重新剪枝。
ERROR 2
下列是筆者debug解決bug的過程，或許只是對筆者有意義罷了??，感興趣的伙伴可以看一下~~
debug尋找到產(chǎn)生bug的語句，定位到HRBranch模塊：
觀察中間變量可以發(fā)現(xiàn)，enc2x的shape與bug顯示的input一致：
于是，進(jìn)入HR Branch，定位到enc2x的定義：
可以看到兩個channels定義，向上索引找到MODNet中HR Branch的初始化地方：
可知hr_channels為32，enc_channels用同樣的方法，索引到backbone中：
至此，便可明確enc_2x定義時的通道數(shù)數(shù)值：
這也正好對應(yīng)上了bug中的weight尺寸：[32, 16, 1, 1]。
由于目前尚未明確input如何從上一層的輸出：[1,1,32,32] ---> [1,16,256,256]（模塊交界處）
因此可以修改權(quán)重shap： 16 ---> 8.
至此，該問題成功解決！
這里的enc_channels和mobilenet v2中的interverted_residual channels相關(guān)。
參考剪枝前模型的enc_channels設(shè)置修改：32--->16，96--->48
32--->16：產(chǎn)生了上述類似的錯誤，因此暫時保持不變。
96--->48：成功load！
然而，成功load并未加載裁剪后的參數(shù)，起初是為了分解問題。
目前，結(jié)構(gòu)本身的推理已經(jīng)能夠成功執(zhí)行！
階段四
加載參數(shù)，填入模型。
ERROR 1
將channel從96--->48后導(dǎo)致ckpt中的參數(shù)shape無法與model中的shape匹配，所以，先恢復(fù)到96。
ERROR 2
結(jié)合上述的兩個問題，如果將8--->16，那么模型本身子模塊間的匹配就不再滿足。這是一個矛盾點！
因此，在已有的正確MODNet結(jié)構(gòu)的基礎(chǔ)上，重新填入裁剪后的參數(shù)，保存模型，成功加載！
但channel從96--->48是一個遺憾，這里再次嘗試設(shè)置48。
實際上，這個問題和ERROR6異曲同工（參數(shù)shape > 結(jié)構(gòu)中的shape），成功解決！
實驗結(jié)果
①參數(shù)量
對比channels從96--->48的MODNet參數(shù)量對比：
| 通道數(shù)為96 | 通道數(shù)為48 | 剪枝前 | |
| 參數(shù)量 | 4.93M? | 3.36M | 6.45M |
②推理時延
| 剪枝前 | 剪枝后 | |
| 1 | 0.834 | 0.665 |
| 2 | 0.875 | 0.690 |
| 3 | 0.822 | 0.680 |
寫在最后
本文在分析了 MODNet 結(jié)構(gòu)特性后，先針對主干網(wǎng)絡(luò)MobileNetV2部分進(jìn)行剪枝，基于L2范數(shù)方法，在剪枝完成后進(jìn)行參數(shù)替換。盡管遇到了許多坎坷，但都一一克服，最后成功完成了剪枝，并將其嵌入MODNet！
接下來，筆者將分享對MODNet其他模塊的剪枝、以及MODNet剪枝的探索過程！文章來源：http://www.zghlxwxcb.cn/news/detail-814259.html
希望本文的一些歷程可以為小伙伴們帶來啟發(fā)~~文章來源地址http://www.zghlxwxcb.cn/news/detail-814259.html
到了這里，關(guān)于對MODNet 主干網(wǎng)絡(luò) MobileNetV2的剪枝探索的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
