ROCm 是什麼：AMD 版的 CUDA 生態入門觀念

只要研究過 GPU 運算，一定聽過一句話：NVIDIA 真正的護城河不是晶片，是 CUDA。十幾年累積的軟體生態，讓每個想跑深度學習的人自然而然買它的卡。那 AMD 的卡呢？程式要怎麼寫、框架接不接得上？

答案就是 ROCm。這一篇不背術語表，而是用你可能已經熟悉的 CUDA 當對照組，一層一層看懂 ROCm 是什麼、HIP 扮演什麼角色、既有程式怎麼搬家，以及 PyTorch 使用者實際上會遇到什麼。

先講定位：ROCm 補的是「軟體」這塊拼圖

GPU 硬體的規格表再漂亮，開發者的第一個問題永遠是：我的程式跑得起來嗎？NVIDIA 用 CUDA 回答了這題十幾年，累積出函式庫、工具、教學與人才的完整生態。

ROCm 就是 AMD 對同一題的回答：一套開放原始碼的 GPU 運算軟體堆疊，官方定義是「為 AMD GPU 提供程式開發所需的一切」，包含執行環境、編譯器、效能與系統工具，以及最佳化過的數學與運算函式庫。

名字順便記一下：ROCm 是 Radeon Open Compute 的縮寫，重點在 Open 這個字。整個堆疊的程式碼是公開的，這是它與 CUDA 在商業路線上最根本的分歧。

用 CUDA 對照著看：一層一層都有對應

理解 ROCm 最快的方法，是把你認識的 CUDA 生態逐層拿來對照。從上到下：框架層兩邊共用 PyTorch 這些開源框架；函式庫層各有一套；程式介面層是 CUDA C++ 對上 HIP；最底下是各自的驅動與執行環境。

函式庫層的對應關係值得背下來，看文件時會一直用到：做線性代數的 rocBLAS 對應 cuBLAS，深度學習基元的 MIOpen 對應 cuDNN，多卡通訊的 RCCL 對應 NCCL。另外還有 rocFFT、rocSPARSE 這些數學函式庫，以及 ROCgdb 與 ROCprofiler 這類除錯與效能分析工具。

HIP 與 HIPIFY：從 CUDA 搬家的那條路

生態後進者最大的難題是存量：世界上已經有海量的 CUDA 程式碼，不可能要求大家重寫。AMD 的解法是把程式介面設計成「可轉換」的：HIP 的 API 與 CUDA 高度相似，多數函式幾乎是把 cuda 前綴換成 hip 前綴。

而且不必手動換。官方的 HIPIFY 工具可以掃描 CUDA 原始碼，自動轉換成 HIP 寫法；轉完的程式碼在 AMD 平台走 ROCm 執行，在 NVIDIA 平台仍可對接 CUDA 執行，等於一份程式碼保留了兩邊的退路。

當然，自動轉換不是魔法。用到 CUDA 專屬進階特性的程式、手工調到極致的核心，轉換後仍需要人工檢查與調校。合理的期待是：HIPIFY 把搬家成本從「重寫」降到「校對」，而不是零成本。

PyTorch 使用者的視角：幾乎無感，但有三個坑

好消息是，做應用的人多數碰不到上面那些層。ROCm 官方支援 PyTorch 與 JAX，推論引擎支援 vLLM 與 SGLang；裝好 ROCm 版的 PyTorch，模型程式碼照舊執行。

更有趣的是，ROCm 版 PyTorch 刻意保留了 cuda 這個裝置名稱：torch.cuda.is_available() 在 AMD GPU 上回傳 True，to('cuda') 照用。這是務實的取捨，為的是讓既有程式碼一行都不用改。

• 坑一：裝錯套件。預設管道裝到的 PyTorch 是 CUDA 版，要照官方指示指定 ROCm 版本的安裝來源。
• 坑二：硬體不在支援清單。ROCm 優先支援 Instinct 加速器，消費級 Radeon 只有部分型號支援，動手前先查官方相容性矩陣。
• 坑三：第三方擴充。直接用 CUDA 專屬 API 寫成的自訂擴充套件無法直接執行，要找 ROCm 對應版本或等社群移植。

現實面：開放是路線，成熟度要自己驗證

把 ROCm 講成「CUDA 的完全替代品」是不誠實的。CUDA 生態的深度與廣度仍然領先，ROCm 的支援清單、平台涵蓋與社群資源都還在追趕，Linux 是它的主場，Windows 的支援範圍相對有限。

但方向值得注意：開放原始碼讓雲端業者與大型客戶能自己讀碼、自己修、自己整合，主流框架的官方支援也一版比一版完整。評估的正確姿勢不是問「ROCm 好不好」，而是問「我要跑的那套軟體，在支援清單上嗎」，然後小規模實測。