AMD 在 Windows 上运行 CUDA 已可实现，但仅限于一条狭窄的兼容路径
尽管 CUDA 仍是 NVIDIA 的平台，AMD 用户如今已有一套可复现的 Windows 上 AMD 运行 CUDA 的配置方案。该社区项目通过 ZLUDA 转译部分 CUDA 调用，再通过 AMD 的 HIP 库执行。其创建者表示，已在 Radeon RX 9060 XT 上完成一项 AI 训练工作负载。
这项成果之所以重要，是因为它跨越了一道艰难的界限。开发者可以从一款为 NVIDIA 软件栈构建的 Windows 应用开始，并在一种受支持的 AMD 配置上运行它，而无需先将该应用重写为 HIP。
不过，这一结果并未让 CUDA 摆脱硬件绑定。该方案依赖兼容层、固定的软件版本以及尚不完整的库替代方案。目前，项目中只有一个 GPU 型号处于已验证状态。
因此，真正的竞争并不只是 AMD 与 NVIDIA 硬件之间的较量，而是现有 CUDA 应用的兼容性与原生厂商支持可靠性之间的权衡。这套新方案推进了前者，但尚未实现后者。
该项目将 CUDA 二进制程序转化为 AMD 工作负载
关键变化在于：它提供了一条从面向 CUDA 的 Windows 应用到 AMD GPU 的文档化、可重复执行路径。
这个开源兼容性项目整合了安装、运行时部署、诊断和验证脚本。它建立在 ZLUDA 与 AMD 的 Windows HIP 软件之上，而非从头实现另一套 GPU 运行时。
ZLUDA 是一个向应用呈现 CUDA 兼容接口的转译层。它会将受支持的操作重定向到宿主 GPU 软件栈中可用的对应函数。
HIP，即异构计算可移植接口（Heterogeneous-compute Interface for Portability），是 AMD 面向可移植 GPU 软件提供的 C++ 运行时与内核语言。在该方案中，HIP 构成最终与 Radeon GPU 通信的底层。
这条路径始于一个预期使用 NVIDIA CUDA 组件的 Windows 程序。ZLUDA 接收这些调用，并将受支持的库操作路由至 AMD 的等效实现。
例如，cuBLAS 操作可到达 rocBLAS，而 cuSPARSE 调用可到达 rocSPARSE。这些库处理常见的线性代数和稀疏矩阵工作负载。
该仓库包含一个 PowerShell 安装程序，用于检查检测到的 GPU、驱动程序、HIP SDK 以及所需数学库。随后，它会下载固定版本的 ZLUDA 构建，并通过 SHA-256 哈希验证下载文件。
安装程序还可以获取为 CUDA 11.8 构建的 LibTorch 2.3.0。LibTorch 是 PyTorch 的 C++ 发行版，适用于应用在不使用 Python 运行时的情况下嵌入 PyTorch 功能。
根据该仓库的信息，这一下载约为 2.66 GB。不需要 LibTorch 的用户可以跳过它。
安装完成后，脚本会生成机器特定的运行时和 GPU 报告。另一项诊断会针对已安装的 AMD 软件栈运行 ZLUDA 的 cuda_check 工具。
启动应用需要使用该项目的包装脚本。它会将必要的兼容库放置在目标可执行文件旁，并为该进程配置 HIP 运行时路径。
这种本地部署模式限制了系统范围的改动，但也暴露出一个核心弱点：每个应用仍取决于 ZLUDA 能够转译的确切 CUDA 函数和库。
项目报告称，CUDA 驱动接口、cuBLAS、cuBLASLt、cuSPARSE 和 cuFFT 均已成功通过检查。这些结果仅适用于其经过验证的机器和软件组合。
它们并不能证明 Windows 应用具有普遍兼容性。一个程序可能通过基础运行时检查，却在后续不同工作负载中调用不受支持的函数。
该仓库指出，只有由 AMD gfx1200 目标标识的 Radeon RX 9060 XT 具有已验证参考状态。其他检测到的 Radeon 架构仍属于未经验证的候选对象。
这一措辞非常重要。检测到设备仅表示脚本识别了该设备及其架构，并不意味着应用、转译层和库能够协同工作。
为什么此时 Windows 上的 AMD CUDA 方案值得关注
该项目着力解决的是 CUDA 应用周边的迁移成本，而非改变 CUDA 的归属或削弱 NVIDIA 的硬件优势。
CUDA 是 NVIDIA 的并行计算平台与编程模型。其编程模型涵盖内核执行、内存管理、同步，以及针对 NVIDIA GPU 优化的库。
许多应用依赖的不只是带有 CUDA 风格的源代码。它们还会调用 cuBLAS、cuFFT、cuSPARSE 和 cuDNN 等库，并依赖特定的运行时行为。
这些累积的软件资产形成了转换成本。购买另一款 GPU，并不会自动让面向 CUDA 的 Windows 程序具备可移植性。
开发者通常有三种广泛选择：继续使用 NVIDIA 硬件，将程序移植到其他接口，或在应用与硬件之间加入转译层。
AMD 通过 HIP 支持移植路线。其HIPIFY 工具可将许多 CUDA 源代码结构转换为可移植的 HIP C++。
当开发者掌控应用时，源代码转换可以是合理的长期选择。但它同样需要测试、维护，有时还需针对不受支持的 API 手动修改。
对于手中只有已编译 Windows 二进制程序的用户，这条路线帮助有限。对于维护 CUDA 专用依赖的小型团队，它也会带来额外工作。
ZLUDA 正是针对这一空白。它试图保留应用所预期的面向 CUDA 的接口，同时在运行时转译操作。
这种方式更像一座兼容性桥梁，而不是新的编程标准。应用继续使用 CUDA，而桥梁会将受支持的请求映射到 AMD 的软件栈。
Windows 使这个问题格外具有现实意义。AMD 已在该平台扩展 GPU 计算支持，但其 Windows 软件栈历来提供的组件少于 Linux 上的 ROCm。
AMD 将Windows HIP SDK描述为更广泛 ROCm 平台的一个子集。其支持矩阵同样将官方支持限制于列出的操作系统和 GPU。
近期 ROCm 版本改善了原生 Windows 选择，包括在指定 Radeon 硬件上支持 PyTorch。当应用本身已提供 AMD 路径时，原生支持可降低对转译的需求。
然而，原生 PyTorch 支持并不能解决所有 CUDA 依赖。一个 Windows 应用可能捆绑了 CUDA 专用的 LibTorch 构建，或直接加载 NVIDIA 库。
这个新仓库处理的正是这种不那么方便的情况。其公开说明的动机，是让一款面向 CUDA 的 LibTorch 训练应用能在 AMD 桌面 GPU 上运行。
项目称，其测试应用完成了推理、强化学习更新和优化器工作。该网络包含 2,216,347 个参数，并运行了一次覆盖 65,536 个时间步的验证迭代。
这些数字描述的是一项真实工作负载，而非合成 API 探针。相比只能启动应用窗口的启动器，它们赋予该项目更高的可信度。
不过，这项测试仍然很有限。一个相对较小的强化学习网络无法代表所有 Transformer、图像生成器、科学模拟或渲染管线。
开发压力最直接地落在 AMD 的 Windows 软件体验上。每一次成功的兼容性实验，都凸显出市场对仍假定 CUDA 存在的应用的需求。
NVIDIA 同样面临另一种压力。转译层检验了 CUDA 应用生态中有多少依赖于其他运行时能够复现的关键接口。
这两种压力都不会立即带来平台转变，但它表明开发者仍在寻找绕过厂商专属应用边界的方法。
该机制保留 API，而非完整 CUDA 平台
ZLUDA 可以转译部分接口，但 CUDA 应用往往依赖远超这些接口范围的行为。
一个 CUDA 应用通常包含运行在 CPU 上的主机代码和运行在 GPU 上的设备工作。主机负责分配内存、传输数据和启动内核。
二进制程序还可以调用优化库。这些库往往决定一款 AI 或科学应用能否以实用速度运行。
ZLUDA 为面向 CUDA 的组件提供替代实现，并将其连接至非 NVIDIA 后端。在 AMD 硬件上，这些后端使用 HIP 和 ROCm 库。
当程序使用已实现的运行时函数和已映射库时，该模型可以良好运行。一旦应用需要缺失的行为，它便会变得脆弱。
版本兼容性又增加了一层复杂性。CUDA 应用可能面向不同的工具包、二进制格式、库以及编译器假设。
该仓库固定使用 ZLUDA v6 preview 69、AMD HIP SDK 6.4，以及搭配 CUDA 11.8 的 LibTorch 2.3.0。固定版本将一组持续变化的依赖转化为一个可测试的组合。
这种纪律提高了可复现性，也意味着用户不应假定较新组件可以互换使用。
较新的 HIP SDK 可能改变库路径、导出符号或受支持的设备目标。较新的面向 CUDA 的应用也可能调用其固定兼容层尚未实现的函数。
项目报告称，cuBLAS、cuBLASLt、cuSPARSE 和 cuFFT 通过了其运行时检查。这些组件覆盖重要的矩阵、稀疏计算和傅里叶变换操作。
最显著的缺失部分是 cuDNN。NVIDIA 的 CUDA 深度神经网络库提供了许多神经网络工作负载所使用的优化原语。
该仓库表示，在其已验证的稳定 Windows HIP SDK 配置下，cuDNN 不可用。它还指出，该 SDK 缺少其他环境中可用的完整 ROCm AI 库集合。
这一缺失形成了明确的应用边界。依赖 cuDNN 的卷积密集型软件可能会失败，需要较新的开发栈，或需要额外的兼容性工作。
成功的强化学习工作负载在其测试路径中并不需要 cuDNN。它所执行的功能仅需密集矩阵操作。
这一细节同时解释了成果及其限制。项目选择的工作负载与其机器上可用的库相兼容。
运行时转译也不同于源代码可移植性。HIP 源代码可以针对不同后端编译和优化，而二进制兼容层必须推断并重定向现有行为。
源代码层面的工作让开发者能更好地控制针对特定架构的调优。当修改原始应用并不现实，转译则能提供更快的初始访问路径。
两种方法都不能保证性能完全一致。GPU 在执行宽度、内存行为、指令支持和专用硬件方面各不相同。
一个经过转译的函数可以产生正确输出，但采用效率较低的路径。反过来，映射后的厂商库也可能表现良好，因为 AMD 已对底层操作进行了优化。
这也解释了为何单项基准测试无法解决更广泛的性能问题。转译开销只是一个因素，库选择和内核行为可能主导总运行时间。
该仓库记录了一项于 2026 年 9 月 13 日进行的受控比较。它在同一项 RX 9060 XT 强化学习工作负载上，对每个运行时运行了十次迭代。
在移除每次试验的首次预热迭代后，上游路径报告的整体中位速度达到每秒 13,278 步。恢复出的自定义覆盖层达到 12,876。
仓库计算显示，在该测试中，自定义覆盖层约慢 3.03%。因此，它仍将公开的上游路径设为默认方案。
该比较评估的是同一台机器上的两种兼容性配置。它并未将 Radeon 显卡与 NVIDIA GPU 或原生 HIP 实现进行比较。
仓库中的历史数据采用了另一种训练配置，无法与这一受控测试直接比较。
对开发者而言，更实用的结论其实更简单：公开组件在不依赖私有或恢复出的二进制文件的情况下完成了所选工作负载。
这让流程更易于检查和复现。其他硬件上的独立结果将决定它是否能超越单机参考的意义。
一块经过验证的 GPU，仍留下巨大的兼容性缺口
这套配置是一个有证据支撑的实验，而非对 Radeon 显卡的通用 CUDA 支持。
RX 9060 XT 目前是该项目列出的唯一已验证设备。脚本能够识别更多 AMD 架构系列，但将其标记为候选设备。
AMD 的官方支持矩阵构成另一项限制。该公司表示，未出现在其当前表格中的 GPU，并不受相关 Windows 发行版的官方支持。
即使某块 GPU 被列出，也不代表它自动获得该仓库的验证。官方 HIP 支持与成功的 CUDA 翻译测试针对的是系统的不同层面。
用户需要兼容的 AMD 驱动、可正常运行的 HIP 安装、受支持的库、正确工作的 ZLUDA，以及始终处于已实现覆盖范围内的应用程序。
任何一层出现故障，都可能导致报错或结果不正确。有些问题会在安装期间显现，另一些则可能只会在持续计算后出现。
正确性比应用能否启动更值得关注。数值工作负载可能顺利完成，但由于精度、库或实现行为差异而产生不同的输出。
严谨的验证计划应比较预期输出、训练行为和可重复性，同时还应测试内存压力、长时间运行和故障恢复。
该仓库提供了脚本和有文档说明的工作负载，有助于其他用户开始这一过程。由于项目较新且硬件覆盖范围有限，独立验证仍然稀少。
ZLUDA 自身将其软件描述为面向非 NVIDIA GPU 的即插即用 CUDA 替代方案。其公开仓库也记录了大量实现改动和预览版本。
然而，即插即用接口并不等同于完整的行为兼容性。ZLUDA release history 显示，加载器、编译器行为、数据类型和 CUDA 版本处理仍在持续修复。
预览软件可能引入回归。项目固定一个已验证可用的版本，可以避免部分变化，但也会错过之后的兼容性修复。
Windows 安全软件带来了另一项实际风险。运行时拦截和库重定向可能与恶意软件使用的技术相似。
用户应仅从已明确识别的上游发行版本获取二进制文件，并验证哈希值。不应仅为强制未知软件包运行而关闭广泛的安全控制措施。
仓库提供的哈希验证在这里很有价值。它降低了被修改的下载文件悄然进入运行时的可能性。
但它并不审计上游代码，也无法证明每个依赖项都安全。组织应执行其常规的软件审查和构件控制流程。
许可证同样需要谨慎处理。该仓库包含自己的许可证和第三方声明，而 ZLUDA 使用开源许可证。
CUDA 仍是一个包含专有组件和许可条款的 NVIDIA 平台。用户必须了解其应用包含哪些可再分发文件，以及兼容性配置会下载什么内容。
该仓库强调仅使用公开上游组件的路径。这一选择有助于将当前方法与先前涉及恢复或私有库的实验性方案区分开来。
企业团队还面临另一个问题：支持责任归属。AMD 不会仅因某个方案使用 HIP SDK，就官方支持社区提供的 CUDA 兼容性方案。
NVIDIA 也不支持在 AMD GPU 上运行的 CUDA 应用。项目维护者无法替代任一供应商的服务承诺。
因此，这套配置不太适合未经大量内部验证便要求保证正常运行时间的工作负载。它对实验室、爱好者和测试可移植性的开发者仍更具吸引力。
评估该方案的团队应保留机器报告、精确的软件包版本、验证输出和应用日志。一个可搜索的工程知识库可以让这些构件与每次测试保持关联。
他们还应将测试与生产环境隔离。专用机器或可随时弃用的 Windows 镜像，可在驱动或库发生冲突时简化回滚。
核心问题不在于示例能否启动，而在于该应用能否在团队所需的硬件上产生正确、可重复的结果。
兼容层让 CUDA 的软件优势面临新的考验
该项目在边缘地带挑战 CUDA 对应用的锁定，同时也再次证明实现完整兼容性有多么困难。
NVIDIA 的优势包括硬件、驱动、编译器、调试工具、优化库、文档，以及多年来的应用集成。CUDA 是连接这些部分的接口。
兼容性项目可以复现部分调用，却无法复现整个开发环境。这一差异解释了为何此类项目往往在实现广泛可靠性之前就获得关注。
对 AMD 而言，兼容性为触及供应商尚未移植的应用提供了一条途径。当开发者维护两个后端时，原生 ROCm 和 HIP 支持仍是更清晰的路线。
这两种策略可以并存。翻译服务于现有 CUDA 二进制文件，而 HIP 支持为跨供应商部署而设计或转换的软件。
DirectML 及其他 Windows 接口提供了额外选择。它们可以提供供应商中立的加速，但应用必须明确采用这些接口。
OpenCL 和 SYCL 也在不同层面追求可移植性。它们的存在并未消除 CUDA 专用库或应用假设。
Hacker News 的讨论暴露了这种张力。一些评论者认为，开放标准应获得更多关注，因为封闭接口限制了硬件选择。
另一些人强调，可移植接口往往带来较弱的开发者体验。还有一种批评观点认为，针对特定硬件的优化使得任何通用层都无法匹配每个供应商。
两种立场都描述了真实的限制。开发者希望获得可移植性，但高性能内核依赖架构细节和经过调优的库。
ZLUDA 选择兼容性而非纯粹性。它让应用保留面向 CUDA 的假设，并尽可能进行翻译。
这种做法降低了初始迁移工作量。它也保留了应用预期的 CUDA 语言，而不是用独立标准取而代之。
这正是项目的核心反转：在 AMD 上运行面向 CUDA 的程序可以削弱硬件锁定，同时软件对 CUDA 的依赖仍然存在。
如果更多应用能够运行，CUDA 可能会成为一种被广泛面向的接口，其二进制文件可覆盖多个后端。这种结果将对 NVIDIA 的硬件排他性形成压力。
如果兼容性仍局限于特定工作负载，这些实验反而可能展现 NVIDIA 软件集成的深度。每一个缺失的库，都会成为开发者继续使用受支持 CUDA 硬件的另一个理由。
AMD 在 Windows 上的原生进展改变了这一计算。更好的 HIP 库和更广泛的 PyTorch 支持，为翻译项目提供了更坚实的基础。
当应用能够采用 AMD 官方软件包时，它们也降低了对翻译的需求。这是一种健康的重叠，并不必然构成冲突。
重要的竞争信号将来自应用行为。支持矩阵很重要，但用户通过能否安装、完成工作并返回正确结果的程序来体验兼容性。
翻译后的 API 名称列表无法替代这种证据。没有可比较原生实现的孤立基准测试同样不能。
未来最有价值的报告将说明应用版本、GPU、驱动、HIP SDK、ZLUDA 版本、所使用的库、输出检查和持续性能。
负面报告同样重要。有文档记录的失败能够指出维护者必须解决的缺失功能或不兼容假设。
这些证据还可以指导应用供应商。若某一依赖项反复导致失败，就可能有理由采用原生 HIP 后端或其他可移植执行路径。
因此，即使该仓库永远无法成为通用运行时，它依然重要。它创造了一个可复现的测试面，用于衡量 CUDA 依赖从何处开始、又在何处结束。
三个信号将决定接下来会发生什么
更广泛的硬件报告、更深入的库覆盖，以及稳定的应用结果，将决定它能否成为实用的 Windows 选择。
第一个信号是对更多 Radeon GPU 的独立验证。RX 9060 XT 的结果需要在官方支持的 RDNA3 和 RDNA4 硬件上得到复现。
成功报告应包含精确版本和输出检查。简单的截图或识别出的设备名称，无法证明工作负载兼容性。
若能获得多项一致结果，将加强该配置可跨 AMD Windows 设备移植的主张。频繁出现特定架构故障，则会将其范围缩小为参考配置。
第二个信号是 cuDNN 或等效神经网络功能的覆盖。许多 AI 应用依赖于当前已验证稳定栈无法通过此路径提供的操作。
支持可能来自更新的 HIP 发行版、新增的 ZLUDA 映射、应用修改或另一种库桥接方式。每条路径都带来不同的维护成本。
卷积密集型应用若能正常运行，将实质性扩大项目的相关性。若持续缺失，则许多图像和模型工作负载仍将无法实际采用。
第三个信号是跨应用和工具链更新的稳定性。当前的成功依赖于固定版本的 ZLUDA、HIP 和面向 CUDA 的 LibTorch。
开发者应关注后续 ZLUDA 版本是否保留该测试、较新的 Windows HIP 软件包是否仍兼容，以及较新的应用是否引入不受支持的调用。
当升级无需重新发现脆弱的组合时，兼容性项目才会获得更大价值。回归将表明该方法仍需要密集的手动维护。
在这项评估中，性能应排在正确性之后。一个偶尔返回错误结果的翻译应用，无论吞吐量多高，价值都很有限。
在确认正确性后，比较应纳入存在原生 HIP 构建时的原生 HIP 版本，同时使用等效的应用设置和相同硬件。
与 NVIDIA 的比较可以回答采购问题，但无法隔离翻译开销。GPU 架构、内存容量和供应商库都会影响结果。
当前项目已经跨过了一个有意义的门槛：它将一组上游组件转化为可重复执行的 Windows 流程，并完成了其最初的目标工作负载。
它尚未达到其醒目标题所暗示的门槛。Windows 上的 CUDA for AMD 仍是一项兼容性主张，且仅与特定软件及一款经过验证的 GPU 相关。
有兴趣测试的开发者，应先从该仓库记录的版本和诊断脚本开始。在安装任何内容之前，应根据 AMD 当前的支持列表确认自己的 GPU 是否兼容。
接下来，应选择具有已知正确参考结果的工作负载。这个参考结果比程序是否检测到一台名为 CUDA 的设备更重要。
团队应记录故障，并在可能的情况下发布可复现的兼容性报告。共享证据将揭示，这座桥梁究竟支持一类应用，还是仅能覆盖零星案例。
如今，更宏大的问题已具备可衡量的形式：有多少 CUDA 软件能够在无需修改源代码的情况下迁移到 AMD 硬件，而最先出现故障的又会是什么？
未来几个月，请关注兼容性矩阵、与 cuDNN 相关的进展，以及真实 Windows 应用的测试结果。这些信号将决定 Windows 上的 CUDA for AMD 会成为可靠方案，还是仍只是一项具有启发意义的实验。
