中國 GPU 發展窗口期已至，生態構築核心優勢
AI 發展已經帶動 GPU 行業高速發展，中國 AI 也為中國 GPU 的發展提供契機。在國際供應鏈不確定性背景下，我們認為，未來三年可能是中國 GPU 發展的關鍵窗口期，這一段時期，中國 GPU 有望取得長足發展，有可能是較好的投資時期。目前，中國大陸 GPU 領域公司數量較多，從性能指標方面來看，已有部分公司能夠在理論硬體性能方面接近國際主流水平，理論算力指標較高。
同時，在晶片對外帶寬方面，英偉達也並非完全高不可攀。例如，根據 AMD 官網，其 MI 系列產品的帶寬就經歷了快速進化，從 MI50 到 MI100 再到 MI250，其 Infinity Fabric 通道就從 2 個提升到 8 個，對外帶寬從 184GB/s 提升到 800GB/s。中國大陸產品在通信方面也進行了嘗試，例如壁仞科技的 BR100 晶片，其 BLink 技術就實現了 8 通道，合計 512GB/s 的對外帶寬，技術定位類似於英偉達的 NVLink。
但儘管中國晶片的理論算力和理論帶寬均能夠做到較為良好的水平，理論性能卻往往面臨軟體生態的限制，即便集成 GPU 領域的領先企業 Intel 也無法擺脫這一規律。Intel 新發布的獨顯 Arc 系列在使用了更多電晶體的前提下，具備更高的理論性能，但實際使用性能相比友商的基礎型顯卡有一定差距。
我們從軟體測試中可以看見，3Dmark 測試所代表的 GPU 理論性能測試中，Intel 的 Arc 系列均有亮眼表現，而到了實際使用場景中，Intel Arc 系列產品的實際幀率相比同樣的友商產品則有一定差距，重要原因在於驅動程序，而驅動程序正是生態的核心組成部分之一。
另外生態在數據中心與開發者場景中起到更重要的作用，能夠重塑整個數據科學/AI 工作流程，加強開發者黏性，形成正反饋。在開發者的日常流程中，首個環節是數據管理，包括數據從數據來源的提取（Extraction）、變形（Transform）、加載到應用端（Load）， 合併稱為 ETL，隨後還有數據的存儲等。其次是數據訓練、驗證（可視化）、部署（推理）等多個環節。足夠良好的 GPU 生態能夠極大影響上述工作流，首先可以將模型訓練環節遷移到 GPU，隨後還可以將 ETL 環節（傳統上由 CPU 完成）也遷移到 GPU 上，讓整個數據科學/AI 工作流幾乎全部在 GPU 上完成。
通過發達的 GPU 軟體支持實現工作流遷移，能夠極大提高效率，從而重塑開發者的軟體使用習慣，讓開發者的黏性極大增加，形成正反饋，持續提高軟體生態的壁壘。
形成上述正反饋的前提是在每個環節中都必須有足夠豐富、可靠、易於使用的工具供開發者使用，且最好是開發者熟悉、擁有成熟社區的，由此可見生態的重要性。
CUDA：GPU 生態先驅，AI 時代基礎設施
提及生態，GPU 生態的奠基者 CUDA 是無法繞過的。如今整個科學計算、AI 的軟體生態大多構建在 CUDA 的基礎之上。CUDA 也是軟體生態的標杆，從軟體庫的覆蓋面、AI 框架和算子庫的支持程度兩方面來講，都是目前最完善的。
CUDA 的誕生：實現從 GPU 到 GPGPU 的轉變。在 CUDA 問世之前，想要調用 GPU 的計算能力必須編寫大量的底層語言代碼或借用圖形 API，對使用高級語言為主的程序員十分不便。英偉達公司的首席技術官 David Kirk 以及 CEO 黃仁勛主導推出了 CUDA。2006 年 CUDA 發布，2007 年正式推出 CUDA1.0 公測版本。此後程序員無需再通過圖形 API 來調用 GPU，而是可以直接採用類似 C 語言的方式直接操控 GPU。2008-2010 年，CUDA 平台進一步發展，拓展了新局域的同步指令、擴充全速常量內存並且支持遞歸，NVIDIA 向各軟體廠商免費提供開發工具，使得 CUDA 生態初具規模。
發展：十年苦坐冷板凳，與 AI 生態深度綁定。在 CUDA 系統誕生之初，英偉達大量投入研發對 CUDA 進行不斷更新與維護，但並沒有立即得到市場的認可，CUDA 用戶不多但大量研發卻直接影響利潤，英偉達市值長期不振，直到 2016 年市值才超過 2007 年的水平。但 CUDA 對科學計算領域的滲透一直在進行，2012 年深度學習革命開始以來更是一直在滲透 AI 領域，2012 年 ImageNet 挑戰賽冠軍使用的就是英偉達 GTX580 GPU。此後 CUDA 持續疊代，2023 年 CUDA 已經推出最新的 12.0 版本 API。如今整個 HPC 與 AI 生態都已經與 CUDA 形成了深度綁定，CUDA 已經成功塑造了用戶習慣，成為了 AI 時代開發者最熟悉的工具箱。
CUDA 生態：組件龐雜、取代難度高。CUDA 所包含的生態組分眾多，包含編程語言和 API、開發庫、分析和調試工具、數據中心和集群管理工具，以及 GPU 硬體等多個大類。每一大類中都包含了大量的組件，是英偉達以及開源生態開發者們在二十年間日積月累所形成，如今要將其取代難度較大，需要巨量的時間和資源投入。CUDA 生態雖已成為 AI 和 HPC 幾乎不可分割的一部分，但英偉達占據了絕大部分市場份額，對下游用戶來說，其使用成本也不低（根據英偉達財報，近 5 年來其毛利率基本維持在 60%上下），用戶有意願尋求低成本替代。且在當前國際局勢下，中國本土企業面臨一定的供應鏈不確定性。因此，對於諸多企業而言，在 CUDA 之外尋找一個第二選項，是對於企業經營可行的選擇，要做到這一點，就需要儘可能跨越 CUDA 的護城河。
CUDA 的兩大生態護城河：軟體庫覆蓋率、AI 框架支持度。對於後來者而言，關鍵是採取切實可行的措施向 CUDA 學習靠攏，進行自身生態建設。我們認為，CUDA 的第一個壁壘是軟體庫覆蓋率，既包含了基礎的並行計算軟體庫，也包含了細分行業軟體庫，還有配套的輔助軟體等；第二個壁壘則是針對 AI 領域而言的 AI 框架支持率。對於中國晶片公司而言，中短期內可以儘可能投入資源實現的是並行計算軟體 輔助軟體庫開發，以及對 AI 框架的完善支持，而對於細分行業的支持，則需要較長的時間和積累。
並行計算軟體庫覆蓋度：以 ROCm 為例
目前，有望替代 CUDA的選項已經存在，即 ROCm。ROCm 是 AMD 開發的對標 CUDA 的軟體平台。ROCm 全稱為 Radeon Open Computing platforM，是基於 AMD 系列 GPU 設計的開源計算生態，同時也能夠相當大程度上兼容 CUDA、支持 NVIDIA GPU，其目標是建立有望替代 NVIDIA CUDA 生態的平台。
以下我們將以 ROCm 為例，分析生態的第一個核心要素——並行計算軟體庫覆蓋度，包括軟體支持覆蓋範圍的變化及其影響，未來的演變趨勢等。
ROCm 前為何沒有能挑戰 CUDA 者？OpenCL 自身不足，AMD 舊產品性能待提升
ROCm 出現之前，AMD 也意識到 GPU 在 AI 計算領域的潛力。根據五二電子工作室網站信息，AMD 曾經嘗試利用 OpenCL 打入深度計算領域，先是嘗試移植 cuda-convnet，後轉向 Caffe，最後的成果是 OpenCL Caffe，雖然是有益的嘗試，但這項努力並沒有引起很多的關注，其成果也局限在單一工具，並未構建起有效的平台。此前嘗試失敗的一個重要原因在於 AMD 此前一直使用 OpenCL，而 OpenCL 本身具有不足之處：語言支持少（2015 年以前只支持 C），更多面向底層軟體而非上層軟體。另外硬體層面，主導 ROCm 生態的 AMD 此前在計算卡系列仍然採用 GCN 架構，產品性能相對不足。
軟體不足：OpenCL 對 HPC 支持有限，產品節奏長期滯後
OpenCL 最早提出是為了應對單核性能極限與多核並行計算的發展，最初由蘋果開發，並與 AMD、Intel、英偉達、高通、IBM 的團隊合作完成 API 方案，各家公司在 2008 年合作成立 Khronos 計算工作組，並於當年發布 OpenCL 標準，各公司採用統一的 API，但各自完成實現方式。需要注意的是，這時 GPU 的算力價值還沒有被廣泛認知，Khronos 成員除了英偉達外均以 CPU 為主業，OpenCL 也更多考慮了多核 CPU 計算，導致 OpenCL 更多考慮底層硬體驅動/操作系統支持，對高層的科學計算庫等支持則相對有限。這一點從支持的語言也可以看出，OpenCL 長期以來僅支持 C 語言（底層驅動、操作系統等多使用 C），而科學計算庫常用的 C 支持直到 2015 年的 OpenCL2.1 版本才得以推出。
與之相對比，英偉達早在 2010 年的 CUDA 3.0 版本就已經添加 C 和 Fortran 支持，2011 年的 4.0 版本更通過 GPU Direct 2.0 等技術在 HPC 領域站穩腳跟，2013 年的 GTC13 上，CUDA 添加了 Python 支持，易學易用水平再度提升，到 OpenCL 發布 C 支持的 2015 年，CUDA 已經疊代到 7.0 版本，形成了相對穩定的護城河。可見二者在科學計算領域的統治力完全不可同日而語。根據 AnandTech，OpenCL 始終沒有在 HPC 領域獲得大規模應用，遑論後續的 AI。
硬體不足：早期 MI 產品性能待提高，對數據中心用戶吸引力有限
ROCm 誕生前以及誕生早期，CUDA 以外的計算生態推廣也有硬體方面的原因。如果僅是軟體支持不足，那麼如果硬體性能占優或具備明顯的性價比優勢，硬體產品仍然有可能在一些對生態要求不高的細分領域得到銷售，例如虛擬貨幣市場，AMD 桌面顯卡曾經依靠較高的浮點性能占據較高的份額。
但根據AMD官網發布的信息可以看到，早期AMD的計算卡在性能表現方面並不占優。在 2020 年 CDNA 架構面世前，AMD 的數據中心 GPU 一直使用的是 GCN 系列架構，搭載 GCN 系列架構的產品在 2012 年就已推出，雖然在遊戲機等場景獲得較高市場份額，但在數據中心市場並未取得顯著成果，這與其性能表現有關。AMD 在 2017 和 2018 年曾經兩次推出 Instinct MI 系列數據中心 GPU，但第一批推出的 MI6、MI8、MI25 在算力表現上與同期的 NVIDIA V100 具有一定差距，這三款 GPU 的 FP64 算力均未超過 1TFLOPS，而 V100 的兩個版本均在 7TFLOPS 以上，FP32 算力也僅採用 GCN5 架構的 MI25 與 V100 相對接近。到了 2018Q4 批次推出的 MI50/MI60，AMD 終於在算力表現上接近 2017 年推出的 V100。
而在顯存與帶寬等方面，2017 年批次的 MI 系列顯存容量與帶寬僅有 V100 的約一半水平，而 GPU 互聯方面尚未配備 Infinity Fabric，帶寬與 V100 SXM 的 NVLink 也有差距。到 2018Q4 批次的 MI50/MI60，AMD 為其配備了初代 Infinity Fabric，單通道 92GB/s，共計雙通道 184GB/s，有所提升，在顯存與外部帶寬方面向 V100 靠攏。
從上述性能對比可見，早期的 Instinct MI 系列 GPU 性能與 V100 相比仍有差距，也在一定程度上影響了 ROCm 生態的推廣。這一現象隨著 AMD CDNA 架構的推出有所改觀，2020 年 Q4，MI100 與 NVIDIAA100 在相近的時間推出，其 FP64、TF64、FP32 算力指標全面超越 A100，但在 AI 常用的低精度張量計算（TF32、TF16、INT8 等）方面仍與 A100 存在較大的算力差距。到了 CDNA 這一代，AMD 在數據中心 GPU 硬體算力方面可以說已經與 NVIDIA 互有優劣，不再是被全方位包圍的態勢。到了 CDNA2 這一代，MI 250/250X 在 FP64、TF64、FP16 計算方面取得了相對 H100 的優勢，但 FP32、TF32、TF16 算力方面弱於 H100，在張量計算方面仍然不及 NVIDIA，但可以說維持住了與 NVIDIA 主力產品各有優勢的局面。
顯存方面，MI250/MI250X 在容量與帶寬方面超越了 H100 SXM 版本。在外部帶寬方面也憑藉 8 通道 Infinity Fabric 實現了 800GB/s 的帶寬，接近 H100 SXM 的 900GB/s。
綜上所述，ROCm 的推廣緩慢受到硬體性能發展滯後的影響，但硬體方面的掣肘隨著 2020 年 CDNA 架構產品的發布已經有所改善，在可見的未來，硬體方面可能不再對 ROCm 構成限制。
AMD 系算力走向實用化的轉折點：重建基礎平台，從 OpenCL 轉向 HIP
OpenCL 的發展遲緩導致了 AMD 多年未能在 GPU 計算領域有所作為，更多局限在遊戲卡領域，而神經網絡、區塊鏈等技術在 2010s 的發展讓英偉達獲取了大量市場份額，CUDA 生態的護城河愈發強大。AMD 也希望能夠改變自身市場地位，因而進行了完全的戰略轉向，不再基於 OpenCL 僅僅提供單體工具，而是開始全面擁抱現有 CUDA 生態， 並構造軟體平台，實現開發者的低成本遷移，這一過程持續至今，並且在可見的未來仍將持續。
具體而言，AMD 首先在 2015 年 11 月的 SC15 超算會議上提出 Boltzman 計劃（得名於奧地利物理學家玻爾茲曼，其在統計物理學領域的成果對科學計算中的流體模擬、AI 中的隨機 RNN 等都有重要作用）。Boltzman 計劃的主要內容在於將標準 C 引入 AMD 計算生態，並為其提供 HCC 編譯器（Heterogeneous Compute Compiler，對標英偉達 NVCC），同時提供HIP（Heterogeneous-compute Interface for Portability）套裝來擁抱現有的 CUDA 生態。
AMD 官方對於這一戰略也賦予了較高期待，希望能夠給 GPU 計算生態帶來變化，這從 AMD 在玻爾茲曼計劃開始一年後的 SC16 大會上的相關表態可以得以體現。
落實到具體執行層面，如何真正在 GPU 生態立足？我們認為，第一要與 CUDA 生態融合，做到低成本遷移；第二要在保證可遷移性的前提下優化體驗，追求更廣的函數庫覆蓋、更佳的易用性以及性能；第三需要有足夠的疊代速度，才能在市場上形成正循環。以下我們分別對這幾方面進行分析。
ROCm 如何融入 CUDA 生態：HIP 通用前端代碼 Hipify 轉換工具
ROCm 首先需要融入 CUDA 生態，這一點主要通過 HIP 系列函數庫完成。具體而言有兩種兼容方式，第一種針對存量程序，即將已有的 CUDA 代碼運行在 AMD 或類似的 GPU 上，這一方式可以通過 Hipify 工具來實現，將 CUDA 代碼轉化為等效的 HIP 代碼，再經過 ROCm 的編譯器，即可運行；第二種針對增量程序，即希望新寫的代碼能夠同時 在 NVIDIA 或 AMD 的 GPU 上運行，這一方式較為簡單，HIP 代碼通常扮演與用戶交互的「前端」角色，而真正執行任務的「後端」既可以是 ROCm 生態的各種 roc 開頭的函數庫，也可以是 CUDA 生態的 cu 開頭的函數庫，可以由 HIP 函數庫在運行時自動檢測、自動選擇，所以 HIP 代碼可以一次寫作多平台部署。
此處一個值得注意的點在於，Hipify 工具是否能夠真正實現 CUDA 代碼的完美轉換？ROCm 生態中提供了兩種 Hipify 工具，第一種是一個編譯器，將 CUDA 代碼編譯成 HIP 代碼，採用的是目前較為成熟的 clang 編譯器前端，只要 CUDA 代碼正確、引入的外部信息均可獲得，那麼代碼就能夠得到妥善翻譯；第二種是一個簡單的腳本，採用 Perl 語言，其功能就是文本替換，按照一定規則將 CUDA 代碼中的各種函數名稱替換成 HIP 中的對應函數，但這個腳本在面對較為複雜的代碼結構時有一定局限性。
由上述內容可見，如今的 ROCm 在融入 CUDA 生態方面基本具備一定能力。
ROCm 可以多大程度上替代 CUDA：支持日漸完整，體驗仍需進步
在能夠基本融入 CUDA 生態的基礎上，接下來的問題就在於使用體驗。具體而言，可以分為軟體庫支持、基礎軟硬體硬體支持、性能、易用性等方面。
軟體庫支持：支持範圍持續擴大，基本支持 AI 與 HPC 生態
軟體庫支持是可用性的核心，2015 年以來 ROCm 生態持續豐富組件。2016 年，ROCm1.0 階段，基本的數據格式、基本運算指令、常用的基礎線性代數庫、部分常用 AI 框架已經得到初步支持
在隨後的年份中，ROCm 生態繼續得到優化，2018 年開始開發容器支持以及系統管理工具；2019 年 ROCm3.0 版本中基本將系統/集群管理工具、集群通信工具、容器工具開發完成，AI 框架支持基本實現；2020 年 ROCm4.0 版本中，HPC 生態已實現初步可用，各類核心基礎庫基本完成初步搭建。
此後 ROCm 也持續更新到 2023 年 4 月已經推出 ROCm5.6 版本，形成了底層驅動/運行時、編程模型、編譯器與測試調試工具、計算庫、部署工具等相對清晰的軟體架構。
在當前 AI 領域最常用的 AI 框架與並行計算算法庫方面，ROCm 5.0 及以後的框架始終保持著緊密跟蹤支持，為其在 AI 領域滲透提供了基礎。
目前從完成度上來看，ROCm 對比 CUDA 已經在開發、分析工具、基礎運算庫、深度學習庫與框架、系統軟體方面做到相對完整的支持，但對於 DPU、物理模擬、細分領域、用戶界面等支持還存在一定不足，例如用於 GIS 和空間運算的 cuSpatial、用於產生 GUI 的 cuxfilter、用於材料物理模擬的 Modulus 等，ROCm 尚未在這些領域提供完善的支持。
基礎軟硬體支持：Windows 支持或將面世，CDNA 與 RDNA 架構支持提升
僅支持 AI 的核心框架與算法庫對於 GPU 而言仍然不夠，往往需要全面的軟硬體支持才能觸及大量用戶，在使用中獲得反饋、進行快速疊代，從而構建生態護城河。操作系統方面，目前 ROCm 的現狀仍以支持 Linux 為主，未來計劃添加 Windows 支持。當前版本 ROCm 支持的操作系統主要是 3 類 Linux 發行版：RHEL（Red Hat Enterprise Linux）、SLES（SUSE Linux Enterprise Server）、Ubuntu。
對 Windows 的官方支持不足是 ROCm 目前的一個短板，而早在 2007 年的 CUDA 1.0 時代，CUDA 就已經明確支持 Windows，這也讓 CUDA 的用戶群體更加廣泛。
但面對 CUDA 的優勢，ROCm 也在跟進，根據 AnandTech 的文章，儘管 AMD 儘量避免對 Windows 支持上線日期做出承諾，但其工作日誌顯示 AMD 仍在進行 Windows 方面的開發。
硬體支持方面，目前 ROCm 支持的 GPU 型號主要集中在計算卡領域，圖形卡的 ROCm 支持已經有所進步但仍需擴展。目前 Instinct 計算卡方面，從 MI50（GCN5.1 架構）以後（CDNA 系列架構）均實現了 ROCm 完整支持（僅需使用 ROCm 自帶的驅動），但只能在 Linux 環境下使用。
專業圖形顯卡方面，目前支持的型號還較為有限，在使用 Radeon Pro 驅動的情況下，部分基於 GCN5.1 架構以及 RDNA/RDNA2 架構的專業顯卡（用於工作站等場景的 Radeon Pro 系列）也進行了適配，其中 Radeon Pro W6800 實現了 Windows 支持，其餘諸如 W6600、W5000 系列等型號並未在文檔中提及。
圖形卡/遊戲卡方面，目前支持的型號也較為有限，官方提供完整支持的僅有 Radeon VII，另有 RX6600 獲得了 HIP Runtime 在 Linux/Windows 的支持，RX6900XT 獲得了 HIP SDK（包含 HIP Runtime 以及一組 GPU 計算庫）在 Linux/Windows 的支持，其餘絕大多數普通遊戲卡並未在文檔支持列表中被提及。據和 AnandTech 消息，2023Q3 版本的 ROCm 有望首次支持 RDNA3 架構，包括 Radeon Pro W7900 48GB 專業顯卡、Radeon RX 7900 XTX 24GB 遊戲顯卡等。
與之相比，NVIDIA 目前全產品線支持 CUDA，能夠獲得更廣闊的市場空間。尤其是對於圖像生成等算力消耗較小的應用，用戶往往只需購買一張 NVIDIA 遊戲卡，並在 CUDA 支持下進行部署即可，這一張遊戲卡還能支持其他日常工作與娛樂，對於小用戶具有較強的吸引力。而同樣的工作（Stable Diffusion），在 ROCm 生態內部，現在是由開源社區自發支持的（docker_sd_webui_gfx1100 項目）。硬體支持還包括 CPU 方面，目前只需 Intel Haswell 架構（2013 年）以後或 AMD Zen 架構以後的產品即可。虛擬化支持對於數據中心給客戶按需分配算力較為重要，目前 ROCm 生態在此處的支持水平尚可，已經能夠支持 VMWare ESXi 7/8 版本。
綜合來看，ROCm 生態在軟硬體支持領域目前已經有一定可用性，但 Windows 支持和 GPU 產品的全線支持仍需繼續推進。
性能表現與易用性：ROCm 在 AI 框架領域性能無短板，易用性尚需提升
軟硬體與庫決定可用範圍，而在可用範圍內更多比較的是優化水平（性能水平）與易用性。性能層面，在進行了完善優化的情況下，ROCm 與 CUDA 的差距並不大。以 Pytorch 為例，Meta 與北卡州立大學的研究人員進行了較為全面的測試，使用 NVIDIAA100 與 AMD MI210 測試模型運行所需時間，如果比值小於 1 則說明模型在 A100 上表現更佳，反之則說明在 MI210 上表現更佳。研究人員得出結論，最終模型運行的時間表現與 Tensor Core 有關，如果模型能夠使用 Tensor Core 的部分更多，則通常在 A100 上的表現更好。
但並非所有模型都能使用 TF32 數據格式，如果模型使用了更多的「按對應位置的運算」（在兩個矩陣中位於相同位置的元素進行加減乘除），那麼就無法調用 Tensor Core，此時 MI200 FP32 算力更高的優勢就能夠得以體現。同時，按照訓練和推理分類頁可見，在大多數推理場景中 A100 性能更好，因為推理場景中使用 Tensor Core 的比例更高。
通過上述研究結果可見，Pytorch 模型性能基本準確反映了 A100 與 MI210 的性能區別，從而也說明 ROCm 在支持完善的框架領域相比 CUDA 並無明顯性能損失。
易用性方面，對於個人用戶而言，ROCm 與 CUDA 相比還存在一定差距。目前 CUDA Toolkit 已經可以在英偉達官網直接下載安裝包，如同其他應用程序一樣快速安裝完成。
如果要在 CUDA Toolkit 的基礎上添加功能，例如添加深度學習功能，只需在官網下載 cuDNN 對應的 zip 壓縮包（或其他格式壓縮包）並解壓即可，其內部就包含了所需使用的 C 語言頭文件、動態鏈接庫、lib 文件等，操作十分簡便。
與之對比，ROCm 由於只支持 Linux，其使用命令行形式或腳本形式安裝門檻比 CUDA 的圖形化操作要更高，對於開發人員或算法工程師等專業人士尚可，但對於並非以 AI 為核心專業的用戶仍有一定門檻。
總結：張量計算待提升，基礎軟硬體與軟體庫支持需完善
綜上所述，ROCm 生態已經能夠一定程度上對 CUDA 進行替代，尤其在核心的 AI 領域已經具備較為完善的支持和可用性，但要更進一步仍需利用 AMD 以及開源社區的力量，對張量算力、易用性、Windows 支持、硬體支持範圍等方面進行優化。
ROCm 的未來：開源是後發者的合理選擇，或可參照 Python 與 MATLAB
綜上所述，如今的 ROCm 已經逐漸具備了枝幹，仍待枝繁葉茂。為了在整體研發投入不及 CUDA 的情況下讓後發者的生態逐步茂盛，開源並藉助外界的社區力量是一個可行的選擇。目前整個 ROCm 項目的源代碼基本已經全部公布於 GitHub，在眾多組件當中，只有 AMD 私有的編譯器 AOCC（在開源 LLVM 的基礎上修改而來，針對 AMD 硬體進行優化）屬於閉源項目，其餘均通過不同形式的開源許可證進行開源，整個開源社區的開發者力量均可為 ROCm 項目的完善做出貢獻。
開源是否能真正促進生態的完善甚至幫助 ROCm 超越 CUDA？這一問題的答案並不是非黑即白，開源能夠聚集社區開發力量，而商業閉環則能夠實現有效的經濟激勵，可謂各有優勢。但對於處在後發位置的 ROCm 來說，採用開源模式或許更為合適。其原因在於，商業閉環的能量與商業生態的規模直接相關，如果 ROCm 與 CUDA 同樣閉源，則受 限於收入與利潤規模，AMD 的研發資源大概率不如 NVIDIA 多，難以取得競爭優勢。
那麼如何對趨勢進行更具體的判斷？可以參考以往的案例，例如 iOS/Android、Windows/Linux、MATLAB/Python 等。其中前兩對都是操作系統，用戶群體較為廣泛，生態的力量也強大很多；或許更可以類比的是 Python 與 MATLAB，二者同為編程語言，各有自身的生態，用戶都是軟體開發者或科學計算等領域的專業人士，其生態的強度或許與 ROCm/CUDA 更為接近，且軟體生態的構成也都是中心化的常規軟體庫與細分專業庫相結合，因此在生態構成方面也具有較高的可比性。
Python 作為開源的代表，憑藉開源能夠獲取相當大一部分市場。由於其簡潔易用免費的特性已經成為 AI 和數據科學領域首選語言，根據 TIOBE 的統計，Python 語言的市占率近年來快速上升，屢居第一，達到 15%左右。目前 AI 領域的 Pytorch、TensorFlow 以及數據處理領域的pandas以及各類爬蟲庫乃至金融科技等領域均有大量 Python 庫在生態中居於領先地位。這與生態規模相對較大、需求相似度高、可標準化程度高有關，投入產出比較高，因此能夠聚集足夠多的開發者，迅速建立起足夠強大的生態，並憑藉開源免費易用的優勢牢牢把持優勢地位。
而 MATLAB 則憑藉全面優質的 simulink 支持，把控大多數細分場景。在各種電力、機械仿真模擬等領域，simulink 依靠商業循環推出了大量工具箱，完成了大量細分領域的覆蓋與支持，並形成較強的用戶粘性。這些領域由於用戶規模較少，且用戶大多不是專業的程序開發人員，往往生態形成速度較慢，MATLAB 能夠以此在相當長的時間內維持相對穩定的市場地位。
因此我們認為，在長期來看，ROCm 生態有望憑藉開源的特性，在一些較大的生態領域（如 AI 領域）迅速形成軟體的全面覆蓋，逐步占據更多份額，至於一些較為細分的領域（如材料物理模擬等），ROCm 或許還需要更長的時間才能具備競爭力。
AI 框架支持：以昇騰為例，算法庫 配套軟體基建
對於 GPU/GPGPU 而言，通用並行算法（通常為向量計算）的廣泛支持是軟體生態的核心優勢，然而對於 AI 晶片（NPU 等）而言，其本身的硬體架構（專注強化矩陣計算，而矩陣計算單元並不能進行向量運算）決定了其難以真正全面支持並行計算需求。因此，對於此類晶片，重點在於實現 AI 框架支持，發揮其在 AI 領域的高效性。以 NPU 領域較為領先的華為昇騰為例。其採用自主開發的 CANN 軟體體系，適配的計算庫主要是神經網絡（Neural Network，NN）庫、線性代數計算庫（Basic Linear Algebra Subprograms，BLAS），這兩類庫以矩陣類運算為主，與其硬體架構相合，而其餘常規的向量計算庫，支持則並不十分完備。
儘管全面支持通用並行計算有一定困難，但如果將適用領域局限在 AI 範圍，NPU 仍然可以提供相對完善的支持，其主要原因在於大多數 AI 程序都利用了成熟的 AI 框架，如果能對 AI 框架提供足夠完善的支持，則仍然是在 AI 領域的可用選擇。當前在諸多 AI 框架中，全球使用率最高的當屬 Pytorch，隨後是 TensorFlow 等。據 AssemblyAI 等數據，當前 GitHub 新 AI 項目當中，有近 70%使用的 AI 框架是 Pytorch；在 HuggingFace 平台上最受歡迎的 30 個模型當中，有 7 個僅使用 Pytorch，23 個同時支持 Pytorch 和 TensorFlow。
從 AI 框架的使用情況可見，對於 AI 晶片的生態構建，並行計算庫的全面覆蓋並非唯一路徑，實現對 AI 框架的良好支持是另一條路徑。能夠完善支持 Pytorch、TensorFlow 等，即可滿足相當一部分 AI 需求。當前中國大陸已有 AI 晶片在此方面取得顯著進步，舉例來說，昇騰 CANN 提供 AI 框架適配器 Framework Adaptor 用於兼容 Tensorflow、Pytorch 等主流 AI 框架。華為昇騰 NPU 團隊通過長期投入適配工作，已於 2023 年 10 月 4 日的 Pytorch2.1 版本中被納入第三方設備原生支持列表，在中國大陸進度領先，有望藉此形成生態優勢並保持。
但將適配工作拆開來看，要實現 AI 框架的完善支持，其工作量仍然較大，核心工作之一就是實現算子庫的支持，各家的實際支持度不一定完全相同。所謂算子即實現特定功能的運算操作。對於通常的 AI 框架來說，其所需支持的算子數量較為龐大，因此需要大量資源和時間進行軟體支持。考慮到 Pytorch 自定義算子較多，支持的操作較為龐雜，因此我們可以在其他 AI 框架中大致了解算子庫的內容。比如 ONNX 框架，其中包含了上百種不同的計算操作，硬體開發商需在其硬體指令集的基礎上實現諸多算子，其中不乏相對複雜的算子。map、reduce 等經典的大數據處理操作、分類器常用的 OneHot 編碼、各類激活函數、超越函數等都包括在內。
參考前文 AMD 的相關歷史，ROCm 對各類算子和工具庫的初步適配經過了約 3-5 年時間，與昇騰從 2019 年發布到 2023 年獲得原生支持經過的時間類似。在這樣的資源與工作量投入下，昇騰才得以在中國大陸 NPU 晶片領域占據強勢地位，根據昇騰官網 ModelZoo 頁面顯示，其提供的神經網絡模型樣例有 200 余個，涵蓋了視覺的分割、分類、生成，語音和聲紋識別，NLP、機器翻譯、推薦系統、LLM、擴散模型、多模態模型等類型，下載量靠前的包括了 YOLO、BERT、ChatGLM、ResNet、LLaMA 等經典模型。
中國大陸廠商生態進展：或復刻 CUDA，或兼容框架
目前中國 GPU 公司均在通過不同方式對 CUDA 進行兼容，提高各類計算庫的覆蓋率，同時實現對AI框架的支持。而 AI 晶片產品由於硬體架構限制，往往不一定追求兼容CUDA，而是嘗試通過增加自行開發的方式，直接與 AI 框架進行兼容。GPU 方面，各公司的軟體生態架構、兼容 CUDA 的思路大多與 ROCm 類似。例如摩爾線程官網顯示，其自主構建了 MUSA 生態來兼容 CUDA，其生態組成與英偉達 CUDA 極為接近，基本所有組件都有與 CUDA 的對應關係，例如採用 muDNN 代替 cuDNN、muBLAS 代替 cuBLAS 等，另外自行開發 MCC 編譯器等。
根據摩爾線程官網顯示，摩爾線程兼容 CUDA 的手段與 ROCm 是基本一致的，可以通過 MUSIFY 工具將 CUDA 代碼遷移到 MUSA 平台，正如 ROCm 生態中的 Hipify；通過自行實現 MUSA-X 計算庫（類似 rocBLAS、rocFFT 等），來實現 CUDA API 的一對一替換；通過 MUSA Toolkit 來進行編譯、調用 MUSA 程序後端，實現 CUDA 代碼兼容。
但 MUSA 生態與 ROCm 的不同在於，MUSA 的大部分組件並不開源。在摩爾線程的 GitHub 官方頁面可見，其名下僅有 3 個開源庫，其中 qtbase 和 installer-framework 均與可視化界面有關，僅有 torch_musa 庫與實際的運算有關，用來兼容 Pytorch。而其中，Qt 本身屬於開源項目，Pytorch 作為基於 Python 的項目，同樣也是開源的，可見 MUSA 生態除開源社區項目外均採用閉源方式構建。這一方式的弊端在於，摩爾線程作為創業公司，其資源未必能與 AMD 等成熟大型公司相當，構建生態、形成規模效應的難度更大，在 GPU 生態的競爭中取得先發優勢也更困難。
與之類似，壁仞科技也開發了 BIRENSUPA 平台試圖兼容 CUDA，但並非開源項目，需要自行構建各類計算庫與工具，也同樣受到資源限制。
目前從結果來看，其生態構建確實也需要進一步推進。除了自身開發的 BRCC 編譯器外，還需要自行開發設備端以及主機上的各類驅動/運行時程序，以及基礎的測試和管理程序。其當前計算庫主要包含 DL 算子庫、並行計算庫、多卡通訊庫等基礎庫，應用端主要有兩大行業解決方案，分別是負責影片分析的 AutoStream 和負責廣告推薦系統的 suCTR，目前覆蓋的範圍還有限。我們認為其軟體生態覆蓋水平約與 ROCm 早期版本類似。
沐曦集成電路的 MXMACA 平台也屬於同一類型，通過自行開發 BLAS、DNN 等庫，以及自行開發 Pytorch 等框架的兼容程序，來實現與 CUDA 生態的兼容。
此外還有天數智芯等廠商也提供其 GPU 產品以及 DeepSpark 開源軟體生態，與其他 GPU 廠商一樣支持 FFT 等 HPC 負載以及 AI 框架、輔助軟體工具。
海光與上述同業企業在軟體生態領域的一個主要區別在於充分利用開源社區，且兼容現有的國際主流開源方案，這也是我們認為海光相對容易進行 CUDA 軟體生態替代的原因。從海光信息官網可見，目前海光使用的 MIOpen、RCCL、hipSPARSE 等庫都屬於國際主流開源社區，且在開源領域屬於影響力較大的方案，這極大降低了海光自身開發軟體生態的門檻。另外利用開源社區的好處在於代碼公開，用戶可以按需進行代碼更改，這對於一個尚未完善的生態而言，也具有一定的作用。
NPU 方面，寒武紀的路線與昇騰類似。寒武紀基礎軟體平台是寒武紀專門針對其雲、邊、端的智能處理器產品打造的軟體開發平台。其採用雲邊端一體、訓推一體架構，可同時支持寒武紀雲、邊、端的全系列產品。寒武紀終端 IP、邊緣端晶片、雲端晶片共享同樣的軟體接口和完備生態，可以方便地進行智能應用的開發、遷移和調優。
寒武紀訓練軟體平台支持基於主流開源框架原生分布式通信方式，同時也支持 Horovod 開源分布式通信框架，可實現從單卡到集群的分布式訓練任務（Horovod 是 Uber 開源的分布式訓練框架，可以在對單機訓練程序儘量少改動前提下進行並行訓練，支持不同的前端訓練框架和底層通信庫，包括英偉達的 NCCL 以及 Intel 的 oneCCL，此處還包括寒武紀自身的 CNCL）。支持多種網絡拓撲組織方式，並完整支持數據並行、模型並行和混合併行的訓練方法。訓練軟體平台支持豐富的圖形圖像、語音、推薦以及 NLP 訓練任務。通過底層算子庫 CNNL 和通信庫 CNCL，在實際訓練業務中達到業界領先的硬體計算效率和通信效率。同時提供模型快速遷移方法，幫助用戶快速完成現有業務模型的遷移。 MagicMind 是寒武紀全新打造的推理加速引擎，也是業界首個基於 MLIR 圖編譯技術達到商業化部署能力的推理引擎。藉助 MagicMind，用戶僅需投入極少的開發成本，即可將推理業務部署到寒武紀全系列產品上，並獲得頗具競爭力的性能。
燧原科技作為中國大陸 AI 晶片廠商也推出了自己的「馭算 TopsRider」生態框架，支持 AI 訓練和推理，並對主流 AI 框架進行了支持。
總體來說，中國算力晶片在並行計算庫、AI 框架領域都已經有所儲備，但不同廠商的具體適配進度或存在一定差別。
我們認為軟體生態是算力晶片可用性的核心，用戶的學習成本決定了市面上難以長期同時存在大量的生態（尤其是 GPU 生態），且生態存在較強的正反饋特性，容易存在強者恆強，快者恆快的現象。而開源模式能夠讓公司調動超越自身規模的資源，加速生態發展，在生態競爭中占據先機。
