ニューラルネットの共通フォーマット対決! NNEF vs ONNX

遠藤です。

ニューラルネット界隈では、Caffe、TensorFlow、Chainer をはじめ、数々のフレームワークが群雄割拠の様相を呈しております。弊社でも、プロジェクトに応じて適宜フレームワークを使い分け、日々の業務にあたっております。

多数のフレームワークを扱っていると「あっちのフレームワークで学習したモデルを、こっちのフレームワークで使いたい!」といった、フレームワーク間をまたいでモデルを共有したいというニーズが出てきます。そのために、フレームワーク間で共通して使える交換フォーマットが開発されるようになりました。

そこで、今回はニューラルネットの共通フォーマットとして NNEF と ONNX の2つをご紹介したいと思います。

NNEF とは?

概要

NNEF は、Khronos Group が発表した交換フレームワークです。Khronos Group といえば、弊社ともかかわりが深い OpenCL などの開発元であります。

NNEFでは、ネットワークはテキストとして、重みはバイナリファイルとしてそれぞれ表現されます。例えば、 NNEF のドキュメントによると AlexNet は次のようなテキストで表現されます。

特徴

NNEFの特徴は「ネットワークの表現力」です。これは、ネットワーク構造と、量子化の2つの面でいうことができます。

まず、ネットワーク構造における表現力について説明します。これは、あるまとまった単位のネットワークを “fragment” として定義し、fragment を組み合わせることでより大きなネットワークを表現できるということです。例えば GoogLeNet を例にとると、inception モジュールというネットワークの単位があり、それを複数個つなげることで、階層的で複雑なネットワークが構成されています。Caffe 等でネットワークを表現する場合は、inception モジュールは展開され階層のないフラットなネットワークとして表現されます。NNEF を使うと、inception モジュールの階層性を残したまま、わかりやすいネットワークの表現が可能です。これは、Chainer 等のフレームワークにおけるネットワーク表現のわかりやすさと似ていると考えられます。

次に、量子化における表現力について説明します。ネットワークをエッジ側で動かす際には、INT8 や FP16 のようにビット幅を減らし量子化することがあります。普通は重みもそれに合わせて量子化したものを保存するのですが、NNEF では表現方法が違います。何故かというと、NNEF はプラットフォーム非依存の表現を目指しており、量子化した生データといったプラットフォーム依存の表現をそのまま入れたくないという事情があるからです。そこで、NNEFでは以下に示すように、量子化を実数を入力とする数式として表現しています。ドキュメントには線形量子化と対数量子化の2種類が定義されていますが、それ以外の量子化もやろうと思えば fragment として定義することができるのではないかと思います。

サポート状況

本記事の執筆時点では、 Caffe と TensorFlow から NNEF へのコンバータが公式の GitHub に公開されています。残念ながら、それ以外のフレームワークからのコンバータは現時点では公開されていません。

また、NNEF をインポートして推論を行うソフトウェアも、現時点では公開されていませんでした。

ONNX とは?

概要

ONNX は、Facebook などが中心となって開発し現在はオープンに公開されているネットワーク交換フォーマットです。元々は Caffe2 と PyTorch 間でのモデルの交換を意図して開発されたもののようです。現在は、より多くのフレームワークが ONNX をサポートしています。

NNEF がテキストベースでネットワークを記述するのに対し、ONNX は単一のバイナリファイルでネットワークとパラメータを表現します。

特徴

ONNX の特徴は、仕様がシンプルであるという点です。NNEF では階層的なネットワーク記述を許していた一方で、ONNX では階層を持たないフラットなネットワーク記述となっています。また、量子化についても量子化済みの重みがそのまま記述されるような仕組みとなっています。NNEF と比べると表現力は劣りますが、その分シンプルな仕様にまとまっています。

また、データのバイナリ化には Caffe や Tensorflow 等と同じく Protocol Buffer 形式を採用している点も特徴です。既存のフレームワークと共通のライブラリを使うことで、ONNX の対応コストを下げる効果がありそうです。

これらは、フレームワーク間でのモデルのやり取りをやるために必要十分なものを作ろうという点で、NNEF とは設計思想の違いを感じます。

サポート状況

ONNX は、様々なフレームワークでサポートされています。公式のドキュメントで公開されているものは以下のとおりです。

  • ONNX モデルへの変換 (エクスポート)
    • Caffe2
    • PyTorch
    • CNTK
    • Chainer
  • ONNX モデルを用いた推論 (インポート)
    • Caffe2
    • CNTK
    • MXNet
    • TensorFlow
    • Apple CoreML
    • TensorRT (ただしサンプルコードが未公開)

NNEF と ONNX の違いは?

NNEF と ONNF の違いを表にまとめてみました。

Format Pros Cons
NNEF
  • テキストベースなので読みやすい
  • 仕様の柔軟性が高く、複雑な構造のネットワークを書きやすい
  • サポートされているフレームワーク・推論エンジンの数が少ない
  • 仕様が複雑で、import/export の難易度が高そう
ONNX
  • 対応しているフレームワークが豊富
  • 単一ファイルで扱いやすい
  • Model Zoo がある
  • protobuf なのでパーサが簡単に生成できる
  • バイナリなのでファイルの中身が人間にはよくわからない
  • 量子化時に数値表現が機械上での表現に引きずられる

結局どちらを使えばいい?

本記事執筆時点では、NNEF はサポート状況が弱いため、実質的な選択肢は ONNX のみです。しかし、NNEF は現在開発中のステータスであり、今後サポートされるフレームワーク等が増えていくことが予想されます。

ニューラルネットワークのフレームワークだけでなく、今後はファイルフォーマットでも競争が起こっていきそうです。究極のメニューと至高のメニューのように双方がしのぎを削り、より使いやすく、より広く使うことのできる共通フォーマットへと成長していくことを見守っていきたいと思います。

次は、実際に ONNF を用いてモデルをやり取りしてみるコードを実際に書いて、動作を確かめてみたいと思います。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です