谷歌雲TensorFlow性價比測試：CPU比GPU表現更好

問耕 編譯整理

量子位 出品 | 公眾號 QbitAI

作者Max Woolf畢業於卡內基梅隆大學，曾是蘋果公司的軟體工程師

我一直在用Keras和TensorFlow搞一些深度學習的個人項目。然而用亞馬遜和谷歌的雲服務可不是免費的，從成本方面考慮，我嘗試使用更便宜的CPU實例，而不是GPU實例來節省資金。沒有想到的是，這隻讓我的模型訓練只慢了一點點。

於是我決定進一步研究一番。

Google Compute Engine（GCE）上GPU實例的價格為0.745美元/小時（0.7美元/小時的GPU+0.045美元/小時的n1-standard-1實例）。幾個月前，谷歌推出基於英特爾Skylake架構、最高有64個vCPU（虛擬CPU）的CPU實例。

更重要的是，這些可以應用在Preemptible CPU實例（一種更便宜、更經濟的經濟虛擬機服務）中，這種服務最多可以在GCE上存在24小時，而且可以隨時終止服務，費用只有標準實例的20%。具有64個vCPU和57.6GB RAM的preemptible n1-highcpu-64實例，價格為0.509美元/小時，約為GPU實例價格的三分之二。

如果使用64個vCPU的模型訓練，與使用GPU訓練速度相當（哪怕略慢），那麼使用CPU顯然從成本考慮更加划算。不過這個結論是基於深度學習軟體和GCE平台硬體運行效率達到100%，如果效率沒這麼高，可以通過減少vCPU的數量來降低成本。

所以，使用CPU而不是GPU來進行深度學習訓練，到底可不可行？

設置

我之前就有真實情況下深度學習的性能測試腳本、Docker容器環境以及TensorFlow vs. CNTK對比測試的結論。只需要一些小調整，就可以通過設置CLI參數，讓腳本用於CPU和GPU實例。我還重建了Docker容器，以支持最新的TensorFlow 1.2.1；還創建了一個CPU版本的容器，以安裝適用於CPU的TensorFlow庫。

使用CPU時，如果使用pip安裝並且在TensorFlow里訓練模型，你會在控制台中看到這樣的警告：

為了解決這些警告，並對SSE4.2/AVX/FMA進行優化，我們從源代碼編譯了TensorFlow，並創建了第三個Docker容器。在新容器中訓練模型時，大多數警告都不再出現，而且確實提高了訓練速度。

這樣，我們就可以使用Google Cloud Engine開始測試三大案例：

一個Tesla K80 GPU實例

一個64 Skylake vCPU實例，其中TensorFlow通過pip安裝，以及8/16/32個vCPU的測試

一個65 Skylake vCPU實例，其中TensorFlow使用CPU指令編譯（cmp），以及8/16/32個vCPU的測試

結論

對於每個模型架構和軟/硬體配置，下面的結論都使用GPU實例訓練時間作為基準進行對比換算，因為在所有的情況下，GPU應該是訓練速度最快的方案。

讓我們從MNIST手寫數字數據集+通用的多層感知器（MLP）架構開始，使用密集的全連接層。訓練時間越少越好。水平虛線是GPU的成績，虛線以上代表比GPU表現更差。

在這個環節的測試中，GPU是所有平台配置中最快的。除此之外我發現，32個vCPU和64個vCPU之間的性能非常相似，編譯的TensorFlow庫確實能大幅提高訓練速度，但只變現在8和16個vCPU的情況下。也許vCPU之間協調溝通的開銷，抵消了更多vCPU的性能優勢；也許是這些開銷與編譯TensorFlow的CPU指令不同。

由於不同vCPU數量的訓練速度之間差異很小，因此可以肯定縮減數量能帶來成本優勢。因為GCE實例的成本是按照比例分攤的（這與亞馬遜EC2不同），所以可以更簡單的計算成本。

如上圖所示，降低CPU數量對這個問題來說成本效益更高。

接著，我們使用相同的數據集，用卷積神經網路（CNN）進行數字分類：

在CNN中，GPU的速度是CPU的兩倍以上，而且從成本效率上看，64個vCPU甚至高於GPU，而且64個vCPU的訓練時間比32個vCPU還長。

繼續，我們在CNN方向上更深一步，基於CIFAR-10圖像分類數據集，使用一個使用深度covnet+多層感知器構建圖像分類器模型（類似於VGG-16架構）。

與簡單CNN測試的情況類似，不過在這種情況下，所有使用已編譯TensorFlow庫的CPU都表現更好。

接下來是fasttext演算法，用來在IMDb的評論資料庫中分辨評論是正面還是負面，在文本分類領域比其他方法都快。

在這個環節中，GPU比CPU快得多。數量較少的CPU配置，沒帶來太大的優勢，要知道正式的fasttext實現視為大量使用CPU設計的，並且能夠很好的進行並行處理。

雙向長短期記憶（LSTM）架構對於處理諸如IMDb評論之類的文本數據非常有用，但是在我之前的測試文章里，有Hacker News的評論指出，TensorFlow在GPU上使用了LSTM的低效實現，所以也許差異將會更加顯著。

等等，什麼？雙向LSTM的GPU訓練比任何CPU配置都慢兩倍以上？哇哦（公平地說，基準測試使用Keras LSTM默認的implementation=0，這對CPU更好；而在GPU上使用implementation=2更好，但不應該導致這麼大的差異）

最後，LSTM文本生成尼採的著作與其他測試類似，但沒有對GPU造成嚴重打擊。

結論

事實證明，使用64個vCPU不利於深度學習，因為當前的軟/硬體架構無法充分利用這麼多處理器，通常效果與32個vCPU性能相同（甚至更差）。

綜合訓練速度和成本兩方面考慮，用16個vCPU+編譯的TensorFlow訓練模型似乎是贏家。編譯過的TensorFlow庫能帶來30%-40%的性能提升。考慮到這種差異，谷歌不提供具有這些CPU加速功能的預編譯版本TensorFlow還是令人吃驚的。

這裡所說成本優勢，只有在使用谷歌雲Preemptible實例的情況下才有意義，Google Compute Engine上的高CPU實例要貴5倍，完全可以消弭成本優勢。規模經濟萬歲！

使用雲CPU訓練的一個主要前提是，你沒那麼迫切的需要一個訓練好的模型。在專業案例中，時間可能是最昂貴的成本；而對於個人用戶而言，讓模型兀自訓練一整晚也沒什麼，而且是一個從成本效益方面非常非常好的選擇。

這次測試的所有腳本，都可以在GitHub里找到，地址：

https://github.com/minimaxir/deep-learning-cpu-gpu-benchmark

另外還可以查看用於處理日誌的R/ggplot2代碼，以及在R Notebook中的可視化展現，其中有關於這次測試的更詳細數據信息。地址：

http://minimaxir.com/notebooks/deep-learning-cpu-gpu/

【完】

一則通知

量子位讀者5群開放申請，對人工智慧感興趣的朋友，可以添加量子位小助手的微信qbitbot2，申請入群，一起研討人工智慧。

另外，量子位大咖雲集的自動駕駛技術群，僅接納研究自動駕駛相關領域的在校學生或一線工程師。申請方式：添加qbitbot2為好友，備註「自動駕駛」申請加入~

招聘

量子位正在招募編輯/記者等崗位，工作地點在北京中關村。相關細節，請在公眾號對話界面，回復：「招聘」。

掃碼強行關注『量子位』

追蹤人工智慧領域最勁內容

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