•
隨著人工智慧不斷滲透到生活的各個領域，這些工具將運行在哪種軟體上仍然是一個問題。軟體堆疊（或協同工作以在計算系統上實現特定功能的軟體元件集合）的選擇在以 GPU 為中心的人工智慧任務計算需求中變得越來越重要。
隨著 AI 和 HPC 應用不斷突破計算能力的極限，軟體堆疊的選擇會顯著影響性能、效率和開發人員的生產力。
目前，軟體堆疊競爭中有三個主要參與者：Nvidia 的計算統一裝置架構 (CUDA)、英特爾的 oneAPI 和 AMD 的 Radeon Open Compute (ROCm)。雖然它們各有優缺點，但 Nvidia 的 CUDA 繼續佔據主導地位，主要是因為其硬體在 HPC 和現在的 AI 領域處於領先地位。
在這裡，我們將深入研究每個軟體堆疊的複雜性——探索它們的功能、硬體支援以及與流行的 AI 框架 PyTorch 的整合。此外，我們將最後快速瞭解兩種高級 HPC 語言：Chapel 和 Julia。
Nvidia 的 CUDA 是該公司專有的平行計算平台和軟體堆疊，用於在其 GPU 上進行通用計算。CUDA 提供了一個應用程式程式設計介面 (API)，使軟體能夠利用 Nvidia GPU 的平行處理能力來加速計算。
首先必須提到 CUDA，因為它在 AI 和 GPU 密集型 HPC 任務的軟體堆疊領域佔據主導地位，這是有充分理由的。CUDA 自 2006 年就已存在，這使其擁有悠久的第三方支援歷史和成熟的生態系統。許多庫、框架和其他工具都專門針對 CUDA 和 Nvidia GPU 進行了最佳化。對 CUDA 堆疊的長期支援是其相對於其他堆疊的主要優勢之一。
Nvidia 提供了一套全面的工具集作為 CUDA 平台的一部分，包括 CUDA 編譯器，如Nvidia CUDA Compiler (NVCC)。還有許多用於偵錯和最佳化 CUDA 應用程式的偵錯程式和分析器以及用於分發 CUDA 應用程式的開發工具。此外，CUDA 的悠久歷史催生了大量的文件、教學和社區資源。
在討論 AI 任務時，CUDA 對 PyTorch 框架的支援也至關重要。該軟體包是一個基於 Torch 庫的開源機器學習庫，主要用於電腦視覺和自然語言處理中的應用。PyTorch 對 CUDA 提供了廣泛且完善的支援。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 是許多開發人員選擇的另一種軟體堆疊。雖然 CUDA 可能佔據主導地位，但 ROCm 卻與眾不同，因為它是用於 GPU 計算的開放原始碼軟體堆疊。此功能允許開發人員自訂和貢獻程式碼庫，促進社區內的協作和創新。ROCm 的一個關鍵優勢是它支援 AMD 和 Nvidia GPU，從而實現跨平台開發。
這一獨特功能由異構計算可移植介面 (HIP)實現，它使開發人員能夠建立可在不同 GPU 平台上運行的可移植應用程式。雖然 ROCm 支援消費級和專業級 AMD GPU，但其主要重點是 AMD 專為專業工作負載設計的高端 Radeon Instinct 和 Radeon Pro GPU。
與 CUDA 一樣，ROCm 提供了一系列用於 GPU 程式設計的工具。這些工具包括 C/C++ 編譯器（如 ROCm 編譯器集合、AOMP 和 AMD 最佳化 C/C++ 編譯器）以及 Fortran 編譯器（如 Flang）。此外，還有適用於各種領域的庫，例如線性代數、FFT 和深度學習。
儘管如此，與 CUDA 相比，ROCm 的生態系統相對較新，需要在第三方支援、庫和工具方面迎頭趕上。與 CUDA 提供的大量文件、教學和支援相比，進入市場的遲到也意味著文件和社區資源更加有限。對於 PyTorch 來說，情況尤其如此，它支援 ROCm 平台，但由於其歷史和成熟度較短，需要在性能、最佳化和第三方支援方面趕上 CUDA。ROCm 上 PyTorch 的文件和社區資源比 CUDA 的更有限。不過，AMD在這方面正在取得進展。
與 Nvidia 一樣，AMD 也提供了大量的ROCm 庫。AMD 為深度學習提供了一個與 cuDNN 相當的庫，名為 MIOpen，用於 PyTorch 的 ROCm 版本（以及其他流行工具）。
此外，雖然 ROCm 同時支援 AMD 和 Nvidia GPU，但由於驅動程式開銷和最佳化挑戰，其在 Nvidia 硬體上執行階段的性能可能無法與 CUDA 相匹配。
英特爾的 oneAPI 是一種統一的跨平台程式設計模型，支援針對各種硬體架構和加速器進行開發。它支援多種架構，包括來自不同供應商的 CPU、GPU、FPGA 和 AI 加速器。它旨在為異構計算提供與供應商無關的解決方案，並利用 SYCL 等行業標準。此功能意味著它可以在 AMD 和 Nvidia 等外部供應商的架構以及英特爾的硬體上運行。
與 ROCm 一樣，oneAPI 是一個開源平台。因此，與 CUDA 相比，oneAPI 有更多的社區參與和對程式碼庫的貢獻。oneAPI 支援開源開發，支援多種程式語言和框架，包括帶有 SYCL 的 C/C++、Fortran、Python 和 TensorFlow。此外，oneAPI 為異構計算提供了統一的程式設計模型，簡化了跨不同硬體的開發。
同樣，與 ROCm 一樣，oneAPI 也存在一些與堆疊成熟度相關的缺點。作為一個較年輕的平台，oneAPI 需要在第三方軟體支援和針對特定硬體架構的最佳化方面趕上 CUDA。
從 PyTorch 中的具體用例來看，與成熟的 CUDA 整合相比，oneAPI 仍處於早期階段。PyTorch 可以利用 oneAPI 的資料平行 Python (DPPy) 庫在 Intel CPU 和 GPU 上進行分佈式訓練，但對 oneAPI GPU 的原生 PyTorch 支援仍處於開發階段，尚未準備好投入生產。
話雖如此，值得注意的是，oneAPI 的優勢在於其基於開放標準的方法和跨平台可移植性的潛力。如果擔心供應商鎖定並且在不同硬體架構上運行 PyTorch 模型的能力是優先事項，那麼 oneAPI 可能是一個可行的選擇。
目前，如果 Nvidia GPU 上的最大性能是 PyTorch 工作負載開發人員的主要目標，那麼 CUDA 仍然是首選，因為它擁有完善的生態系統。也就是說，尋求與供應商無關的解決方案的開發人員或主要使用 AMD 或英特爾硬體的開發人員可能希望分別依賴 ROCm 或 oneAPI。
雖然 CUDA 在生態系統開發方面處於領先地位，但其專有性質和硬體特異性可能會使 ROCm 和 oneAPI 成為某些開發人員更有利的解決方案。此外，隨著時間的推移，這些堆疊的社區支援和文件將繼續增長。CUDA 現在可能佔據主導地位，但這種情況在未來幾年可能會發生變化。
總體而言，許多開發人員更喜歡建立獨立於硬體的應用程式。在 HPC 中，出於性能原因，硬體最佳化是合理的，但許多現代程式設計師更喜歡專注於他們的應用程式，而不是底層硬體的細微差別。
PyTorch 就是這一趨勢的一個很好的例子。Python 並不是一種特別快的語言，但 Hugging Face 上 92% 的模型都是PyTorch 獨有的。只要硬體供應商在其庫上建構了 PyTorch 版本，使用者就可以專注於模型，而不必擔心底層硬體的差異。雖然這種可移植性很好，但它並不能保證性能，而這正是底層硬體架構可能發揮作用的地方。
當然，Pytorch 基於 Python，這是許多程式設計師最喜愛的第一語言。這種語言通常以易用性換取性能（尤其是平行程式設計等高性能功能）。當使用 Python 啟動 HPC 項目時，它們傾向於遷移到基於分佈式 C/C++ 和 MPI 或使用 OpenMP 的執行緒應用程式的可擴展高性能程式碼。這些選擇通常會導致“兩種語言”問題，開發人員必須管理其程式碼的兩個版本。
目前，兩種“較新”的語言 Chapel 和 Julia 提供了一種易於使用的語言解決方案，可提供高性能編碼環境。除其他外，這些語言試圖“抽象”編寫平行 HPC 叢集、多核處理器和 GPU/加速器環境應用程式所需的許多細節。在它們的基礎上，它們仍然依賴於上面提到的供應商 GPU 庫，但通常可以輕鬆建構能夠在執行階段識別和適應底層硬體環境的應用程式。
1Chapel
Chapel（Cascade 高生產力語言）最初由 Cray 開發，是一種平行程式語言，旨在實現比當前程式語言（即“Fortran/C/C++ 加 MPI”）更高等級的表達。收購 Cray 的惠普企業目前支援該語言的開發，將其作為 Apache 許可證第 2 版下的開放原始碼專案。當前版本為2.0 版，Chapel 網站發佈了一些令人印象深刻的平行性能資料。
Chapel 默認編譯為二進制可執行檔案，但也可以編譯為 C 程式碼，使用者可以選擇編譯器。Chapel 程式碼可以編譯為可從 C、Fortran 或 Python（及其他語言）呼叫的庫。Chapel 通過為 Nvidia 和 AMD 圖形處理單元生成程式碼來支援 GPU 程式設計。
Chapel可用的庫越來越多。最近有一個名為 Chainn 的神經網路庫可用於 Chapel，它專門用於使用平行程式設計建構深度學習模型。Chainn 在 Chapel 中的實現使使用者能夠利用該語言的平行程式設計功能，並在從筆記型電腦到超級電腦的大規模上訓練深度學習模型。
2Julia
Julia 由麻省理工學院開發，旨在成為上述雙語言問題的快速、靈活且可擴展的解決方案。 Julia 的開發工作始於 2009 年，當時 Jeff Bezanson、Stefan Karpinski、Viral B. Shah 和 Alan Edelman 著手建立一種既高級又快速的開放式技術計算語言。
與 Python 一樣，Julia使用快速的即時編譯器提供響應式解釋程式設計環境（REPL 或 read–eval–print loop ） 。該語言語法類似於 Matlab，並提供許多高級功能，包括：
1、多重分派：一個函數可以根據輸入類型有多種實現（方法）（易於建立可移植和自適應程式碼）
2、動態類型系統：用於文件、最佳化和調度的類型
3、性能接近 C 等靜態類型語言。
4、內建包管理器
5、專為平行和分散式運算而設計
6、可以編譯為二進制可執行檔案
Julia 還擁有適用於 CUDA、ROCm、OneAPI 和 Apple 的GPU 庫，可與機器學習庫 Flux.jl（以及其他庫）一起使用。Flux 是用 Julia 編寫的，為 Julia 的原生 GPU 支援提供了輕量級的抽象。
Chapel 和 Julia 都提供了一種高級且可移植的 GPU 程式設計方法。與許多隱藏底層硬體細節的語言一樣，它們可能會有一些性能損失。不過，開發人員通常願意犧牲幾個百分點的性能來換取易移植性。 (半導體行業觀察)