开源社区最近出现了一次引人注目的跨生态尝试。开发者在 GitHub 发布了名为 CUDA-for-AMD-Windows 的项目，构建了一套基于 ZLUDA 与 AMD HIP 运行时组件的兼容环境，让 AMD 显卡在 Windows 操作系统下直接执行面向 NVIDIA CUDA 编译的程序。
这套方案以 AMD 采用 RDNA4 架构的 Radeon RX 9060 XT 作为首个也是目前唯一完成验证的硬件，在不依赖私有闭源动态链接库的前提下，成功跑通了基于 LibTorch 的强化学习算法训练。然而，这并不是普通用户期待的无痛平替。拨开测试数据可以看到，底层运行库的硬性缺失与硬件支持的代际断层，让这场看似惊艳的破冰行动依然受困于狭窄的技术死角。
跑通 221 万参数模型背后的技术破冰
这套环境搭建在 ZLUDA v6-preview.69、AMD HIP SDK 6.4 以及预编译的 LibTorch 2.3.0 基础之上。系统在目标机器上通过了底层驱动 nvcuda 以及 cuBLAS、cuBLASLt、cuSPARSE、cuFFT 等核心数学库的加载调用，意味着基本的密集矩阵计算与傅里叶变换已经被映射到 AMD 对应的 ROCm 库中。
真正的压力测试来自一个包含 2,216,347 个参数的 PPO 近端策略优化网络。测试记录显示，该网络在未经修改的代码环境下完成了前向推理、反向传播与优化器更新，单次验证顺利执行了 65,536 个时间步，其中核心的 PPO 学习计算阶段耗时 5.5658 秒。
在 2026 年 9 月 13 日开展的受控 A/B 性能测试中，项目对纯净的公开上游组件与包含自定义补丁的恢复运行时进行了 10 轮对比。在剔除首轮冷启动预热后，公开上游路径的中位数吞吐达到了 13,278.46 overall SPS，反比自定义覆盖层的 12,875.80 overall SPS 领先了 3.03%。这证明在受控的稠密计算负载下，现成的开源兼容栈已经具备相当可观的执行效率。
缺失的 MIOpen 掐断了通用 AI 场景
通过基础检查并不等于可以接管日常工作流。项目最直接的技术软肋，在于 AMD 官方分发的 Windows 版稳定 HIP SDK 至今没有包含 MIOpen 这一关键组件。
由于缺乏底层加速库对应物，NVIDIA 生态中至关重要的 cuDNN 在这一方案中直接处于不可用状态。PPO 这类强化学习模型主要依赖稠密矩阵乘法，因而能够借道 cuBLAS 跑通流程；但绝大多数计算机视觉模型、主流卷积网络以及依赖特定算子的生成扩散框架，一旦失去 cuDNN 便会立即崩溃。
用户单看项目介绍很容易产生误解，以为只要安装脚本执行成功，就能把原本属于 RTX 显卡的各种 Windows AI 软件直接搬到 Radeon 显卡上。现实则是只要涉及复杂的非标准算子或卷积结构，这套环境立刻就会停摆。
硬件断代与跨平台鸿沟
更深层次的问题在于硬件覆盖范围的断层。从设计目标来看，ZLUDA 理论上能够向下兼容到 RDNA1 架构的 RX 5000 系列显卡。但作为底层基石的 AMD 官方 Windows HIP SDK 7.2，在实际策略上却极为保守，目前官方支持列表仅涵盖 RDNA3 架构的 RX 7600 至 7900 以及 RDNA4 架构的 RX 9060 至 9070，存量庞大的 RDNA2 架构 RX 6000 系列被明确排除在外。
这就造成了一个尴尬的断层：持有旧卡的开发者无法获得官方运行时的算力支持，而拥有最新显卡的用户往往不需要如此曲折的折腾方式。
与此同时，软件版本也显示出维护脱节的迹象。该测试方案锁定的组件依然是 ZLUDA v6-preview.69。事实上，ZLUDA 官方已经在 2026 年 6 月 29 日正式发布了二进制等同于 6-preview.79 的 v6 稳定版本，并在 2026 年 8 月 26 日推进到了包含 32 位支持的 v7-preview.10 开发分支。
转译层能在夹缝里抢出几分算力，却补不齐厂商在驱动上欠下的账。
即便把目光放到跨平台工具链上，Windows 依然处于劣势。第三方 CUDA 跨平台编译工具 SCALE 1.7 尽管同样加入了对 gfx1200 硬件的支持，但官方明确表态仅支持 Linux 发行版，对 Windows 关上了大门。实际表现的差距更为悬殊：社区实测显示，同一张 RX 9060 XT 在运行 ComfyUI 的 FP8 工作流时，Windows 环境耗时达 8.80 秒，而在 Linux 原生环境下仅需 4.37 秒，耗时直接相差一倍，且 Windows 端还频繁伴随驱动重置与显存分配溢出的问题。
业余维系下的兼容孤岛
审视 ZLUDA 本身的处境，这套方案更像是一次精密而脆弱的个人工程展示。在 2026 年 6 月商业资助完全终止后，ZLUDA 已经彻底退回个人业余维护状态，依赖 MIT 与 Apache 2.0 双许可勉力支撑。
在庞大且高速演进的 CUDA 软硬件体系面前，仅仅依靠业余时间去逆向拦截 API、翻译 PTX 指令，注定只能追赶而无法比肩。面对闭源程序，转译层或许能起到应急过渡的作用，但在主流研发管线中，使用 AMD 官方提供的 HIPIFY 工具进行源码级转译，依然是业界更认可的合规路径。
- 风险.若 AMD 官方迟迟不在 Windows 版 HIP SDK 中补齐 MIOpen，任何基于 ZLUDA 的无源码平替设想，最终都只能局限在极少数模型的小圈子里。