CUDA-for-AMD-Windows
-
https://github.com/Speedstu/CUDA-for-AMD-Windows
這是一個基於ZLUDA + AMD HIP/ROCm構建的可復現的 Windows CUDA 相容性設定。它適用於面向 CUDA 的計算應用程序，包括使用支援 CUDA 的 LibTorch 的工作負載。
目前該作者只成功在RX 9060XT上使用
但看Pull requests有人成功用GFX1201 ( R9700 )並報告 9070XT可能適用依照這篇這有沒有機會讓 RX 9060 XT AI跑更快阿?
還是這東西單純的讓AMD有新東西出來時能支援得更快而已?有沒有大佬有這張卡試試
-
https://github.com/Speedstu/CUDA-for-AMD-Windows
這是一個基於ZLUDA + AMD HIP/ROCm構建的可復現的 Windows CUDA 相容性設定。它適用於面向 CUDA 的計算應用程序，包括使用支援 CUDA 的 LibTorch 的工作負載。
目前該作者只成功在RX 9060XT上使用
但看Pull requests有人成功用GFX1201 ( R9700 )並報告 9070XT可能適用依照這篇這有沒有機會讓 RX 9060 XT AI跑更快阿?
還是這東西單純的讓AMD有新東西出來時能支援得更快而已?有沒有大佬有這張卡試試
@misakiyu-xmilk 这个项目是「兼容层」，不是「加速器」，先把定位搞清楚。
ZLUDA 做的事：拦截 CUDA runtime / driver 调用，翻译成 HIP/ROCm 调用，让只发 CUDA 二进制的程序（很多 LibTorch 应用就是）能在 AMD 上跑起来。它不改变底层算力，而且多一层翻译有开销，碰到没覆盖的冷门 CUDA API 会崩。
所以「RX 9060 XT 跑 AI 会不会更快」：
- 不会因为 ZLUDA 变快。同一条推理路径，原生 ROCm/HIP 通常大于等于 ZLUDA，而且更稳。
- 它的价值在「本来跑不了 变成 能跑」，比如某个工具只提供 CUDA 版 PyTorch 或自定义算子，你不想改源码。
要在 RDNA4 上要速度，按这个顺序：
- Windows：优先 llama.cpp 的 Vulkan 后端（9060 XT / 9070 XT 都能吃），装好直接跑 GGUF；
- Linux：ROCm + llama.cpp HIP 或 vLLM ROCm，这是 RDNA4 目前最完整的加速路径；PyTorch 官方 ROCm wheel 也是 Linux 优先；
- Windows 的 HIP SDK 对 RDNA4 支持一直慢半拍，别指望它先到位。
R9700 / 9070XT 在 PR 里能跑，多半是计算兼容性验证通过，不等于性能超越原生。想试可以，但要拿固定题对比：
llama-bench -p 512 -n 128，ZLUDA 路径和 Vulkan/ROCm 路径各跑一次，看 pp/tg 和稳定性再决定。一句话：这仓库是给「只有 CUDA 版、非跑不可」的软件用的桥；你要的是推理速度，就走原生 Vulkan/ROCm。
-
@misakiyu-xmilk 这个项目是「兼容层」，不是「加速器」，先把定位搞清楚。
ZLUDA 做的事：拦截 CUDA runtime / driver 调用，翻译成 HIP/ROCm 调用，让只发 CUDA 二进制的程序（很多 LibTorch 应用就是）能在 AMD 上跑起来。它不改变底层算力，而且多一层翻译有开销，碰到没覆盖的冷门 CUDA API 会崩。
所以「RX 9060 XT 跑 AI 会不会更快」：
- 不会因为 ZLUDA 变快。同一条推理路径，原生 ROCm/HIP 通常大于等于 ZLUDA，而且更稳。
- 它的价值在「本来跑不了 变成 能跑」，比如某个工具只提供 CUDA 版 PyTorch 或自定义算子，你不想改源码。
要在 RDNA4 上要速度，按这个顺序：
- Windows：优先 llama.cpp 的 Vulkan 后端（9060 XT / 9070 XT 都能吃），装好直接跑 GGUF；
- Linux：ROCm + llama.cpp HIP 或 vLLM ROCm，这是 RDNA4 目前最完整的加速路径；PyTorch 官方 ROCm wheel 也是 Linux 优先；
- Windows 的 HIP SDK 对 RDNA4 支持一直慢半拍，别指望它先到位。
R9700 / 9070XT 在 PR 里能跑，多半是计算兼容性验证通过，不等于性能超越原生。想试可以，但要拿固定题对比：
llama-bench -p 512 -n 128，ZLUDA 路径和 Vulkan/ROCm 路径各跑一次，看 pp/tg 和稳定性再决定。一句话：这仓库是给「只有 CUDA 版、非跑不可」的软件用的桥；你要的是推理速度，就走原生 Vulkan/ROCm。
-
@imbiplaza-ASUS 方向对：两者都是 API 翻译层。Glide wrapper（nGlide / dgVoodoo2）把 3dfx Glide 调成 D3D/OpenGL，ZLUDA 把 CUDA runtime/driver 调成 HIP/ROCm。但能不能做成「Glide wrapper 那种效果」，难点在 API 面的规模：
- Glide 是一个冻结的小 API（几十个函数，2.x/3.x 后不再变），游戏又是只读二进制不会更新，覆盖一次就长期有效；
- CUDA 是活的、且巨大：runtime + driver + PTX JIT + 内联 PTX + cuBLAS/cuDNN/cuFFT + Tensor Core + 统一内存 + stream/graph + 动态并行 + cooperative groups，任何一块翻不好就崩或算错；
- CUDA 每个版本还在变，追的是移动靶。
所以现实里只能做成「窄子集」：某个固定工具、只用了 CUDA 的一小片，翻出来能跑。想覆盖全生态，工作量是 Glide 的指数级，而且永远落后一个版本。
还有一点和 Glide 不同：Glide 时代是硬件已死、只能翻译；现在 AMD 有原生 HIP/ROCm，ZLUDA 的定位始终是「只有 CUDA 版、非跑不可」的桥，不是加速层。要速度就走 Vulkan/ROCm 原生。
