大資料文摘出品
來源：thegradient
編譯：張大筆茹、曹培信、劉俊寰、牛婉揚、Andy
2019年，機器學習框架之爭進入了新階段：PyTorch與TensorFlow成為最後兩大玩家，PyTorch佔據學術界領軍地位，TensorFlow在工業界力量依然強大，兩個框架都在向對方借鑑，但是都不太理想。
最後誰能勝出？還得看誰更好的回答幾個關鍵問題。
來自康奈爾大學的Horace He剛剛在Gradient釋出了一篇長文探討2019年的兩大機器學習框架之爭，他論述了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是首選平臺，但這種情況可能不會持續很久。下圖顯示了頂級研究會議接受論文中，使用TensorFlow或Pythorch的比率。可以發現，所有的折線都向上傾，並且在2019年，主要會議的論文中，多數使用的都是PyTorch。如果覺得僅靠會議論文資料還不夠，這裡還有一張圖來證明PyTorch在研究社群獲得關注的速度。下圖顯示了PyTorch和TensorFlow在各類會議上被提及的次數圖。
2018年，PyTorch獲得的關注還比較少。但現在，大多數人都在使用PyTorch：69%的CVPR、75%以上的NAACL和ACL、50%以上的ICLR和ICML使用的也是PyTorch。
PyTorch在視覺和語言會議方面的優勢最為明顯，分別以2:1和3:1的比例超過了TensorFlow。此外可以看到，在ICLR和ICML等通用機器學習會議上，PyTorch也比TensorFlow更受歡迎。雖然有人認為PyTorch還是一個全新的框架，並試圖在TensorFlow主導的世界中分得一杯羹，但是資料告訴我們並非如此。除了ICML，在NAACL、ICLR和ACL等會議上，TensorFlow今年的論文整體上都比去年少。也就是說，慌的不是PyTorch，而是TensorFlow。簡單。PyTorch類似於numpy，非常Python化，很容易就能與Python生態系統的其餘部分整合。例如，可以在PyTorch模型中任何地方新增pdb斷點。而在TensorFlow中，除錯模型需要一個活動會話，整個過程非常麻煩。
API。大多數研究人員更喜歡PyTorch的API而不是TensorFlow的API。部分原因是因為PyTorch的設計更好，還有部分是因為TensorFlow切換其API介面過於頻繁(比如“layers”-“slim”-“estimators”-“tf.keras”)，這阻礙了其自身的發展。
表現。儘管PyTorch的動態圖給出的最佳化機會很少，但許多傳聞稱PyTorch的速度不比TensorFlow慢多少。目前尚不清楚這是否屬實，但至少，TensorFlow在這一方面還沒有獲得決定性的優勢。即使TensorFlow在功能上與PyTorch不相上下，但PyTorch已經覆蓋了機器學習社群的大部分。這意味著PyTorch實現將更容易找到，作者將更有動力用PyTorch釋出程式碼，而且你的合作者也很可能會更喜歡PyTorch。因此，任何向TensorFlow 2.0的回遷可能會很慢。TensorFlow在Google/Deepmind中有一批忠實的使用者，但不知道Google最終是否會在這一點上動搖。現在，很多Google想招募的研究人員已經開始喜歡上PyTorch了，我也聽到抱怨說Google內部很多研究人員希望使用TensorFlow之外的框架。此外，PyTorch的統治地位很可能會切斷谷歌研究人員與其他研究社群的聯絡。他們不僅難以在外部研究的基礎上進行構建，而且外部研究人員也不太可能在谷歌釋出的程式碼基礎上進行構建。TensorFlow 2.0是否能重新俘獲回之前的粉絲還有待觀察。儘管eager模式很吸引人，但對於Keras API而言並非如此。雖然PyTorch目前在研究領域佔據主導地位，但稍微注意一下就會發現TensorFlow仍然是佔據主導地位的框架。例如，根據2018年到2019年的資料，TensorFlow在招聘的頁面上有1541個新工作崗位，而PyTorch有1437個，TensorFlow在Medium上有3230個新文章，而PyTorch有1200篇，TensorFlow在GitHub有13.7K標星，而PyTorch有7.2K。那為什麼PyTorch現在已經如此受研究人員歡迎了，但它在工業上還沒有同樣的成功呢？顯而易見的第一個答案就是使用習慣。TensorFlow比PyTorch早幾年問世，而產業接受新技術的速度要比研究人員慢。另一個原因就是TensorFlow在產業適應方面優於PyTorch，什麼意思呢？要回答這個問題，我們需要知道研究人員和工業界的需求有何不同。研究人員關心的是他們在研究中迭代的速度有多快，這通常是在相對較小的資料集(可以在一臺機器上執行的資料集)上，並在8個GPU上就可以執行。這通常不是出於對效能的考慮，而是更關注可以快速實現自己的想法。而工業界則認為效能是最優先考慮的。雖然執行時速度提高10%對研究人員來意義不大，但這可以直接為公司節省數百萬美元。另一個區別是部署。研究人員一般在自己的機器上或某個專門用於執行研究工作的伺服器叢集上進行實驗。但是在產業上，部署則有一連串的限制與要求。- 沒有Python。執行Python對伺服器的開銷太大了；
- 移動。你不能在移動終端二進位制檔案中嵌入Python直譯器；
- 服務。需要包羅永珍的功能：不用停機更新的模型，在模型之間無縫切換，批處理在預測時間，等等。
TensorFlow就是特別針對這些需求構建的，併為所有這些問題提供瞭解決方案：網路圖格式和執行引擎本身不需要Python，而TensorFlow Lite和TensorFlow Serving可以分別處理移動終端和伺服器需求。從歷史上看，PyTorch在滿足這些需求方面做得還不夠，因此大多數公司目前在生產中都還是使用 TensorFlow。
PyTorch引入了JIT編譯器和“TorchScript”，從而引入了基於圖的特性；
TensorFlow宣佈他們將在2.0版本中預設轉移到Eager模式。顯然，這些舉措都是為了解決PyTorch和TensorFlow各自的弱點。那麼這些特性到底是什麼，它們能提供什麼呢？PyTorch JIT是PyTorch的一箇中間表示(intermediate representation，IR) ，稱為TorchScript。Torchscript是PyTorch的“圖”表示。你可以透過使用跟蹤或指令碼模式將常規PyTorch模型轉換為TorchScript。跟蹤接受一個函式和一個輸入，記錄用該輸入執行的操作，並構造IR。雖然很簡單，但是跟蹤也有它的缺點。例如，它不能捕獲未執行的控制流。例如，如果它執行了true塊，它就不能捕獲條件塊的false塊。Script模式接受一個函式/類，重新解釋Python程式碼並直接輸出TorchScript IR。這允許它支援任意程式碼，但是它實際上需要重新解釋Python。一旦PyTorch模型進入了這個IR，我們就可以獲得圖模式的所有優勢。我們既可以在C++中部署PyTorch模型，而不依賴Python，或者對其進行最佳化。在API級別上，TensorFlow Eager模式基本上與PyTorch Eager模式相同，後者最初由Chainer推出,這為TensorFlow提供了PyTorchEager模式的大部分優勢(易用性、可除錯性等等)然而，這也給TensorFlow帶來了同樣的缺點。TensorFlow Eager模型不能匯出到非python環境中，也不能進行最佳化，不能在移動裝置上執行。這將TensorFlow置於與PyTorch相同的位置，它們的解析方式基本相同——你可以跟蹤程式碼(tf.function)或重新解釋Python程式碼(Autograph)。因此，TensorFlow的Eager模式並不能真正做到“兩全其美”。雖然可以使用 tf.function註釋將eager code轉換為靜態圖，但這永遠不會是一個無縫轉換的流程(PyTorch的TorchScript也有類似的問題)。跟蹤基本上是有限的，重新解釋Python程式碼實際上需要重寫Python編譯器的大部分內容。當然，透過限制在深度學習中使用的Python子集，範圍可以大大簡化。在預設啟用Eager模式時，TensorFlow將強迫使用者做出選擇——為了便於使用而Eager執行，並且需要為部署而重寫，或者根本不使用急於執行。雖然這與PyTorch的情況相同，但PyTorch的TorchScript的可選擇加入特性可能比TensorFlow的“預設Eager”更容易接受。PyTorch在研究領域領先，並試圖擴充套件到工業領域。而TensorFlow正試圖在不犧牲太多產業優勢的情況下，更多的參與到研究領域。PyTorch要在行業中產生有意義的影響肯定還需要很長時間，畢竟TensorFlow在產業界的影響力已經根深蒂固。然而，從TensorFlow 1.0到2.0的轉換為企業評估PyTorch提供了一個絕佳的機會。- 研究者偏好對產業的影響有多大？隨著當前一批博士研究生開始畢業，他們也許會帶上用慣的PyTorch。這種勢頭是否足夠明顯，以至於公司會選擇PyTorch用於招聘的條件？同時畢業生會在PyTorch的基礎上創業嗎？
- TensorFlow的Eager模式在可用性上能趕上PyTorch嗎？就網上的反應來看，TensorFlow Eager嚴重受到效能/記憶體方面問題的困擾，而且Autograph也有自己的問題。谷歌將花費大量的工程努力，但TensorFlow還是揹負著歷史包袱
- PyTorch滿足產業需求的速度有多快？PyTorch還有許多沒有解決的基本問題——沒有好的量化支援、不支援移動等等。在這些問題得到解決之前，PyTorch甚至不會成為許多公司的選擇。PyTorch能否為企業提供一個足夠吸引人的故事來進行轉型？注意：PyTorch已經宣佈支援量化和移動。雖然兩者都還處於試驗階段，但代表了PyTorch在這方面的重大進展。
- 谷歌在行業中的孤立會傷害TensorFlow嗎？谷歌推動TensorFlow的主要原因之一是幫助其蓬勃發展的雲服務。由於谷歌試圖擁有整個機器學習垂直領域，這促使谷歌與之競爭的公司(如微軟、亞馬遜、Nvidia)支援只能支援PyTorch。
它不僅使機器學習研究成為可能，更讓研究人員能夠更輕鬆地探索。有多少新的想法因為沒有簡單的方法在框架中表達而被扼殺？PyTorch已經達到了研究的本地極小值，但是值得研究的其他框架提供了什麼？還有什麼樣的研究機會？PyTorch和TensorFlow的核心是自動差異化框架，它能對某個函式求導。實現自動微分的方法有很多，大多數現代機器學習框架所選擇的方法被稱為“逆向模式自動微分”，也就是通常所說的“反向傳播”。對神經網路的衍生而言，這種實現是非常有效的。然而，在計算高階導數(Hessian/Hessian Vector Products)時，就出問題了。有效地計算需要“正向模式自動微分”，如果沒有這個功能，Hessian Vector Products的計算速度就會降低一個數量級。Jax是由最初建造Autograd的同一批人建立的，它具有正向和反向模式自動分化的功能，這使得計算高階導數的速度比PyTorch/TensorFlow的更快。並且，Jax不僅能計算高階導數，Jax開發人員將Jax視為組成任意函式轉換的框架，包括vmap(用於自動批處理)或pmap(用於自動並行化)。Jax最初的使用者主要是大學畢業生(儘管沒有GPU支援，但ICML有11篇論文使用了它)，但相信Jax很快就會找到一個類似的忠實粉絲社群，用它來做各種n階導數。當執行PyTorch/TensorFlow模型時，大部分工作實際上並不是在框架本身中完成的，而是由第三方核心完成的。這些核心通常由硬體供應商提供，類似於MKLDNN（用於 CPU）或cuDNN（用於Nvidia GPUs），由高階框架可以利用的運算子庫組成。高階框架將計算圖表分解成塊，然後呼叫計算庫。這些庫代表了數千小時的工作量，並針對體系結構和應用程式進行最佳化以獲得最佳效能。然而，最近非標準硬體、稀疏/量子化張量和新運算子的流行暴露了依賴這些運算子庫的一個缺陷：它們不夠靈活！如果你想在研究中使用像膠囊網路（capsule networks）這樣的新操作怎麼辦？現有的解決方案還不夠完善。正如本文所說，現有的膠囊網路在GPU上的實現比最優實現慢2個數量級。每個新的硬體體系結構、張量或運算元的類別，都大大增加了問題的難度。目前已經有許多處理工具，如Halide、TVM、PlaidML、TensorComprehensions、XLA、Taco等，但是正確的方法還沒找到。如果沒有解決這個問題，我們就會面臨機器學習研究與工具過度匹配的風險。對於TensorFlow和PyTorch的未來，他們的設計已經趨於一致，任何一個框架都不會憑藉其設計而取得最終勝利，每一方也都有自己的地盤——一方擁有研究，另一方擁有工業。就我個人而言，在PyTorch和TensorFlow之間，我會覺得PyTorch更有勝算。因為機器學習仍然是一個研究驅動的領域，工業界不能忽視研究成果，只要PyTorch在研究領域佔據主導地位，企業就只有被迫轉型。然而，跑得足夠快的不僅僅是框架。機器學習研究本身也處於一個巨大的變革中。不僅框架發生了變化，5年來使用的模型、硬體、正規化與我們今天使用的截然不同。未來也許PyTorch和TensorFlow之間的戰爭將變得無關緊要，因為另一種計算模型或將佔據主導地位。在所有這些相互衝突的利益中，機器學習投入了大量資金，退一步想想其實也不錯。大多數從事機器學習軟體的工作不是為了賺錢，也不是為了協助公司的戰略計劃，而是想要推進機器學習的研究，關心人工智慧民主化，也或許他們只是想創造一些很酷的東西。所以，不管你更喜歡TensorFlow還是PyTorch，它們的目的只有一個，就是想讓機器學習做到最好。%2BviuAbdWRIFSgV1Yvu7Oj6KhVNWWGEpmoUHaDqlPyjAOIGgCho%2B2PznlO1KQYW8u9DRdYlPaILzqUApS1GAhmL3M0gzBGeyCQhOpiftWASSZTR1xaNMzV7VwTuLvCfUyjKAw1TyuzeOQxF8yhnIiuGJcRdthH7JX%2FaOLMtMfgaiDs0TuIDe5lMlcmhRZtnAg3YP30gg%3D%3D
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31562039/viewspace-2659554/，如需轉載，請註明出處，否則將追究法律責任。
