2019 年の機械学習フレームワークの戦い: Tensorflow との競争は熾烈、進化する PyTorch はどこで勝利するのか?

[[278853]]

ビッグデータダイジェスト制作

出典: thegradient

翻訳者: 張大毓如、曹培鑫、劉俊環、牛万洋、アンディ

2019 年、機械学習フレームワーク間の競争は新たな段階に入り、PyTorch と TensorFlow が最後の 2 大プレーヤーとなりました。PyTorch は学術界で主導的な地位を占めており、TensorFlow は産業界で依然として強力な存在です。どちらのフレームワークも互いに学び合っていますが、どちらも理想的ではありません。

最終的に誰が勝つでしょうか? それは、いくつかの重要な質問に誰がよりうまく答えられるかにかかっています。

コーネル大学の Horace He 氏は、2019 年の 2 つの主要な機械学習フレームワーク間の競争について論じた長い記事を Gradient に掲載しました。氏は PyTorch と TensorFlow の長所と短所、開発動向について論じましたが、彼が PyTorch、特に学術分野におけるその牽引役についてより楽観的であることは明らかです。

偶然にも、今日は PyTorch 1.3 がリリースされた日です。最新バージョンでは、より多くの産業用機能、量子化、端末サポートが追加されています。 PyTorch の担当者は、モデルの解釈可能性をサポートし、マルチモーダル研究を製品化するために、他の多くのツールやライブラリもリリースする予定だと述べた。

PyTorch 1.3 公式リリースリンク:

https://PyTorch.org/blog/PyTorch-1-dot-3-adds-mobile-privacy-quantization-and-named-tensors/

機械学習の将来にとって、PyTorch と TensorFlow のどちらが優れていると思いますか? お気軽にメッセージをお寄せください。

全文は次のとおりです。

2012 年にディープラーニングが再び注目を集めて以来、多くの機械学習フレームワークも研究者や業界の専門家の間で新たな人気を博しています。

Caffe や Theano などの初期の学術的な取り組みから、大規模な業界でサポートされている PyTorch や TensorFlow まで、選択肢が非常に多いため、最適なフレームワークが何であるかを判断するのは難しい場合があります。

Reddit を見ると、PyTorch が大流行していると思うかもしれません。しかし、機械学習の第一人者 Francois Chollet の Twitter フィードを閲覧していたら、TensorFlow/Keras が主流のフレームワークだと考えるかもしれません。

2019 年、機械学習フレームワークの戦いは PyTorch と TensorFlow の対決が主流でした。

私の分析によると、学術分野では研究者が徐々に TensorFlow を放棄し、PyTorch に集まってきています。一方、産業分野では TensorFlow がプラットフォームとして選ばれていますが、その状態は長く続かないかもしれません。

1. PyTorchは研究でますます優位に立っている

まず第一に、もちろん、データ自体が語るようにしましょう。

次のグラフは、TensorFlow または PyTorch を使用するトップ研究会議に採択された論文の比率を示しています。破線はすべて上向きに傾いており、2019年は主要なカンファレンスの論文のほとんどでPyTorchが使用されていたことがわかります。

会議論文のデータだけでは不十分だと思うなら、PyTorch が研究コミュニティで注目を集めるスピードを証明する別の図があります。

下の図は、さまざまなカンファレンスで PyTorch と TensorFlow が言及された回数を示しています。

2018 年、PyTorch は比較的注目されませんでした。しかし現在、ほとんどの人が PyTorch を使用しています。CVPR の 69%、NAACL と ACL の 75% 以上、ICLR と ICML の 50% 以上も PyTorch を使用しています。

PyTorch の優位性はビジョンカンファレンスと言語カンファレンスで最も顕著で、それぞれ 2:1 と 3:1 の比率で TensorFlow を上回りました。また、ICLRやICMLなどの一般的な機械学習カンファレンスでも、TensorFlowよりもPyTorchの方が人気が高いことがわかります。

PyTorch はまだまったく新しいフレームワークであり、TensorFlow が支配する世界でシェアを獲得しようとしていると考える人もいますが、データはそうではないことを示しています。 ICML に加えて、NAACL、ICLR、ACL などのカンファレンスでも、今年は全体的に TensorFlow に関する論文が昨年よりも少なくなっています。

つまり、パニックになっているのは PyTorch ではなく、TensorFlow です。

1. 研究者が PyTorch を好むのはなぜですか?

単純。 PyTorch は numpy に似ており、非常に Python 的であり、Python エコシステムの他の部分と簡単に統合できます。たとえば、PyTorch モデル内の任意の場所に pdb ブレークポイントを追加できます。 TensorFlow では、モデルをデバッグするにはアクティブなセッションが必要であり、プロセス全体が非常に面倒になります。

API。ほとんどの研究者は、TensorFlow の API よりも PyTorch の API を好みます。これは、PyTorch の設計が優れていることと、TensorFlow が API インターフェースを頻繁に切り替えた (「layers」-「slim」-「estimators」-「tf.keras」など) ため、TensorFlow の開発が妨げられたことが原因です。

パフォーマンス。 PyTorch の動的グラフでは最適化の機会がほとんどありませんが、多くの事例報告によると、PyTorch は TensorFlow よりもそれほど遅くないようです。これが真実かどうかは明らかではありませんが、少なくとも、TensorFlow はこの点で決定的な優位性を獲得していません。

2. TensorFlow の今後の研究の方向性は何ですか?

TensorFlow は機能面では PyTorch と同等ですが、PyTorch はすでに機械学習コミュニティの大部分をカバーしています。つまり、PyTorch の実装が見つけやすくなり、作成者は PyTorch でコードをリリースする動機が高まり、共同作業者も PyTorch を好む可能性が高くなります。したがって、TensorFlow 2.0 へのバックポートは遅くなる可能性があります。

TensorFlow は Google/Deepmind 内で忠実な支持者を抱えていますが、この点に関して Google が最終的に揺らぐかどうかは不明です。現在、Google が採用したい研究者の多くが PyTorch を好むようになり、Google 社内の多くの研究者が TensorFlow 以外のフレームワークを使いたいと考えているという不満も耳にしています。

さらに、PyTorch の優位性により、Google の研究者は他の研究コミュニティから切り離される可能性があります。外部の研究に基づいて構築するのは難しいだけでなく、外部の研究者が Google によってリリースされたコードに基づいて構築する可能性も低くなります。

TensorFlow 2.0 が以前のファンを取り戻せるかどうかはまだ分からない。イーガーモードは魅力的ですが、Keras API の場合はそうではありません。

2. 産業向け PyTorch と TensorFlow

現在、研究分野では PyTorch が主流ですが、少し注意してみると、TensorFlow が依然として主要なフレームワークであることがわかります。

たとえば、2018 年から 2019 年のデータに基づくと、TensorFlow の求人情報ページには 1,541 件の新規求人が掲載されたのに対し、PyTorch では 1,437 件、Medium には TensorFlow の新規記事が 3,230 件、PyTorch では 1,200 件、GitHub では TensorFlow のスターが 13.7K 件、PyTorch では 7.2K 件でした。

では、なぜ PyTorch は現在研究者の間で非常に人気があるのに、産業界ではまだ同様の成功を収めていないのでしょうか?

明らかな最初の答えは使用習慣です。 TensorFlow は PyTorch より数年前に登場しましたが、業界は研究者よりも新しいテクノロジーの導入が遅れています。

もう 1 つの理由は、業界への適応という点では TensorFlow が PyTorch よりも優れていることです。これは何を意味するのでしょうか。この質問に答えるには、研究者と業界のニーズがどのように異なるかを知る必要があります。

研究者は、通常、比較的小さなデータセット (単一のマシンで実行できるもの) を対象に、8 つの GPU で実行される研究をどれだけ速く反復できるかを重視します。これは通常、パフォーマンス上の理由ではなく、アイデアを迅速に実装できるようにするためです。

一方、業界ではパフォーマンスが最優先事項であると考えています。実行時間の 10% の改善は研究者にとってはあまり意味がないかもしれませんが、企業にとっては直接的に数百万ドルの節約につながります。

もう 1 つの違いは展開です。研究者は通常、自分のマシン上、または研究作業専用のサーバークラスター上で実験を実行します。ただし、業界では、展開には一連の制限と要件があります。

Pythonはありません。 Python を実行するとサーバーに負担がかかりすぎます。
動く。モバイル端末バイナリに Python インタープリターを埋め込むことはできません。
仕える。ダウンタイムなしでのモデルの更新、モデル間のシームレスな切り替え、予測時のバッチ処理など、包括的な機能が必要です。

TensorFlow はこれらのニーズに合わせて特別に構築されており、これらすべての問題に対するソリューションを提供します。ネットワークグラフ形式と実行エンジン自体は Python を必要とせず、TensorFlow Lite と TensorFlow Serving はそれぞれモバイル端末とサーバーの要件を処理できます。

歴史的に、PyTorch はこれらのニーズを十分に満たしていないため、ほとんどの企業は現在、本番環境で TensorFlow を使用しています。

3. 建築の「融合」

2018 年後半、2 つの大きな出来事がこの状況を完全に変えました。

PyTorch は、JIT コンパイラと「TorchScript」を導入することでグラフベースの機能を導入しました。

TensorFlow は、バージョン 2.0 でデフォルトで Eager モードに移行することを発表しました。

明らかに、これらの動きは PyTorch と TensorFlow のそれぞれの弱点を解決することを目的としています。では、これらの機能とは具体的に何であり、何を提供するのでしょうか?

1. PyTorch トーチスクリプト

PyTorch JIT は、TorchScript と呼ばれる PyTorch の中間表現 (IR) です。 Torchscript は PyTorch の「グラフ」表現です。トレースモードまたはスクリプトモードを使用して、通常の PyTorch モデルを TorchScript に変換できます。トレースでは、関数と入力を受け取り、その入力で実行された操作を記録し、IR を構築します。

追跡はシンプルですが、欠点もあります。たとえば、実行されていない制御フローをキャプチャすることはできません。たとえば、true ブロックを実行すると、条件ブロックの false ブロックをキャプチャできません。

スクリプトモードは関数/クラスを受け入れ、Python コードを再解釈して TorchScript IR を直接出力します。これにより任意のコードがサポートされますが、実際には Python を再解釈する必要があります。

PyTorch モデルがこの IR に入ると、グラフモードのすべての利点を活用できるようになります。 Python に依存せずに C++ で PyTorch モデルをデプロイするか、最適化することができます。

2. TensorFlow Eager

API レベルでは、TensorFlow Eager モードは基本的に PyTorch Eager モードと同じです。PyTorch Eager モードはもともと Chainer によって導入されたもので、TensorFlow に PyTorch Eager モードの利点のほとんど (使いやすさ、デバッグ可能性など) を提供します。

ただし、これにより TensorFlow にも同じ欠点が生じます。 TensorFlow Eager モデルは、Python 以外の環境にエクスポートしたり、最適化したり、モバイルデバイスで実行したりすることはできません。

これにより、TensorFlow は PyTorch と同じ位置に置かれ、ほぼ同じ方法で解釈されます。つまり、コードをトレースしたり (tf.function)、Python コードを再解釈したり (Autograph) できます。

したがって、TensorFlow の Eager モードでは、実際には「両方の長所」を実現することはできません。 tf.function アノテーションを使用して Eager コードを静的グラフに変換することは可能ですが、これはシームレスなプロセスにはなりません (PyTorch の TorchScript にも同様の問題があります)。トレースは基本的に制限されており、Python コードを再解釈するには、実際には Python コンパイラの大部分を書き直す必要があります。

もちろん、ディープラーニングで使用される Python のサブセットに制限することで、範囲を大幅に簡素化できます。

デフォルトで Eager モードが有効になっていると、TensorFlow はユーザーに選択を迫ります。使いやすさを重視して Eager 実行を使用し、デプロイメントのために書き直す必要があるか、Eager 実行をまったく使用しないかです。

これは PyTorch の場合と同じ状況ですが、PyTorch の TorchScript のオプトインの性質は、TensorFlow の「デフォルトでの先行」よりも受け入れやすいかもしれません。

IV. 機械学習フレームワークの現状

PyTorch は研究分野をリードしており、産業分野への拡大を目指しています。 TensorFlow は、産業上の利点をあまり犠牲にすることなく、研究分野への関与をさらに深めようとしています。

PyTorch が業界に意味のある影響を与えるまでには確かに長い時間がかかるでしょう。結局のところ、TensorFlow の業界への影響はすでに深く根付いています。ただし、TensorFlow 1.0 から 2.0 への切り替えは、企業にとって PyTorch を評価する絶好の機会となります。

将来については、以下の問題を誰が最もうまく解決できるかにかかっています。

研究者の好みは業界にどの程度の影響を与えるのでしょうか? 現在の博士課程の学生が卒業し始めると、彼らは PyTorch の知識を持ち込むかもしれません。企業が採用要件として PyTorch を選択するほどの勢いがあるでしょうか? また、卒業生は PyTorch をベースにしたスタートアップを立ち上げるでしょうか?
TensorFlow の Eager モードは、使いやすさの面で PyTorch に追いつくことができるでしょうか? オンラインでの反応から判断すると、TensorFlow Eager はパフォーマンス/メモリの問題に深刻な問題を抱えており、Autograph にも独自の問題があります。 Googleはエンジニアリングに多大な労力を費やすだろうが、TensorFlowには依然として歴史的な負担が残っている
PyTorch は業界のニーズをどのくらい早く満たせるでしょうか? PyTorch にはまだ解決されていない基本的な問題が数多くあります。たとえば、適切な定量的サポートがない、モバイルがサポートされていないなどです。これらの問題が解決されるまで、PyTorch は多くの企業にとって選択肢にさえなりません。 PyTorch は、企業が移行するのに十分な説得力のあるストーリーを提供できるでしょうか? 注: PyTorch は量子化とモバイルのサポートを発表しました。どちらもまだ実験段階ですが、この分野における PyTorch の大きな進歩を表しています。
Google が業界で孤立することで TensorFlow は打撃を受けるでしょうか? Google が TensorFlow を推進している主な理由の 1 つは、同社のクラウドサービスの繁栄を支援することです。 Google は機械学習の分野全体を独占しようとしているため、Google と競合する企業 (Microsoft、Amazon、Nvidia など) は PyTorch のみをサポートするようになりました。

5. 次のステップは何ですか?

機械学習フレームワークは機械学習研究にどの程度影響を与えますか?

機械学習の研究が可能になるだけでなく、研究者の調査も容易になります。フレームワークで簡単に表現できないために、どれだけの新しいアイデアが抑制されているでしょうか? PyTorch は研究の極小値に達しましたが、調査する価値のある他のフレームワークにはどのようなものがあるでしょうか? どのような研究の機会があるでしょうか?

1. 高階微分計算の問題点

PyTorch と TensorFlow の中核となるのは、関数を微分化できる自動微分フレームワークです。自動微分を実装する方法は多数ありますが、ほとんどの最新の機械学習フレームワークで選択される方法は「逆モード自動微分」と呼ばれ、一般的には「バックプロパゲーション」として知られています。この実装は、ニューラルネットワークの導出に非常に効率的です。

ただし、高次の導関数 (ヘッセ行列/ヘッセ行列ベクトル積) を計算するときに問題が発生します。効率的な計算にはフォワードモードの自動微分が必要です。この機能がないと、ヘッセ行列ベクトル積の計算速度が 1 桁遅くなります。

Jax は、もともと Autograd を構築した同じ人々によって作成され、順方向および逆方向モードの自動微分機能を備えており、PyTorch/TensorFlow よりも高速に高次導関数を計算できます。

また、Jax は高階導関数を計算できるだけでなく、Jax 開発者は、vmap (自動バッチ処理用) や pmap (自動並列化用) などの任意の関数変換を構成するためのフレームワークとして Jax を考えています。

Jax の初期のユーザーは主に大学卒業生です (GPU サポートがないにもかかわらず、ICML ではこれを使用した論文が 11 件ありました)。しかし、Jax はすぐに同様に忠実なファンコミュニティを見つけ、あらゆる種類の n 次導関数を実行するために使用するようになると思います。

2. 柔軟性が足りない!

PyTorch/TensorFlow モデルを実行する場合、ほとんどの作業は実際にはフレームワーク自体ではなく、サードパーティのカーネルによって実行されます。これらのカーネルは通常、MKLDNN (CPU 用) や cuDNN (Nvidia GPU 用) と同様にハードウェアベンダーによって提供され、高レベルのフレームワークが活用できる演算子のライブラリで構成されています。高レベルのフレームワークは計算グラフをブロックに分割し、計算ライブラリを呼び出します。これらのライブラリは何千時間もの作業の成果であり、アーキテクチャとアプリケーションのパフォーマンスが最高になるように最適化されています。

しかし、非標準ハードウェア、スパース/量子化テンソル、新しい演算子の最近の人気により、これらの演算子ライブラリに依存することの欠陥が明らかになりました。つまり、柔軟性が十分ではないのです。研究でカプセルネットワークなどの新しい操作を使用したい場合、どうすればよいでしょうか。既存のソリューションは十分に完璧ではありません。論文に示されているように、GPU 上の既存のカプセルネットワーク実装は、最先端の実装よりも 2 桁ほど遅くなります。

新しいハードウェアアーキテクチャ、テンソルのクラス、または演算子が追加されるたびに、問題の難易度は大幅に増加します。 Halide、TVM、PlaidML、TensorComprehensions、XLA、Taco など、すでに多くの処理ツールが存在しますが、正しい方法はまだ見つかっていません。

この問題が解決されなければ、機械学習の研究がそのツールに過剰適合してしまう危険があります。

6. 機械学習フレームワークの将来

TensorFlow と PyTorch の将来については、その設計はより一貫性のあるものになっています。設計によって最終的な勝利を収めるフレームワークは 1 つもありません。また、それぞれに独自の領域があり、一方には研究領域、もう一方には産業領域があります。

個人的には、PyTorch と TensorFlow を比較すると、PyTorch の方が勝つ可能性が高いと思います。機械学習は依然として研究主導の分野であるため、業界は研究結果を無視することはできません。PyTorch が研究分野を支配している限り、企業は変革を余儀なくされるでしょう。

ただし、十分に高速に実行されるのはフレームワークだけではありません。機械学習の研究自体も大きな変革の真っ只中にあります。フレームワークが変化しただけでなく、5 年前に使用されていたモデル、ハードウェア、パラダイムも現在使用されているものとはまったく異なります。将来的には、別のコンピューティングモデルが優勢になるため、PyTorch と TensorFlow の戦いは意味をなさなくなるかもしれません。

こうした利害が対立する中で、機械学習に多額の資金が投資されていることは、考えてみると悪いことではありません。機械学習ソフトウェアに取り組んでいる人のほとんどは、お金を稼ぐためでも、会社の戦略計画を支援するためでもなく、機械学習の研究を発展させたい、AI の民主化に関心がある、あるいは単に何かクールなものを作りたいと考えているのです。

したがって、TensorFlow と PyTorch のどちらを好むかに関係なく、それらの目的は 1 つだけであり、それは機械学習を最高のものにすることです。