雲端競速:MLPref最新AI訓練跑分結果出爐

作者 : Sally Ward-Foxton,EE Times歐洲特派記者

微軟Azure利用大規模的Nvidia驅動實例,在最新一回合的MLPref人工智慧訓練性能測試基準跑分展現了世界速度最快的AI雲端系統...

最新一回合的MLPref人工智慧(AI)訓練性能測試基準跑分結果出爐,微軟(Microsoft) Azure利用大規模的Nvidia驅動實例,展現了世界速度最快的AI雲端系統。Azure的NDm A110 v4系列虛擬機器以2,048顆Nvidia A100-80GB繪圖處理器(GPU)進行跑分,每一項測試都是在18分鐘之內完成。

在8項不同工作負載的封閉賽程(closed division)性能測試中,Nvidia以內含高達4,320顆A100加速器的系統,拔得其中7項測試的頭籌。微軟Azure則於第八項測試(醫療影像)取得領先地位。AI晶片新秀Graphcore與Habana Labs也在ResNet-50和BERT兩項性能測試上取得了進步的成果。

微軟Azure

微軟Azure的MLPref跑分結果在全球前100大超級電腦中排名第十。Nvidia內部的AI超級電腦Selene,規模是前者的兩倍,目前排名世界第六。

Azure的NDm A110 v4系列虛擬機器,依需求可從1台擴充到256台,或者說從8顆GPU擴充至2,048顆。在Azure雲端就利用了2,048顆GPU,展現了在僅超過25秒多一點點的時間內,就能完成整個BERT自然語言處理模型訓練的能力。而最困難的MiniGo性能測試基準,Azure以1,792顆GPU、在低於17.5分鐘的時間內完成訓練。

此外Azure在3D醫療影像的3D Unet性能測試基準項目上取得第一,利用768顆GPU,以1.262分鐘完成訓練(Nvidia採用768顆GPU的系統在3D Unet項目跑分結果是1.373分鐘)。而微軟的目標之一,就是展示Azure雲端性能可以與現場部署設備媲美。

Nvidia

Nividia參與測試的系統則是為了展現執行大規模AI訓練的能力。「擴充至更大的叢集實際上是AI訓練時最困難的部分,而Nvidia的AI平台在這方面擁有龐大的優勢;」Nvidia加速運算產品管理資深總監Paresh Kharya表示:「擴充性真的很重要,因為所有事情都會成為瓶頸,這是很困難的問題,從分配、協調工作到資料的移動,每件事都會成為瓶頸。」

Kharya表示,就算是Selene系統,進行龐大、最先進模型的訓練可能也會需要花費幾個月的時間,而不具備擴充性,就無法讓最新AI模型有所進展。規模也很重要;他指出,AI專案的快速進化能力是關鍵,「我們常見的一個錯誤認知是,只利用訓練模型的基礎建設成本來考量(投資報酬率);但使用者不只該關心基礎建設成本,也要注意他們昂貴的資料科學團隊生產力,以及最終的產品上市/更新時間是否能比競爭對手更快。」

Selene以4,320顆GPU進行性能測試基準跑分,是這一回合測試中規模最大的系統。Nvidia表示,與Graphcore最快的系統(採用256個加速器)相較,其跑分結果在速度上快了30倍,而比起Habana Labs的最大系統(同樣採用256個加速器),Nvidia系統則是快了53倍。

所有項目的AI訓練性能基準測試跑分結果,時間越短表現越好。這裡的跑分結果比較了配備不同數量加速器的系統,其中Google TPU v4的跑分結果來自於前一回合MLPref的測試。

(資料來源:Nvidia)

在個別加速器晶片的效能上,Nvidia則宣稱它勝過了Graphcore和Habana Labs的加速器;不過仍落後Google TPU v4在前一回合性能測試中的ResNet-50訓練模型跑分。而Nvidia強調,自2020年7月(A100問世時)以來,其MLPref訓練跑分的表現穩定進步,以Nvidia A100為基礎的系統性能表現整體快了五倍,在晶片層級則快了兩倍。

其性能的提升得益於軟體上的變化,包括透過同步而非連續地啟動整個核心序列的CUDA繪圖技術減少CPU的瓶頸,因此整個訓練演進都直接在GPU上執行。CUDA串流透過導入一個微調過的運算與通訊的重疊,來改善其平行性。

此外Nvidia的NCCL和 SHARP技術被用來改善多GPU和多節點的處理作業。NCCL利用現有的頻寬和網路延遲來最佳化資料聚合;SHARP則透過將CPU的運作分攤至交換器,來免除不同端點和伺服器間多次傳送資料的需要。同時,更新版的MX網路配置,改善了串接(concatenation)和區分(split)等運作的所需的記憶體複製效率。

以Nvidia的A100作為基準之性能正規化(normalized)至每個加速器晶片的結果;數字越高表現越好。其中Google TPU v4的跑分結果也是來自前一回合的MLPref測試。

(資料來源:Nvidia)

 

Graphcore

Graphcore則展示了較大系統的可擴充性,包含那些具備128和256顆IPU加速器的系統。在16和64顆加速器的系統方面,Graphcore的IPU-POd16在ResNet-50模型的跑分進步了24% ,IPU-Pod64則進步了41%。BERT模型部分,IPU-Pod16的跑分進步了5%,IPU-Pod64跑分進步了12%;這再次說明,軟體最佳化助力了性能提升。

Graphcore將IPU-Pod16的性能基準測試跑分結果與Nvidia的DGX-A100進行比較,就算前者的加速器晶片數量是兩倍。Graphcore主張兩套系統尺寸差不多(IPU-Pod16是5U,DGX-A100則是6U),在功耗和價格上也相當。不過應注意的是,Graphcore唯一做這種比較的公司。

在以ResNet-50模型進行的性能測試上,Graphecore宣稱其IPU-Pod16表現優於Nvidia的DGX-A100 (Graphcore系統花了28.3分鐘進行訓練;Nvidia系統完成訓練的時間則是29.1分鐘)。

不同於ResNet-50模型,Graphcore的BERT模型測試跑分,反映了每個加速器配備較少主CPU的系統表現。BERT的跑分是以每32個IPU有一個主CPU的系統為基準,ResNet-50模型的跑分則是以每8個IPU有一個主CPU的系統為基準。

「我們擁有依據每個工作負載變化該屬性的彈性,這不常見;」 Grapgcore首席軟體架構師Dave Lacey指出,「這讓我們能夠實驗…並取得這些效率點。」他強調這種方法允許使用者在單一主伺服器上執行更多運算,不需要轉移至需要額外基礎建設的分散式CPU運算。」

「這也是一個重要的成本因素,」Lacy表示:「所有這些系統都搭載了繁重的CPU,這對系統而言是一個顯著的成本。如果你能以最佳比例、最小數量的CPU來擺脫負擔,讓繁重的任務實際上由加速器來執行,就能針對特定工作負載進行成本最佳化。」

進行BERT模型訓練時,每個Graphcore加速器所需的主CPU數量較少。

(資料來源:Graphcore

 

Lacey表示,Graphcore的IPU設計是經過深思熟慮,把應用邏輯放在加速器上;主處理器和加速器之間的連結只用於訓練資料──他強調,沒有程式碼、沒有繁重的同步,只有資料。

另一個議題是,減少CPU的數量是根據工作負載以及工作負載使用的資料來決定。Lacey指出:「它是依據需要多少準備,或是有多少其他非AI類型的任務需要在CPU上完成;還有在CPU和加速器之間有多少資料傳輸。」

其效果對於執行BERT模型的工作負載而言特別顯著,其中輸入的資料會比其他類別的工作負載所需的影像來得小。像是ResNet-50模型的影像處理工作負載需要額外的非AI任務,例如影像解壓縮就比較適合在CPU執行,因此需要更多的主機。在主機與加速器間的乙太網路連結,也提供了相應地重新配置主CPU數量的彈性。

Graphcore比較了主CPU和加速器數量的比例,是以單一顆Graphcore晶片對Nvidia晶片或Habana晶片為基礎。如果單一Graphcore IPU-Pod16等同於單一的Nvidia DGX-A100,當Graphcore尋求ResNet-50訓練時間比較,就需要同樣數目的主CPU (但在這個例子中任何優勢只針對BERT)。

Habana Labs

英特爾(Intel)旗下的Intel的Habana Labs在第二回合的MLPerf訓練性能基準測試,是採用其Gaudi訓練加速器晶片。與上一回合相較,Gaudi的BERT模型跑分成果加倍,ResNet-50跑分也提升了11%。Habana也展現出它的Gaudi技術的可擴展性,在樸素縮放(naïve scaling)與弱縮放(weak scaling)上呈現類似的結果(weak scaling並未包括在MLPref的跑分結果中)。

Habana資深研究員Itay Hubara表示,樸素縮放考量在不同規模系統中所需的訓練時間,弱縮放則是來自樸素縮放的結果。通常伴隨著樣本總數(batch size,即同時饋入系統的訓練資料樣本數目)增加,加速器的數量也會增加,才能保持硬體充分發揮性能。

但是增加樣本總數往往需要更多的反覆訓練,因為在處理更多資料樣本之後,權重會被更新;這意味著需要更多的訓練資料,以便在較大的系統當中達到相同的結果。weak scaling是每一次資料處理或相同資料量被處理的樸素縮放分數正規化結果。

在每一回合的MLPref性能基準測試中,Habana的樸素縮放(左)結果與弱縮放(右)結果類似。

(資料來源:Habana Labs)

 

「我們高達64顆Gaudi晶片的系統弱縮放和樸素縮放表現很接近,因為我們不需要增加樣本數目,我們能夠以一個小的本地樣本數目執行;」Hubara表示:「當加速器從8個轉換到16個的時候,我不需要將整體樣本數目增加到兩倍…Guadi的架構讓我們能夠實現高利用率,甚至我們不需要將饋入裝置的樣本數目最大化。」

Habana的跑分結果也比上一個回合進步,這又是得益於軟體最佳化的結果。由於資料封包的技術,BERT訓練時間少了一半;在訓練資料中較短的句子,被以多序列(multi-sequence)方式打包(較短的句子會以0來填充,以達成一個固定的輸入尺寸)。資料封包是在預處理過程中進行處理,不算在性能基準訓練時間內。

此外Habana也實現了輕度的檢查點(checkpoint)節約;減少檢查點可顯著節省時間,不僅是節省一個檢查點,每個工作節省一組模型權重子集,能使速度大幅提升。

而被問到Habana加速器是否能以較少主 CPU來運作,該公司的回答是:「主CPU對Gaudi卡的比例是可以改變的,對我們的Gaudi卡來說不是限制。一套典型的系統有兩個Xeon 插槽供8個加速器所用。我們利用這個配置是因為我們的目標是取代以GPU為基礎之系統,而且我們的客戶偏好雙插槽系統。」

Google

Google在這一回合的MLPref訓練性能測試中,並未參與封閉賽程的跑分,不過在開放賽程公佈了兩套非常大型之模型的跑分結果;這兩套模型在架構上與MLPref的BERT模型相似,但有更大的維度和更多層數。

其中之一是利用TensorFlow框架,在一套配備2,048個加速器的TPUv4系統上,進行4,800億參數、以Transformer架構為基礎、僅編碼器的性能測試基準訓練,花費時間約55個小時。另一個跑分結果是以配備1,024顆晶片的TPUv4系統,進行2,000億參數的JAX模型訓練,花費時間約40個小時。Google表示,每一場訓練的系統執行可達到63%的計算效率。

完整的MLPref AI訓練性能測試基準跑分結果請參考此連結

 

本文同步刊登於《電子工程專輯》雜誌2022年1月號

責編:Judith Cheng

(參考原文:MLPerf Training Scores: Microsoft Demonstrates Fastest Cloud AI,By Sally Ward-Foxton)

 

 

 

 

加入我們官方帳號LINE@,最新消息一手掌握!

發表評論