6 月 29 日，开源 CUDA 兼容层 ZLUDA 发布了 v6 版本，带来了项目历史上最丰富的功能更新：32 位 PhysX 支持让 AMD 显卡终于能渲染老游戏中的布料撕裂和粒子碎片，Blender 的纹理管线首次在非 NVIDIA GPU 上跑通，Windows 加载器不再需要用户手动配置性能库路径。但同一篇博客文章也宣告了商业资金的第三次枯竭。项目作者 Andrzej Janik 的措辞平静得近乎冷淡："ZLUDA 开发不再有商业资助，所以它现在又是我的周末项目了。"
这不是 ZLUDA 第一次被"打回原形"。自 2020 年创建以来，这个项目经历了三次资助-断供的循环。每一次资金断裂都不是因为技术做不出来，而是因为出钱的人最终发现，CUDA 兼容层在商业上是一道无解的题。
v6 做了什么：当没有人付钱之后
v6 的功能列表看起来不像一个失去资金的项目。PhysX 支持是用户呼声最高的需求之一，Janik 在持续了数月的一个 PR（#651）中实现了 32 位 PhysX 指令的翻译。结果是 AMD GPU 用户可以在 2010 年的《Mafia II》中以最高画质开启 PhysX 效果，帧率提升约 3 倍——在此之前，这些物理特效在非 NVIDIA 硬件上完全不可见。
纹理支持的加入使 Blender 首次能在 ZLUDA 上运行。这个进展部分得益于 PhysX 渲染需求倒逼的架构改动，部分得益于 Janik 对项目方向的一次根本调整：既然不再为商业需求服务，那就做自己觉得"最有趣"的事。
Windows 体验也获得了实质改善。旧版 ZLUDA 在 Windows 上的最大痛点不是兼容性，而是用户必须自己找到并配置 ROCm 性能库（cuBLAS、cuDNN 等的 AMD 对应物），而这些库在 Windows 端的发布一直混乱——要么用官方但过时的 SDK，要么用新鲜但 bug 不断的 nightly build。v6 的 zluda.exe 不再需要用户手动传参，而是自动检测并加载可用库；缺失时直接告诉用户该装什么。
在 ML 方向，v6 合并了大量 PyTorch 用户提交的 trace 驱动的修复：编译器 bug、性能库改进、新 PTX 指令支持。这些改进不来自任何产品路线图，而来自 Janik 逐一分析用户发给他的失败日志——一种典型的单人开源项目的维护方式。
但这些进展的方向本身就说明了问题。Janik 在博客中承认："大部分新功能此前明确不在 ZLUDA 的 roadmap 上。"PhysX、Blender 纹理、Windows 便利性改进——这些是"好玩"的功能，是"周末项目"会优先做的事。对商业资助方而言，ZLUDA 的价值在于让 PyTorch 和 LLM 推理在 AMD GPU 上跑得更快，但 v6 恰好在这个方向上的进展最碎片化。
六年的三次生死
ZLUDA 的融资史本身就是 CUDA 生态系统权力结构的一份简史。
Andrzej Janik 在 2020 年创建了这个项目，最初的目标是让 CUDA 程序运行在 Intel GPU 上。2021 年项目被放弃，原因未公开。2022 年，AMD 介入资助，要求 Janik 将目标切换到 AMD GPU 和 ROCm 平台，但要求保持低调——代码不公开。两年后，AMD 内部评估认为"在 AMD GPU 上运行 CUDA 应用没有商业案例"，切断了资金。根据合同条款，Janik 获准将代码开源，这就是 2024 年 2 月的 ZLUDA 3。
开源后不到一个月，NVIDIA 做出了反应。2024 年 3 月，CUDA 11.6 的安装文件中首次出现了翻译层禁令："不得对使用 SDK 元素生成的输出进行逆向工程、反编译或反汇编，以将其转换为针对非 NVIDIA 平台。"这条款自 2021 年起就存在于在线 EULA 中，但从未出现在用户安装时实际看到的文档里。时机耐人寻味。
2024 年 8 月，AMD 更进一步——不仅撤资，还要求 Janik 下架 AMD 资助期间产生的代码。Janik 照做了，然后从头重建了整个项目。同年 10 月，一家未公开身份的机构提供了新的商业资助，Janik 称之为 ZLUDA 的"third life"。新方向明确聚焦 ML 工作负载：llm.c、llama.cpp、PyTorch、TensorFlow。同时放弃了对 OptiX（光线追踪）、老 GPU 架构和 Windows 便利工具的支持。
这位未公开的资助方很可能是某家拥有大量 AMD Instinct GPU 的 AI 公司——翻译层能让他们运行 CUDA 生态的 ML 工具链而无需重写。Tom's Hardware 的报道也指向这个方向。但不到一年半，资金再次枯竭。Janik 没有解释原因，只提到团队另一名开发者 Violet 已成为"首位 Developer Emeritus"——一个开源项目用来致敬不再活跃的贡献者的荣誉头衔，用在这里意味着团队从两人缩编为一人。
不是技术问题，是商业逻辑问题
ZLUDA 的三次断供让一个模式变得清晰：问题从来不是"CUDA 能不能翻译"，而是"翻译了 CUDA 之后，这门生意怎么做"。
对 GPU 厂商而言，资助 CUDA 翻译层存在内在矛盾。AMD 有自己的 ROCm/HIP 栈，Intel 有 oneAPI。资助一个让用户继续写 CUDA 代码的翻译层，等于承认 CUDA 是行业标准、自己的原生平台不值得学习。AMD 在 2024 年的评估结论——"没有商业案例"——是诚实的。与其帮用户留在 CUDA 生态里，不如推动 HIPIFY 这样的源码移植工具，让开发者至少名义上"迁移"到 AMD 平台。
对 AI 公司而言，翻译层的价值取决于 GPU 供给。如果能买到足够的 NVIDIA GPU，翻译层没有意义。如果因为出口管制或供应链瓶颈买不到，翻译层理论上有用——但这类公司通常规模够大，有能力直接做源码级别的移植，或者转向 AMD 原生的 ROCm 生态。ZLUDA 能覆盖的是中间地带：有少量 AMD GPU、不想做代码改动、也不想付 NVIDIA 溢价的小团队。这是一个真实存在但极难商业化的市场。
对云厂商而言，同时提供 NVIDIA 和 AMD 实例即可，用户自己选择。翻译层不解决他们的问题。
还有一层法律风险。NVIDIA 的 EULA 禁止翻译层已不是秘密。虽然该条款的法律可执行性从未在法庭上被检验——软件 EULA 中"不得反编译"条款在不同司法辖区的效力差异很大——但对任何商业实体而言，依赖一个建立在灰色地带的单点工具来支撑生产级 AI 管线，风险-收益比难以通过。
替代者的困境
ZLUDA 不是唯一尝试打破 CUDA 锁定的项目。Spectral Compute 的 SCALE 工具包采用了不同技术路线，声称能让未经修改的 CUDA 二进制（.ptx 和 .cubin 文件）直接在 AMD GPU 上执行——不是源码翻译，而是二进制兼容。中国的摩尔线程开发了 MUSA 架构和 MUSIFY 移植工具，声称兼容 CUDA 编程模型，但具体实现细节未公开。
但这些项目面临与 ZLUDA 相同的结构性约束。CUDA 不是一个静态目标。NVIDIA 每个架构代际都会引入新的 PTX 指令、新的库 API、新的精度模式。翻译层本质上是一辆永不到站的追赶列车。而且 CUDA 的真正护城河并非语言本身，而是 cuDNN、cuBLAS、NCCL、TensorRT 这一整套在 NVIDIA 硬件上深度优化的性能库——它们的行为不仅依赖公开 API，还依赖未文档化的硬件特性。ZLUDA 的 PyTorch 兼容性需要逐条 trace 去修，就是因为这些性能库的替代品（ROCm 的 MIOpen、rocBLAS、RCCL）在行为上并不总是逐位等价。
Janik 在 Q4 2024 更新中详细记录了 PTX 解析器的一个典型案例：NVIDIA 的 PTX 文档定义了严格的指令语法，但实际编译器接受大量"非正式"的写法——操作数的顺序可以乱、可选修饰符可以省略。更麻烦的是，这些非正式写法恰恰出现在 NVIDIA 自己的库里。ZLUDA 必须兼容事实上的 PTX 方言，而不是纸面上的 PTX 规范。这种"bug-for-bug 兼容"的维护成本是持久且不可预测的。
护城河的真正深度
ZLUDA 的遭遇经常被解读为"NVIDIA 的 CUDA 护城河太深"。这个判断方向是对的，但不够精确。CUDA 的护城河不只是技术壁垒，而是一个正向飞轮：越多开发者使用 CUDA → 越多库和框架针对 CUDA 优化 → 越少人愿意用替代平台 → 替代平台生态越贫瘠 → 越多开发者选择 CUDA。翻译层试图从这个飞轮中间插入一个楔子——让 CUDA 生态的软件可以跑在非 NVIDIA 硬件上，而不需要打破飞轮本身。
但飞轮的另一半是 NVIDIA 持续投入的性能优化。cuDNN 的一个卷积实现可能针对特定 tensor 形状和 GPU 代际做了汇编级调优，翻译层无法复制这种优化——它只能用 AMD 的对应库去模拟，结果往往是正确但不高效。对于"能跑就行"的渲染类工作负载（PhysX、Blender），这可以接受。对于需要榨干每一滴算力的训练工作负载，性能差距会抵消硬件价格优势。
ZLUDA 的六年三次生死并不是失败叙事。Janik 一个人（加上短期队友 Violet）做到了让未经修改的 CUDA 二进制在 AMD GPU 上运行——这是一个反编译器和编译器工程领域的成就。问题在于，这种成就无法转化为可持续的商业组织。它是那种只有开源个人项目才能做的事：在商业逻辑无法成立的空间里，纯粹靠技术兴趣推进。
当前版本就是这种状态下做出来的——不是妥协的产物，而是释放的产物。Janik 不再需要回答"这个功能对公司有什么用"，只需要回答"我周末想不想做这个"。v6 的 PhysX 支持和 Windows 改善是这种自由的结果。但这也意味着，下一批 PyTorch 用户的 bug 报告、下一个 CUDA 版本的新指令、下一个 ROCm 版本的 breaking change——都不会有人全职处理了。
