pytorch 转换onnx_珍爱生命，远离模型转换

1. 面临的问题

在开源项目群里，经常有同学问“xxx转xxx应该怎么办/为什么转完了结果不对”，然后是一通调试甚至怀疑人生。

1.1 训练框架不统一

在做模型转换前，首先要搞清这个问题出现的根本原因：

搞训练的大神们就像纪晓岚手下的文人，相互之间谁也不服谁，总觉得我可以做的比他好（事实也的确如此），然后创造了各种轮子。尽管大家都懂 onnx 的好处，能否重视起来并且完全兼容全靠自觉。除非这个行业遇冷，不然不会一堆人突然转性要大搞兼容。所以在公司里想统一训练框架，一定是靠类似行政的命令强制统一。

1.2 layer 满天飞

最近几年各种训练方法层出不穷，光视觉检测任务至少就流行过 yolo/rfcn/ssd 三大类，每一类都需要特定 layer 才能支持；更不要提其他类型的任务。外加训练框架、分支问题（例如ssd 只有caffe的一个fork分支才兼容）、layer实现问题（例如pooling向上向下取整），每次我面对形式各样的模型（caffe/pytorch/tf/keras/kaldi/mxnet，甚至有基于lua开发的），内心是崩溃的。

2. 解法

根据个人经历，提供以上问题的解决方法。仅供参考。

2.1 规范入口

训练用什么都好，部署交付的结构必须一致。经过一番调研，caffe 和 onnx 兼容性最好，早期所有训练框架都能导出为 caffe。因此做推理的只收 caffe 模型。

偶尔有同学会说，“论文作者用的keras，别的框架不支持，所以我只能给你keras格式”。该怎么办你懂的。

2.2 自研推理库

对于AI公司，自研推理库是有必要的。抛开“生态”、“核心竞争力”不提，仍有以下好处：

1）咱们不必为了支持SSD 每天切换使用的 caffe 分支；

2）训模师若要使用新方法，新的 layer 可以立即支持。只服务内部需求，不会产生版本冲突。

2.3 生命苦短，我用 python

人生苦短，我早早地（2年前）放弃了 C++ 转换模型的方法，转而用 python。在这个过程中发现了以下优点，与各位分享：

1）工作量少了很多。即便是新手入门，也只需3-4天便可完成 caffe2xxx 的 python 开发；

2）python django等框架可以轻易地（1天学习django api足够）部署一个web应用，专门用来做模型转换；

3）web可以简单轻松地让训模师使用 shape inference，定义好网络结构不必训练就知道速度。免除了训练结束后发现速度有问题又返工的尴尬；

4）不需要写代码编译就能做性能测试，出测试报告极度方便。打开浏览器，翻历史记录就行。

关于为啥偏爱web ... 扪心自问，除了作者本人，真的有人想敲一个黑乎乎、错误百出、环境依赖严重的命令行么？真的有人愿意花大把时间了解你的工作么？

或者说，推理在整个项目里到底有多重要？

我们以后再讨论这个问题，先来波商业互吹：

ncnn “可能”将发布 web 版模型转换工具，目前是测试版，以后妈妈再也不用担心转换出错了。