PyTorch 和 TensorFlow的區別

自 2012 年深度學習重新獲得重視以來,許多機器學習框架便爭相成爲研究人員和行業從業人員的新寵。從早期的學術成果 Caffe 和 Theano ,到背靠龐大工業支持的 PyTorch 和 TensorFlow,大量的選擇讓我們很難跟蹤最流行的框架到底是哪個。

 


如果你平常只看 Reddit,可能會認爲每個人都在切換到 PyTorch。如果根據 Francois Chollet 的Twitter來判斷,TensorFlow / Keras 則可能是最受歡迎的,而 PyTorch 的發展勢頭卻停滯不前。
 
在 2019 年,機器學習框架之戰仍然由兩個主要競爭者主導:PyTorch 和 TensorFlow。我的分析表明,研究人員正在放棄 TensorFlow 並大量湧向 PyTorch。同時,在行業中,Tensorflow 當前是首選平臺,但從長久來看可能並非如此。

首先,我們先對這兩者的特性和有點進行簡單的比較:
TF是目前深度學習的主流框架,Tensorflow主要特性:

  • TensorFlow支持python、JavaScript、C ++、Java和Go,C#和Julia等多種編程語言。
  • TF不僅擁有強大的計算集羣,還可以在iOS和Android等移動平臺上運行模型。
  • TF編程入門難度較大。初學者需要仔細考慮神經網絡的架構,正確評估輸入和輸出數據的維度和數量。

TF使用靜態計算圖進行操作 。 也就是說我們需要先定義圖形,然後運行計算,如果我們需要對架構進行更改,我們會重新訓練模型。 選擇這樣的方法是爲了提高效率,但是許多現代神經網絡工具能夠在學習過程中考慮改進而不會顯着降低學習速度。 在這方面,TensorFlow的主要競爭對手是PyTorch 。

TensorFlow優點:

  • 它非常適合創建和試驗深度學習架構,便於數據集成,如輸入圖形,SQL表和圖像。
  • 它得到谷歌的支持,這就說明該模型短期內不會被拋棄,因此值得投入時間來學習它。

PyTorch基本特性:

  • 與TensorFlow不同,PyTorch庫使用動態更新的圖形進行操作 。 這意味着它可以在流程中更改體系結構。
  • 在PyTorch中,您可以使用標準調試器 ,例如pdb或PyCharm。

PyTorch優點:

  • 訓練神經網絡的過程簡單明瞭。 同時,PyTorch支持數據並行和分佈式學習模型,並且還包含許多預先訓練的模型。
  • PyTorch更適合小型項目和原型設計。

再來看看 PyTorch 是如何漸漸縮小與 TensorFlow 之間的差距的。

PyTorch在研究領域的主導地位不斷提高

讓我們看數據說話。下圖顯示了在每個頂級研究會議上,使用 PyTorch 的論文與使用 Tensorflow 或 PyTorch 的論文之間的比率。所有的直線都在向上傾斜,2019 年的每個主要會議的論文都用 PyTorch 實現。


       會議說明:
CVPR, ICCV, ECCV - 計算機視覺會議
NAACL, ACL, EMNLP - NLP 會議
ICML, ICLR, NeurIPS - 綜合 ML 會議
 
有關數據收集過程的詳細信息
該圖根據過去幾年在大型 ML 會議上發表的所有論文生成。根據論文是否提及 PyTorch 或TensorFlow 進行分類,但不包括與 Google 或 Facebook 關聯的作者以及同時提及 Tensorflow和 PyTorch 的論文。這些去處的因素可以在附錄中找到 https://thegradient.pub/p/cef6dd26-f952-4265-a2bc-f8bfb9eb1efb/
 
圖的交互式版本:https://chillee.github.io/pytorch-vs-tensorflow/
 
如果你需要更多證據證明 PyTorch 在研究界的發展速度,下面是 PyTorch 與 TensorFlow 原始統計表。


2018 年,PyTorch 是少數派。現在,它卻已經佔據絕對優勢,使用 PyTorch 的 CVPR 佔 比 69%,NAACL 和 ACL 的佔比在 75% 以上,而 ICLR 和 ICML 的佔比在 50% 以上。PyTorch 不僅 在視覺和語言會議上的統治地位最強(分別是 TensorFlow 的 2 倍和 3 倍),在諸如 ICLR 和 ICML 之類的綜合機器學習會議上也比 TensorFlow 受歡迎。
 
儘管有些人認爲 PyTorch 仍然是一個新貴框架,試圖在 TensorFlow 主導的世界中開拓一席之地,但數據卻揭示了另一個真相。除了 ICML 之外,TensorFlow 的增長速度甚至無法與論文增長速度保持同步。在 NAACL、ICLR 和 ACL 上,今年 TensorFlow 實現的論文實際上少於去年。
 
不是 PyTorch 需要擔心它的未來,而是 TensorFlow。


爲什麼研究人員喜歡 PyTorch?

 
簡單。它與 numpy 類似,非常具有 python 風格,並且可以輕鬆地與其他 Python 生態系統集成。例如,你可以在 PyTorch 模型中的任何地方簡單地插入一個 pdb 斷點就能用了。在TensorFlow 中,調試模型需要有效時間,且複雜得多。
很棒的 API。與 TensorFlow 的 API 相比,大多數研究人員更喜歡 PyTorch 的 API。一方面是因爲 PyTorch 的設計更好,另一方面是 TensorFlow 多次切換 API(例如“圖層”->“超薄”->“估算器”->“ 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 的統治地位可能會開始切斷 Google 研究人員與其他研究社區的聯繫。他們不僅很難在外部研究的基礎上進行構建,而且外部研究人員也不太可能在 Google 發佈的代碼基礎上進行構建。
 
TensorFlow 2.0 是否將獲得新的 TensorFlow 用戶還有待觀察。儘管 eager 模式一定會很吸引人,但對於 Keras API 就不一定了。

PyTorch和TensorFlow用於生產

儘管 PyTorch 現在在研究領域中處於主導地位,但快速過一下產業界就會發現,TensorFlow 仍然是主導框架。例如,基於 2018 年至 2019年 的數據,在公共招聘平臺上,TensorFlow 的招聘崗位有 1541個,而 PyTorch 爲 1437 個,Medium 文章中 TensorFlow 相關文章有 3230 篇,PyTorch 爲 1200 篇,GitHub 上 TensorFlow 和 PyTorch 的 Star 數分別爲 1.37 萬個和 7.2k。
 
因此,如果 PyTorch 在研究人員中變得如此受歡迎,爲什麼它在工業上沒有獲得同樣的成功呢?很明顯,第一個答案就是慣性。TensorFlow 早於 PyTorch 出現,而且行業採用新技術的速度比研究人員要慢。另一個原因是 TensorFlow 在生產方面比 PyTorch 更好。但是,這是什麼意思?
 
要回答這個問題,我們需要知道研究人員和行業的需求有何不同。
 
研究人員關心他們能夠以多快的速度進行研究,這類研究通常是在相對較小的數據集(可以容納在一臺計算機上的數據集)上運行的,並且運行在 <8 個 GPU 上。通常,主要決定因素不在於性能方面,而在於快速實現他們的新想法的能力。另一方面,產業界認爲性能是重中之重。儘管將運行時間提高 10% 對研究人員而言毫無意義,但這可以直接爲公司節省數百萬美元的費用。
 
另一個區別是部署。研究人員將在自己的計算機或專用於運行研究工作的服務器集羣上進行實驗。另一方面,行業有很多限制/要求。
 

  • 沒有 Python。一些公司使用的服務器在 運行 Python 時開銷太大。
  • 移動。你無法在移動二進制文件中嵌入 Python 解釋器。
  • 服務。功能全面,例如無停機更新模型,在模型之間無縫切換,在預測時進行批處理等。

TensorFlow 是專門針對這些要求而構建的,併爲所有這些問題提供瞭解決方案:圖形格式和執行引擎本來就不需要 Python,TensorFlow Lite 和 TensorFlow Serving 分別解決了移動和服務上的顧慮。
 
從歷史上看,PyTorch 未能滿足這些考慮,因此大多數公司目前在生產中使用 TensorFlow。

框架“融合”

2018 年底,兩個重大事件讓事情變得棘手:
 
PyTorch 引入了 JIT 編譯器和“ TorchScript”,從而引入了基於圖形的功能。
TensorFlow 宣佈默認情況下它們將轉爲 eager 模式。

顯然,這些都是試圖解決各自弱點的舉動。那麼這些功能到底是什麼?它們提供了什麼?
 


PyTorch Torch腳本

PyTorch JIT 是 PyTorch 的中間表示(IR),稱爲 TorchScript。TorchScript 是 PyTorch 的“圖形”表示。你可以使用跟蹤或腳本模式將常規 PyTorch 模型轉換爲 TorchScript。跟蹤採用一個函數和一個輸入,記錄使用該輸入執行的操作,並構造 IR。跟蹤雖然簡單明瞭,但也有其缺點。例如,它無法捕獲未執行的控制流。再如,如果執行條件塊,則無法捕獲條件塊的錯誤塊。
 
腳本模式採用一個函數/類,重新解 釋Python 代碼並直接輸出 TorchScript IR。這允許它支持任意代碼,但是實際上它需要重新解釋 Python。
 

             
 
一旦你的 PyTorch 模型進入此 IR,我們將獲得圖形模式的所有好處。我們可以在不依賴 Python的情況下以 C ++ 部署 PyTorch 模型,或對其進行優化。

Tensorflow Eager

在 API 層面,TensorFlow Eager 模式與 PyTorch 的Eager 模式基本相同,該模式最初因爲 Chainer 流行起來。這爲 TensorFlow 提供了 PyTorch Eager 模式的大多數優勢(易於使用,可調試性等)。
 
但是,這也給 TensorFlow 帶來了同樣的缺點。TensorFlow Eager 模式無法導出到非 Python 環境,無法優化,無法在移動設備上運行等。
 
這使 TensorFlow 與 PyTorch 都面臨着各自的問題,並且它們以基本相同的方式來解決——你可以跟蹤代碼(tf.function)或重新解釋 Python 代碼(Autograph)。


              (圖12-4 TensorFlow 如何使用 autograph 和跟蹤生成圖像)
 
因此,TensorFlow 的 Eager 模式並不能真正爲你提供“兩全其美”的體驗。雖然確實可以使用tf.function 批註將 eager 代碼轉換成靜態圖形,但這絕不是一個無縫的過程(PyTorch 的TorchScript 也存在類似的問題)。跟蹤從根本上受到限制,並且重新解釋 Python 代碼本質上需要重寫許多 Python 編譯器。當然,通過限制深度學習中使用的 Python 子集,可以大大縮小範圍。
 
默認情況下,在啓用 Eager 模式時,TensorFlow 會強制用戶進行選擇——使用 eager execution 以簡化使用並需要重寫以進行部署,或者完全不使用 eager execution。這一點TensorFlow 與 PyTorch 相同,但 PyTorch 的 TorchScript 可供選擇,這可能比 TensorFlow 的“默認 eager”更讓人愉快。


機器學習框架現狀


因此,我們得出了 ML 框架的當前狀態。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 在這方面的重大進展。
Google 在產業界的孤立會傷害到它嗎?Google 推動 TensorFlow 的主要原因之一是幫助其迅速發展的雲服務。由於 Google 試圖佔整個 ML 框架垂直市場,這激勵了 Google 的競爭對手(微軟、亞馬遜、英偉達)支持這個唯一可與之抗衡的機器學習框架。

下一步是什麼?

機器學習框架對機器學習研究的影響也許被低估了。它們不僅支持機器學習研究,它們還促進或限制了研究人員輕鬆探索的想法。單是因爲沒有簡單的方法可以在框架中表達,多少新生的想法被扼殺在搖籃之中?PyTorch 可能已經達到了本地研究的最低要求,但是繼續挖掘其他框架能夠提供的能力,以及它們可能帶來的研究機會也是值得探索的。


高階微分:

PyTorch 和 Tensorflow 的核心是自動分化框架。也就是說,它們允許人們採用某些函數的導數。但是,有許多方法可以實現自動分化,而大多數現代 ML 框架選擇的特定實現爲“反向模式自動分化”,通常稱爲“反向傳播”。事實證明,此實現對於採用神經網絡極爲有效。
 
但是,計算高階導數(Hessian / Hessian 矢量乘積)時情況發生了改變。有效地計算這些值需要所謂的“前向模式自動分化”。如果沒有此功能,則計算 Hessian Vector Products 的速度可能會慢幾個數量級。
輸入 Jax。Jax 和 Autograd 的發明者是同一撥人,並具有正向和反向模式自動分化功能。這使得高階導數的計算速度比 PyTorch / TensorFlow 快。


但是,Jax 不僅提供高階導數。Jax 開發人員將 Jax 視爲組成任意功能轉換的框架,包括vmap(用於自動批處理)或 pmap(用於自動並行化)。
最初的 autograd 擁有忠實的粉絲(儘管沒有 GPU 支持,ICML 上仍 有 11 篇論文使用了它),而且 Jax 可能很快就會形成一個忠實社區,將其用於各種 n 階導數。


代碼生成

當你運行 PyTorch / TensorFlow 模型時,大多數工作實際上不是在框架本身中完成的,而是由第三方內核完成的。這些內核通常由硬件供應商提供,並且由高級框架可以利用的 operator libraries 組成。這些就是 MKLDNN(用於CPU)或 cuDNN(用於Nvidia GPU)之類的東西。更高級別的框架將其計算圖分成多個塊,然後可以調用這些計算庫。這些庫代表數千個小時的人工,並且經常針對體系結構和應用程序進行優化,以產生最佳性能。
 
但是,最近對非標準硬件、稀疏/量化張量和新 operators 的興趣暴露了依賴這些 operators libraries 的主要缺陷:它們不靈活。如果你想在研究中使用像膠囊網絡這樣的新operator 怎麼辦?如果要在 ML 框架沒有很好支持的新硬件加速器上運行模型怎麼辦?現有的解決方案經常達不到要求,比如在 GPU 上實現膠囊網絡比最佳實現要慢 2 個數量級。
 
每個新的硬件體系結構、張量類別或運算符,都會大大增加此問題的難度。有許多工具可以解決不同方面的問題(Halide、TVM、PlaidML、Tensor Comprehensions、XLA、Taco等),但是扔不清楚正確的方法到底是什麼。
 
如果沒有更多的工作來解決這個問題,我們就有將 ML 研究過度適合於我們擁有的工具的風險。
 
ML框架的未來

TensorFlow 和 PyTorch 的設計已經趨於一致,以至於任何一個框架都不會憑藉其設計獲得決定性的勝利。雙方各佔一方領土——一個擁有研究界,另一方擁有產業界。
 
在我個人看來,在 PyTorch 和 TensorFlow 之間,我認爲 PyTorch 更有優勢。機器學習仍然是研究驅動的領域。產業界不能忽視研究成果,只要 PyTorch 主導研究,這將迫使公司做出選擇。
 
但是,正在快速發展的不僅是框架。機器學習研究本身也處於不斷變化的狀態。框架不僅會發生變化,而且 5 年內使用的模型/硬件/範例可能與我們今天使用的模型/外觀大不相同。隨着另一種計算模型的普及,也許 PyTorch 和 TensorFlow 之間的鬥爭將變得無關緊要。
 
在所有這些利益衝突以及機器學習帶來的利益中,退一步海闊天空。我們大多數人都不是爲了賺錢或爲了協助公司的戰略計劃而開發機器學習軟件。我們從事機器學習的原因是,我們關心、關注推進機器學習研究,使 AI 民主化,或者只是關注創造有趣的東西。無論你是喜歡 TensorFlow還是 PyTorch,我們都只是爲了機器學習軟件達到最佳狀態。

最後補充一下,在機器學習框架之爭中,除了 TensorFlow 和 PyTorch 之外,還有其他一些用戶也很廣泛的框架,比如 DeepMind 用於創建具有複雜架構的神經網絡,建立在 TensorFlow 基礎之上的 Sonnet,適合初學者快速入門機器學習的 Keras,高度可擴展的深度學習工具 MXNet,可以用來創建複雜的模型的 Gluon,通過直接與通用編程語言集成,可以表達更強大的算法的 Swift for TensorFlow,動態計算圖或網絡神經網絡框架的“大前輩”Chainer,Java 深度學習框架 DL4J,集成各種深度學習框架優點的 ONNX 等,都是具有各自特點的機器學習框架,雖然不如 TensorFlow 和 PyTorch 的受衆廣,但是用於不同類型的任務還是顯示出各自的優勢。
 
原文鏈接:
https://thegradient.pub/state-of-ml-frameworks-2019-pytorch-dominates-research-tensorflow-dominates-industry/

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章