6 月 29 日，开源 CUDA 兼容层 ZLUDA 发布 v6，改善了 Blender 和 Windows 的使用体验。开发者还展示了让 AMD 显卡运行老游戏 PhysX 特效的进展，但这项功能仍处于早期测试，尚未并入正式版。同一篇博客披露，项目约三个月前已失去商业资助。作者 Andrzej Janik 写道："ZLUDA 开发不再有商业资助，所以它现在又是我的周末项目了。"
自 2020 年创建以来，ZLUDA 多次更换目标平台和资助方。现在，项目已经能够让部分 CUDA 应用在 AMD GPU 上运行，持续维护所需的资金却仍不稳定。这次资助结束的原因没有公开，今后的开发速度将更多取决于作者能投入的业余时间。
Blender 和 Windows 支持改善，PhysX 仍在早期测试
PhysX 是此次更新博客重点展示的功能。Janik 在持续了数月的一个 PR（#651）中开发了 32 位 PhysX 支持，并展示了 AMD GPU 在 2010 年《Mafia II》最高画质、开启 PhysX 条件下的运行结果。Tom's Hardware 根据对比截图称，使用 ZLUDA 后帧率约为原来的 3 倍。开发者强调，这只是其个人电脑上的早期测试，仍有流体效果错误、向 Steam 游戏加载 ZLUDA 的方式不完善等问题，普通用户最好等 PR 合并后再尝试。它还让部分游戏中原先只在 NVIDIA GPU 上出现的额外碎片等效果有机会在 AMD GPU 上呈现。
新增的基础纹理支持，已经足以满足 PhysX 和 Blender 的部分需求，让重建后的 ZLUDA 再次运行 Blender。旧版 ZLUDA 此前就曾支持 Blender，此次恢复支持也弥补了项目重建后的一处缺口。Janik 对项目优先级也作了调整：结束商业资助后，他开始投入更多时间做自己觉得"最有趣"的功能。
Windows 体验也有所改善。过去，用户需要自行寻找、配置 ROCm 性能库，也就是 cuBLAS、cuDNN 等库在 AMD 平台上的对应工具。开发者在博客中抱怨，Windows 用户往往需要在过时的官方 SDK 和较新但可能有故障的每日构建版之间选择。v6 的 zluda.exe 可以自动检测并加载可用库，不必再为此手动传参；缺失时也会提示应安装什么。
机器学习方向也在陆续修复问题，包括编译器故障、性能库改进和新 PTX 指令支持。用户提供的 PyTorch 执行记录（trace）是线索来源之一。不过 Janik 表示，自己无法分析收到的每份记录，只能尽量多看。
Janik 在博客中写道："大部分新功能此前明确不在 ZLUDA 的 roadmap 上。"PhysX、纹理支持和 Windows 便利性改进，反映了项目优先级的变化。此前接受商业资助时，ZLUDA 明确聚焦机器学习；转为业余维护后，作者可以投入个人感兴趣的用途，但机器学习兼容性仍需要持续修补。
从 Intel 到 AMD，项目多次更换方向和资助方
ZLUDA 的六年经历中，资助方的变化几次影响了技术方向。
Andrzej Janik 在 2020 年创建了这个项目，最初的目标是让 CUDA 程序运行在 Intel GPU 上。据他后来在项目 README 中的回顾，Intel 在 2021 年评估后认为缺乏商业理由，未继续推进。2022 年，AMD 介入资助，项目转向 AMD GPU 和 ROCm 平台，开发期间不公开代码。Janik 称，经过约两年开发和评估，AMD 也认为"在 AMD GPU 上运行 CUDA 应用没有商业案例"，不再继续资助。根据合同条款，Janik 获准将代码开源，这就是 2024 年 2 月的 ZLUDA 3。
2024 年 3 月，媒体又关注到 CUDA 安装包中的许可限制："不得对使用 SDK 元素生成的输出进行逆向工程、反编译或反汇编，以将其转换为针对非 NVIDIA 平台。"据 Tom's Hardware 梳理，这条款自 2021 年起就存在于在线 EULA 中，也出现在 CUDA 11.6 及更新版本的安装文档中。CUDA 11.6 早在 2022 年已发布，这一限制早于 ZLUDA 在 2024 年 2 月的开源。
2024 年 8 月，AMD 要求 Janik 下架其资助期间产生的代码。Janik 照做后，将代码回退到接受 AMD 资助之前的状态，再重建相关实现。同年 10 月，一家未公开身份的机构提供了新的商业资助，Janik 称之为 ZLUDA 的"third life"。新方向明确聚焦 ML 工作负载：llm.c、llama.cpp、PyTorch、TensorFlow。同时收缩对 OptiX（光线追踪）、老 GPU 架构和 Windows 便利工具的支持范围。
Tom's Hardware 猜测，新资助方可能是一家 AI 公司，但其身份始终没有公开。从公开的 2024 年计划看，项目主要面向 RDNA 1 及更新的非服务器 AMD GPU。这轮资助在不到一年半后结束。Janik 没有解释原因，只提到开发者 Violet 已成为"首位 Developer Emeritus"，即向不再活跃的贡献者致敬的荣誉身份。
兼容层能降低迁移成本，谁来承担长期维护费用
ZLUDA 已展示了技术可行性，但持续维护还需要稳定的付费者。GPU 厂商、AI 公司和云厂商，都可能从兼容性改善中受益，各自愿意承担多少费用则取决于具体用途。
对 GPU 厂商而言，兼容层与原生开发工具需要分配研发资源。AMD 有 ROCm/HIP，Intel 有 oneAPI。兼容层可以降低客户试用新硬件的门槛，HIPIFY 这样的源码移植工具则能帮助开发者直接适配本平台。AMD 当年认为 ZLUDA"没有商业案例"，显示其当时选择了其他投入方向。
对 AI 公司而言，GPU 供给、价格和移植成本都影响选择。如果希望使用价格或供给条件更合适的其他硬件，公司就需要在采购收益与软件迁移投入之间权衡。拥有少量 AMD GPU、希望少改代码的小团队，是兼容层的一类潜在用户。大型团队同样需要比较直接移植、使用 ROCm 原生支持和依赖兼容层的总成本。
对云厂商而言，同时提供 NVIDIA 和 AMD 实例可以满足不同需求，但客户能否顺利迁移软件也会影响实例使用率。资助兼容层是否划算，需要看新增需求能否覆盖适配和支持成本。
许可条件也是商业部署需要核查的一部分。NVIDIA 的相关条款限制为非 NVIDIA 平台而逆向处理 SDK 输出的行为，具体方案是否涉及这一行为，需要结合实现和所使用的软件判断。企业还需要评估相关许可的适用范围，以及持续依赖这类工具的维护风险。
不同兼容路线，都要跟上 CUDA 和性能库的变化
ZLUDA 之外，也有其他项目帮助 CUDA 开发者使用不同硬件。Spectral Compute 的 SCALE 工具包采用兼容 CUDA 的编译器和接口，目标是在尽量不改 CUDA 源代码的情况下，为 AMD GPU 编译程序；这与直接执行已有 CUDA 二进制不同。摩尔线程的 MUSA 架构和 MUSIFY 工具则提供另一条迁移路径，其公开文档说明，MUSIFY 可以辅助把 CUDA 源代码转换为 MUSA 源代码。
这些路线的共同挑战是持续适配。CUDA 会增加 PTX 指令、库 API 和精度模式，兼容工作需要随之更新。cuDNN、cuBLAS、NCCL、TensorRT 等性能库也经过了面向 NVIDIA 硬件的优化。ROCm 的 MIOpen、rocBLAS、RCCL 等对应库，在接口细节和计算行为上未必完全一致。ZLUDA 从 PyTorch 执行记录中修复的问题，既包括这些库的适配，也包括编译器和指令支持。
Janik 在 Q4 2024 更新中记录了 PTX 解析器的一个例子：文档规定的语法较严格，实际编译器却接受某些修饰符顺序不同的写法，而这类写法也出现在 NVIDIA 自己的库中。ZLUDA 需要同时处理规范和实际代码之间的差别，不能只照文档实现。要找出并兼容这些细节，需要额外的测试和维护。
从运行成功到长期可用，还需要性能验证和维护人手
CUDA 的积累包括开发者习惯、现成代码，以及库和框架的优化。软件越集中于这一平台，迁移到其他硬件时需要验证的工作就越多。兼容层试图减少这部分负担，让用户保留已有软件，再选择不同 GPU。它能降低迁移门槛，但仍需要证明具体应用的稳定性和性能。
NVIDIA 的性能优化也增加了适配难度。例如，cuDNN 的卷积实现可能针对特定张量形状和 GPU 代际调优；迁移到 AMD 硬件后，需要通过对应库或其他实现重新优化。PhysX、Blender 和模型训练各有性能要求，需要分别测试。硬件价格优势能否保留下来，最终要看实际运行速度、可靠性和维护成本。
ZLUDA 已经让部分未经修改的 CUDA 应用在 AMD GPU 上运行，这是 Janik 与贡献者们完成的工程进展。目前尚未解决的是，如何让这项工作获得持续投入。项目再次转为业余维护后，兼容性承诺与作者可投入时间之间的差距，也需要用户自行评估。
现在，Janik 可以按个人兴趣安排开发，PhysX 测试和 Windows 改进都反映了这种变化。与此同时，PyTorch 用户的故障报告、CUDA 新指令和 ROCm 不兼容更新，仍会持续产生维护需求。他已经表示，今后可投入的时间减少，季度进展博客也会降低频率。对依赖 ZLUDA 的用户而言，接下来要关注的是兼容性改善的速度和维护支持能否延续。
