雲CPU上的TensorFlow基準測試：優於雲GPU的深度學習

選自Minimaxir

作者：Max Woolf

機器之心編譯

參與：乾樹、李澤南

越來越多的開發者正在使用雲服務來訓練和運行模型，然而目前看來這種做法的成本較高。不過相比雲 GPU 而言，動態分配的雲 CPU 就便宜很多了。前蘋果員工 Max Woolf 最近測試了雲 CPU 陣列在執行 TensorFlow 任務時的效率，並得到了令人滿意的結果。利用價格差使用雲 CPU 代替 GPU 可以為我們節約不少使用成本。

我一直在使用 Keras 和 TensorFlow 開展一些個人深度學習項目。但是，使用 Amazon EC2 和 Google Compute Engine 等雲伺服器來訓練神經網路模型需要付費。鑒於本人目前並未工作，我必須留意無關花費，並儘可能地具有成本效益。我曾試為了省錢，試過在廉價的 CPU 而不是 GPU 上訓練我的深度學習模型，出乎意料的是，這隻比在 GPU 上訓練略慢一些。因此，我深入了解了這兩種類型的實例的定價機制，看看 CPU 是否對我的需求更有用。

在谷歌計算引擎上的 GPU 版本的價格最低是 0.745 美元/小時（通過將0.700美元/小時 的 GPU 裸片連接到0.045美元/小時 n1-standard-1 實例上）。幾個月前，谷歌宣布其基於 Intel Skylake CPU 架構的 CPU 實例可以配置多達 64 個虛擬 CPU，更重要的是，它們也可以用在可搶佔的 CPU 實例中，它們在 GCE 上最多可以存活 24 小時，隨時可能會掛掉（不過很少見），但是它的價格卻是標準實例的 20%。具有 64 個 vCPU 和 57.6GB RAM 的可搶佔的 n1-highcpu-64 實例加上使用 Skylake CPU 的附加款的總價是 0.509美元/小時，花費大約是 GPU 實例的 2/3。

如果在 64 vCPU 上的模型訓練速度與 GPU 版本差不多（或者就略慢那麼一點），那麼用 CPU 來代替 GPU 就是划算的。但是這些結論都是假設深度學習軟體和 GCE 平台硬體的運行效率達到 100％; 如果不能達到（很可能不會），則可以通過縮減 vCPU 的數量和相應的開支來省錢。

由於沒有需求，所以沒有使用大量 CPU 對深度學習庫進行基準化測試方法。同時 GPU 是深入學習硬體的奧卡姆剃刀問題的解決方案。由於谷歌財大氣粗，可搶佔實例提供了巨大的價格差，所以目前選擇使用 CPU 而不是 GPU 進行深度神經學習訓練是划算的（儘管這有些違背直覺）。

配置

我已有一個現實運用的深度學習案例的基準化測試腳本，Docker 容器環境，結果日誌在另一篇文章中：http://minimaxir.com/2017/06/keras-cntk/

幾處小小的改動就可以讓這份腳本適用於 CPU 和 GPU 實例（通過設置 CLI 參數）。為了支持最新的 TensorFlow (1.2.1)，我重建了 the Docker container，並且創建了 CPU 版本的容器，而不是只安裝對應 CPU 版本的 TensorFlow。

此處有個值得注意的 CPU 版本 TensorFlow 特有的現象；如果你是從 pip 安裝（按照 official instructions 和教程推薦的方法）並開始用 TensorFlow 訓練你的模型，你將會在控制台看到這些警告：

為了修復這些警告並使用 SSE4.2/FMA 這些優化指令集，我們要從源代碼編譯 TensorFlow，我還創建了第三個 Docker 容器。在新容器中訓練模型時，大多數警告不再顯示，（spoiler alert）確實在訓練時有加速作用。

我們可以使用 Google Compute Engine 測試三個問題：

• Tesla K80 GPU 實例

• 使用 pip 安裝 Tensorflow 的 64 Skylake vCPU 實例（同時在 8/16/32 vCPUs 上測試）

• 使用 CPU 指令集（+ 8/16/32 vCPUs）編譯 TensorFlow 的 64 Skylake vCPU 實例

結果

對於每個模型架構和軟/硬體配置，我通過在訓練模型時運行前文提到的測試腳本來計算相對於 GPU 實例訓練的總訓練時間。在所有的模型中，GPU 實例都應該是最快的訓練配置，而且多處理器系統應該比少處理器系統的訓練速度更快。

我們從手寫數字數據集 MNIST dataset 和常見的使用緊密的全連接層的多層感知機 (MLP) 結構開始。訓練時間越短越好。所有低於水平虛線的配置都好過 GPU；反之則不如 GPU。

在這裡，GPU 是所有平台配置中最快的，但還有其它奇怪的走勢。

32 個 vCPU 和 64 個 vCPU 之間的性能差異不大，編譯過的 TensorFlow 庫在訓練速度上確實有重大提升，但只有 8 和 16 個 vCPU 時才這樣。也許在 vCPU 之間進行信息交換的消耗抹去了多 vCPU 的性能優勢，又或許是這些開銷與編譯的 TensorFlow 的 CPU 指令集有所不同。最後，這是一個黑盒子，也就是我為什麼更喜歡黑盒測試的硬體配置而不是搞純理論。

由於 vCPU 數量對訓練速度的影響很小，那麼顯然減少它的數量是有好處的。對於每個模型架構和配置，我計算了相對於 GPU 實例訓練成本的歸一化訓練成本。因為 GCE 實例成本是按比例計算的（不像 Amazon EC2），我們可以將實驗運行的總秒數乘以每秒實例的成本來簡單地計算實驗成本。理想情況下，我們希望最小化成本。

對於這個問題，CPU 數量越少越划算。現在我們來看看在同一數據集上使用卷積神經網路解決數字識別任務的情況：

不出意料，在卷積網路上 GPU 的訓練速度比任何 CPU 方案快兩倍不止，不過成本結構仍然相同，除了 64 vCPU 比 GPU 成本方面更差，32 個 vCPU 訓練速度甚至快過 64 個 vCPU。我們來深入了解下卷積神經網路，CIFAR-10 圖像分類數據集，以及一個使用深層卷積網路加多層感知機進行圖像分類的模型（類似於 VGG-16 架構）。

與簡單的卷積神經網路（CNN）性質類似，儘管在已編譯 TensorFlow 庫的實例下 CPU 的表現更好。

用在 IMDb 影評數據集上的 fasttext 演算法能判別一個影評是正面的還是負面的，相對於其它演算法，該演算法對於影評分類最為快速。

在這種情況下，GPU 比 CPU 快得多。CPU 數量較少的好處並不是很明顯。儘管如此，官方的 fasttext 演算法實現是為大型 CPU 集群設計的，並且可以更好地處理並行化。

雙向長短期記憶網路（LSTM）極其善於處理類似 IMDb 影評這樣的文本數據，但是在我發布基準測試文章後，Hacker News 上的一些評論指出 TensorFlow 使用的是一個在 GPU 上的 LSTM 的低效實現，因此，實際上這種差異可能還會更加明顯。

等等，什麼情況？雙向 LSTM 的 GPU 訓練速度是任意 CPU 配置的兩倍慢？哇。（實際上，基準化測試使用 Keras LSTM 默認 implementation=0，這對 CPU 而言更好，而在 GPU 上 implementation=2 更好，但不應該導致這麼大的差異）。

最後，尼采作品的 LSTM 文字生成器與其他架構的表現相似，CPU 並沒有對 GPU 造成嚴重威脅。

結論

事實證明，使用 64 個 vCPU 不利於深入學習，因為當前的軟/硬體架構無法充分利用所有 CPU 的計算性能，通常會有與 32 個 vCPU 完全相同（甚至更差）的性能。就平衡訓練速度與成本來說，使用 16 個 vCPU 加編譯的 TensorFlow 來訓練模型貌似是最佳選擇。編譯過的 TensorFlow 庫的 30％-40％的速度提升是一個意想不到的驚喜，但令我震驚的是，雖然增益不菲，但 Google 並未提供具有這些 CPU 加速功能的 TensorFlow 的預編譯版本。

這裡顯示的成本優勢只有在可搶佔的情況下才可能是有價值的；Google Compute Engine 上的常規 high-CPU 實例價格約為 5 倍，因此可以完全消除成本優勢。規模經濟萬歲！

使用雲 CPU 訓練方式的一個主要的隱含假設是，你不需要像 ASAP 那樣的訓練過的模型。在專業用例中，時間及其寶貴，但在個人用例中，我們可以訓練一個模型一整夜，這對個人來說是個很好很划算的選擇，也是我做出的選擇。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！