0
雷鋒網 AI 科技評論按：對于機器學習科研工作者和工業(yè)界從業(yè)人員來說，熟練掌握一種機器學習框架是必備技能之一。隨著深度學習技術發(fā)展的突飛猛進，機器學習框架市場也漸漸度過了初期野蠻生長的階段。大浪淘沙，目前仍然活躍的機器學習框架主要是 PyTorch 和 TensorFlow。本文從學術界和工業(yè)界兩個方面深度盤點了 2019 年機器學習框架的發(fā)展趨勢。
自 2012 年深度學習再度成為萬眾矚目的技術以來，各種機器學習框架爭相成為研究人員和從業(yè)者的新寵，可謂「你方唱罷我登場」。從早期在學術界廣為使用的 Caffe 和 Theano，到業(yè)界推崇的 PyTorch 和 TensorFlow，各種各樣可供選擇的學習框架使得人們很難確定「誰才是真正最主流的框架」。
如果你僅僅通過瀏覽 Reddit 來做出判斷，你可能會認為每個人都在轉而使用 PyTorch；而如果你根據(jù) Francois Chollet 推特中的內容做出判斷，你會發(fā)現(xiàn) TensorFlow 或 Keras 可能是主流的框架，而 PyTorch 的勢頭正在衰減。
回顧 2019 年，機器學習框架之爭中還剩下兩個競爭者：PyTorch 和 TensorFlow。我的分析表明，研究人員正在放棄 TensorFlow 并紛紛轉向使用 PyTorch。然而與此同時，在工業(yè)界，TensorFlow 目前則是首選的平臺，但這種情況可能不會持續(xù)太久。
讓我們用數(shù)據(jù)說話！下圖顯示了在近些年的研究頂會中，僅僅使用了 PyTorch 框架進行研究的論文數(shù)和使用了 TensorFlow 或 PyTorch 的論文總數(shù)的比例。如圖所示，每條曲線（代表不同的會議）都向上傾斜（意味著 PyTorch 的占比越來越高），而且在 2019 年的每個主要的會議中，大多數(shù)的論文都采用 PyTorch 實現(xiàn)。
會議的圖例
數(shù)據(jù)收集過程的細節(jié)
這些圖表的交互式版本鏈接如下：https://chillee.github.io/pytorch-vs-tensorflow/
如果你需要更多的證據(jù)來說明 PyTorch 在研究社區(qū)中獲得關注的速度有多快，請看下面關于 PyTorch 和 TensorFlow 使用情況的原始統(tǒng)計圖。
在 2018 年，PyTorch 在深度學習框架中的占比還很小。而現(xiàn)在，PyTorch 已成占據(jù)壓倒性比重的多數(shù)。據(jù)統(tǒng)計，69% 的 CVPR 論文、75% 以上的 NAACL 和 ACL 論文，以及 50% 以上的 ICLR 和 ICML 論文都選擇使用 PyTorch。PyTorch 在視覺和語言類的會議上（分別以 2:1 和 3:1 的比例超過了 TensorFlow）被使用的頻繁度最為明顯，而且 PyTorch 在 ICLR 和 ICML 等通用機器學習會議上也比 TensorFlow 更受歡迎。
雖然有些人認為 PyTorch 仍然是一個處于萌芽期的框架，試圖在 Tensorflow 主導的世界中開辟出一片市場，但真實的數(shù)據(jù)卻說明事實并非如此。除了在 ICML 上，其它學術會議中使用 TensorFlow 的論文的增長率甚至還趕不上整體論文數(shù)量的增長率。在 NAACL、ICLR 和 ACL 上，今年使用 TensorFlow 的論文數(shù)量實際上比去年還少。
需要擔心未來發(fā)展的并不是 Pytorch，而是 TensorFlow。
1、為什么研究人員青睞 PyTorch？
簡潔性。PyTorch 與 numpy 很相似，具有很強的 python 風格，并且很容易與 Python 生態(tài)系統(tǒng)中的其它組件實現(xiàn)集成。例如，你可以簡單地在 PyTorch 模型中的任何地方添加「PDB」斷點，然后就可以進行調試。在 TensorFlow 框架中，想要進行程序調試就需要一個運行中的會話，這使得調試難以進行。
易用的應用程序接口（API）。相較于 TensorFlow 的 API，大多數(shù)研究人員更喜歡 PyTorch 提供的 API。這在一定程度上是由于 PyTorch 的設計更好，另一方面是因為 TensorFlow 需要多次切換 API（例如，「layers」->「slim」->「estimators」->「tf.keras」）從而限制了自己的易用性。
卓越的性能。盡管 PyTorch 的動態(tài)圖留給我們優(yōu)化的機會很少，但是已經有很多有趣的報道說明 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 在這個方面并沒有獲得絕對的優(yōu)勢。
2、TensorFlow 在研究領域的前景如何？
即使 TensorFlow 在功能方面與 PyTorch 的水平差不多，但是 PyTorch 已經擁有了研究社區(qū)中的大多數(shù)用戶。這意味著我們更容易找到 PyTorch 版本的算法實現(xiàn)，而作者也會更有動力發(fā)布 PyTorch版本的代碼（這樣人們就會使用它），而你的合作者們很可能也更喜歡 PyTorch。因此，如果將代碼移植回 TensorFlow 2.0 平臺，這將會是一個很漫長的過程（如果真的這么做了）。
TensorFlow 在 Google/DeepMind 內部總會有一批固定的用戶，但我不知道 Google 最終是否會放開這一點。即使是現(xiàn)在，很多 Google 想要招募的研究人員已經在不同程度上更加青睞 PyTorch 了。我也聽到了一些抱怨，很多 Google 內部的研究人員希望使用 TensorFlow 以外的框架。
此外，PyTorch 的統(tǒng)治地位可能會開始切斷 Google 研究人員與其它研究社區(qū)之間的聯(lián)系。不僅 Google的研究人員將更加難以在他人研究的基礎上構建自己的工作，而且外部的研究人員也不太可能基于 Google 發(fā)布的代碼開展工作。
TensorFlow 2.0 是否能夠為 TensorFlow 挽回一部分研究人員用戶還有待觀察。盡管它的動態(tài)圖模式（TensorFlow 2.0 的動態(tài)圖模式）一定很吸引人，但是 Keras 的 API 就并非如此了。
雖然 PyTorch 現(xiàn)在在研究領域占據(jù)主導地位，但是我們快速分析一下工業(yè)界的情況就會發(fā)現(xiàn)，在工業(yè)界 TensorFlow 仍然是主流的框架。例如，2018 年到 2019 年的數(shù)據(jù)（參考鏈接：https://towardsdatascience.com/deep-learning-framework-power-scores-2018-23607ddf297a）顯示，在公開招聘網站上，涉及 TensorFlow 的新招聘信息有 1541 個，而涉及 PyTorch 的新招聘信息則是 1437 個；知名科技媒體「Medium」上有 3230 篇關于 TensorFlow 的新文章，而關于 PyTorch 的新文章只有 1200 篇；在 GitHub 上，用 TensorFlow 編寫的項目獲得了 13,700 顆星，而用 PyTorch 編寫的項目只獲得了 7,200 顆星。
那么，既然 PyTorch 在研究人員中是如此受歡迎，為什么它在工業(yè)界還沒有取得同樣的成功呢？第一個顯而易見的答案就是：慣性。TensorFlow 比 PyTorch 早誕生數(shù)年，而且工業(yè)界采用新技術的速度比研究人員要慢一些。另一個原因是：TensorFlow 比 PyTorch 更適用于生產環(huán)境。但這意味著什么呢？
要想回答這個問題，我們需要知道研究人員和工業(yè)界的需求有何不同。
研究人員關心的是他們在研究中迭代的速度有多快，這通常是在相對較小的數(shù)據(jù)集（可以在一臺機器上運行的數(shù)據(jù)集）上、使用少于 8 個 GPU 進行的。最大的限制因素往往不是出于性能的考慮，而是他們快速實現(xiàn)新思路的能力。相反，工業(yè)界認為性能是需要最優(yōu)先考慮的。雖然運行時的速度提升 10% 對于研究人員來說基本沒有意義，但這可以直接為公司節(jié)約數(shù)百萬美元的成本。
另一個區(qū)別是部署。研究人員將在他們自己的機器或某個專門用于運行研究工作的服務器集群上進行實驗。另一方面，工業(yè)界在部署方面則有一連串的限制/要求：
不能使用 Python。對于一些公司運行的服務器來說，Python 運行時的計算開銷太大了。
移動性。你不能在移動端的二進制文件中嵌入 Python 解釋器。
服務性。需要滿足各種需求，例如在不停機的狀態(tài)下更新模型、在模型之間無縫切換、在推理時進行批處理，等等。
TensorFlow 是專門圍繞這些需求構建的，并為所有這些問題提供了解決方案：計算圖的版式和執(zhí)行引擎本身并不需要 Python，并且通過 TensorFlow Lite 和 TensorFlow Serving 分別處理移動端和服務器端的問題。
在此前，Pytorch 還不能夠很好地滿足上述需求，因此大多數(shù)公司目前在生產環(huán)境下都選擇使用 TensorFlow。
在臨近 2018 年末的時候，業(yè)內發(fā)生的兩件「爆炸性」事件打破了這種局面：
1. PyTorch 引入了即時（JIT，Just In Time）編譯器和「TorchScript」，從而引入了基于圖的特性。
2. TensorFlow 宣布它們將在 TensorFlow 2.0 版本中默認轉而采用動態(tài)圖模式。
顯然，這些舉措都旨在解決它們各自的弱點。那么，這些特性到底代表什么？它們能夠為框架帶來什么呢？
1、PyTorch TorchScript
PyTorch JIT可以將 PyTorch程序轉換為一種名為「TorchScript」的中間表征（IR）。Torchscript 是PyTorch的「圖」表征。你可以通過使用跟蹤或腳模式將常規(guī) PyTorch 模型轉換為 TorchScript。跟蹤接受一個函數(shù)和一個輸入，記錄用該輸入執(zhí)行的操作，并構造中間表征。雖然跟蹤操作很直接，但是它也存在一些缺點。例如，它不能捕獲未執(zhí)行的控制流（例如，如果它執(zhí)行了true情況下的程序塊，它就不能捕獲false 情況下的程序塊。
Script模式接受一個函數(shù)/類作為輸入，重新解釋 Python 代碼并直接輸出 TorchScript 中間表征。這使得它能夠支持任意代碼，但它實際上需要重新解釋 Python。
一旦你的 PyTorch 模型處于其中間表征狀態(tài)，我們就獲得了圖模式的所有好處。我們可以在不依賴 Python 的情況下，在 C++ 環(huán)境中部署 PyTorch 模型，或者對其進行優(yōu)化。
2、Tensorflow 動態(tài)圖
在 API 的層次上，TensorFlow 的動態(tài)圖模式基本上與最初由 Chainer 推崇的 PyTorch 的動態(tài)圖模式相同。這為 TensorFlow 帶來了PyTorch 動態(tài)圖模式的大部分優(yōu)勢（易用性、可調試性，等等)。
然而，這也給 TensorFlow 帶來了相同的缺點：TensorFlow 動態(tài)圖模型不能被導出到非 python 環(huán)境中，也不能進行優(yōu)化，不能在移動設備上運行，等等。
這使得 TensorFlow與 PyTorch 旗鼓相當，它們的解決方式本質上是相同的——你可以跟蹤代碼（tf.function）或重新解釋 Python 代碼（Autograph，將 print()函數(shù)和其它 Python 代碼轉化為純 TensorFlow計算圖代碼）。
圖注：TensorFlow 通過 autograph 和追蹤（tracing）生成計算圖
因此，TensorFlow 的動態(tài)圖模式并不能真正做到「兩全其美」。盡管你可以用「tf.function」注釋將動態(tài)圖代碼轉換為靜態(tài)圖，但這永遠不會是一個無縫轉換的過程（PyTorch 的 TorchScript 也有類似問題）。跟蹤根本上是有限的，而重新解釋 Python 代碼實際上需要重寫大量的 Python 編譯器。當然，通過限制深度學習中用到的 Python 子集可以極大地簡化這一范圍。
在默認情況下啟用動態(tài)圖模式時，TensorFlow 使用戶不得不做出選擇：
（1）為了易用性使用動態(tài)圖執(zhí)行，而為了進行部署需要重寫函數(shù)；
（2）完全不使用動態(tài)圖執(zhí)行。
盡管 PyTorch 也面臨相同的問題，但相較于 TensorFlow 的「默認采用動態(tài)圖」的做法， PyTorch 的 TorchScript 所具備的「選擇性加入」的特性似乎讓用戶更愿意接受。
以上原因造就了機器學習框架領域當今的局面。PyTorch 擁有研究人員的市場，并試圖將這種成功延伸至工業(yè)界。而 TensorFlow 則試圖在不犧牲過多的生產能力的情況下，阻止其在研究社區(qū)中所占市場份額的流失。PyTorch 想要在工業(yè)界產生巨大的影響肯定還有很長的路要走，畢竟 TensorFlow 在工業(yè)界已經根深蒂固，而且工業(yè)界革新的速度也相對較慢。然而，從 TensorFlow 1.0 過渡到 2.0 將是一個艱難的過程，這也讓公司自然而然地會評估是否采用 PyTorch。
在未來，哪種框架能夠「笑到最后」取決于以下問題：
研究人員的傾向會對工業(yè)界產生多大的影響？隨著當下的博士生紛紛畢業(yè)，他們將會把使用 PyTorch 的習慣延續(xù)新的崗位上去。這種傾向是否足夠令公司選擇招聘使用 PyTorch 的雇員呢？畢業(yè)生們會基于 Pytorch 技術創(chuàng)業(yè)嗎？
TensorFlow 的動態(tài)圖模式能否在易用性方面追趕上 PyTorch？我從對該問題緊密追蹤的人以及在線社區(qū)哪里感受到的情況是，TensorFlow 的動態(tài)圖嚴重受到「性能/內存」問題的困擾，而且「Autograph」自身也存在許多問題。Google 將為此付出大量的工程努力，但是 TensorFlow 還是會受到許多「歷史遺留問題」的困擾。
PyTorch 能多快在生產環(huán)境中被大規(guī)模采用？PyTorch 還有許多基本問題有待解決，比如沒有好的量化方式、不能滿足移動性和服務性需求。對于大多數(shù)公司來說，在這些問題被妥善解決之前，它們甚至都不會考慮使用 PyTorch。PyTorch 是否能足夠令公司信服，改變使用的機器學習框架呢？（注：近日，PyTorch 宣布了支持量化和移動性功能，這兩種功能尚處于試驗階段，但代表了 PyTorch 在這方面取得了重大進展。）
Google 在業(yè)內被孤立會讓 TensorFlow 受挫嗎？Google 推動 TensorFlow 的主要原因之一是幫助其迅速發(fā)展的云服務。由于 Google 正在試圖占領整個機器學習垂直市場，這刺激其它競爭公司（微軟、亞馬遜、英偉達）紛紛轉向唯一的機器學習框架備選方案——PyTorch。
我們還沒有充分認識到機器學習框架對機器學習的研究產生了多大的影響。它們不僅使機器學習研究可以進行下去，還將一些研究的思路進行了限制，使這些思路切實可行，讓研究人員能夠很容易地對這些思路進行探索。事實上，有多少新奇的想法僅僅因為不能在某種框架中用一種簡單的方式表達出來而破滅？目前看來，PyTorch 可能已經能夠達到研究的「局部最小值」，但是我們仍然需要看看其它的框架提供了哪些特性，還存在哪些研究的機會。
1、高階微分
PyTorch 和 Tensorflow 的核心是自動微分框架。也就是說，這些框架使我們可以對某些函數(shù)進行求導。然而，盡管有許多方法可以實現(xiàn)自動微分，但大多數(shù)現(xiàn)代機器學習框架采用的都是「逆向模式自動微分」（通常又被稱為「反向傳播」）算法。事實證明，這種方法對于對神經網絡進行求導是極為高效的。
然而，在計算高階導數(shù)（Hessian/Hessian 向量積）時，情況就不一樣了。想要高效地計算這些值需要用到「前向模式自動微分」。不使用這個功能的話，對 Hessian 向量積的計算速度會慢幾個量級。
接下來我們將介紹「Jax」。Jax 是由開發(fā)原始「Autograd」的人員開發(fā)的，它同時具備「前向傳播」和「逆向傳播」自動微分。這使得我們對于高階導數(shù)的計算相較于 PyTorch/TensorFlow 可以提供的方法快了幾個數(shù)量級。
然而，Jax 并不僅僅只提供了計算高階導數(shù)的方法。Jax 的開發(fā)者將其視為一種組成任意函數(shù)變換的框架，包括「vmap」（針對自動化批處理）或「pmap」（針對自動化并行計算）。
原始的 Autograd 擁有其忠實的擁躉（盡管沒有 GPU 的支持，仍然有 11 篇 ICML 上發(fā)表的論文采用了它），Jax 可能很快就會擁有一個類似的忠實用戶社區(qū)，使用它來求解任何類型的 n 階導數(shù)。
2、代碼生成
當你運行一個 PyTorch/TensorFlow 模型時，大部分工作實際上并不是在框架本身中完成的，而是由第三方內核完成的。這些內核通常由硬件供應商提供，由高級框架可以利用的算子庫組成，例如，MKLDNN（用于 CPU）或 cuDNN（用于英偉達 GPU）。高級框架將計算圖分解成塊，它可以調用上面提到的計算庫。構建這些庫需要數(shù)千個人時的工作量，并針對架構和應用程序進行了優(yōu)化以獲得最佳性能。
然而，最近研究人員對于「非標準硬件」、「稀疏/量子化張量」和「新運算符」的關注暴露了依賴這些運算符庫的一個缺陷：它們并不靈活。
如果你想在研究中使用像膠囊網絡這樣的新算子，你該怎么做？如果你想在機器學習框架目前還不支持的新型硬件加速器上運行你的模型，你又該怎么做？現(xiàn)有的解決方案往往還不夠完善。正如論文「Machine Learning Systems are Stuck in a Rut」（論文地址：https://dl.acm.org/citation.cfm?id=3321441）所提到的，現(xiàn)有的膠囊網絡在 GPU 上的實現(xiàn)比最優(yōu)的實現(xiàn)慢了兩個數(shù)量級。
每種新的硬件架構、張量或算子的類別，都大大提高了該問題的難度。目前已經有許多處理工具（如 Halide、TVM、PlaidML、TensorComprehensions、XLA、Taco 等）可以處理各種問題，但是真正正確的處理方法還有待探索。
如果不能進一步解決這個問題，我們就會有一定風險將我們的機器學習研究與我們擁有的研究工具「過度擬合」。
這對于 TensorFlow 和 PyTorch 的未來而言是激動人心的時刻：它們的設計逐漸趨同，它們都不太可能憑借其設計獲得決定性的勝利。與此同時，這兩種機器學習框架都有其各自主導的領域——PyTorch 在學術界占據(jù)主導，而 TensorFlow 在工業(yè)界則更受歡迎。
就我個人而言，在 PyTorch 和 TensorFlow 之間，我認為 PyTorch 更有勝算。機器學習仍然是一個由研究驅動的領域。工業(yè)界不能忽視科學研究的成果，只要 PyTorch 在研究領域占據(jù)主導地位，就會迫使公司轉而使用 PyTorch.
然而，不僅機器學習框架迭代得非?？欤瑱C器學習研究本身也處于一場巨大的變革之中。發(fā)生變化的不僅僅是機器學習框架，5 年后使用的模型、硬件、范式與我們現(xiàn)在使用的可能有非常大的區(qū)別。也許，隨著另一種計算模型占據(jù)主導地位，PyTorch 與 TensorFlow 之間的機器學習框架之爭也將煙消云散。
置身于這些錯綜復雜的利益沖突、以及投入在機器學習領域的大量資金中，退一步，也許海闊天空。大多數(shù)從事機器學習軟件的工作不是為了賺錢，也不是為了協(xié)助公司的戰(zhàn)略計劃，而是想要推進機器學習的研究，關心人工智能民主化，也或許他們只是想創(chuàng)造一些很酷的東西。我們大多數(shù)人并不是為了賺錢或協(xié)助我們企業(yè)的戰(zhàn)略而從事機器學習軟件事業(yè)，我們從是機器學習工作的原因只是因為——我們關心機器學習研究的發(fā)展，使人工智能走進千家萬戶，或者僅僅只是因為我們向創(chuàng)造一些很酷的東西。無論你更喜歡 TensorFlow 還是 PyTorch，我們都懷著一個共同的目的：盡力做出做棒的機器學習軟件！
雷鋒網 AI 科技評論編譯。雷鋒網
雷峰網原創(chuàng)文章，未經授權禁止轉載。詳情見轉載須知。
