Hi guys,
I am working on supporting ONNX <https://github.com/onnx/onnx> pre-trained models in Apache MXNet and would like to seek your opinion on the choice of implementation. I also have created a GitHub issue <https://github.com/apache/incubator-mxnet/issues/8319>. Supporting ONNX in MXNet will enable users to move between frameworks with their models, this will also enable MXNet project to be a part of the ONNX open standard and steer the direction of ONNX. For those who don’t know ONNX, ONNX is an open source format for AI models which enables models to be transferred between frameworks. Refer to https://github.com/onnx/onnx for more details. To implement the import/export functionality in MXNet, I propose to expose a MXNet python module “serde”(name taken from Apache Hive project) with the following methods supporting different formats: sym, params = mxnet.serde.import(other_format_file, other_format=‘onnx’) other_format_file = mxnet.serde.export(mxnet_sym, mxnet_params, ‘onnx’) The implementation under the hood can be done in two ways: 1) Implement at the MXNet layer by parsing the ONNX model(in protobuf format) and turn into MXNet Symbolic operators and build MXNet model directly. Similarly, I can convert the MXNet model to ONNX format at this layer. 2) The DMLC community has released the nnvm/tvm complier and an intermediate representation of the models, refer: http://www.tvmlang.org/2017/10/06/nnvm/tvm-compiler-announcement.html <http://www.tvmlang.org/2017/10/06/nnvm-compiler-announcement.html> Based on the conversation on the GitHub issue <https://github.com/apache/incubator-mxnet/issues/8319> I opened, Mu mentioned that MXNet would use nnvm/tvm as the backend in the future. We could hook into this layer to implement the import/export functionality. nnvm/tvm has ONNX 0.1 version import implemented. For import, 1. I will need to enhance nnvm/tvm’s importer to support ONNX 0.2 2. Implement nnvm/tvm->mxnet symbolic operators. For export: 1. mxnet->nnvm/tvm ( nnvm/tvm provides this implementation already) 2. I will need to Implement nnvm/tvm>onnx. These are the pros and cons I see in the above approaches: 1. Import/export at mxnet layer Pros: 1. Stable APIs currently used by users. 2. Larger Apache MXNet community of contributors. 3. CI pipeline to catch bugs. 4. Comparatively less time to implement and put it in the hands of the users. Cons: 1. In the future we may have to reimplement at the nnvm/tvm layer, in case MXNet moves to the nnvm/tvm backend(assuming it will move). 1. Import/export at nnvm/tvm layer Pros: 1. Less engineering work in case mxnet moves to nnvm/tvm 2. nnvm/tvm would become a hub to convert to different formats. 3. nnvm operators are more in parity with mxnet’s gluon APIs this could be useful in case Gluon becomes the only standard that MXNet will support. Cons: 1. Nascent project with few contributors 2. Does not support all operators that exist in MXNet Symbolic API 3. No CI Pipeline 4. Current Apache MXNet project does not use nnvm/tvm backend 5. mxnet->nnvm/tvm backend needs more testing and user feedback. Any suggestions on both of these approaches? From user's perspective, this will be an implementation detail that is not exposed. Thanks, Roshani
