編輯 | 言征

出品 | 51CTO技術棧（微信號：blog51cto）

為了緩解“英偉達”焦慮，市場上浮現出了不可思議的事情。

就在今天，一個“可以讓AMD GPUs上跑CUDA的編程工具包”不脛而走，引起業界的注意。

圖片

1.AMD GPU 可以本地跑英偉達的CUDA？

不需要修改 CUDA 程序，也不需要構建系統，通過一個編程工具包，就可以把CUDA應用程序進行AMD GPU的本地編譯。這個工具包就是Spectral Compute推出的SCALE。

關鍵是，SCALE的制作方還是個“AI芯片大一統的野心家”，表示：“當然，AMD 只是開始，對更多 GPU 供應商和 CUDA API 的支持正在開發中。”

據介紹，SACALE有以下幾個部分組成：一個nvcc兼容編譯器，能夠為 AMD GPU 編譯 nvcc-dialect CUDA，包括 PTX asm；針對 AMD GPU 的 CUDA 運行時和驅動程序 API 的實現；開源包裝器庫通過委托給相應的 ROCm 庫來提供“CUDA-X”API。這就是和等庫的cuBLAS處理cuSOLVER方式。

測試了哪些項目？

SCALE 團隊通過編譯開源 CUDA 項目并運行其測試來驗證 SCALE。并且完全通過的開原項目包括：NVIDIA Thrust、Blender Cycles、AMGX、llama-cpp、stdgpu等。

圖片

目前支持哪些 GPU？據介紹，AMD gfx1030（Navi 21、RDNA 2.0）、AMD gfx1100（Navi 31、RDNA 3.0）已經通過測試，AMDgfx1010、AMDgfx1101臨時測試后似乎有效。

2.那么SCALE是如何做到的？

市面上有不少跨平臺的GPGPU解決方案，比如受到英偉達官方支持的HIP方案，可以避免使用CUDA的模糊功能（如內聯PTX）的代碼，而AMD自己，本身就有一種轉換工具：hipfy，可以將CUDA代碼轉換為hip。

那么與其他跨平臺 GPGPU 解決方案相比，SCALE 有幾個關鍵創新：

• SCALE 接受原樣的 CUDA 程序。無需將它們移植到其他語言。即使您的程序使用內聯 PTX 也是如此asm。
• SCALE 編譯器接受與 相同的命令行選項和 CUDA 方言nvcc，可作為替代品。
• “模擬” NVIDIA CUDA 工具包的安裝，因此現有的構建工具和腳本就可以cmake正常工作。

當然在某些領域，SCALE對NVIDIA CUDA中某些功能的實現也有不同的行為。比如，SCALE尚不支持每個線程的默認流行為，雖然這不會破壞程序，但可能會降低性能。而在NVIDIA GPU上運行時，則有一種也會略微提高程序性能的解決方法：即顯式使用非阻塞CUDA流，而不是依賴于隱式CUDA流。

整體上看，與其他方案有這些不同：

（1）SCALE并不提供編寫 GPGPU 軟件的新方法，而是允許使用廣受歡迎的 CUDA 語言編寫的程序直接為 AMD GPU 進行編譯。

（2）SCALE 旨在與 NVIDIA CUDA 完全兼容。我們認為用戶不必維護多個代碼庫或犧牲性能來支持多個 GPU 供應商。

（3）SCALE 的語言是NVIDIA CUDA 的超集，它提供了一些可選的 語言擴展 ，可以讓那些希望擺脫的用戶更輕松、更高效地編寫 GPU 代碼nvcc。

當然，SCALE 尚在開發中。可能會缺少部分 API 而導致無法使用 ，不過團隊會根據用戶提的需求加速開發。

教程文檔很詳細：https://docs.scale-lang.com/

3.神奇的極客團隊

Specrtral Compute 是一個致力于加速GPGPU和HPC工作負載的全球團隊，這個團隊很神奇。小編翻了一下他們官網，可謂是一群AI極客的玩法。

官網顯示，他們推出了一種1秒內向全球傳送視頻的直播解決方案，還針對高吞吐量的GPU加速應用程序后臺和低延遲CPU執行進行優化，推出了最快的正則表達式引擎，而且性能不受影響；此外，這個團隊隊員還擅長優化你在用AI軟件，使其要么跑得更快，要么服務免費。

4.萬能的網友

為什么不是AMD？但代替不了英偉達

首先，一部分人爭議的焦點是“怒AMD不爭”——“如果AMD采取任何行動就好了，支持這個，任何一項都會話費幾百萬美元，但對AMD股東來說卻價值一萬億美元。”

然而也有人認為AMD正在努力，正如上文提到的HIP解決方案。

然而，也有部分網友認為如果AMD支持這樣的編程工具或者轉換層，會是一個壞主意。

據悉，CUDA 的設計并不與供應商無關，而 Nvidia 可以在技術和法律上任意制造困難。“我認為在此上運行 cuDNN 或 cuBLAS 違反了許可協議。因此，這些和其他 Nvidia 庫將成為 AMD 需要重新實現和支持的 API 邊界的一部分。”

“追求 bug-for-bug 兼容性是愚蠢的行為。CUDA 的重要用戶是開源。AMD 可以直接在上游項目（如 pytorch 或 llama.cpp）中實現支持。一旦獲得支持，社區就可以對其進行維護。”

5.指責 AMD 而不是 Nvidia，這很奇怪嗎？

事實并非如此。

一位網友已經被CUDA征服了，“即便AMD有一些努力，我也不相信 HIP 或 RocM 是 Cuda 的可行替代品。”

George Hotz 做了很多工作，試圖將各種 ML 架構移植到 AMD，并遇到了無數的驅動程序錯誤。問題不在于英偉達不會構建開放平臺——問題在于 AMD 不會投資競爭平臺。

即使 CUDA 是開放的， 你是否希望 nvidia 也為 AMD 編寫驅動程序？我不相信第三方會編寫“兼容層”，因為 AMD 自己的 GPU 并未針對類似 CUDA 的工作負載進行優化或測試。

99%的ML工程師不會寫CUDA

99% 的 ML 工程師不會編寫 CUDA。一位業內人士表示，對于絕大多數工作負載，Meta 可能有 20 名工程師為 Pytorch 編寫 Cuda 后端，其他每個工程師都會使用。Meta 可以再雇傭 20 名工程師來支持 AMD 擁有的一切（他們確實這樣做了，但它不如 CUDA 那么強大）。

真正擅長CUDA的工程師是金子一樣的貴，所以他們能做的項目遠遠超出了自己的精力和時間。甚至又網友爆料稱：自己認識一位CUDA工程師配有一個滑雪屋，價值超過180鎊黃金（約532萬美元）。

也有人延伸出了對現有芯片編程的建議，希望趕緊加入互操作性，開發人員太需要互操作性技術了。互操作性技術可以幫助目前僅支持NVIDIA GPU的軟件在未來快速添加對Intel和AMD GPU的支持。

寫在最后：英偉達的CUDA已經成為事實上的標準

作為 NVIDIA 發明的一種并行計算平臺和編程模型，CUDA已經憑借大模型時代成功完成了蝶變，目前基于 CUDA 的 GPU 銷量已經達到無法完全統計，軟件開發商、科學家以及研究人員正在各個領域中運用 CUDA。

Nvidia 付出了巨大的努力，也獲得了豐厚的回報。他們與實際使用其產品的人密切合作，資助開發并為研究人員、教師等提供大量支持，迄今已有十年之久。

正如網友評論的：“ 即使 AMD 推出了各方面都更好的 CUDA 版本，它仍然不會被采用，因為 CUDA 已經成為標準。”

“AMD 開始真正嘗試的最佳時機是 10 年前；第二佳時機是今天。”