目錄
花開兩朵,各表一枝
花再開兩朵,再各表一枝
首頁 科技週邊 人工智慧 系統設計的藝術:當HPC與AI應用成為主流,GPU架構該往何處去?

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

Apr 08, 2023 pm 01:51 PM
gpu ai hpc


系統設計的藝術:當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與AI應用成為主流,GPU架構該往何處去?

系統設計的藝術:當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模型完全代表著另一個時代,如下圖所示:

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

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

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

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

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

下圖所示,為推薦系統的基本架構:

系統設計的藝術:當HPC與AI應用成為主流,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中文網其他相關文章!

本網站聲明
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn

熱AI工具

Undresser.AI Undress

Undresser.AI Undress

人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover

AI Clothes Remover

用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool

Undress AI Tool

免費脫衣圖片

Clothoff.io

Clothoff.io

AI脫衣器

Video Face Swap

Video Face Swap

使用我們完全免費的人工智慧換臉工具,輕鬆在任何影片中換臉!

熱門文章

<🎜>:泡泡膠模擬器無窮大 - 如何獲取和使用皇家鑰匙
3 週前 By 尊渡假赌尊渡假赌尊渡假赌
北端:融合系統,解釋
3 週前 By 尊渡假赌尊渡假赌尊渡假赌

熱工具

記事本++7.3.1

記事本++7.3.1

好用且免費的程式碼編輯器

SublimeText3漢化版

SublimeText3漢化版

中文版,非常好用

禪工作室 13.0.1

禪工作室 13.0.1

強大的PHP整合開發環境

Dreamweaver CS6

Dreamweaver CS6

視覺化網頁開發工具

SublimeText3 Mac版

SublimeText3 Mac版

神級程式碼編輯軟體(SublimeText3)

熱門話題

Java教學
1664
14
CakePHP 教程
1423
52
Laravel 教程
1318
25
PHP教程
1269
29
C# 教程
1248
24
如何理解C  中的DMA操作? 如何理解C 中的DMA操作? Apr 28, 2025 pm 10:09 PM

DMA在C 中是指DirectMemoryAccess,直接內存訪問技術,允許硬件設備直接與內存進行數據傳輸,不需要CPU干預。 1)DMA操作高度依賴於硬件設備和驅動程序,實現方式因係統而異。 2)直接訪問內存可能帶來安全風險,需確保代碼的正確性和安全性。 3)DMA可提高性能,但使用不當可能導致系統性能下降。通過實踐和學習,可以掌握DMA的使用技巧,在高速數據傳輸和實時信號處理等場景中發揮其最大效能。

C  中的chrono庫如何使用? C 中的chrono庫如何使用? Apr 28, 2025 pm 10:18 PM

使用C 中的chrono庫可以讓你更加精確地控制時間和時間間隔,讓我們來探討一下這個庫的魅力所在吧。 C 的chrono庫是標準庫的一部分,它提供了一種現代化的方式來處理時間和時間間隔。對於那些曾經飽受time.h和ctime折磨的程序員來說,chrono無疑是一個福音。它不僅提高了代碼的可讀性和可維護性,還提供了更高的精度和靈活性。讓我們從基礎開始,chrono庫主要包括以下幾個關鍵組件:std::chrono::system_clock:表示系統時鐘,用於獲取當前時間。 std::chron

怎樣在C  中測量線程性能? 怎樣在C 中測量線程性能? Apr 28, 2025 pm 10:21 PM

在C 中測量線程性能可以使用標準庫中的計時工具、性能分析工具和自定義計時器。 1.使用庫測量執行時間。 2.使用gprof進行性能分析,步驟包括編譯時添加-pg選項、運行程序生成gmon.out文件、生成性能報告。 3.使用Valgrind的Callgrind模塊進行更詳細的分析,步驟包括運行程序生成callgrind.out文件、使用kcachegrind查看結果。 4.自定義計時器可靈活測量特定代碼段的執行時間。這些方法幫助全面了解線程性能,並優化代碼。

量化交易所排行榜2025 數字貨幣量化交易APP前十名推薦 量化交易所排行榜2025 數字貨幣量化交易APP前十名推薦 Apr 30, 2025 pm 07:24 PM

交易所內置量化工具包括:1. Binance(幣安):提供Binance Futures量化模塊,低手續費,支持AI輔助交易。 2. OKX(歐易):支持多賬戶管理和智能訂單路由,提供機構級風控。獨立量化策略平台有:3. 3Commas:拖拽式策略生成器,適用於多平台對沖套利。 4. Quadency:專業級算法策略庫,支持自定義風險閾值。 5. Pionex:內置16 預設策略,低交易手續費。垂直領域工具包括:6. Cryptohopper:雲端量化平台,支持150 技術指標。 7. Bitsgap:

怎樣在C  中處理高DPI顯示? 怎樣在C 中處理高DPI顯示? Apr 28, 2025 pm 09:57 PM

在C 中處理高DPI顯示可以通過以下步驟實現:1)理解DPI和縮放,使用操作系統API獲取DPI信息並調整圖形輸出;2)處理跨平台兼容性,使用如SDL或Qt的跨平台圖形庫;3)進行性能優化,通過緩存、硬件加速和動態調整細節級別來提升性能;4)解決常見問題,如模糊文本和界面元素過小,通過正確應用DPI縮放來解決。

C  中的實時操作系統編程是什麼? C 中的實時操作系統編程是什麼? Apr 28, 2025 pm 10:15 PM

C 在實時操作系統(RTOS)編程中表現出色,提供了高效的執行效率和精確的時間管理。 1)C 通過直接操作硬件資源和高效的內存管理滿足RTOS的需求。 2)利用面向對象特性,C 可以設計靈活的任務調度系統。 3)C 支持高效的中斷處理,但需避免動態內存分配和異常處理以保證實時性。 4)模板編程和內聯函數有助於性能優化。 5)實際應用中,C 可用於實現高效的日誌系統。

給MySQL表添加和刪除字段的操作步驟 給MySQL表添加和刪除字段的操作步驟 Apr 29, 2025 pm 04:15 PM

在MySQL中,添加字段使用ALTERTABLEtable_nameADDCOLUMNnew_columnVARCHAR(255)AFTERexisting_column,刪除字段使用ALTERTABLEtable_nameDROPCOLUMNcolumn_to_drop。添加字段時,需指定位置以優化查詢性能和數據結構;刪除字段前需確認操作不可逆;使用在線DDL、備份數據、測試環境和低負載時間段修改表結構是性能優化和最佳實踐。

C  中的字符串流如何使用? C 中的字符串流如何使用? Apr 28, 2025 pm 09:12 PM

C 中使用字符串流的主要步驟和注意事項如下:1.創建輸出字符串流並轉換數據,如將整數轉換為字符串。 2.應用於復雜數據結構的序列化,如將vector轉換為字符串。 3.注意性能問題,避免在處理大量數據時頻繁使用字符串流,可考慮使用std::string的append方法。 4.注意內存管理,避免頻繁創建和銷毀字符串流對象,可以重用或使用std::stringstream。

See all articles