Deep Learningモデルのオープンなフォーマット「ONNX」形式とはなんなのか
ソニーさんのブログには以下のように説明されてます。
ONNXはDeep Learningモデルのオープンなファイルフォーマットで、各社からリリースされている多数のDeep Learningのフレームワーク、ライブラリがこれに対応しています。
公式ページ(英語)はここです。
目指すところは、「アイデアをより迅速に本番に投入することを可能にするために、モデルを1つのフレームワークで訓練し、推論のために別のフレームワークに転送する等の相互利用を簡単にする」ことです。
発展途上でじわじわと対応フレームワークが増えていっているところで、2018/10/27時点の対応状況はこんな感じです。
フレームワーク | インストール | ONNX形式出力 | ONNX形式ロード(取込み) |
Caffe2 | part of caffe2 package | 〇 | 〇 |
PyTorch | part of pytorch package | 〇(拡張) | ×(対応中) |
Cognitive Toolkit (CNTK) | built-in | 〇 | 〇 |
Apache MXNet | part of mxnet package docs github | 〇 | 〇 |
Chainer | chainer/onnx-chainer | 〇 | ×(対応中) |
TensorFlow | onnx/onnx-tensorflow | 〇 | △(実験的) |
Apple CoreML | onnx/onnx-coreml and onnx/onnxmltools | 〇 | 〇 |
SciKit-Learn | onnx/onnxmltools | 〇 | × |
ML.NET | built-in | 〇 | 〇 |
Menoh | pfnet-research/menoh | × | 〇 |
MATLAB | onnx converter on matlab central file exchange | 〇 | 〇 |
あと、上記表にはないのですが、以下については、ONNXからコンバートツールが提供されています。
- scikit-learn
- CoreMLTools
- Keras
- LightGBM (scikit-learn interface)
ひとつのフレームワークだけを見ると、得手不得手ができてきます。
だから。
学習したモデルを実務で使うため、相互変換して使いたいってことはありそうなので、
こういう取り組みは、どんどんすすめてほしいです。
実際にONNX形式をダウンロードしてみる
今度はONNX形式を実際にダウンロードして、中身を見てみたいと思います。
Neural Network Consoleクラウドを使います。
使ったことがない方は、アカウント登録からお願いします。
さて。
Neural Network Consoleクラウドで、サンプルプロジェクトで学習します。
そうすると、学習の最後の方で「ONNX」形式のアウトプットが生成されるようです。
NNabla command line interface (Version 1.0.5.console_day3-fix-181003, Build 181003062836)
2018-10-27 03:19:12,782 [worker]: [INFO]: create result_train.nnp
2018-10-27 03:19:13,827 [worker]: [INFO]: create result.nnb
2018-10-27 03:19:17,058 [worker]: [INFO]: create result.onnx
2018-10-27 03:19:19,487 [worker]: [INFO]: worker done
すると、ダウンロードのメニューにONNXがでてきます。
生成されたONNXファイルはこんな感じです。
テキストで読める部分もありますが、まあ、バイナリフォーマットですね。
Caffe や Tensorflow 等と同じ Protocol Buffer 形式だそうです。
これを実際に取り込んでみるのはやりません。
興味があれば、こちらの記事をどうぞ。
さて、どの程度普及するのでしょうか
標準化仕様にはONNX以外に、NNEFってのがあります。
NNEFは「Neural Network Exchange Format」の略です。
NNEFは、テキストベースで読みやすく、かつ、仕様の柔軟性が高く、複雑な構造のネットワークを書きやすいなど、技術的にはONNXより優れた仕様みたいなのですが、その分仕様が複雑です。
ONNXの方は逆で、仕様の柔軟性や拡張性よりも、仕様のシンプルにしたり、Protocol Buffer 形式みたいな汎用的な技術を取り入れるなど、各フレームワーク側の対応コストを下げるような工夫を重視している感じです。
そのせいか。
対応しているフレームワークはONNXの方が圧倒的に多いです。
NNEFはCaffe と TensorFlow位だったんじゃないかと思います。
NNEFの「NNEF Working Group Participants」には、SONYもはいっているので、Neural Network Consoleも対応してくるのかもしれないのですけど・・。
なんか、よく見る構図です。
- 技術的に優れているけど、仕様が複雑で対応にコストがかかる方
- 技術的には相手に見劣りしても、仕様がシンプルで対応コストがかからない方
この両者の派遣争い。
でも、歴史的に見ると、だいたい後者の方が勝ち残ってるんですよね。
どうなるかはわからないですが・・。
ONNXって、どこまで普及するのでしょうか。
なんか、浅くてすいません。
ではでは。