AMD 軟體生態
破除 CUDA 壁壘：ROCm 與主流框架的適配進度
破除 CUDA 壁壘：ROCm 與主流框架的適配進度
站上另一篇談 ROCm 基礎的文章，講的是 ROCm 是什麼、怎麼裝、基本觀念。這篇不重複那些內容，直接跳到 2026 年當下，主流框架與推論引擎跟 ROCm 的整合現況。
對演算法工程師與 MLOps 團隊來說，真正該問的問題從來不是「ROCm 能不能跑」，而是「我常用的框架跟推論引擎，現在被支援到什麼程度」。
你將學到什麼
從相容到官方支援
PyTorch 已把 ROCm 列為正式支援的後端，不必再另外找特殊分支或自行編譯。
推論引擎不只是移植
vLLM、SGLang 為 AMD 加速器另外設計了專屬的運算路徑，而不只是讓程式碼跑得起來。
生態系已經有厚度
JAX、Triton 到 Ollama、llama.cpp，主流工具鏈陸續補齊 ROCm 版本。
導入前要先驗證
框架支援進度更新很快，團隊導入前務必用自己的模型與流程實測，不要只看名詞清單。
「能不能在 AMD 硬體上跑我的模型」這個問題，答案已經從勉強可以，變成官方支援，而且有人專門為它做優化。
這篇要回答的問題，跟入門文不一樣
站上另一篇談 ROCm 基礎的文章，講的是 ROCm 是什麼、怎麼裝、基本觀念。這篇不重複那些內容，直接跳到主流框架與推論引擎跟 ROCm 的整合現況。
對演算法工程師與 MLOps 團隊來說，真正該問的問題從來不是「ROCm 能不能跑」，而是「我常用的框架跟推論引擎，現在被支援到什麼程度」。
PyTorch：從相容分支到官方後端
PyTorch 官方已經把 ROCm 列為正式支援的運算後端之一，標準安裝流程就能指定對應的套件來源，不必再仰賴社群維護的特殊分支或自行編譯。
這件事的意義不只是省了安裝步驟，而是代表 ROCm 的相容性測試已經進到 PyTorch 官方自己的驗證流程裡，版本更新時會一併考慮 ROCm 這條路徑。
官方支援的 PyTorch 與 ROCm 版本組合會持續更新，團隊導入前務必查當期的官方相容性頁面，不要沿用舊文章裡的版本號。
推論引擎：vLLM 與 SGLang 在 AMD 硬體上的位置
高併發推論引擎過去在 AMD 硬體上，常常只是把既有的程式碼搬過去，能跑就算過關。
這個階段已經過去。vLLM 官方部落格描述，目前的做法是針對不同世代的 AMD 加速器架構，分別設計專屬的注意力運算路徑，並由 AMD 工程團隊參與核心層級的優化。
SGLang 走的是類似的路線。這代表這兩套目前最主流的高併發推論引擎，都把 AMD 硬體當成需要專門優化的第一線平台，而不是次要的相容選項。另外像 MoRI 這類框架，則進一步鎖定跨節點的分散式推論場景。
整條軟體堆疊：從框架到硬體，中間隔了幾層
評估「支援進度」的時候，很容易只看框架這一層，忽略中間其實隔了好幾層，每一層都要各自成熟，整條路才算真的通。
| 層級 | 扮演的角色 | 常見例子 |
|---|---|---|
| 訓練框架 | 定義模型結構與訓練迴圈，工程師日常打交道的第一層。 | PyTorch、JAX |
| 推論引擎 | 負責服務化、批次調度與記憶體管理，決定線上推論的吞吐與延遲。 | vLLM、SGLang |
| 硬體抽象層 | 把上層框架的呼叫翻譯成加速器看得懂的指令，是可攜性的關鍵。 | ROCm |
| 加速器硬體 | 實際執行運算的地方。 | AMD Instinct 系列 |
這也是為什麼「框架支援 ROCm」不能直接等於「我的服務會跑得順」。任何一層沒跟上，體感都是變慢或不穩定，評估的時候要一層一層看，不能只看最上面那一層打勾。
生態系的其他角色
- JAX：另一個官方支援的深度學習框架，適合已經用 JAX 生態工作的團隊。
- Triton：用來寫自訂運算核心的工具鏈，在 ROCm 上也有對應支援。
- Ollama、llama.cpp：面向個人開發者與輕量部署的推論工具，陸續推出 ROCm 版本。
MLOps 導入前的實務檢查清單
- 先查 ROCm 官方文件的相容性矩陣，確認目前用的框架與版本組合是否在支援清單內。
- 用自己實際的模型與推論流程做一輪驗證，不要只看框架名稱有沒有出現在支援清單。
- 分階段導入，先從影響範圍小的服務開始，確認穩定後再擴大。
- 把相容性檢查排進例行維運，而不是導入當下查一次就結束。
