Horace He氏は先頃、"The State of Machine Learning Frameworks in 2019"と題した要約記事を公開した。記事の中で氏は、研究分野において短期間で主流となったPyTorchと、商用/産業分野で展開されるアプリケーションのための主力的なフレームワークであるTensorFlowについて、いくつかの基準値を基に論じている。
コーネル大学の研究生であるHe氏は、ECCV、NIPS、ACL、NAACL、ICML、CVPR、ICCV、EMNLPといった、著名なマシンラーニング関係のカンファレンスで発表された、PyTorchとTensorFlowを論じた論文数をカウントした。結果から言うならば、2019年に開催されたすべての主要なカンファレンスにおいて、大半の論文がPyTorchを使って実装を行っていた。画像関係のカンファレンスでは2対1、言語関係のカンファレンスでは3対1の比率で、PyTorchがTensorFlowを上回っていたのだ。ICLRやICMLといった、より一般的なマシンラーニングのカンファレンスで公開された論文においても、PyTorchの参照数が多かった。
PyTorchが優勢になった理由のひとつに氏が挙げたのは、そのシンプルさである。TensorFlowよりも使用が簡単なのだ。APIは直感的で、(少なくとも)受容できるレベルのパフォーマンスを備えている。
その一方で、著者の基準値によって評価した産業界での採用度では、依然としてTensorFlowがリーダであった。その基準値とは、求人数、GitHubでの人気度、メディアにおける記事の数などだ。学界と産業界の格差が3倍になっている理由について、氏はいくつかの仮説を立てた。最初に挙げたのは、Pythonランタイムの持つオーバーヘッドを、可能ならば回避したいと多くの企業が考えているから、ということだ。2つめの理由は、PyTorchにはモバイル"エッジ"MLのサポートがないためだ。偶然にも、今月初めにリリースされたバージョン1.3では、Facebookの手によるモバイルサポートがPyTorchに追加されている。第3の理由は、開発サービスに関わる機能不足である。すなわち、TensorFlowで開発された同等のシステムに比較すると、PyTorchシステムは、運用段階に持ち込むことが難しいのだ。
この数年間で、PyTorchとTensorFlowは、いくつかの面で収束しつつある。PyTorchに"Torchscript"とJITコンパイラが導入されたのに対して、TensorFlowはバージョン2.0から、実行を"Eager Mode"に移行すると発表している。Torchscriptは、基本的にはPyTorchのグラフ表現である。コードからグラフを取得するということは、モデルをC++でデプロイして、最適化することが可能になる、ということを意味する。一方、TensorFlowのEager Modeは、グラフを構築せずにオペレーションを即時評価する、命令型プログラミング環境を提供するもので、利点と欠点の両面においてPyTorchのEager Modeと同等である。デバッグは容易になるが、モデルをPython外部にエクスポートして最適化したり、モバイル上で実行することなどは不可能になる。
2つのフレームワークは将来的に、今よりもっと近いものになるだろう。新たな競合者が現れて、コード生成や高階分化などの分野で両者に挑む可能性もある。競合者の候補として、氏が挙げるのはJAXだ。人気の高いAutogradプロジェクトに従事したメンバが開発したもので、順方向と逆方向の両方の自動微分を備える。これによって、"PyTorch/TensorFlowが提供可能なものよりも、はるかに高速な"高次導関数の計算が可能になる。
記事の筆者であるHorace He氏への連絡は、Twitter経由で行うことができる。記事で使用されたデータセットの生成に使用されたコードとインタラクティブなチャートは、いずれも公開されている。