2017年1月18日Facebook發行的PyTorch相比TensorFlow、MXNet有何優勢？

01-13

PyTorch

老Torch用戶說說PyTorch的好處：

加入了autograd，不用自己寫backward了
可以動態生成computational graph，對NLP一些model來說這個特性很有用
module和weight分離，這樣clone module、共享內存的時候就方便快速很多
集中管理內存，和Torch比可以省不少內存
LuaJIT有2G memory的限制，Python沒有這個問題
看常式是可以無縫使用numpy，這個不錯
因為繼承了Torch的後端TH，THNN等等C庫，所以使用以前的nn modules有正確性和速度保證
Python好用庫太多了，多進程啥的搞起來也方便，Lua基本上啥都得自己寫
和Torch比並不會有很大的速度差距，因為LuaJIT在訪問C模塊的時候會有比較大的性能損失

歡迎補充

====================== 6月30日更新 =====================

做了一點微小的貢獻，把最開始隨便寫寫的代碼，變成了一個IBM的開源項目IBM/pytorch-seq2seq，歡迎各種反饋！

====================== 原答案==== =====================

我們的一個項目用到第一名回答我親學長 @董力的donglixp/lang2logic，一個用Torch寫的sequence-to-tree模型。但是我們組裡沒有人熟悉Lua，所以就要我來用別的語言來重現一遍。

在Tensorflow的成熟的企業級應用的誘惑下，我先用TF實現了一遍，君不知用靜態computational graph實現每個輸入都不一樣的樹形結構有多痛苦，TF的control flow的設計簡直反人類。

在我要崩潰了的時候PyTorch出現了，可以用Torch的動態computation graph不說，一方面我懂python，另一方面因為autograd不需要程序員自己寫back propagation，學長代碼里大段的計算梯度的代碼都可以省了。果斷放棄了Tensorflow用兩天時間把學長的工作給重現了。

5.1 更新

8個小時前soumith終於把新的autograd merge到master了，但是0.1.12的release還沒有這個。新的autograd支持gradient是一個variable，並且能夠求高階導了。

-------

重新回來編輯一下答案：

昨天今天花時間寫了一個neuraltalk2的pytorch版本，寫的快感動哭了。真尼瑪簡單。

鏈接在這，ruotianluo/neuraltalk2.pytorch，求star，兩塊錢一個star買不起

背景是這樣的，本來是torch正房，tf小妾，現在是pytorch上位，torch退居二房，tensorflow已打入冷宮。（torch比較熟，tf相對沒有那麼習慣）

以下是我的吐槽，主要比較tf和pytorch：（在我博客里也有My first attempt on Pytorch）

1. 分支和循環：tf的循環和分支首先寫起來非常噁心，不知道你們怎麼覺得，我是寫的要哭。（而且會有莫名其妙bug，比如雙重分支。。）而pytorch中的循環和分支就是普通的循環和分支，跟python一毛一樣的。

2. 在pytorch你可以隨時列印中間結果。完全是過程式編程。（tf也可以列印。。但是。。。呵呵）

3. 你不用過多的去考慮怎麼構建一個圖。圖在你進行forward時候自動就造好了。（當然啦，如果要做更fancy的事情的話，還是需要想著中間怎麼stop gradient之類的）

4. 很容易就去分開graph和graph外的操作可以放到一起，而且可以完美融合。舉個例子你們大概就懂我是什麼意思了。

比如說作beam search。tf的做法是，每一步session run一下，獲得了prob和state，然後在numpy下排序整理，然後在到session run下一步。第一個缺點是，這樣很醜。第二個缺點時，明明可以用cuda的演算法排序，但是這裡因為在session外面，只能使用numpy。

而pytorch下就很簡單，圖內的用variable，圖外的用tensor，圖內的結果要傳到圖外計算，就直接v.data，圖外的結果要扔到圖內，就Variable(t). 非常簡單。

5. 在tf下使用vgg和resnet我都用的是非官方的code。雖然官方提供了model zoo，但官方models里沒有使用這兩個模型的樣例，只有inception。。然後我由於蠢笨，至今沒使官方的model work過。。。。。然而pytorch下，就是一行代碼。。。攤手

===========

速度：~~有可能是我代碼水平有限，現在我pytorch的代碼比tf要慢一倍（但是講道理這是我剛學pytorch頭兩天。。。。）~~ 我把batch size調高速度就接近了。。interesting

理論速度：講道理靜態圖肯定要更快，優化一勞永逸。tensorflow fold不知道怎麼跟pytorch比較。我覺得tensorflow fold的演算法應該是通用的（打個問號？）

github：ruotianluo (Ruotian Luo)

blog: Ruotian Luoamp;#x27;s Blog

知乎專欄：https://zhuanlan.zhihu.com/c_73407294

PyTorch比較吸引我的特性有以下幾點：

1. 支持Python, 之前用Lua寫代碼不要太痛苦，各種功能性函數沒有。舉個例子，Lua裡面最主要的數據結構是table(類似於Python語言裡面的dict)，table里元素是通過key的形式來訪問的。很多情況下我想訪問table裡面有多少個元素，這要是在python或者java裡面就是table.size()一句話就能搞定的，但放在Lua裡面，唯一可行的方案就是像下面這樣：

function tablelength(T) local count = 0 for _ in pairs(T) do count = count + 1 end return count end

2. 支持autograd，不用自己去定義和數學推導back-propagation. 這個還是比較實用的，記得很早的時候，torch裡面還沒有計算cosine similarity的函數，得自己定義cosine的forward和backward函數，又溫習了一遍微積分=_=不過自己寫backward也是有好處的，這是一個很好的學習過程，對你理解深度學習的原理有很大的幫助。當你的代碼出錯了的時候，你能有個比較清晰的思路從哪裡開始debug.

3. 更容易debug。無論是Torch還是PyTorch的底層都是一個C語言實現的庫函數。在寫深度學習的代碼的時候最痛苦的一塊可能就是debug了。當結果出現問題的時候你不知道你是因為你的hyper-parameter設得不對，還是模型定義的時候出錯了，或者是某一層layer計算的時候出錯了和整個模型的assumption就不適合這個數據集。要找出原因只能不斷的簡化模型並且試錯，這時候PyTorch能夠逐層列印出計算結果就顯得非常靈活了（簡直是NN debug的救星）。雖然其他一些工具Keras也能支持顯示每層layer的output，但是依賴於一些輔助函數，寫起來也比較麻煩。

4. 支持動態圖的創建。現在的深度學習平台在定義模型的時候主要用兩種方式：static computation graph(靜態圖模型) 和 dynamic computation graph(動態圖模型)。絕大部分平台都採用的是static的定義方式，包括TensorFlow, Theano, Caffe，Keras等。靜態圖定義的缺陷是在處理數據前必須定義好完整的一套模型，能夠處理所有的邊際情況。比如在聲明模型前必須知道整個數據中句子的最大長度。相反動態圖模型(現有的平台比如PyTorch, Chainer, Dynet)能夠非常自由的定義模型。舉個例子，傳統的LSTM往往處理一個句子的時候都是以word為單位，然後利用word2vec來初始化詞向量。但是往往有一些很奇怪的詞在vocabulary里是找不到的，也就是沒法用word2vec初始化詞向量。這時候你可能想用characer-level(字元)級別的表示來初始化那個單詞，就需要藉助動態圖模型的定義了。簡單來說動態圖模型允許你在運行程序的時候動態去修正你的模型結構，來處理各種奇奇怪怪的邊角輸入，這在學術研究的時候的靈活性就體現出來了。

上圖左邊為靜態圖的計算框架，右邊為動態圖的框架 [1]。靜態圖需要在處理數據前定義好一套完整的模型；而動態圖模型允許用戶先定義好一套基本的框架再根據數據來實時修正模型。

5. 比LuaJIT比降低了大概30%-50%的內存使用率，而且LuaJIT是有2G的內存上限的(這個有時候很麻煩)。另外謝謝評論區的@peng sun補充，LuaJIT的內存上限是指lua內部的數據結構，比如table, string等，不包括用戶定義的數據結構，比如torch.Tensor之類等，不然把word embedding load到內存里就炸了。。有時候為了避免內存溢出的情況，會用Lua 5.1編譯，而不用LuaJIT。關於Lua 編譯器和LuaJIT的區別，可以參看這個帖子：What makes LuaJIT faster than Lua?

補充一點是，目前版本在效率上比Torch慢5%，可能是因為創建動態圖的時候多耗時了. 在PyTorch網站上有個帖子討論和Torch的比較，可以看看：Roadmap for torch and pytorch

其他一些我會考慮的點：
1. 遷移成本。作為Torch用戶，我已經很習慣它的一套開發流程了，也能夠比較高效的實現定義的模型了。如果要遷移到PyTorch平台，需要學習下裡面的一些函數定義和使用，不想換平台的時候太麻煩。
2. 社區支持。作為一個新開發的平台，PyTorch的社區支持還是比較弱的，還沒有什麼開源的代碼和模型。我不知道有多少老Torch用戶去轉移到PyTorch上面去，但是有一個良好的社區環境是需要長時間的積累的。

在選擇一個深度學習平台上，我會主要考慮易用性，學習成本和社區環境。舉個例子就Torch而言，社區環境很好，但學習成本和易用性上要打個折扣，我想這是很多新用戶可能不會選擇Torch的原因，也是PyTorch開發的一部分初衷吧（降低學習成本和提高易用性來吸引更多的新用戶）。就PyTorch而言，剛開始開放出來社區支持還不是很強，不過最近一段時間口碑上去得很快，社區的增長也比較迅速。總體來說我還是很喜歡PyTorch的編程模式的，非常好用，推薦researcher使用。相反，如果只是想了解一下深度學習，並且快速開發出一套簡單實用的深度學習模型，推薦Keras+TensorFlow作為入門工具(API簡單+文檔全+社區強)。

------------------------------------------------------

最後貼一張Andrej Karpathy博客里各深度學習平台使用比例的圖：

圖片來源：https://medium.com/@karpathy/a-peek-at-trends-in-machine-learning-ab8a1085a106

[1] Chainer: a Next-Generation Open Source Framework for Deep Learning, Tokui, Seiya and Oono, Kenta and Hido, Shohei and Clayton, Justin, NIPS 2015, Learning System workshop.

就作為一個初學者做一點比較談一些感受：

1. Pytorch 才是真的python風格的框架，而不是用python在寫其他語言風格的代碼。這種風格我們一般用elegant來形容。

2. Pytorch的Tutorial和doc對初學者更友好，tensorflow的tutorial感覺真的寫的有點邏輯混亂。當然tensorflow有社區優勢所以這個不算什麼大的差距。

3. Pytorch現在還是beta版，有一些bug以及底層優化、速度上還有待進步。

4. 動態結構對NLP，RNN友好，這一點上估計少有爭議了。

5. Pytorch更便於調試，符合研究人員的使用習慣，可視化之類的工具相信很快能跟上的。

順手夾一點私貨，fork過來自己改進的一個小dependency parser，剛開始入門NLP和使用github，非常感謝如果您提出任何的意見。

Graph-based dependency parsers based on BiLSTMs

https://github.com/xiezhq-hermann/bist-parser

PyTorch的出現，應該說確實體現了Python科學計算生態圈的廣大潛力。。。

尚未上手，先用文檔來放些嘴炮拋磚引玉。。

Python first PyTorch is not a Python binding into a monolothic C++ framework

還沒仔細看源代碼，所以這裡的深度使用Python還不清楚是做了什麼，因為後面也有寫

At the core, it』s CPU and GPU Tensor and Neural Network backends (TH, THC, THNN, THCUNN) are written as independent libraries with a C99 API.

計算相關的代碼是用嵌入的C寫的

無縫嵌numpy代碼這一點挺帶感：

import torch from torch.autograd import Function from torch.autograd import Variable from numpy.fft import rfft2, irfft2 class BadFFTFunction(Function):


    def forward(self, input):

        numpy_input = input.numpy()

        result = abs(rfft2(numpy_input))

        return torch.FloatTensor(result)
    def backward(self, grad_output):

        numpy_go = grad_output.numpy()

        result = irfft2(numpy_go)

        return torch.FloatTensor(result)

# since this layer does not have any parameters, we can # simply declare this as a function, rather than as an nn.Module class def incorrect_fft(input): return BadFFTFunction()(input) input = Variable(torch.randn(8, 8), requires_grad=True) result = incorrect_fft(input) print(result.data) result.backward(torch.randn(result.size())) print(input.grad)

繼承pytorch中的Function類就可以無縫嵌入，但這裡看，似乎存在兩次轉型：torch相關類型(forward里的input參數和backword函數里的grad_output參數)轉成numpy array-like(暫無實操，不清楚這裡具體是ndarray還是其他的)，numpy計算完了再轉回torch Tensor。

這個轉型操作的效率如何，也沒有看到具體文檔，縱觀全部文檔，也暫時沒有橫向比較Benchmark，簡單的一句

it』s one of the fastest implementations of it to date

似乎沒有什麼說服力。。。

另外縱觀各類TensorFlow ML項目，因為使用者各有各的偏好，許多人都沒有發揮這些庫的巨大威力，濫用大數組、在原生Python代碼和TensorFlow之間頻繁切換、用循環而不是矩陣操作

這些問題不是一個庫可以解決的。但開發經驗會慢慢變好的

簡單的掃了一眼，沒有發現PyTorch中存在的和TensorFlow類似的if、while控制流。。所以類型轉換、c-python切換的代價。。。總之得看benchmark。。

PyTorch 90天一個release版本，按照路圖，下一步會有：

分散式支持 (Tensorflow已經有了
Backward of Backward (反向傳播的反向傳播么。。) 支持
autograd的惰性求值引擎支持，以對autograd進行JIT支持————Python沒有lua那麼好用的JIT，這是個痛點。。TensorFlow的圖計算上面的話，有人提過這樣的問題，但目前進度未知

先玩玩吧。。

對我而言，好處就是很多原先torch實現的代碼不用再去看奇葩的lua語法了，現在框架太多專註一個，做深很難了，其他不深入的框架更多的是能夠閱讀好代碼配合理解原理，真正工程化選擇好你最熟悉的對比優勢不太了解，torch沒有深入過。

用了一段時間來回答一下：

一個詞形容pytorch：elegant

另外見下圖：can"t agree more.

reddit上這個問題的討論也很熱烈 [D] Pytorch vs Tensorflow

機器之心的翻譯： PyTorch和TensorFlow到底哪個更好？

facebook以後可能會主推pytorch了，torch的一些庫還會繼續開發，但是FAIR應該會邊緣化torch的使用。新出的大作WGAN就是用pytorch實現的martinarjovsky/WassersteinGAN 。聽說facebook對pytorch的定位是Research，而對caffe2的定位是Production。

最後：動態庫是未來：Chainer， DyNet， MinPy和tensorflow fold。

-----------------------原文----------------------------------------

1 python 表示我不是針對lua，我是說在座的各位都是垃圾（排名前十的框架現在全部提供python介面，或主要提供python介面或只提供python介面）

2 torch/pytorch是命令式，比tf等基於computation graph好寫（個人直覺，尤其是numpy用戶）

3 pytorch相比與torch增加了自動求導（autodiff），這下實現crazy RNN 輕鬆了許多--torch也有graph模塊可構建圖自動求導

4 pytorch 相比與tf的圖模型實現了一種動態的構建方式，類似chainer 和DyNet，比tf的靜態圖好用，好調試

5 性能估計略輸torch，坐等benchmark

6 作為之前torch的老用戶必須吐槽lua的冒號語法，全局變數，REPL：th，notebook：itorch 跟ipython和jupyter python notebook真的差的不是一星半點

7 Facebook出馬，質量有保證。

8 torch的文檔無力吐槽不僅少，而且分散在各個頁面，希望pytorch能完善。

由於只使用過TensorFlow，所以只能說下與TensorFlow之間的差別。

pytorch建立的是動態圖，TensorFlow建立的是靜態圖。pytorch更加符合一般的編程習慣，而不是像TensorFlow那樣需要先定義計算圖，然後通過·feed and run·。

tensorflow半年用戶，剛剛接觸pytorch

當我實現了下面這個函數的時候，

def loss_f(labels,logits): """ Args: labels:[batch_size,1] logits:[batch_size,1] """ ###sigmoid(x) = 1/(1+exp(-x)) logits = F.sigmoid(logits) loss =-torch.mean(labels*torch.log(logits)+(1-labels)*torch.log(1-logits)) return loss

我感動到哭，好不好！

不是因為tensorflow實現不了這個簡單的loss，當然tensorflow可以實現

但是作為一個初學者，當我在糾結labels*logits是數乘還是矩陣乘的時候，

對於pytorch：

import torch a = torch.Tensor([[1],[2],[3]]) b = a print a*b

而對於tensorflow：

import tensorflow as tf a = tf.reshape(tf.constant([1,2,3]),shape=[1,3]) b = a c = b*a sess = tf.InteractiveSession() print a.eval() sess.run(c)

別看就多著兩行代碼，給人的感覺是千差萬別的。

實際上學了半年tensorflow，給我的感覺就是所有的函數都想用他原生支持的。。。半年來我一次都沒有寫過上面這個loss function。

簡單建議：如果你是在公司做工程，可以使用tensorflow，精通tensorflow應該可以嘚瑟一會了。如果你是在做research，那麼我建議你使用pytorch。因為你總是需要以最簡單，最快捷的方式去實現你的奇思妙想。

這些開源的軟體平台有和晶元公司對接的嗎？

以前的NVDA是自己搞了一套，軟硬都吃了。現在看來，軟體公司想有新的想法。

這個需要硬體公司的支持，才能打破壟斷。目前看來沒有誰有這樣的具體動作啊。

比如，google 開源tensorflow 但是沒開源TPU設計。把它作為秘密武器了。

亞馬遜和facebook，百度等第二階梯，似乎沒有硬體合作的具體動作。

（目前第一梯隊google+NVDA）

之前寫過較長時間的torch，各方面還是挺麻煩的，比如要自己寫BP，lua好多東西得自己重複造輪子，而且lua本身也有很多坑，特別是默認全局變數和table這個看似能實現任意數據結構的東西。torch實現的多gpu訓練確實比tf快一些（可能比mxnet慢一些），但寫起來和用起來都麻煩一些。

試了下pytorch，發現這東西api高層和底層的基本夠用，而且最大的好處是不用像在tf中思考什麼是構建圖的部分，直接用python的思維就可以了。和tf對比起來，其api是更為簡潔，但是要不是之前寫過torch，api還是不那麼熟。而tf的api基本和numpy差不多，更為友好而且文檔更加良心，但tf最大的痛點在於調試的時候不能用動態size。基本來說，二者都能實現dl，ml以及通用的矩陣演算法，只是編程思維需要稍微轉變下。

PyTorch的發布說明各大框架已經全面使用python作為前端，和python自帶的庫無縫鏈接(tf和mxnet的minpy都在儘力達到這個目標)，這一點非常便利。

另外也有答案提到將來可能作為keras的後端，這對於做一些高層次的模塊堆積是很方便的。我更期待的是，各大框架前端統一，而且後端可隨意調用任意框架的模塊進行組合，合理利用各框架的優勢進行互補，類似最近出來的NNVM或者其他VM的思想。

pytorch還是思路挺不錯的。。 define and run的思路大大方便debug 不過用了很久tensorflow換個框架感覺理由還不充分。。首先tf的開源社區更活躍先入為主很多論文都有快速的開源tf實現版本用戶數量很大程度決定框架成敗另外目前pytorch遠沒有 tensorflow成熟，比如沒有sampled softmax支持，比如計算loss得到一個標量，我想獲取batch每個instance的loss呢。。

如果連變長mini_batch都不知道，那隻能說明對TF還不熟悉。現在深度學習框架的市場爭奪越來越火熱，正是對深度學習方向的一種肯定！

Keras表示python早就可以用tensorflow了

用了pytorch之後就再也不想碰tensorflow了

另外， tensorflow真是不知道怎麼處理變長的minibatch，每次想要reshape的時候都一陣蛋疼。。

目前，pytorch沒有windows版本，在linux下必須先安裝Torch。

等待綁定Python的Torch，如果torch真的好，會有人做的。

感覺支持numpy是個很好的事情