zerone_nasa
4月底的時候，RiseML發表了一篇文章對TPUv2 和 Nvidia V100進行了對比，這是迄今為止TPUv2和V100芯片之間最為徹底的比較。原文譯文如下：
Google最近在其雲產品中新增了一種定製開發的微型芯片——TPUv2，用於加快深度學習。TPUv2是該芯片的第二代產品，也是第一款公開上市的深度學習加速器，有望成為Nvidia GPU的替代品。我們最近報告了對該產品的第一次體驗，並收到了許多請求，希望能與Nvidia V100 GPU進行更詳細的比較。
對深度學習加速器展開一個均衡且有意義的對比並非易事。考慮到未來這類產品的重要性以及當前缺乏詳細對比，我們認為有必要自己進行一個比較。這還包括傾聽可能與我們意見相左一方的意見，所以我們一早就分別聯繫了谷歌和Nvidia的工程師，讓他們就本文的草稿發表意見。為了保證不會偏袒任何一方，我們還邀請了獨立專家來審查這篇文章。據我們所知，這是迄今為止TPUv2和V100芯片之間最為徹底的比較。
實驗方案
接下來，我們將四個TPUv2芯片（即一個雲TPU）和四個Nvidia V100 GPU進行比較。兩者的內存都為64GB，因此可以訓練相同的型號，使用相同的批量。在實驗中，我們還以同樣的方式訓練模型:雲TPU上的四個TPUv2芯片進行一種同步數據並行分佈式的訓練，如同四個V100所做的一樣。
至於模型，我們決定在ImageNet上使用ResNet-50——一種用於圖像分類的事實標準和參考點。ResNet-50的參考實現是對外開放的，但目前沒有一個實現可以同時支持雲TPU和多個GPU上的訓練。
對於V100，Nvidia建議我們使用MXNet或TensorFlow實現，這兩種實現都能在Nvidia GPU雲上的Docker映像中找到。然而，我們發現這兩種實現在具有多個GPU和由此產生的大批量的情況下無法很好地快速融合。因此需要做出調整，尤其是在學習率計劃方面。
相反，我們使用了來自TensorFlow基準存儲庫的ResNet-50實現，並在Docker映像中運行它( TensorFlow / TensorFlow : 1 . 7 . 0 - GPU、CUDA 9.0、CuDNN 7 . 1 . 2 )。它比Nvidia推薦的TensorFlow實現要快得多，而且只比MXNet實現略慢一點(約3 %，見下文)。並且，它融合得很好。這樣做還有一個另外的好處，那就是可以在相同的版本( TensorFlow 1 . 7 . 0 )中比較同一框架中的兩個實現。
對於雲TPU，Google建議我們使用來自TensorFlow 1.7.0官方TPU存儲庫的bfloa 16實現。TPU和GPU實現都在各自的體系結構上使用混合精度計算，並以半精度存儲大部分張量。
在V100實驗中，我們用4個V100 GPU（每個GPU內存為16GB）在AWS上進行了一個p3.8 xlarge實例( Xeon E5–2670 @ 2.30 GHz 16核，244 GB內存，Ubuntu 16.04 )。在TPU實驗中，我們使用小型n1 - standard - 4實例作為主機( Xeon @ 2.3 GHz雙核、15gb內存、Debian 9 )，為其配置了一個由4個TPUv2芯片組成的雲TPU (每個芯片內存為16GB)。
我們做了兩個不同的比較。首先，分別從合成數據的吞吐量以及不增強數據情況下的吞吐量(每秒映像數)來看原始性能。這種比較獨立於收斂性，並確保I / O中的瓶頸或數據增強不會影響結果。在第二個比較中，我們將介紹ImageNet上兩種實現的精度和收斂性。
吞吐量結果
我們利用合成數據上的每秒圖像來計算吞吐量，即使用動態創建的訓練數據，計算不同批量的吞吐量。請注意，TPU的唯一推薦批量型號是1024型，但根據大量讀者的要求，我們還彙報了其他批量的性能。
上圖為合成數據和w / o數據增強的不同批量下每秒圖像的性能。批量型號是“通用的”，例如1024表示在每個步驟中每個GPU / TPU芯片上的256批量。
批量大小為1024時，吞吐量幾乎沒有差別！TPU以大約2 %的差距領先。較小的批量導致兩個平臺上吞吐量的下降，GPU在這方面表現略好一些。但是如上所述，這些批量目前並不是TPU的推薦設置。
根據Nvidia的建議，我們還在MXNet上進行了一個使用GPU的實驗。我們使用了Nvidia GPU雲上Docker映像( mxnet : 18.03 - py3 )中提供的ResNet-50實現。當批量大小為768 ( 1024太大)時，GPU的處理速度約為每秒3280張圖像。這比上述最佳TPU結果約快了3 %。然而，如上所述，MXNet實現在此批量的多個GPU上並不能很好地融合，這也是我們在此以及接下來都非常關注TensorFlow的原因。
基於雲價格的成本
目前，雲TPU (四個TPUv2芯片)僅能從Google雲中獲取。只有在需要計算時，它才可以按需附加到任何VM實例。我們考慮為V100提供的雲產品來自AWS ( Google雲尚不能提供V100)。基於以上結果，我們可以將相應平臺和提供商每美元每秒的圖像數標準化。
每美元每秒的圖像性能
以這種定價來看，雲TPU無疑是一個贏家。但是，如果考慮長期租賃或購買硬件(儘管目前這不是雲TPU的選項)，情況可能會有所不同。上圖中，我們還包括了在AWS上租用12個月p3.8 xlarge預留實例的價格(無需提前付款)。這大大降低了價格，導致每美元（生成）375張圖像/秒。
對於GPU，除了購買之外，還有可以考慮其他有趣的選項。例如，Cirrascale提供月租服務，價格約為7.5千美元(約每小時10.3美元)，每臺服務器有4個V100 GPU。但是，由於硬件不同於AWS ( CPU類型、內存、NVLink支持等)，因此需要進一步的基準測試來進行直接比較。
精度和收斂性
除了報告原始性能之外，我們還希望驗證計算實際上是“有意義的”，即實現融合到良好的結果。由於我們比較了兩種不同的實現方式，所以可能會存在一些偏差。因此，我們的對比不僅包括衡量硬件速度，還包括衡量實現質量。例如，TPU實現應用了最佳計算密集型的圖像預處理步驟，實際上犧牲了原始吞吐量。根據Google預測，這是一種預期行為，而且正如我們將在下文看到的那樣，這樣做是有代價的。
我們在ImageNet數據集上訓練這些模型，任務是將圖像分為1000個類別，如蜂鳥、墨西哥捲餅或比薩餅。數據集由大約130萬個用於培訓的映像(約142 GB )和5萬個用於驗證的映像(約7GB )組成。
我們對90個epoch進行了1024批量的培訓，並對驗證數據的結果進行了比較。TPU實現處理的圖像大約始終為每秒2796個，GPU實現約為每秒 2839個。這與上面的吞吐量結果不同，此前計算吞吐量時我們禁用了數據增強，並使用合成數據來比較TPU和GPU的原始速度。
90個epoch之後兩種實現方式的最高精度(即，僅考慮對每個圖像具有最高置信度的預測)。
如上所示，TPU實現90個epoch後的最高精度提升了0.7 %。雖然這種提升看起來可能很小，但在這個已經非常高的水平上進行改進是極困難的，而且取決於不同的應用，這種小進步最終可能產生很大的不同。讓我們來看看模型學習過程中不同時期的最高精度。
兩種實現驗證集的最高精度上圖中的急劇變化與學習率的變化一致。TPU實現的收斂性能較好，在86個epoch後最終精度達到76.4 %。GPU實現落後一點，84個epoch之後最終精度達到75.7 %，而TPU實現只需64個epoch即可達到這一精度。TPU的收斂性得到改善可能是預處理和數據增強變得更好的結果，但還需要進一步的實驗來證實這一點。
基於雲定價的解決方案成本
最終來說，真正重要的是達到一定精度所需的時間和成本。如果我們假定的可接受解決方案為75.7 %( GPU實現的最佳精度)，我們可以基於所需的epoch和每秒圖像的訓練速度來計算實現該精度的成本。這不包括評估epoch和訓練啟動時間之間模型的時間。Cost to reach 75.7% top-1 accuracy. *reserved for 12 months達到最高精度75.7 %的所需成本（保留12個月）
如上所示，雲TPU當前的定價可以讓它以55美元的價格在ImageNet上將一個模型從零訓練到75.7 %，而所需時間9小時不到！將收斂性培訓到76.4 %的費用為73美元。儘管V100的運行速度類似，但其較高的價格和實現結果較慢的收斂速度會導致相當高的解決方案成本。請再次注意，這種比較取決於實現的質量以及雲定價。另一個有趣的對比將基於功耗。然而，我們目前還沒有任何關於TPUv2功耗的公開信息。
小結
就ResNet -50的原始性能而言，四個TPUv2芯片(一個雲TPU )和四個V100 GPU在我們的基準測試中速度相當(彼此相差不到2 % )。我們可能會看到軟件(例如TensorFlow或CUDA )的進一步優化，這些優化可以提高性能並改變這種情況。
然而，在實踐中最重要的往往是在某個問題實例上達到某個精度所需的時間和成本。雲TPU目前的定價，加上ResNet -50的世界級實現，在ImageNet上實現了令人印象深刻的時間和精度成本——使我們能夠以大約73美元的價格將模型的精度訓練到76.4 %。
未來，我們需要對來自其他域和具有不同網絡體系結構的模型進行基準測試，以提供進一步的見解。另一個還需要考慮的有趣問題是，如何有效地利用特定的硬件平臺。例如，混合精度計算帶來了很大的性能提升，但其在GPU和TPU上的實現和行為不同。
感謝漢娜·巴斯特( Hannah Bast，弗賴堡大學)、大衛·安德森(David Andersen，卡內基梅隆大學)、蒂姆·德特默（Tim Dettmers）和馬蒂亞斯·邁耶（Mathias Meyer）對本文草稿的閱讀。
