【2026 最新】AMD Windows 跑 CUDA：ZLUDA＋HIP 6.4 安裝、3 關驗收與回滾

AMD Windows 跑 CUDA不是把 Radeon 變成 NVIDIA GPU，而是讓 ZLUDA 把「部分 CUDA 介面呼叫」轉到 AMD 的 HIP／ROCm 函式庫。2026 年真正可重現的答案很窄：目前這個新專案只在作者的 RX 9060 XT（gfx1200）上，以 ZLUDA v6-preview.69、HIP SDK 6.4 與 LibTorch 2.3.0+cu118 完成過一個 PPO workload。你的卡被偵測到、甚至 cuda_check 亮綠燈，都還不等於你的程式能用。

這篇不會把那一台電腦的結果外推成 RX 6000／7000／9000 相容表。你會先判斷是否根本該用 ZLUDA，再用固定 commit、乾淨沙盒、三層驗收與可丟棄副本完成測試；失敗時，也能留下足以幫助下一個人的最小報告。

AMD Windows 跑 CUDA，先分清楚三條路

先問「程式吃什麼後端」，不要先問「哪個比較快」。如果你有原始碼，或應用已提供 AMD 後端，優先走原生 HIP／ROCm；如果是可轉成 ONNX 的推論，優先評估 Windows ML；只有程式是 Windows 上的 CUDA-only 二進位檔、又沒有原生 AMD 路徑時，ZLUDA 才是合理的相容層實驗。

路線 A：應用已支援 AMD，走當代原生路徑

截至 2026 年 9 月，AMD 的 ROCm 10.0 相容矩陣已列出 Windows 元件與 MIOpen 3.6.0；另一份 Radeon Windows PyTorch 矩陣則列出特定 GPU 搭配 PyTorch 2.9／ROCm 7.2.1，同頁也明說整套 ROCm 尚未在 Windows 全面支援。這兩份表都比本文的 HIP 6.4 實驗新。若你的精確 SKU、Windows、driver、framework 版本都在當期表內，而且應用已有原生後端，就不該為了保留「CUDA」三個字而繞進 ZLUDA。

路線 B：ONNX 推論，走 Windows ML

Microsoft 已把 DirectML 放在 sustained engineering，主要新功能轉向 Windows ML。若任務是 ONNX 推論與跨硬體部署，先看官方 DirectML／Windows ML 選路說明。它不是 CUDA 相容層，也不會替 CUDA custom node 自動改寫算子。

路線 C：只有 CUDA 二進位檔，才測 ZLUDA

本文採用的固定專案快照，價值在於把下載、雜湊、GPU 掃描與 cuda_check 串成同一個可追蹤流程；它不是 ZLUDA 的新發明，也不是正式發行版。專案主分支目前只公開驗證 RX 9060 XT／gfx1200，其他架構只是 scanner candidate。

安裝前：先建立可回滾的實驗邊界

ZLUDA 的 staging 腳本會用 Copy-Item -Force 把相容 DLL 複製到目標程式旁，沒有備份，也沒有留下「哪些檔案被覆寫」的 manifest。最可靠的回滾不是事後猜哪些 DLL 能刪，而是一開始就只對完整複製的應用資料夾動手。

1. 更新重要檔案備份；若要建立 Windows 還原點，記得它不能取代應用資料夾副本。
2. 用檔案總管完整複製目標程式，例如從 C:\Apps\TargetApp 複製到 C:\ZLUDA-Sandbox\TargetApp。
3. 若電腦同時有 iGPU 與 dGPU，先停下來確認應用實際選到哪張卡。此快照的 -GpuIndex 只影響掃描報告，不會替 runtime 設定可見裝置。
4. 不要把 token、密碼或私密路徑放進命令列；launcher 會把完整參數印在 console。

這個快照的測試腳本使用較新的 .NET API，而 CI 以 PowerShell 7（pwsh）解析，沒有在 stock Windows PowerShell 5.1 上執行 GPU 測試。本文因此以 PowerShell 7 為前提。先開新的 PowerShell 7 視窗：

$PSVersionTable.PSVersion
Get-CimInstance Win32_VideoController |
  Select-Object Name, DriverVersion

接著到 AMD 當期硬體表核對精確 SKU。官方支援、專案曾測、你的 workload 能跑，是三個不同欄位；不要把 RX 7900 XTX 的結果抄給 RX 7900 XT，也不要把 gfx 相同當成應用相容證明。若你還不熟悉顯存與模型大小的關係，可先讀本地 AI 顯存需求指南。

AMD Windows 跑 CUDA：固定 HIP 6.4 與 repo commit

這裡刻意重現作者的舊版參考組合，而不是追最新：ZLUDA v6-preview.69、AMD HIP SDK 6.4、選配 LibTorch 2.3.0+cu118。請從 AMD 封存的 HIP SDK 6.4.2 文件安裝 HIP SDK 與 HIP Libraries。安裝器中的 Factory Reset 會移除既有版本，AMD 文件也說這會失去 rollback；為了本實驗，不要勾選它。

建立全新 clone，並 detach 到本文查核的 commit。先看腳本中的下載位置與預期雜湊，再允許本次 PowerShell process 執行：

git clone https://github.com/Speedstu/CUDA-for-AMD-Windows.git
Set-Location .\CUDA-for-AMD-Windows
git checkout --detach a2ea12bed0e2bf488ed71ac28a57474a6d997448
git rev-parse HEAD

Select-String -Path .\scripts\setup.ps1 `
  -Pattern 'zludaUrl|expectedZluda|expectedTorch'

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

本文查核到 ZLUDA 資產大小 32,944,552 bytes，SHA-256 為 E2959ED17C8DDAE6BF2BF76CF3A7348F577A2548754685D776389DF2220E5D9A；專案腳本也期待 LibTorch 壓縮檔的 SHA-256 為 E7D57EE5052996E1A9AAEAD5ECC3C491BA7C0DB21316FB1FA8A4A8136005C6CC。腳本只在首次下載時驗雜湊；因此要用乾淨 clone／空的 .runtime，不要沿用來源不明的解壓目錄。

先跳過 2.66 GB LibTorch，驗證最小 runtime

明確指定 HIP 6.4 路徑很重要：若不指定，腳本可能選到機器上數字最大的 HIP 目錄，讓「同一篇教學」變成另一個 stack。

$Hip64 = 'C:\Program Files\AMD\ROCm\6.4'

.\scripts\doctor.ps1 -HipRoot $Hip64 -Strict
.\scripts\install.ps1 -HipRoot $Hip64 -SkipLibTorch

只有前面通過、而且你真的要驗 CUDA 版 LibTorch 時，才在同一個乾淨參考環境省略 -SkipLibTorch。下載約 2.66 GB，解壓後占用會更大：

.\scripts\install.ps1 -HipRoot $Hip64

讀懂三份報告，不把 READY 當成支援

安裝器會在 .runtime 下生成三份 JSON。用下面命令讀取，而不是只看 console 最後一行：

Get-Content .\.runtime\gpu-report.json -Raw | ConvertFrom-Json
Get-Content .\.runtime\runtime-config.json -Raw | ConvertFrom-Json
Get-Content .\.runtime\runtime-test.json -Raw | ConvertFrom-Json

• gpu-report.json：確認 GPU 名稱、gfx、driver、HIP 路徑與專案狀態。這裡的 HIP version 只是資料夾名稱，不是從 binary 讀出的版本。
• runtime-config.json：確認 hip_root 真的是 6.4、ZLUDA 是 v6-preview.69、沒有啟用來源不完整的 custom overlay。
• runtime-test.json：除了 core_ok，還要同時看到 timed_out: false 與 process_exit: 0。目前腳本可能在解析到 OK 行後，即使稍後 timeout／非零退出仍留下 core_ok: true。

五組 smoke test 各自證明什麼

test-runtime.ps1 會以 ZLUDA 的 cuda_check.exe 檢查 nvcuda、cuBLAS、cuBLASLt、cuSPARSE 與 cuFFT，cuDNN 8／9 則另列 optional。這只證明在該機器上能載入／初始化一小段介面。ZLUDA 的一個 RX 7900 XTX 問題回報就呈現過 cuFFT probe 通過、實際 torch.fft 仍遇到 unsupported 的情況。

HIP SDK 6.4 這條 legacy 路徑不含 MIOpen，因此 cuDNN 不通不意外；但不能把這句外推成「2026 年 Windows ROCm 都沒有 MIOpen」。如果目標 app 強依賴 convolution／cuDNN，這個固定 profile 就在此判定不合格，回到上面的原生 ROCm 路線，而不是把 ROCm 10、nightly 與 HIP 6.4 DLL 混成第四種環境。

最後一關：用你的真實 workload 驗收

專案文件記錄作者的一個 2,216,347 參數 CUDA 版 LibTorch PPO workload 完成 inference、learning、optimizer 與 65,536 timesteps；但 repo 沒附 trainer 原始碼、執行命令、driver build 或完整機器報告。這是「作者在單一 workload 成功」的邊界證據，不是你能一鍵重播的 benchmark。

請改用你原本想執行的 app，對沙盒副本測試。從獨立的 PowerShell 7 子程序啟動，避免腳本末尾的 exit 關掉你正在工作的 shell：

pwsh -NoProfile -ExecutionPolicy Bypass `
  -File .\scripts\run-zluda.ps1 `
  -Program 'C:\ZLUDA-Sandbox\TargetApp\app.exe'

驗收至少要包含一個實際輸入、完整 forward／輸出，以及你的使用情境真正需要的步驟：若是訓練，就要走完 backward、optimizer step 並檢查 loss 是否有限；若是圖片，就比較固定 seed 的輸出是否在可接受容差內；若是 custom node，就必須逐 node 測，不可用 ComfyUI 首頁能開啟代替。

若要比較 native HIP、Windows ML、ZLUDA

本文沒有適合的 Windows AMD 實機，也沒有同版本、同模型、同算子的公開三後端原始紀錄，所以不刊登速度或顯存勝負。你可以用同輸入 parity A/B 方法自測：固定模型、權重、輸入、batch、dtype、seed 與輸出容差；每條路暖機 1 次，再量 5 次，記錄成功次數、中央値、峰值顯存與需要維護的 patch。若 ONNX 轉換或 HIP port 已改變算子，就只能比較「同任務結果」，不能寫成同一 binary 的純後端速度 A/B。

失敗怎麼讀：停在最早壞掉的一層

• doctor 找不到 HIP：先修 driver／HIP SDK／明確路徑，不要進入 ZLUDA。
• GPU model 有、gfx 不明：WMI fallback 不是執行證據；檢查 hipInfo.exe 與官方 SKU 表。
• nvcuda 失敗：先檢查 ZLUDA、HIP path 與 DLL 載入順序。
• BLAS／sparse／FFT 任一失敗：核心 profile 不合格；不要靠「程式似乎能開」繼續。
• 只有 cuDNN 失敗：先確認目標 workload 是否真的需要；需要就淘汰這個 HIP 6.4 profile。
• custom PTX、TensorRT、NCCL、Triton 或 extension 出錯：這些都超出該專案目前的一般化證據。保留第一個有效錯誤，停止堆疊隨機 DLL。
• 啟動後 hard crash／輸出異常：runtime probe 通過也不算成功；回到真實 workload 與數值容差。

匯出不洩漏隱私的失敗回報

重新產生 scanner 與 runtime 報告：

.\scripts\gpu-scan.ps1 -HipRoot $Hip64 `
  -OutputPath .\.runtime\gpu-report.json
.\scripts\test-runtime.ps1

上傳前逐行檢查 gpu-report.json、runtime-config.json 與 runtime-test.json。它們會含絕對路徑與完整 stdout／stderr；stdout 也可能帶入 app 參數。最小回報只需：精確 GPU、gfx、Windows build、driver、HIP／ZLUDA／app 版本、結果分類、可重現命令、第一個有效錯誤，以及哪一層最後通過。刪除使用者名稱、token、帳戶路徑與無關檔名後，再交到專案的 GPU compatibility issue 表單。成功與失敗都要回報，否則相容矩陣只會留下倖存者偏差。

完整回滾：丟棄副本，不猜 DLL

1. 關閉目標程式與獨立 PowerShell 子程序。
2. 先用 Resolve-Path 'C:\ZLUDA-Sandbox' 人工確認範圍，再以檔案總管刪除整個沙盒副本；不要在原始 app 目錄逐個猜 DLL。
3. 刪除這次新 clone，即可一併移除 .runtime、下載壓縮檔與展開檔。標準 launcher 設定的環境變數只存在於該 process。
4. 若 HIP SDK 6.4 只為這次測試安裝，從 Windows「設定 → 應用程式 → 已安裝的應用程式」移除精確版本；不要用 Factory Reset。
5. 重新開啟原始 app，以原本固定輸入做一次 baseline，確認回到實驗前狀態。

常見問題 FAQ

1. ZLUDA 會讓 AMD 原生支援 CUDA 嗎？

不會。它是把部分 CUDA-facing 呼叫轉到 AMD HIP／ROCm 函式庫的相容層；完整度由實際 API、library 與 workload 決定。

2. RX 6000、7000 或 9000 系列能照做嗎？

不能用系列名稱回答。先查 AMD 當期表中的精確 SKU，再看此專案證據；目前 main 只把 RX 9060 XT／gfx1200 列為 validated reference。scanner 認得架構不等於支援。

3. 可以直接把 HIP 6.4 換成 ROCm 10 嗎？

不能把結果沿用。那會成為新的 stack，必須從硬體表、library probe 到真實 workload 全部重測。若 app 已有當代原生 ROCm 路線，直接走官方安裝通常更合理。

4. cuda_check 全過就代表 app 支援嗎？

不代表。它是小型載入／初始化 probe；真實 app 可能呼叫 probe 沒覆蓋的 FFT、PTX、extension 或 shape。

5. cuDNN 失敗還能跑 AI 嗎？

有些 dense／GEMM-heavy workload 不依賴 cuDNN，作者的 PPO 紀錄就是一例；卷積、VAE 或特定模型則可能直接卡住。由你的算子需求判斷，不能用「AI」兩字概括。

6. ComfyUI 開得起來，custom nodes 就都能用嗎？

不是。每個 node 可能另帶 Triton、xformers、custom CUDA／PTX、attention wheel 或 ONNX execution provider，必須逐一跑實際 workflow 驗收。

7. ZLUDA_CC=8.6 是我的 Radeon gfx 嗎？

不是。8.6 是 CUDA-facing compatibility value；AMD 架構則是 gfx1200 這類命名，兩者不能互換。

8. ZLUDA、Windows ML、原生 ROCm 哪個最快？

沒有跨模型通用答案。算子 coverage、dtype、attention、顯存是否溢出、版本與暖機都會改變結果；先以同輸入驗證成功與正確，再談中位時間。

把一次成功，升級成可維護的 AI 實驗

真正能長期複製的不是一串安裝命令，而是「版本 pin、baseline、驗收門檻、失敗紀錄、回滾」五件事。想把這套方法延伸到模型選型與推論系統，可到 AlphaLab 課程建立完整學習路徑；也可先理解推論引擎如何拆分模型與 runtime，避免把框架名稱當成硬體相容保證。