系統設計的藝術：當HPC與AI應用成為主流，GPU架構該往何處去？

^{我們多年前就曾經提到，配合充足的資料並使用卷積神經網路進行AI工作負載訓練正逐漸成為主流，而全球各主要HPC（高效能運算）中心多年來一直把這方面負載交給英偉達的GPU處理。對於模擬和建模等任務，GPU的效能表現可謂相當突出。從本質上講，HPC模擬/建模與AI訓練其實是一種諧波收斂，而GPU作為大規模平行處理器特別擅長執行這類工作。}

但自2012年起，AI革命正式爆發，影像辨識軟體第一次將準確度提升至超越人類的水平。所以我們非常好奇，HPC和AI這種在同類GPU上高效處理的共通性還能持續多久。於是在2019年夏季，透過模型的細化迭代，我們嘗試用混合精度數學單元在Linpack基準測試中得出與FP64計算相同的結果。而在英偉達於隔年推出「Ampere」GA100 GPU之前，我們再次進行一番HPC與AI的處理效能嘗試。當時英偉達還沒有推出「Ampere」A100 GPU，所以顯示卡巨頭尚未正式朝著在混合精度張量核心上訓練AI模型的方向傾斜。現在的答案當然已經明好了，FP64向量單元上的HPC工作負載需要做點架構調整才能發揮GPU效能，毫無疑問有點「二等公民」的意思了。但在當時，一切仍有可能。

隨著英偉達在今年稍早推出「Hopper」GH100 GPU，AI與HPC的世代效能改進幅度出現了更大的差距。不僅如此，在最近的秋季GTC 2022大會上，英偉達公司聯合創始人兼CET黃仁勳表示，AI工作負載自身也出現了分歧，也迫使英偉達開始探索CPU業務——或者更準確地說，應該叫面向GPU的優化擴展內存控制器。

稍後我們會具體討論這個問題。

花開兩朵，各表一枝

讓我們先從最明確的判斷說起。如果英偉達想讓自己的GPU擁有更強的FP64性能，用以支持天氣建模、流體動力學計算、有限元素分析、量子色動力學及其他高強度數學模擬等64位浮點HPC應用，那加速器的設計思路應該是這樣的：製造一款不設任何張量核心、也不設FP32 CUDA核心（在CUDA架構中主要作為圖形著色器）的產品。

但這樣的產品恐怕只有幾百家客戶願意採購，所以單晶片價格可能在數萬甚至數十萬美元，只有這樣才能覆蓋掉設計和製造成本。為了建立起規模更大、而且更具利潤空間的業務，英偉達必須設計出更通用的架構，其向量數學運算能力只要比CPU強就夠了。

所以自從英偉達15年前決定認真為HPC應用設計產品開始，他們就一直專注於使用FP32浮點數學運算的HPC場景——包括地震處理、信號處理和基因組學類負載中使用的單精度資料與處理任務，並逐步提升GPU的FP64功能。

2012年7月推出的K10加速器搭載兩個「Kepler」GK104 GPU，與遊戲顯示卡中使用的GPU完全相同。其中設有1536個FP32 CUDA核心，沒採用任何專用FP64核心。它的FP64支援純由軟體完成，因此無法實現可觀的效能提升：雙GK104 GPU在處理FP32任務時效能為4.58 teraflops，而在處理FP64時為190 gigaflops，比率為24比1。而在2012年底的SC12超級運算大會上發表的K20X則採用GK110 GPU，FP32效能為3.95 teraflops，FP64效能為1.31 teraflops，比率提升至3比1。到這個時候，該產品對於HPC應用程式以及在學術/超大規模計算領域訓練AI模型的用戶來說，已經初步具備了可用性。 K80 GPU加速卡採用兩台GK110B GPU，這是因為英偉達並沒有為當時最高階的「Maxwell」GPU添加FP64支援，因此GK110 B就成了當時廣受歡迎、最具性價比的選項。 K80的FP32性能為8.74 teraflops，FP64性能則為2.91 teraflops，比率仍保持為3比1。

到“Pascal”GP100 GPU，HPC與AI的差距隨FP16混合精度指標的引入而進一步拉開，不過矢量FP32與矢量FP64的比例進一步轉化為2比1，而且在“Volta” GV100之後的“Ampere”GA100和“Hopper”GH100等更新GPU中得到了保持。在Volta架構中，英偉達首次引入了具有固定矩陣磊小的張量核心（Tensor Core）矩陣數學單元，顯著提升了浮點（及整數）運算能力，並繼續在架構中保留向量單元。

這些張量核心被用來處理越來越大的矩陣，而具體運算精度卻越來越低，於是這類設備獲得了極為誇張的AI負載吞吐量。這當然離不開機器學習自身的模糊統計性質，同時也跟著多數HPC演算法要求的高精度數學拉開了巨大差距。下圖所示為AI和HPC表現差距的對數表示，相信大家已經能夠看到二者間的趨勢性差異：

對數形式看著不夠震撼，咱們用實際比例再看一次：

系統設計的藝術：當HPC與AI應用成為主流，GPU架構該往何處去？

並不是所有HPC應用程式都能針對張量核心進行調整，也不是一切應用程式都能把數學運算移交給張量核心，所以英偉達的GPU架構中仍然保留著一些向量單元。另外，很多HPC組織其實拿不出像HPL-AI那樣的迭代解算器。 Linpack基準測試中使用的就是HPL-AI求解器，它採用常規HPL Linpack並配合FP16加FP32運算，再輔以一點點FP64運算來收斂至與純FP64蠻力計算相同的答案。這款迭代解算器能夠在橡樹嶺國家實驗室的「Frontier」超級電腦上提供6.2倍的有效加速，並在RIKEN實驗室的「富嶽」超級電腦上實現4.5倍的有效加速。如果能有更多HPC應用程式迎來屬於自己的HPL-AI類求解器，那AI跟HPC「分家」的難題也就有解了，相信這一天終會到來。

但同時，對於許多工作負載，FP64效能仍然是唯一的決定性因素。而憑藉強大AI算力賺得盆滿缽滿的英偉達，短時間內肯定沒太多閒心照顧HPC這塊市場。

花再開兩朵，再各表一枝

可以看到，英偉達的GPU架構主要追求更高的AI性能，同時保持可接受的HPC性能，雙管齊下引導客戶每三年更新一次硬體。從純FP64效能的角度來看，在2012年至2022年這十年間，英偉達GPU的FP64吞吐量成長了22.9倍，從K20X的1.3 teraflops到H100的30 teraflops。如果能配合迭代求解器用上張量核心矩陣單元，那麼增幅則可達45.8倍。但如果是只需要低精度大規模平行計算的AI訓練用戶，那從FP32到FP8的性能轉變就誇張了，已經由最早的3.95 teraflops FP32算力提升至FP8稀疏矩陣的4 petaflops，也就是提高了1012.7倍。而如果是在當時的K20X GPU上用FP64編碼的AI演算法來比較（當時的主流作法），那這十年間的效能提升只有可憐的2倍。

很明顯，二者的表現差異已經不能用巨大來形容了。黃仁勳自己也提到，目前的AI陣營本身又一分為二。一類是基於transformer模型支援的巨型基礎模型，也被稱為大語言模型。這類模型的參數數量迅速增長，對硬體的需求也不斷提升。與先前的神經網路模型相比，如今的transformer模型完全代表著另一個時代，如下圖所示：

請原諒這張圖有點模糊，但重點在於：對於第一組不包含transformers的AI模型，計算需求在兩年之內成長了8倍；但對於包含transformers的AI模型，其運算需求在兩年內成長了275倍。如果用浮點運算來處理，那系統中得有10萬個GPU才能滿足需求（這還不是太大的問題）。但轉向FP4精度會把計算量翻倍，未來GPU採用1.8奈米電晶體時算力又能增加2.5倍左右，所以還是剩下了55倍左右的差距。要是能實現FP2運算的話（假設這樣的精度足夠解決問題）倒是可以把計算量減半，但那也至少得使用25萬個GPU。而且，大語言transformer模型往往很難擴展，特別是不具備經濟意義上的可行性。所以這類模型就成了巨頭級企業的專屬，就如同核武只會被掌握在強國手中一樣。

至於作為「數位經濟引擎」的推薦系統，它需要的不只是成倍增加的運算量，還需要遠超大語言模型、甚至是GPU所能提供記憶體容量的資料規模。黃仁勳在先前GTC主題的演講中就曾提到：

「與大語言模型相比，各個運算單元在處理推薦系統時面對的資料量要大出一個量級。很明顯，推薦系統不僅要求記憶體速度更快，而且需要10倍於大語言模型的記憶體容量。雖然大語言模型隨時間推移而保持著指數增長、對算力的需求一刻不停，但推薦系統也同樣保持著這樣的增長速度，而且不斷吞噬更多內存容量。大語言模型和推薦系統可以說是當下最重要的兩類AI模型，而且有著不同的計算要求。推薦系統可以擴展至數十億用戶與數十億個條目，每篇文章、每段視頻、每個社交帖都有對應的數字表示，被稱為嵌入。每個嵌入表可能包含數十TB的數據，需要由多個GPU協同處理。在處理推薦系統時，既要求網路中的某些部分實現數據並行處理，又要求網路中的其他部分實現模型並行處理，這就對計算機中的各個部分提出了更高要求。」

下圖所示，為推薦系統的基本架構：

為了解決定特殊的記憶體容量與頻寬問題，英偉達開發了「Grace」Arm伺服器CPU，並將其與Hopper GPU緊密耦合。我們也開玩笑說，如果需要的主記憶體量十分巨大，那Grace其實只是Hopper的記憶體控制器。但從長遠來看，也許把一堆運行有NVLink協定的CXL連接埠掛入Hooper的下一代GPU就行。

所以英偉達拿出的Grace-Hopper超級晶片，就相當於把一個「兒童」級CPU叢集放進了巨大的「成人」級GPU加速叢集。這些Arm CPU倒是可以支援傳統的C 與Fortran工作負載，但代價是：混合叢集當中CPU部分的效能，只相當於叢集中GPU效能的十分之一，而成本卻是常規純CPU叢集的3到5倍。

順帶一提，我們對於英偉達所做的任何工程選擇都尊重且理解。 Grace是一款出色的CPU，Hopper也是一款出色的GPU，二者結合肯定會有不錯的效果。但現在的情況是，我們在同一平台上面對著三種截然不同的工作負載，它們各自把架構拉向不同的方向。高效能運算、大語言模型和推薦系統，這三位老哥各有特點，根本沒辦法以符合經濟效益的方式同時進行架構最佳化。

而且很明顯，AI這邊的優勢很大、HPC則逐漸勢微，這種狀況已經持續了近十年。如果HPC想要完成自我改造，那麼其程式碼就得朝著推薦系統和大語言模型靠攏，而不能繼續堅持在FP64上運行現有C 和Fortran程式碼。而且很明顯，跟AI客戶相比，HPC客戶的每一次運算都有溢價。所以除非HPC專家摸清了迭代求解器的普適性開發方式，能夠以較低的精確度對物理世界進行建模，否則這種被動局面將很難扭轉。

幾十年來，我們一直覺得大自然本身其實是不符合數學規律的。我們是在被迫用高精度數學來描述大自然的效應，或者說在用不適合的語言描述客觀現實。當然，大自然也許比我們想像中的更精妙，而迭代解算者反而更接近我們所要建模的現實。如果真是如此，那也許是人類的一種幸運，甚至要比十年前HPC和AI的偶然重疊更幸運。

畢竟世上本沒有路，走的人多了，也便成了路。

以上是系統設計的藝術：當HPC與AI應用成為主流，GPU架構該往何處去？的詳細內容。更多資訊請關注PHP中文網其他相關文章！