Dahan Gong

可以参考 https://github.com/THU-MIG/torch-model-compression/blob/main/torchpruner/DOCUMENT.md#operator-注册 来写一个新算子支持解析Softplus。

考虑到Softplus是逐元素操作，可以直接用 onnx_operator.onnx_pw，也就是写 `operator_reg.regist("Softplus", onnx_operator.onnx_pw)`

重训练看看吧。普通分类模型确实不会掉这么多，往往是一次就一两点，分割的话我不太熟 ---原始邮件--- 发件人: ***@***.***> 发送时间: 2022年1月11日(周二) 晚上8:22 收件人: ***@***.***>; 抄送: "Dahan ***@***.******@***.***>; 主题: Re: [THU-MIG/torch-model-compression] demo中剪枝后预测结果差距很大？ (Issue #8) 考虑到Softplus是逐元素操作，可以直接用 onnx_operator.onnx_pw，也就是写 operator_reg.regist("Softplus", onnx_operator.onnx_pw) 谢谢，已经可以使用了。我仅仅按照1%的比例剪枝，剪完后的mAP是43，而不剪的时候是93，性能掉的有点多，这情况正常吗 — Reply to this email directly, view...

`_sample_to_device`改的没问题；显存增加有很多可能的原因，首先要测测不剪枝或者量化的时候会不会增加。 比如，也许是`calculate_loss_function` 里缓存了什么？PyTorch会追踪tensor是经过了哪些算子得出的，所以如果forward的输出被缓存下来了，那每次迭代都记录的很多东西都跟着被缓存了，最后就肯定爆显存。 下边那个RuntimeError 可以被跳过去，我提交了新代码，你更新下。 `qat.py`的地方谢谢提醒。

你能跑完2个batch吗？还是只跑了1个batch就崩出来了？ - 如果是只能跑1个，那就是batch太大了，显存不够反向传播用 - 如果跑了好几个batch才错，那才可能是泄露 - 如果是跑完1个epoch就报错，可能是eval的batch太大了，显存不够跑验证集的 `torchslim/quantizing/qat_tools.py#export_trt` 这里已经设置了 `trt.BuilderFlag.INT8`，应该是int8保存的。大小差不多的原因不太清楚，更可能的是tensorrt自己存了很多算子优化融合的编译结果之类的东西。测一下速度就知道了，int8和fp32速度上大概会有区别的。

`evaluate` 有点问题，最后返回的时候，需要把tensor转成python float，你改成 `{"...": -loss_value.item()}`试试

正常吧，eval的时候也需要大量显存，建议改小一点batch size重新试，有时候连train的batch size也要改小以留出空间。 可以用很小的数据集来测，比如train 5个batch就算一个epoch，然后就做eval，这样测起来快。

`Softplus` 的问题也是项目里有个地方弄错了，写成`SoftPlus`了。刚提交了代码修正它。现在可以不额外注册onnx op了。

Um, not yet. Since it varies among devices and flops percentages, it's a bit too hard to write a table for it.

有道理啊。感觉这行是测试用的代码，提交时没改回去。可以手动改，或者直接用标准的 resnet，比如 `torchvision.models.resnet18`