如何評價Facebook Training ImageNet in 1 Hour這篇論文?

01-05

論文：Accurate, Large Minibatch SGD: Training ImageNet in 1 Hour
論文鏈接：https://research.fb.com/wp-content/uploads/2017/06/imagenet1kin1h3.pdf
摘要：深度學習隨著大型神經網路和大型數據集的出現而蓬勃發展。然而，大型神經網路和大型數據集往往需要更長的訓練時間，而這正好阻礙研究和開發進程。分散式同步 SGD 通過將小批量 SGD（SGD minibatches）分發到一組平行工作站而提供了一種很具潛力的解決方案。然而要使這個解決方案變得高效，每一個工作站的工作負載必須足夠大，這意味著 SGD 批量大小會有很大的增長（nontrivial growth）。在本論文中，我們經驗性地展示了在 ImageNet 數據集上使用較大批量大小在優化上遇到的困難，但如果這個問題解決了，訓練的神經網路會展現出很好的泛化性能。具體來說，當我們使用較大批量大小（達 8192 張圖片）進行訓練時，實驗幾乎沒有精度損失。為了實現這一結果，我們採用了線性縮放規則（linear scaling rule）作為批量大小函數來調整學習率，同時我們開發了一種新的預熱方案（warmup scheme），該方案會在訓練前期克服優化的困難。通過這些簡單的技術，我們基於 Caffe2 的系統可以使用批量大小為 8192 進行訓練 ResNet-50 網路，該訓練不僅在 256 塊 GPU 上只花費一小時就能完成，同時還有匹配小批量的精度。在使用標準硬體從 8 到 256 塊 GPU 調整時，我們的實現達到了 90% 以上的縮放效率（scaling efficiency）。該系統能使我們針對大型互聯網數據高效地執行視覺識別任務。

首先, Facebook 這篇文章不錯. 因為它簡單易懂直截了當地告訴了大家在 neural network 優化中的一些技巧, 而且也大規模地實驗出來給大家信心. （補充。。這篇 paper 有爭議原因是因為 paper 里的技巧都是之前已知的。能做到這個 scale 告訴大家最大 batch size 能到多少以及把結論總結出來是不錯，實驗做的也很專業，然而之前工作得 cite。。話說 google 起標題都起到 one model to learn them all 了。。

然後是私貨時間看了這篇 paper 我覺得我有一種不能再繼續小號潛水的使命感 XD 一些讀者可能會覺得有些驚訝, 這些 trick 實際上在之前的理論已經給出, 而且有很好的解釋 (所以說不僅要看這些好的實驗 paper, 關注理論發展也是有用的, 而且會提供 insight XD)

下面開始 not only tell you how but also tell you why (笑)

先說步長. 在我們的[1506.08272] Asynchronous Parallel Stochastic Gradient for Nonconvex Optimization, In NIPS 2015. 一文中, 指出 SGD 的步長 (learning rate) 選擇應該為 $gamma = 1/sqrt{MKsigma^2}$ 量級才能保證 $1/sqrt{MK}$ 量級的收斂速度 (也就是有並行加速), 其中 M 為 batch size, K 為 iteration 數, $sigma^2$ 為 stochastic gradient 的方差上界. 因為 MK 就是一共使用的 sample 個數, 故在 training 同樣多 epoch 的情況下, MK 為定值, 所以步長應該不變. (咦不是說線性增長么? 馬上解釋!)

之所以不變, 是因為在我們 paper 里使用的 update rule 是

$x_{k+1} leftarrow x_k - gamma sum_{i=1}^M ext{i-th stochastic gradient},$

而 Facebook paper 中是

$x_{k+1}leftarrow x_k - gamma$

也就是他們的 stochastic gradient 是被 average 過得, 如果要保證新的步長跟原來等價就要 $gamma$ 所以 $gamma$ 就要隨 batch size M 線性增長了. 實際上這種步長取法早在我們 paper 之前就已經知道了 (在同步更新 SGD 里, 比如 Efficient mini-batch training for stochastic optimization, In Proceedings of the 20th ACM SIGKDD international conference on Knowledge discovery and data mining (pp. 661-670). ACM.), 我們這篇 paper 是證明了即使 stochastic gradient 非同步更新, 在 nonconvex objective (比如神經網路) 上也可以有線性加速.

下面要講 facebook 這篇文章沒有的 insight. 從

$x_{k+1}leftarrow x_k - gamma$

的步長線性增長我們實際上可以看出這種做法是讓每個 stochastic gradient 係數不變, 也就是跟 batch size 小的時候發揮一樣大小的作用, 那為什麼 batch size 加太大會失敗呢. 因為把這些 stochastic gradient 的平均當成一個 gradient, 那對於這個平均過後的 gradient 的步長為 $Mgamma$ . 在 batch size 很大時候, 這個平均是相當接近 true gradient 的, 總所周知如果用 gradient descent, 步長應該為 $1/L$ 其中 L 為 objective 的 gradient Lipshitz constant, 也就是 gradient descent 步長是常數, 既然 batch size 很大的時候 stochastic gradient descent 趨近於 gradient descent, 那麼步長怎麼能任意線性增大呢? 答案是當然不能. 之前我們說的 $gamma$ 實際上是在 K 遠大於 M 時候的結論. 在一般情況下步長應該取為 $1/(L+sqrt{Ksigma^2/M})$ 在 M 很大時這個步長變成 $1/L$ , 退化為 gradient descent 步長. 所以說步長隨 batch size 線性增長也是不準確的, 確切地說是逐漸增長到定值 (繼續私貨, 這個在我們的 [1606.00498] A Comprehensive Linear Speedup Analysis for Asynchronous Stochastic Parallel Optimization from Zeroth-Order to First-Order, In NIPS 2016. 有, 當然我們這個還是在搞 Async 演算法, sync 的只是 async 的一種特殊情況).

然後是 warmup, 這個其實 dependent on dataset. 前面我們都是把 stochastic gradient 的 variance $sigma^2$ 當作常數, 但是實際中一開始離解的距離比較遠的時候, stochastic gradient 的大小和方差可能很大 (取決於 model 和 dataset), 而逐漸接近解的時候方差逐漸減小 (again, 取決於 model 和 dataset). 於是就會出現一開始取小一些步長的做法.

有人看的話我再慢慢填坑.. 其實這裡面還有很多東西可以討論包括如何解決 bandwidth 和 latency 問題

吐槽 GPU 多的, 以及說什麼幾千 GPU 就更快啥的, 我想說這個事情不是那麼簡單有 10 倍 GPU 速度就能快 10 倍的..

最後的最後, 知乎編輯器能不能測試好了再上線

================================================================

繼續填坑. 之前 @張昊說了 bandwidth 和 latency 的問題. 首先我們來看這些問題怎麼來的. 在用 parameter server 並行的時候, 系統的 topology 如圖

每個 iteration 所有黑色節點從 parameter server 拿到模型 weights, 然後計算 gradient, 再把 gradient push 回 parameter server. parameter server 將這些 gradient 加起來 update 到 parameter server 保存的 weights 上去. 這樣就完成了一個 iteration. 這樣相當於把一個大 batch 分成很多份讓很多黑色節點一起算. 但是問題是如果有很多節點的時候, 每個節點都要和 parameter server 通訊, 對 parameter server 帶寬壓力很大.

非同步並行的 SGD 緩解了這個問題 (比如我之前說的兩個 paper), 因為非同步 SGD 每個節點可以無腦從 parameter server 取 weights 以及無腦 push gradient, 不需要同步, 這樣各個節點跟 parameter server 的通訊可以錯開. 在非同步的情況下, 可以證明在節點數 bound 住的情況下, 可以有跟同步 SGD 一樣的收斂速度. (還是見我前面說的倆 paper).

但如果節點數繼續增多, parameter server 還是會有很大壓力. 這時候我們可以用 AllReduce 方法去掉中心的 parameter server 做同步並行 SGD. AllReduce 具體過程描述起來比較麻煩, 但大體意思是每個節點只跟它相鄰的節點通訊 (比如把所有節點連成一個環). 這樣通訊就不再集中於某個 parameter server, 而是被所有節點分擔了. 但 AllReduce 有一個問題, 如果網路有 n 個節點, 則 AllReduce 要將每份 gradient 切成 n 份再一份一份傳, 這樣會導致網路 latency 比較大的時候, 延遲對整體收斂速度的影響會非常大.

下面來談怎麼解決

我們最新的 paper: [1705.09056] Can Decentralized Algorithms Outperform Centralized Algorithms? A Case Study for Decentralized Parallel Stochastic Gradient Descent 講了在分散式 SGD 中, 比如 topology 可以是

沒有中心的 parameter server. 每個節點 local keep 一份 weights 的複製. 每個節點只需要從它的相鄰節點把他們 local 的 weights 拿來, 跟自己的 average, 然後將自己local 算出的gradient update 到average 過的新 weights 上. 這篇文章證明了在這種情況下整個網路的 local weights 的平均依然收斂, 而且收斂速度與同步並行 SGD 一樣. 也就是說有加速. 而且在這種情況下, 每個 iteration 每個節點只需要跟近鄰通訊一次, 而不是 AllReduce 中的 n 次. 這樣大幅減少了 communication 上的問題, 可以最大幅度地 scale.

目前實驗做到了 112 GPU, 接下來準備做更大的並進一步改進演算法. 我個人認為這個工作是我至今最好的一個, 因為它提供了很有可能大幅增加 scale 的方式, 而且很經濟, 而且有很好的理論保證 wwww 歡迎交流 (感覺回答越跑越遠了

我來說幾點（以下純屬scientific discussion，不涉及任何利益）。

先說正面的：

這個paper對實際應用很有指導價值，他揭示了很多在大minibatch下訓練ResNet的小技巧，empirically回答了一個很重要的問題：怎麼minimize大的batch size對訓練造成的負面影響。主要手段是：如何調learning rate，怎麼加batch normalization，怎麼改loss，怎麼scale梯度，怎麼shuffle data，等等。注意，能夠empirical的回答這個問題的paper是非常非常有價值的，前面某些回答提到了幾篇ICML/NIPS上拿小或簡單的network證bound或者收斂率的paper，這些理論很nice，但理論上和實際應用中還是會有些差距。而這篇paper的writing很直接，直接告訴你這些trick怎麼用，其中有幾個我自己也用到過。我知道知乎上大多朋友看這篇文章可能覺得很新鮮很遙遠，因為真正接觸到&>8張卡並行訓練的人還不多（這裡我說8張卡是因為一個工作站基本上8張就到上限了，而且大部分CV/NLP/ML 實驗室為了省錢都是買這種配置吧），而8張卡能觀測到的大batch size的負面效果其實還不是很明顯（比如，原始150多層的ResNet就是8張卡上訓練的，所以你們可能根本觀測不到這個負面效果）。
結果很好，上到256張卡，訓練ResNet-50這個25M-parameter網路可以達到linear scaling on throughput，accuracy基本和「標準setup持平」（這裡標準setup不一定是單張卡，因為ResNet原始paper也是8張卡一起train的）。也報了絕對時間，從另一個側面顯示出Caffe2的性能非常卓越。

然後再說點我掃了一眼這個paper之後自己的幾個問題。首先介紹一點基本概念，做分散式機器學習系統，我們一般比較關注兩件事。第一，因為我們要設計一個系統，我們通常關注這個系統的性能如何，在機器學習任務上，衡量數據並行的機器學習系統的性能，一般我們都看它能否scale up throughput，比如訓練image classification CNN，我們就看他能不能在node更多的時候，每秒處理更多的圖片。這是一個和收斂不同的評價標準，但是一般throughput高，收斂的都會更快些（但不絕對），因為機器的利用率高，掃數據更快。第二，由於我們在做機器學習，我們最終目標是要更快的minimize某個loss，所以我們關注一些機器學習的metric，比如神經網路收斂到多少accuracy啊，topic model收斂到多少likelihood之類。

所以，圍繞這些標準，我就有以下幾個問題。

如我前面所說，ResNet-50, 這個network是一個很小的神經網路（只有25M parameters）。比較一下其他幾個network，比如CV人常用來抽特徵的VGG19，143M個參數；再比如在某些NLP或者某些extreme classification問題裡面，如果vocabulary/class比較大，參數會直接線性增長起來。舉個例子，Hinton老爺子的那個knowledge distillation的paper你們都應該看過吧，在Google或者Facebook的各個應用場合，分類器最後一層的softmax都是直接上萬的output，這個output連到隨便一個什麼network後面，參數就很容易過100M，這個時候問題是完全不同的，能否保持linear scaling就要很看系統設計了。
ResNet is a special case。這個可能大部分朋友是不知道的，因為畢竟不是每個人都把DL搬到cluster上train過。我記得去年在CMU某個talk的時候也看了一個結果，ResNet-152 （60M個參數，不大且參數分布均勻），128張卡，linear throughput，而且調一調參數也有linear convergence。我自己在CMU內部一個cluster上用Poseidon的分散式引擎和TensorFlow當計算引擎，在32個node上train ResNet-152也有相同的observation ---- ResNet這個神經網路很好train在兩個方面：一是如前所說，這個網路不大，而且參數分布很均勻，所以設計系統達到linear throughput scalability不會太難；其次是這個網路很容易train收斂，尤其是在large batch size下，而且基本不會影響收斂後的泛化性能（當然這個我也沒有一套完整的theory，只是empirically觀測到）。做個比較，如果你去幾十個node上train一下VGG或者某些大一點的RNN，上面這兩個condition就不一定成立，會有新的問題凸顯出來：1. 參數太多了，或者參數分布非常不均勻，通訊的時候bandwidth不夠有瓶頸，或者peak communication峰值太高會爆掉，這些都需要加強系統設計；2. 某些網路在large batch size下訓練時候的收斂會差很多，測試時候的性能差的更多。所以我期待FAIR團隊去這些network上試一下，一是驗證一下這個系統性能是否足夠好，能handle這些cases，二是驗證一下這些DL trick是不是夠general。
既然這是一個典型的分散式訓練應用場景，就難不免談一談系統設計和硬體了。這篇paper看格式應該是扔到了一個ML或者相關的venue上，觀眾也主要是各種煉丹師，所以大家討論的點都在：FAIR怎麼這麼多GPU，accuracy怎麼這麼高。我偶爾也煉煉丹，看到這個也確實能感覺到CMU和FAIR在硬體上距離。不過我還懂一點分散式系統，所以最impress我的倒不是他有多少塊GPU，而是：（a）他用了一個50Gbit Ethernet switch。這個可能大部分煉丹師沒有概念，AWS你們用過吧，AWS那個最貴的p2.8xlarge只有10Gbit Ethernet，大部分普通的用得起的instance，以及你們腳底下那個丹爐可能也就1Gbit。(b) 這個cluster每個node有多少個CPU thread，如果你稍微設計過一下這種分散式機器學習平台，就會發現CPU core比較多提升很大，因為你可以開更多的async的線程提高並行度（對應到parameter server上，你可以開更多的push和pull threads把通信和計算overlap起來）；然而，AWS上p2xlarge僅僅只有4個線程，你沒看錯，就是4個，比你的筆記本還要少。這篇paper裡面argue說我們train ResNet只用了15GbE，但是這個argument並不make sense，因為50GbE的Ethernet用了15GbE和直接用15GbE的Ethernet感覺是完全不同的，舉個簡單例子，比如在某個點你的通信達到peak，15Gb可能就直接卡了，50GbE就很舒服。除了這個，還有很多其他因素，比如latency，等等；這個專攻networking的同學們可以出來說說，我個人在train的時候做了這個對比試驗：我把某個在40GbE上跑的很舒服的實驗搬到10GbE上跑（因為我通過簡單的計算髮現10GbE應該夠了），然而卻發現throughput差了一大截。

以上隨便說了幾點，paper還是很不錯的，大家應該好好appreciate（很多人是把這些藏著掖著不讓別人知道的），大部分的claim在ResNet-50這個模型上得到了客觀驗證。所以，如果你們是想去訓練個ResNet，這個paper乾貨滿滿。但是以下兩點有些問題：1. 在別的network（比如，參數更多，分布不均勻，收斂behavior不太相同的網路）上怎麼樣？2. 某些偏系統的claim上不太恰當，比如用了50GbE卻commodity Ethernet，等等。

最後，我打個廣告，前段時間我們把Poseidon系統update到了v2.0，投了paper中了今年的ATC（一個還不錯的系統會議）。過段時間我會在知乎寫個專欄，比較通俗一點談談分散式機器學習，談談Poseidon，也談談我們組（CMU Sailing lab以及Petuum Inc.）的其他工作以及和對這個大領域的認識，和大家一起分享一下。

我覺得這篇Paper寫的很好，乾貨滿滿，值得收藏。最大的意義在於，FB大佬們提到的trick很多我們也用過，摸索過，試探過，看到大V也用同樣的辦法，就感覺心裡踏實多了。

現在大家的訓練trick都自己藏著掖著，這種state of the art的結果把調參過程說的這麼詳細，還主動幫讀者排坑踩雷，羅列了很多作者認為容易踩的坑，這種Paper難道不是良心大作嗎？

另外這個答案底下為什麼清一色的吐槽256塊GPU, 2048塊GPU。。如果給你256塊GPU，你真的能train出同樣的結果嗎？

（感覺有點偏題）

剛移步fb看了看。

結論：一fair pr確實厲害。二其實不單單是pr的問題，其實還有作者對這些techniques定位。

感覺李沐做mxnet更關注的是訓練速度隨著gpu數目線性增長。但是kaiming的意思是說這篇文章里講到的這些方法，都是我這幾年用到的一些技巧，但是我發現不是所有人都知道，所以就把這些放出來。（一下是不是立意高了起來？）

（但其實技巧確實重要啊，剛開始做dl的時候，老闆說lr，就0.1開始然後converge了就除以10。反正我當時感覺就是這是不是太傻逼了點，那些line seaech啥的都是搞笑嗎）

然而有些作者就情商超低。。直接就是哎呀你明明就是跟我們不一樣什麼的，一點都不懂得說話的藝術。

機器學習方面的技術回答 Kaiming 在 fb 上已經很完整了，在系統設計上面我努力回答一些可能會有人感興趣的問題。 @張昊的系統分析非常不錯，我下面也努力添加了一些對於他文中提到的技術的展開解釋。 @廉相如的理論解釋文章很有意思，我轉給我們的 co-author 啦。

另外，我知道有一些媒體和評論提到了我們沒有引用 @李沐的 PhD thesis 的問題，這是無心之失，在 arxiv 新版本里也當然會加上。對於這個失誤我也代表其他作者表示歉意。希望我們還是專註技術，華人在機器學習領域做到今天這樣的影響很不容易，窩裡斗沒有必要。我個人很敬佩李沐和 Kaiming 的工作，對於文章的異同，可以參見 Kaiming 的回復。

（1）fp16。目前 Pascal 上的純 fp16 計算（16bit IO，16bit accumulation）在不對模型做 tuning 的情況下是很難收斂的，因為 16 bit accumulation 的 mantissa bit 太少，精度損失很大。在 Volta 上的 fp16 計算可以使用 32bit accumulation。所以在文章裡面我們依然保持了最常用的 fp32 計算。關於 Volta 上 fp16 的訓練，英偉達會有後續的介紹，基本的結論是比 Pascal 上的 fp16 要簡單。

（2）50G Ethernet。這個的確是一個值得討論的問題。Ethernet 的 latency 沒有 Infiniband 這樣低，同時價格的確比 Infiniband 要低很多，所以說是 "commodity ethernet" 從數據中心的角度是合理的。當然，很多實際網路比如說實驗室或者 AWS 的帶寬並沒有那麼高，這一點上今早我和 Pieter Noordhuis 討論了一下，如果誰希望在低速的網路環境下復現結果或者探討速度對於 convergence 的影響，歡迎和我們聯繫。我們對此也很感興趣，但是限於各個公司和實驗室的網路設計千差萬別，大家合力分析會更全面。

（3）ResNet50 和其他 CNN 的關係。基本上絕大多數 CNN 的演算法，特別是計算量很大的那些，都比較容易將通訊的時間隱藏到計算當中。AlexNet 是個例外，因為很大的 FC 層，通訊時間很難隱藏，這也是為什麼 Alex Krizhevsky 要做 one weird trick 的緣故。VGG 的 FC 層也有一定問題，Inception 基本上沒有通訊的問題。

（4）Async vs sync。接上條，絕大多數現有產品中的 CNN 訓練都不會需要用到 async 的演算法。從系統的角度說，雖然有知友提到 sync 是 async 的一種特例，但是用 async 實現 sync 一定程度上會損失效率。比如說，用 general parameter server 實現 sync sgd 的話，由於 PS 的星型結構，網路的堵塞情況會隨著 worker 的增加而線性增長。雖然可以通過 sharding 來解決，但是這個會造成資源浪費。另外的解決方案是每一個 worker 同時兼做 sharded parameter server，但是可以發現這其實是 scatter gather allreduce 的實現。另外，數學上，sync sgd 比 async 常常更加穩定，參見 Google 的 Rethinking synchronized sgd 文章。

（5）MPI。熟悉 HPC 的同學可能發現文章中提到了 double buffer ring reduction 這些傳統 MPI 的演算法。的確，在 sync sgd 的上下文裡面，類 MPI 的 api 定義非常優秀，傳統 HPC 也有很多這些演算法的研究。又及，Facebook 沒有直接使用 MPI 的原因是絕大多數 MPI 的實現都太重，而我們幾乎只需要 Broadcast 和 Allreduce，所以我們設計了更輕的 Gloo。

（6）再說 Parameter server。上面說 async vs sync 的時候提到很多 CNN 的訓練並不需要使用 ps。這不是說 ps 完全沒有用處，比如說我們在訓練 sparse + dense 聯合的模型的時候，會混用 ps 和 sync sgd，甚至疊加 hogwild 這樣的情況。所以基於不同的網路計算和通訊的比例，可以選擇不同的通訊方式。

（7）對於 framework 的要求。基本上的需求是下面幾個：（a）需要有足夠優化的數據 IO 以及 prefetching，（b）需要有基於 computation graph 的計算引擎保證 concurrent communication and computation，（c）需要 framework 的 overhead 足夠低。該演算法是可以在絕大多數現代的 DL 框架上重現的。對於早期框架，比如說 Caffe 或者 Torch，倒是會比較困難。

（8）Caffe2。我們重構 Caffe 到 Caffe2 的目的，一部分就是從系統上支持這些研究項目，另外一點是模型可以無縫轉到各個應用平台，所以用 Caffe2 是一個比較自然的事情。但是我們在文章中明確指出，我們的演算法在滿足（7）條件的任何框架下應該都可以重現。

（9）CPU。在訓練中 CPU 主要起到數據 preprocess 以及 GPU scheduler 的作用。的確，有足夠多核的 CPU 對於計算是很重要的。如果機器 GPU 足夠多但是 CPU 的算力不夠的話，會需要有其他的方法 - 比如說在其他機器上做數據的 preprocessing，或者把 preprocessing 完全放到 GPU 上 - 這些方法來平衡 CPU 和 GPU 之間的 load。

（10）成本。這個無法估計非公開的數字，而且還有科研迭代的 cost。但是演算法出來以後，訓練的成本其實並不比傳統演算法更高，同時可以在更短時間內得到結果 - 這也是為什麼 strong scaling 那麼重要的緣故之一。按照 aws p2.8xlarge 的價格，訓練一次大概是 230 美元，這個應用成本對於一般創業公司也都是可以接受的。

就想到這些，如果有需要我會再補充。

-- 轉貼 Kaiming 在 Facebook 上對於文章 impact 的評論 --
We had an internal debate on whether we should publish a paper describing how we can achieve the results. I agree there is not so much new, because these have been what I and my colleagues had been doing in the past few years, including how we developed ResNets and Faster R-CNN. After discussing with many people including current/former scientists/engineers from Microsoft, Facebook, Google, Baidu, and universities, we realized that not all the details are widely known by practitioners, engineers, or researchers, and in general there had been limited success at this scale. So finally I was convinced that we should write this white paper: we hope it may be a helpful manual for people who might miss something in their systems.

In my experience, 「linear scaling lr」 is so surprisingly effective that it helped a lot for us to prototype and develop computer vision algorithm in the past few years, including ResNets, Faster R-CNN, and Mask R-CNN, on the old days when we didn』t have enough 8-GPU or even 4-GPU machines or when we need to migrate baselines. By 「surprisingly effective」 I mean that we don』t need to re-select any hyper-parameters (in contrast to picking individual lr and schedules as people usually do). This linear scaling lr is not a new thing: in our paper (Sec. 2.1 「Discussion」, p3) we cited Leon Bottou et al.』s survey paper [4] which gave theories behind linear scaling lr (and also warmup). Through personal communications with Leon we realized that this theory is so ancient and so natural that we are even not able to trace back who did it first. I hope to recommend this linear scaling lr 「rule」 (or theory) to broader audience as I benefited a lot from it in the past few years.

On the contrary, I had little successful experience using the 「sqrt」 rule: one experimental results can be found in Table 2(a) in our paper. There are discussions on the theoretical correctness of the 「linear scaling」 rule vs. the 「sqrt」 rule; but in this paper we share our rich empirical results (covering ImageNet/COCO, pre-training/fine-tuning, classification/detection/segmentation) to the readers and give strong support to the linear rule, as I have experienced in the past few years.

You mentioned 「not stable」 results using the linear scaling lr rule. This is consistent with our motivation of presenting the warmup techniques, which may find its theoretical support from [4]. I also benefited a lot from the warmup strategy in my research experience in the past few years, which helped me to scale out simpler and made my life much easier. We hope this can help some (if not all) researchers and engineers.

其實個人認為這篇工作價值很大，雖然我們學術界是沒那麼多卡來複現了，不過很多東西是很有實踐的指導意義的。

之前就有相關工作指出，當batch size增大時，網路的泛化效果會降低，例如ICLR 2017的兩篇文章：（ENTROPY-SGD: BIASING GRADIENT DESCENT INTO WIDE VALLEYS， LeCun的）https://arxiv.org/pdf/1611.01838.pdf ，（ON LARGE-BATCH TRAINING FOR DEEP LEARNING: GENERALIZATION GAP AND SHARP MINIMA, intel的，文章有提到這是LeCun的idea）https://arxiv.org/pdf/1609.04836.pdf ，以及 Automated Inference using Adaptive Batch Sizes （AISTATS 2017，這個主要是慢慢增大batch size這個trick），當然也有一些爭議：例如

ICML 17的（Sharp Minima Can Generalize For Deep Nets， Bengio的文章，主要側重於理論分析，沒細看，沒有看到對於增大batch size後保持泛化能力的的相關insight）https://arxiv.org/pdf/1703.04933.pdf

總之，batch size增大，特別是增大的比例超出平時的想像能力之外的時候，想要保持同樣的泛化效果是non-trivial的。（個人之前也有相關的經歷，發現這確實是個問題。。。）

FAIR的這個工作厲害之處就在於，巧妙地結合了之前的一些文章中提出的相關tricks，成功地達到了很好的效果，並且文章從另外一個角度指出，batch size增大使得訓練更困難，而不是更容易到sharp minima，anyway，實踐效果好就足以說明一切。期待後面有更好的理論分析，以及相關其他任務上的證據。

其他有的文章也做了很大batch size的工作，但是並沒有看到說關於泛化能力的分析，很多只是關注於線性加速什麼的，即使加速再多，如果泛化能力損失了有啥用。。。

學術界的貧富差距越來越大了。

何不食肉糜？

當時我們老闆聽說買工作站5W+的時候

語重心長的和我們說：

設備是必須的嗎？

你們就要多考慮深度學習怎樣能兼容到普通電腦上。

雖然當時很氣憤

但我覺得這才是我們需要向老一輩學術人學習的科研狀態

很早就說過真正深度學習是有錢人的遊戲~

沒錢的小機構真是連參與這個遊戲的資格都快沒有了~

現在谷歌在全力部署Tensorflow以及自己的TPU，我反而更期待看到谷歌是不是會拿什麼成果來懟回去

我認為文章本身還是有很多技術幹活可以學習的，一如既往fair的extensive experiment。至於256gpu，2048gpu這一類的，也只是吐槽而已，因為做研究首先需要發現問題再解決問題。解決不解決另說，但是因為這個N塊gpu，多數人連發現問題的資格都沒有了23333。

對學術圈越來越沒興趣了。整天就是這些東西。希望我不是一個人。

1.我有錢

2.快來用caffe2

出了關注fb的pr外，其他的一些trick不才是對自己對有用的嗎？

256塊gpu，怪我咯