Theano、TensorFlow、Torch、MXNet 再到近日比較熱門的 PyTorch 等等，深度學(xué)習(xí)框架之間的比較一直以來都是非常受人關(guān)注的熱點話題。不過你知道用戶實際用起來的感覺怎么樣嗎？近日，Reddit 用戶 cjmcmurtrie 發(fā)了一個主題為「PyTorch vs. TensorFlow」的討論帖，想要了解這兩大流行的框架之間各自有什么優(yōu)勢。

[[184501]]

帖子一樓寫道：

我還沒有從 Torch7 遷移到 TensorFlow。我玩過 TensorFlow，但我發(fā)現(xiàn) Torch7 更加直觀（也許是我玩得不夠？）。我也嘗試了一點 PyTorch，所以我決定先看看效果。

使用了幾周 PyTorch 之后，我認(rèn)為我現(xiàn)在還不必遷移到 TensorFlow，至少在我感興趣的項目上還不需要。用 PyTorch 寫自定義模塊真是簡單至極。而且其動態(tài)圖構(gòu)建（dynamic graph construction）給我之前需要熬夜實現(xiàn)（或等待列表上）的東西帶來了很多新想法。我認(rèn)為對機(jī)器學(xué)習(xí)開發(fā)者來說，PyTorch 是一個了不起的工具集。我也知道 TensorFlow 的社區(qū)資源要強(qiáng)大得多，但如果要開發(fā)全新的項目（而不是為已有的架構(gòu)重新寫代碼或閱讀教程），社區(qū)也不一定能有很大的幫助。

這個 Reddit 帖子發(fā)出后得到了很多機(jī)器學(xué)習(xí)研究者和開發(fā)者的關(guān)注，他們紛紛跟貼談?wù)撟约旱南敕ê徒?jīng)驗（不只是關(guān)于 PyTorch 和 TensorFlow，討論中還涉及到更多工具）。

下文為我們提煉的一些觀點，原帖請看：https://redd.it/5w3q74

TensorFlow 

優(yōu)勢：

• 等效的圖形編譯（graph compilation）要快得多；我們用了幾秒而不是幾分鐘。但是它仍然不夠快，如果我們想要將它的大部分添加到我們的 CI 套件（CI suite），但我們不需要等待很長時間來開始訓(xùn)練。

• 從 Lasagne 轉(zhuǎn)到 TensorFlow 之后，我喜歡 tf.layers 和 tf.contrib.layers 中更高層次的功能；它們?yōu)榻邮軓埩浚╰ensor）并返回張量的功能性 API，因此更容易與「原始」的 TensorFlow 集成。我們可以做普通的張量操作，而不用寫一個層那么麻煩。

• 在我們使用的模型上，TensorFlow 的速度稍稍快于 Theano（20％-30％）。當(dāng)***次使用時，我們看到大致相同的性能，并認(rèn)為這可以接受，但然后我們閱讀 TensorFlow 的性能指南（https://www.tensorflow.org/performance/performance_guide），并切換到 NCHW 并融入批處理規(guī)范（batch norm），然后一切運行得更快了。我猜 Theano 本身就不是很快……

• 關(guān)于開發(fā)人員的反饋速度：我曾在 TF 的問題區(qū)提出了一些微不足道的問題，但 TF 開發(fā)人員通常在一兩天內(nèi)就回復(fù)我了。

• 此外，工具是相當(dāng)好的。TensorBoard 絕對好用，用來表示的時間線（timeline）/跟蹤（trace）的工具也一樣好用。但是我還沒有嘗試新加入的 tfdbg。

• TensorFlow 在設(shè)計時就考慮到了分布式，所以如果你需要運行真正的大規(guī)模項目，TensorFlow 多半是***的。

缺點：

• TensorFlow 的 API 非?；闹嚕诿總€階段都會重新發(fā)明輪子，并且要求開發(fā)者學(xué)習(xí)很多本不必要的新概念。然而，開發(fā)者峰會表示這一境況正在改善——而且同時使用 TensorFlow Servin 和 Cloud ML 會提高你的生產(chǎn)力。

• 在實踐中部署到 iOS 非常困難。

• 我并沒有在 Keras 或者 Tensorflow 上工作，但是我看過他們的「問題」日志和一些用戶組，只是因為大量的用戶，這些框架看起來并不會得到這種個人的關(guān)注。

PyTorch

優(yōu)勢：

• 它屬于輕量級；

• 它目前位于 Python 中；

• 它使你能夠明確地控制計算。沒有編譯器能自己妄圖變聰明來「幫助你」，或是將你的代碼加速；事實上大多編譯器在調(diào)試中會產(chǎn)生大量麻煩；

• 它使 GPU 內(nèi)核調(diào)用之上僅有少量（可解釋的）抽象層，而這恰恰是高性能的保證；

• 也許這是個人偏好，但我得到了與抽象有關(guān)的特定 OCD。每當(dāng)我要做艱巨的工作時都會很緊張，因為一旦我的未來被泄漏，我便能感覺到它那些無法擺脫且難以忍受的痛苦。相對簡單的事情理應(yīng)在引擎蓋之下發(fā)生的大多數(shù)情況下，這種感覺尤為強(qiáng)烈；

• 調(diào)試更容易，因為特定代碼中會是特定行（而不是在距離使用大型或生成的 Graph 對象的 sess.run（）很遠(yuǎn)的地方）失敗。你的堆棧跟蹤不會填滿三個屏幕來讓你玩「找找錯誤在哪里！」的豎版卷軸游戲；

• 不存在編譯時間。我無法理解 Theano 用戶是如何處理的，他們一定更有耐心；

• 你可以直接操作漸變，顯然，做一些事情時可以更容易，也更自然（如在反向傳播過程中的漸變剪輯，或各種「破碎的反向傳播」的有關(guān)想法，就像最近的 Shake Shake reg 命令一樣；的確，我認(rèn)為你可以用 stop_gradient 破解一個解決方案）；

• 它對動態(tài)圖的支持從一開始就是自上而下的設(shè)計原則，而非隨之而至的事后想法。并且我們會看到更多的動態(tài)圖表，如做成一大塊 NLP，或是神經(jīng)模塊網(wǎng) ；

• 它沒有縮進(jìn)或膨脹你的代碼的顯式會話對象；

• 它獲得的抽象是正確的：raw numpy - > Tensors（但 GPU 上的 raw numpy 可能對深度學(xué)習(xí)一無所知?。? >變量（它們了解深度學(xué)習(xí)），并且 Modules 或 Optim 等等會稍有益處。

• 動態(tài)計算使很多事情更加容易，如 seq2seq + attention 的神經(jīng)翻譯很難通過 keras + tf 來實現(xiàn)，但使用 PyTorch 便會很容易；

• 更容易調(diào)試，因為你可以只使用標(biāo)準(zhǔn)的 PyThon 工具；

• PyTorch 讓自定義的實現(xiàn)更加容易，所以你得以將更多時間專注于算法中，這樣往往能夠改進(jìn)主要性能；

• 使 Multi-gpu 簡單易懂；

• Torch-vision 使加載和變換圖像變得容易。

• PyTorch 提供了一個強(qiáng)化功能。增強(qiáng)功能基本上不會在實現(xiàn)中產(chǎn)生過多資源消耗，能有一些內(nèi)置函數(shù)來調(diào)用 RL 的感覺真棒。

• 我遇到的錯誤或問題得到PyTorch 團(tuán)隊及時的反映，通常會在當(dāng)天修復(fù)，或者得到解決方法或得到問題跟蹤。

• PyTorch 是可以立即使用的，在我當(dāng)前的項目的單 GPU 的訓(xùn)練時間比 theano+lasagne 快 100%。我測試過，100% 逐字地在 CIFAR100 上從（在最簡單的情況下）5 分/歷元到 2.5 分/歷元，并且在某些情況下降到 2 分鐘/歷元（即，快兩倍）

缺點：

• PyTorch 的 API感覺有些粗糙，但對它有一些限定詞。如果你只是做一些標(biāo)準(zhǔn)的任務(wù)（實現(xiàn) ResNet 或者 VGG）我認(rèn)為你不會有問題，但我一直都有一些分歧因為我所做的一切都有些奇怪。

• 對于 PyTorch 我***的「抱怨」基本上是在神經(jīng)網(wǎng)絡(luò) API 方面「事情并未按照我讓他們組合的方式進(jìn)行放置」。具體來說，我非常喜歡 Lasagne 的「層次（layers）」范式—但是一點點批判性的思維就會讓你得出這個結(jié)論，這個范式尤其不適合動態(tài)圖框架。

• PyTorch 沒有為部署設(shè)計，開發(fā)團(tuán)隊它看上去并沒有把重心放在 PyTorch 上（雖然在這方面，我可能看錯了，我模糊的記得我在論壇的帖子上看到過這個）。我想要練習(xí)將一些東西放置在網(wǎng)站或者 droid app 上我不確定其他的框架能很好地支持這種方式。