2019 ディープラーニング フレームワーク対決: PyTorch がトップ AI カンファレンスを席巻し、NeurIPS 2019 で再び優勝!

最近、Reddit のホットな投稿が機械学習コミュニティで大きな議論を巻き起こしました。

NeurIPS 2019 で使用された機械学習フレームワーク: PyTorch 68->166、TensorFlow 91->74

ポスターの Horace He はコーネル大学の学生であり、コンパイラと機械学習の交差点を研究対象としています。彼は、NeurIPS 2019 の論文で使用された機械学習フレームワークを分析し、2018 年と比較して、PyTorch を使用した論文の数は今年は 68 件から 166 件に増加し、TensorFlow を使用した論文の数は 91 件から 74 件に減少したことを発見しました。

論文数で見ると、2018年と比較すると、PyTorchを使用した論文数が大幅に増加し、TensorFlowは若干減少しています。

PyTorchはTensorFlow/PyTorchに言及している論文の69%を占めている

これは、先月彼が書いた「2019 年の機械学習フレームワークの現状」という記事を裏付けるもので、研究分野では PyTorch の成長が TensorFlow をはるかに上回っており、研究者が TensorFlow を放棄して PyTorch に集まっていることを指摘しています。同時に、業界では Tensorflow が依然として好まれるフレームワークですが、長期的にはそうではないかもしれません。

PyTorch と Tensorflow の成長を比較したこの包括的な分析は当時多くの議論を巻き起こしましたが、一部の人々は「これらの結果は NLP カンファレンスにのみ当てはまるのか」と疑問を呈しました。

さて、NeurIPS カンファレンスの結果を分析すると、答えは「ノー」です。

動的グラフ/PyTorch は NLP コミュニティでのみ人気があると考えている人もいます。明らかに、そうではありません。

これらの分析結果から判断すると、PyTorch は機械学習、コンピューター ビジョン、自然言語処理などのディープラーニング研究を支配しており、Yann LeCun 氏もこれに同意しています。

Yann LeCun: NeurIPS19 の論文で使用されたディープラーニング フレームワークの 69% 以上で PyTorch が言及されていました。 PyTorch はディープラーニング研究 (ML/CV/NLP カンファレンス) を支配してきました。

上の図からわかるように、主要な ML/CV/NLP カンファレンスでは、PyTorch を使用した論文の数は引き続き大幅に増加している一方で、TensorFlow の成長率は鈍化、あるいはわずかに減少しています。

主要なトップカンファレンスに採択される論文数は年々増加していることを考えると、絶対数だけを見ても現実を完全に反映することはできません。上の図は、PyTorch/TensorFlow を使用した論文の総数に対する割合を示しており、この傾向がより明確に示されています。

Redditユーザー: TensorFlowからPyTorchへの切り替えは本当に良い

この傾向の原因は何でしょうか? PyTorch は本当に、多くの研究者が TensorFlow を放棄して PyTorch に集まるほど便利なのでしょうか?

Reddit ユーザーのコメントから判断すると、PyTorch に切り替えた人は皆、それが「本当に良かった」と言っています。

私は過去 2 年間 Keras/TF を使用してきましたが、最近になって PyTorch に切り替えました。今では、PyTorch がとても気に入っています。はるかに簡潔でわかりやすいと思います。あくまでも私の個人的な意見です。

私は PyTorch を使用して、さまざまな奇妙なトレーニング、バックプロパゲーション グラフなどを備えた新しいモデルを設計するのが大好きです。 PyTorch を使用すると、標準モデルをすぐにデプロイできない場合でも、独自のカスタム アルゴリズムを設計する自由度が高くなると感じています。おそらくそれが主に研究に使われる理由でしょう。

私はしばらくの間、Tensorflow/Keras を使用しています。私が覚えている結論は、Tensorflow は本番環境への展開に適しており、PyTorch は研究に適していたというものでした。最近 PyTorch を使い始めましたが、とても気に入っており、より「Python らしい」感じがします。さらに、ONNX などのフレームワークを使用すると、(よく知られているモデルの) デプロイメントの問題が少なくなります。どちらも引き続き使用していきます。

Tensorflow 2.0 と PyTorch の選択は難しいです。

私は Tensorflow が好きですし、PyTorch も好きです。

TF は開発ベースで、PyTorch は研究ベースです。

両方必要です。私の意見では、どちらも同等です。 50-50

長い間、TensorFlow には PyTorch にはなかった「本番環境向け」の機能が数多くありました。例えば、モバイルデバイスへのデプロイ、Python 環境なしでの実行が可能、モデルのパフォーマンスを最大化する方法 (量子化など) が多数あります。

モデルを本番環境にデプロイする場合、TF は依然として業界の第一の選択肢です。 PyTorch の生産パイプラインをそれほどひどくしない限り、この状況は続くでしょう。

全体的に、ネットユーザーの経験はホレス・ホー氏の分析とほぼ一致している。しかし、PyTorch の利点は何でしょうか? Horace He 氏の記事では、両者のそれぞれの特徴、利点、欠点も慎重に分析し、機械学習フレームワークの将来について議論しています。

2019 年の機械学習フレームワークの戦いは、PyTorch か TensorFlow か?

2012 年にディープラーニングが再び注目を集めて以来、多くの機械学習フレームワークが研究者や業界の専門家の新たなお気に入りになるために競い合ってきました。初期の学術的成果である Caffe や Theano から、業界で広くサポートされている PyTorch や TensorFlow まで、数多くの選択肢がある中で、最も人気があるのはどれでしょうか?

Reddit だけを閲覧している場合は、誰もが PyTorch を使用していると思われるかもしれません。 Francois Chollet 氏の Twitter から判断すると、TensorFlow または Keras が主流になり、PyTorch は停滞している可能性があります。

2019 年、機械学習フレームワーク戦争には PyTorch と TensorFlow という 2 つの主要な競合相手がいます。分析によると、研究者は TensorFlow を放棄し、PyTorch に大勢集まっているようです。一方、業界では現在、Tensorflow がプラットフォームとして選ばれていますが、長期的にはそうではないかもしれません。

研究におけるPyTorchの優位性は拡大し続けている

まずはデータを見てみましょう。下の図は、2017 年から 2019 年までの主要な機械学習カンファレンスで、PyTorch のみに言及した論文と TensorFlow または PyTorch を使用した論文の比率を示しています。ご覧のとおり、すべての線は上向きに傾斜しており、2019 年のすべての主要なカンファレンスでは、論文の大部分が PyTorch で実装されていました。

詳細については、https://chillee.github.io/pytorch-vs-tensorflow/ を参照してください。

PyTorch が学術界でどれだけ急速に成長しているかについてさらに証拠が必要な場合は、PyTorch と TensorFlow の言及数を比較したグラフをご覧ください。

PyTorchとTensorFlowの個別言及数

2018 年当時、PyTorch はまだ少数派でした。現在、PyTorch は主流であり、CVPR の 69%、NAACL と ACL の 75% 以上、ICLR と ICML の 50% 以上が PyTorch を使用しています。 PyTorch の優位性はビジョンと言語のカンファレンスで最も強くなっていますが (PyTorch 対 TensorFlow で 2:1 と 3:1)、ICLR や ICML などの定期的な機械学習カンファレンスでも TensorFlow よりも人気があります。

PyTorch は、TensorFlow が支配する世界でニッチな市場を切り開こうとしている新興フレームワークであると主張する人もいますが、データはそうではないことを示しています。 TensorFlow の成長は、ICML を除くすべてのカンファレンスでの論文の全体的な成長と一致しています。 NAACL、ICLR、ACL では、Tensorflow に関する今年の論文数は昨年より実は少なかったです。

PyTorch は自身の将来について心配する必要はありません。心配する必要があるのは TensorFlow です。

研究者はなぜ PyTorch を好むのでしょうか?

• 単純。これは numpy に似ており、非常に Python 的であり、Python エコシステムの他の部分と簡単に統合できます。たとえば、PyTorch モデルの任意の場所に pdb ブレークポイントを挿入するだけで機能します。 TensorFlow では、モデルのデバッグにはアクティブなセッションが必要となり、より複雑になります。
• 素晴らしいAPIです。ほとんどの研究者は、TensorFlow の API よりも PyTorch の API を好みます。 1 つの理由は、PyTorch の方が設計が優れていることであり、もう 1 つの理由は、TensorFlow が API を複数回切り替えることによって機能不全に陥っていることです (例: 'layers' -> 'slim' -> 'estimators' -> 'tf.keras')。
• パフォーマンス。 PyTorch の動的グラフでは最適化の機会がほとんどないにもかかわらず、PyTorch は TensorFlow と同等かそれ以上に高速であるという逸話的な報告が数多くあります。これが実際に真実であるかどうかは明らかではありませんが、少なくとも、TensorFlow はまだこの分野で決定的な優位性を獲得していません。

TensorFlow の研究展望は何ですか?

TensorFlow は機能面では PyTorch と同等ですが、PyTorch はすでにコミュニティの大部分をカバーしています。つまり、PyTorch が見つけやすくなり、著者は PyTorch でコードを公開するインセンティブが高まり (人々が使用できるようになるため)、共同作業者も PyTorch を好む可能性が高くなります。したがって、Tensorflow 2.0 への移行は、もし行われるとしても、遅くなる可能性があります。

TensorFlow は Google/DeepMind 内で常に一定の支持を得ていますが、Google が最終的に諦めるかどうかは不明です。現在でも、Google が採用したいと考えている研究者の多くは、さまざまなレベルで PyTorch を好んでおり、Google 社内の多くの研究者が TensorFlow 以外のフレームワークを使いたいと考えているという不満が聞こえてきます。

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

PyTorchとTensorFlowを本番環境に導入

現在、研究分野では PyTorch が主流ですが、業界では TensorFlow が依然として主流のフレームワークです。たとえば、2018 年から 2019 年までの求人サイトのデータによると、TensorFlow には 1,541 件の新規求人があり、PyTorch には 1,437 件の新規求人がありました。 TensorFlow には 3,230 件の Medium 記事がありますが、PyTorch には 1,200 件あります。また、TensorFlow には 13,700 件の GitHub スターがありますが、PyTorch には 7,200 件あります。

では、PyTorch が学術界で非常に人気があるのに、産業界ではなぜ同様の成功を収めていないのでしょうか?明らかな最初の答えは慣性です。 Tensorflow は PyTorch より数年前に登場しましたが、業界は研究者よりも新しいテクノロジーの導入が遅れています。もう 1 つの理由は、本番環境での使用には TensorFlow の方が PyTorch よりも優れているということです。しかし、これは何を意味するのでしょうか?

この質問に答えるには、研究者と産業界のニーズがどのように異なるかを知る必要があります。

研究者は、研究をどれだけ速く行えるかを重視します。研究は通常、比較的小さなデータセット (1 台のマシンに収まるもの) で行われ、8 個未満の GPU で実行されます。通常、研究者はパフォーマンスよりも速度、つまりどちらが新しいアイデアを迅速に実装できるかを考慮します。むしろ、業界ではパフォーマンスが最優先事項であると考えています。プロセスの速度を 10 パーセント上げることは研究者にとっては何の意味もないかもしれませんが、企業にとっては直接的に数百万ドルの節約につながる可能性があります。

もう 1 つの違いは展開です。研究者は、自分のコンピューターまたは研究作業専用のサーバー クラスターで実験を実行します。それどころか、業界には多くの制限や要件があります。

• Pythonはありません。サーバーを運用している企業の中には、Python を実行するための高いオーバーヘッドを負担できないところもあります。
• 動く。 Python インタープリターをモバイル バイナリに埋め込むことはできません。
• 仕える。ノンストップのモデル更新、シームレスなモデル切り替え、予測時のバッチ処理などの包括的な機能セット。

TensorFlow はこれらのニーズに合わせて特別に構築されており、すべてのニーズに対応するソリューションを提供します。グラフ形式と実行エンジンはネイティブで Python を必要とせず、TensorFlow Lite と TensorFlow Serving はそれぞれモバイルとサービングを念頭に置いて構築されています。

歴史的に、PyTorch はこれらの考慮事項を満たすことができず、結果として、ほとんどの企業は現在、本番環境で TensorFlow を使用しています。

Tensorflow イーガー

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

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

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

したがって、TensorFlow の Eager モードでは、実際には「両方の長所」を実現することはできません。 tf を使用してコードを静的グラフに変換することは可能ですが、シームレスなプロセスではありません。コードのトレースには制限があり、Python コードを再解釈するには、基本的に Python コンパイラの大部分を書き直す必要があります。もちろん、ディープラーニングに使用される Python のサブセットに限定することで、範囲を大幅に簡素化できます。

PyTorchは研究の世界を支配し、TensorFlowは産業界の世界を支配している

これまでのところ、機械学習フレームワークの現状は次のように結論づけられています。

• 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 では大きな進歩が遂げられています。

• Google の業界からの孤立は同社に悪影響を及ぼすでしょうか?

Google が TensorFlow を推進している主な理由の 1 つは、急速に成長しているクラウド サービスを支援することです。 Google は ML 分野全体を独占しようとしているため、競合企業 (Microsoft、Amazon、Nvidia など) が唯一の代替機械学習フレームワークである PyTorch をサポートするよう促される可能性があります。

機械学習フレームワークの次のステップ: 高階微分とコード生成

次は何か

おそらく過小評価されているかもしれませんが、機械学習フレームワークは ML 研究に大きな影響を与えています。これらは機械学習の研究を可能にするだけでなく、研究者が簡単に探求できるアイデアを可能にしたり、それらのアイデアに制約を課したりすることもできます。フレームワークで簡単に表現できないというだけの理由で、どれだけの初期のアイディアが潰されてきたでしょうか? PyTorch はすでにローカル研究の最小要件を満たしているかもしれませんが、他のフレームワークが何を提供し、どのような研究機会を可能にするかを探ることは価値があります。

高階微分:

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

ただし、高次の導関数 (ヘッセ行列/ヘッセ行列ベクトルの内積) を計算する場合は状況が変わります。これらを効率的に計算するには、「順方向モード自動微分」と呼ばれるものが必要です。この機能がなければ、ヘッセ行列ベクトルの内積の計算は桁違いに遅くなる可能性があります。

Jax は Autograd と同じ開発者によって構築され、順方向モードと逆方向モードの両方の自動微分機能を備えています。これにより、PyTorch/TensorFlow よりも桁違いに高速に高次導関数を計算できるようになります。

ただし、Jax は単なる高次導関数以上のものを提供します。 Jax 開発者は、Jax を、vmap (自動バッチ処理用) や pmap (自動並列化用) などの任意の関数変換を構成するためのフレームワークと見なしています。

オリジナルの autograd には熱心な支持者がおり (ICML の 11 の論文では GPU サポートがないにもかかわらず autograd が使用されました)、Jax もすぐに同様に熱心なコミュニティを形成し、あらゆる種類の n 次導関数に autograd が使用されるようになるでしょう。

コード生成

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

しかし、非標準ハードウェア、スパース/量子化テンソル、新しい演算子に対する最近の関心により、これらの演算子ライブラリに依存することの大きな欠陥が明らかになりました。つまり、柔軟性に欠けるということです。カプセル ネットワークなどの新しい演算子を研究で使用したい場合は、どうしますか? ML フレームワークでサポートされていない新しいハードウェア アクセラレータでモデルを実行したい場合はどうすればよいでしょうか?既存のソリューションでは不十分な場合がよくあります。

新しいハードウェア構造、テンソル クラス、または演算子が追加されるたびに、この問題の難易度は大幅に増加します。これを処理できるツールは数多くあります (Halide、TVM、PlaidML、Tensor Comprehensions、XLA、Taco など) が、正しい方法はまだ 1 つではありません。

この問題に対処するためにさらなる取り組みを投資しなければ、ML 研究が既存のツールに過剰適合してしまう危険性があります。

機械学習フレームワークの未来

TensorFlow と PyTorch の将来にとって、今はエキサイティングな時期です。それぞれの設計は、単一のフレームワークが設計によって決定的に勝利することはないという点まで収束しています。双方とも独自の領域を切り開き、一方は研究の世界、他方は産業界の領域を占めている。

個人的には、PyTorch と TensorFlow のうち、私は PyTorch を好む傾向があります。機械学習は依然として研究主導の分野です。業界は研究結果を無視することはできず、PyTorch が研究を支配している限り、企業は PyTorch に切り替えざるを得なくなるでしょう。

しかし、急速に進化しているのはフレームワークだけではありません。機械学習の研究自体は急速に変化しています。フレームワークが変化するだけでなく、5年後に使用されるモデル、ハードウェア、パラダイムも、現在使用されているものとは大きく異なる可能性があります。おそらく、別のコンピューティング モデルが主流になるにつれて、PyTorch 対 TensorFlow の議論は意味をなさなくなるでしょう。

私たちのほとんどは、お金を稼ぐため、あるいは企業の戦略的取り組みを支援するために機械学習に取り組んでいるわけではありません。私たちが機械学習を行うのは、機械学習の研究を前進させること、AI を民主化すること、あるいは単に興味深いものを構築することに関心があるからです。 TensorFlow と PyTorch のどちらを好むかに関わらず、私たちは機械学習ソフトウェアを最高のものにするために一生懸命取り組んでいます。