AI開発は断片化に直面しており、ディープラーニングフレームワークの統一が必要

人工知能の急速な発展の背後には、大手メーカー間の秘密戦争の始まりがあります。誰もが開発者をめぐって競い合い、独自のディープラーニング開発フレームワークを立ち上げています。しかし、アプリケーションがさまざまなシナリオでますます重要になるにつれて、断片化されたフレームワークも開発者に問題を引き起こし、開発フレームワークを統一する必要があります。

[[252714]]

AI 開発は断片化に直面しており、ディープラーニング フレームワークを統一する必要がある (画像は FactorDaily より)

ディープラーニングの利点は、従来の手動による特徴取得に代わる、教師なしまたは半教師ありの特徴学習と階層的特徴抽出の効率的なアルゴリズムを使用することです。この目的のために、Microsoft、Google、Amazon などの IT 大手は、ディープラーニング関連のプロジェクトに投資し、フレームワーク ツールを開発しています。CNTK、TensorFlow、MXNet はすべてこれらの企業によってサポートされています。さらに、Caffe、Torch、Theano も人気のある開発フレームワークです。

開発者にとって、これらのフレームワークを使用する特徴や機能はさまざまであり、アプリケーション シナリオにはコンピューター ビジョン、音声認識、自然言語処理、バイオインフォマティクスなどが含まれることもあります。 TensorFlow の場合、ユーザーは Theano と同様にバックプロパゲーションを通じて勾配を解決する必要がなくなり、ニューラル ネットワーク構造を設計するときに C++ または CUDA コードを記述するのに多くの労力を費やす必要がなくなります。

使用中、C++ はオンライン展開の複雑さを軽減し、携帯電話、タブレット、ウェアラブルデバイス、および集中的な処理リソースを消費するその他の端末で、より複雑なモデルを実行できるようにします。比較すると、Python のリソース消費は依然として比較的高いレベルにあることに注意してください。これにより、開発者は、比較的十分なハードウェア パフォーマンスを備えたマシンで Python を使用する場合でも、低レイテンシの組み込み環境で C++ を使用できるようになります。もちろん、TensorFlow にも問題はあります。たとえば、異種デバイス間の通信の最適化はまだ改善が必要です。

Theano は、同種のライブラリの中で最も古いものの 1 つであり、ディープラーニングの元来の主要な標準の 1 つです。その人気により、ユーザーはトレーニング モデルの保存方法や実行方法など、さまざまな一般的な問題を Theano で見つけることができます。単一の GPU での実行効率も非常に優れています。さらに、多数のディープラーニングライブラリが Theano をベースに派生しています。たとえば、Keras のニューラルネットワークの抽象化により、実行バックエンドを自由に切り替えることができます。

ただし、Theano には基盤となる C++ インターフェイスがないため、展開が不便であり、産業生産環境ではほとんど使用されません。そのため、最終製品というよりも研究ツールとして捉えている人も多く、CPU のパフォーマンスが低いこともこの点の障害となっています。したがって、このフレームワークは原始的な言語のようなもので、開発者がこれを直接使用してニューラル ネットワークを設計したり、その出力情報を読み取ったりするのは困難です。

さらに、Caffe、Deeplearning4J などにも独自の問題がありますが、ここでは詳しく説明しません。これによって、開発者はディープラーニング開発プラットフォームをどのように選択すべきかという疑問も生じます。考慮すべき点がいくつかあります。まず、ほとんどの企業の AI アーキテクチャはゼロから構築されているわけではなく、既存のプログラミング プラットフォームを統合することの難しさは無視できません。次に、機械学習ソフトウェア パッケージやデータ処理との互換性も追求する必要があります。最後に、二次開発機能も同様に重要です。分散型のマルチ GPU 最適化機能では、他のプラットフォームでどのように役割を果たすかを検討する必要があります。

いくつかの主流のディープラーニング開発フレームワークを比較すると、C++ (Caffe、MXNet、CNTK、TensorFlow) と C (Torch) が基盤言語の大部分を占めており、現在最も効率的であることがわかります。Python は次世代のプラットフォーム言語になると予想されており、これは Microsoft が CNTK 2.0 で取り組んでいる方向性でもあります。

生態学的観点から見ると、各企業の枠組みは依然としてある程度異なるチームに分かれています。開発者はそれぞれのプラットフォームで独自の開発を行う必要があり、これらのフレームワークは更新時に統一されていません。つまり、開発者が 1 つのフレームワークで開発したニューラル ネットワーク モデルを、別のフレームワークで直接使用することはできません。両者を互換性のあるものにするためには、開発者が自ら解決するために多大な労力を費やす必要があります。

この問題を解決するには、開発者の「主権」を握るマイクロソフトやグーグルなどの企業が立ち上がり、互換性のあるフレームワークを使って開発者の体験を統一する必要がある。この考えに基づいて設立されたのがONNX（Open Neural Network Exchange）だ。これはマイクロソフトが共同で始めたプロジェクトで、FacebookやAWSなどのソフトウェアメーカーのほか、AMD、ARM、Huawei、IBM、Intel、Qualcommなどの業界関係者が参加している。たとえば、ONNX を使用すると、開発者は PyTorch でトレーニングされたモデルを推論のために Caffe2 に直接配置できます。

ONNX はほぼ 2 ～ 4 か月ごとにアップグレードされます。たとえば、ユーザーが新しいモデルを作成できるように、いくつかの新しい演算子が追加されます。実際、Microsoft の主力製品である Bing、広告、Office、ビジュアル サービスは、基本的にすべてバックグラウンドで ONNX を使用しています。これを基に、Microsoft は ONNX ランタイムもリリースしました。プラグイン エグゼキュータ インターフェイスにより、ONNX ランタイムはソフトウェアとハ​​ードウェアの改善に迅速に適応できます。 Executor インターフェイスは、ハードウェア アクセラレータがパフォーマンスを ONNX ランタイムに報告するための標準的な方法です。 Intel と NVIDIA は、ONNX ランタイムをハードウェア アクセラレータに統合しています。現在、Intel の MKL-DNN、nGraph コンパイラ、NVIDIA の最適化された TensorRT 推論エンジンが統合されています。

ONNX がより多くのオープンソース フレームワークを吸収するにつれて、すべてのメーカーが同じ姿勢をとるわけではありません。たとえば、TensorFlow の ONNX への関心はそれほど明確ではありません。実際、Microsoft は TensorFlow から ONNX へのコンバーターも作成しています。このような変換機能により、TensorFlow の多くのモデルを実際に ONNX に転送できます。さらに、ONNX は、主に音声および言語機能をサポートするために使用される LSTM などの非常に高レベルまたは特殊な演算子もサポートしています。

AI分野で成功したいのであれば、ハードウェアとソフトウェアの両方を組み合わせる必要があるため、ONNXのような橋渡しが必要になります。これまでは、異なるインターフェースやインターフェイスが開発者に大きな混乱をもたらしていましたが、ONNXはハードウェアとアプリケーションを有機的に組み合わせ、クラウド、ローカル、エッジなどあらゆる環境に展開することができます。この観点から、AI開発フレームワークの統一が必須となります。