Nvidia CUDA vs AMD ROCm vs Intel oneAPI:AI與HPC軟體堆疊比較
隨著人工智慧(AI)持續滲透生活的各個領域,這些工具將運行在什麼樣的軟體平台上成為一個重要的問題。軟體堆疊——即一組協同工作的軟體組件,用於在計算系統上實現特定功能——在以GPU為中心的AI任務中變得愈發重要。隨著AI和高效能計算(HPC)應用推動計算能力的極限,選擇合適的軟體堆疊可以顯著影響效能、效率和開發者生產力。
▲ 選擇合適的軟體堆疊可以顯著影響效能、效率和開發者生產力。(圖/ENews新聞網AI生成)
目前,軟體堆疊競爭中有三大主要玩家:Nvidia的計算統一設備架構(CUDA)、Intel的oneAPI和AMD的Radeon開放運算(ROCm)。雖然各有優劣,Nvidia的CUDA因其硬體在HPC及AI領域的領先地位而持續占據主導地位。
我們將深入探討這些軟體堆疊的細節,了解其功能、硬體支援以及與流行的AI框架PyTorch的整合。此外,我們還將簡要介紹兩種高階HPC語言:Chapel和Julia。
Nvidia的CUDA
Nvidia的CUDA是一個專有的平行運算平台和軟體堆疊,旨在在其GPU上進行通用計算。CUDA提供了一個應用程式介面(API),使軟體能夠利用Nvidia GPU的平行處理能力進行加速計算。
▲ Nvidia的CUDA是一個專有的平行運算平台和軟體堆疊,旨在在其GPU上進行通用計算。(圖/ENews新聞網AI生成)
CUDA必須首先被提及,因為它在AI和GPU密集型HPC任務的軟體堆疊領域占據主導地位,且原因充分。自2006年問世以來,CUDA擁有悠久的第三方支持歷史和成熟的生態系統。許多函式庫、框架和其他工具已經專門針對CUDA和Nvidia GPU進行了最佳化。這種長期支持是CUDA相較其他堆疊的一個關鍵優勢。
Nvidia提供了一整套工具作為CUDA平台的一部分,包括Nvidia CUDA編譯器(NVCC)等編譯器。還有許多除錯器和分析器,用於除錯和最佳化CUDA應用,以及分發CUDA應用的開發工具。此外,CUDA的悠久歷史也促成了廣泛的文件、教程和社群資源。
CUDA對PyTorch框架的支援在討論AI任務時尤為重要。這是一個基於Torch函式庫的開源機器學習函式庫,主要用於計算機視覺和自然語言處理應用。PyTorch對CUDA的支援非常成熟,實現了Nvidia GPU上高效的訓練和推論。再次強調,CUDA的成熟度意味著PyTorch可以訪問眾多函式庫和工具。
除了大量的加速函式庫,Nvidia還為AI研究人員和軟體開發者提供了一整套深度學習軟體堆疊。其中包括著名的CUDA深度神經網路函式庫(cuDNN),這是一個GPU加速的深度神經網路原語函式庫。cuDNN加速了廣泛使用的深度學習框架,包括Caffe2、Chainer、Keras、MATLAB、MxNet、PaddlePaddle、PyTorch和TensorFlow。此外,CUDA設計與所有Nvidia GPU相容,從消費級GeForce顯示卡到高端資料中心GPU,為使用者提供了廣泛的硬體選擇範圍。
然而,CUDA並非完美,Nvidia的軟體堆疊也存在一些需要考慮的缺點。首先,雖然CUDA免費提供,但它是一項Nvidia擁有的專有技術,因此不是開源的。這種情況使開發者被鎖定在Nvidia的生態系統和硬體上,因為在CUDA上開發的應用無法在非Nvidia GPU上運行,除非進行大量程式碼修改或使用相容層。類似地,CUDA的專有性質意味著軟體堆疊的開發路線圖完全由Nvidia控制,開發者對修改或貢獻CUDA程式碼庫的能力有限。開發者還必須考慮CUDA的授權成本。雖然CUDA本身對非商業用途免費,但商業應用可能需要購買昂貴的Nvidia硬體和軟體授權。
AMD的ROCm
AMD的ROCm是另一個許多開發者選擇的軟體堆疊。儘管CUDA在該領域占據主導地位,但ROCm因為其開源特性而顯得獨特。這一特性允許開發者自訂並貢獻程式碼庫,促進了社群內的合作和創新。ROCm的一個關鍵優勢是它支援AMD和Nvidia GPU,這使得跨平台開發成為可能。
▲ ROCm允許開發者自訂並貢獻程式碼庫,促進了社群內的合作和創新。(圖/ENews新聞網AI生成)
這一獨特功能由異質運算介面(HIP)實現,使開發者能夠創建可在不同GPU平台上運行的可攜式應用。雖然ROCm支援消費級和專業級AMD GPU,但其主要重點是針對專業工作負載的高端Radeon Instinct和Radeon Pro GPU。
與CUDA類似,ROCm提供了一系列GPU程式設計工具,包括C/C++編譯器如ROCm編譯器集合、AOMP和AMD最佳化C/C++編譯器,以及Fortran編譯器如Flang。還有各種領域的函式庫,如線性代數、FFT和深度學習。
然而,與CUDA相比,ROCm的生態系統相對年輕,在第三方支援、函式庫和工具方面需要迎頭趕上。進入市場較晚也意味著文件和社群資源較少,尤其是在PyTorch方面。PyTorch支援ROCm平台,但在效能、最佳化和第三方支援方面落後於CUDA,這是由於其歷史和成熟度較短。針對ROCm的PyTorch文件和社群資源較CUDA少,但AMD在這方面正逐步改進。
與Nvidia類似,AMD也提供了大量ROCm函式庫。AMD提供了一個名為MIOpen的深度學習函式庫,相當於Nvidia的cuDNN,用於ROCm版的PyTorch(以及其他流行工具)。此外,儘管ROCm支援AMD和Nvidia GPU,但在Nvidia硬體上運行時,其效能可能不及CUDA,這是由於驅動程式開銷和最佳化挑戰所致。
Intel的oneAPI
Intel的oneAPI是一個統一的跨平台程式設計模型,支援廣泛的硬體架構和加速器。它支援包括CPU、GPU、FPGA和來自不同供應商的AI加速器在內的多種架構,旨在提供一個廠商中立的異質運算解決方案,並利用SYCL等行業標準。這一特性意味著它可以運行在AMD和Nvidia等外部供應商的架構上以及Intel的硬體上。
▲ Intel的oneAPI是一個統一的跨平台程式設計模型,支援廣泛的硬體架構和加速器。(圖/ENews新聞網AI生成)
與ROCm類似,oneAPI也是一個開源平台。因此,與CUDA相比,社群參與和對程式碼庫的貢獻更多。oneAPI支援多種程式設計語言和框架,包括C/C++(使用SYCL)、Fortran、Python和TensorFlow。此外,oneAPI提供了一個統一的異質運算程式設計模型,簡化了跨多種硬體的開發。然而,與ROCm類似,oneAPI在堆疊成熟度方面存在一些缺點。作為一個較新的平台,oneAPI在第三方軟體支援和特定硬體架構最佳化方面需要迎頭趕上。
在PyTorch的特定使用案例中,oneAPI仍處於早期階段,與成熟的CUDA整合相比。PyTorch可以利用oneAPI的數據並行Python(DPPy)函式庫在Intel CPU和GPU上進行分佈式訓練,但對oneAPI GPU的原生支援仍在開發中,尚未準備好進入生產階段。
儘管如此,需要注意的是,oneAPI的優勢在於其基於開放標準的方法和跨平台可攜性的潛力。如果供應商鎖定是一個問題,而運行PyTorch模型在不同硬體架構上的能力是優先考量,那麼oneAPI可能是一個可行的選擇。
目前,如果開發者的主要目標是在Nvidia GPU上獲得最佳效能,CUDA仍是首選,因為其生態系統已經成熟。然而,尋求廠商中立解決方案或主要使用AMD或Intel硬體的開發者,可能會選擇依賴ROCm或oneAPI。
雖然CUDA在生態系統開發方面領先,但其專有性和硬體特異性可能使ROCm和oneAPI對某些開發者更具優勢。隨著時間的推移,這些堆疊的社群支援和文件將繼續增長。CUDA目前主導市場,但未來幾年情況可能會改變。
抽象化堆疊
總體來說,許多開發者更喜歡創建硬體獨立的應用。在HPC中,硬體最佳化可以因效能原因而被證明是合理的,但許多現代開發者更喜歡關注他們的應用,而不是底層硬體的細微差別。
PyTorch是一個很好的例子。雖然Python不是以高效著稱的語言,但在Hugging Face上的模型中,有92%是PyTorch專用的。只要硬體供應商有基於其函式庫的PyTorch版本,使用者就可以專注於模型,而不是底層硬體差異。儘管這種可攜性很好,但它並不能保證效能,這也是底層硬體架構可能進入討論的地方。
當然,PyTorch是基於Python的,這是許多程式設計師的首選語言。這種語言通常在易用性上做出妥協,換取效能(特別是高效能特性,如平行程式設計)。當HPC項目用Python開始時,它們往往會遷移到基於分佈式C/C++和MPI或使用OpenMP的多線程應用,這些選擇經常導致“兩語言”問題,即開發者必須管理兩個版本的程式碼。
目前,兩種“較新”的語言Chapel和Julia提供了一個簡單易用的語言解決方案,提供高效能程式設計環境。這些語言等嘗試“抽象掉”許多細節,以便為平行HPC叢集、多核心處理器和GPU/加速器環境編寫應用程式。在它們的基礎上,它們仍然依賴上述的廠商GPU函式庫,但通常使開發者更容易構建能夠在運行時識別和適應底層硬體環境的應用程式。
▲ Chapel和Julia提供了一個簡單易用的語言解決方案,提供高效能程式設計環境。(圖/ENews新聞網AI生成)
Chapel
最初由Cray開發的Chapel(Cascade高生產力語言)是一種平行程式設計語言,設計比現有的程式設計語言(讀作“Fortran/C/C++加MPI”)表達能力更強。Hewlett Packard Enterprise(惠普企業)在收購Cray後,支持其作為一個開源項目在Apache許可證2.0版本下進行開發。目前的版本是2.0,Chapel網站展示了一些令人印象深刻的平行效能數據。
Chapel預設編譯成二進制可執行檔,但也可以編譯成C程式碼,且使用者可以選擇編譯器。Chapel程式碼可以編譯成函式庫,從C、Fortran或Python(及其他語言)呼叫。Chapel支援GPU程式設計,通過程式碼生成支援Nvidia和AMD圖形處理單元。
Chapel的函式庫集合正在不斷增長。最近有一個名為Chainn的神經網路函式庫可供Chapel使用,專門用於使用平行程式設計構建深度學習模型。Chapel中Chainn的實現使用戶能夠利用該語言的平行程式設計特性,從筆記型電腦到超級電腦進行深度學習模型的訓練。
Julia
Julia由麻省理工學院(MIT)開發,旨在成為一個快速、靈活和可擴展的解決方案,以應對上述的“兩語言”問題。Julia的工作始於2009年,當時Jeff Bezanson、Stefan Karpinski、Viral B. Shah和Alan Edelman著手創建一種高階且快速的開放技術計算語言。
像Python一樣,Julia提供了一個回應式解釋程式環境(REPL或讀取-求值-列印循環),使用快速的即時編譯器。該語言語法類似於Matlab,提供許多先進的特性,包括:
- 多重派發:根據輸入類型,函式可以有多種實現(易於創建可攜和自適應程式碼)
- 動態類型系統:用於文件、最佳化和派發的類型
- 效能接近靜態類型語言如C
- 內建套件管理器
- 為平行和分佈式運算設計
- 可以編譯成二進制可執行檔
Julia還擁有針對CUDA、ROCm、OneAPI和Apple的GPU函式庫,可與機器學習函式庫Flux.jl(等其他函式庫)一起使用。Flux用Julia撰寫,為Julia的原生GPU支援提供輕量級抽象。
Chapel和Julia都提供了一種高階且可攜的GPU程式設計方法。與許多隱藏底層硬體細節的語言一樣,可能會有一些效能上的損失。然而,開發者往往願意以幾個百分點的效能換取可攜性的便利。
參考資料:
Spelunking the HPC and AI GPU Software Stacks
更多eNews報導
桃園停車場驚傳恐怖意外!老翁不明原因「高速暴衝撞破牆」慘遭夾死
快訊/北市婦過馬路遭水泥車撞!「腳慘卡車輪」現場血肉模糊