首頁 > 文章內容

2019機器學習框架之爭:與Tensorflow競爭白熱化,進擊的PyTorch贏在哪里?

大數據文摘出品

來源: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是首選平臺,但這種情況可能不會持續很久。

PyTorch在研究領域日益占據主導地位

首先當然是先用數據說話。

下圖顯示了頂級研究會議接受論文中,使用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?

簡單。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 未來的研究方向是什么?

即使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

雖然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。

架構「融合」

2018年末,兩件大事徹底改變了這一局面:

PyTorch引入了JIT編譯器和“Torch”,從而引入了基于圖的特性;

TensorFlow宣布他們將在2.0版本中默認轉移到Eager模式。

顯然,這些舉措都是為了解決PyTorch和TensorFlow各自的弱點。那么這些特性到底是什么,它們能提供什么呢?

PyTorch Torch

PyTorch JIT是PyTorch的一個中間表示(intermediate representation,IR) ,稱為Torch。Torch是PyTorch的“圖”表示。你可以通過使用跟蹤或腳本模式將常規PyTorch模型轉換為Torch。跟蹤接受一個函數和一個輸入,記錄用該輸入執行的操作,并構造IR。

雖然很簡單,但是跟蹤也有它的缺點。例如,它不能捕獲未執行的控制流。例如,如果它執行了true塊,它就不能捕獲條件塊的false塊。

模式接受一個函數/類,重新解釋Python代碼并直接輸出Torch IR。這允許它支持任意代碼,但是它實際上需要重新解釋Python。

一旦PyTorch模型進入了這個IR,我們就可以獲得圖模式的所有優勢。我們既可以在C++中部署PyTorch模型,而不依賴Python,或者對其進行優化。

TensorFlow Eager

在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的Torch也有類似的問題)。跟蹤基本上是有限的,重新解釋Python代碼實際上需要重寫Python編譯器的大部分內容。

當然,通過限制在深度學習中使用的Python子集,范圍可以大大簡化。

在默認啟用Eager模式時,TensorFlow將強迫用戶做出選擇——為了便于使用而Eager執行,并且需要為部署而重寫,或者根本不使用急于執行。

雖然這與PyTorch的情況相同,但PyTorch的Torch的可選擇加入特性可能比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,它們的目的只有一個,就是想讓機器學習做到最好。

責任編輯:

相關推薦

相關新聞

回到首頁 回到頂部

網站簡介 - 廣告服務 - 誠聘英才 - 聯系我們 - 法律聲明 - 友情鏈接

加拿大快乐8作假吗