作者 | Horace He

翻譯 | MrBear

對於機器學習科研工作者和工業界從業人員來說，熟練掌握一種機器學習框架是必備技能之一。隨著深度學習技術發展的突飛猛進，機器學習框架市場也漸漸度過了初期野蠻生長的階段。大浪淘沙，目前仍然活躍的機器學習框架主要是 PyTorch 和 TensorFlow。本文從學術界和工業界兩個方面深度盤點了 2019 年機器學習框架的發展趨勢。

自 2012 年深度學習再度成為萬眾矚目的技術以來，各種機器學習框架爭相成為研究人員和從業者的新寵，可謂「你方唱罷我登場」。從早期在學術界廣為使用的 Caffe 和 Theano，到業界推崇的 PyTorch 和 TensorFlow，各種各樣可供選擇的學習框架使得人們很難確定「誰才是真正最主流的框架」。

如果你僅僅通過瀏覽 Reddit 來做出判斷，你可能會認為每個人都在轉而使用 PyTorch；而如果你根據 Francois Chollet 推特中的內容做出判斷，你會發現 TensorFlow 或 Keras 可能是主流的框架，而 PyTorch 的勢頭正在衰減。

回顧 2019 年，機器學習框架之爭中還剩下兩個競爭者：PyTorch 和 TensorFlow。我的分析表明，研究人員正在放棄 TensorFlow 並紛紛轉向使用 PyTorch。然而與此同時，在工業界，TensorFlow 目前則是首選的平臺，但這種情況可能不會持續太久。

一、PyTorch 在研究領域日益佔據主導地位

讓我們用數據說話！下圖顯示了在近些年的研究頂會中，僅僅使用了 PyTorch 框架進行研究的論文數和使用了 TensorFlow 或 PyTorch 的論文總數的比例。如圖所示，每條曲線（代表不同的會議）都向上傾斜（意味著 PyTorch 的佔比越來越高），而且在 2019 年的每個主要的會議中，大多數的論文都採用 PyTorch 實現。

• 會議的圖例

• 數據收集過程的細節

這些圖表的交互式版本鏈接如下：https://chillee.github.io/pytorch-vs-tensorflow/

如果你需要更多的證據來說明 PyTorch 在研究社區中獲得關注的速度有多快，請看下面關於 PyTorch 和 TensorFlow 使用情況的原始統計圖。

在 2018 年，PyTorch 在深度學習框架中的佔比還很小。而現在，PyTorch 已成佔據壓倒性比重的多數。據統計，69% 的 CVPR 論文、75% 以上的 NAACL 和 ACL 論文，以及 50% 以上的 ICLR 和 ICML 論文都選擇使用 PyTorch。PyTorch 在視覺和語言類的會議上（分別以 2:1 和 3:1 的比例超過了 TensorFlow）被使用的頻繁度最為明顯，而且 PyTorch 在 ICLR 和 ICML 等通用機器學習會議上也比 TensorFlow 更受歡迎。

雖然有些人認為 PyTorch 仍然是一個處於萌芽期的框架，試圖在 Tensorflow 主導的世界中開闢出一片市場，但真實的數據卻說明事實並非如此。除了在 ICML 上，其它學術會議中使用 TensorFlow 的論文的增長率甚至還趕不上整體論文數量的增長率。在 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」）從而限制了自己的易用性。

• 卓越的性能。儘管 PyTorch 的動態圖留給我們優化的機會很少，但是已經有很多有趣的報道說明 PyTorch 的運行速度和 TensorFlow 一樣快（https://www.reddit.com/r/MachineLearning/comments/cvcbu6/d_why_is_pytorch_as_fast_as_and_sometimes_faster/），甚至更快（https://arxiv.org/abs/1608.07249）。目前尚不清楚這種說法是否屬實，但至少，TensorFlow 在這個方面並沒有獲得絕對的優勢。

2、TensorFlow 在研究領域的前景如何？

即使 TensorFlow 在功能方面與 PyTorch 的水平差不多，但是 PyTorch 已經擁有了研究社區中的大多數用戶。這意味著我們更容易找到 PyTorch 版本的算法實現，而作者也會更有動力發佈 PyTorch版本的代碼（這樣人們就會使用它），而你的合作者們很可能也更喜歡 PyTorch。因此，如果將代碼移植回 TensorFlow 2.0 平臺，這將會是一個很漫長的過程（如果真的這麼做了）。

TensorFlow 在 Google/DeepMind 內部總會有一批固定的用戶，但我不知道 Google 最終是否會放開這一點。即使是現在，很多 Google 想要招募的研究人員已經在不同程度上更加青睞 PyTorch 了。我也聽到了一些抱怨，很多 Google 內部的研究人員希望使用 TensorFlow 以外的框架。

此外，PyTorch 的統治地位可能會開始切斷 Google 研究人員與其它研究社區之間的聯繫。不僅 Google的研究人員將更加難以在他人研究的基礎上構建自己的工作，而且外部的研究人員也不太可能基於 Google 發佈的代碼開展工作。

TensorFlow 2.0 是否能夠為 TensorFlow 挽回一部分研究人員用戶還有待觀察。儘管它的動態圖模式（TensorFlow 2.0 的動態圖模式）一定很吸引人，但是 Keras 的 API 就並非如此了。

二、用於工業生產的 PyTorch 和 TensorFlow

雖然 PyTorch 現在在研究領域佔據主導地位，但是我們快速分析一下工業界的情況就會發現，在工業界 TensorFlow 仍然是主流的框架。例如，2018 年到 2019 年的數據（參考鏈接：https://towardsdatascience.com/deep-learning-framework-power-scores-2018-23607ddf297a）顯示，在公開招聘網站上，涉及 TensorFlow 的新招聘信息有 1541 個，而涉及 PyTorch 的新招聘信息則是

那麼，既然 PyTorch 在研究人員中是如此受歡迎，為什麼它在工業界還沒有取得同樣的成功呢？第一個顯而易見的答案就是：慣性。TensorFlow 比 PyTorch 早誕生數年，而且工業界採用新技術的速度比研究人員要慢一些。另一個原因是：TensorFlow 比 PyTorch 更適用於生產環境。但這意味著什麼呢？

要想回答這個問題，我們需要知道研究人員和工業界的需求有何不同。

研究人員關心的是他們在研究中迭代的速度有多快，這通常是在相對較小的數據集（可以在一臺機器上運行的數據集）上、使用少於 8 個 GPU 進行的。最大的限制因素往往不是出於性能的考慮，而是他們快速實現新思路的能力。相反，工業界認為性能是需要最優先考慮的。雖然運行時的速度提升 10% 對於研究人員來說基本沒有意義，但這可以直接為公司節約數百萬美元的成本。

另一個區別是部署。研究人員將在他們自己的機器或某個專門用於運行研究工作的服務器集群上進行實驗。另一方面，工業界在部署方面則有一連串的限制/要求：

• 不能使用 Python。對於一些公司運行的服務器來說，Python 運行時的計算開銷太大了。

• 移動性。你不能在移動端的二進制文件中嵌入 Python 解釋器。

• 服務性。需要滿足各種需求，例如在不停機的狀態下更新模型、在模型之間無縫切換、在推理時進行批處理，等等。

TensorFlow 是專門圍繞這些需求構建的，併為所有這些問題提供瞭解決方案：計算圖的版式和執行引擎本身並不需要 Python，並且通過 TensorFlow Lite 和 TensorFlow Serving 分別處理移動端和服務器端的問題。

在此前，Pytorch 還不能夠很好地滿足上述需求，因此大多數公司目前在生產環境下都選擇使用 TensorFlow。

三、架構「趨同」

在臨近 2018 年末的時候，業內發生的兩件「爆炸性」事件打破了這種局面：

1. PyTorch 引入了即時（JIT，Just In Time）編譯器和「TorchScript」，從而引入了基於圖的特性。

2. TensorFlow 宣佈它們將在 TensorFlow 2.0 版本中默認轉而採用動態圖模式。

顯然，這些舉措都旨在解決它們各自的弱點。那麼，這些特性到底代表什麼？它們能夠為框架帶來什麼呢？

1、PyTorch TorchScript

PyTorch JIT可以將 PyTorch程序轉換為一種名為「TorchScript」的中間表徵（IR）。Torchscript 是PyTorch的「圖」表徵。你可以通過使用跟蹤或腳模式將常規 PyTorch 模型轉換為 TorchScript。跟蹤接受一個函數和一個輸入，記錄用該輸入執行的操作，並構造中間表徵。雖然跟蹤操作很直接，但是它也存在一些缺點。例如，它不能捕獲未執行的控制流（例如，如果它執行了true情況下的程序塊，它就不能捕獲false 情況下的程序塊。

Script模式接受一個函數/類作為輸入，重新解釋 Python 代碼並直接輸出 TorchScript 中間表徵。這使得它能夠支持任意代碼，但它實際上需要重新解釋 Python。

一旦你的 PyTorch 模型處於其中間表徵狀態，我們就獲得了圖模式的所有好處。我們可以在不依賴 Python 的情況下，在 C++ 環境中部署 PyTorch 模型，或者對其進行優化。

2、Tensorflow 動態圖

在 API 的層次上，TensorFlow 的動態圖模式基本上與最初由 Chainer 推崇的 PyTorch 的動態圖模式相同。這為 TensorFlow 帶來了PyTorch 動態圖模式的大部分優勢（易用性、可調試性，等等)。

然而，這也給 TensorFlow 帶來了相同的缺點：TensorFlow 動態圖模型不能被導出到非 python 環境中，也不能進行優化，不能在移動設備上運行，等等。

這使得 TensorFlow與 PyTorch 旗鼓相當，它們的解決方式本質上是相同的——你可以跟蹤代碼（tf.function）或重新解釋 Python 代碼（Autograph，將 print()函數和其它 Python 代碼轉化為純 TensorFlow計算圖代碼）。

圖注：TensorFlow 通過 autograph 和追蹤（tracing）生成計算圖

因此，TensorFlow 的動態圖模式並不能真正做到「兩全其美」。儘管你可以用「tf.function」註釋將動態圖代碼轉換為靜態圖，但這永遠不會是一個無縫轉換的過程（PyTorch 的 TorchScript 也有類似問題）。跟蹤根本上是有限的，而重新解釋 Python 代碼實際上需要重寫大量的 Python 編譯器。當然，通過限制深度學習中用到的 Python 子集可以極大地簡化這一範圍。

在默認情況下啟用動態圖模式時，TensorFlow 使用戶不得不做出選擇：

• （1）為了易用性使用動態圖執行，而為了進行部署需要重寫函數；

• （2）完全不使用動態圖執行。

儘管 PyTorch 也面臨相同的問題，但相較於 TensorFlow 的「默認採用動態圖」的做法， PyTorch 的 TorchScript 所具備的「選擇性加入」的特性似乎讓用戶更願意接受。

四、機器學習框架的現狀

以上原因造就了機器學習框架領域當今的局面。PyTorch 擁有研究人員的市場，並試圖將這種成功延伸至工業界。而 TensorFlow 則試圖在不犧牲過多的生產能力的情況下，阻止其在研究社區中所佔市場份額的流失。PyTorch 想要在工業界產生巨大的影響肯定還有很長的路要走，畢竟 TensorFlow 在工業界已經根深蒂固，而且工業界革新的速度也相對較慢。然而，從 TensorFlow 1.0 過渡到 2.0 將是一個艱難的過程，這也讓公司自然而然地會評估是否採用 PyTorch。

在未來，哪種框架能夠「笑到最後」取決於以下問題：

• 研究人員的傾向會對工業界產生多大的影響？隨著當下的博士生紛紛畢業，他們將會把使用 PyTorch 的習慣延續新的崗位上去。這種傾向是否足夠令公司選擇招聘使用 PyTorch 的僱員呢？畢業生們會基於 Pytorch 技術創業嗎？

• TensorFlow 的動態圖模式能否在易用性方面追趕上 PyTorch？我從對該問題緊密追蹤的人以及在線社區哪裡感受到的情況是，TensorFlow 的動態圖嚴重受到「性能/內存」問題的困擾，而且「Autograph」自身也存在許多問題。Google 將為此付出大量的工程努力，但是 TensorFlow 還是會受到許多「歷史遺留問題」的困擾。

• PyTorch 能多快在生產環境中被大規模採用？PyTorch 還有許多基本問題有待解決，比如沒有好的量化方式、不能滿足移動性和服務性需求。對於大多數公司來說，在這些問題被妥善解決之前，它們甚至都不會考慮使用 PyTorch。PyTorch 是否能足夠令公司信服，改變使用的機器學習框架呢？（注：近日，PyTorch 宣佈了支持量化和移動性功能，這兩種功能尚處於試驗階段，但代表了 PyTorch 在這方面取得了重大進展。）

• Google 在業內被孤立會讓 TensorFlow 受挫嗎？Google 推動 TensorFlow 的主要原因之一是幫助其迅速發展的雲服務。由於 Google 正在試圖佔領整個機器學習垂直市場，這刺激其它競爭公司（微軟、亞馬遜、英偉達）紛紛轉向唯一的機器學習框架備選方案——PyTorch。

五、機器學習框架之爭的下半場將如何上演？

我們還沒有充分認識到機器學習框架對機器學習的研究產生了多大的影響。它們不僅使機器學習研究可以進行下去，還將一些研究的思路進行了限制，使這些思路切實可行，讓研究人員能夠很容易地對這些思路進行探索。事實上，有多少新奇的想法僅僅因為不能在某種框架中用一種簡單的方式表達出來而破滅？目前看來，PyTorch 可能已經能夠達到研究的「局部最小值」，但是我們仍然需要看看其它的框架提供了哪些特性，還存在哪些研究的機會。

1、高階微分

PyTorch 和 Tensorflow 的核心是自動微分框架。也就是說，這些框架使我們可以對某些函數進行求導。然而，儘管有許多方法可以實現自動微分，但大多數現代機器學習框架採用的都是「逆向模式自動微分」（通常又被稱為「反向傳播」）算法。事實證明，這種方法對於對神經網絡進行求導是極為高效的。

然而，在計算高階導數（Hessian/Hessian 向量積）時，情況就不一樣了。想要高效地計算這些值需要用到「前向模式自動微分」。不使用這個功能的話，對 Hessian 向量積的計算速度會慢幾個量級。

接下來我們將介紹「Jax」。Jax 是由開發原始「Autograd」的人員開發的，它同時具備「前向傳播」和「逆向傳播」自動微分。這使得我們對於高階導數的計算相較於 PyTorch/TensorFlow 可以提供的方法快了幾個數量級。

然而，Jax 並不僅僅只提供了計算高階導數的方法。Jax 的開發者將其視為一種組成任意函數變換的框架，包括「vmap」（針對自動化批處理）或「pmap」（針對自動化並行計算）。

原始的 Autograd 擁有其忠實的擁躉（儘管沒有 GPU 的支持，仍然有 11 篇 ICML 上發表的論文采用了它），Jax 可能很快就會擁有一個類似的忠實用戶社區，使用它來求解任何類型的 n 階導數。

2、代碼生成

當你運行一個 PyTorch/TensorFlow 模型時，大部分工作實際上並不是在框架本身中完成的，而是由第三方內核完成的。這些內核通常由硬件供應商提供，由高級框架可以利用的算子庫組成，例如，MKLDNN（用於 CPU）或 cuDNN（用於英偉達 GPU）。高級框架將計算圖分解成塊，它可以調用上面提到的計算庫。構建這些庫需要數千個人時的工作量，並針對架構和應用程序進行了優化以獲得最佳性能。

然而，最近研究人員對於「非標準硬件」、「稀疏/量子化張量」和「新運算符」的關注暴露了依賴這些運算符庫的一個缺陷：它們並不靈活。

如果你想在研究中使用像膠囊網絡這樣的新算子，你該怎麼做？如果你想在機器學習框架目前還不支持的新型硬件加速器上運行你的模型，你又該怎麼做？現有的解決方案往往還不夠完善。正如論文「Machine Learning Systems are Stuck in a Rut」（論文地址：https://dl.acm.org/citation.cfm?id=3321441）所提到的，現有的膠囊網絡在 GPU 上的實現比最優的實現慢了兩個數量級。

每種新的硬件架構、張量或算子的類別，都大大提高了該問題的難度。目前已經有許多處理工具（如 Halide、TVM、PlaidML、TensorComprehensions、XLA、Taco 等）可以處理各種問題，但是真正正確的處理方法還有待探索。

如果不能進一步解決這個問題，我們就會有一定風險將我們的機器學習研究與我們擁有的研究工具「過度擬合」。

六、機器學習框架的未來

這對於 TensorFlow 和 PyTorch 的未來而言是激動人心的時刻：它們的設計逐漸趨同，它們都不太可能憑藉其設計獲得決定性的勝利。與此同時，這兩種機器學習框架都有其各自主導的領域——PyTorch 在學術界佔據主導，而 TensorFlow 在工業界則更受歡迎。

就我個人而言，在 PyTorch 和 TensorFlow 之間，我認為 PyTorch 更有勝算。機器學習仍然是一個由研究驅動的領域。工業界不能忽視科學研究的成果，只要 PyTorch 在研究領域佔據主導地位，就會迫使公司轉而使用 PyTorch.

然而，不僅機器學習框架迭代得非常快，機器學習研究本身也處於一場巨大的變革之中。發生變化的不僅僅是機器學習框架，5 年後使用的模型、硬件、範式與我們現在使用的可能有非常大的區別。也許，隨著另一種計算模型佔據主導地位，PyTorch 與 TensorFlow 之間的機器學習框架之爭也將煙消雲散。

置身於這些錯綜複雜的利益衝突、以及投入在機器學習領域的大量資金中，退一步，也許海闊天空。大多數從事機器學習軟件的工作不是為了賺錢，也不是為了協助公司的戰略計劃，而是想要推進機器學習的研究，關心人工智能民主化，也或許他們只是想創造一些很酷的東西。我們大多數人並不是為了賺錢或協助我們企業的戰略而從事機器學習軟件事業，我們從是機器學習工作的原因只是因為——我們關心機器學習研究的發展，使人工智能走進千家萬戶，或者僅僅只是因為我們向創造一些很酷的東西。無論你更喜歡 TensorFlow 還是 PyTorch，我們都懷著一個共同的目的：盡力做出最棒的機器學習軟件！

via https://thegradient.pub/state-of-ml-frameworks-2019-pytorch-dominates-research-tensorflow-dominates-industry/

閱讀更多 AI科技評論 的文章

關鍵字: 設計 深度學習 Python