mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roshani Nagmote <roshaninagmo...@gmail.com>
Subject Request for suggestions- Supporting onnx in mxnet
Date Wed, 18 Oct 2017 20:41:52 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message