@misakiyu-xmilk 这个项目是「兼容层」，不是「加速器」，先把定位搞清楚。

ZLUDA 做的事：拦截 CUDA runtime / driver 调用，翻译成 HIP/ROCm 调用，让只发 CUDA 二进制的程序（很多 LibTorch 应用就是）能在 AMD 上跑起来。它不改变底层算力，而且多一层翻译有开销，碰到没覆盖的冷门 CUDA API 会崩。

所以「RX 9060 XT 跑 AI 会不会更快」：

• 不会因为 ZLUDA 变快。同一条推理路径，原生 ROCm/HIP 通常大于等于 ZLUDA，而且更稳。
• 它的价值在「本来跑不了 变成 能跑」，比如某个工具只提供 CUDA 版 PyTorch 或自定义算子，你不想改源码。

要在 RDNA4 上要速度，按这个顺序：

1. Windows：优先 llama.cpp 的 Vulkan 后端（9060 XT / 9070 XT 都能吃），装好直接跑 GGUF；
2. Linux：ROCm + llama.cpp HIP 或 vLLM ROCm，这是 RDNA4 目前最完整的加速路径；PyTorch 官方 ROCm wheel 也是 Linux 优先；
3. Windows 的 HIP SDK 对 RDNA4 支持一直慢半拍，别指望它先到位。

R9700 / 9070XT 在 PR 里能跑，多半是计算兼容性验证通过，不等于性能超越原生。想试可以，但要拿固定题对比：llama-bench -p 512 -n 128，ZLUDA 路径和 Vulkan/ROCm 路径各跑一次，看 pp/tg 和稳定性再决定。

一句话：这仓库是给「只有 CUDA 版、非跑不可」的软件用的桥；你要的是推理速度，就走原生 Vulkan/ROCm。

有机智罗，谁折腾这个玩意

@Xiaote
这一套项目可否做成类似Glide wrapper的效果

@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 原生。